The other week I had a customer asking me how they could keep clients from using a Management Point, yet still have it installed and functional to interact with some 3rd party software they wanted to use. That question didn’t have a simple answer. By default an SCCM 2012 client will randomly choose from any available MP in a site. The key things that control the choice over one MP versus another are if an HTTPS MP specifically is required. Clients also have a preference to use the MP in the same forest they are in, if several MP area available. For my customer, all the MP were HTTP and all in the same forest, so of their 3 MP all would have the same possibility of being chosen.
I tried an idea that turned out to work, which is to "hide" one of the MP. By “hide” I mean that it is still in AD and seen in an MPList call but will not be returned to clients which call their current MP and request other MP to communicate with. This means that normal client processes would randomize between 2 of the MP, but the third MP would be used only when specified or hard coded, such as during client installation. That third MP is still there and running as normal but it takes something like 3rd party software, boot media, or a client command line parameter for it to be used. Un-publishing the MP means that it won’t be listed in AD and normal location requests will not return it as an option. Screen shots on where this un-publishing can be done are below. The change can be seen by watching the clientlocation.log on the clients and looking for a line similar to the following, never changing to the "hidden" MP:
Assigned MP changed from <MP1> to <MP2>.
There is a desire in the SCCM community to allow clients to have an affinity to a specific MP, similar to the use of boundaries and Distribution Points (DP). To be clear this will not provide that affinity. It simply removes one or more MP from normal client use processes. It cannot be used to selectively make one MP serve a subset of clients. If you were to set a client to use this “hidden” MP it would, for a time. Various processes in the SCCM client would eventually ask for a list of available MP, and the results returned would be the other MP, and thus the clients would switch away from the use of this “hidden” MP. The MP would serve a limited purpose, until such a switch occurred.
Thanks go to Jason Sandys and Adam Meltzer for helping me provide clarity on this post.
6/27/2014 UPDATE – To provide better clarity I changed the post to reflect that MPList will still show the "hidden" MP and its object will still be in AD