4 comments

SCCM 2007: DCM Check For A Registry Value Only If the Value Exists

Published on Monday, September 10, 2012 in

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

image

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.

image

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

image

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:

image

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”.

image

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?

Related Posts

4 Response to SCCM 2007: DCM Check For A Registry Value Only If the Value Exists

Anonymous
06 February, 2013 01:17

Thomas,
I was hoping to get some insight as to the solution you have found for this issue. I am having the same issue you described, and I've got an active thread about the situation open here: http://social.technet.microsoft.com/Forums/en-US/winserverprint/thread/08bc6b4b-0190-40b0-be16-8b82249148e4
I'm assuming the "printer feature hotfix package of Microsoft" you described was KB2647753?
Did that resolve your problem? The issue still occurs on our units after applying that fix.
We are currently running Procmon on 14 client machines to check for changes to the Dependent Files registry entry, in order to shed some light on the cause of this issue.
We would rather not disable client-side rendering, though it seems that this is the path most admins have chosen to combat this issue.
Any information you can provide would be greatly appreciated, as we are seeing 8-12 occurrences per day out of about 400 machines.
I will check this blog daily for your response.
Thanks for your time.

06 February, 2013 09:02

I'll have to check with my colleagues for the actual solution. This is a customer where I only drop by everyone once in a while... I'll come back to you.

Anonymous
11 February, 2013 17:45

I'm anxiously awaiting your response! We've had another network admin post to that MS forum who is experiencing the same issue, so your solution would be greatly appreciated! I think MS is interested in the solution as well, for it seems to be a software bug.
Thanks for your time!

18 February, 2013 14:18

Sorry for my latish comment. I've contact my colleague, and it seems that for now they wrote a procedure for the helpdesk to be able to fix the situation by recreating the registry keys and recycling the spooler service. We are aware that this is not a fix but a workaround. But due to the fact that we rarely see new cases this was acceptable for us...

Good luck with your case...

Add Your Comment