Three essential steps for preparing to migrate to Exchange 2013
A comprehensive collection of articles, videos and more, hand-picked by our editors
Preparing for a migration to Exchange Server 2013 is no small feat. There are a number of tasks you must complete...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
before you can even begin installing the Exchange 2013 pieces. We'll cover some of the most important tasks you'll have to complete before you can bring an Exchange Server 2013 Client Access Server into an Exchange 2010 environment.
Essential task #1: Install the correct service packs.
Make sure existing Exchange Servers are running the correct service pack level before migrating to Exchange 2013. All of your Exchange 2010 servers will need to be running SP3 for Exchange.
If your Exchange Server organization contains multiple Active Directory sites, you must apply the service pack to all the Exchange servers in the Internet-facing site first. Once that's done, you can begin applying the service pack to internal sites.
After your Exchange Server 2010 machines have been upgraded to the correct service pack version, you'll need to download Cumulative Update 2 for Exchange Server 2013. This update is necessary for Exchange Server 2010 and Exchange Server 2013 to coexist. You should be able to install the cumulative update without first installing Exchange Server 2013.
Essential task #2: Prepare the Active Directory.
Next you'll need to update Active Directory before migrating to Exchange 2013. To do so, you'll need administrative rights at the forest level and at the domain level. The account you use will also need Schema Admin permissions.
It's technically possible to skip the Active Directory preparation because Exchange Server setup will detect whether AD is ready and, assuming you have the correct permissions, will automatically prepare it. However, many organizations prefer to prepare the Active Directory ahead of time. Sometimes this is done to reduce the amount of time it takes to deploy the first Exchange 2013 server; it's more often because the Exchange admin lacks the appropriate permissions to modify the Active Directory schema. Microsoft provides instructions for updating AD.
Essential task #3: Set up a temporary Exchange Server.
I recommend setting up a temporary virtual machine (VM) to use for your first Exchange Server 2013 deployment. This one isn't an official Microsoft best practice, but it is something I strongly suggest. In most cases, this should be done as an alternative to deploying Exchange Server 2013 to a production box or VM.
Most production Exchange Server deployments -- except for those in very small organizations -- separate the Client Access Server role and the Mailbox Server role. That way, the Client Access Server acts as a buffer to prevent user traffic from reaching mailbox servers directly, thereby improving security.
The problem with this is that Microsoft made major architectural changes to the Client Access Server role in Exchange Server 2013; the CAS is now lightweight and offers extremely limited functionality. In fact, there are really only three things an Exchange Server 2013 Client Access Server can do: it can authenticate requests, redirect requests and proxy requests. The Client Access Server does not natively perform any data processing.
The reason why this is a problem is because the Mailbox Server role handles all data processing in Exchange Server 2013, including the execution of remote PowerShell cmdlets. Therefore, a lone Exchange 2013 Client Access Server is completely powerless to do anything. It totally depends on a back-end Mailbox Server to perform basic functionalities. I've never tried it myself, but some say you can't even configure a lone Exchange 2013 Client Access Server due to the lack of remote PowerShell support.
This is why it's important to set up a temporary Exchange 2013 server on a VM. The first Exchange 2013 server you bring into an Exchange 2010 organization must contain both the Client Access Server and the Mailbox Server roles. This is obviously not a desirable configuration for organizations that want to separate these roles. So, you'll need to deploy a temporary Exchange 2013 server containing both server roles. Once the server is in place, you can bring other Exchange 2013 servers online that are running just the Client Access Server role or just the Mailbox Server role. When you're done, simply remove Exchange Server from your temporary VM.
Essential task #4: Acquire the necessary certificates.
The final step before installing your first Exchange 2013 server is to evaluate your certificate requirements and acquire any necessary certificates.
Depending on your namespace requirements and what types of certificates you currently use, it may be possible to reuse the certificates you already have in place. Often new certificates are required. This is especially true for organizations using something other than Subject Alternate Name certificates or wildcard certificates.
If your organization still has Exchange Server 2007 servers, you'll most likely need new certificates due to legacy namespace requirements. Many administrators find it easier to migrate Exchange 2007 servers to Exchange 2010 before bringing Exchange 2013 into the organization, than to try establishing coexistence between three different versions of Exchange Server.
About the author:
Brien Posey is an eight-time Microsoft MVP for his work with Windows Server, IIS, Exchange Server and file system storage technologies. Brien has served as CIO for a nationwide chain of hospitals and health care facilities and was once responsible for IT operations at Fort Knox. He has also served as a network administrator for some of the nation's largest insurance companies.