I was doing an OSD project about 5 years ago when I came up with the idea of automatically opening the smsts.log file using Trace32 (now replaced by CMTrace).  I am always up for a challenge to see if something can be done, so I set out to see if I could make it happen.  By automatically opening the smsts.log, I could save a ton of time during the development and testing phase of engineering the task sequence.

Back in the ConfigMgr 2007 days, you would have to hit F8 in order to bring up the command prompt and then hopefully you remembered to put the Trace32 on the boot image for the WinPE phases.  Now in CM12, CMTrace is included in the boot image, however, it is not in the path (see my other post called ConfigMgr 2012: Always including certain files in your Boot Images for a little trick to put CMTrace in the System32 directory so that it is in the path and can be launched from any directory).  After you launch the log viewer for the first time, the first thing it does is ask you if you want to make it the default log viewer before it will continue.  Setting a couple of registry keys ahead of time is all that it takes to prevent this from being displayed.

After that, it is a matter of launching the log viewer and calling smsts.log.  There are two things to consider for this action: 1. Depending on the scenario (i.e. new computer or refresh), you need to know how to launch CMTrace and 2. Depending on the scenario and place in the task sequence, you need to know where the smsts.log is located.  For #1, you can launch CMTrace directly if you are in WinPE or the newly installed OS during State Restore.  If starting from a currently installed OS (i.e. refresh scenario), then you need to use a utility from the MDT Toolkit called ServiceUI.exe in order to make CMTrace visible.  For #2, the smsts.log file starts in different locations based on the scenario and it also moves around during the task sequence.

With that said, let’s take a look at the steps that need to get inserted into a ConfigMgr R2-MDT client task sequence:

Each *DEBUG* Group has a condition on the Task Sequence Variable DEBUG (DEBUG equals “TRUE”).  This variable can be set on a Collection or System Resource.

Set OS Target Architecture: this step is used to set the architecture of the OS that is being applied.  For an example, use the value x64 if the new OS being installed is Windows 8.1 Enterprise x64.  This is used later in order to copy the correct architecture version of CMTrace and ServiceUI onto the target OS.

Use Toolkit Package and Gather: This step is used to obtain CMTrace (which needs to be copied into the MDT Toolkit Package) and ServiceUI utilities, and also determine the current architecture under the refresh scenario.

Copy CMTrace: This step is also used in the refresh scenario and is used to copy the correct architecture version of CMTrace into System32 (which minimizes the number of registry setting steps).

Set Default Log Viewer HKCU: These three steps set the necessary registry keys in order to prevent CMTrace from prompting to be the default log viewer.  Yes, they could be done via a script with a package or a very long command line, but I kept them split out and in Run Command Line steps for simplicity.

Open SMSTS Log-NEWCOMPUTER: This step opens the smsts.log in a new computer scenario using the following command: cmd /c “start x:\Windows\System32\CMTrace.exe x:\Windows\Temp\SMSTSLog\smsts.log”

Open SMSTS Log-REFRESH: This step opens the smsts.log in a refresh scenario using the following command: “%deployroot%\tools\%architecture%\ServiceUI.exe” -process:tsprogressui.exe -nowait %WINDIR%\System32\CMTrace.exe %_SMSTSLogPath%\smsts.log

Each time the task sequence boots into a new OS, the above registry entries need to be set.  The following screen shots show each of the phases below:

Refresh scenario booting into WinPE:

Copying CMTrace and ServiceUI into the new OS and then rebooting into the target OS:

Closing CMTrace at the end of the task sequence:

In summary, here are the steps for getting this up and running in your environment.  This assumes that you already have MDT integrated with ConfigMgr 2012 R2:

1. Add both the x86 and x64 version of CMTrace.exe to your MDT Toolkit Package.  They can be found in ConfigMgr install directory\OSD\bin\i386 and ConfigMgr install directory\OSD\bin\x64.  In the MDT Toolkit Package place the x86 version in .\Tools\x86 and the x64 version in .\Tools\x64.  Be sure to update your Distribution Points after adding the files.

2. Download the Client Task Sequence – DEBUG.xml and copy it into the SCCM directory where the Microsoft Deployment Toolkit is installed (i.e. C:\Program Files\Microsoft Deployment Toolkit\SCCM).

3. Use the Create MDT Task Sequence action and select Client Task Sequence – DEBUG in the Choose Template drop down.  Complete the wizard and edit the newly created task sequence.  Select the step Set OS Target Architecture and edit the value to reflect the architecture of the WIM that is being deployed.

4. Create a Deployment and target a Collection.

5. On the targeted Collection, create a variable called DEBUG and set the value to TRUE.  Add some test machines, start a deployment and watch the smsts.log open automatically!

Originally posted on https://miketerrill.net/

Back in the ConfigMgr 2007 days, I wrote a similar blog called ConfigMgr OSD: Always including certain files in your Boot Images -think Trace32.  I figured it was time to create a similar one for ConfigMgr 2012 since some things have changed.  Even though CMTrace is now included in the boot image by default, there are still a few other utilities that I find useful to inject.  Plus, I do not like the fact that CMTrace is not in the path and you have to locate it in order to launch it (i.e. more typing from a command prompt).  Other things like your company’s background image is also nice to include as well.

After making the following changes, any time a boot image is generated (regardless of who does it), the files that you want will always be there.  First, on the Primary Site server, locate a file called osdinjection.xml and open it with Notepad (or your favorite editor).  It will be located in the ConfigMgr installation directory\bin\x64.  This file controls which files get injected into the WinPE Boot Images.  There is a section for each platform.  However, the two common platforms are x86 <Architecture imgArch=”i386”> and x64 <Architecture imgArch=”x64”>.  Underneath each of these sections, there will be a section for WPE, WDT and SCCM.  I add my additions under the SCCM section.  So, for including CMTrace in the Windows\System32 directory, you would add the following under the i386-SCCM section:

<File name="CMTrace.exe">
<LocaleNeeded>false</LocaleNeeded>
<Source>bin\i386</Source>
<Destination>Windows\System32</Destination>
</File>

Make sure to include it before the closing file list tag </Filelist> and save the file.  Also, it is a good idea to make a backup of this file before editing it just in case something happens to the formatting or a tag accidentally gets deleted.  If the file gets corrupt, then all future Boot Images creations will fail. For the x64 boot image, add the following under the x64-SCCM section:

<File name="CMTrace.exe">
<LocaleNeeded>false</LocaleNeeded>
<Source>bin\x64</Source>
<Destination>Windows\System32</Destination>
</File>

Since both architectures of CMTrace.exe are already in the source file locations there is nothing else that needs to be done for these files.  Keep in mind for x64 Boot Images; you will need to use x64 executable files since there is not a WOW 32 bit subsystem in WinPE x64.

Let say you want to increase the log size and history from the default for bare metal builds to 5 MB and 5 roll over logs.  Using Notepad, create a file called smsts.ini with the following contents:

[Logging]
LogMaxSize=5242880
LogMaxHistory=5

Save the file in the ConfigMgr installation directory\OSD\bin\i386. Next, we need to update both the i386 and x64 SCCM sections with the following:

Place the following under both the imgArch=”i386″ and imgArch=”x64″, SCCM sections:

<File name="smsts.ini">
<Destination>Windows</Destination>
<LocaleNeeded>false</LocaleNeeded>
<Source>sms\bin\i386</Source>
</File>

Since the ini file is not platform specific, we can use the same file in both boot images and do not need to create two separate files.

If you always want to include your company’s background image in your boot images, simply rename it to winpe.jpg and copy it (replacing the existing winpe.jpg) into the ConfigMgr installation directory\OSD\bin\i386 directory.  Future upgrades and service packs may over write these files (including osdinjection.xml), so be sure to add it to your upgrade testing check list.

Add any other scripts, tools or utilities to your boot images using the above process (as long as they do not change frequently).  This prevents the need for having a reference package for WinPE stages.  It is best if they are small in size, otherwise your boot images will balloon in size.

Originally posted on https://miketerrill.net/