In the past month or so, I have seen some alarming trends with regards to patching Exchange. I’ve seen customers who don’t think patching is necessary at all. I’ve seen customers who were so inconsistent that no two servers had the same Service Pack level or Update Rollup applied. I’ve seen customers who only wanted to patch Exchange once a year, missed their last interval, and are now running on an unsupported version and didn’t even realize it. And I have seen customers who didn’t think this mess would affect their users at all. Frankly, it shocked me, since I kind of thought common sense was still a commodity valued amongst IT professionals, and Exchange admins are typically ahead of the curve.
Thinking I would just point some of these customers to current online documentation, I went looking for what I was certain would be an easy find: a current KB on TechNet talking about Exchange and best practices for patching. Surprisingly enough, I couldn’t find much past Exchange 2000 days, since it would seem that patching best practices are such common knowledge that they don’t need documentation! But since my own experiences with my customers seems to indicate something else entirely, I’ve decided to share a set of best practices for Exchange patching below.
The following best practices apply equally to all currently supported versions of Exchange; even 2003 though by the time you are reading this, Exchange 2003 may be completely out of support. It won’t turn into a pumpkin on 2014-04-14, but you won’t be getting any more patches from Microsoft for it. It would be good for you to get it as up to date as you possibly can. It would be even better for you to get off that dinosaur and onto a supported version.
Exchange Major Versions
Within an Exchange organization, different versions of Exchange can coexist, but servers within the same site, or performing the same role(s) should be on the same major version where possible.
Exchange Service Packs
All Exchange servers, regardless of major version, should be on the latest service pack available for the specific version. All servers of the same major version should be on the same service pack.
Exchange Update Rollups
All Exchange servers, regardless of major version and service pack, should be on the latest update rollup.
CAS Servers
All CAS servers should be on the same major version, service pack, update rollup, and running all the same hotfixes and updates. Clients can use different CAS servers depending on site and need, and servers running different code levels may provide inconsistent results to clients. This can result in intermittent issues that will be very difficult to troubleshoot.
CAS Servers in the same site
All CAS servers in the same site running the same major version must be on the same service pack, update rollup, and have all the same hotfixes and patches deployed. In the same site, any CAS server may service requests from clients, so it is essential that all servers on the same major version be code identical. You should have all CAS servers in the same site on the same major version as well to ensure that all features and functionality are available to all users, regardless of which CAS server processes a request from the client.
DAG Members
All members of a DAG must be code identical, meaning on the same major version, service pack, update rollup, and with all the same hotfixes and security patched deployed. There should be no difference between them at all.
Patching order
Patch servers from the outside in, meaning in this order. For Exchange 2010
- Edge Transport
- CAS
- Hub Transport
- Mailbox
- UM
For Exchange 2013, the list is similar though slightly shorter.
- Edge Transport
- CAS
- Mailbox
- UM
If you have some best practices of your own to share, please leave a comment and let us all know what works for you. I’d love to pick up a tip or two from our readers, as you are a wealth of knowledge. Here’s your chance to share!
The post Best Practices for Patching Exchange appeared first on Email management, storage and security for business email admins.
