SMS 2003 SP3 upgrade and custom MOF classes
Have you added several custom classes to sms_def.mof (perhaps from the Monster)? or use a Mini.mof? Planning on upgrading your sms servers from SP2 to SP3?
One trick I learned for my last upgrade (SP1 to SP2), was to pre-edit the sms_def.mof in the setup folder. Assuming you've extracted the files from the SP3 update into folders/files, the default sms_def.mof is contained in \smssetup\inboxes\clifiles.src\hinv
Since I'm planning on implementing the Asset Management piece right away, the process I used for SP1 to SP2 will have to change a bit for the SP2 to SP3 update; but not by much. What I'm planning to do to minimize the # of edits/steps I have to do to get my customizations back:
-
Compare my production sms_def.mof to the one in the setup folder, and changed all the FALSE in the default to TRUE (that I have in production). If you have customizations or just the #pragma include for a mini-mof; don't add that yet. Test the modified .mof in your lab (you have a SMS2003 lab, right? Ok, if not; just keep a backup of the original sms_def.mof from SP3 somewhere for paranoia reasons)
-
Put a copy of the current production sms_def.mof, (and if you use it, the mini.mof) somewhere in the SP3 folder structure (again, just for paranoia, so you have a copy somewhere safe)
-
From my Central, send the entire sp3 folder structure to all sites as a package (so I have it local on each server when I need it).
-
When upgrading each primary site (secondaries aren't that relevant to me for sms_def.mof, since I have no legacy clients), as soon as I'm comfortable the upgrade is complete, IIS/MP is working, and no errors in Site Status, add back to sms_def.mof the #pragma include statement; or if you do not use the pragma include/mini mof; add back your custom classes.
-
That's it. just fyi, The reason I don't put the #pragma include in first (in the setup folder version), is because I did do that in the lab test; and all the new asset classes added themselves after the #pragma include. It would have worked just fine that way, but it just didn't look neat and tidy to me. I wanted all the Microsoft classes first, and my customizations last in sms_def.mof. So it was really just my OCD (obsessive-compulsive) tendencies... you could add them in step 1 and not have to edit the sms_def.mof post-install at all.
PS: The above is just what I'm *thinking* I'll do in production. This is so far only in the lab environment. And I just noticed my lab XP workstations aren't reporting the ConsoleUser class. The server is (and there is data in WMI on the server), but on the xp workstations, that data simply isn't there in WMI, so there is nothing to report. So my process above might just have a critical flaw.
Basically.... test, test, test yourself!