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
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. [E-Bitz – SBS MVP the Official Blog of the SBS “Diva”]