<img height="1" width="1" src="https://www.facebook.com/tr?id=1529264867168163&amp;ev=PageView &amp;noscript=1">
blog_listing_hero_img.jpg

Setting Up a Simple Exchange Server 2016 Lab

exchange-server-2016.png

The best way to learn about Exchange Server is to get hands-on with the product. And the best way to get hands-on without risking a production environment is to build your own test lab.

Sure, you might ask your employer to provide you with a test lab, but in my experience most employers will simply say no. Even if they do say yes, you’ll be sharing the environment with others in your team, which usually means less time to try things yourself, and more rules about how the environment can be used.

Having your own private test lab environment is the best approach to learning new skills in IT, and in particular Exchange Server. So how do you get started?

To begin with, decide which version of Exchange you want to learn about. The latest version right now is Exchange 2016. Even if your workplace is still running Exchange 2010 or earlier, I recommend you learn Exchange 2016 today.

At some point in the near future you’ll be migrating to either Exchange 2013, 2016, or Office 365. Exchange 2016 is very similar to Exchange 2013, close enough that you can gain an understanding of the differences by reading TechNet. And Office 365 is running an Exchange build that is closer to 2016 than 2013 in terms of features. So learning Exchange 2016 is the best way to gain a broad understanding of multiple platforms.

A Simple Exchange 2016 Scenario

When you read documents like the Preferred Architecture it’s easy to think that every Exchange deployment needs to be highly available and site resilient. But the Preferred Architecture represents just one recommendation about how to deploy Exchange 2016.

In reality, many Exchange 2016 deployments consist of just a single server. And for your test lab environment you can easily deploy a single server, and get access to most of the features of Exchange (excluding the high availability features of course) to begin learning how to perform administrative tasks.

The simple scenario that I recommend is:

  • 1 x domain controller, running Windows Server 2012 R2
  • 1 x Exchange 2016 server, running Windows Server 2012 R2
  • (Optional) 1 x Client, running Windows 10 Pro

The client is optional, because if you didn't have enough resources to run that many virtual machines you could install Outlook on the domain controller and connect to mailboxes from that computer, or just use OWA (Outlook on the web) any time you need to access a mailbox.

Hardware Requirements and Tips

Any mid- to high-end laptop or desktop computer bought within the last year should have a fast enough processor (any Intel i7 CPU would be sufficient) to run some virtual machines.

For memory, I recommend at least 16GB in your host machine. This gives you enough to allocate at least 6GB to Exchange, and then 3-4GB each to the domain controller and client machine.

Exchange servers can’t use dynamic memory, but the other virtual machines can. Even in a test lab, dynamic memory for an Exchange VM results in horrible performance, so just don’t bother trying.

For storage, an SSD drive is essential. If you have a computer with multiple drives the SSD can be used for the Exchange VM, whereas SATA drives are usually good enough for the other VMs.

I can fit a simple test lap scenario onto my laptop or desktop, but if you're looking at building dedicated computer then take a look at the guides that Exchange MVP Jeff Guillet has written for his own test lab servers.

Testing with Clients

To truly understand the impact of administrative changes you make in your Exchange test lab, you should log on with normal user accounts and connect to Exchange mailboxes with clients such as Outlook and mobile devices. Installing Outlook on the client machine, or the domain controller if necessary, is simple enough.

Mobile devices get a little trickier. Mobile devices will connect via the LAN if your DNS is configured to resolve the Exchange URLs to your local IP addresses. But you might also want to have them connect via the internet for more realism.

This brings into play several important elements of a real world Exchange 2016 deployment – namespaces, DNS, certificates, and firewalls. So I do recommend you try to get full, external access to Exchange 2016 working in your test lab at some stage. It will be a very educational exercise.

Certificates

I’ve already mentioned certificates as an important element in successful mobile connectivity. But certificates play a role in pretty much every client connection to Exchange 2016, because it is all happening over HTTPS or other secured protocols.

Though it may be tempting to try and disable certificate requirements, or just use the self-signed SSL certificate that Exchange generates, it is definitely worth your while gaining an understanding of how SSL certificates work with Exchange. You’ll be dealing with it constantly in the real world.

You can install the Certificate Services role on your domain controller and issue free certificates for Exchange from that CA, but they won’t work well for your mobile devices. Fortunately, several certificate authorities sell very inexpensive certificates, so you can buy a cheap wildcard certificate if you really need to without going to any major expense.

Test Lab Exercises

An Exchange 2016 test lab is not much use if it just sits their idle. You need to get hands-on and do real world administrative tasks with it.

I’ve already talked about a few things that you should look at, such as mobile connectivity, but here is a more detailed list of scenarios to tackle in your test lab.

  • Installing a new Exchange 2016 organization and server into an Active Directory Forest
  • Configuring client access namespaces
  • Create a certificate request, installing a certificate, and enabling the certificate
  • Achieving full client connectivity with no certificate errors or warnings
  • Moving databases to different storage paths
  • Creating a single mailbox user, and creating bulk mailbox users
  • Assigning email addresses to new and existing users automatically
  • Using PowerShell to modify multiple mailbox user’s attributes
  • Establishing inbound and outbound mail flow
  • Backing up and recovering mailbox databases
  • Upgrading the Exchange server with new Cumulative Updates
  • Granting a user access to another user’s mailbox
  • Create a Room mailbox and configure automatic calendar processing
  • Creating distribution lists, and preventing specific users from sending email to them
  • Create an admin account and grant it only the required Exchange permissions to be able to manage mailboxes

I won’t tell you how to actually do those things. You’ll find documentation and tutorials online with a few simple searches, and then become familiar with how those tasks are performed by practicing them in your lab.

What Else?

Having a test lab will open up a range of new learning possibilities for you. Always wanted to learn PowerShell? Now you have an environment to start, and not just for Exchange, you can also learn PowerShell for Active Directory, Windows Server itself, and many other features of the operating system.

You could also look at setting up a Hybrid deployment with Office 365. This gets a bit tricker if you don’t have the certificates and firewall access that Hybrid depends on, but if you can meet those requirements then definitely go ahead and grab a trial Office 365 tenant to play around with as well.

But ultimately, a test lab environment will be a very good investment of your time and money to grow your Exchange administrative skills, and improve your career.