Re: SBS 2003 Patching Guidelines

David Overton — Sat, 13 May 2006 06:07:30 GMT

Andrew,

Sorry this has taklen so long to reply to, I naturally assumed someone else might answer this, but ho hum.

The best person to talk about patching is the infamous Susan Bradly, who is a SBS MVP and known as a Diva. Before I point you off to some of her blogs on it, I thought I would answer some of your other questions about the area:

You always have to make a decision regarding patching vs risk. How much time would you spend testing the fix for blaster vs deploying it asap. Likewise, how many times do patches break machines - if they do, find out why that system needs extra care and only evaluate vs that piece of software / hardware, but deploy to the rest.

Also remember, support to fix problems as a result of a patch (or service pack) is free from Microsoft, so you can always pickup the bat phone.

Personally, I deploy all application patches from microsoft to desktops immediately via WSUS. I evaluate drivers, but rarely deploy them 'cos if they ain't broke, don't fix and I would normally be looking for drivers only when I am setting up a system or if it is causing problems.

On my server, I auto deplpy critical patches and then hand manage the rest. However I also read the security bulletins to see if there is something coming I need to worry about.

For places of info, there is no better than Susan Bradley's blog - http://msmvps.com/blogs/bradley - and you can always ask her a question. She also covered this is a webcast on the SBSShow - http://www.vladville.com/sbsshow/2005/12/sbs-show-8-patch-management-with-susan.html

ttfn

David

SBS 2003 Patching Guidelines

andrewbettany — Tue, 28 Mar 2006 09:36:45 GMT

Hi fellow SBSers

What are your generally accepted guidelines regarding patching of a SBS server?

I appreciate that this for many SME's the SBS box is their only/critical server, and that therefore we cannot allow a rogue patch to bring it down (or not install it - leaving a potential vulnerability open), however, I do get frustrated by the potential duplication of effort with regard to the "best practice" of testing the patches on a test machine first.

The general arguments are that any patch/update could potentially bring a server down, since nearly every server is unique (at least until virtualisation removes this issue), and therefore each patch should be tested prior to deployment. I can of course test the patch myself on my test SBS server, but even this machine lacks some of the LOB apps and hardware that my clients have, and therefore it is impossible to guarantee the success of an incubated patch.

Also MS do test extensively the patches before release, and therefore the problems that are encountered, tend to be on the non standard setup servers running bespoke LOB applications etc.

How can we, as a community, collaborate to make the patching process simpler? How safe, in the SBS world is it to simply switch on the update service and walk away? Do all SBSC consultants currently test each patch, or do they allow the critical patches to update your customers, and then become reactive when a problem arises?

Is there, or should there be a central depository of the issues surrounding the patches that we can turn to, to quickly see if a particular server, with a LOB, and various choices of hardware will be ok - like a matrix or database of patches/software/equipment - perhaps that the community subscribe and update?

Of course our primary concern is to keep our customers safe and protected. My concern (and dilemma) is that if we adopt established "enterprise level" best practices, which is to test/incubate/test deploy/full deploy the patches then we all duplicate a vast amount of effort when in reality we (and our customers) have the least resources to do this, and yet with many of our customers, all of our eggs are in one basket and therefore more at vulnerable to the problem.

I look forward to your comments....

Regards

Andrew in Sheffield