I was recently pulled into a project with a client that is enrolling their estate into Autopilot. This would normally be unexceptional, but this client had a several challenges that made this process difficult. We devised a novel approach using WIM Witch and The Microsoft Deployment Toolkit (MDT) to mitigate risk, meet the client’s needs, and create a simple process for enrollment.
– The organization is global
– Each location has its own unconnected forest and domain
– No centralized management had ever been implemented
– Local admin was enabled almost everywhere
– No consistency with vendor and models
– Many systems are field in remote locations with inconsistent and poor internet connectivity
The client also had a set of criteria to be met:
– They needed a break-glass solution in the event of enrollment or provisioning failure
– Had to be simple as the process would be user driven
– The process had to support multiple languages
– All existing data needed to be removed
– Minimal down time
While it would have been possible to have users enroll their devices in their existing state into Intune, there would have been an undesirable amount of administrative intervention to then wipe the devices post enrollment. This would have also increased user down time as the devices would essentially be provisioned twice. Additionally, since there was no consistency in the versions of Windows 10, systems would likely require a Feature Update along with provisioning.
The process we designed would use WIM Witch to handle the device enrollment into Autopilot, the various language needs, and break glass solution. We would then use MDT to deploy the WIM Witch image via Task Sequence on an ISO, allowing the device to be easily and quickly wiped and provisioned. The ISO would be written to USB and sent to the users.
Like any other WIM Witch build, we imported a WIM and .Net binaries from a Windows 10 ISO. We also imported the three Language Packs and Local Experience Packs for the languages they needed to make available, as well as the Feature on Demand binaries.
Leveraging the Language Pack, Local Experience Pack, and Feature on Demand support introduced in version v1.4.0, we selected the required options to support their supported languages through their environment. We also opted to include .Net 3.5, updated the OneDrive client, and chose to apply the latest updates.
Removing the In-box Apps
The client wanted to remove the gaming related apps. WIM Witch was happy to oblige.
By using the “Retrieve Profile” option, we downloaded the JSON file that would correctly register the device to the appropriate profile. We enabled the option, and selected the downloaded file.
By all rights, the onboard Windows 10 drivers included in the image should be enough to get the machine up and running. Just to be safe, we opted to include the network drivers from the WinPE driver packs from HP and Dell (Lenovo doesn’t have an all-purpose PE driver pack). This would help ensure that Windows would have a better chance of connecting to the internet.
Breaking glass – leveraging the flexibility of WIM Witch v1.5
Version 1.5.0 of WIM Witch introduced a feature set that allows the user to add their own customizations to the build process. In this scenario, we leveraged the feature to meet the break glass requirement.
In this case, the plan was to create a folder off the root of C: called “BackUpPlan”. Within this folder we would add the installer for TeamViewer. If something were to go wrong during provisioning, helpdesk could coach the user through the installation of TeamViewer. Once installed, Help Desk could connect to the computer.
To make this magic happen, we needed one simple checkbox:
Making It So
The build process went off without a hitch, and WIM Witch dutifully handled the customizations we selected. Once our other customizations had been applied, WIM Witch paused the build process as expected. She displays the following warning:
The following dialog box pops up when the process is paused:
With the build process paused, we can manipulate the mounted image manually to satisfy the client’s break glass requirement. When an image is mounted, it’s files and folders are exposed. The structure can be manipulated as need.
We simply created our “break glass” folder at the root of the mount folder and copied over the TeamViewer installer.
Clicking “Yes” on the dialog box lets the process continue, which will give us our customized WIM file.
A word of caution on pausing the build process
In order for DISM to properly dismount an image, any connections to the mount path must be closed. This includes viewing the mount path with File Explorer, CMD, or other PowerShell sessions. If connections are not closed, the following error will occur.
Microsoft Deployment Toolkit (MDT)
There has been plenty written on the process of creating Task Sequences to support Autopilot for Existing Devices, so I am not going to go into detail in this post. In a nutshell, to make Autopilot work in this scenario, we need to copy the JSON file (the Autopilot Profile file) into a specific path, and then delete the Unattend.XML file. Since WIM Witch handles the JSON file for us, we only need to include the deletion of the Unattend.XML.
It’s worth noting that how one creates an ISO with MDT isn’t exactly obvious. The ability to do so resides in Advanced Configurations -> Media.
The media created under this option have their own discrete Windows PE configurations, which we used to add custom branding, make CMTrace available in WinPE, and control what prompts the users are presented.
To make the process simple, we added the rules to configure all the available options, except for which Task Sequence to select. We left this requirement so users wouldn’t inadvertently get stuck in a boot-loop if they left the USB key in and misconfigured their device’s boot order.
Once all of that was configured, all the remained was to generate the ISO and test it. After selecting the Update Media option, we had a useable ISO.
To validate the build, we spun up a VM and added the MDT created ISO as a boot option and fired up the machine. Upon boot, the user is greeted with one simple option:
The Task Sequence runs as normal, and it completes very quickly because all of our customizations have been applied directly to the WIM file. What would likely take at least 20 minutes to complete, had we applied each customization individually in the Task Sequence, takes less than 10 to finish.
Once the imaging phase completes, Windows starts OOBE. The first screen shows that our customizations are working.
After following the normal prompts, the user is prompted to enter their corporate credentials
At this stage, Autopilot is in full control of the provisioning process!
All that is left is to burn the ISO to USB and distribute.