SMS 2003 check for specific registry entry?

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:

> Thank you for the feedback Sherry. I followed the below:
> http://scug.dk/blogs/configurationma...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\\SOFTWAR E\\Microsoft\\Windows\\CurrentVersion\\WindowsUpda te|SusClientId"),Dynamic,Provider("RegPropProv")]
> SusClientId;
> };
> #pragma namespace ("\\\\.\\root\\cimv2\\SMS")
> #pragma deleteclass("SusClientId1", NOFAIL)
> [SMS_Report(TRUE),SMS_Group_Name("SusClientId1"),SM S_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]" <SherryKissingerMVP@discussions.microsoft.com>
> wrote in message news:4E3D8683-764B-425A-9504-ECCC995816F9@microsoft.com...
> > 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:
> >
> >> 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/configurationma...inventory.aspx
> >>
> >>
> >> "Tom Watson" <TomWatson@discussions.microsoft.com> wrote in message
> >> news:6F9F8DD8-87C9-42E1-8705-471E41594D29@microsoft.com...
> >> > You could try :-
> >> >
> >> > http://myitforum.com/cs2/blogs/tom_w...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:
> >> >
> >> >> 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.
> >> >>
>
>
> .
>

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.

You could try :-

http://myitforum.com/cs2/blogs/tom_w...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:

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

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/configurationma...inventory.aspx


"Tom Watson" <TomWatson@discussions.microsoft.com> wrote in message
news:6F9F8DD8-87C9-42E1-8705-471E41594D29@microsoft.com...
> You could try :-
>
> http://myitforum.com/cs2/blogs/tom_w...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:
>
>> 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.
>>
>>
>> .
>>

Thank you for the feedback Sherry. I followed the below:
http://scug.dk/blogs/configurationma...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\\SOFTWAR E\\Microsoft\\Windows\\CurrentVersion\\WindowsUpda te|SusClientId"),Dynamic,Provider("RegPropProv")]
SusClientId;
};
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("SusClientId1", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("SusClientId1"),SM S_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]" <SherryKissingerMVP@discussions.microsoft.com>
wrote in message news:4E3D8683-764B-425A-9504-ECCC995816F9@microsoft.com...
> 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:
>
>> 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/configurationma...inventory.aspx
>>
>>
>> "Tom Watson" <TomWatson@discussions.microsoft.com> wrote in message
>> news:6F9F8DD8-87C9-42E1-8705-471E41594D29@microsoft.com...
>> > You could try :-
>> >
>> > http://myitforum.com/cs2/blogs/tom_w...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:
>> >
>> >> 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.
>> >>

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:

> 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/configurationma...inventory.aspx
>
>
> "Tom Watson" <TomWatson@discussions.microsoft.com> wrote in message
> news:6F9F8DD8-87C9-42E1-8705-471E41594D29@microsoft.com...
> > You could try :-
> >
> > http://myitforum.com/cs2/blogs/tom_w...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:
> >
> >> 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.
> >>
> >>
> >> .
> >>
>
>
>
>
> .
>

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" <TomWatson@discussions.microsoft.com> wrote in message
news:E1C2FAFA-5C8E-4769-9A4C-A52C1E605634@microsoft.com...
> 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:
>
>> Thank you for the feedback Sherry. I followed the below:
>> http://scug.dk/blogs/configurationma...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\\SOFTWAR E\\Microsoft\\Windows\\CurrentVersion\\WindowsUpda te|SusClientId"),Dynamic,Provider("RegPropProv")]
>> SusClientId;
>> };
>> #pragma namespace ("\\\\.\\root\\cimv2\\SMS")
>> #pragma deleteclass("SusClientId1", NOFAIL)
>> [SMS_Report(TRUE),SMS_Group_Name("SusClientId1"),SM S_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]" <SherryKissingerMVP@discussions.microsoft.com>
>> wrote in message
>> news:4E3D8683-764B-425A-9504-ECCC995816F9@microsoft.com...
>> > 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:
>> >
>> >> 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/configurationma...inventory.aspx
>> >>
>> >>
>> >> "Tom Watson" <TomWatson@discussions.microsoft.com> wrote in message
>> >> news:6F9F8DD8-87C9-42E1-8705-471E41594D29@microsoft.com...
>> >> > You could try :-
>> >> >
>> >> > http://myitforum.com/cs2/blogs/tom_w...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:
>> >> >
>> >> >> 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.
>> >> >>
>>
>>
>> .
>>

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" wrote:

> 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" <barkbees@nomail.com> wrote in message
> news:OCkAwzgfKHA.2160@TK2MSFTNGP02.phx.gbl...
> > 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" <barkbees@nomail.com> wrote in message
> > news:uMJH%23CffKHA.2780@TK2MSFTNGP05.phx.gbl...
> >>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]" <SherryKissingerMVP@discussions.microsoft.com>
> >> wrote in message
> >> news:F942977A-5E78-4008-BA89-AB9D867AC053@microsoft.com...
> >>> 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:
> >>>
> >>>> 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" <TomWatson@discussions.microsoft.com> wrote in message
> >>>> news:E1C2FAFA-5C8E-4769-9A4C-A52C1E605634@microsoft.com...
> >>>> > 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:
> >>>> >
> >>>> >> Thank you for the feedback Sherry. I followed the below:
> >>>> >> http://scug.dk/blogs/configurationma...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\\SOFTWAR E\\Microsoft\\Windows\\CurrentVersion\\WindowsUpda te|SusClientId"),Dynamic,Provider("RegPropProv")]
> >>>> >> SusClientId;
> >>>> >> };
> >>>> >> #pragma namespace ("\\\\.\\root\\cimv2\\SMS")
> >>>> >> #pragma deleteclass("SusClientId1", NOFAIL)
> >>>> >> [SMS_Report(TRUE),SMS_Group_Name("SusClientId1"),SM S_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]"
> >>>> >> <SherryKissingerMVP@discussions.microsoft.com>
> >>>> >> wrote in message
> >>>> >> news:4E3D8683-764B-425A-9504-ECCC995816F9@microsoft.com...
> >>>> >> > 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:
> >>>> >> >
> >>>> >> >> Thanks for your reply Tom....was there anything wrong with the
> >>>> >> >> way I
> >>>> >> >> went

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:

> 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" <TomWatson@discussions.microsoft.com> wrote in message
> news:E1C2FAFA-5C8E-4769-9A4C-A52C1E605634@microsoft.com...
> > 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:
> >
> >> Thank you for the feedback Sherry. I followed the below:
> >> http://scug.dk/blogs/configurationma...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\\SOFTWAR E\\Microsoft\\Windows\\CurrentVersion\\WindowsUpda te|SusClientId"),Dynamic,Provider("RegPropProv")]
> >> SusClientId;
> >> };
> >> #pragma namespace ("\\\\.\\root\\cimv2\\SMS")
> >> #pragma deleteclass("SusClientId1", NOFAIL)
> >> [SMS_Report(TRUE),SMS_Group_Name("SusClientId1"),SM S_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]" <SherryKissingerMVP@discussions.microsoft.com>
> >> wrote in message
> >> news:4E3D8683-764B-425A-9504-ECCC995816F9@microsoft.com...
> >> > 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:
> >> >
> >> >> 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/configurationma...inventory.aspx
> >> >>
> >> >>
> >> >> "Tom Watson" <TomWatson@discussions.microsoft.com> wrote in message
> >> >> news:6F9F8DD8-87C9-42E1-8705-471E41594D29@microsoft.com...
> >> >> > You could try :-
> >> >> >
> >> >> > http://myitforum.com/cs2/blogs/tom_w...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:
> >> >> >
> >> >> >> 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.
> >> >> >>
> >>
> >>
> >> .
> >>
>
>
> .
>

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" <barkbees@nomail.com> wrote in message
news:OCkAwzgfKHA.2160@TK2MSFTNGP02.phx.gbl...
> 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" <barkbees@nomail.com> wrote in message
> news:uMJH%23CffKHA.2780@TK2MSFTNGP05.phx.gbl...
>>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]" <SherryKissingerMVP@discussions.microsoft.com>
>> wrote in message
>> news:F942977A-5E78-4008-BA89-AB9D867AC053@microsoft.com...
>>> 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:
>>>
>>>> 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" <TomWatson@discussions.microsoft.com> wrote in message
>>>> news:E1C2FAFA-5C8E-4769-9A4C-A52C1E605634@microsoft.com...
>>>> > 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:
>>>> >
>>>> >> Thank you for the feedback Sherry. I followed the below:
>>>> >> http://scug.dk/blogs/configurationma...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\\SOFTWAR E\\Microsoft\\Windows\\CurrentVersion\\WindowsUpda te|SusClientId"),Dynamic,Provider("RegPropProv")]
>>>> >> SusClientId;
>>>> >> };
>>>> >> #pragma namespace ("\\\\.\\root\\cimv2\\SMS")
>>>> >> #pragma deleteclass("SusClientId1", NOFAIL)
>>>> >> [SMS_Report(TRUE),SMS_Group_Name("SusClientId1"),SM S_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]"
>>>> >> <SherryKissingerMVP@discussions.microsoft.com>
>>>> >> wrote in message
>>>> >> news:4E3D8683-764B-425A-9504-ECCC995816F9@microsoft.com...
>>>> >> > 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:
>>>> >> >
>>>> >> >> 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/configurationma...inventory.aspx
>>>> >> >>
>>>> >> >>
>>>> >> >> "Tom Watson" <TomWatson@discussions.microsoft.com> wrote in
>>>> >> >> message
>>>> >> >> news:6F9F8DD8-87C9-42E1-8705-471E41594D29@microsoft.com...
>>>> >> >> > You could try :-
>>>> >> >> >
>>>> >> >> > http://myitforum.com/cs2/blogs/tom_w...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:
>>>> >> >> >
>>>> >> >> >> 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.
>>>> >> >> >>
>>>> >>
>>>> >>
>>>> >> .
>>>> >>
>>>>
>>>>
>>>> .
>>>>
>>
>>
>
>