Thankfully (or not, depending on how you like looking at log files) ConfigMgr 2007 logs everything. Unfortunately, when in WinPE mode for OSD, reading those log files can be a real pain in the behind. Trace32 (and the relatively recent Trace64 for our 64 bit counterparts) were never included in WinPE boot media, which is a tad odd considering the requirement for it.

Fear not, as it is totally possible to integrate Trace into your own boot image. I tend to do this whenever I’m working on a customer OSD engagement as it makes my life, and more importantly, the customers life much easier. No more trawling through Notepad .log files people – upgrade your boot images now!

The first thing you should do is ensure you have MDT 2010 Update 1 integrated into your ConfigMgr environment. Follow this guide if you haven’t already done this. It’s painless procedure and only adds enhancements to the platform which you choose to include if you wish.

Before you start, I’ll be explaining below how to create a new enhanced boot image for both x86 and x64 platforms. I choose to do this as opposed to integrate Trace into the standard boot images just in case something goes wrong – I would hate to interfere with a boot image that was currently being used to deploy an OS. This method allows you to test the new image and swap out the old one as and when you need to.

First off, grab the Trace32 and Trace64 applications from here.

Next up, you need to stage them on a network share, which is the area we will specify when compiling a new boot image. It’s a good idea to place them into a .\Windows\System32 folder, as this is where we want the apps to end up on the boot image so we can execute them from the command line just by typing the name (without the path).

In my example, I have created the following folders and placed the Trace apps into the relevant architecture folder. Notice I’ve also renamed each app to just Trace, so that I do not need to remember whether to run Trace32 or Trace64 depending on what boot image I’ve booted into. Of course, this is just personal preference, but it’s two less characters to type.

• \\server\OSD\Boot\BootImageCustomisations\Files\x86\Windows\System32\Trace.exe (Renamed from Trace32.exe)
• \\server\OSD\Boot\BootImageCustomisations\Files\x64\Windows\System32\Trace.exe (Renamed from Trace64.exe)

Now we have our content staged, lets go ahead and create two new boot images; one x86 and one x64. Expand Operating System Deployment in the ConfigMgr Console and right click Boot Images. Click Create Boot Image Using Microsoft Deployment.

On the Package Source screen, enter the UNC path to the folder in which you want to create the boot image. This is only really a staging area, as clients will grab the source from the Distribution Point when running a deployment. As you can see, I created a source folder for x86 and x64 respectively. Click Next.

You can fill in General Settings as you please, though it pays to add a little detail. Click Next.

On the Image Settings screen, select your acrhitecture. I’m generating a new image for both x86 and x64, but right now, this example is building a x64 boot image. In the Extra Directory to add text box, enter the UNC path to the root of the folder we created earlier containing the Windows folder. Click Next.

On the Summary screen, verify all your settings are as you wish and click Next. The wizard will now generate a new boot image using the settings you defined.

If all goes to plan, you should end up with a successful confirmation screen. Click Finish. Your boot image is now created.

Remember, before you add it to a Task Sequence to boot from, ensure you add it to relevant Distribution Points and enable F8 command prompt support, just like you would any other boot image.

Lather, rinse, repeat for x86, and you have yourselves an enhanced boot image with a proper log viewer for all your ConfigMgr debugging needs! Go ahead, boot your Task Sequence, run up your command prompt and type trace. Magic.

The process to integrate MDT is extremely straight forward and takes two minutes – but the advantages it brings to Operating System Deployment are huge! Some of my favourites are:

• The ability to use a whole bunch of new variables in a Task Sequence. For instance, I can target laptop systems simply by using the IsLaptop variable. Equally, I can also use IsDesktop or IsServer. No more WMI querying for Chasis Type or battery presence. Hoorah.
• Better control over server roles for Server 2008 and 2008 R2. A neat feature if you deploy server operating systems through ConfigMgr.

So what are you waiting for, let’s get to it.

Download MDT 2010 Update 1 for your architecture from here.

Run the installation and work your way through the wizard, which is a simple next, next, next installation in most cases. Once installed, click Start > All Programs >Microsoft Deployment Toolkit > Configure ConfigMgr Integration.

In the Options screen, ensure you enter your Site server name and the Site Code for that site. Notice you can also remove integration from this point at a later stage if you so wish. Click Next.

At the Confirmation screen, you should receive a successful message. Click Finish.

I’m not usually one for ‘I told you so’ but, I told you so! It really is that simple. If you wish, you can jump into the ConfigMgr console and verify the integration by right clicking on the Boot Images node and verifying the new option as shown below.

There are two ways to achieve this in a Windows environment. Firstly, you can configure a Group Policy to do just that. Secondly, you can rename the account as part of your Operating System Deployment. The latter is what I’m interested in.

You can achieve this by adding a new step into your OSD Task Sequence. I place this at the very end of my Task Sequence to ensure it gets applied after any administrator related tasks. The computer is then set to reboot afterewards to ensure it is applied successfully.

Add a Run Command Line step into your Task Sequence and add the following code to the Command Line text box.

wmic UserAccount where Name="Administrator" call Rename Name="NewName"

Change “NewName” to whatever you want the administrator account to be renamed to and save the Task Sequence. Your local administrator account will now be renamed accordingly as part of your Operating System Deployment. I haven’t tried myself, but I’d imagine you could run this step as part of your build and capture Task Sequence. In theory, this should eliminate the need to add the step to each of your OSD Task Sequences.

I think I have this one nailed. It seems that if your system had Windows Server 2003 Service Pack 2 installed before you joined a domain, you will hit this error.

I noticed this in my lab environment, where I commonly build a virtual server template with 2003 R2 SP2. All new servers are cloned from there. Once the clone is created, I join them to a domain if required, so SP2 exists prior to domain joining.

The answer? Remove SP2, reboot, reinstall.