Tue, May 29 2007 20:45
The break fix of patching
The other day in New Orleans I talked about how I hadn’t changed my patch management strategy in 6 years. Never patch on Patch Tuesday, wait for Dead Body Wednesday and don’t install service packs until later. This “patch management” strategy is the “managed services model”. When I was speaking with an attendee (and forgive me I can’t remember who I was talking to on this) and they said they were installing patches the other day and it was a bit difficult to break them up and know what issues were caused with what patch as they were installing like 64 of them.
“64?” I said, “why so many?” And it was because they were a break fix client they said.
Bear with me here… and I don’t mean to sound like you shouldn’t be aware of the consequences of what I’m about to say, but I would like to throw this out on the table.
If a client is a break fix client, I think you do a disservice to that client to not enable automatic updates. The patching process works the best when you take patches in monthly chunks. Installing 64 patches in one afternoon, if you did have some interaction, you’d never figure out which one of the 64 patches was the one that caused the interaction.
While you could easily argue with me that turning on automatic updates on a break fix client was a disservice to that client, I think NOT enabling automatic updates on a client that you only see once a year is also a disservice.
At a minimum I think you should ensure they sign a document that indicates they know you are leaving with updates turned off and that they understand that they are accepting the risks of that setting.
So what do you think? I think if you don't see that client, that they should take the risk of automatic updates versus the risk of 64 patches in one afternoon. Patches are best consumed in little bits.
Filed under: Security