SCCM Operating System Deployment Task Sequences

In  the past few months my business has been working on the move away from XP/Altiris to a Windows7/SCCM 2007R3 environment. I was working closely with an outside contractor to get the infrastructure in place and getting SCCM up and running, but before this was even completed I was tasked to begin considering how to perform operating system deployment (OSD). Looking at SCCM from a newbie perspective I will talk about the challenges I faced in getting my OSD to work successfully.

After some investigation I soon found out that SCCM offers multiple ways to deploy an operating system to new machines and also machines already on your network. So far I have tested and implemented the following:

• PXE boot environment with unknown computer support - I have put a password on this at the moment so that users can't unknowingly image a newly added machine. This is useful where you might be in a scenario where you unbox and build multiple machines at one time, you really don't want to be messing around writing down MAC addresses to import for hundreds of PCS at a time.

• Bootable WinPE CD/USB stick, this method means you don't have to enable a PXE server on the network and is useful in environments like mine that already have multiple PXE servers. Unfortunately this means you will have to manually import the machine MAC address and put it into the OSD collection before it can be installed.  The disadvantage here is that you end up with a duplicate system in SCCM once it is renamed, but providing you have scavenging set up it should disappear reasonably quickly.

• If the PC you image is an existing PC with a previous OS (WinXP) you can simply for an install of the SCCM Client and then put the machine into the OSD collection. This can be very handy, but again it will create a duplicate machine in SCCM, which will be marked as "obsolete". This appears to be by design to avoid endless build cycles.

• Stand-alone task sequence media on CD/USB stick for the entire task sequence onto a DVD - this method works well for remote/small offices that don't have any server infrastructure, but SCCM task sequences can be rather large, in my case I need 3 DVDs worth to fit my standard image. It looks like high capacity USB flash drives are more feasible in this scenario.

Task sequence media is easily created, simply go to "Operating System Deployment" > "Task Sequences" > select your OSD task sequence and click "Create Task Sequence Media"

You can then select the type of media to create or create an ISO of the image for later use. Coming from an Altiris background I have to say I was very impressed easy this was and how well this solution worked.

I've got ahead of myself a little bit here, the largest part of this was the creation of the task sequence to begin with. I was fortunate that I had a base Windows 7 install.wim. Unfortunately it had only been tested on a handful of different models of PCS. After an evaluation of my asset management database I found that I actually had 11 distinct types of desktops that would support Windows7 in my environment. At this point I got a bit of headache, thinking back to Altiris and the multiple images for Windows XP. I wanted to get away from this and have "one image to rule them all".

One Image to Rule them All

The first thing I did was to test my Boot.wim with each device to ensure two things:

1. Each device could successfully boot to WinPE image.
2. By pressing F8 during PE boot and using the command prompt I could verify that WinPE could see the Hard Disk Drive and Network Card.

Fortunately all devices booted to WinPE without issue, but some were missing the network card driver or storage controller. These would have to be injected to the Boot.wim before we could continue. This can either be done by mounting the image using DISM in Microsoft MDT2010, or in SCCM you can go to "Boot Images" > right click on your boot.wim and go to properties, then press the "Windows PE" tab, press the "Sun" icon and then select the drivers you want to be injected. In order for the drivers to appear on this list you will have to firstly import them.

Now I had a working preinstall environment I could then begin testing deploying my main image. The next thing I done was to visit the manufacturer websites and download all existing drivers for the products I wanted to move to Windows 7. I downloaded the drivers for eleven models in total and stored them neatly on my SCCM server, sorting by model and device type. I then had another decision to make.

Order Vs Chaos

After some research it would appear there are two ways to approach driver management. One being "Chaos" whereby you simply import every driver possible and then allow every machine being built to scan then entire available driver database.  The "Order" solution is a very controlled environment whereby you import drivers for each model into a package and apply only that specific package to its relevant model. Being lazy I liked the sound of Chaos, but In practice I found this method to be much slower at building machines; the more drivers there are available the longer Windows takes to sort through and determine which driver is the most suitable.

Fortunately, SCCM makes importing drivers very easy. Simply create a new folder in the drivers section, right click, select import and browse to the location you stored the drivers for that specific model.

I was surprised to find that even when you select x64 drivers only that the packages also seem to contain XP, Vista, x86 drivers too. If you are going to import the packages for an x64 image like mine make sure to remove these drivers.

Either click new package to create a specific package or select an existing package, ensure to tick "Update distribution points when finished" to ensure your drivers get sent to PXE for immediate use.

Trying to adopt the "Order" method was causing me to run into issues. SCCM doesn't like it when you try to import a duplicate driver. It turns out that it's quite common for several HP laptops and desktops to share the exact same hardware, this was causing an error when trying to import this driver even although I just wanted to put that driver into my specific machine package. To get around this I installed patch KB2213600 which will allow SCCM to import duplicates.

With this method I was left with eleven different driver packages which I could apply. The next question would undoubtedly be how does SCCM know to apply that specific driver package? 

Using  a WMI query to select the model name from the system bios as a condition for installation allows only this package to be installed.

It's not only drivers that benefit from this functionality, what about the differences in software between laptops and desktops? You won't want to install certain software such as a VPN client or a mobile connectivity suite on your desktops!  Luckily there are a couple of easy ways around this.

Below shows and example using the "IsLaptop" variable - note that this is only availble when you have MDT integration. Before checking for this variable you will need to perform a "Use Toolkit Package" and  a "Gather" from the MDT menu. 

This also seems to work bothways. IE you can use "isDesktop"

You can also check for the presence of a battery.

Hardware Based Applications

When I had created all my packages and performed some test builds I noticed that there were some systems that just wouldn't install the drivers without its accompanying piece of software. ATI and Nvidia graphics packages seem to be the worst culprits, as both rely on their "Catalyst control centre" and "Nvidia Control Panel" to offer any advanced functionality. Bluetooth drivers were also the same as each device requires its own custom Bluetooth stack. I read elsewhere that these types of programs were called "Hardware based applications" being that they blur the lines between drivers and software. I found the simplest way to deal with these is to treat them like any other piece of software. Referring to the suppliers documentation *cough* and after fiddling about I found all the required silent install switches.

So far I'm about 90% there towards finalising the build. There are always little tweaks to go back and add. The other big part of this will be a brand Active Directory/Group policy re-structure which will go a long way to configuring this build. I don't want to add too many registry fixes into the build, but inevitably these will keep coming. At this point my OSD task sequence looks like this.

Please note that grey items are currently disabled experimental steps I was toying with. In the end I don't think I really need these. Using the above I can perform a zero touch installation on a new out-of-box PC or reimage an existing machine by simply dropping the PC into the OSD collection.

Like I said, I'm still an SCCM newbie and I would appreciate any advice on improving this.

Andrew