Well, it's almost Patch Tuesday again. Are you ready to apply and test them? It's one of the most important things you can do to maintain the security and availability of your SQL Servers. Remember Slammer? The patch for that was months old, but hadn't been widely applied.
Keeping up with patches used to be a time consuming, hit-and-miss sort of affair. By scheduling a regular monthly patch release, Microsoft has provided the predictability that many organizations need to manage and keep up with the patching process. There isn't really an excuse any more for not having some sort of regularly scheduled patch deployment and testing process.
We happen to use Windows Server Update Services (WSUS) to authorize and deploy patches in our environment. We push the patches through QA and test environments before pushing them to pilot groups then the rest of the enterprise. It's a pretty decent system and has served us well.
Testing the patches is critical, because they do occasionally cause production outages of their own. We had to back one out of production a couple of months ago because it affected the communication between one of our Windows applications and its WCF service. Of course, since we're not perfect, the same patch made it back into test last month, but we were able to get it backed out before it made it through to production again (it had been mistakenly re-authorized in WSUS). We'll have to really watch out this month: the only thing more embarrassing than getting caught by the same mistake twice is getting caught by it three times. Three strikes, and you're out, right?
Just to help get things rolling, this is the schedule we use for applying Microsoft's monthly patches. Just place the Microsoft release on the second Tuesday then testing and production rollouts fall right in place.
Keeping up with patches used to be a time consuming, hit-and-miss sort of affair. By scheduling a regular monthly patch release, Microsoft has provided the predictability that many organizations need to manage and keep up with the patching process. There isn't really an excuse any more for not having some sort of regularly scheduled patch deployment and testing process.
We happen to use Windows Server Update Services (WSUS) to authorize and deploy patches in our environment. We push the patches through QA and test environments before pushing them to pilot groups then the rest of the enterprise. It's a pretty decent system and has served us well.
Testing the patches is critical, because they do occasionally cause production outages of their own. We had to back one out of production a couple of months ago because it affected the communication between one of our Windows applications and its WCF service. Of course, since we're not perfect, the same patch made it back into test last month, but we were able to get it backed out before it made it through to production again (it had been mistakenly re-authorized in WSUS). We'll have to really watch out this month: the only thing more embarrassing than getting caught by the same mistake twice is getting caught by it three times. Three strikes, and you're out, right?
Just to help get things rolling, this is the schedule we use for applying Microsoft's monthly patches. Just place the Microsoft release on the second Tuesday then testing and production rollouts fall right in place.
This is based on an Excel Template by Vertex42
No comments:
Post a Comment