Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SMS 2003 check for specific registry entry?

50 views
Skip to first unread message

Barkley Bees

unread,
Dec 11, 2009, 2:08:35 AM12/11/09
to
We need to check all of our client PC's for a specific string value in the
registry under HKLM. Is it possible to perform this using SMS 2003 or
perhaps there is a better alternative method? Appreciate any advice. Thanks.


Tom Watson

unread,
Dec 14, 2009, 8:27:01 AM12/14/09
to
You could try :-

http://myitforum.com/cs2/blogs/tom_watson/archive/2009/09/16/alternative-registry-inventory-with-configmgr.aspx

Hopefully my instructions are easy enough to follow. PS. This would be for
ConfigMgr 2007. For SMS 2003, you'd have to compile the addition to
Configuration.mof on the client using MOFCOMP.EXE.

Regards,
Tom Watson

"Barkley Bees" wrote:

> .
>

Barkley Bees

unread,
Dec 14, 2009, 11:48:21 AM12/14/09
to
Thanks for your reply Tom....was there anything wrong with the way I went
about it using RegKeyToMof?
I have had a look at the below also but I must be doing something wrong as I
can't get it going on my SMS2003 server:

http://scug.dk/blogs/configurationmanager/archive/2009/10/21/how-to-get-registry-information-into-hardware-inventory.aspx


"Tom Watson" <TomW...@discussions.microsoft.com> wrote in message
news:6F9F8DD8-87C9-42E1...@microsoft.com...

Sherry Kissinger [MVP]

unread,
Dec 14, 2009, 2:34:01 PM12/14/09
to
There's nothing wrong with RegKeyToMof. It's just Tom's method is kind of
cool, too. :-)

And if you are on Configuration Manager, depending upon what you actually
needed to do with knowing something about a particular regkey, in some
limited scenarios, you could skip a MOF edit completely, and just use a DCM
Baseline to look for "is this computer compliant" or not.

"Barkley Bees" wrote:

> .
>

Barkley Bees

unread,
Dec 15, 2009, 12:00:03 AM12/15/09
to
Thank you for the feedback Sherry. I followed the below:
http://scug.dk/blogs/configurationmanager/archive/2009/10/21/how-to-get-registry-information-into-hardware-inventory.aspx
and this was what I added to the end of my sms_def.mof:
--------------------------

#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("SusClientId1", NOFAIL)
[DYNPROPS]
Class SusClientId1
{
[key] string KeyName;
String SusClientId;
};
[DYNPROPS]
Instance of SusClientId1
{
keyname="SusClientId.value";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\WindowsUpdate|SusClientId"),Dynamic,Provider("RegPropProv")]
SusClientId;
};
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("SusClientId1", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("SusClientId1"),SMS_Class_ID("CUSTOM1|SusClientId1|1.0")]
Class SusClientId1: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String SusClientId;
};

--------------------------


When saving SMS_DEF.mof, I didn't get see any apparent errors in dtaldr.log:


SMS_DEF.Mof change detected SMS_INVENTORY_DATA_LOADER 6348 (0x18CC)
Connected to SQL; waiting for Hinv action ID... SMS_INVENTORY_DATA_LOADER
6348 (0x18CC)
Done with wait for Hinv action ID. SMS_INVENTORY_DATA_LOADER 6348 (0x18CC)
Start of cimv2\sms-to-policy conversion SMS_INVENTORY_DATA_LOADER 6348
(0x18CC)
Resetting SMS_Report qualifier to FALSE on all classes and properties in
cimv2\sms namespace SMS_INVENTORY_DATA_LOADER 6348 (0x18CC)
Running MOFCOMP on C:\SMS\inboxes\clifiles.src\hinv\sms_def.mof
SMS_INVENTORY_DATA_LOADER 6348 (0x18CC)
MOF backed up to C:\SMS\data\hinvarchive\sms_def.mof.bak
SMS_INVENTORY_DATA_LOADER 6348 (0x18CC)
Warning: cannot get SMS_Class_ID of SMS_Win32ProviderEx
SMS_INVENTORY_DATA_LOADER 6348 (0x18CC)
End of cimv2\sms-to-policy conversion; returning 0x0
SMS_INVENTORY_DATA_LOADER 6348 (0x18CC)


After this, however, I cannot see any way to query this class nor does it
appear in the Resource Explorer.

The SMS server's application log is showing entries of Event ID: 63 & 5603
(WinMgmt) with the warnings below:

---------Event ID 5603 ------------
A provider, MS_VIEW_INSTANCE_PROVIDER, has been registered in the WMI
namespace, root\cimv2, but did not specify the HostingModel property. This
provider will be run using the LocalSystem account. This account is
privileged and the provider may cause a security violation if it does not
correctly impersonate user requests. Ensure that provider has been reviewed
for security behavior and update the HostingModel property of the provider
registration to an account with the least privileges possible for the
required functionality.

----------Event ID 63 -------------
A provider, SMS_CIMV2_EX, has been registered in the WMI namespace,
root\cimv2\SMS, to use the LocalSystem account. This account is privileged
and the provider may cause a security violation if it does not correctly
impersonate user requests.

----------Event ID 63 -------------
A provider, SMS_CIMLD_EX, has been registered in the WMI namespace,
root\cimv2\SMS, to use the LocalSystem account. This account is privileged
and the provider may cause a security violation if it does not correctly
impersonate user requests.

---------Event ID 5603 ------------
A provider, SMS_CIMP, has been registered in the WMI namespace,
root\cimv2\SMS, but did not specify the HostingModel property. This
provider will be run using the LocalSystem account. This account is
privileged and the provider may cause a security violation if it does not
correctly impersonate user requests. Ensure that provider has been reviewed
for security behavior and update the HostingModel property of the provider
registration to an account with the least privileges possible for the
required functionality.

---------Event ID 5603 ------------
A provider, RegProv, has been registered in the WMI namespace, root\cimv2,
but did not specify the HostingModel property. This provider will be run
using the LocalSystem account. This account is privileged and the provider
may cause a security violation if it does not correctly impersonate user
requests. Ensure that provider has been reviewed for security behavior and
update the HostingModel property of the provider registration to an account
with the least privileges possible for the required functionality.

---------Event ID 5603 ------------
A provider, RegPropProv, has been registered in the WMI namespace,
root\cimv2, but did not specify the HostingModel property. This provider
will be run using the LocalSystem account. This account is privileged and
the provider may cause a security violation if it does not correctly
impersonate user requests. Ensure that provider has been reviewed for
security behavior and update the HostingModel property of the provider
registration to an account with the least privileges possible for the
required functionality.
---------Event ID 5603 ------------
A provider, AAInstProv, has been registered in the WMI namespace,
root\cimv2\SMS, but did not specify the HostingModel property. This
provider will be run using the LocalSystem account. This account is
privileged and the provider may cause a security violation if it does not
correctly impersonate user requests. Ensure that provider has been reviewed
for security behavior and update the HostingModel property of the provider
registration to an account with the least privileges possible for the
required functionality.
---------------------------------


I am at a loss as to what the cause for this may be and how to resolve it
but would appreciate any advice from those who may have experience in this
area. Thanks.


"Sherry Kissinger [MVP]" <SherryKis...@discussions.microsoft.com>
wrote in message news:4E3D8683-764B-425A...@microsoft.com...

Tom Watson

unread,
Dec 15, 2009, 4:59:01 AM12/15/09
to
One thing you mentioned is that you ran MOFCOMP on SMS_DEF.MOF. However, you
should only need to MOFCOMP the addition. Try doing that instead on a client.

Also, if you are looking for somewhere to troubleshoot, the
InventoryAgent.log file contains all the classes its actually reporting from
the client.

Regards,
Tom Watson

"Barkley Bees" wrote:

> .
>

Barkley Bees

unread,
Dec 15, 2009, 10:21:16 AM12/15/09
to
Thanks Tom, I found the following in the InventoryAgent.log:

---------------------------------------------------------
<![LOG[Collection: Namespace = \\.\root\cimv2; Query = SELECT __CLASS,
__PATH, __RELPATH, KeyName, SusClientId FROM SusClientId1; Timeout = 600
secs.]LOG]!><time="17:04:34.796+000" date="12-15-2009"
component="InventoryAgent" context="" type="1" thread="7296"
file="collectiontask.cpp:330">
---------------------------------------------------------
So it looks like it is attempting to in grab the information but I can't
seem to find how to out any data from SMS.

"Tom Watson" <TomW...@discussions.microsoft.com> wrote in message

news:E1C2FAFA-5C8E-4769...@microsoft.com...

Sherry Kissinger [MVP]

unread,
Dec 15, 2009, 7:03:01 PM12/15/09
to

As long as the very next line following the line you mention below doesn't
say "Does not Exist Out" inside of it, then...

Based on your mof edit, in general (in some cases, it's not true, but it's
only 2 I know of), the view will be based on what you had put in groupname,
SMS_Group_Name("SusClientId1")

Create a quick'n'dirty report like...


select * from v_gs_susclientid10 (custom views will invariably add a 0 to
the end)

and see what you get.

"Barkley Bees" wrote:

> .
>

Barkley Bees

unread,
Dec 15, 2009, 8:40:17 PM12/15/09
to
I thought I was home free at first but when I created a query the only
system that showed up was the SMS server itself. Then I checked a client
system's InventoryAgent.log (which is what I should have been doing all
along...d'oh) and found the following:

<![LOG[Collection: Class "SusClientId1" does not exist
out.]LOG]!><time="13:03:53.736+000" date="12-15-2009"
component="InventoryAgent" context="" type="2" thread="3312"
file="collectiontask.cpp:482">


Sigh... I can see that this class exists in wmi on the SMS server but I
assume that this has not been passed on to the client machines. I had
assumed that once I edited the sms_def.mof and it was compiled that this
class information would get passed on tothe clients during their next
inventory but it appears not to be the case. What should I be doing so that
each client has this class as well? Thanks Sherry!


"Sherry Kissinger [MVP]" <SherryKis...@discussions.microsoft.com>
wrote in message news:F942977A-5E78-4008...@microsoft.com...

Barkley Bees

unread,
Dec 16, 2009, 12:02:11 AM12/16/09
to
After some reading I see that I must, as suspected, mofcomp the clients
using the sms_def.mof with the new class included.
I will create a package for this and test it on some test clients. My
question then becomes, should I be mofcomp-ing the full "sms_def.mof" on the
clients or should I create a mini.mof to include only my new class? Is it
safe to run mofcomp the full sms_def.mof on the client?

I am thinking to use this command line for the SMS package:
"mofcomp -AUTORECOVER sms_def.mof"

"Barkley Bees" <bark...@nomail.com> wrote in message
news:uMJH%23CffK...@TK2MSFTNGP05.phx.gbl...

Barkley Bees

unread,
Dec 16, 2009, 12:30:21 AM12/16/09
to
Another update (apologies for the continual posts). I have performed the
"mofcomp -AUTORECOVER sms_def.mof" on a test client and it now reports the
new class (SusClientId1) correctly after a hardware inventory. That said,
the test client's Application Event log also shows the same WinMgmt errors
(Event ID: 5603 and 63) that I mentioned earlier in this thread.

Needless to say I am a more than a little apprehensive about doing this on
all our client systems as I don't know (despite researching) the possible
impact this may have on the systems. Has anyone seen these types of errors
after mofcomp-ing the sms_def.mof?

"Barkley Bees" <bark...@nomail.com> wrote in message

news:OCkAwzgf...@TK2MSFTNGP02.phx.gbl...

Sherry Kissinger [MVP]

unread,
Dec 16, 2009, 1:33:02 PM12/16/09
to
99% of the time, you do not need to mofcomp the entire sms_def.mof on your
sms2003 clients.

Just save out the bottom section (your new stuff) into a separate mof file;
and ship that to your clients.

I used a mini.mof concept back in my sms2003 days. look it up if you want
to try it.

The easy answer is to upgrade your site to ConfigMgr07, and your clients
too. Then you'll never have to mofcomp again.

Barkley Bees

unread,
Dec 30, 2009, 7:19:48 AM12/30/09
to
Thank you for your advice Sherry. I have taken the safe route and opted not
to go ahead with editing the sms_def.mof on our production sms server and
will be planning to upgrade to ConfigMgr2007 early next year.
That said, I found a quick and easy way to scan the specific registry values
of online clients using a tool I have been using for many years. I had not
noticed they introduced remote registry scanning in a recent version.
Perhaps some of you are familiar with it:
http://softperfect.com/products/networkscanner/
....very handy and free tool and recommend it.

Happy holidays!

"Sherry Kissinger [MVP]" <SherryKis...@discussions.microsoft.com>
wrote in message news:3BEE4B51-7767-4F9C...@microsoft.com...

0 new messages