Update: In Configuration Manager 2012 SP2/SP1 R2 this feature can now be implemented using boundary groups and doesn’t require this registry method. You can enable this feature in the Hierarchy Settings on the site:
A common request the product group has received is to provide a way to define management point affinity for a specific set of ConfigMgr Clients in a primary site.
Starting with ConfigMgr 2012 R2 cumulative update 3 (http://support.microsoft.com/kb/2994331) there is a new way to define management point affinity for clients.
Caveats of Management Point Affinity in CU3:
There are some caveats in the way management point affinity works in cumulative update 3. You can set a client to use a specific management point(s) by setting a registry value. When this registry value exist, It will cause LocationServices to bypass switching to any management point(s) during a Location Services Rotation unless it’s defined in the registry value.
The downside to this approach is if the management point(s) the client is forced to use goes down you will have an unmanaged client until the management point(s) is back online or the registry value is deleted or changed.
This method should only be used for management point(s) in a primary site. Clients in a boundary group of a secondary site will still use the secondary sites management point as a proxy management point. This can be used to set the initial management point communication for clients to register with a management point at a primary site before it starts to use a secondary site’s management point as a proxy management point.
This method is only for management point selection. This does not apply to distribution points, software update points, Fallback Status Points, or any other site system roles.
This method only works for intranet clients and intranet management points.
This method can’t be used to defeat the HTTPS preference over HTTP management point(s).
Only management point(s) in the same primary site as the client can be used.
- Computers in restricted network such as a DMZ where the client can only communicate with specific set management point(s) in the primary site.
How to Set the Management Point Affinity:
Below are snippets from my lab that I used to test out this new feature.
Site Servers / Systems:
CM12PR1 - (Site Server also Hosting a Management Point Intranet)
CM12IBCM - (Site System Hosting a Management Point Intranet)
WIN7CL1 – (Client currently using CM12PR1 as MP)
WIN7CL2 – (Client currently using CM12PR1 as MP)
WIN8CL1 – (Client currently using CM12PR1 as MP)
WINCPCL1 – (Client currently using CM12IBCM as MP)
How to Set Management Point Affinity:
Management point affinity is set by defining the following registry value.
Value Data: CM12IBCM.CONTOSO.LOCAL
Value Data: Is the FQDN of the Management Point(s) you want to allow the client to communicate with. You can set multiple management points in the REG_MULTI_SZ value one per line.
I manually set these values on four machines in my lab, but you could use Group Policy, Compliance Scripts, etc.
I set each of my four clients to use the opposite management point as they were currently communicating with as mentioned above.
After these values where set, I installed the cumulative update 3 on my 4 clients machines. The order shouldn’t matter here though you could set the registry values before or after installing the cumulative update 3 client update.
On WIN7CL1, I could see the following information in the logs after cumulative update 3 was installed:
We can see that Location Services can detect the new registry value and will filter out any management points that are not in the list.
Here’s a screenshot of my 4 clients after cumulative update 3 was installed. We can see each client switched management points.
This is not intended as a MP enforcement for “Mobile” devices such as Laptops and Tablets. This is intended for scenarios where it is really required like DMZ networks where communication may not be open to all management points in the site.