i thought i'd point out a couple of interesting articles since the problem seems to surface on some of the listmail subscriptions i'm a part of. the first one is the neverending question... why do the active directory and exchange helper objects get installed on machines that aren't domain controllers or exchange servers?
it's simple. the push installation does it automatically. here's the article that goes into detail about the asinine method to avoid this (manual installations or remove through arp).
i included this one because it was something one of my coworkers discovered with microsoft (russ slaten to be exact). he's published a blog entry on it. here's the official article, however. basically it details how to get around (scripted or otherwise) the problem when you try to import a report, and it mercilessly tacks your cpu. basically the import object wizard can't handle large sql queries. :)
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