While I have always been, and will always be, a strong advocate for the Microsoft Deployment Toolkit, I found myself in a bit of a quandary one day. My MDT workstation had just died and I was, fortuitously, also rebuilding my SCCM infrastructure. I decided to see about combining the two and see if I can make SCCM's built-in operating system deployment solution work for me.
To be clear, I'm still using MDT, but have it integrated with SCCM (but not using the User-Driven Installation, UDI, mode) so that I can get the task sequences and scripts. I'm not really using CustomSettings.ini for anything (it is just the stock, empty file in my case). To front-end things, I'm using CoreTech's OSD HTA, but slightly modified so that it a) runs on 64-bit Windows PE and b) handles some disk management tasks before and after CoreTech's HTA wizard. So, let me describe some of the things that I've done and you can see if those will be useful for you.
CoreTech OSD HTA
The CoreTech OSD HTA is, itself, OS bit-width insensitive; it works equally well over 32-bit or 64-bit Windows PE. The problem that it has is that it is packaged using AutoIT into a self-extracting executable that is 32-bit only. That is what causes it to not run well on 64-bit systems. I'm not certain, but I assume that this was done so that usernames and passwords necessary to connect back to the SCCM server share are encrypted. That said, this was the first challenge to unlock. To get past it, you can simply run the HTA on the local SCCM server (or wherever the share is) and AutoIT will extract the HTA and all components into a temporary directory (in my case, it created a GUID named folder in my user's TEMP folder). You can grab them from there and copy them to a more permanent location. It is this location that I include in my Windows PE build (under Customization, Enable prestart command, Include files for the prestart command).
As for the Windows PE prestart command itself, I created a VBScript file (in my case, I also encrypt it into a VBE file since it has usernames and passwords) that wraps around the CoreTech HTA wizard. This script handles making sure that the internal disk drive is visible and writable (to solve a problem with SCCM and USB boot disks becoming unusable after each deployment), dealing with BitLocker being enabled on the internal disk, connecting to the CoreTech share for configuration, running the wizard itself, and then forcing an additional wait time for SCCM to process advertisements for the computer object created by the wizard. See here for a commented copy of the launch script. When customizing the Windows PE image, I elect to have this script started automatically as a prestart command (cscript //nologo Run.vbe).
SCCM OSD Challenges
While I did use the MDT stock task sequence for client deployment (which gets you most of the way there to getting things configured), I ran into a few problems along the way that I had to resolve in order to get things to work the way that I needed them to. All of these "fixes" happen after the main Windows installation is done (during the State Restore phase), since most of the issues are Windows itself being unhelpful at times.
First up, I ended up needing to change power settings to prevent the monitor and computer from going to sleep or hibernating on my during the deployment (or, more likely) in the time after the deployment has finished. I accomplished this by having four Run Command Line tasks in a row that just execute the powercfg.exe utility to make changes. Here are the commands that I ran:
- powercfg.exe /change monitor-timeout-ac 0
- powercfg.exe /change disk-timeout-ac 0
- powercfg.exe /change standby-timeout-ac 0
- powercfg.exe /change hibernate-timeout-ac 0
Note that these settings will persist even after the operating system is fully deployed. You'll need to apply a power policy via SCCM or make manual adjustments if the computer won't be managed by SCCM later on.
Next, for BitLocker, I had to make sure that a particular GPO setting was configured on the computer in order for me to enable BitLocker on Surface Pro tablets. To do this, I added a Run Command Line task that ran the following command:
reg add HKLM\SOFTWARE\Policies\Microsoft\FVE /v OSEnablePrebootInputProtectorsOnSlates /t REG_DWORD /d 0x1 /f
Immediately after the task that enables BitLocker on the computer (and I ended up using several different variations depending on the Role and Type selected by the CoreTech OSD HTA wizard), I suspend the protectors so that, as the task sequence reboots, it doesn't get stuck at a PIN entry screen. I accomplish this by another Run Command Line task that runs the following command:
manage-bde.exe -protectors -disable c: -rc 0
At the end of the sequence, just before the "Report done" task, I add in another Run Command Line that enables the protectors:
manage-bde.exe -protectors -enable c:
NOTE: For both of the suspend and enable commands, I have a condition that does a WMI query in the root\cimv2\Security\MicrosoftVolumeEncryption namespace, looking for select * from Win32_EncryptableVolume where ConversionStatus > 0. This will ensure that the command only applies if there is an encrypted volume in the system. Additionally, on the enable command, I also look for the DoCapture sequence variable to not be equal to YES.
Apps Installed Per-User
Although this isn't the real way to fix this, occasionally I find an application that created its Start Menu entries in the SYSTEM user account profile (since all SCCM OSD installs run as SYSTEM). To work around that problem, I have three Run Command Line tasks that move those links over to the ProgramData Start Menu folders and then reset permissions on them so that they are visible and accessible to everyone. NOTE: I know that this does not correct any per-user registry keys that may have been stored for the app in the SYSTEM user hive; the proper way to fix this is to ensure that the app supports an AllUsers-type deployment or to repackage it to officially handle those per-user keys and dump them into the Default user profile for use as user accounts are created. That said, here's the commands that I run:
- powershell -command "move-item \"$env:Windir\syswow64\config\systemprofile\appdata\roaming\microsoft\windows\start menu\programs\*\" -destination \"$env:ProgramData\Microsoft\Windows\Start Menu\Programs\" -force"
- powershell -command "move-item \"$env:Windir\system32\config\systemprofile\appdata\roaming\microsoft\windows\start menu\programs\*\" -destination \"$env:ProgramData\Microsoft\Windows\Start Menu\Programs\" -force"
- icacls "%ProgramData%\Microsoft\Windows\Start Menu" /reset /t
Uninstall SCCM Client
There are some scenarios where I don't want to have the SCCM client still installed (such as when I want to just put a vanilla Windows operating system onto a computer for use with some random project or to hand to a non-employee for use). For that, I have created a pair of scripts (see here) that handle that process. I just add a Run Command Line task that runs the ConfigureForCleanup.cmd script, referencing a package containing the two script files. That step is at the end and will uninstall the SCCM client the next time the computer is rebooted.
Other odds and ends are in the task sequence but they are the typical customizations anyone will make (selecting particular device drivers, installing various apps, etc.). In general, I like using the same task sequence to handle all of the permutations of Role and Type that I can (because any common changes only have to be made once), but the CoreTech HTA OSD solution is flexible enough that you can actually run different sequences for each Role or Type.
Advertising the Sequence
In my particular case, I advertise the sequence twice to each particular CoreTech HTA OSD collection. The first is a required deployment available only via media and PXE. This will ensure that, if you have the USB boot media running in unattended mode, that it just runs the sequence after the wizard finishes. It also ensures that PXE boot runs without prompting for F12 or Enter. The second deployment is an "available" deployment, also only for media and PXE. This is to handle the case where PXE needs to boot twice because we formatted the disk and reset the TPM chip. SCCM places a flag on a particular computer record when it was recently PXE booted due to a required deployment (specifically to prevent it from endlessly cycling into PXE when PXE boot is ordered above booting to the internal disk in BIOS boot orders). So, in this case, when I have to reset the TPM chip, I then have to pay attention and press F12 or Enter to boot into PXE to then run the OSD wizard and proceed with deployment.