Controlling Management Point access during OSD

*** Update - I wrote a tool called ManageMP that let's you specify MP's to be blocked and on which subnet a client has to be for the block to take place, check it out here

I wrote a tool called SwitchMP to force an existing ConfigMgr Client to perform Management Point rotation, and while doing so attempt to control which Management Point the Client eventually selects to use.

See, there’s no real Location Awareness for Management Points in ConfigMgr, not based on subnet’s and such, more to do with realms, security (HTTP or HTTPS), domain, forest etc. The tool runs in a full OS and gives you control over which Management Point a ConfigMgr Client uses. Right now we don’t have that functionality in our outside of the product.

Anyway there was a hole here, OSD and WINPE. Some people are experiencing issues with Management Point selection during OSD for devices residing in DMZ’s or, in a restrictive part of the network.

They get failure because the selected Management Point is not contactable. I haven’t looked into it beyond noting that some are having the issue.

This led me to wonder how you could control Management Point access very early on during OSD WINPE build phase, and I came up with the following:



 NOTE: I meant to use >> not >, either work fine but just be aware that redirection will either append (>>) or overwrite (>) the hosts file, for a booting WINPE the hosts edits are temporary as a reboot will start WINPE loading again with a new hosts file, but if hosts is staying around it's always a good idea to append so as to not lose the existing contents of hosts.

It worked.

Some notes:

  • I have two Management Points available and created dynamic bootable media from a stand-alone Primary Site server
  • I specified all the Management Points
  • In the Command Line box I specified the Management Point I want WINPE to ignore
  • I did this test twice, swapping the Management Point names around so that both were tested by being blocked and it worked
  • I didn’t let it run through a Task Sequence, I let the boot image present a list of task sequence which it can only have got from one of the unblocked Management Points so as to prove that you can ignore a specific Management Point

I’ll do some more tinkering and write a tool that should open up far more control of Management Point usage during WINPE booting phases of OSD.

I know the above solution may work out good for some of you experiencing Management Point selection issues during OSD WINPE phase, let me know if it does.

  • Also note that once the list of Task Sequences is presented, at that point you have full copies of each of those Task Sequences cached and ready to go, so the key element being tested here, Management Point communication blocking has been tested.