SCCM 2007 Not a Virtualization Candidate?

The last couple of days I’ve been in training class, taking the 6451B Planning, Deploying and Managing Microsoft System Center Configuration Manager 2007 course.

One of the first things that got mentioned, was that for larger deployments you should not run System Center Configuration Manager virtually. Of course, this caught my eye as I’m a proponent for the virtualize first “movement”.

It runs out that the reason for this is that Configuration Manager is somewhat poorly designed, as just about everything it receives from the clients in the network is placed in text based log files (inbox folder) before being processed and pumped into the back-end SQL DB. SCCM lives for and eats log files for a living.

I’m sure there are good reasons for this, especially back in the day when SCCM 2007 was developed, but in retrospect this seems to be a poor design choice. Especially since the IO intensity of writing text-based log files is high, and doesn’t scale well when you have loads of clients which SCCM 2007 supposedly is designed for in the first place.

There are ways of alleviating the strain on the machine running SCCM, like running the SQL server on a different server and running the management console on your local computer (remember a Windows server is tuned, by default, to prioritize background tasks), but the fact remains that sum of all the small write operations SCCM constantly does to your storage puts a heavy strain on it.

So, if you want to run SCCM 2007 virtualized in your environment, make sure your storage is up to the task and that you don’t saturate it by deploying what is in essence management software. Perhaps it is better to run it on a physical server with adequate local storage, but don’t blame it on virtualization, blame it on poor design in SCCM 2007.

Hopefully Configuration Manager 2012, which is currently in beta 2, behaves better when it’s released. If not, how will Microsoft defend not getting real performance when running it in Hyper-V (or any other Hypervisor).

Poor Man’s WSUS

Not that WSUS is expensive, after all it’s a “free” addon to the server you’re already running if you need it. Of course, running your own Windows Server Update Services (WSUS) infrastructure is preferable in just about every scenario except for some edge cases where bandwidth or latency issues might prevent you from syncing the updates from a central repository. Sadly, these edge cases enter the fray from time to time and I recently found myself in the middle of such a scenario. Without a WSUS infrastructure to sync from, and with very poor network connectivity how would you go about getting hold of all the Microsoft patches for a given OS and Office suite? Manually download all the patches, and then manually (or scripted) apply them to the clients?

Thankfully his is where WSUS Offline Update comes to the rescue! This clever little application, that requires no installation what so ever, helps you patch Microsoft Windows and Microsoft Office without having an active network connection.

In essence WSUS Offline Update lets you specify which operating systems and what versions of Office (and languages) you want to have patches available for in it’s repository. Run ..\wsusoffline\UpdateGenerator.exe to select versions and download them.

Poor Mans WSUS ScreenshotPoor Mans WSUS Screenshot






It then proceeds to connect to Microsoft and download all applicable patches, and service packs if you want it to, figuring out the dependencies and supersedes along the way.






Of course, this takes a while, but once it’s done you have a lovely little local repository of all the current Microsoft patches. Since WSUS Offline Update doesn’t require an installation, just unzip and run, it’s also very easy to move the repository to an external drive, USB stick or even transport it via the network. In addition it also provides built in methods for creating ISO files or place the files directly on a USB media.

When the patches have been downloaded, all you have to do is get the files transferred to the target client and run the ..\wsusoffline\client\UpdateInstaller.exe file and the patches will be applied to the system you ran it on.

It also keeps track of it’s local repository, to make sure that the next time it’s run it only downloads patches that has been released by Microsoft since the last run. All in all, this a great tool to keep in your tool belt, it sure helped me this time!