THE OFFICIAL BLOG OF THE SBS "DIVA"

Every month we get security updates from Mothership Redmond.  And each time, especially in the server world, we say “you need to test patches” and many times in the SBS community the question comes back “but how can I set up a test lab?”

There are a couple of ways to ensure that you can have successful patching experiences even without a test network

1.  Minimize your tweakages in SBSland.  My job here at the office is to keep this network, this server chugging.  So I only 'tweak' things that I know are SUPPORTED by the SBS support gang.  I'm actually getting tired of the SBS gang tweaking the OWA to be domain/user versus our SBS user.  If the Exchange folks in their patches and service packs want it to be domain/user and there's obviously more of them than us... I say stop tweaking.  BE STANDARD.  If you have no test network, don't change the defaults.  Microsoft tests these patches on default systems and includes external parties, ISVs and OEMs in patch testing.   

Steve Riley's blog yesterday talks about my favorite recent BE STANDARD example of Security bulletin 05-051, the patch that if you had followed third party advice on your security hardening and had messed with ACLs you ended up getting your servers and workstations messed up.

I once said on a listserve that in my space you had to have a real good reason for me to recommend not following the guidance of Mothership Redmond, Mothership Los Colinas or Mothership Shanghai.  That's SBS Dev, SBS Support, and SBS Partner Support.  You move away from their guidance and you need to start setting up your own test network.  You've just made it your responsibility to test.  It's not Redmond's anymore.  You just made it your job when you followed something not advocated and in turn, tested by support.

2.  Watch the communities.  I watch a couple of listserves like patchmanagement.org and my SBS community for issues.  You don't have to be first in applying these patches.  People like me that have test networks will report in when we see issues.

...okay so what does it take to set up a testing network?  You know it doesn't even have to be a real one, just try to virtualize as best as you can a micro version of your network.  For the consultant crowd that means tools like Action pack from the Microsoft partner program, and VMware's PtoV tool.  In mid sized companies, they will do things like breaking the mirror, patching, ensuring everything is working, and then redoing the mirror.

And what are the tools to help you keep an eye on things?  Event logs.  In a SBS network it also means I send an email out, make sure it's received.  Make a RWW connection, VPN is good to go and all the other connectivity things..including these days the Audiovox cell phone, to make sure all is well.

So bottom line... if you don't have a test network... we do.  Wait for us.  We'll tell you.  But remember the key to having consistent, good patching experiences is mainly to stay with what the Motherships say to do. And if they say “Don't mess with those ACLs”, that's exactly what I'm going to do.

I have been patching this network of mine for many years..and while I can say a few third party applications and broken a time or two [and rightfully so since they depended on insecure things], I cannot say that I've had bad experencies with Security patches.  Service Packs I won't quite lump in the same kind of “gee I love them” category because in our space they are bigger and quite honestly cause more disruption.  But security patches?  Especially not these days.  I stay with the recommended guidance and certainly don't mess with ACLs and what not.  I have a good backup.  I know that I can remove them if it's truly critical, and I know if....IF.... I have issues with them, when I call in, give the credit card number, at the end of the call if the issue is the security patch/service pack related, it's a free call.

Bottom line...staying within the boundaries of what is recommended means that I will have a good solid patching experience and happy and protected servers and workstations.