Displaying C# Dialogs in the 64bit SCCM Task Sequence

Task Sequence Variables are a powerful tool when deploying new Operating Systems with Task Sequences in System Center 2012 R2. With a Task Sequence Variable, stored on a collection, you can reduce the number of Task Sequences you maintain. Each action or group of actions can be executed based on what the content of a Task Sequence Variable is.

The next logical step to using Task Sequence Variables for existing systems is to use them for unknown computers. For that you need a user dialog box to appear at the start of the Task Sequence to allow the person building the new PC to select what options to include in the build. You might want to be very specific about the drivers you install, for example.

For a Task Sequence with a 32bit boot image Psexec.exe is perfect for launching a dialog in Session 0. Without the option to do this the dialog does not appear. The application will run but it cannot display a GUI without having been launched in the same session at the Task Sequence.

However, 32bit is a bit old in the tooth. Most sensible people are now switching to 64bit operating systems. Psexec.exe however is a purely 32bit application that will not run on a 64bit WinPE image because WinPE does not support Windows on Windows (WOW64.) There are instructions on Technet Blogs about how to write your own application, which you then have to go search out each step of the way.

I did this and found the path a bit harrowing. It's not for the feint hearted but it's doable. I managed to write it first time. To make the application specific to Task Sequences (and not exploitable for other uses) it is written in such a way that it is tied to the task sequence process and will otherwise fail. If you like you can download it from here.

To use it, add it and the dialog executable to a package. In the task sequence use a "Run Command Line" option. Specify the package and for the command-line use tslaunch.exe

This was built for .Net 4.5.1 and works with the Window 8.1 64bit WinPE image (6.3.9600.16384)

If you would like the source code, please contact me on Google+ and I'd be happy to oblige.

System Center 2012 Configuration Manager, 802.1x and Migration

It was interesting going to a Microsoft System Center 2012 launch party and hearing the opinion that wired 802.1x is an old outgoing technology and we should all move to IPSEC. At the same time across town Cisco have 802.1x at the heart of their up and coming ISE product. Anyway, well done to Microsoft for bring the System Center product up to date (to a point!)

My guess is that we will still be hacking away at Microsoft Products in order to enable the smooth running of wired 802.1x. Fortunately, with the ground laid down in my previous posts, there is very little to do different from the latest version of Configuration Manager. if you have not already read those posts, you will need to cover those. This just adds on to the previous offering.

Your prepared boot images will still work with one exception. Microsoft have done something amazingly sensible: They have moved the start up hook from the TSConfig.ini file and into the GUI. To be precise, you no longer have to amend the TSConfig.ini file I referred to in my previous into the boot image before showing it to Configuration Manager. In fact, if you do it will ignore it now. Instead go to the boot image in Configuration Manager and select property. On the Customisation tab tick 'Enable prestart command' and enter your script command here: x:\windows\system32\cscript.exe pretsmboot.vbs.

I have still included the pretsmboot.vbs files in the image because they are needed when you run a task sequence that does not boot from PXE, such as when you run it from the new Software Center. However, you do have the choice of including the files and you also specify this in the same location.



There is a gotcha, of course. If you want to do the same for a CD or USB bootable image, you will need to put those same files into a package. When you create the bootable CD image you will be asked for a package is you want to include file, not just a source directory. But that's not a problem.

Otherwise everything else is the same as before. Of course, we are still talking about Windows 7 here, not Windows 8. That's another hurdle that will be long into the next half of the year before we venture there.

Other Gotchas in System Center 2012 Configuration Manager

• It is entirely possible to import the Operating System Images and driver packages from SCCM 2007. My advice? Don't. Especially the OS images. Don't even think about just copying the same previously captured WIM file. I don't know what the MDT does to images when you capture them, but it creates interesting and varied problems with OSD afterwards. One such problem is the disappearance of the OSD Task Sequence Progress Bar on 64bit builds. Who knows why, it just solves it when you create and capture a new image. Instead create new images captured with the 2012 MDT that is the only version compatible with System Center 2012. This will save you a whole heap of pain.
• I don't know about you, but we are now running totally on 64bit, with any 'I really need 32bit' applications running happily on Application Virtualisation. However, that does not mean you can ditch the 32bit boot image. Oh, no! If you want PXE to work, even if you only server 64bit OS to PCs, you need a 32bit boot image set up to be served by PXE as well as your 64bit version that will be the only image ever used. PXE will not run without a 32bit image. I think it's something like a comforter. PXE has reached that age when no-one really wants it in the room, but seeing it still hasn't written a will, everyone is being nice to it, so really it can do what it likes and no one will scold it. I will be glad when the IPv6 equivalent finally makes an appearance and puts the old man to bed.
• Capture those reboots. The 2012 OSD seems to be a little less robust in handling unexpected reboots. So wherever possible, try to catch those application reboots with a -noreboot flag or similar. The OSD will bomb out if it is hit with an unexpected reboot and it will not recover.

Finally, if you haven't already, introduce some custom task sequence variables. The standard MDT Task Sequence includes such things as "Request State Store" regardless of whether it has actually done a Capture User State or not. You will end up with errors every time you run a task sequence on a new PC. It is a trivial task to clean up this mess by settings a task sequence variable after the Capture User State and referring to that Variable as a condition for the State Store Restore tasks. I don't know about you, but I hate spurious red marks in my logs that I know should not be there. It just makes it look like it's not a clean build when it really is.

SCCM, WinPE and 802.1x - Windows 7 Service Pack 1

In addition to my last post on this issue here, Windows 7 Service Pack 1 has brought with it only a minor change. The details in that post are still valid, with one minor exception.

In "Stage Two Prepare the WinPE Image" I referred to a hot fix package KB972831, which contained the WinPE module for 802.1x. This had to be added using DISM /add-package. Happily the Service Pack 1 AIK toolkit now contains the winpe-dot3svc.cab in the same location as the other three cabs (winpe-scripting.cab, winpe-wmi.cab, winpe-wds-tools.cab.) 

This means that there is very little reconfiguration needed for introducing your SP1 image.

SCCM, WinPE and 802.1x - The Director's Cut

I've been busy. After many months of asking questions I seem to have come up with a definitive 'working in all scenarios' guide to enabling 802.1x in WinPE and working with System Center Configuration Manager. It seems my previous post on this was a little premature but provided a testing a ground for the technology.

So the problems that occurred following my last post were:

• The 802.1x only occurred only at initial boot and subsequent reboots failed to authenticate. This was because the TSBootshell.ini file was only run when initially running the task sequence and not when continuing a task sequence.
• Changing the WIM file after updating the package resulted a package hash mismatch (as the hash is calculated when SCCM updates the package, not when the DPs are refreshed.) This meant that the image could only be used for initial boot and failed when the image was downloaded (either from within Windows or when switching architecture.)

While 802.1x worked, there were obvious flaws. But with a bit more poking at the TechNet forums I managed to over come these. So this post is not all my own knowledge and work, there are other people in the background proving each point.

I explained in my last post why certain files are needed, so please read this as I will shorten this post by not rewriting this information.

So here goes:

Stage 1 Prepare the files for WinPE
You will need to prepare two xml files (see This Technet Post for the XML content) for authentication purposes. I shall call them profile.xml for the LAN Profile and uprofile.xml for the EAP Host User Credentials.
Prepare a file called TSConfig.ini that contains:

[CustomHook]
CommandLine="x:\Windows\system32\cscript.exe x:\windows\System32\8021x.vbs"


Prepare a file called 8021x.vbs that contains:

Set objshell = CreateObject("Wscript.Shell")
Q = chr(34)
objshell.Run "%comspec% /c net start dot3svc", 0, True
objshell.Run "%comspec% /c netsh lan set autoconfig enabled=yes interface=" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%compsec% /c netsh lan add profile filename=%systemdrive%\windows\system32\profile.xml interface=" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%comspec% /c netsh lan set eapuserdata filename = %systemdrive%\windows\system32\uprofile.xml allusers=yes interface=" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%comspec% /c netsh lan reconnect interface =" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%comspec% /c del %SYSTEMDRIVE%\windows\system32\uprofile.xml /Q", 0, True
...

I have added additional script after this point to detect encrypted drives and ask the user to format it. There is a good reason for this. You are about to create a custom WinPE image. If the image is over 100Mb, and you have already used bitlocker on your machines, then the usual size of the boot partition is just 100Mb. If there is a need to download the image to the PC (as happens when you switch architectures or initiate the rebuild from Control Panel) the sequence fails because of insufficient space. But you can add any other scripts in at this point for your own purposes and they will run before the Task Sequence starts.

Stage 2 Prepare the WinPE Image
Mount a vanilla WinPE image using DISM and add the packages in order (or they will fail):

• winpe-scripting.cab
• winpe-wmi.cab
• winpe-wds-tools.cab
• windows6.1-KB972831-x86.MSU (or the x64 for the 64bit WinPE...)

Copy TSConfig.ini to the root of the mounted image. Copy the other 3 files to the Windows\System32 directory in the mounted image.

Commit the image and present this as the source for the boot image in the Configuration Manager Console. Now you can update the Image and it will work in all modes. The tsconfig.ini contains a hook that will be executed before any task sequence begins. Note, that this runs before the policy is checked, but after any task media password.

Stage 3 Prepare the Windows images
Windows also needs to authenticate in the first stages of installation or the build will fail. So all of the following needs to be done in Windows before you capture your reference image for SCCM:

• Set the dot3svc (Wired Autoconfig) Service to Automatic
• Copy the profile.xml, uprofile.xml and 8021x.vbs files (as above) to Windows\System32
• Install the Windows 7 hotfix KB976210

After these are done, you can then capture an image for use with SCCM.

Stage 4 Amend the custom settings
If you followed the MS guidelines when adding the MDT2010 to SCCM, you will have task sequences that refer to a Custom Settings Package. Locate the source files for this package and amend the Unattend.xml

Locate the section "Mircosoft-Windows-Deployment" and note that there are 3 commands under sub section. Add a 4 as follows:

<runsynchronouscommand action="add">
  <description>Configure 802.1x</description>
  <order>4</order>
  <path>cscript.exe c:\windows\system32\8021x.vbs</path>
</runsynchronouscommand>

The way it works:
Booting to PXE downloads the image, before the task sequence runs it looks for a file called TSConfig.xml in the root of the WinPE image. It then executes any commandline entries it finds in the CustomHook section. This runs the scripts necessary to initiate an 802.1x connection with a user name and password in the profile.xml and uprofile.xml files. (We set up an account for connection that can be enabled as and when we decide to rebuild our PCs.)

If the architecture needs changing, the appropriate WinPE image is now downloaded (without HASH issues) and booted from, once again initiating the 802.1x from the scripts in CustomHook.

Once the image is applied and Windows Boots for the first time, the RunSynchronous Command is run before any other commands are run and 802.1x is established. After joining the domain, group policy takes over and the Computer is instructed to authenticate using its computer account.

And that is about it
This effectively adds all the components needed for a successful connection and build that will work without being the ugly hack it was before.

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:

Run=x:\sms\bin\i386\pretsmboot.cmd

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.