alphaspirit - Fotolia

Manage Learn to apply best practices and optimize your operations.

Untested Exchange patches can spell disaster

Seemingly perfect patches can cripple Exchange setups in production, but test labs can help you catch problems before they occur.

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.


Next Steps

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.

Dig Deeper on Exchange Server setup and troubleshooting

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

"If you use Exchange 2013, the support schedule is slightly different. Simply put, you should be using one of the last two cumulative updates."

I wouldn't disagree, except for the fact that I presently have a case open with MS Exchange tier 3 support, and they have plainly stated to me that once I get to a stable rollup for 2013 sp1, that unless there is a compelling security fix or feature that I need, that they recommend staying on said rollup least until the next SP is released.....

caveat: My situation is specific to coexistence with 2007 and O365....we are attempting to implement hybrid mode, and ran into all kinds of problems with 2013 CU5 and CU6.... right now we are running on CU5 with an IU to enable hybrid mode...and still having a few issues.