THE OFFICIAL BLOG OF THE SBS "DIVA"

There's a person I'm going to refer to as The “~”.  Now while I'm going to speak specifically about this one person... in reality he represents a type of a person. 

His job is to fix things.  Find things.  Get things to break.  Figure things out.  Analyze things.  Thus, he's the type of guy that would be installing Exchange 2003 Service pack 2 today.  Now.  In fact, I'm surprised he wasn't up at midnight installing it on some box somewhere.  And in fact if things go smoothly ... he might be a bit disappointed.  He and those like him actually like breaking things.   Because then they learn more about the thing they are breaking.

There's another type of person I'm going to blog about.  This person is the IT Pro.  The Consultant.  I'm going to call him The “V's“.  Now he's a bit like The “~”, but a smidge different.  You see he wants to figure things out, but he wants to ensure once he's installed something, understands it, it's reproducable in a solid manner to his clientele.  So he'll install Exchange 2003 sp2.  Document it.  And quite quickly in fact, but he's probably going to go through the dry run steps of a 'best practice for deploying Service Packs” checklist.

He'll make sure he's read the documentation, he'll make sure he's backed up the Exchange Store.  He'll understand that for his clients that depend on email, Service packs deployments on Exchange are upgrading a Jet database.  Thus he'll make sure he builds in a rollback strategy.  But he's going to to a dry run on a test machine and recreate as best as he can the steps and checklists he'll use for deploying this Service Pack.  He's then probably going to watch that box for a few days and monitor the log files and just make sure everything is as it should be.  And then he'll start rolling it out.  Mainly because his clientele are near the max of those 16 gig limits right now and they are busting at the seams.  And he'll read the documentation on how the default store goes up to 18 gigs but above that needs a manual registry adjustment.

He's also probably going to “triage“ this service pack and only deploy it to those clients who are near that 16 gig database limit.  The ones that need that registry edit.  You see he's probably already in the process of deploying SBS sp1 and he'll want to give is clients a bit of a breather on that for a bit before fully rolling this one out.

Then there's me.  And it's this personal view from my Patch Deployment Central.  It's this view that I post to this blog.  My role in my office is to not introduce risk.  My role is risk mitigator.  So I'm not going to be the one downloading the patch at midnight installing this on my box.  I'm waiting.  I'm going to first install it on my home server, again following the guidance of The “V's”, and I'm going to watch the log files.  I'm going to then pick a date in my office that it's a good time for me to deploy this.  In my office my traditional time for deployment is Friday night, after the office closes at 5 p.m.  I'm going to ensure I have a rollback plan.

And what if you don't have a home server to test this on?  What if you are a DIY admin and you only have your one SBS box?  Well, you can be rest assured of the following....

• The “~'s“ have done it and are running just fine [well it will be as soon as he installs SBS]
• The “V's“ have done it and are running just fine
• The patch has been certified for SBS boxes by Mothership Redmond and Los Colinas [there is no need to wait for a SBS only service pack]
• and soon I'll be doing it here

In my earlier post I talked about how one shouldn't patch at lunchtime.  There's a running joke that we are so confident in patching that we'll just blindly install patches before testing.  If you don't have a test machine, but only a real production one, just keep this in mind... follow the recommendations.  Have a backup.  Remember you have to have SBS sp1 on the box “before” applying this Service pack.  And honestly you really should consider a Service Pack like a near new operating system.  You don't have to be first.  You can wait for all those “~'s” and “V's”.      

Need some guidelines and ideas for Patch [and a bit of Service pack] testing?  Here's some things I've gathered up along the way...

• Identify the operating system subject to testing.
• Identify the service pack level.
• Identify the hotfixes installed on your systems (if in addition to security fixes).
• Identify critical third party applications.
• Identify third party applications that have had patching historically.
• Identify those files used in patches that may have causes issues in the past. Are the included in this current patch? Assign testing resources appropriately.
• Study the bulletin to determine if you can uninstall the patch. If not, determine if additional resources for testing or imaging need to be in place before approving the patch.
• Test the installation of the patch both manually and via your automated patch technology. Can you uninstall the patch using add/remove program or your patch tool?
• Review the processes of your line of business applications. Are they performing as expected? Attempt to replicate a production environment using imaged data. Having an exact image provides the best testing bed.
• Set up performance and monitoring tools to review your testing machines43 such as PerfMon, tools from Sysinternals and review all log files.
• Confirm the installation of the patches via registry review or other means.
• (OPTIONAL) Confirm the effectiveness of the patch using testing code.
• Follow any additional procedures your situation requires.
• Approve the patch for release.
• PREPARE BACKUPS. [Oh yeah did I say prepare backups?]

The Infraguard Technology Risk checklist also includes the following:

• When applying a patch to any system vulnerability, verify the integrity of, and test for the proper functioning of the patch
• Verify that the patch will not negatively affect or alter other system configurations
• Test patches on test beds before being released into the network
• Backup your system before applying patches
• Conduct another vulnerability test after you apply a patch
• Keep a log file of any system changes and updates
• Prioritize patches prioritized
• Disseminate patch update information among the organization's local systems administrators Add timetables to patch potential vulnerabilities
• Require that external partners deploy all non-critical patches within 30 days
• Require that external partners deploy critical patches to servers and clients within 48 hours

So if you are one of “The “~'s“, go ahead, deploy it.  The rest of us mere mortals will type up a checklist and at least make sure we have a backup in place.