Lately we had a ticket where a user was unable to execute task sequences from the Run Advertised Program console on his client. FYI, we’re running SCCM 2007 R2. The error the user was facing was this one:

This program cannot run because a reboot is in progress or software distribution is paused.

In the smsts.log file on the client (c:\Windows\System32\CCM\Logs\SMSTSLog\smsts.log) we saw the message “Waiting for Software Updates to pause”. So it seems that besides our Task Sequence we wanted to execute the client was also performing software updates in the background.

In the UpdatesDeployment.log we found something alike “Request received – IsPasued” and “Request received – Pause”

Somehow we couldn’t do much with this information. We hit a wall as we had no clue what updates were installing or why did they hang . So we continued our search. After some digging we found the following information in the registry:

So SCCM keeps track of the Task Sequence currently executing below HKLM\Software\Microsoft\SMS\Task Sequence. It will only allow one at a time. When comparing the registry entries with a working client we saw a small difference. The problem client didn’t had a “SoftwareUpdates” registry entry. As far as I can tell this is SCCM’s system of letting a Task Sequence know it can execute or not. In order to execute it needs two “cookies”. One for Software Distribution and one for Software Updates. If it has both, it means it has the necessary “cookies” to get started.

The actual value of the cookies can also be found in the following location: HLM\Software\Microsoft\SMS\Mobile Client\Software Distribution\State

There we could see that indeed execute was paused as this entry had a value of 1. This was consistent with the error we were seeing in the Run Advertised Programs GUI. A lot of articles and blogs tell you to set it to 0 or delete it. We tried that, but it didn’t had any effects. And then I found the following forum post: http://www.myitforum.com/forums/Software-Updates-waiting-for-installation-to-complete-m221843.aspx With the information posted by gurltech I was able to perform the following steps:

Open wbemtest and connect to root\ccm\softwareupdates\deploymentagent

Execute the following query: select * from ccm_deploymenttaskex1

If all goes well you find an instance

And now check the AssignmentID property

This ID can be used to track down the Deployment so called being “in progress”. When opening the “Status for a deployment and computer” report. And providing the id we just found and the computer name, we couldn’t find any updates to be installed or failed.

So I figured using the script to clear the deployment task from WMI couldn’t hurt much. Either on a next software update cycle scan it would reappear, or it would be gone forever. And indeed, after setting the ID’s (AssignmentId and JobId) to 0 and recycling the SCCM client service we were able to execute Task Sequences again on that client. This situation might be very rare to run into, but I think it might inform you of some insights as to how SCCM works.

This is a bit far from my regular technologies, but today I used the DCM (Desired Configuration Management) feature of SCCM to map the amount of clients which are suffering a particular issue. More specific, we are suffering the issue as described in: social.technet.microsoft.com: Print drivers on windows 7 clients missing dependent files..?

So we know that clients which have the “corrupted” printer driver registry settings look like this:

• Key: HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\Lexmark Universal
• Value1: Help File=””
• Value2: Dependent Files=””

We also know that clients which are healthy look like this:

• Key: HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\Lexmark Universal
• Value1: Help File=”UNIDRV.HLP”
• Value2: Dependent Files=”blabla.dll blablo.dll ….dll”

And we should not forget that not all clients have this driver! So the ones which don’t have have the key/value should not be reported!

SCCM DCM to the rescue! I’ve actually spent quit some time to get this right. Probably because I’m a first time DCM’r, but perhaps because some things aren’t that obvious as well. What I wanted to achieve with DCM explained in words: get me a report which returns all computers that have a blank value for the “Help File” value. So I’d specifically wanted to ignore the ones where that registry value didn’t exist or where it has a value of “UNIDRV.HLP”.

So here is how you don’t do it:

Adding a CI (Configuration Item) where you add a registry key to the Objects tab

As far as I’ve come to understand the DCM configuration, by adding a registry key to the Objects tab, you can check for it’s existence. Now I typed key in bold as in registry terms, a key is like a folder. A registry value on the other hand is like a string, or binary thing which can hold an actual value.

Here’s how can do it:

Leave the Objects tab empty and go on with the Settings tab.

On the settings tab we can add a specific setting of the type registry. Your definition should look like this:

On the general tab all we need to do is specify the Hive, the Key and the name of the Value we are interested in. The validation tab is the one where the real magic happens:

I will first go the next screenshot and then I’ll come back to this one. In the next screenshot you will see how I added a new validation rule by clicking “new”.

What you see here should be pretty obvious: I specified that if the “Help File” registry value equals “UNIDRV.HLP” all is good. And more specific if this wouldn’t be the case it should be expressed as a severity of Error. Now some examples:

• Value example #1: “UNIDRV.HLP”: compliant
• Value example #2: “UNIDRV”: non-compliant
• Value example #2: “”: non-compliant
• Now what if the registry value doesn’t exist to begin with?!

Well that’s where the previous screenshot comes into play: by default Report a non-compliance event when this instance count fails is checked. I specifically unchecked this one. It is to my understanding that this one will cause the CI to be non-compliant if the registry value (the instance) can’t be found. In my case if the value can’t be found it means the driver isn’t installed and thus the client is not suffering the issue.

So in short, using the configuration as shown above I have established that all clients which have a registry value “Help File” under the given key should have a value of “UNIDRV.HLP”. If they’ve got an empty value, they’ll be included in the report. The ones which don’t have this driver, and thus don’t have this registry value will be excluded from the report. This will allow us to do some quick and dirty fixing of the clients which already are suffering this issue and at the same time we can try distributing a printer feature hotfix package of Microsoft. Once that one is out on the clients we can use the reporting to find out if new cases are occurring.

It was a post of KevinM (MSFT)  which made all of the above fall together: social.technet.microsoft.com: Check if Registry Value Exists?

The actual reason why I’m toying around with DCM (Desired Configuration Management) will be explained in my next post. But here’s a tip I’ve found to be quit practical when trying to get your CI (Configuration Item) configuration right.

I quickly found out that whenever you changed settings in the CI you’ve had to initiate the Machine Policy Retrieval & Evaluation Cycle action so that the Conf Manager client would have the latest version of your Baseline/CI.

In the Configuration Manager client you’ve got a button called Evaluate on the last tab which you can use to actually allow the CI to be evaluated and give you a report displaying the current compliance state.

In the screenshot you see “Unknown:Scopel….” but that’s just a GUI refresh thingy. After a few minutes it’s properly displayed. Now this part is easy. Now on the other hand I was switching a regkey by hand on the client in order to trigger the various possible outcomes of my baseline. And after I while I figured out that there had to occur some caching behind the scene’s…

Using google I found an explanation at the following forum: myitforum.com:[mssms] Configuring DCM to detect (Default) Value name [mdfdr5]

And then I started using the following workaround in order to avoid the 15’ interval:

By appending a number to the CI name I was triggering a version increase. This in turn causes the cached result to be come invalid and ensures my evaluation always gives the most up to date answer. It’s a bit dirty and causes for a high version number, but on the other hand, this is in a test environment, and it’s damn easy like this.