Boundary Groups were introduced in ConfigMgr 2012 to combine boundaries together and give them one of two common purposes:

  • Content Location
  • Site Assignment

These are the same two things that boundaries were used for in ConfigMgr 2007; however, all boundaries were used for both purposes in 2007 and there was no way to separate them out. In 2012, you assign boundaries for one (or both) purposes by placing them into a Boundary Group. Also, unless a Boundary is in a Boundary Group, it is not used for anything.

Based on this, Boundary Groups can be classified as one of the two types (or both) based upon what they reference. For Content Location boundaries, the Boundary Group references a site system hosting a Distribution Point (DP):


and Site Assignment Boundary Groups reference sites:


This is pretty straight-forward but what’s not clear (from the documentation or console) is whether you should add a secondary site to a Site Assignment Boundary Group. There has also been some confusion in the forums, other blogs posts, and among us (the MVPs) about what you should or should not do and why.

The reason I’ve heard that you shouldn’t do this is because secondary sites don’t manage clients and thus clients can not be assigned to them. While this is a true statement, it is not a reason to not set a secondary site in a Site Assignment Boundary Group (beware of the double-negative in this sentence). Actual client site assignment is something the client does after it is installed – this site assignment process, if not specifically forced by the SMSSITECODE property during installation is smart enough to realize that the site code discovered through auto-site assignment is for a secondary site and thus the primary site code must be used. However, if you specifically force a client to install to a secondary site using SMSSITECODE=SS1, then you will run into problems – specifically, you’ll get the following message in ClientLocation.log: “Attempting to assign client to SS1 site that does not match assignment requirements”. This is ultimately no different than ConfigMgr 2007.

Note that by default, client push from the console hard-codes the use the the SMSSITECODE property to the primary site’s code; this shouldn’t be changed without very good reason. You can see this by navigating to Overview –> Site Configuration –> Sites in the Administration workspace, selecting a site in the details pane (primary or secondary), choosing Client Push Installation from the Client Installation Settings fly out menu on the ribbon bar (or right-click context menu), and finally selecting the Installation Properties tab on the Client Push Installation Properties dialog.


So, should you or shouldn’t you use a secondary site in a Site Assignment Boundary Group? The answer is that both ways are valid. But, what’s the difference?

If you don’t use a secondary site in a Site Assignment Boundary Group, the only ramification is that during client push, the initial CCMSETUP files will come from the primary site server. This does not include all of the files required for client setup as those come off of DPs in ConfigMgr 2012. What this implies is that you must have a/the DP from the secondary site directly referenced in a Content Location Boundary Group that is applicable to the client is question based upon the boundaries that it contains.

The next obvious question (to me at least) is how would a client know if it is within the scope of a secondary site if there is no secondary site specified in a Site Assignment Boundary Group? The answer, although it is somewhat non-intuitive and maybe even backwards, is that a client uses Content Location Boundary Groups for this. Why does it do this? I can only speculate on this one, but my thinking is that this is not really a site assignment task. As mentioned above, clients aren’t really assigned to a secondary site; they are simply using the resources – MP, DP, SUP – at a secondary site. Also, site assignment is a one-time thing; once a client is assigned to a site, it will not try to re-detect the site it belongs to unless it is manually forced to do so. Content Location is an on-going, ad-hoc activity based upon the client’s current network status however. Thus, this lines up with a client’s ability to use other secondary sites or even go straight to the primary site depending upon where it is located network-wise.

Note that none of this implies that MPs are located using Content Location Boundary Groups, just the fact that a client is within the scope of a secondary. MP retrieval in ConfigMgr 2012 is not based on client location, just site assignment. The above also does not imply that clients will fallback to a primary site if the MP in the secondary site is down; when an MP at a secondary goes down, clients within the scope of that secondary are essentially on an island unless you change the Boundary Groups and wait for their 25 hour re-evaluation cycle or the clients detect a network change.

If you do use a secondary site in a Site Assignment Boundary Group, then client push will be initiated by the secondary site server and the initial CCMSETUP files will also come from that secondary site. The rest of the pre-requisite files and other files needed by CCMSETUP, will still come off a DP. So in reality, the difference between using a secondary site in a Site Assignment Boundary Group and not using it is just which site server initiates the push a single downloaded file from that site server: ccmsetup.exe.

A couple of things not to do with Boundary Groups when a secondary site exists include the following:

  • Overlapping boundaries for Site Assignment Boundary Groups. Specifically, overlapping boundaries occur when two Boundaries assigned to two different Site Assignment Boundary Groups include the same set of IP addresses. These are officially unsupported and will cause odd results. Don’t do it.
  • Use a Site Assignment Boundary for a secondary site without a Content Location Boundary Group. Although there aren’t any technical problems with doing this, it’s pointless to do this because clients will not use any of the site systems in the secondary site thus defeating the purpose of the secondary site in the first place.

As a final recommendation, don’t mix your Site Assignment and Content Location Boundary Groups; i.e., don’t reference a site for Site Assignment and site systems for Content Location in the same Boundary Group. There are a couple of reasons for this including simplicity and conceptual separation. Another potential reason is because overlapping boundaries are in fact supported for Content Location.

Thanks to Aaron Keller for reviewing the above.