JRB - Fotolia
Patches are an essential part of an Exchange admin's job because they protect Exchange Server environments from ever-changing security vulnerabilities and threats. But before applying patches and putting them into production, test them for any potential problems.
One of the best ways to test patches for problems is to create an Exchange lab and apply them there. These labs allow admins to apply and observe the patches in an environment similar to the production environment -- complete with the same configuration and add-ons -- but on a smaller scale. If a problem appears in the lab environment, admins can fix it and avoid a major incident in their full Exchange environment.
But unless you cover the right areas, a test lab will be little more than a chance to practice the install and will be useless when it comes to avoiding real issues. You must know what to check.
Your Exchange test lab checklist
The checklist doesn't cover every organization's needs to test patches, but it will help you think about the areas you need to cover when building a test environment. This may look like a long list, and you might even add more items to fit your organization's needs. But this basic set of criteria will help you catch most issues that could affect your production deployment.
- Separate Active Directory environment: Exchange is installed into the Active Directory (AD) forest, not just a server. If you build a test server in your existing forest and install the service pack, you'll actually upgrade the entire schema across the whole environment.
- Same domain and forest functional level: Unless you're testing the domain functional level and the forest functional level upgrade in preparation to apply it in production, ensure you're running AD in the same mode as your production environment.
- Same forest and domain configuration: It may sound obvious, but make sure you have a similar configuration to your production AD. If you have an empty root domain and have installed Exchange into a subdomain, you should create a similar environment. If you use a resource forest model, deploy the same type of infrastructure. If you currently have set up anything, such as a single label domain, or if you use an external domain internally (or vice versa), make sure your test environment follows this model.
- Similar user and group counts and organization unit structure: Sometimes, a patch installation can fail due to excess numbers of a certain type of object. If possible, export objects from the production environment and import relevant objects into the test AD.
- Same operating system and patch level: Administrators often find it's easier to build a test environment using the latest version of Windows Server rather than using the same version found on the production environment. For example, if you installed Exchange 2010 onto Windows Server 2008, it might be tempting to build your lab on Windows Server 2012 or Windows Server 2008 R2 instead. Unless you're testing an OS migration, keep the same versions of the OS.
- Walk through the same environment history: It isn't always possible, but it's often better if you can walk through the same steps the production environment took. Although an import of AD data can mimic this, nothing beats starting with the same Exchange 5.5 environment your production environment began with and upgrading it through the same versions. Ideally, you'll inherit the same issues or unusual configuration your current environment has.
- Representative Exchange installation and configuration: If you have tens of servers, it might not be practical to install the same amount into a test environment. You should look to deploy servers with the same configuration, such as installation and database locations, and with the same environment layout. If you currently separate roles, don't build your test environment with multi-role servers. If you have High Availability configured in the production environment, ensure you configure the same features in test.
- Same Exchange patch level: This is a no-brainer if you're patching. However, it's easy to forget to put the same update rollups on if you're building a test environment.
- Same versions of third-party products and configuration: The one area many organizations encounter issues with is the third-party software that integrates with Exchange. This includes systems such as fax software, signature software, mobile device management, load balancers and spam filtering.
- Representative clients, including client-side add-ins: If you aren't testing with the same devices your users have, you haven't done proper testing. Some patches have been known to break certain versions of Outlook connecting to Exchange, so keep the same client software and patch levels available as you test patches.
- Read the release notes: Many people forget to read the release notes published with each service pack or update. These often contain critical information, such as new features that must be configured or issues discovered after the final patch build that require additional steps. Carefully read these release notes.
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 two in a series on the importance of testing patches before deploying them in your Exchange environment. Click here for part one, which covers how perfect patches can spell disaster and how test labs can catch problems.