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.

Delving into the distmgr.log file didn’t shed too much light on the issue, but there was an interesting error code in there which you should look out for.

Win32 Error = 5

After a little poking around in some event logs on the Distribution Point server (running Win2008 R2 SP1) I noticed the McAfee Antivirus Engine reporting some strange errors. Funnily enough, it was blocking access to one of the files included in the package, Autorun.INF.

Once I disabled the AV protection and removed and re-added the package to the DP, it installed as expected.

This issue had me running in circles for an hour or two. Initially, I had thought it must be WebDAV extension filtering blocking access to the .VBS files within the package, but after tweaking the settings, I ended up looking elsewhere. That is when I spotted the AV event log errors!

Lesson learned: Always disable AV on a DP. Alternatively, try and exclude the DP folder from protection if AV is a must have.

I’m in the process of creating a demo environment for SCCM 2007 R3 in a local VMware Workstation environment. Everything was working fine and dandy until I came to deploy a Windows 7 x86 image to a bare metal VM.

The Task Sequence would initialise and the Partition and Format step would work, but as soon as it went to move on to the next step, I’d receive the error 0×80004005 with a 15 minute countdown to restart.

Eventually, I narrowed down the issue. I basically discovered that the VM was originally a Windows XP VM, therefore no x64 extensions were installed. Seeing as I was booting to a x64 boto image, I figured this could be the cause. Low and behold, changing the properties of the Task Sequence to use the x86 boot image solved the issue! The machine now builds.

So all those hours of throwing in different versions of drivers were wasted, It really was that easy…

What you’ll need:

• Microsoft SyncToy 2.1
• A Windows XP or higher computer

Grab yourself a copy of SyncToy and get it installed. Once you’ve installed, you can launch the application from your All Programs menu. Upon first use, you’ll be asked to create your first folder pair. Before you do, there are a couple of options to consider.

Synchronisation can be performed in a number of ways, each with different effects. Below is a description for each method.

Syncronize

Files in the left and right folders are mirrored. This ensures files remain syncronised even if you edit the file on your remote storate. Deletions will also be mirrored.

Echo

Files in the left folder will update to the right only. Assuming you set your right folder to the remote storage, changes in the remote storage will not be copeid to your left folder. Deletions on the left will delete to the right.

Contribute

Files created and modified on the left will copy to the right. Deletions will not effect the right folder.

Once you’ve picked your chosen sync method, go ahead and specify your left and right folders. In my case, I set the left folder as my local data storage, and the right folder as my remote storage. Click Next and you’ll be asked for your sync method. Select your chosen method and click Finish. Your folder pair is now created.

There are a few other options to consider, such as file exclusions, but I’ll leave that to your discretion.

Now the good part. It’s all very well having folder pairs, but as it stands, we can only sync manually by clicking the Run button. With a little bit of scripting and Group Policy modification, we can set SyncToy to sync all folder pairs on log off. Very handy.

Open your local Group Policy Editor (Start > Run > gpedit.msc) and browse the tree to User Configuration > Windows Settings > Scripts.

Double click on Logoff and you will be presented with the Logoff Properties window. Create the following script somewhere on your local machine.

CD "%ProgramFiles%\SyncToy 2.1\"
SyncToyCmd.exe -R

Now in the Logoff Properties, add the script you just created by clicking the Add button and browsing to the file. The script should now appear in the Logoff Properties window. Click OK to accept this and close the Group Policy Editor.

The script should now execute on logoff. Test it out by creating some local files and logging off. Windows should say Running Logoff Scripts for a little longer that usual. This is a good indication that it is running. Log back on a voilà. Your files should magically have copied up to your remote storage.

Not the most elegant of solutions, but it works, and its free. No complaints from me.

Reviewing the C:\ConfigMgrSetup.log file revealed that the install had indeed stalled and the last couple of entries in my logfile looked like this.

08-04-2010 12:55:21 Enabling monitoring for inbox def Status Manager.
08-04-2010 12:55:21 Enabling monitoring for inbox def Scheduler (LAN Outbox).
08-04-2010 12:55:21 Enabling monitoring for inbox def Scheduler (Requests).
08-04-2010 12:55:21 Enabling monitoring for inbox def Data Loader.
08-04-2010 12:55:21 Enabling monitoring for inbox def Software Inventory Processor (Site).
08-04-2010 12:55:21 Enabling monitoring for inbox def Despooler.
08-04-2010 12:55:21 Enabling monitoring for inbox def Replication Manager (Incoming).
08-04-2010 12:55:21 Enabling monitoring for inbox def Discovery Data Manager.
08-04-2010 12:55:21: Status Modules\Status Modules
08-04-2010 12:55:21: Components Status Module: SMS Server\Components
08-04-2010 12:55:21: Components Status Module: SMS Client\Components
08-04-2010 12:55:21: Components Status Module: SMS Provider\Components

After some research, I discovered that the reason this was occurring was I had a huge collection of .CCR files within the ccr.box folder on my site server. When I say huge collection, I mean over a million files. After deleting them all, which took around 30 minutes, the installation jumped right to the next stage.

It’s worth noting, the .CCR files were actually in a sub-folder of ccr.box, so I’m assuming that SCCM SP2 update searches for all .CCR files in the complete ccr.box folder hierarchy.

After much research, I found out that I didn’t actually need anything else at all! With the help of this nifty bit of software, you can ‘remux’ a MKV video into something the XBOX360 will decode straight out of the box, the trusty MP4 video format.

The software is called XenonMKV. Readers of my blog will probably know I’ve written about this software before. I have much love for it. It’s simple to use, pretty quick, and gets the job done. Seeing as all the software is doing is stripping the video and audio out of it’s MKV container, it’s far, far quicker than conversion.

Sadly, there is a downside, although strictly the fault of Microsoft, not XenonMKV. All video files (besides WMV) are restricted to a 4gb maximum file size. Though XenonMKV caters for this by offering the option to break movies down into 4gb bite site nuggets, it’s still a royal PITA. The other downside is that audio is reverted to 2.1 stereo. Bye bye DTS track. The optimist inside of me wonders if Microsoft will ever unblock these features. The realist inside guesses probably not.

The trouble with Adobe Reader updates is that they aren’t particularly easy to distribute. Sure, you can download the MSI installer from Adobe’s website and use the Adobe Customisation Wizard to create a neat little MST file to transform the install with all your company’s standard settings, but have you ever tried installing the new MSI over a previous version? Not so easy now huh.

For some unknown reason, Adobe engineer their Reader installations in such a way that simply deploying the new MSI isn’t enough. For instance, you can’t simply push out Adobe Reader 9.3.3 and hope that it updates all the previous 9.3.2 installations. You first have to uninstall all previous versions.

Adobe updates usually come in the form of MSP files. These files are designed to patch your existing installation points. It’s important to note that this is only the case for quarterly updates. Security updates cannot be used to patch your administrative installation point.

For this example, I’m going to patch my Adobe Reader 9.3.0 administrative installation point with the MSP for 9.3.3.

Oh but wait, another fly in the ointment. You can’t patch a 9.0 administrative point with 9.3.3 directly. You must follow this order of patching:

9.3.0 > 9.3.2 > 9.3.3

Start by downloading all of your files. You’ll need:

• Your 9.3.0 administrative point
• AdbeRdrUpd932_all_incr.msp
• AdbeRdrUpd933_all_incr.msp

Slipstreaming Updates into the Administrative Installation Point.

Fire up a command line window, and run the following. This command will integrate your MSP with your installation point.

msiexec.exe /a "path to acroread.msi in admin point" /p "path to AdbeRdrUpd932_all_incr.msp" /qb

You’ll notice the installer wizard configuring your computer. Note that this is actually configuring your installation point, not your computer.

Repeat the above with the AdbeRdrUpd933_all_incr.msp file. You will now have an installation point with Adobe Reader 9.3.3 ready to roll.

Deploying the Updated Version.

If like me you have Microsoft System Center Configuration 2007 at your disposal, you can make use of my batch file script that I have created to remove all previous versions of Adobe Reader prior to installing the new 9.3.3 version. Simply set the script to run before the installation for Adobe Reader 9.3.3 and you should find the install takes place with no errors.

For the script to work fully, you’ll need to add the MSIZap executable into the same folder as the script. This can be downloaded for free as part of the Windows Installer Cleanup Utility (found here…). You only need msizap.exe for the script to work, forget about the other files. MsiZap is a very useful tool. Check out the command line syntax I use and experiment to your hearts content.

If you only have Group Policy at your disposal, I’m sure it wouldn’t be too hard to modify the script to call the install after the uninstalls have taken place. Hope this helps!

REM *** MSI Uninstall Adobe Reader 6
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A00000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 7
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A70900000002} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 8.0
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A80000000002} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 8.1
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A81000000002} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 8.1.4
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A81300000003} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.0
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A90000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.1
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A91000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.2
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A92000000001} REBOOT=Supress /qn
REM *** MSI Uninstall Adobe Reader 9.3
msiexec.exe /x {AC76BA86-7AD7-1033-7B44-A93000000001} REBOOT=Supress /qn
REM *** Zap Uninstall Adobe Reader 6
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A00000000001}
REM *** Zap Uninstall Adobe Reader 7
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A70900000002}
REM *** Zap Uninstall Adobe Reader 8.0
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A80000000002}
REM *** Zap Uninstall Adobe Reader 8.1
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A81000000002}
REM *** Zap Uninstall Adobe Reader 8.1.4
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A81300000003}
REM *** Zap Uninstall Adobe Reader 9.0
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A90000000001}
REM *** Zap Uninstall Adobe Reader 9.1
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A91000000001}
REM *** Zap Uninstall Adobe Reader 9.2
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A92000000001}
REM *** Zap Uninstall Adobe Reader 9.3
"%~dp0msizap.exe" TW! {AC76BA86-7AD7-1033-7B44-A93000000001}

SELECT
CS.Name0 AS [Hostname],
CS.UserName0 AS [Last User],
DateDiff(Day, OS.LastBootUpTime0, GetDate()) AS [Uptime (in Days)],
OS.LastBootUpTime0 AS [Last Reboot Date],
WS.LastHWScan AS [Last Hardware Inventory]
FROM
DBO.v_GS_WORKSTATION_STATUS WS LEFT OUTER JOIN DBO.v_GS_Operating_System OS ON WS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_GS_COMPUTER_SYSTEM CS ON CS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_GS_SYSTEM SYS ON SYS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_R_SYSTEM RSYS ON RSYS.ResourceID = CS.ResourceID
WHERE
SYS.SystemRole0 = 'Workstation' AND DateDiff(Day, OS.LastBootUpTime0, GetDate()) > @Days
ORDER BY
CS.Name0

SELECT
CS.Name0 AS [Hostname],
RSYS.Description0 AS [Directory Description],
DateDiff(Hour, OS.LastBootUpTime0, WS.LastHWScan) AS [Uptime (in Hours)],
OS.LastBootUpTime0 AS [Last Reboot Date],
WS.LastHWScan AS [Last Hardware Inventory]
FROM
DBO.v_GS_WORKSTATION_STATUS WS LEFT OUTER JOIN DBO.v_GS_Operating_System OS ON WS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_GS_COMPUTER_SYSTEM CS ON CS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_GS_SYSTEM SYS ON SYS.ResourceID = OS.ResourceID
LEFT OUTER JOIN DBO.v_R_SYSTEM RSYS ON RSYS.ResourceID = CS.ResourceID
WHERE
SYS.SystemRole0 = 'Server' AND DateDiff(Hour, OS.LastBootUpTime0, GetDate()) < 168
ORDER BY
CS.Name0