SMPs in fast network boundary group is returned as ‘Remote’ when one of the site systems in the boundary group is marked ‘slow'

I have come across an interesting issue while working with a customer.  Essentially, while using SMP during operating system deployment, marking any system in the boundary group as slow will return all site systems as ‘Remote’ when the client requests for an SMP location.  Implications are that clients could end up connecting to a remote SMP on a slow link instead of a local SMP flagged as fast.

Overview

It appears that the boundary group configuration for link speeds to site systems does not function as expected when one or more SMPs are part of it. In the event that one site system is marked as a slow link all other systems within the boundary group are also marked as slow (remote) links. This prevents the usage of distribution points at a remote datacenter for secondary content locations (slow) and local state migration point servers (fast) for primary content access and user profile data storage. The below steps were taken to reproduce the issue.

All systems running System Center Configuration Manager 2012 R2

 

Task Sequence Design:

 

 

Deployment Properties:

 

 

 Two SMPs (DP1, DP2), 1 Distribution point (SCCM12)

 

 

DP1

 

 

DP2

 

 

SCCM12 (Distribution Point)

 

 

 Test Case 1:

The following was performed to show expected behaviour -- multiple systems defined in the boundary group all as fast connections.

  • All systems marked as fast links inside of Boundary Group configuration 

  

  • All SMP properties do not have "Allow fallback source location for content" selected. 

Results

  • Client executes task sequence and receives both DP1 and DP2 as SMP content storage locations.

 

 <<OSDSMSClient.log>>

SMP Location Info = <SMPLocationInfo><Sites><Site><SMPSite SiteCode="LAB" MasterSiteCode="LAB" SiteLocality="LOCAL"><LocationRecords><LocationRecord><ADSite Name="LAB-Site"/><IPSubnets><IPSubnet Address="10.0.0.0"/><IPSubnet Address=""/></IPSubnets><ServerName>http://DP1.lab.local</ServerName></LocationRecord><LocationRecord><ADSite Name="LAB-Site"/><IPSubnets><IPSubnet Address="10.0.0.0"/><IPSubnet Address=""/></IPSubnets><ServerName>http://DP2.lab.local</ServerName></LocationRecord></LocationRecords></SMPSite></Site></Sites></SMPLocationInfo> 

  • Both state migration points provided to client as expected.
  • SiteLocality set to "Local"

 

 Test Case 2

The below is an exact copy of the test case 1 process, but only one of the site systems in the boundary group was changed to a "Slow" connection. This resulted in all of the site systems being marked as "slow" links, and due to the configuration of the deployment the task sequence failed. 

  • One system marked as slow within boundary group configuration

  

  • All SMP properties do not have "Allow fallback source location for content" selected.

 Results

  • Clients receive SMP locations, all SMPs are marked as "Remote". Because deployment does not allow remote content locations, task sequence fails.

 

 <<OSDSMPClient.log>>

SMP Location Info = <SMPLocationInfo><Sites><Site><SMPSite SiteCode="LAB" MasterSiteCode="LAB" SiteLocality="REMOTE"><LocationRecords><LocationRecord><ADSite Name="LAB-Site"/><IPSubnets><IPSubnet Address="10.0.0.0"/><IPSubnet Address=""/></IPSubnets><ServerName>http://DP1.lab.local</ServerName></LocationRecord><LocationRecord><ADSite Name="LAB-Site"/><IPSubnets><IPSubnet Address="10.0.0.0"/><IPSubnet Address=""/></IPSubnets><ServerName>http://DP2.lab.local</ServerName></LocationRecord></LocationRecords></SMPSite></Site></Sites></SMPLocationInfo> 

  • Both state migration points are returned to the client
  • SiteLocality set to “Remote”

 

Conclusion:

As per the above test cases we can understand that if either one of the SMP or a DP in the boundary group is marked as ‘slow’, the site itself is marked as slow.  The reason for this behavior is that the site locality is based on the entire site.  The logic surrounding the calls SCCM make is based on the Site Locality and not the individual servers in the site.  So, if any DP or SMP in the site is remote, the entire site is marked ‘Remote’.  There is no method for the SCCM to mark a site as ‘Remote’ and ‘Local’ at the same time and this appears to be a limitation by design.

The only way to get around this limitation is to mark all the site servers – DPs and SMPs in the site as ‘Fast’ in order for the site to be considered ‘Local’.

 

Arvind Kumar CM

Support Engineer | Microsoft System Center Configuration Manager  

Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights.