Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 1)

If you would like to read the other parts in this article series please go to:

• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 2)
• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 3)
• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 4)

Planning for Deployment

For the purposes of guiding through the relevant upgrade steps in a succinct manner, we won’t be making big changes to the source and target environments.

We will migrate from a single-server Exchange 2010 server installation to a new Exchange 2013 server, in our example organization Lisa Jane Designs:

Figure 1: Our example organization

In the diagram above we’ve a single source server – LJD-E1401. This is our Exchange 2010 server and could quite easily be split roles. You can add in additional components if you need them, like Database Availability Groups. High Availability in Exchange 2013 is relatively simple compared to Exchange 2010 as concepts like the Client Access Array no longer exist – all communication is HTTPS and no affinity to a server is required. However – we’ll keep it simple in this guide.

Naming and Services

We’ll start with defining names for Exchange. Migration from Exchange 2010 to Exchange 2013 allows us to use and share HTTPS names for AutoDiscover, OWA, ActiveSync and other services. This allows for a smooth transition with minimal co-existence.

For our migration we’ll therefore plan not to use a coexistence namespace, and simply move the current HTTPS namespace across to the new platform.

Updating Exchange Server 2010

As a bare minimum, Exchange 2010 must be running Service Pack 3 before installing Exchange 2013 into the domain. Exchange 2010 SP3 is available from this URL.

For the best experience, ensure that Exchange 2010 SP3 also has the latest Update Rollup, currently Update Rollup 9 at the time of writing. This is available from this URL.

Updating Outlook Clients

Exchange 2013 supports Outlook 2007 and above on Windows, and on the Mac, Entourage 2008 Web Services edition and higher versions of Outlook for Mac.

Ideally update all supported clients to the latest version, or upgrade to Office 2013 before migrating to Exchange 2013.

All versions of Office 2013 are supported, along with Outlook 2010 Service Pack 1 with at least the November 2012 update and Outlook 2007 Service Pack 3 with at least the November 2012 update.

Outlook 2003 is not supported, and clients running it must be upgraded before moving associated mailboxes to Exchange 2013.

Exchange Server Sizing

In part 6 our series, “Planning and Migrating a small organisation from Exchange 2007 to 2013” we covered how to use the Exchange Server Role Requirement Calculator to determine the sizing required.

We will not cover the same steps here, but instead examine the inputs and associated outputs from the Calculator.

Our example environment uses Hyper-V and an underlying Storage Array. The following tables show our example environment’s available resources:

We have also collected statistics from the existing environment:

We’ll use those figures in the Exchange 2013 Role Requirements Calculator to determine the requirements for the Exchange 2013 deployment.

When sizing the solution two important factors will form design constraints:

• The solution will not have high availability and instead will use Hyper-V for high availability.
• The Exchange 2013 environment will provide quota limits of 10GB per user.

Our output from the role requirements calculator results in the following server specification:

The Virtual CPU specifies how many CPU cores should be assigned to the Virtual Machine used, as does the RAM. The OS disk will hold both Operating System Exchange install and transport databases.

The Physical Disks represents how many of the available physical disks are needed to actually support the deployment and meet requirements for performance and space. In the virtual environment, these will be presented as virtual disks and will be used for database and log files respectively.

You’ll note that we’re still splitting databases and logs. For an implementation making use of Exchange Native Protection we wouldn’t look to do this, but for an implementation in a virtual environment that takes advantage of backups this is still required. We’ve also included an additional virtual disk to use as a restore LUN.

Splitting Databases from logs ensure that in the scenario of a log disk filling up, databases will not be corrupted. By splitting databases we also ensure that losing or the corruption of a virtual disk doesn’t result in a full restore of Exchange.

Getting the servers ready for Exchange

Exchange 2013 supports Windows 2008 R2 to Windows 2012 R2. In our series we’ll use Windows 2012 R2.

Exchange 2013 Base Server

We’ll be using physical disks to support Exchange 2013 and then creating virtual disks atop our Hyper-V environment. In Hyper-V, our new VM looks like this:

Figure 2: Our Exchange 2013 server configuration

We’ll then proceed and install Windows Server 2012 R2 on the virtual machine used for Exchange 2013, then configure it with correct network settings, install the latest Windows updates and join it to our domain.

Configuring storage

Exchange 2013 expect disks – virtual or otherwise – to be formatted in a particular way to ensure best performance. To accomplish this we will need to ensure that disks are formatted with a 64KB NTFS allocation unit size.

In addition to making sure we’re using the optimum NTFS allocation unit size we will create mount points to represent the disks and their purpose:

We will then bring storage online, initialize and then format and mount the storage. We’ll by launching Computer Management, from Server Manager:

Figure 3: Accessing disk management tools

Within Server Manager, navigate to Disk Management. We will see in the upper panel the system disk, C: and the System Reserved Partition. These also display in the lower page, contained as partitions within the primary disk.

All newly added disks will typically be shown as offline. We’ll need to first change each of these disks to an online state before we prepare them. This is accomplished by right clicking each disk and simply choosing online. Perform this step, as shown below, across all new disks before proceeding:

Figure 4: Changing disks to online status

After bringing the disks online, we will now select one of the disks, right click and choose Initialize Disk:

Figure 5: Initializing disks for Exchange use

This will allow us to initialize all new disks in a single operation. We’ll ensure all disks are selected (in our case all 12 additional disks), then select GPT (GUID Partition Table), which is recommended for Exchange and supports disks sizes over 2TB, should they be required:

Figure 6: Choosing the GUID Partition Table

We’ll now create our first volume for the Page File. In our design, this is not to be located on a mount point, so we don’t need to create a folder structure to support it. We can simply right click and choose New Simple Volume:

Figure 7: Creating a new Simple Volume

The New Simple Volume Wizard will launch. We’ll be provided with the opportunity to assign our drive letter, mount in an empty folder (which we will use for the database and log volumes) or not to assign a drive letter or path. We’ll choose a drive letter, in this case, D:

Figure 8: Assigning a drive letter to our page file disk

After choosing the drive letter, we’ll then move onto formatting our first disk. It is recommended to use 64KB allocation unit sizes with Exchange.

This helps with performance, as Exchange will be reading and writing large database block sizes, large log file sizes and uses lazy commits.

Rather than break the writes into smaller, unnecessary chunks we will use the largest unit size possible. This is mirrored somewhat with Page File disks as although memory pages are 4KB in memory they may be flushed and returned in bigger chunks.

Figure 9: Selecting the correct allocation unit size and volume label

After formatting the page file volume, move straight onto our database and log volumes. We need to first create mount points, which we will create on our system drive using the values specified in the table above.

For simplicity, we have used the command line to create the mount points using the mkdir command:

Figure 10: Creating volume mount points

Next, start the process of formatting and assigning mount points to use disk, by right-clicking each individual volume and choosing New Simple Volume. We will go through the same process as the page file disk with one difference; we will specify the mount point for each disk, as shown below:

Figure 11: Assigning a new simple volume a mount point

As with the page file disk we will choose a file system type of NTFS, and specify an allocation unit size of 64KB. We’ll specify a volume label that will make it easy to identify the purpose of the volume:

Figure 12: Formatting the volume with correct 64KB allocation unit settings

After formatting each new volume, assigning a mount point and label we will see the list of volumes within Disk Management’s upper pane. You will see the benefit of specifying a label at this point, as without using drive letters to identify disks it is hard to see the purpose of each disk:

Figure 13: Examining our disk configuration

Summary

In the first part of this series we’ve defined the server specifications for the Exchange 2013 server that we’ll migrate to, then installed and configured the base operating system and disks. In the next part of this series we will complete the server configuration then install and begin configuration of Exchange Server.

If you would like to read the other parts in this article series please go to:

• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 2)
• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 3)
• Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 4)