Planning and migrating a small organization from Exchange 2007 to 2013 (Part 5)

By /

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

Introduction

In the previous parts to this series we began our journey to migrate from Exchange 2007 to Exchange 2013, beginning with investigating what we’ve got to contend with in our existing environment.

With that valuable information, we’re now ready to look at what needs to be done next when planning the Exchange 2013 deployment. We’ll start the next two parts in this series by using the information gathered during discovery along with business inputs to define what will be required from our upgraded Exchange environment.

Planning for Deployment

High Availability, SLA and RTO/RPO

The importance of email to any organization differs, and for many email is a critical application. High Availability, Site Resilience and Exchange Native Protection features within Exchange enable an organization to ensure that email continues to function through most events; however these features come at a price and therefore might not be suitable for every organization.

When looking at which High Availability features must be deployed, you need to examine what Service Level Agreement (SLA) will be in place for the solution, and the respective Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The SLA defines how much uptime the solution is expected to have, and might be defined for example as 99.9% which allows for just over 8 hours of downtime a year. The RTO and RPO are closely related to the SLA and define the expected time to recover the service in the event of a catastrophic failure and the earliest point at which it is permissible to recover from.

The example organization we’re using for this article, Exchange Labs keeps things simple (partly so we can build a single-node Exchange server and focus on the migration aspects) and has a fairly relaxed SLA of 99%, with an RTO and RPO of 12 hours. Exchange Labs has already covered their requirements using virtualization products, providing high-availability at the Hypervisor level, and Exchange-aware backup and replication product to provide a consistent, verified backup of their entire environment to an off-site location, including Exchange and Active Directory, every 6 hours. We can also be confident that the Exchange 2013 Servicing Model, requiring updates at least every 6 months will allow us to stay with this SLA.

We’ll record this information below along with the decisions we make based on this.

SLA 99%
RTO 12 hours
RPO 12 hours
Exchange HA Required No
Alternative HA Solution Yes

Table 1

Naming, Services and Coexistence

Wherever possible keep things simple. This applies particularly to Exchange service naming. An Exchange 2007 deployment typically has at least two service names the end-user will be able to see. Firstly the HTTP name, such as mail.exchangelabs.co.uk used by OWA, ActiveSync, Web Services and others, the HTTP name for AutoDiscover; and the Exchange RPC/MAPI name, which is typically the Exchange Server name itself.

Some organizations do have more complicated naming structures, even within single sites. In Exchange 2007, a common misconfiguration may be to use different names for HTTP services internally and externally unnecessarily – for example mail.exchangelabs.co.uk externally, but mail.exchangelabs.local internally. By using Split DNS, or PinPoint DNS, we can avoid unnecessary HTTP names.

For co-existence with Exchange 2007 we will need a legacy name for Exchange 2007. This is used, for example, by OWA and Web Services clients to connect to Exchange 2007 after primary services using mail.exchangelabs.co.uk are switched to Exchange 2013.

You will need co-existence if you aren’t planning on migrating all users at once. If you are planning on migrating all users in a “big bang” migration though, you won’t need to worry about a legacy namespace.

The benefits of a legacy namespace mean you can perform a small pilot and/or user acceptance testing before moving all users, and if you aren’t able to upgrade all clients to the required versions for Exchange 2013, begin your migration in the interim. We will pilot Exchange 2013 before migrating remaining users and therefore configure co-existence.

Services that don’t use a Legacy name include ActiveSync, IMAP, POP3 and client SMTP. This is because these clients don’t support redirection as well as OWA or re-AutoDiscover methods as well as Outlook and Mac Outlook. Therefore when the primary name for Exchange is moved over, Exchange 2013 will handle these legacy clients and proxy the connection to Exchange 2007 without affecting users.

Based on the information we recorded about current HTTP names with Exchange 2007 in part two of this series, we’ll use the following names for Exchange 2013 and our legacy environment. The legacy name used for Exchange 2007 is often suggested by Microsoft and therefore used here – however you can use any name you prefer, as long as it is different from the name you’ll use for Exchange 2013.

Exchange 2013 HTTP Name AutoDiscover HTTP Name Exchange 2007 Legacy   Coexistence Name POP3/IMAP/SMTP Name
mail.exchangelabs.co.uk autodiscover.exchangelabs.co.uk legacy.exchangelabs.co.uk mail.exchangelabs.co.uk

Table 2

We’ll use the above information later on when we generate a new SSL certificate to be used by Exchange 2013, and to be used on the Exchange 2007 server. You’ll notice we don’t need the Exchange Server names on the certificate – we only need the service names. Clients should not need to know the actual name of the Exchange 2013 servers themselves.

Quota Limits and Numbers of Mailboxes

You’ll also need to decide on what your quota limits will be across your organization. This is an important decision, because it will directly affect how much storage you’ll need to ensure you’ve got sufficient space for your mailboxes.

Even if you’re planning on using the same quota limits as you’re already got in place, you’ll still need to use these as the basis of storage sizing rather than looking at the storage currently used. That’s because Exchange 2007 uses single instance storage per database, meaning that the used space will not bear much relation to used disk space in Exchange 2013. To add to that, messages are stored differently within the database and the content indexing engines have changed.

If you are looking to increase quota limits at this point, Exchange 2013 is not going to disappoint you. But, if you’re undecided don’t worry. When we use the Exchange 2013 Server Role Requirements Calculator, we’ll have the ability to adjust quotas and examine the resulting requirements.

For our example organization, we’ll look to tier the users by quota and increase user’s quotas by 50% to accommodate growth. We’ll also account for an additional 20% growth in the number of users.

Based on the data we collected in parts 3 and 4, we’ll use the following values:

User Tier Current Number of Users Number of Users for Sizing Current Quota New Quota
Standard 497 597 550MB 825MB
VIP 4 6 20GB 30GB

Table 3

If you have more than 4 user tiers, you may wish to consolidate these to a smaller number, as the tool we’ll use in the next part of the article, Microsoft’s Exchange 2013 Role Requirements Calculator only allows a maximum of 4 user teirs.

Mailbox Databases

We’ll expect to use the Standard Edition of Exchange Server 2013 for our deployment. This is because given the number of users, the type of deployment and the quota sizes, we’ll expect to fit within the relevant limits of Standard Edition – 5 mounted Mailbox Databases.

From our quota sizing, we’ll be expecting the Exchange 2013 Role Requirements Calculator to split the users into at least 2 databases to fit within the maximum recommended database size of 200GB, for environments with single Database Copies. If quota sizes are larger then we’d expect the number of databases to be automatically split up further.

What we can do, is decide on the number of databases we want though. If we aim to use 4 Mailbox Databases, we have smaller databases which are better for a restore, and we have space for one additional database if we need a temporary database to move users into if we perform maintenance at a later date.

A common technique administrators use is to split databases by user type. This can cause issues if, for example, you place all VIPs on a single database. While it might make it easy for quota management – it can mean that if you have a database failure for your VIP database all your VIPs (i.e. Senior Management) lose access to email. Therefore for smaller environments, consider distributing all your different user tiers across a standard set of databases.

Because we’ll be splitting users equally across databases, we’ll therefore set the Database quota limits to the most common tier of users – our Standard Users, and make exceptions for the VIP Users.

We’ll also need to define our retention periods. The Retention Periods that we’ll set against each Mailbox Database define how long we want to keep deleted items before removing them from the database, and how long we want to keep deleted mailboxes. When determining the retention values think about how often you want to have to perform a restore from backups. The former value defines the period of time that by default a user can recover deleted items themselves; the latter value defines how long we’ve got to re-attach a mailbox if a user is deleted, or if the mailbox is inadvertently disabled.

Our backup solution for Exchange Labs uses a product with single item recovery, so we’ll leave the defaults of 14 days for deleted items and 30 days for deleted mailboxes.

Warning Limit Prohibit Send Limit Prohibit Send/Receive Limit Keep Deleted Items for (days) Keep Deleted Mailboxes for   (days)
800MB 825MB 850MB 14 30

Table 4

Public Folders

Our Public Folder infrastructure will be migrated to Exchange 2013 too. Some of the best news for environments of this kind of size is that we don’t need to “waste” a Public Folder database to support what might be a small Public Folder infrastructure.

In part three, we determined that we had 3 Public Folders, with a total of 396MB. We’ll say that Exchange Labs have decided they must keep these Public Folders –simply so we can walk through the migration. If you have a smaller Public Folder infrastructure like this, then you might decide that although Public Folders live on in Exchange 2013 and will be supported until 2022- it’s easier to ditch them.

When planning for Modern Public Folders, always remember that Public Folders live within Mailboxes. From the client point of view this doesn’t matter, and Public Folders can be split across multiple mailboxes with no impact to the client. However there are some considerations. The Public Folder mailbox that stores the master copy of the Hierarchy (the folder tree) should be placed in a location with great connectivity to clients, place Public Folders in Public Folder Mailboxes with low-latency links to clients that use those folders, and remember the maximum limit for a Mailbox is 100GB so you must split Public Folder Mailboxes at that upper limit. For smaller infrastructures, you might only need one Public Folder Mailbox.

Public Folders Total Size Number of PF Mailboxes   Required
3 396MB 1

Table 5

Summary

In part five of this series, we’ve started to plan what will be required in our new Exchange 2013 environment. In part six we’ll continue our planning and look at the target hardware we’ll use and the Exchange 2013 Role Requirements Calculator.

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