ConfigMgr 2012 R2 OSD: Create Your Own TS Templates

If you spend a lot of time creating ConfigMgr 2012 R2 OSD Task Sequences, you probably have a method for inserting the steps and groups that you like to use in every TS you create.  Maybe you open a reference TS up and copy and paste steps into a new TS that you are creating.  Maybe you export and import your favorite task sequences or just right-click on one and copy it in the console.  Wouldn’t it be great if you could just create a template of your favorite task sequences and be able to pick them when running through the Create MDT Task Sequence wizard?  Yeah – I was thinking the same thing one day and decided to see if I could do it.

A ConfigMgr Task Sequence is stored in XML.  If you use the Get-CMTaskSequence PowerShell cmdlet, you will notice one of the properties is Sequence.  This is what gets displayed (and updated) when you use the Task Sequence editor.  So, all you need to do is the following:

  1. Build a TS the way you like it
  2. Export the TS XML
  3. Modify it slightly
  4. Copy it into the MDT directory
  5. Test it by using the Create MDT Task Sequence wizard

For step #1, depending on the steps that you add in the task sequence, you might need to clean them up a bit.  For example, if you have a reference package in a step, you might disable the step if you plan on using the template in another ConfigMgr site.  Do the same for anything that is unique or you do not want shared.  In these cases, there might be minor edits that need to be made to the task sequence after running through the Create MDT Task Sequence wizard.  The benefit is the time saving and all of the groups and steps are in the correct order in the task sequence.

For step #2, export the (XML) contents of Sequence property.  If you just dump that value, the XML will be unformatted and if you are like me, that will drive you crazy.  With a little help from PowerShell (and my good friend Kaido @ Coretech for the proper syntax), we can dump this to a file all nicely formatted.  In my previous post, ConfigMgr 2012 OSD: Automatically Open SMSTS log, I included a template that could be used.  I will use this as my example.  The name of the task sequence that I created as a reference is called Standard OS Deployment MDT-DEBUG.  I want to export the XML to a file called Client Task Sequence – DEBUG.xml.  I accomplished this by using the following:

	$TS = Get-CMTaskSequence -Name 'Standard OS Deployment MDT-DEBUG'
	[XML]$XML = $TS.Sequence
	$XML.Save('e:\1E Demo\Client Task Sequence - DEBUG.xml')

For step #3, there are just a few things that need to be done in order to make it usable with the Create MDT Task Sequence wizard.  Add the following to the beginning of the XML:

<?xml version="1.0"?>
<SmsTaskSequencePackage xmlns:xsi="" xmlns:xsd="">
  <Category />
  <DependentProgram />
  <Description />
  <Name>Client Task Sequence - DEBUG</Name>

Be sure to give it the proper name as you want it to show up in the Create MDT Task Sequence wizard drop down box (mine is named Client Task Sequence – DEBUG), and update any other settings you require.  The Boot Image ID will get updated by the one that is selected/created in the wizard, so no need to worry about that field.  The next thing is to add the following to the end of the XML:

  <SupportedOperatingSystems />

I usually modify the SourceDate as a way of versioning my templates.  (Modifying this manually shows what needs to be done, however, this whole process could be automated using PowerShell.)

For step #4, save the file and copy it into the SCCM directory where the Microsoft Deployment Toolkit is installed (i.e. C:\Program Files\Microsoft Deployment Toolkit\SCCM).

For step #5, create a new task sequence using the Create MDT Task Sequence wizard and you should see your newly created template:

01 Create TS Template

Test it out to make sure it works and then share it with your coworkers, friends, local user group, etc.!

Originally posted on

ConfigMgr 2012 OSD: Automatically Open SMSTS log

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:

01 OSD-Debug

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:

02 OSD-Debug

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

03 OSD-Debug

Closing CMTrace at the end of the task sequence:

04 OSD-Debug

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

ConfigMgr 2012: Always including certain files in your Boot Images

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">

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">

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:


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">

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

AZ Systems Management User Group presents: Kent Agerlund and Mike Terrill

We are planning on having our fifth meeting of 2014.  This meeting will be held at ***Interface Technical Training***: 3110 North Central Avenue, Suite 160, Phoenix, AZ 85012, September 11th . The meeting will start at **5:00 PM** with the welcome time at 4:30 PM-come early and socialize a bit.

Kent and Mike will be presenting on the following:

Compliance – the new orange in Enterprise Client Management

Never before have we been looking at the same amount of challenges in terms ensuring compliance among all our clients. Forget about the days where managing compliance was a question of implementing the correct group policy: The challenges of today and tomorrow are different as the types of devices become more diverse. This session will teach you how you can use Settings Management to ensure compliance on your Windows devices, Mac OSx devices and mobile devices. We will also look into how you can use Settings Management modify registry settings, deploy software and much more.

Kent Agerlund, Coretech Co-Founder and evangelist

In 1999 Kent Agerlund, co-founded Coretech. The company growth is heavily fueled by Kent´s own enthusiasm and determination to constantly strive for the highest possible expert knowledge in the System Center suite.  Kent’s enormous experiences as an instructor are recognized world-wide by delegates attending his courses. His rare ability to combine hands-on know-how with deep and detailed knowledge of Configuration Manager, which he has worked with since 1996, as well as advanced infrastructure makes Kent one of the most sought after expert instructors in the world.

Mike Terrill, Product Manager at 1E

Mike is the Windows Migration and User-centric Application Management Product Manager at 1E.  He specializes in the design, architecture and installation of Configuration Manager and Windows operating system deployments.  Prior to joining 1E in 2007, he worked 10 years for a global strategic outsourcing company as an IT Architect specializing in SMS, software distribution and operating system deployment.  His most recent project included deploying System Center 2012 Configuration Manager and Windows 7 to a 450K seat environment.  He founded and runs the Arizona Systems Management User Group and has been working with SMS since version 1.2.

Registration Link:

Mike Terrill
AZ Systems Management User Group