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.

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.

This has been puzzling me for some time, and during my research, I noticed that despite the ConfigMgr Software Update app indicating these updates are required, they are actually already installed on the machines.

The software updates causing this headache are:

• Microsoft .NET Framework 2.0 Service Pack 2 Update for Windows Server 2003 and Windows XP x86 (KB976569)
• Microsoft .NET Framework 3.5 SP1 and .NET Framework 2.0 SP2 Security Update for Windows 2000, Windows Server 2003 and Windows XP x86 (KB979909)

It seems that despite actually being already installed, Windows Update still tries to install the update, thus causing a failure as shown in the screenshot above. It’s also worth noting that other updates I approved after these two, successully install, so this isn’t an issue with the Windows Update agent. The SCCM log files also indicated that the updates install without error.

After much head scratching, I found I could resolve this issue by doing the following.

1. Bring up a command prompt and run the following to stop the Windows Update agent.

   NET STOP wuauserv

2. Delete the following folder, including its contents.

   C:\Windows\SoftwareDistribution

3. Reboot the computer.

Now the next time the Windows Update agent runs, it will see that the updates are already installed and present you with the status of ‘Installed’ instead of failed.

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.

Things you’ll need:

• The Adobe Reader 9.4.0 distributable package.
• Some disk space.
• The Adobe Reader Customisation Wizard 9.
• SCCM environment. (Although you can use this method for Group Policy Software Installation too).

Go ahead and grab your Adobe Reader 9.4.0 installation EXE. The first thing we’ll need to do with this is extract the MSI installation from within it. This is a pretty straight forward task that can be achieved with the following command:

<path to>\AdbeRdr940_en_US.exe -nos_o"Reader940" -nos_ne

The -nos_o switch is the folder name to extract the files to. This will form your AIP (Administration Installation Point) and is what we will customise using the Adobe Customisation Wizard. The Adobe Reader 9.4.0 – Setup screen will extract the MSI into your specified folder (as shown below). The screen will disappear once extraction is complete.

Once extracted, you will have your new AIP. It should look similar to my one below.

Now it’s time to customise your AIP. This is done using the Adobe Custmoisation Wizard. Install the application from the link provided above and you’ll find a new icon in Start > All Programs. Run it and select File > Open Package. Browse to the AIP you just created and select AcroRead.msi. You’ll then be presented with various categories down the left and options on the right. This is where the magic happens.

At this point you can go through the categories on the left and customise at your leisure. To get you started, here are a few common items you may wish to customise.

• Run Installation: Silently
• Suppress Reboot
• Suppress display of End User License Agreement (EULA)
• Hide Document Message bar
• Disable all updates
• Disable Help > Digital Editions
• Disable Product Improvement Program
• Disable all Acrobat.Com access, including initiation and participation

Once you have finished your customisations, select Transform > Generate Transform.

Save your transform to the AIP. You can now close the Adobe Customisation Wizard. Be sure to click No when prompted to save the package. We don’t want anything written to the original MSI. That completely goes against the idea of transform files.

Congratulations, you now have a customised Adobe Reader 9.4.0 installation which is ready for deployment.

Depending on your chosen deployment method, you can now create your SCCM package or Group Policy object using the files within your AIP. If you are using GPO deployment, you can use the AcroRead.msi file. Be sure to add the transform file in the Modifications tab so that the MSI file takes in your customisations.

If like me you have the benefit of SCCM in your environment, you’ll want to configure your package with a Program command line such as this:

msiexec.exe /i "AcroRead.msi" TRANSFORMS="<path to transform>" RebootYesNo="No" Reboot="ReallySuppress" /qb

One thing to remember, with 9.4.0 being a major release, the installation will remove previous versions of Reader by default, so you don’t have to worry about running my removal script as previously blogged. Bonus. You’re now ready to deploy. Good luck!

It seems there is a bug when creating a transform when setting the Allow PDF files to open in Browser option. If you set this option to enabled, once the software is deployed and you try to open a PDF within a web browser window, the following error is displayed:

The Adobe Acrobat/Reader that is running can not be used to view PDF files in a web browser. Adobe Acrobat/Reader version 8 or 9 is required."

I’m still unsure as to the exact cause of this issue, but trawling the web seems to indicate that this is indeed a result of a bug within the Customisation Tool. My workaround was to set the option to Disable and regenerate the transform. This allows you to open a PDF from a web browser but forces the PDF to open within an Adobe Reader window, as opposed to inline within your web browser.

Thanks Adobe.

After running a few successful deployments, I started to notice PXE boots were failing. The PXE server seemed to be ignoring client boot requests as if they were ‘Known’ to SCCM. This was the case even after deleting the resource from the SCCM database. This behaviour was validated by looking into the SMSPXE.LOG file on the PXE server. I noticed the following lines were present.

No Boot Action for Device (17898) found
ProcessDatabaseReply: No Advertisement found in Db for device

I began to investigate the PXE server configuration and noticed that after deleting the resource from the SCCM database and restarting the Windows Deployment Services service, the computer was correctly identified by PXE boot as an Unknown Computer and successfully booted into the Task Sequencer.

It seems to be the PXE server cache is causing the resource ID to remain in memory so it is no longer discovered as an Unknown Computer. Luckily, I discoverd a fix that seems to work for me. The PXE server cache timeout is determined by the following registry key. In my case, it was set to 0, which I assume is infinite. I ammeded this value to 300 (decimal) and restarted the Windows Deployment Services service on the PXE server and all seems to work as expected. I can image a bare metal computer, delete it from the SCCM database and after approximately two minutes, I can PXE boot it as an Unknown Computer again to reimage it.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\PXE\CacheExpire

Be warned though, I believe this is set for a reason. I’d imagine that if you are using a mandatory advertisement to the Unknown Computers collection, the machine will re-PXE boot each time the OS deployment tries to reboot as part of the OSD Task Sequence. Though this hasn’t been tested and isn’t a problem for me as I am using optional advertisements.

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.

This is all well and good, unless you are intending on installing the EXE version of Flash, and not the MSI.

Usually, I’d go MSI over EXE any day of the week, but Flash Player is a fickle b*tch of an install. For some reason, I was seeing plenty of MSI installations fail while using SCCM 2007. Most of the failures related to certain files not being marked for installation. The following event log entry could be observed on the machines.

Product: Adobe Flash Player 10 ActiveX — Error 1722.There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action NewCustomAction1, location: C:\DOCUME~1\<username>\LOCALS~1\Temp\InstallAX.exe, command: -install activex -msi

For this reason, I bailed out and went with the EXE installation, which so far, when used with the new silent install switch (-install) works flawlessly.

Now, obviously we can’t transform an EXE, so I’ve had to come up with the following CMD script which can be applied to computer startup through the use of a Group Policy Object.

ECHO AutoUpdateDisable=1 > %WinDir%\System32\Macromed\Flash\mms.cfg
ECHO DisableProductDownload=1 >> %WinDir%\System32\Macromed\Flash\mms.cfg

The nice thing about this script is that it will only run if the Macromed folder exists.

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}