If you have a site distributed over a wide geographical area, you might find that you have problems with how clients retrieve their content. We had a situation to which I alluded here, namely a remote site downloading all its Config Manager data over a throttled WAN link.
Anyway as promised, I thought I’d put my thoughts into a blog relating to content access and remote sites.
My site already had two boundaries set. One for the main Config Manager geographical location (we’ll call it SCCM_Boundary1), and another for location elsewhere in the United Kingdom (SCCM_Boundary2). These geographical locations are defined in AD as AD sites, so we’ll call them AD_Site1 (main) and AD_Site2 (remote) for ease here.
Still with me? I had to retype that bit a few times. Too many sites! o.0
I had previously confirmed that:
PCs in AD_Site1 were part of the Config Manager site code XXX, and assigned to the boundary for SCCM_Boundary1.
PCs in AD_Site2 were part of the Config Manager site code XXX, and assigned to the boundary for SCCM_Boundary2.
Still with me? Good!
I can see in the CCMSETUP.log that the client is aware of their AD Site. However I was always uncomfortable with PCs at the remote site trawling up the WAN link and talking to servers at the main site. It must have been torturous. I spent a great deal of time and effort lobbying for a server at the remote site, and eventually I got one sorted out.
I whacked on the Distribution Point and Management Point role; once the server had settled down, I then started tinkering with the Boundaries and Boundary Groups.
Please bear in mind that the two boundaries were already established in Config Manager on the basis of the Active Directory Site.
As the Boundaries were already set, two, as per our Active Directory sites, I created four Boundary Groups:
AD_Site1 – Server Assignment
AD_Site2 – Server Assignment
AD_Site1 – Site Assignment
AD_Site2 – Site Assignment
I added all the Site1 MPs and DPs into a boundary group I named “AD_Site1 – Server Assignment” and all the Site2 MPs and DPs into a boundary group named “AD_Site2 – Server Assignment” as references. I did not tick the site assignment option; that’s apparently against best practises! I’ll cover that in a tick though.
Why individual site assignment boundary groups, well this was a result of how I interpreted a TechNet document here. Specifically:
When you configure boundary groups for site assignment, ensure that each boundary in a boundary group is not a member of another boundary group with a different site assignment. Boundaries that are associated with more than one assigned site are called overlapping boundaries. Overlapping boundaries are not supported for site assignment. However, overlapping boundaries are supported for content location.
- Overlapping boundaries for site assignment can prevent clients from joining the site you expect.
- Overlapping boundaries for content location can provide clients access to content from multiple content sources.
- To help avoid overlapping boundaries for site assignment, consider using of one set of boundary groups for site assignment, and a second set of boundary groups for content location.
I then added the MPs for both sites into their respective site assignment boundary groups. I ticked the option to “use this boundary group for site assignment”.
I then added each boundary group to its respective Boundary via the General Tab.
Now you may ask why I added the MPs, when preferred access only applies to content from a DP. Well with Config Manager 2012 SP2, you can now set preferred MPs instead of the cack handed MP affinity pushed in Cumulative Update 3.