CCMEXEC.COM – System Center blog

CCMEXEC.COM – by Jörgen Nilsson

I promised last week I would write a blog post on how I use OSDbackground in case of a Task sequence failure, so here it is. OSDbackground gives us the possibility to show an error in case a Task Sequence fails and when doing so it also provides us with the option to read all TS variables and open a command Prompt or CMtrace without having F8 Support enabled.

Well, to handle errors in a Task Sequence I use a couple of small scripts that I will describe here and that can be downloaded further down in the blog post. Basically, the functionality is the same as in an MDT integrated Task Sequence.

We start by using a group called “Execute Task Sequence” with the “continue on” error option selected.

TS error handling

Then we run our whole Task Sequence within that group, in that way we can catch any error in a group later in the Task Sequence.

I also set the variable shown above “SMSTSErrorDialogTimeOut” to “28800” which equals 8 hours. If the task sequence fails, the countdown timer will count down from 8 hours before restarting.


In the end of the Task Sequence we have two groups, “OSD Completion” and “OSD Error”.

The OSD Completion group is run as the name indicates when the Task Sequence is successful, using the Task Sequence variable “_SMSTSLastActionSucceeded” = “True”. We remove the computer from the OSD Collection using the Onevinn WebService in this group as well.


I also added a little step to stop the OSDBackground process, if we don’t restart the computer after we started OSDBackground the last time it will still show as desktop background when the user logs on.

The Powershell script used looks like this.

Stop-Process -Name “OSDBackground” -Force -ErrorAction SilentlyContinue

What if the Task Sequence fails?

In the OSD Error group we have a couple of interesting steps as well. The OSD Error code has the following condition. Using the same Task Sequence variable as before when there is an error in the Task Sequence, “_SMSTSLastActionSucceeded” = “False”.


The next step saves the error code from the Task Seqeunce step that actually failed in a Task Sequence variable called “ErrorReturnCode”. We use that later to actually fail the Task Sequence using a script but with the original error code.


The next step uses OSDBackground to change the Background image and enable us to open a password protected debug mode with ,command prompt support without having F8 enabled.


The next three steps are from the sample scripts in the Onevinn OSD WebService, and the first one sets a couple of variables we need to be able to remove it from the Collection used to target the OS deployment.


The next step remove the computer from the OSD Collection.


We can then disable the computer account using the Web Service in the domain to make sure no one uses a computer with a failed OS deployment potentially missing anti-virus and much more.

Disable Computer account

Then we use a small script that will fail the Task Sequence with the original error code that we saved in the variable before.


The script used looks like this:

$tsenv = New-Object -ComObject Microsoft.SMS.TSEnvironment

exit $tsenv.Value(”ErrorReturnCode”)

The result is a Task Sequence that will end up with this dialog when it fails.


Now we can right-click in the upper left corner and supply the configured password to open the debug options in OSDBackground and troubleshoot our Task Sequence error without having F8 enabled in our boot image.


OSDBackground was updated on Technet yesterday as well, so if you don’t have CMtrace in your image, you can just copy Cmtrace.exe to the OSDBackground package and it will copy CMtrace to the local drive so it can be used to read the log files. A great addition by Johan!
The two scripts used can be downloaded here and I would add them to the OSDBackground package so we can run them from the same package in our Task Sequence.

OSDBackground Addon

Thanks Johan Schrewelius for creating OSDBackground!!

I wrote a blog post a while ago on a tool my college Johan Schrewelius has published which sets the OSDbackground during OSD and gives us the possibility to troubelshoot without F8 support enabled which should be avoided. An update of OSDBackground is now published with som bug fixes like:

1. Added Management Point to Wallpaper.

2. Made “ComputerNameVariable” Case Unsensitive.

3. Masked sensitive TS Variables in Debug mode.

4. Added support for Error background.

5. Moved background pictures to sub folder

The error background is a great addition, using this we use OSDBackground with a specific background when a Task Sequence fails and then we can access a Command Prompt or Cmtrace without F8 support enabled. We need to have a section in our Task Sequence with steps that are executed when a TS fails, I will write a post on that later this week. Configuring the “SMSTSErrorDialogTimeOut“ variable to for example 28′800 =8 hours is a good idea so we have time to catch the computer with the error still present.


Adding a step to our TS failed section like this:

OSDBackground Error

Then we get the following dialog when the Task Sequence fails.


OSDBackground can be downloaded on Technet Gallery:

I have used Michael Niehaus excellent script for dumping all task sequence variables during OSD which is great for troubleshooting.

However it dumps all TS variables including:

  • _SMSTSReserved variables which for instance contains the Network access account username and password in clear text. The same goes for the Domain Join account used in the Task Sequence.
  • _OSDOAF which contains the TPM Password Hash for the computer it the Pre-Provision Bitlocker step is used and it takes ownership of the TPM.

So my college Johan Schrewelius posted a nice little Powershell script that can be used instead, which excludes the “sensitive” variables and only write the public ones to the log file.
It can be downloaded here:

In many environment scripts used for troubleshooting like this are left in the production Task Sequences and that is not a really good idea if it includes username/password in clear text or TPM password hash.

The script simply filters out the “sensitive” variables:

FilterSo if you need to use a script to list the TS variables be carefull where that log file is stored or use this one.

Great to wake up to a new release of Configuration Manager Technical Preview 1611! The Configuration Manager team must have been really busy, first shipping 1610 and then a week after 1611 technical Preview.

Truly impressed by the work they are putting in the product!

Not that many new features in 1611 Technical Preview though but a really useful one, the possibility to pre-cache the content for an available Task Sequence deployment.

Cm1611TP New


In previous releases there have been more features than was listed in the What’s New section.. Wonder if there are any this time…

In Windows 10 1607 the TPM Password Hash is no longer accessible from within windows. This is design change to increase the Security in windows 10 which you can read more about here:

Quote: “Starting with Windows 10, version 1607, Windows will not retain the TPM owner password when provisioning the TPM. The password will be set to a random high entropy value and then discarded.”

The ability to turn on TPM Backup to AD using Group Policy is also removed in the Windows 10 1607 .ADMX files as documented here:

The behavoiur is controlled by the registry key called “’HKLM\Software\Policies\Microsoft\TPM\OSManagedAuthLevel” it is default set to “2” which means it will discard the TPM Password Hash, if we set it to “4” it is retained.

When we upgrade ADK to 1607 we get the same behavior in WinPE so the script used before to capture the TPM Password Hash when we use Pre-provision Bitlocker and write it to registry doesn’t work anymore.

When me and my College Johan Schrewelius tested this, we found a Task Sequence variable that contains the TPM password hash if the Pre-Provision Bitlocker step is used in the Configuration Manager Task Sequence called “_OSDOAF”

Johan posted two Powershell Scripts here on Technet Galleries, one that read the TS variable and write it to the registry and set the “OSDManagedAuthLevel” to “4” otherwise it will be removed by Windows again.

And one that simply sets the “OSDManagedAuthLevel” value back to default.

Here are the steps that are involved, I disabled the SaveWinPETPMOwnerAuth.wsf that we used before to achieve the same thing.

TPM Pass the Hash

The “MBAM TPMPassTheHash” step which we call it, runs the following script. A Computer restart must be run before the Invoke-MbamClientDeployment step is run.

TPM Pass the Hash Step1

And the “Reset tpm policy” step will reset the value of the “OSDManagedAuthLevel” back to default.

TPM Pass the Hash Step2

Then we have the TPM password Hash in our MBAM database once again.

Note that it is recommended that the TPM Password Hash isn’t saved anymore as stated in one of the links above. “Microsoft strongly recommends that you do not change the default value of this registry key in order to retain the owner password.”

But in some scenarios we still want to be able to do it.

There are a couple of OS deployment webservices out there like the legendary one from Maik Koster that is great (Should be built-in the product!) We have been using and developing our own OSD webservice at Onevinn which we used a couple of years now. It has been developed by my college Johan Schrewelius who have done a marvelous job with it!!

We have been planning to share this for a long time but never found the time to complete it, at today’s System Center User Group Sweden – Client day at Microsoft in Sweden we thought it was time!

It can be downloaded from Technet Galleries here with complete documentation as well:

It contains the following features which can be used once installed.


One reason to why we started doing this is for instance the need to delete Primary users during OS deployment during OSD so that it can be set once again during OS deployment but the history is removed.

The installation is a simple setup that you run on the server.


Configure the service account to be used.


To make it easy to use there are sample scripts included as well which can easily be used in a Task Sequence.

Powershell Sample scripts

All Configuration is done in the Configuraiton.ps1 file that all the other scripts use so we only need to configure this once.

Powershellscript config

This makes it really easy to include in a Task Sequence as shown below.


Why use a webservice? Well we move the logic to the Server side which makes our OSD much more stable and less latency sensitive when you run scripts against the Configuration Manager server in a Task Sequence. We don’t have to open all more than port 443/80 from clients to the server as we don’t run any scripts in the Task sequence just calls a webservice.

As I wrote before the download includes complete documentation so check it out when you downloaded it on how to get started!

There are many solutions out there for setting the OSD background to show progress during OS deployment. My college Johan Schrewelius at Onevinn has written a great one that shows:

  • Time elapsed
  • Host information
  • Current OSD Step
  • Custom background
  • Yes, it works in full OS in Windows 8.1 and Windows 10 as well.
  • Password Protected debug mode!!
  • Customizable colors
  • Easy configuration in a .xml file.


It has a password protected debug mode for accessing Task Sequence variables, CMtrace, SMSTS.log and Command Prompt. If you haven’t turned of F8 Support in your boot image, it is time to do so now! It is accessed by Right-Clicking the upper left corner.



In the Task Sequence, we simply add a step that executes OSDBackground and which step number it is. As shown below.


It requires minimal configuration as everything is configured using a .xml file, it does require .NET framework and Powershell support in the Boot image so it needs to be added under optional components. The steps shown in the background is easily added modified, colors, debug password as well.

OSDBackground confguration

It can be downloaded from Technet Galleries, both the binaries and complete documentation on how to use it:

Great work Johan!!

I have gotten this question so many times now when writing scripts and blog posts what the difference is between a Task Sequence in MDT and SCCM. In some scenarios this makes a huge difference and is important to know about.

When you execute an OSD Task Sequence in MDT you are logged on as the local administrator account as shown below. Which means that all Scripts, Applications etc. is run as the local administrator account.



When you use Configuration Manager the Task Sequence is executed in System context which means that scripts, applications are executed in System Context. So if we enable F8 support (Remember testing only!) we are running in System Context.

Why is this important?, well if you test and install applications using Configuration Manager you should always test them in System Context and not as the local administrator, this can be done using PSexec. When you develop and run scripts you need to be aware of this as well and again test them in System Context if applicable.
An example would be the script I blogged a while ago to set a corporate wallpaper in Windows 10, when running that script we need to take ownership of the files in question before we can replace them. If we run it in MDT we need to the “Administrator” to own the files to be able to replace them, if we use Configuration Manager we need to use “System” instead to own the files.

Example MDT

takeown /f c:\windows\WEB\wallpaper\Windows\img0.jpg

takeown /f C:\Windows\Web\4K\Wallpaper\Windows\*.*

icacls c:\windows\WEB\wallpaper\Windows\img0.jpg /Grant ‘Administrator:(F)’

icacls C:\Windows\Web\4K\Wallpaper\Windows\*.* /Grant ‘Administrator:(F)’

Remove-Item c:\windows\WEB\wallpaper\Windows\img0.jpg

Remove-Item C:\Windows\Web\4K\Wallpaper\Windows\*.*

Copy-Item $PSScriptRoot\img0.jpg c:\windows\WEB\wallpaper\Windows\img0.jpg

Copy-Item $PSScriptRoot\4k\*.* C:\Windows\Web\4K\Wallpaper\Windows

Example Configuration Manager

takeown /f c:\windows\WEB\wallpaper\Windows\img0.jpg

takeown /f C:\Windows\Web\4K\Wallpaper\Windows\*.*

icacls c:\windows\WEB\wallpaper\Windows\img0.jpg /Grant ‘System:(F)’

icacls C:\Windows\Web\4K\Wallpaper\Windows\*.* /Grant ‘System:(F)’

Remove-Item c:\windows\WEB\wallpaper\Windows\img0.jpg

Remove-Item C:\Windows\Web\4K\Wallpaper\Windows\*.*

Copy-Item $PSScriptRoot\img0.jpg c:\windows\WEB\wallpaper\Windows\img0.jpg

Copy-Item $PSScriptRoot\4k\*.* C:\Windows\Web\4K\Wallpaper\Windows

I hope this is helpful!