How to Build an Exchange Server Test Environment

Every time a new Exchange Server update is released the topic of test environments is discussed. Naturally we always recommend testing updates before deploying them in production, but that advice tends to result in more questions such as “how should I build a test environment?” and “what should I actually test?”.

How to Build a Test Environment for Exchange Server

Let’s start with the first part, how to actually build the test environment. The challenge here is to create a test environment that is a reasonably close representation of your production environment, without incurring a very large cost.

Hosting the Test Environment

First you need somewhere to host it. Organizations with spare servers or virtual capacity can use those to host the test environment. Others may need to invest is some new hardware. Even a small IT budget should be able to fit in a small hardware purchase such as Jeff’s Hyper-V server for $1000 USD. If not, then perhaps you’re able to budget for a 16gb laptop or desktop and squeeze a couple of VMs into that. I’ve run a DC and 2x Exchange 2013 servers on systems like that before. SSD storage helps a lot.

There are also cloud options such as Amazon Web Services and Microsoft Azure. These can work for a test environment where you aren’t concerned about support (Exchange 2013 is supported on Azure now but within very specific guidelines if you’re running it for production). Just be very careful not to incur an unexpectedly high bill from using them. Honestly for a test environment I think a low cost hardware server will be better value in the long run.

Installing Active Directory and Exchange Server

You could host your test systems in your production Active Directory forest, but that means you have nowhere to test things like schema updates without risking your production environment.

A separate standalone environment is the lowest risk. However, this also means you may need to install additional VMs to host any important third party systems that integrate with your Exchange servers.

If you’ve inherited an AD/Exchange environment to maintain and have never actually set one up yourself here are some resources to get you started:

• Training videos for installing Exchange Server 2010
• Training videos for installing Exchange Server 2013

Configuring the Test Environment

You may need to make a few concessions around how you configure the test environment. If your production environment is a single Exchange server, then a single test server is obviously the way to go.

On the other hand, if your production environment is a multi-site 16 member DAG, replicating that topology in your test environment may be overkill. Instead you may opt for just a two member DAG so that you can still play with DAG features just at a smaller scale.

More importantly, any configurations or features beyond a standard Exchange installation should be replicated in the test environment. This may include things like:

• Archiving/retention policies
• Address Book Policies
• Public folders
• Transport rules
• Co-existence with other versions
• Virtual directory authentication types

This list could be very long, depending on how much configuration is in your production environment.

Using a Test Environment to Test Exchange Server Updates

Once you have a test environment in place the next piece of the puzzle is how to actually use it for testing updates. Simply running the updates is an obvious step, that will at least validate that the setup process is unlikely to cause you any issues. But what comes next?

The best advice I’ve heard on this subject came from Wes Blalock of Microsoft. To summarise as best I can:

• Think about everything that makes your environment different than a vanilla Exchange Server install, such as anti-virus products that install as a custom transport agent, or features that you’ve turned on and are using heavily.
• Don’t expect to get a perfect test plan on the first attempt. As you perform each update and find new scenarios that are impacted and need to be tested in future, update your test plan accordingly. Over time you’ll develop a highly valuable test plan that reduces the risk of upgrades in your environment substantially.

The other advice I would offer is to not rush upgrades into production. Unless there is a critical security or stability issue that the update resolves there is really no need to hurry. Give yourself the time to perform your own testing and keep up to date with any issues being reported by others as well (the comments on the release posts on the Exchange Team Blog are a good source for this, as are the TechNet forums).

What Else Would You Recommend?

Anybody who has been dealing with Exchange Server updates for a while has probably built up a good list of catches and gotchas of their own. Do you have any tips about testing Exchange Server updates to share? Leave a comment below.