How does Hardware Inventory ACTUALLY work

[sencee]

....at a lower level.

I know most of the answers will probably very well educated guesses or workings. But,
does anyone actually know each step of the Hadware Inventory process.....what populates what, in what order etc....

for example.....does the client write directly to the DB, or is it returned to the Site Server, which does the writing?

examples like this would be good

SMS_Mof altered on Server > Server REQUESTS Client HWInv > Server Checks if mof has changed > if so, sends mof with request > client writes to database > server reads database for Res Expl.

Im particularly interested in changed mof files.....who creates what table, when is it created. Does the server create the tables when it compiles the mof before requesting HW Inv, or is the table created by the event of client trying to write to tables or properties that don't exist, so needs to be created. Does the InventoryClass and InvClassProperties, GroupMap and DataItems/DIProp tables get altered by the mof comp, and the ClassInstance_DATA/ClassInstance_HIST get created by the client ETC. Is this process different if the property reporting is true, can the server side mof comp do anything or everything. Is the mof comp actually server side. As the WMI Classes are not actually created on the server, yet I can only find logs with mofcomp enteries on the server, yet htere is no sign of the source.

I would be very much appreciate some more knowledgeable feedback on this subject. But I guess nobody could actually make sence of anything I just said....I do tend to ramble.

 

[tbrennans]

when you alter or add a new category the sms_def.mof you must recompile it on the server (every server) unless you make a "true false" change.


With the advanced client this new mof must be sent out, the clients themselves need to run Mofcomp.exe on SMS_Def.mof in order for them to be aware of any new changes to the mof, once again if you added a true or false there is no reason to do anything, but a new class would require the mof to be recompiled on every client locally. That can be done with an sms package.

This what your looking for?

 

[tbrennans]

This SMS Installer file basically copies the sms_def.mof down to the SMS 2003 advanced client, mofcomp's it and kicks a hinv. (From Rod Trent on MYITForum)

(cut and paste to a ipf)

item: Copy Local File
Source=%inst%\misc\sms_def.mof
Destination=%win%\temp\sms_def.mof
Flags=0000000001000010
end
item: Execute Program
Pathname=%win%\system32\wbem\mofcomp.exe
Command Line=%win%\temp\sms_def.mof
Flags=00001010
end
item: Delete File
Pathname=%win%\temp\sms_def.mof
end
item: Set Variable
Variable=INV_RES
Value=0
end
item: Call DLL Function
Pathname=%INST%\misc\ScanHlpr.dll
Function Name=StartHardwareInventory
Argument List=41%LOGFILE%
Return Variable=3INV_RES
Flags=00100000
end

 

[tbrennans]

and read this...great info and links

http://myitforum.techtarget.com/articles/8/view.asp?id=8629

 

[sencee]

I am only "creating a new class" as far as SMS is concerned...not WMI. My propriatory classes are installed before I even took the SMS setup disk out of its sleeve.

You shouldn't need to compile the mof file to create WMI entries on the server, as it is not the server than needs to access these classes, it is only the client.

The SMS WMI provider will build a copy of classes instances in one namespace. root\sms but this is only for the SMS_Template_Class view provider. This takes classes from any namespace and located a "view" of them in a single name space as so referencing them is always a local operation. root\cimv2 root\NJCTP root\cimv2\sms they are all "available" in root\sms but there are no instances of data as they are only references for the view provider to use when running the HWInv.

 

[tbrennans]

if they are not compiled on the client in the sms_def.mof it wont be collected. If you dont enter it on the server it wont store them.

There are 100's if not thousands of wmi entries that sms doesnt use, but if you dont tell sms to use them and create the class in the sms db it really wont show up in the db or any query you make in sms

Perhaps I'm missing what your wanting to do here.....

 

[sencee]

On the server...if you are not treating it as a client, only stores the sms_def.mof class entries in WMI root\sms::SMS_CLASS_TEMPLATE which is just a view provider.

The actual hardware linked classes aren't required on the server. I know this is the case, cause I have several classes of my own that are working 100%, and for some reason some that are not. They do not live in server//root\cimv2 which is the rooted location but they do live in client//root\cimv2.
Clients do not have a root\sms folder but do have a root\cimv2\sms folder (which is used for client temporary repsository for the client appliation.
In the server//root\sms is a an empty class deffinition called SMS_CLASS_TEMPLATE...from this...only classes specified in the sms_def.mof file exist. As I said, these are implicit to the classes that exist on the clients, but not a physically linked class, they are servered by the WMI provider which works as an ORB for the communication, so they are treated asif they were local, but actually are not, hence the name VIEW PROVIDER....the same as you have views in protected DB tables.

According to ALL Microsoft sources, unless im looking in the wrong place, there is no need to manually run a mofcomp.exe complile on the mof file on each client. As this is done in the first of the two reporting HWInvs after the policy is updated, and I cant remember which log it was in, but one on the server, reports the remote MOFCOMP execution.

Just incase anyone has jumped in at the bottom of this thread....my propriatory classes were created on the clients months ago...exist and report instances and can be queried.

What I am looking for is some residing policy or file on the client that can tell me what the client is supposed to be giving the server/DB. So i can synchronise the actions that are accuring durring hardware inv, to the hardware inv schedule to try and isolate my problem. Find out where the link is breaking down, because the serverside policy is reporting the update of the classes that I am having problems with.

And did I mention...I hate log files for network management tools....why don't they invent a better view tool or reporter to conform to standard log files...some are great...why cant they make a hetrogenius one. Actually, thats not my issue right now. I need to sort this.

 

[tbrennans]

From Jon Gilbert:

For the SMS 2003 Legacy Client, processing of the SMS_DEF.MOF remains the same. Make changes to the SMS_DEF.MOF and the Legacy client will incorporate the changes into each client's WMI by updating/creating the necessary classes and instances, etc.

For the Advanced client, things work completely different. The Adv client NEVER sees a copy of the SMS_DEF.MOF. The Adv client install modifies and creates the SMS 2003 default WMI classes needed to work with the default SMS 2003 SMS_DEF.MOF. Any new classes to the SMS_DEF.MOF will not be inventoried and changes to classes defined in the default SMS 2003 SMS_DEF.MOF will break them (they will not get reported). This is because a server-side process connected with the policy provider for Adv clients will "digest" the SMS_DEF.MOF on the server and only place the classes/attributes to report into policies.

The Adv client downloads these policies that define "what they should report" but have no information on "how to create or update" classes if they do not match what is already in WMI. <whew!>

Please feel free to ask Microsoft for feature enhancements to correct this.

The current solution is to...

(a) leave the classes defined in the default SMS 2003 SMS_DEF.MOF alone. Feel free to enable or disable reporting, but don't change the class definitions themselves. Why? Because the Adv Client will change client-side WMI class definitions back to their defaults when it repairs itself.

(b) do NOT replace the SMS 2003 SMS_DEF.MOF with the Monster MOF.
This will break reporting of classes defined in the default 2003 SMS_DEF.MOF the next time the Adv client repairs itself. See (a).
There are also new providers defined in the 2003 SMS_DEF.MOF that are important for the Adv client.

(c) surgically add class definitions you want from the Monster MOF to the default SMS_DEF.MOF. Make sure you change any classes that use the registry provider or registry instance provider so that they use the provider names defined at the top of the default 2003 SMS_DEF.MOF.
Duplicate definitions for these providers will cause issues.

(d) create a package to run MOFCOMP on Adv Clients. The package should copy your updated SMS_DEF.MOF to the client (into the %temp% folder for instance) and run "%windir%\system32\wbem\mofcomp %temp%\sms_def.mof" to update the local WMI class definitions; then have the package kick off a hardware inventory cycle (the process to kick an inventory is also different on Adv Clients - see the SMS 2003 SDK)

(e) create a collection that returns Adv Clients that have hardware inventories but where the inventories are missing your custom classes.
These clients need to be advertised the package created in (d).

 

[sencee]

cheers.
Is there anyway, from the client, (anyway, shape or form), to see what it is meant to be reporting, or at least, what it thinks it will be reporting?