Patching Exchange Server is critical to protect it from potential security vulnerabilities. Patches help ensure...
the environment is compatible with other Microsoft products and is fully supported. Keeping up to date with patches can't be understated because these often contain critical fixes that repair security issues or prevent possible data loss.
If you use any Exchange 2007 or Exchange 2010 version prior to Service Pack 3, you need to update as soon as possible and install subsequent update rollups. If you use Exchange 2013, the support schedule is slightly different. Simply put, you should be using one of the last two cumulative updates.
Patches aren't perfect. They sometimes contain new bugs or cause additional problems. Exchange Server is mission-critical, so it's reliable and easy when it comes to patch application. But that means that a problem with a patch can affect multiple organizations. This is why it's essential to test patches.
Testing Exchange patches before going into production can detect potential problems. It also gives you some assurance that those patches will work once they're applied. If you haven't invested the time and effort into building a test lab yet, now is the time.
When good Exchange patches go bad
It's an unwritten rule of thumb that Exchange admins should wait a few weeks after the release of a service pack, update rollup or cumulative update before they apply it. The only exception should be when the update fixes a critical security issue. Why? Exchange customers will try the patch in test labs after it's released and will find any major bugs that didn't affect beta testers.
Even if there are no issues reported in the community and the patch is known to be reliable, you still shouldn't apply it to your Exchange Servers. Your mix of third-party add-ins and any custom configuration could result in issues. For example, if you neglect to check that the signature software is compatible with the update, you may stop mail flow until the software is disabled or updated.
The importance of test labs for Exchange patches
It's a fact of life that things eventually go wrong. Some issues are unavoidable, such as an Exchange service pack crashing halfway through installation. But some problems, such as breaking integration with your Blackberry Enterprise Server, could be found before they hit production. Building a representative test environment that's set up the same as your production environment allows you to test Exchange patches with the same add-ons and configuration, but on a smaller scale.
Don't worry if you don't have identical hardware available to use in a test lab; many organizations can't do this. The most common test environments are contained within virtual environments. While this can't test areas such as firmware compatibility, it can allow for thorough testing of third-party software, the associated environment and clients.
If you're struggling to find hardware for a test environment, consider looking to the cloud. Cloud services such as Amazon Web Services and Microsoft Azure enable you to build a large virtual environment for testing, and you have to pay for it only while it's switched on.
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners. Goodman has worked extensively with Microsoft Exchange since version 5.5 and with Office 365 since its origins in Exchange Labs and Live@EDU.
This is part one in a series on the importance of testing patches before deploying them in your Exchange environment. Click here for part two, which includes a checklist of factors to consider for your test lab environment.