ConfigMgr 2012 SP1 meets Tablets – The case of the “Unknown”

Scary title

What do I mean by this?

In the last two posts, I wrote about Issues with Boot images and the default partitioning schema, I came across when preparing a deployment for some Windows 8 based tablets.

During this, we ran into a situation, that raised an interesting question with quite a bunch of even more interesting discussions, that I would like to highlight and hopefully get some additional comments/feedback on this.

“Unknown computers”

Within ConfigMgr, there is the concept of “Unknown Computers”. It’s a construct to allow further handling of machines, like OS Deployment, that aren’t known yet to ConfigMgr and to avoid pre-staging those computers. In the case of Operating System deployment, you e.g. have a Task Sequence advertised/deployed to those Unknown computers. Now if a new computer is booted via e.g. PXE or from a bootable USB Stick, it can start the Task Sequence.

I really like the concept, as it allows you to treat unknown and known computers differently.

Identification

So far so good. Now, to identify a computer, ConfigMgr uses the Mac Address and/or the UUID from the BIOS. Those values are some kind of the least common denominator, that is available at e.g. PXE boot or from within WinPE. If neither of those values is “known”, meaning no client so far has reported them, it’s considered an “Unknown computer” and handled appropriately.

Tablets

Most tablets are considered to be used wireless, preferably Wireless only. What makes sense, considering their primary usage scenario. However deploying an Operating System via a Wireless connection can be quite “interesting”, not to say almost impossible in most cases. After the Operating System has been applied, it can for sure be used exclusively on Wireless, but at least during the initial setup, a physical network connection is highly appreciated.

For this reason, most of those devices meant to be used in Enterprises as well, come with a optional USB to Ethernet converter or some kind of docking station. And here starts the problem. The Mac address is no longer the Mac address of the device. It’s the mac address of the USB adapter or the docking station. On typical Laptops, the docking station is more like a Port replicator or Breakout box and just “extends” the built-in hardware. So the Mac Address if connecting a laptop via a docking station is mostly the Mac Address of the built-in NIC. On the other hand on tablets, they often don’t have a built-in NIC, so there is nothing to extend.

The Issue

“So what’s the issue?”, you might ask.

Well, let’s go through a theoretic example. We have a Windows 8 Task Sequence deployed to “All Unknown Computers”. We take our brand new, shiny tablet, connect it to our network via the USB-to-Ethernet dongle or a docking station that we have available in our lab and PXE boot it. The tablet sends a PXE request to our PXE Service Point (PSP). The PSP looks up the ConfigMgr database and doesn’t find any entry for this particular MAC Address or UUID, that came with the request. So this computer is considered “Unknown” and as it has a valid Task Sequence deployed, it immediately starts downloading the appropriate WinPE, boots and starts the deployment process.

So far, so good.

The deployment finished, we verified that it’s working well on our device and want to start another deployment. so we unpack the next tablet, connect it to the same dongle or stick it into the same docking station and want to PXE boot. And … PXE aborts!

What?

We still have our bootable media, that we created in the first post, connect it to the tablet and boot from it. Btw. this can actually become a quite interesting experience on a Surface device, as this comes with one USB port only. Now having a USB-to-Ethernet dongle and a USB Stick to boot from … Gotcha We have to go back to good old active USB switches. Yeah.

The tablet has finished booting, but no Task Sequence shows up.

So we get back to the smspxe.log on the PSP and try to figure out, why it didn’t PXE boot as it was working fine on the last device. And I’m pretty sure you already know what you will see. The device is known already! And sure it is. The Mac Address of the Dongle/Docking station is currently assigned to the tablet that we just deployed.

This raises quite a bunch of problems, as we now need to target a second set of computers

Possible solutions

The easiest solution, and so far the recommended way from Microsoft, is to use one dongle or one docking station for each device. This is definitely not the best solution due to the cost impact and it will most likely also not work due to the inherence laziness of most IT persons (Laziness, the primary reason for automation). Looking at a typical lab, where new machines are being set up, you will most likely see pre-cabled docking stations. So the support staff will keep on using the same docking station or the same set of USB dongles for all the devices and just hand out a boxed device with each tablet.

A “better” solution could be to create a collection, that is based on the Mac Address of the devices, which are used to deploy those systems. So typically this collection will have a handful of Mac Addresses. Important part is, that those Mac addresses shouldn’t be used in day to day business, just for the plain purpose of deployment. Then one can advertise as many task sequences as required and limit the deployment(s) to only media and PXE. This way, the deployment isn’t visible from the Software Center but the support staff can continue to deploy new systems using PXE or other medias like USB Sticks.

Now to get rid of the “wrong” entries in this collection, a new package has to be created and deployed to those systems with a Configuration manager client only setting. This package has to execute two commands (e.g. via a batch or script) that

Update the DDR:

and Force a full hardware inventory:

This will make sure, that the client record is updated with the current configuration and the old information is aged out. However, as this requires, that the Dongle/Docking station, which was used for the deployment is disconnected, it should be executed in regular intervals. As soon as the client record was updated, it should automatically drop out of the collection and no longer execute these commands.

Optionally a local process on the computer could be initiated, that watches for the USB Dongle to be disconnected and then executes the above mentioned commands. However, that’s even more complex to implement. Maybe Compliance settings are another option and the above commands could be executed as an automatic remediation step.

Both solutions have their drawbacks. So I’m very interested to hear your comments about this on the myITforum SCCM email distribution list.