SMS_DEF.MOF Distribution

Environment: 3-tier (central site, regional primaries, local secondaries)
 
When a change is made to SMS_DEF.MOF, I replace it, by hand, on my central site and regional primaries.  The Ops book says clients will pick up the changes on their next policy refresh.
 
Do the changes need to be replicated manually to the secondaries (in sms\inboxes\clifiles.src\hinv) as well?  The Ops book is a bit ambiguous on that score.  Our secondaries are proxy MPs as well, if that affects matters.
 
This is for SMS 2003 SP2/SP3 (upgrade underway).
 
Thanks.

Subscribe, curious for the answer..

Here's my understanding...
 
You need to do a MOFCOMP on your servers to start this change process off.
 
If you're using the legacy client agent, it will automatically update the SMS_DEF.MOF on the clients.  We don't run legacy clients so I can't personally confirm this.
 
If you're using the advanced client agent you will need to create a package, program, collection and advertisement to run something like: MOFCOMP -class:forceupdate SMS_DEF.MOF to compile the new MOF file on each client computer.  You can also perform a check of your MOF file by performing: MOFCOMP -check SMS_DEF.MOF
 
You should also consider adding a class for a MOF File Revision so that you know when your revisions are compiled successfully.  Do a Google search for Monster MOF as that grouping of MOF updated has some good ideas.
 
We keep all of our MOF file edits in a separate file and only add one line to the end of our SMS_DEF.MOF file for servers and clients.  The line we add is:  #progra include ("SMS_SC.MOF"); 
For a Windows 2003 server, or remove the include for a Windows 2000 platform.  You can also use whatever filename you want in quotes.
 
We don't update our secondaries because we don't have proxy MP's and they don't have a SQL database.
 
Lastly always test, test, test!  And test some more.
 
Hope this helps a bit?
 
 
Mike.
 

You only need to do a MOFCOMP if you create a new class in your MOF file. If you are using existing class, no MOFCOMP has to be made on your client.
 
I'm not sure to understand your question about replication but if you modify your MOF on your primary, it does not has to be copied manually to the secondary site, SMS will copy it.

Here's what I found in the Planning and Deployment guide:
 

SMS uses the SMS_def.mof file that is stored in the SMS site database to create the appropriate

Advanced Client policy for Advanced Clients. Advanced Clients retrieve from management

contain site configuration information and other information that Advanced Clients need.

Just doing a little bit on reading on modifying the SMS_DEF.MOF file because we're working through this same process as well right now.  I get the impression that all SMS Site Servers (Primary and Secondary) should be updated with any edits to the SMS_DEF.MOF and in our case we should include our modularized SMS_SC.MOF file as well.
 
Probably everyone's on holidays, but anyone have any further info on this subject area?

Mike's really, really close--but I'm not sure about the #progra include.  I think he means   #pragma include ?
 
A few resources: 
Using a mini-monster file for hardware inventory with sms2003
Changing FALSE to TRUE in sms_def.mof
Compiling (mofcomp) your sms_def.mof extensions on clients
Mofcomp'ing the entire sms_def.mof + changes causes problems with WindowsUpdateAgentVersion
2003 sp3 update & custom classes
A different way to sms_def.mof
Buy an e-book
 
Feel free to ask more questions if the above articles just make it more confusing.
 

Thanks, all.  I'm not sorry I asked, but I think I've got more questions now than when I started.
A couple of answers, though:

1. we're running advanced clients only, no legacy.
   
2. we're only modifying a few entries in the OEM version of SMS_DEF.MOF, turning them on ('TRUE').
   
3. it does not appear to be true that SMS will automatically copy SMS_DEF.MOF updates from a primary site to its child secondaries, at least not into the inboxes\clifiles.src\hinv location.  We made a minor update (same thing, setting something TRUE) several months ago, manually replicated the change to our primaries, but the secondary copies never changed.

The immediate work effort here is SP3 upgrades.  SP3 modifies the .MOF file, certainly if you turn on the Asset Intelligence stuff.  Per MS requirements, we're upgrading top-down, meaning primaries get upgraded prior to secondaries.  May take a week or more to get all 90+ secondaries upgraded.  But I'm pretty confident we don't want to push an SP3 copy from a primary to a secondary in advance of the SP3 upgrade to that secondary.
 

If you are running only Advanced clients--don't worry about the secondaries' sms_def.mof.  Only legacy clients would look at that copy of sms_def.mof.  Advanced clients get their information from the policy provided by their Management Point--which is based on what is in the primary site inboxes\clifiles.src\hinv\sms_def.mof.
 
I modify the sms_def.mof probably every other month; and I never update my secondaries 'cause I have no legacy clients.  So just make your changes on the Primaries.  As you update the next primary to SP3; copy in your updated sms_def.mof. 

not sure about the #progra include.  I think he means   #pragma include ?
 
Yes, sorry #pragma include (or on Windows 2000 just the #pragma portion).  My syntax error.
 
Sherry, for SMS Secondary Sites that are configured as Proxy Management Points does the SMS_DEF.MOF need to be copied to these servers do you know?
 
 
Mike.
 
 

From my experience (I've got Secondaries that are PMPs, no SQL), no, you do not need to copy the sms_def.mof + mini.mof to them; unless you have legacy clients.

With SP3, there are slight modifications to the SMS_DEF.MOF file.  We enabled and disabled certain attributes.
Would you distribute the compiled SMS_DEF.MOF to the client workstations?

Did you add to sms_def.mof?  Or just change TRUE to FALSE (or FALSE to TRUE)?  If you've 'just' changed T/F ; to the SMS Client that is simply a policy change--there is no need to compile the sms_def.mof on your workstations at all.  Your SP3 clients know all the default classes already; and the policy generated at the server (by changing FALSE to TRUE for example in clifiles\hinv\sms_def.mof) will be picked up by your clients at their next policy refresh.  After that policy refresh, that client's next Hardware Inventory action will report as directed.

blecours763


You only need to do a MOFCOMP if you create a new class in your MOF file. If you are using existing class, no MOFCOMP has to be made on your client.

I'm not sure to understand your question about replication but if you modify your MOF on your primary, it does not has to be copied manually to the secondary site, SMS will copy it.

 
I accidentally replied to this thread, please disregard.