My oldest son started high school this fall. As you can probably imagine, there was a bit of anxiety in our household in the days leading up to the start of school. After all, the first year of high school is a big milestone, and he didn’t know what to expect. Well, the good news is that now, several weeks into the school year, my son has realized that all his old familiar friends are still around to keep him at ease, and he’s found a few cool, new things like robotics club to keep things fresh and exciting along the way.
So what does that have to do with deploying Windows? With many organizations looking to roll out Windows 8 in the near future, maybe some of you are having similar feelings of trepidation about what it’s going to take to deploy it. Fortunately, the Operating System Deployment (OSD) feature of System Center 2012 Configuration Manager Service Pack 1 (ConfigMgr SP1) is like your old friend, offering the same familiar deployment experience for Windows 8 as the previous version of ConfigMgr did for Windows 7. And, just like my son’s experience during the first weeks of school, we’ve thrown in some fresh, new bells and whistles to keep things interesting. In this post, I’ll walk through the process of deploying Windows 8 with ConfigMgr SP1, focusing on what’s new. I’ll also point out some potential “gotcha’s” to watch out for if you’re upgrading from ConfigMgr 2012 RTM.
The basic process for deploying a Windows operating system with OSD hasn’t changed. It goes something like this:
Whether you’re new to the product or have been using OSD since it was a feature pack add-on, one of the first things you’ll notice (when installing or upgrading your site) is the requirement to install the Windows Assessment and Deployment Kit (ADK) for Windows 8. This replaces the Windows Automated Installation Kit (AIK) for Windows 7 and provides the latest versions of tools we need to deploy Windows: Windows PE, Windows Deployment Tools, and User State Migration Tool (USMT). ConfigMgr Setup will use these tools to create or update the default boot images (Windows PE images used to initially boot the computer while preparing it to be provisioned with a new operating system) that are used by OSD. If you’re upgrading from ConfigMgr 2012 RTM and you have custom boot images, Setup will not update them for you. You’ll need to remove them and manually recreate your custom boot images, using the winpe.wim file from the ADK as your base image. Then you can re-import your custom boot image. That being said, our goal is to reduce the need for custom boot images by making it easier to apply the most common customizations directly from the ConfigMgr console as a layer on top of the default boot images. In ConfigMgr SP1, we not only have all the same customizations we did previously (drivers, prestart command, Windows PE background, and command shell support), we’ve also added the ability to set the Windows PE scratch space size… and one of my favorite new features, the ability to add Windows PE optional components such as font packages or PowerShell support!
Special note for customers upgrading from ConfigMgr 2012 RTM to ConfigMgr SP1: In addition to the fact that custom boot images don’t get updated automatically by Setup, there are a couple other things to consider when upgrading from ConfigMgr 2012 RTM. First, you should be sure to test your new boot images with all your supported hardware models. Since the new version of Windows PE contains many more drivers in the box, you may find you don’t need to add all the extra drivers you used to need with your old boot images. You should test without any added drivers and add back in only what you need. The other thing to be aware of if you have a hierarchy with a central administration site (CAS) is when you need to do OS deployments while the hierarchy is in “interop” mode. This simply means that your CAS has been upgraded to ConfigMgr SP1, but one or more primary sites are still running ConfigMgr 2012 RTM. In this situation, you need to make some special accommodations to be able to successfully deploy operating systems to the clients that reside in those RTM sites. You’ll need to make a copy of your task sequence for use only in the RTM sites, and that task sequence will need to be associated with an RTM boot image and an RTM client package. Setup won’t create those for you, so you’ll need to create them yourself. Remember that an RTM boot image uses the Windows AIK for Windows 7, so you’ll need to import that custom boot image at an RTM primary site, not at the CAS or an SP1 primary site. I’ll stress again that this is only necessary if you need to use OSD for clients in an RTM site after the CAS has been upgraded to ConfigMgr SP1. If you have upgraded all of your sites to SP1, or if you’re only deploying operating systems to clients in SP1 primary sites, then you don’t need to do this.
Note: If you don’t want to make any customization directly within your reference image, you can just use the Windows 8 install.wim and skip this section. Otherwise, read on.
Once you’ve finished preparing your boot images (and don’t forget to distribute them to your distribution points), you’re ready to build and capture your reference Windows 8 image. As with Windows 7, you can build and customize this image on your own, or you can use ConfigMgr SP1’s Build and Capture task sequence wizard to simplify the process. If you choose to use the wizard, you’ll notice that it prompts for an operating system image package. This is different from ConfigMgr 2012 RTM, which prompts for an operating system installer package. The reason for this change is because Windows only supports certain combinations of Windows PE version and Windows Setup version. To ensure a supported installation method, it is safest to apply an image instead of using an installer package. You can use the install.wim that comes on the Windows 8 media for this purpose. You’ll need to import it as an operating system image before you can use it in the Build and Capture wizard.
One other change that has been made to the wizard is that the ConfigMgr client package will be automatically selected for you, using the default client package that is created by ConfigMgr Setup. If you have a different client package you want to use, you can change this, but the default should be fine for most cases.
Once you’ve completed the wizard, you’ll want to edit the task sequence to add any other customization you want in the reference image. While you’re in the editor, you’ll notice that the default task sequence has been updated to have two different partition disk steps, and the default volume configurations are based on Windows guidelines for partitioning according to the type of firmware the system has.
ConfigMgr SP1 provides support for Unified Extensible Firmware Interface (UEFI) systems. I won’t go into detail about what UEFI is, but it is basically a replacement for the legacy BIOS interface used by older hardware (if you want to know more, read about it on the Unified EFI Forum website or Wikipedia). All hardware that has been certified for Windows 8 will come with UEFI. What’s important to note is that BIOS and UEFI have different disk partitioning requirements. Each of the partition disk steps shown above has a condition based on a new task sequence variable _SMSTSBootUEFI. The task sequence engine will detect at runtime whether the system is running in BIOS mode or UEFI mode and will set this variable accordingly, to ensure only the appropriate step runs.
After you’ve either captured your reference image or imported the install.wim from Windows 8, you’re ready to create the task sequence that will apply your image to a target system and tailor it to the user’s needs. As you step through the create task sequence wizard, you’ll notice a new option to configure the task sequence for use with BitLocker. If selected, the resulting task sequence will contain steps to disable BitLocker on the existing OS, pre-provision BitLocker while in Windows PE if a Trusted Platform Module (TPM) is available, and enable BitLocker protectors after the new OS has been installed and configured.
The new Pre-provision BitLocker step allows you to enable BitLocker while still in Windows PE, telling Windows to only encrypt the used space while the drive is nearly empty, which greatly reduces the amount of time required to encrypt the disk. Note: You may need to do some work to enable your TPM in Windows PE. Otherwise, if the TPM is unavailable, the BitLocker pre-provisioning step will be skipped.
The other new enhancement related to BitLocker in ConfigMgr SP1 is the availability of TPM and PIN as one of the key management options.
You can use the task sequence action variable OSDBitLockerPIN to provide a unique PIN for each computer. For example, you might create a custom HTA to run as a prestart command that prompts the user for a PIN and then assigns it to that variable.
Continuing through the create task sequence wizard, you’ll notice the ConfigMgr client package and USMT package are already selected for you. Both of these packages were created for you by Setup when you installed or upgraded your top-level site server. One nice addition related to USMT in ConfigMgr SP1 is the ability to use hard linking, which saves time by not having to copy data files around.
Upon completion of the wizard, you’ll want to edit the resulting task sequence to add all of your customization, like installing packages/applications. In the editor, you’ll notice two partition disk steps (one for BIOS and one for UEFI), just like in the build and capture task sequence. As mentioned in the previous section, these steps will be run conditionally based on whether the computer is booted in BIOS mode or UEFI mode.
So, your boot images are ready to go, and you’ve got your reference image and your task sequence just the way you want them. Now what? Well, it’s time to deploy your task sequence, of course! This part hasn’t really changed much except for two things. You still want to select your task sequence and “Distribute Content” to make sure all the necessary content is available on your distribution points. And you still walk through the deployment wizard to specify which clients will receive the deployment. However, you’ll notice some new options available on the Deployment Settings page of the wizard.
You can choose whether you want to make the deployment available to ConfigMgr clients only, media and PXE only, or both. The “hidden” option allows you to make a task sequence available in Windows PE that doesn’t show up in the selection list. You can select that deployment by setting the variable SMSTSPreferredAdvertID as part of a prestart command.
The other thing that has changed with regard to deployment is the prestaged media option. Prestaged media allows you to create a WIM file from your task sequence so you can provide that to your OEM to be prestaged on new computers as you buy them. In the past, you could only include the operating system image in the prestaged media file, and all other content had to be downloaded from a distribution point at runtime. Now, you have the ability to specify applications, packages, and driver packages to be included on the media.
And since content and even the task sequence itself can change more frequently than you can update your prestaged media, the task sequence will check the local task sequence cache to see if the latest content is available, and if something has changed, it will pull what it needs from the distribution point.
Well, that turned out to be a bit longer than I had originally hoped, so thanks for sticking with me. While I didn’t cover every change we made in OSD for ConfigMgr SP1, I think I touched on most of them. And most importantly, what I want to emphasize is that deploying Windows 8 is not that different from deploying Windows 7. All of these new things I’ve laid out are not drastic changes to the way you deploy Windows. They are simply some “new friends” to help make your life easier or to take advantage of some new features in Windows 8.
Jim Dempsey Program Manager System Center Configuration Manager
Comments in this blog are open and monitored for each post for a period of two weeks after the posting date. If you have a specific question about a blog post that is older than two weeks, please submit your question via our Twitter handle @MSCloud