The Network Manager at Westminster School presents solutions to sticky problems...

Friday, 19 February 2010

SCCM, WinPE and 802.1x

Running deployment tasks from SCCM on a network with 802.1x security is now possible, thanks to an update from Microsoft. It is a shame that we seem to have been left with an Ikea table set with all the parts but no instructions. So here is a first run "How to enable 802.1x on your SCCM" implentation. This example uses MS-PEAP without certificates.

First off, I will not explain how to set up a 802.1x on your network. Sufficient enouogh it is to say that you need to have an authentication rule that identifies a group with a single domain user specifically for network connectivity alone. This is so that when your winPE 802.1x client passes the username and password, it is authorised and passed a vlan for the installation to run on. I would strongly suggest that this account has no other privilege. For comparison, our test bed is running on Cisco 3560 switches, with a Windows Server 2008 Network Policy Server standing in for RADIUS. We are running SCCM 2007 SP2. We use MDT 2010 which includes winPE 3.0.

The first thing to do is add the KB972831 Hotfix to winPE. I choose to forgive Microsoft for writing in their documentation for this fix (and I quote) "Install and run" and "There are no prerequisites" both of which are most unhelpful. There are two ways to add the hotfix. Before importing the boot image, and SCCM builds the image. You are going to have to amend the boot image after it is built and before it is distributed to the distribution points anyway, so I have taken the second option.

If you want to add the hotfix to a clean winPE image, then before adding the hotfix, add the winPE components for Scripting, WDS Tools and WMI. SCCM does this anyway when it prepares an image. My best guess is that one of these is an unwritten prerequisite to the hotfix.

After updating the boot image with the required drivers, you can find the BOOT.XXX99999.WIM file under \Program Files\Microsoft Configuration Manager\OSD\boot\i386. Copy this to your MDT (Microsoft Deployment Toolkit) prepared workstation. Make sure you have an empty mount directory first. Run your department tools command prompt and then run:

C:\>imagex /mountrw boot.xxx99999.wim 1 c:\mount
C:\>dism /image:c:\mount /add-package /packagepath:c:\temp\Windows6.1-KB972831-x86.MSU
C:\>dism /image:c:\mount .get-packages

(Needless to say that you need to match architectures - No egg sucking lessons here...) Get-Packages confirms that the package is indeed added.

Before committing the image, we need to make a few more changes. The DOT3SVC (Wired Autoconfiguration) does not start automatically, so we need to find a way to kick it off before the task sequence runs. This is an ugly hack, so I hope you do not mind. I am sure the next release of SCCM will have this sorted natively...

We are going to create 3 files and amend another one already in the image. The first is profile.xml - a LANProfile for the Local Area Connection interface. This contains the settings for the interface. (Thanks to Andrew Husking for this version.) You can create your own be going to any Windows 7 interface and exporting the configuration using netsh if you wish. This one works fine.

The second file is uprofile.xml. This file contains the user credentials (EapHostUserCredentials) needed to log into the network. Remember that I said you want an account that has no other purpose, this is because this account will be included in this plain text file and sent to the pxe client. (Once again thanks to Andrew Husking.) Just change the usename and password.

You can find the xml for these two files on this technet board here... (Note that I left the RoutingIdentity as 'test' and it did no harm.

Place these two files in c:\mount\windows\system32

The third file is a batch file pretsmboot.cmd. This contains the following:

@echo off
net start dot3svc
netsh lan set autoconfig enable=yes interface="Local Area Connection"
netsh lan add profile filename=%SYSTEMDRIVE%\windows\system32\profile.xml interface="Local Area Connection"
netsh lan set eapuserdata filename=%SYSTEMDRIVE%\windows\system32\uprofile.xml interface="Local Area Connection"
netsh lan reconnect interface="Local Area Connection"
del %SYSTEMDRIVE%\windows\system32\uprofile.xml /Q
x:\sms\bin\i386\TsmBootstrap.exe /env:WinPE /configpath:%CONFIGPATH%

Copy this file to c:\mount\sms\bin\i386

Finally, copy the file TsBootShell.ini out from c:\mount\sms\bin\i386 to Documents. Edit it so that the last line reads:


You will notice that the last thing pretsmboot.cmd does is kick off the line that you have just replaced. Copy the tsBootShell.ini back to c:\mount\sms\bin\i386

Now you can commit the changes back to the wim using:

C:\>imagex /unmount /commit c:\mount

(It is possible to do the image mounting and dismounting with DISM but I find imagex more mature and cleaner.) Copy the boot.xxx99999.wim file back to its original location on your SCCM server. Go into the Configuration Manager Console and go back to Boot Images. Right click your boot image and select Manage Distribution Points to start the wizard off. Choose Refresh the package on selected distribution points. If you select Update anywhere in this process, you will overwrite the image you have just made changes to.

There are consequences to this. The biggest and most obvious is that you cannot allow your boot image to automatically rebuild and update (obviously) because you need to inject the scripts and profile before refreshing the distribution points. The update of files can easily be scripted into a batch file but needs to be manually monitored as the MSU update can fail???

Another consequence is that you lose to ability to build on insecure ports. This new image you have created is 802.1x only. You will need to create another boot image without the amendments.

The final consequence I want to mention is the ugly dos screen this hack brings up. Yes, I could probably write a vbs that does the same thing without the dos window. I might just do that, but I am running out of half term...

So there you are - one working 802.1x winPE implementation using SCCM.


  1. this is wrong. people, don't follow this article.

  2. Thanks anonymous! Apart from the fact that MS have not published any documentation on this thus far, oh, and that this is working on our network, would you care to elaborate?

  3. How did you get around the package hash mismatch?

  4. Ah yes. Watch this space... an update coming soon!