what was once a trivial thing to understand has become an edifice for systems management in the windows space. back when i started learning sms, wmi was completely foreign. it was used primarily to hold configuration data here and there, acting as a mini-database and largely untapped by most software vendors at the time. since its popularity has grown, so has the usage.
this is largely ostensible without spinning up wbemtest, opening cim studio, or constructing a single wmi query. if your repository corrupts, there is absolutely no recommendations at this point to remove all items from the wbem repository directory and allow wmi to recover. the ubiquitous usage almost guarantees something will break.
i suppose for that reason, wmidiag was born. download it and get to know it. while you're at it, attend the webcast if you can. alain lissoir himself is presenting... content should be great.
UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress. if you are using the v2 toolkit, PLEASE read this blog post before proceeding. here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can
Comments
Post a Comment