ConfigMgr Client failure – CCMRegisterWinTask

If the SCCM 2012 client fails with  a generic 1603 error at the following phase;

MSI: Action 7:01:41: CcmSetServiceConfig. Sets WMI ServiceRootDir and configures CCMEXEC service.            ccmsetup            2015-01-26 07:01:41       1764 (0x06E4)

MSI: Action 7:01:41: CcmRegisterWinTaskRollback. Rolls back the changes made by CcmRegisterWinTask.        ccmsetup            2015-01-26 07:01:41       1764 (0x06E4)

MSI: Action 7:01:41: CcmRegisterWinTask. Registers tasks with Windows Task Scheduler.           ccmsetup          2015-01-26 07:01:41            1764 (0x06E4)

MSI: Action 7:01:42: Rollback. Rolling back action:         ccmsetup          2015-01-26 07:01:42       1764 (0x06E4)

File C:\WINDOWS\ccmsetup\{181D79D7-1115-4D96-8E9B-5833DF92FBB4}\client.msi installation failed. Error text: ExitCode: 1603

ErrorMessages: ccmsetup          2015-01-26 07:02:14       1764 (0x06E4) 


This is usually caused by failures within the Task Scheduler and those errors will also happen outside of ConfigMgr.

In order of preference, try the following suggested solutions;

1. Run the below command and restart the computer


2. Run the below command and restart the computer

fsutil resource setautoreset true c:\

3. Delete all files in c:\Windows\System32\config\TxR and restart the computer

Create Application

During a project I created a specific tool to ease the insert of applications within SCCM 2012. It was only tested for SCCM 2012 SP1 CU3 and on Windows 7 x64, with Windows Management Framework 3.0.

Video that demonstrates the tool; Create Application

David O`Brien wrote some great code that sorts out the poor quality of the SCCM 2012 PowerShell support. It is used as part of the script process.

Luca Sturlese made a logging function for PowerShell available which I used to create the log-file.

The idea is that you copy the source-files to your source-folder for all your apps, right-click the MSI and then the script creates an application within SCCM 2012 based on the MSI information. A log-file is generated incase some troubleshooting is necessary, but for status you can simply review the notification bubble.


I haven’t tested this on SCCM 2012 R2. I code horribly. I know the installer breaks on a x86 platform. It most likely works on Windows 8+, but I haven’t tested that. The script is depending on multiple WMI-calls, which in high latency environments will cause issues.

You are welcome to try this, send me improvements – or even take this for a spin and just make it better. I was tired of bitcoin casino doing this manually, and copy and pasted something from the internet which solved my problem. Take this for what it is. Nothing more, nothing less.

Some tips for installing the MSI;

Use the following properties;
FQDN to site-server
Basefolder where all packages will be created. A new sub-folder with username will be created
Base Application Name on MSI-info (false) or folder-name
(true – requires; APPNAME\DEPLOYMENT folder structure)

True or False
True or False
Numbers only
True or False
Numbers only
Download or DoNothing
Path and prefix to where log-files will be located.
ProductName and ProductVersion will be appended
Path and prefix to where log-files will be located.
ProductName and ProductVersion will be appended

Logging happens to:

Download the file here

SCCM 2012, Software Center and applications made available to users

As noted quite early in the marketing for SCCM 2012 there was a change on how users were presented with available applications. The fundamental change is that any software made available (as opposed to required) were only presented in the new Application Catalog. Microsoft posted a blog-article detailing the different scenarios that could happen, which presents a good overview table on what is seen where when deployed to different resources.

As opposed to start communicating users to either use Application Catalog or Software Center depending on how we have decided to target the users or the computers within SCCM, a better way would be to leverage the traditional method of targeting computers. If targeting computers any software made available will be presented in Software Center, however SCCM 2012 has also been released with the mindset to start handling users – and not computers.

What to do?

Use SCCM to target software to the user’s devices. This would avoid the following topics in the forums; user-based available application not showing up in Software Center by design?!

Previously a few blog-articles have discussed this method for targeting Software Updates and a few rare occasions have shown up with no specific purpose.

To boil it down we will be leveraging the fact that SCCM can track users primary devices and thereby maintaining a relationship between devices and users. This method will allow us to query the database for the following information;

All the devices for users belonging to AD-group X.

Create a collection with the below query and this will allow you to provision software to users, but target their computers.

select SMS_R_SYSTEM.ResourceID,
from SMS_R_System
JOIN SMS_UserMachineRelationship ON
SMS_UserMachineRelationship.UniqueUserName = SMS_R_User.UniqueUserName
WHERE   SMS_UserMachineRelationship.Types=1
AND   SMS_R_User.UserGroupName="DOMAIN\\AD-GROUP"

Apply hotfixes during task sequence

If you want to apply hotfixes as part of a task sequence there are of course numerous ways to achieve this. Using PowerShell, MDT 2012 U1 (soon to be 2013??) with SCCM 2012 can make this look a lot prettier with just a few lines of code.

So, lets set this up.

1. First of all we need a script, named hotfixes.ps1. The code looks like this;

$scriptPath = split-path -parent $MyInvocation.MyCommand.Definition
$folder = $scriptPath
$total = gci $folder *.msu | measure | Select-Object -expand Count
$i = 0
gci $folder *.msu | foreach {
WUSA ""$_.FullName /quiet /norestart""
Write-Progress -activity "Applying Hotfixes" -status "Installing $_ .. $i of $total" -percentComplete (($i / $total) * 100)
Wait-Process -name wusa

2. Collect the hotfixes necessary into a folder. Place the script in the root, and the hotfixes in a sub-folder named “hotfix”. All hotfixes must be of the .MSU-kind.


3. Create a package of this to make the files available within the SCCM 2012 infrastructure


4. Create a new MDT 2012 Update 1 task sequence. Add the following steps;


As you can see below we set our script to be executed and reference the package which contains the updates


5. Deploy the task sequence to a computer and verify the results;


Looks nice? Well, the script is partly built on the ideas of Niklas Åkerlund, a fellow Swede, on howto install multiple Windows hotfixes. Using a forum-post response by Michael Niehaus I gathered that it would be rather simple to output it more nicely and provide insight into progress using the task sequence progress bar.

Notifications are globally suppressed

After reviewing the fact that no new notifications were provided by the SCCM 2012 Client for applications beeing deployed a quest for the right log-file to locate the root-cause, it was a great relief to identify all notifications beeing processed in a single log-file.

SCNotify_DOMAIN@USERNAME_1.log presents a complete history of what the user has been presented with. However, this was shown;


Notifications are globally suppressed, this event will not be processed by NotifyObjectInstanceBase   (Microsoft.SoftwareCenter.Client.Notification.NotifyObjectInstanceBase at IsKnownEvent)

It seems that the Computer Agent settings has a setting which doesn’t directly reveal its impact, however the documentation clearly states that it will disable notifications.

Additional software manages the deployment of applications and software updates

Enable this option only if one of the following conditions apply:

You use a vendor solution that requires this setting to be enabled.
You use the System Center 2012 Configuration Manager software development kit (SDK) to manage client agent notifications and the installation of applications and software updates.


It seems that reboot notifications are not impacted by this as it requires a few more tricks provided by Microsoft to suppress them.

Detection logic for MSU in SCCM 2012

I spent the day reading quite a few blog-articles relating to the detection logic for Microsofts new patching format, and howto properly output that into SCCM 2012.

Detection Method for MSU in Applications for SCCM 2012

Deploying the App-V 5.0 Client Using Configuration Manager 2012 SP1

How to create an application for deploying the App-V 5.0 Client with Configmgr 2012

SCCM 2012: Microsoft Update (MSU) als Applikation verteilen

All of the above does have a few issues though. The detection logic isn’t fulproof as a “false” one could easily error out. As I have previously written – the exit-code of a VBScript isn’t relevant when using it for Global  Conditions and the same seems to apply for Detection methods. As noted on Technet (however, for Global Conditions) the output must be through an Echo (or something similar) – which must be something for both a false and a true scenario.

Sample code;

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")

Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_QuickFixEngineering WHERE HotFixID = 'KB2506143'")

If colItems.Count = 0 Then

Wscript.StdOut.Write "False"



Wscript.StdOut.Write "True"


End If

Global Conditions and VBScript

Currently my days are filled of migrating previous heavy-duty VBScripts that have provided what SCCM 2007 doesn’t have, but SCCM 2012 offers in the Application Model.

A major part of replacing VBScripts are Global Conditions within Configuration Manager 2012. And as the original script is in VBScript along with the fact that the client base is Windows XP to some extent – VBScript will prevail a bit longer even though its now wrapped within a Global Condition.

What I should have done from the start was to read about Global Conditons in the official Technet-site. There are a few gotchas and I realized that even more of the old code could have been moved to native functionality. For example – File checks can traverse the environment variable %USERPROFILE% and effectively check for a file (or folder) in all users folders on a specific target.

Now, I didn’t do this. So therefore I suffered for a day.

As the VBScripts had already been used in production I knew the quality of them was quite high in terms of achieving what I wanted – stripping them down to a specific function (remove installs and only perform a specific check for example) was easy. My first belief was that the exit-code of the script mattered. This resulted in some odd experiences, because everything ended with error.

Reading the documentation revealed that the exit-code wasn’t as relevant (should always be 0)

The value returned by the script will be used to assess the compliance of the global condition. For example, when you use VBScript, you could use the command WScript.Echo Result to return the Result variable value to the global condition.

Great – I can perform an echo! Well, obviously  this is the way togo – howelse to return a string for example?

As my initial tests involved the check that could only return true or false that was what I returned (a boolean value). VBScript outputs –1 as true. So when my boolean variable was true – the output was –1. However, SCCM was none the wiser.

Result (from DcmWmiProvider.log )

ScriptProvider::ReadDiscoveryInformation – reading discovery script definition    ScriptProvider   8/20/2013 12:41:57 AM  1428 (0x0594)

ScriptProvider::ReadDiscoveryInformation – ScriptType: 1           ScriptProvider   8/20/2013 12:41:57 AM  1428 (0x0594)

ConvertToVariant failed to convert value:-1 to Type:Boolean (0x80041005).          ScriptProvider   8/20/2013 12:41:57 AM  1428 (0x0594)

Failed in discovering instance.

Type mismatch (Error: 80041005; Source: WMI)  ScriptProvider   8/20/2013 12:41:57 AM  1428 (0x0594)

This failed completely.

If the output instead becomes the string “true” or “false (Result = “True”) – the output is handled by SCCM and can easily be converted into a Boolean (which makes the SCCM admins life my easier).

Unfortunately – the successful use of a script has no output in any logs as far as I have seen.

ConfigMgr 2012, App-V and /EXE

Really? Still not supported?
When using the ConfigMgr integration – it takes over the App-V Client and replaces the default startup for all virtualized applications to something other than sfttray.exe. No harm in that – apart from the fact that any other switch than /launch is not passed on and will result in – nothing!

Why is this important? The App-V team introduced the most wonderful switch /EXE which is explained a lot better by Aaron Parker in his App-V FAQ. (really – he explains it a lot better than I ever could).

How do you work around it?

Command-line that doesn’t work;
C:\Windows\CCM\VAppLauncher.exe /EXE cmd.exe /launch “Microsoft Expression Encoder 4 4.0.4276.0

Command-line that will work with any App-V Client configuration;
“C:\Program Files\Microsoft Application Virtualization Client\sfttray.exe” /EXE cmd.exe /launch “Microsoft Expression Encoder 4 4.0.4276.0

In ConfigMgr 2012 – any produced file type association and shortcut will using vapplauncher.exe as the starting point. To get the latter possibility to troubleshoot within the virtual environment – create a shortcut for SFTTRAY.EXE located in the installation folder of the App-V Client and append the /EXE and /launch switches with your application name and version as input (written in italics above).

Config Mgr 2012 and App-V

Previously when using App-V and leveraging the infrastructure of SCCM 2007 and the integration of the App-V you were “limited” to using anything from Configuration Manager. In itself – this wasn’t all that bad, but any type of migration scenario were very much dreaded and the enabling or disabling of the integration was a big on-off switch – that dropped anything previously distributed to App-V Client and took over the control of the client. Configuration Manager 2012 has come a long ways and especially when migrating between different scenarios – it isn’t as controlling in some scenarios.

First – a few notes; There isn’t any configuration on the Configuration Manager 2012 infrastructure or client that enables or disables any functionality. By default – its capable of integration with App-V and will do so without any particular tasks required to be performed by the administrator. Reviewing a previously installed App-V Client that has one single application distributed gives us the following views;

(registry configuration to start an application)


(one application distributed using stand-alone method)


Even though this wasn’t part of the experiments conducted today – any Publishing Servers should be removed once the client controlled by Configuration Manager 2012. Not only once – but it should continuously be removed in the future.

After installing Configuration Manager client, adding applications and creating new deployment (that didn’t require the install – so we could control the time of installation) for our device – the above registry keys didn’t change. Once we initiated the deployment and installed the App-V package – the registry keys switched to the below;image

Interesting part is that the old application is still there and will still start (as opposed to using the integration with Configuration Manager 2007 – where it would not start). What was rather surprising though – is that even though all three applications are started, the one not distributed via Configuration Manager 2012 will never say that it is In Use.