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):
A Content Location Boundary Group
and Site Assignment Boundary Groups reference sites:
A Site Assignment Boundary Group
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.
Client Installation Properties
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 p
urpose 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.
Hi Jason,
“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”
I’m still a little confused about how clients decide which MP’s they use and which are available to them.
If I install a secondary site at the remote, are clients locating in secondary site boundary more likely to use the MP at the remote site?
If I just install an MP in the remote site, and do not install a secondary site, does this have any affect on what MP the clients in the remote site will choose?
Will clients in a primary site use the MP in the remote site, whether I install a secondary site at the remote site or not?
Ideally, I want the clients in my remote site using the MP (even if just most of the time) in the remote site, and my primary clients never using the MP in the remote site – do I need to setup a secondary site to achieve this?
Other question is whether database replication from Secondary to Primary is any better than just letting clients communicate directly to MP at primary site?
Thanks very much
Shaun Croucher
Q. If I install a secondary site at the remote, are clients locating in secondary site boundary more likely to use the MP at the remote site?
A. No — there is no “more likely” — they will always use the MP at the secondary site if they are within a content location boundary group for that secondary site.
Q. If I just install an MP in the remote site, and do not install a secondary site, does this have any affect on what MP the clients in the remote site will choose?
A. No. Clients choose among multiple MPs within a primary site randomly. Actually, the prefer HTTPS capable MPs if the client is also HTTPS capable. Also, the lookup for an MP is done using the Global Catalog of AD so only MPs within the client’s forest can/will be available to the client. Barring these two caveats — HTTPS and forest — MP selection is random and not location aware or boundary enabled in any way.
Q. Will clients in a primary site use the MP in the remote site, whether I install a secondary site at the remote site or not?
A. Maybe, as mentioned above, it’s essentially random.
Q. Ideally, I want the clients in my remote site using the MP (even if just most of the time) in the remote site, and my primary clients never using the MP in the remote site – do I need to setup a secondary site to achieve this?
A. Yes. Multiple MPs within a primary site are only for availability.
Q. Other question is whether database replication from Secondary to Primary is any better than just letting clients communicate directly to MP at primary site?
A. That depends upon the number of clients and the bandwidth between the MP and those clients. Generally, I would say yes for two related reasons: secondary sites can only have one MP and if that MP is unavailable, clients cannot fail over to any other MP automatically.
Note that the documentation listed at http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_Plan_Service_Location is incorrect or least gives a false impressions of MP selection and I am actively communicating with the documentation team to get it corrected.
Hello –
You could have a Secondary Site Server (SSS) defined within a BG like a ‘region / campus’.
On the SSS have MP, SUP, SMP, DP (and whatever else). Other locations within the region/campus then just get a DP. The advantage here is the regional MP helps with the upward flow of client traffic from the defined ‘region/campus’ and still allowing the downward deployment traffic to come from a DP in each building.
So – I am thinking as far a Boundary Groups (BG) in this scenario would be:
* BG1 = “All clients” (For site assignment)
* BG2 = “Clients in the state of Michigan” – this would have a SSS with 4 roles (MP, SUP, SMP, DP) and have the boundaries for all sites (2 shown here) in Michigan
* BG3 = “Clients in Detroit” = DTW
* BG4 = “Clients in Grand Rapids” = GRR
Thus allowing all of Michigan clients to use 1 MP/SUP but each city having a DP/SMP using additional BG’s.
Correct? Agreed?
Thanks –
– Andrew
Hi Andrew,
Based upon the information provided, correct.
I’m not always a fan of using secondary sites because they are single points of failure in that clients will not do anything if the secondary site is not available — they are essentially orphaned until that secondary site server is restored to full functionality. Also, don’t overestimate the upward flow of traffic — it is often not impact-ful at all. For me, the choice to use a secondary site or not is a sliding scale with more clients and less bandwidth on the end of using a secondary site and less clients and more bandwidth on the side of just using a DP. This is a totally subjective scale and up to you to determine the exact thresholds based upon your knowledge of your network though.
Hi Jason,
I’m a little confused about Management Point selection in a Single Primary site environment, where the site server roles (DP’s MP’s etc) are spread over multiple locations in a multi-domain Forest.
When the Client selects an MP “Randomly from the AD forest”, is this from all available MP’s in the forest, or is the list ordered in some way based on sub-domain membership and/or AD Site constings.
From my testing, clients seem to prefer the MP’s from their local domain, which seems more logical, but contradicts what I keep reading.
Unfortunately, I can’t find any definitive documentation on the exact algorithm used.
Hi Mark,
You are correct. It prefers MPs in the same domain and same forest — the domain part is not listed in the official docs but I’ve gotten that straight from the product group and seen it in my own testing. AD sites are never considered though. The algorithm is fairly simple and will be the subject of my part of the MVP Experts panel next week Monday at TechEd (the video will be posted online sometime after the session).
J
Perfect – Thanks Jason. – Looking forward to seeing the video.
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/PCIT-B410#fbid=
I have a follow up question related to the clients preferring MPs in their own domain.
Take example AD Forest ABC.com with Domains EMEA.ABC.com and APAC.ABC.com
MP1 is in forest root ABC.com and an MP2 is in domain EMEA.ABC.com. There are no MPs in domain APAC.ABC.com. With your assertion that clients will look in thier own domain first, I assume that clients in clients in EMEA.ABC.com will prefer MP2 since it is in the clients domain. Now will clients in the forest root prefer MP1, since MP2 is in a sub domain, or will they get back a list with both MP1 and MP2 as equal possibilities. How about clients in APAC.ABC.com? Since they don’t have any MPs in their domain, will they prefer MP1 in the forest root, or will they get back a list with MP1 and MP2 as equal possibilities, as both MPs are in the ABC.com forest, even though MP2 is in another domain?
“I assume that clients in clients in EMEA.ABC.com will prefer MP2”
Correct.
“Now will clients in the forest root prefer MP1”
Correct. MPs in the same domain are preferred over those in the same forest but not the same domain.
“clients in APAC.ABC.com … will … get back a list with MP1 and MP2 as equal possibilities”
Since there are no MPs in the local domain for APAC clients, they will move on to the next criteria which is forest. There are two MPs in the same forest which will thus both be returned.
I asked our MS rep about this topic and received this response —
What criteria does the agent use to determine the closest management point based on its forest membership? The client uses AD to determine its network location, specifically the client compares the site boundary configuration with AD Site/Subnet configurations in Sites & Services to determine the “nearest” MP. After this the HTTPS/HTTP preference comes into play. Although MP functionality has evolved between 2007 & 2012 this aspect of the client hasn’t.”
Thoughts on this compared to the client using the domain and then forest as you indicated?
Hi Gary,
Unfortunately, that is totally incorrect. AD site and subnet configuration is never considered. My portion of the MVP Experts session at TechEd covers it pretty well: http://blog.configmgrftw.com/microsoft-system-center-2012-configuration-manager-mvp-experts-panel/. The information presented is directly from first hand experience and testing as well as e-mail threads and discussions with multiple members of the product group including one of the developers.
To directly answer the question, there is no such thing as nearest as far as MPs go. The client asks an MP to return a list of MPs to it and this list is prioritized by domain, forest, and then non-forest MPs. If the client is HTTPS capable, then two lists are actually returned: one for HTTPS MPs and one for HTTP MPs. Based on this, the client will prefer MPs from the HTTPS list (if HTTPS capable) and then randomly from each of the categories in order of priority as mentioned.
J
Hi Jason,
A great post. It certainly filled some of the documented vs. real-world experience knowledge gap.
I have a question about Automatic Client Push and Boundary Groups.
I have a single primary site with 14 distribution points across WAN connections. I have configured 14 Boundary groups for Content Location using AD Site Boundaries, and assigned the applicable local distribution point to each Content Location BG. I also have a single Site Assignment Boundary Group, that includes all AD Sites and IP Subnet boundaries. Discovered clients are being successfully assigned to the primary site in the console, however are not being automatically pushed the SCCM 2012 client. I have successfully configured the Site Client Push settings.
Reading through some of your other posts, I think that my problem is that I do not have any site system servers assigned for use by my Site Assignment boundary group. I had assumed that content location BG’s would take care of that? Do different rules apply for the initial Client push content? Should I add my Primary site system to the Site Assignment BG? I’m a little concerned that If I add my Primary Site Distribution point to the Site assignment boundary group, then all packages forever more will be pulled across the WAN from the primary site.
Hope my rambling questions makes sense.
Thanks Jason
– Scott.
No, adding site system’s hosting DPs to the site assignment BGs won’t help and will cause content location issues. What you described above about your BGs in the first main paragraph is correct and sufficient.
To figure out why client’s aren’t getting the client agent pushed to them, you need to start by examining ccm.log on the site server.
Jason,
I have Boundary Group question. My domain has 3 child domains and each child domain has 5 – 7 sites. Child 1 hosts the primary site with all roles and has a second site system server with DP role located at main data center. Child 2 is a secondary site with MP, DP and SUP roles. Child 3 is a site system server with DP, MP and SUP roles.
In your opinion, what is the best way to set up the Boundary Groups?
Thank you very much!
Boundary Groups should be based on DP and/or locations. Based on what you have above, it sounds like you have three total DPs. Thus, I would start with three boundary groups. Question though: Why do you have site systems in each child domain? Are the child domains geographically separated?
Hi,
how to find , which client is associate with which boundary. is possible form sccm console or sql database.?
Yes, it is possible, but it depends upon the boundary types you are using. There is nothing built in that is exposed to handle this directly though. If you are using AD boundaries or IP Subnet boundaries, then it’s pretty easy actually as both of the attributes are reported up to ConfigMgr by the client. If you are using IP Address Range boundaries, then you have to include some logic in your query to determine whether a client falls into a boundary.
Hi,
I have a question about fresh installed clients a a remote site.
At the remote site we setup a secondary site which has two network adapters.
One can communicate to our main network, where our primary site is located.
The other is only a local network with no connectivity to the internet or somewhere else.
We setup a pxe point on that secondary site and install clients within the capsuled network.
This works fine and I get status messages back from the tasksequence.
The problem is, that the clients don’t register or send ddrs to the primary site.
I can only see them as “unknown”.
Because of the capsuled network, the clients are not domain joined.
When I look at the client, they always try to reach the mps from the primary site.
I have set up a boundary for this network and assigned the DP/MP from the secondary site.
As far as I know the clients should use the secondary sites mp as proxy to reach the primary site.
Do you know why the clients don’t use the secondary sites mp?
They do, just not for everything. Basically, what you are seeing is by design. Secondary sites are not and are not intended to be gateways. Clients *must* be able to communicate with an MP in the primary site — there is no other possibility and as mentioned this is by design.
Hi, Have a question here.
We have one primary and two secondary sites. Have configured boundary group and associated preferred MP to that. However, i could see in console that client machine at secondary site shows secondary site MP in console and some shows primary site MP in console. Is that the correct way of working?
Preferred MPs are for MPs within a primary site *only*. Thus, unless you have multiple MPs in your primary site, using preferred MPs is useless and misleading. Clients use of an MP at a secondary site has nothing to do with preferred MPs.