Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 4)

By /

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

Introduction

In part three of this series we concluded our basic discovery of the Exchange 2003 public folder infrastructure and embarked on our mission to eradicate Public Folders in order to ease migration. In this part of the series we begin planning our implementation of the staging Exchange 2010 server and the specifications required for the target Exchange 2013 server environment.

Planning for Deployment

After examining the source environment that we’re moving from, we need to set out our plans for deployment of Exchange 2013. We’ve got a few hops to go through, and to make this migration as easy as possible we will plan for simplicity rather than creating an elaborate solution. That’s partly to keep this article on-point, but also applies to most production designs too.

Naming and Services

With many Exchange 2003 – 2010 migrations, using a namespace for coexistence is a useful recommendation as it enables you to move users across gradually to the new platform. Our migration however will not allow us to migrate from Exchange 2003 to 2013 gradually, so the benefits of keeping mailboxes on the original platform are not present.

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. We’ll also add in the appropriate name for Auto discover services, as these will become critical for clients after the migration.

Exchange 2003 Namespace Exchange 2010 / 2013 Namespaces
mail.lisajanedesigns.co.uk mail.lisajanedesigns.co.uk

autodiscover.lisajanedesigns.co.uk

Quota Limits

Big mailboxes help you ensure that you’re doing your users proud. In Office 365, users get mailboxes of 50GB, so if the investment is being made to move on-premises, then an increase in quota to an appropriate size that satisfies the needs of your users is worth considering, especially as Exchange 2013 has such low IO requirements. If you currently use a compliance or archiving solution, the move to Exchange 2013 is an ideal chance to move away from these systems as Exchange 2013 meets these requirements for most organizations.

Even if you don’t plan on granting larger quotas, be prepared to make moderate increases anyway. That’s because Exchange 2013 now accurately reports the true space users by users and factors that into quota (rather than account for it as overhead).

What we might not want however is users to begin to use those larger quotas when we move over to our stepping stone, Exchange 2010. Therefore for the interim step we will keep quota limits as they are. For the final step onto Exchange 2013, we’ll grant the users larger quotas.

Exchange 2003 Exchange 2010 Exchange 2013
Issue warning at 490MB 490MB 9.8GB
Prohibit send at 495MB 495MB 9.9GB
Prohibit send and receive at 500MB 500MB 10GB

If however you don’t want to increase quotas whilst you upgrade, you will have to normalise them for Exchange 2013. As previously mentioned, the quota limits shown to users now take into account their actual usage including any overhead. Therefore increase user’s quotas by a minimum of approximately 40%.

Mailbox Databases

Many organizations who move to Exchange 2013 can take advantage of the latest improvements in storage to ensure that we can remove reliance on backups and make best use of the space available.

Our number of databases, and disks required, will be governed by the output of the Server Sizing in the next section, but the overall parameters that determine this are based on overall architectural decisions, such as the type of disk we wish to use and whether we will use Exchange Native Protection.

Before deciding to do Exchange the way you always have done, you should consider whether taking advantage of the improvements in Exchange 2013 is worthwhile. In particular, Auto Reseed will allow us to use disks without RAID and in the event of a disk failure, re-seed the databases held on the disk to an online spare disk from another copy in then Database Availability Group. Instead of holding a single database on a disk, multiple databases can be stored per disk, which has the effect of reducing the amount of time it takes to resume full high availability.

This series is based upon use of a virtual infrastructure, which abstracts the physical disks from the Exchange Server itself. Often it makes sense to implement new physical servers alongside the virtual infrastructure, as this aids with best use of hardware in a high availability deployment.

For our series we will not make use of Exchange Native Protection, primarily to allow us to focus on the migration rather than get side-tracked with design and implementation of High Availability. We’ll instead simply use storage on our virtual infrastructure and rely on it’s backup and high availability solutions. For a real implementation a minimum of two multi-role servers, even in a highly available virtual environment has real advantages.

What we will do is define a maximum number of databases. This is because we’d like to use Exchange Standard Edition, which supports a maximum of 5 mounted databases per-server.

Exchange Server Sizing

In part 6 our series, “Planning and Migrating a small organisation from Exchange 2007 to 2013” we covered thow 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:

CPUs Cores SPECint_rate2006 score Host RAM Disks Available
2 x Intel Xeon 12 367 192GB 12 x 4TB 3.5” 7.2K RPM SAS (RAID 10)
Number of mailboxes Average Message Size Average Received Average Sent
550 147.61KB 15.25 14.94

We’ll use those figures in both the Exchange 2010 Mailbox Role Requirements Calculator and Exchange 2013 Role Requirements Calculator to determine:

  • The requirements for the single Exchange 2010 server
  • The requirements for the final Exchange 2013 deployment

When sizing the solution two important factors will determine the Exchange 2010 and 2013 factors, both of which must be taken into account when using the calculator:

  • Both will not have high availability and instead will use our existing backup solution, Veeam.
  • The Exchange 2010 environment will use the same quota requirements as the source system
  • The Exchange 2013 environment will provide new quota limits of 10GB per user.

This results in two configurations from the calculator, one for Exchange 2010 and one for Exchange 2013.

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.

Exchange 2010 Specifications

Virtual CPU RAM OS Disk Pagefile Disk Physical disks required Database virtual disks Log virtual disks Restore LUN
2 x vCPU 8GB 80GB 10GB 4 x 4TB 5 x 112GB 5 x 22GB 1 x 124GB

Exchange 2013 Specifications

Virtual CPU RAM OS Disk Pagefile Disk Physical disks required Database virtual disks Log virtual disks Restore LUN
2 x vCPU 24GB 100GB 29GB 8 x 4TB 5 x 1707GB 5 x 27GB 1 x 1246GB

As you will see, the requirements for Exchange 2013 are significantly higher than Exchange 2010 – this is partly because we’ve increased quotas by over 20 times, but also because Exchange 2013 has higher CPU and RAM requirements.

This results in temporary usage across the virtual environment of 4 x CPU cores, 32GB RAM, 10TB of virtual storage, however after the migration the resources used by Exchange 2010 can be reclaimed.

Summary

In this part of the series we’ve been able to define the requirements for the Exchange 2010 staging platform and Exchange 2013 target platform. In the next part of this series we’ll move onto getting the environment ready.

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

About The Author

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top