Chapter 14
Migrating to Exchange 2013
Exchange migrations are just like any other type of solution deployment: They require practical planning to ensure success. This chapter outlines some of the more important aspects for migration planning and some common problems that you may experience in the field.
According to Gartner, around 20 percent of small IT projects fail. This number increases to 28 percent for large ($1 million+) IT projects. One of the benefits of working for a large consulting organization is that we get to see both good and bad examples of migration projects. We will discuss these observations in order to help you learn from our experiences.
Before delving into migration design, it is worth spending a bit of time discussing the different types of Exchange migrations and the terminology involved in each.
An inter-org migration refers to migrations between different Exchange organizations. By definition, an Exchange organization is also a single Active Directory forest, and so frequently the terms cross-forest migration and inter-org migration are used interchangeably.
Inter-org migrations are often the cause of most problems for migration teams. The primary reason for this is that the very nature of an inter-org migration involves a second Active Directory forest and a second Exchange organization. Having multiple directories and Exchange organizations often means that there will be a requirement for cross-organization collaboration; that is, users in one organization sharing information with users in another organization. This scenario brings with it complexity, and we all know that complexity is something we can usually do without.
The following items are very likely to impact an inter-org migration:
Outlook client reconfiguration is always a requirement when you migrate a mailbox. If the mailbox remains within the same Exchange organization, however, then Outlook will receive an ecWrongServer response back from the original Exchange Server, which will prompt Outlook to determine the new location of the mailbox. This process happens automatically, and the end-user experience is best described as seamless.
If the mailbox move is to a new Exchange organization, then the redirection process is more complex. There are generally two approaches to this. The first (and best) approach is to configure autodiscover to return the correct RPC client access endpoint in the new Exchange organization. The second approach is to use Outlook profile files (PRF) to force the client to update. The PRF method requires that a script or some other mechanism act on the client machine. The script detects when the user's mailbox has been migrated and then imports a preconfigured PRF file with a valid destination in the target Exchange organization. Outlook will then connect and determine its actual server connection endpoint. Even though we have reconfigured our Outlook client, we now have another potential problem: How is the client going to authenticate to the new mailbox? Our source user logon account had rights over the old mailbox, but it doesn't necessarily have rights over the new, migrated mailbox. The migration process in an inter-org migration must ensure that the account that the user is going use to log on with post-migration still has the access rights to log on to the mailbox.
Availability data sharing is somewhat taken for granted in most organizations. The ability to see whether someone is free or busy when trying to arrange a meeting, for example, is a critical service for many business users. Historically, system public folders provided this service, but since Exchange Server 2007 and Outlook 2007, availability data is provided by Exchange Web Services (EWS) instead. The Availability service (AS) will proxy availability requests between the two forests and send back the data to the calling client. This assumes, however, that the client access servers have been configured correctly in each Exchange organization and that all dependencies are in place, including certificates, network connectivity, name resolution, and Global Address List Synchronization. The bottom line is that it is possible to provide a pretty seamless cross-organization availability experience, but that solution brings additional complexity.
The Global Address List (GAL) is a directory of all mail-enabled objects within the organization. It allows end users to pick from a directory rather than having to remember individual email addresses. The problem arises when you have multiple Exchange organizations that want to have a common shared global address list (GAL). This requires a process for synchronizing entries within the GAL across the forests while maintaining all required attributes. Microsoft's Forefront Identity Manager 2010 (FIM2010) has a GALSync component management agent (MA) that provides this functionality. However, this is another added level of complexity that requires designing, testing, and deploying prior to any migration work taking place.
The freely available GALSync MA in FIM2010 has some limitations, but most notably it will only create a mail-contact object in its default configuration. A mail-contact object type is perfectly acceptable for maintaining a common GAL across multiple Exchange organizations, but it is limited in a migration scenario due to it not being possible to log on to a mail-contact object. Typically, it is more useful to customize FIM to generate a mail-enabled user instead. Handily, the Exchange product group has provided some sample code that does exactly this, and it is available for download at the following URL:
http://technet.microsoft.com/en-us/library/ee861124(v=exchg.141).aspx
Public folder data synchronization is also often a migration requirement. Organizations have used public folders for many years, and they maintain a mix of high-priority workflow data and unstructured data stored across their public folder databases. The biggest problem with inter-org migration of public folder data is that the free Inter-Organization Replication (IORepl) tool is limited in functionality and receives limited support from Microsoft. It was updated to support Exchange 2010, but there are no indications currently that it will be updated for Exchange Server 2013. It does a fairly good job of synchronizing folder data between Exchange organizations. There are issues with folder permissions, however, and many organizations have problems with performance. Also, since this tool is not currently supported in Exchange Server 2013, it will require Exchange Server 2010 with a legacy public folder database in the target forest to make it work. In addition, the other end must be Exchange Server 2003.
There are rumors that Microsoft will eventually provide a solution for legacy public folder migration directly to Exchange Server 2013; however, there are no defined timelines available nor is it clear if any solution would include Exchange Server 2003.
If this all sounds like too much complexity, then you have two options: Either move the public folder data to another service (SharePoint, for example, or Exchange 2013 site mailboxes) or look for third-party public folder migration tools. Obviously, none of these routes are very appealing, which is why most migration teams groan whenever public folders are mentioned. By far the best approach for inter-org public folder data migration is to avoid it entirely. Try to classify your public folder data as “old and unused,” “move to alternative technology,” or “stuck in public folders.” Ideally, you are looking to remove or relocate everything prior to the main migration. If you have to deal with inter-org public folder data migration, test it thoroughly in a lab beforehand and validate the deployment in a production environment before migrating any mailboxes. Also, make sure that you have a way to monitor the success of ongoing public folder data replication, because IORepl has a tendency to stop working of its own accord. Public folder migration is discussed in more detail later in this chapter.
Maintaining mail delivery during an inter-org migration is not always a simple task. The most common problem that you need to solve is that both Exchange organizations will be sharing the same primary SMTP name space, for example, exchange-d3.com. When you move a mailbox from one organization to the other, you need to ensure that mail delivery is maintained both prior, during, and after the mailbox move. To achieve this, there are several dependencies:
SMTP addresses on a mailbox are used for mail delivery, and thus it is vital to maintain any valid addresses on the mailbox during its migration. The legacyExchangeDN is also used for mail delivery. Adding the legacyExchangeDN attribute as an X500 proxy address post-migration helps to prevent delivery failures. For example, someone hitting Reply to an email rather than picking an address from the global address list or typing in the SMTP address manually causes Outlook to attempt to deliver the email based on its previously cached information for that user, the legacyExchangeDN. If a mailbox is migrated without the legacyExchangeDN in its X500 proxy address list and someone replies to a previously received email, then Exchange will not be able to identify the correct target mailbox for delivery, and delivery will fail. Luckily, a PowerShell script that ships with Exchange Server 2013 called Prepare-MoveRequest.ps1 handles this. This script is so important for inter-org migrations that we will cover it later in this chapter.
Mailbox permissions refers to any permissions that govern access over the mailbox itself, such as full mailbox rights, send-as, receive-as, and any of the folder-level delegate permissions. Historically, it has been difficult to migrate these permissions between Exchange organizations using native Exchange tools. With Exchange Server 2010 and later, it is possible to migrate all of the mailbox permissions and delegate access rights as long as the target environment is correctly prepared using the Prepare-MoveRequest.ps1 script. This script ensures that all of the necessary attributes are copied from the source object to the target object to enable Exchange to remap the permissions once the mailbox migration is performed.
Mobile device reconfiguration is one of the trickier aspects of an inter-org migration. Fundamentally, there is no easy solution for all mobile devices, and each mobile platform will need to be addressed in its own way. Research in Motion has the Enterprise Transporter that can move BlackBerry devices between domains relatively seamlessly. Good For Enterprise (GFE) has no known way of doing so without the end user erasing and re-creating the device relationship. ActiveSync devices, such as Android, Apple iOS, and Windows Phone, can all use autodiscover. Not all mobile devices, however, will follow autodiscover redirection requests to the new target forest, and some will need to be reconfigured manually.
The bottom line is that migrating mobile devices between forests is difficult. It will require a significant amount of time to discuss the issues involved with your mobile device vendors and to test the proposed solutions in your lab environment. Since we cannot provide an easy solution here, our best advice is not to skimp on mobile device migration testing, because the impact on mobile device email service is one of the most common problems of a migration. Implementing mobile device infrastructure in a migration test lab can be complex and costly, but the time spent getting this aspect of your migration right will more than pay itself back in the long run.
External URL publishing, or publishing an Exchange organization, can be a tricky subject even when you only need to consider a single Exchange organization. It becomes much more so during an inter-org migration when you need to account for multiple organizations. The problem in this case is that Exchange is not aware of the correct URLs to provide to users who have been migrated. For example, User1 is trying to access OWA, which is published on the external URL https://mail.exchange-d3.com/owa that proxies HTTPS requests back to server1.forest1.com. After the migration, however, forest1 no longer has a mailbox for User1, and so when the user tries to access OWA, an error message is received. The most common approach for resolving this issue is to notify users about a new URL to access OWA post-migration, such as https://owa.exchange-d3.com/owa. This information can be delivered via an email message after the mailbox is successfully moved. This approach is relatively trivial from a design perspective, and it lessens user frustration through a simple and effective communication.
Exchange application integration is a minefield of a topic in its own right. During an inter-org migration, this is one area that cannot be rushed, and it often remains an ongoing issue long after the majority of mailboxes have been migrated to the new platform. The reason that application integration is so difficult is that there are a number of ways that an application or service can integrate with Exchange: SMTP, MAPI client and Collaboration Data Objects (CDO), WebDAV, IMAP/POP, or Exchange Web Services. Some applications will have gone through a formal project-delivery process, and thus they will be a known quantity. Others, however, may not have gone through such a process and may have taken advantage of the Exchange 2003 open SMTP relay to send messages, or they may be using normal user mailboxes via CDO, and so forth.
The first problem is discovering each and every application that is relying on the messaging system, understanding how it connects, and taking into account how it will be affected by the migration. Some may be easy to migrate, while others may require a total application upgrade. The key to making this part of the inter-org migration successful is good communication with the business units, analyzing server logs (SMTP and IIS), using Microsoft Exchange Server User Monitor (ExMon), and creating a register of each service—who owns it, how it connects to Exchange, if it uses a mailbox, and what is required to migrate the service to the new platform. Be warned, however, this is a tedious and time-consuming task, which if not done properly can turn an otherwise excellent migration into a disaster. We have all worked migrations where this process alone has caused an Exchange migration project to be viewed as a failure.
Outlook clients in cached mode use an offline address book (OAB) to allow offline access to the global address list. Once Outlook has downloaded an OAB, it will use that by default to query the Exchange infrastructure directly for directory information. This is a great efficiency, and it provides a better user experience while reducing the server workload. It is a problem, however, when you migrate mailboxes between Exchange organizations. Although the global address list looks similar from an end-user perspective in two Exchange organizations that have GALSync configured, the actual attribute data for message delivery is quite different. This means that a migrated user will be performing directory lookups against the wrong GAL post-migration. For this reason, it is necessary to delete the OAB files from Outlook after the mailbox has been migrated. Typically, you delete the OAB file in the same client-side script that imports the PRF file, as noted previously. The downside is that after every user mailbox is migrated, a full OAB download will be required. Depending on the size of the OAB file, you may need to take this additional network traffic into account when you are planning your migration schedule.
Distribution lists (DL), or distribution groups (DG), are used heavily in most organizations. Essentially, a distribution group is a way to send a single email to a group of individuals. The problem with DG migration is that it must result in a delivery to the same users, even halfway through a migration. If you think about this for a minute, this means that you either need to update the DG membership constantly as each mailbox is migrated, or you need to leave all of the DGs in the source environment until the end of the migration, when they can be migrated in one step. There are third-party software tools that can help. The most common approach is to create empty DLs in the target environments and then place a single hidden contact within the DL that has the target address of the source DL. This has the effect of correctly displaying the DL in the global address list, but it defers expansion and delivery back to the source environment where the membership is correct. As each mailbox is migrated, the moving process will leave behind a mail-enabled user in the source environment who is a member of the same groups as before the migration. Once all of the mailboxes have been migrated, the DGs can then be migrated and the membership can be updated in the target organization. Although there are various ways of achieving this, most migration teams tend to use PowerShell or the Active Directory Migration Tool (ADMT) for this task. It is important to note here that ADMT does not migrate Exchange attributes, such as proxyAddresses, so there is also some post-migration processing work that may be required if this route is taken. The trick to getting this right is the same as always: Test thoroughly in your migration test environment before migrating any distribution lists.
In an intra-org migration the migration takes place within the same Exchange organization. In other words, multiple Exchange Server versions coexist within the same Active Directory. This is by far the most straightforward of Exchange migrations because it involves many fewer complexities than an inter-org migration.
With Exchange version coexistence in mind, it must be noted that Exchange Server 2013 cannot coexist in the same Active Directory forest with Exchange Server 2003 or earlier versions. We will cover options for migrating from unsupported legacy environments later in this chapter, but for now it's worth noting that you cannot simply install Exchange 2013 next to Exchange 2003 and move the mailboxes over.
Regarding Exchange 2007 and Exchange 2010 coexisting with Exchange Server 2013, during an intra-org migration you essentially install Exchange 2013 into the existing environment and then move the mailbox from one Exchange Server to another, though running different versions of Exchange. This happens all the time in most Exchange organizations, and it is a well-understood process.
The potential problem areas we identified for inter-org migration remain considerations with an intra-org migration as well. They are far less likely, however, to cause problems since the majority work well once you have deployed Exchange 2013 in coexistence with an older version.
Outlook client reconfiguration is provided via the MAPI protocol. Autodiscover is provided natively within an Exchange organization.
Availability data sharing again occurs natively when you have multiple versions of Exchange installed in the same organization. Some planning is required to ensure that autodiscover and the Availability services are properly configured, but from a migration perspective, end users should not notice any significant impact as their mailboxes are migrated from one version of Exchange to another.
The global address list remains the same before and after migration. However, it may now be supplied from a different server.
Public folder data synchronization becomes public folder migration and becomes slightly less problematic. However, with Exchange 2013 and modern public folders, things become more interesting. Exchange 2013 introduces a totally new implementation of public folders, and although they look the same to the end user, they actually function completely differently from an administrative perspective. We will discuss this further later in this chapter.
Mail flow and mailbox permissions “just work” when migrating between Exchange Servers in the same organization. Assuming that the Exchange 2013 infrastructure has been deployed correctly, the mailbox migration will maintain all previous email addresses and permissions throughout the move. Additionally, since the legacyExchangeDN of the mailbox remains the same, there is no need to modify any proxy addresses during the migration.
Again, mobile devices vary in their behavior. However, the majority of mobile devices support mailbox moves within the same Exchange organization with little or no impact on the end user. BlackBerry and Good for Enterprise require a specific minimum version to support Exchange Server 2013. At the time of this writing, BlackBerry requires BES 5.0 SP4, and Good for Enterprise has not yet provided a definite release date, but they have confirmed that they are developing support for Exchange 2013. ActiveSync devices such as those from Apple, Google, Microsoft, and others all support mailbox moves natively within the same organization.
External publishing needs to be moved over to the newest version of Exchange within the organization prior to a migration being initiated. But once the infrastructure has been correctly configured, an end user can connect to the same URLs initially and rely on Exchange to connect them to the correct server after authentication.
Application integration remains largely as tedious and manual a process as it does with an inter-org migration. As Exchange has evolved, the methods and APIs used for application integration have changed. The older the application, the more likely it is that problems will be present after migration to Exchange Server 2013. The key to mitigating these is the same as with inter-org migration: good communication with the business units, analyzing server logs (SMTP and IIS), using Microsoft Exchange Server User Monitor (ExMon), and creating a register of each service—who owns it, how it connects to Exchange, if it uses a mailbox, and what is required to migrate the service to the new platform.
The offline address book (OAB) is likely to change publishing location, and the server that generates it will change after Exchange 2013 has been installed. Nothing specific, however, is required post-mailbox migration. Outlook will take care of updating the OAB file via its normal incremental update mechanism, and no additional action is required.
Normal distribution groups (DG) do not have to be migrated during an intra-org migration. Dynamic distribution groups, however, may need to have their LDAP search filters upgraded to OPATH filters. The change from LDAP to OPATH was introduced with Exchange 2007, because of PowerShell's use of OPATH filtering. This means that, for an Exchange 2013 migration, it is very likely that this has already been done. Nevertheless, in case it hasn't, it is worth verifying this after the installation of Exchange Server 2013.
Moving mailboxes and data is probably the most critical part of any migration. Any mistakes made here will almost certainly result in a meeting where you are asked to explain your actions, which everyone would prefer to avoid.
We have witnessed some painfully difficult scenarios over the years where mailbox data migrations went wrong. For example, take the scenario where a Lotus Domino migration to Exchange 2007 mixed up the source and the target mailbox data. The result was that some users logged on the morning after the migration only to be presented with someone else's mailbox and calendar data.
Another scenario occurred when a migration team decided to migrate only the last 30 days' worth of email and no calendar data but hadn't informed the business of this. While the IT team viewed this as a successful migration since it met all of their requirements, the business units held a somewhat different viewpoint. The bottom line is that end users are rightfully very protective of their data, and there will be quite an uproar if any of it goes missing, whether intentionally or not.
For Exchange-to-Exchange migrations, moving mailbox data is handled by the Mailbox Replication Service (MRS). The MRS was introduced in Exchange Server 2010, and it brought with it some extremely useful benefits over the legacy approach for moving mailboxes:
Exchange Server 2013 incorporates MRS from Exchange Server 2010 and adds the following improvements:
At its heart, the MRS is a mailbox move-queuing service. It takes requests to move a mailbox from a source to its destination and then processes each request on the administrator's behalf.
One of the most important things to remember is that the mailbox data is not routed via the administrator's management console, as it was in Exchange 2007 and prior. The actual mailbox data movement is controlled via an instance of the Exchange 2013 Mailbox role in the target AD site. This means that you can generate a move request for a mailbox between two databases in Hong Kong from a PowerShell session in London, and the migration data will remain within Hong Kong.
Here is a link to a great post on the Exchange Team Blog that talks in some detail about how MRS in Exchange Server 2010 works:
http://blogs.technet.com/b/exchange/archive/2010/07/19/3410438.aspx
Although Exchange Server 2013 has made improvements, the fundamental mechanics of moving a mailbox via MRS remain the same. This article is highly recommended in order to obtain a working understanding of MRS prior to beginning your migration planning.
We have already discussed inter-org migration considerations. This section is intended to take a look at what you need to do to prepare your target user objects to get them ready for migration. Before MRS can move a mailbox into another forest, there must be a mail-enabled target object in the target forest with matching attributes. A list of mandatory attributes is provided in Table 14.1.
Table 14.1 Mandatory attributes for a cross-forest move
| Mail User's Active Directory Attributes | Action |
| displayName | Copy the corresponding attribute of the source mailbox or generate a new value. |
| Directly copy the corresponding attribute of the source mailbox. | |
| mailNickname | Copy the corresponding attribute of the source mailbox or generate a new value. |
| msExchArchiveGUID and msExchArchiveName | Directly copy the corresponding attribute of the source mailbox. Attributes are available only if the source mailbox is Exchange 2010. |
| msExchMailboxGUID | Directly copy the corresponding attribute of the source mailbox. |
| msExchRecipientDisplayType | -2147483642 (decimal) //equivalent to 0x80000006 (hex). |
| msExchRecipientTypeDetails | 128 (decimal) /0x80 (hex). |
| msExchUserCulture | Directly copy the corresponding attribute of the source mailbox. |
| msExchVersion | 44220983382016 (decimal). |
| cn | Copy the corresponding attribute of the source mailbox or generate a new value. |
| proxyAddresses | Copy the source mailbox's proxyAddresses attribute. Additionally, copy the source mailbox's legacyExchangeDN as an X500 address in the proxyAddresses attribute of the target mail user. |
| sAMAccountName | Copy the corresponding attribute of the source mailbox or generate a new value.
Ensure that the value is unique within the target forest domain to which the target mail user belongs. |
| targetAddress | Set this to an SMTP address in the proxyAddresses attribute of the source mailbox. This SMTP address must belong to the authoritative domain of the source forest. |
| userAccountControl | Constant: 514 //equivalent to 0x202, ACCOUNTDISABLE | NORMAL_ACCOUNT. |
| userPrincipalName | Copy the corresponding attribute of the source mailbox or generate a new value. Because the mail user is logon disabled, this userPrincipalName isn't used. |
Note: The proxy addresses of the source mailbox user must contain an SMTP address that matches the authoritative domain of the target forest. This allows the New-MoveRequest cmdlet to select the target address of the source mail-enabled user correctly (converted from the source mailbox user after the mailbox move request is complete) to ensure that mail routing is still functional.
These mandatory attributes can be managed in two ways. The first is via the Forefront Identity Manager 2010 (FIM 2010), which can be configured to synchronize between the source and the target environments in such a way as to support MRS mailbox moves. The necessary code and configuration information for this approach can be found here:
http://technet.microsoft.com/en-us/library/ee861124.aspx
If you do not have FIM 2010 available, then there is an alternative method that works just as well. The Exchange team provides a PowerShell script called prepare-moveequest.ps1. This script is installed as part of every Exchange Server 2013 installation in the C:\Program Files\Microsoft\Exchange Server\V15\Scripts folder. This script has been the cornerstone of many migration projects since it was introduced in Exchange Server 2010. The script is capable of creating and updating user objects in the target forest, and it ensures that they are ready for a cross-forest mailbox move with all of the mandatory attributes in place.
Use of this script is detailed here:
http://technet.microsoft.com/en-us/library/ee861103.aspx
Storage capacity within the target Exchange infrastructure is a predictable, though frequently overlooked, consideration during a migration. There are two areas to consider.
Mailbox database Volume size is simply how large your mailbox databases will become when you migrate your mailboxes into them. Rather than attempting to plan for this specifically during the migration, it is better to plan your target environment adequately to accommodate all of your mailboxes at their maximum quota size during the design phase. It's easiest to use the Exchange Mailbox Server Role Requirements Calculator to help you with this since it provides the best approximation of the size required to store each mailbox in your environment. Your completed design should specify a limit on the number of mailboxes at the maximum quota size that can safely fit into each mailbox database. As you are planning your migration, you must ensure that no target mailbox database exceeds the design target. Additionally, it is recommended that you validate the predictions at around 25 percent migration complete in order to ensure that the database sizes agree with those predicted during the design phase. Do not be tempted to do this validation check too early since Exchange mailbox databases contain an amount of whitespace that may make things look worse than they are.
Transaction log Volume size has been a problem for Exchange migrations since the very beginning of Exchange. The main problem is that transaction logs record all changes made to the mailbox database, including the data that was added or modified. This is done so that, in the event of a mailbox database problem, the transaction logs can be used to replay changes from the last full backup and bring the database back to a consistently healthy state. This has always been a great feature of Exchange, and it has saved many an administrator's bacon when things have gone awry. It also means that if you move a 1 GB mailbox from the source environment to the target environment, you need to account for the space to hold both the mailbox data in the mailbox database and the transaction logs. So while transaction logs are indeed great, they are also something you need to watch carefully during a migration.
As a general rule of thumb, the size of transaction log data generated on the target database will be roughly equal to the size of the mailbox data being moved. We generally advise adding 10–20 percent headroom when calculating this to account for variations. You should also try to leave the log drives with a minimum of 25 percent free space after each daily migration batch. This may seem like an overly conservative approach. If you do run out of transaction log space, however, then the mailbox database will dismount, and you know what happens next. Thus, all things considered, it's better to migrate conservatively and work upward rather than begin with a tidal wave of mailbox migrations, only to begin day two of your migration in the IT director's office explaining why the new super-highly available Exchange solution was offline after only half a day in production. (Yes, this really happened to one of our more zealous customers.)
Having said all of this about storage capacity during a migration, make no mistake that failing to account for it adequately is a very easy trap we have all fallen into at some point in our careers. All it takes is a failed backup or someone accidentally scheduling in a few too many or too large mailboxes, and you too can run into this scenario. Our best guidance here is to define a plan of action to bring service back online quickly after a transaction log volume has filled up, and make sure that your support teams know what to do if it does occur. Monitoring and alerting can sometimes help here, but typically the rate of change during the migration is very fast, and so, by the time someone has been contacted because of a log volume running low on space, it is generally too late.
Content indexing (CI) in Exchange has evolved greatly over the years. CI is the process by which the content of a mailbox is stored to improve its searchability. As mailbox sizes have grown over the years, so too has the difficulty in finding what you are looking for. Maintaining a content index allows you to search against mailbox contents based on keywords. Initially, it was very resource-intensive and it provided a fairly poor experience, so most customers chose not to enable it. Exchange 2007 brought with it a much better CI implementation, which was retained in Exchange Server 2010. This new implementation of CI was enabled by default since it was more efficient. However, the downside of having CI enabled permanently was a fairly dramatic increase in CPU utilization during mailbox migrations. With Exchange 2007 and Exchange 2010, a newly migrated mailbox is scheduled for indexing once it has been successfully migrated. This means that during a typical migration window, the migration processes are fighting with the CI processes for system resources. This can dramatically reduce migration throughput.
Exchange Server 2013 introduced a totally new CI mechanism based on the Microsoft FAST Search technology. Furthermore, mailbox migration data is now indexed as it is added rather than post-mailbox migration. The idea here is to ensure that the CI is as up to date as possible if the user logs on directly after a mailbox migration. Initial lab testing suggests that Exchange Server 2013 is throttling index generation during migrations, and disabling CI during your migration window may no longer have any significant benefit.
Public folders have been complicating Exchange migration projects since they were first introduced in 1996. Exchange 2013 brings some benefits as well as some problems in this area. These problems include the following:
If you remember back to the section on inter-org migrations, we mentioned that migrating public folder data between organizations relied on either the IORepl tool or a third-party solution. The free IORepl tool required one end of the connector to be Exchange 2003 and the other to be Exchange 2007 or Exchange Server 2010 SP1. Since this tool is no longer being updated, if you need to migrate public folder data cross-forest, you have the choices listed in Table 14.2 available to you. Migrating intra-org within the same forest requires yet a different process, which is unique to modern public folders. This process is discussed later in this section.
Table 14.2 Migrating public folders
| Source Version | MigrationType | Native Tool Steps |
| Exchange 2003 | Inter-org
(cross-forest) |
|
| Exchange 2007 | Inter-org
(cross-forest) |
|
| Exchange 2010 | Inter-org
(cross-forest) |
|
| Exchange 2003 | Intra-org
(same forest) |
|
| Exchange 2007 | Intra-org
(same forest) |
|
| Exchange 2010 | Intra-org
(same forest) |
|
Once the migration request has been finalized, it cannot be reversed.
Interestingly, it is possible to migrate public folder data from Exchange 2003, Exchange 2007, and Exchange Server 2010 directly to a new Office 365 Exchange Online tenant that will provide 1 TB worth of modern public folder data storage space for every tenant. We discussed this in detail in Chapter 7, “Hybrid Configuration.”
If you are performing an intra-org migration within the same forest, the change from legacy to modern public folders is significant. It will require some design investment to ensure good distribution and usage of public folder mailboxes.
The intra-org migration path from Exchange 2007 or Exchange 2010 is as follows:
This process is explained in more detail here:
http://technet.microsoft.com/en-us/library/jj150486%28EXCHG.150%29.aspx
In summary, if you need to migrate public folder data cross-forest from Exchange 2007 or 2010 to Exchange Server 2013, you are going to need to talk to a third-party vendor. Quest and Binary Tree both have mature and established toolsets that can deal with this scenario. If you are migrating from Exchange 2003 to Exchange 2013, you can use IORepl, but an Exchange Server 2010 SP3 public folder database is required in your Exchange 2013 environment for this to work. Alternatively, you may talk to Quest or Binary Tree and avoid dealing with IORepl and Exchange 2010 in your Exchange 2013 environment.
If you are migrating public folder data intra-org within the same forest from Exchange 2007 or Exchange 2010 to Exchange Server 2013, you need to migrate all of your mailboxes first and then perform the modern public folder cutover migration process as detailed previously.
Migrations from non-Exchange systems represent fewer and fewer migration projects nowadays. Exchange Server has been an extremely successful product over the last decade, and the majority of our work these days is migrating Exchange to Exchange. This trend has led to a somewhat specialized community catering migrations to Exchange from non-Exchange platforms. These foreign systems are best classified as follows:
Let's discuss some of the options and challenges of migrating from each of these systems.
Lotus Notes has been around since 1989, and despite changing the server software name in 1996 to Domino 4.5, Powered by Notes, most IT teams still casually refer to it as Lotus Notes. Notes is an interesting service to migrate to Exchange. Although both Exchange and Notes provide an email service, Notes also provides a rich application and database-programming platform while Exchange does not. It is debatable, however, that for most organizations, Exchange provides a better platform for email and collaboration. Migration of email from Lotus Notes to Exchange is a relatively well-understood process, and although there are no longer freely available native migration tools, both Quest and Binary Tree offer specific migration tools for the migration process to Exchange Server 2013. Both toolsets deal with this process from end to end, including planning, scheduling, coexistence, and data migration. However, there are still some common issues when coexisting between Lotus Notes and Exchange:
Having taken care of the email portion of the migration, all that remains are the Lotus Notes applications. There are many vendors that claim to have a solution for this and that offer a tool that will analyze your Lotus Notes applications and determine the correct migration approach. They can even tell you which are used or unused.
This can be very useful and surely reduces some of the migration burden. However, application migration can take many years to complete, especially for heavily used and complex applications. Some can be migrated easily or deleted. What remains, however, is often very difficult to migrate. We advise that you decouple your Lotus Notes email migration project from your Lotus Notes application migration project. It is usually possible to migrate most Lotus Notes mailboxes without migrating a single Lotus Notes application. The end user will require access to both Outlook and the Lotus Notes client until all Lotus Notes applications have been migrated or replaced.
The bottom line for Lotus Notes migrations is that email is relatively easy to migrate, assuming that you plan correctly and use a robust migration toolset. Application migration, however, is usually very complex, and unless you have a trivial set of Lotus Notes applications, do not fall for the application migration toolset hype—it's usually a long and slow process to get rid of those Lotus Notes applications.
Novell GroupWise has a similar migration and coexistence story to Lotus Notes, and the same pitfalls and warnings apply. Quest has the most comprehensive toolset available for GroupWise migrations.
Many alterative mail systems exist. Most of these mail systems provide IMAP integration that can be used to migrate mailbox data. However, these systems often pose additional problems including the following:
Unfortunately, there is no simple solution for all of these systems since they vary widely. Some run on Windows servers and integrate with Active Directory, but most are Unix/Linux-based and have totally separate account and password information.
Back with Exchange Server 2007, Microsoft published the Microsoft Transporter Suite that would migrate from IMAP to Exchange Server 2007. This suite was dropped for Exchange Server 2010, however, and there is no expectation that Microsoft will provide anything similar for Exchange Server 2013. This means that you will need to engage with a third-party vendor to obtain migration tools for this scenario. At the time of this writing, the only tool we are comfortable recommending for this type of migration is Transend Migrator.
This section covers migrations from older versions of Exchange Server with no direct migration path. In the case of Exchange Server 2013, this means Exchange 2003 or older. There are still many deployments of Exchange 2003 in the business world, and so there will be many migration project teams that need to deal with this problem.
Before we dig in to some solutions, let's confront the real problem: There is no way to migrate directly from Exchange Server 2003 to Exchange Server 2013. This includes inter- and intra-org migrations. If you attempt to install Exchange Server 2013 into an existing Exchange organization with any Exchange Server 2003 servers remaining, Exchange setup will block the installation. If you attempt a cross-forest mailbox move from Exchange Server 2003 to Exchange Server 2013, MRS will tell you that you are attempting to move a mailbox from an unsupported Exchange version. Clearly this is a problem if you are still in Exchange Server 2003, so let's review some of your options.
This process is exactly as it sounds. You cannot migrate directly from Exchange Server 2003 to Exchange Server 2013, but you can migrate from Exchange Server 2003 to Exchange Server 2010 and then from Exchange Server 2010 to Exchange Server 2013. For most organizations, this is a particularly painful migration path. It is, however, the one that the Exchange product group recommends if you wish to migrate to Exchange 2013 from Exchange Server 2003.
The migration process is made more difficult by the requirement that you remove all traces of Exchange Server 2003 before installing the first Exchange Server 2013 infrastructure into the organization. On the plus side, once you have all of your mailboxes running in Exchange Server 2010, the mailbox move to Exchange Server 2013 can be performed online, thus reducing the migration time somewhat.
Because of pressure from customers who did not wish to migrate from version to version, the double-hop inter-org migration approach was conceived. This approach relies on a resource forest with both Exchange Server 2010 and Exchange Server 2013 installed. Mailboxes are first migrated cross-forest from Exchange 2003 to Exchange 2010 and then immediately on to Exchange Server 2013. This method allows for mailboxes to be migrated to Exchange Server 2013 before Exchange Server 2003 has been totally decommissioned, and it requires only a small deployment of Exchange Server 2010 in the target forest. There are some downsides, however:
Office 365 provides Exchange Online, which is Exchange Server 2013. It also provides a way to migrate from Exchange Server 2003 directly to Office 365 via MRS over the Internet. This migration process is similar to the one used for an inter-org migration. However, the Office 365 platform provides most of the tool and coexistence software for enterprise customers free of charge.
We discussed hybrid deployments in Chapter 7, “Hybrid Configuration.” However, for most customers who wish to take advantage of Exchange Server 2013, and who are currently running on Exchange Server 2003, moving to Office 365 is the easiest and most cost-effective way to achieve this at the current time.
Sometimes our advice to customers running Exchange Server 2003 who must remain on-premises due to legislation or other constraints is to migrate to Exchange Server 2010 as a strategic platform. This may seem like unusual advice, but Exchange Server 2010 has proven to be a very solid platform and delivers huge improvements over Exchange Server 2003. For some Exchange 2003 customers, Exchange 2010 represents a better target platform than Exchange 2013 because of its easier migration path, and yet it still provides a very low total cost of ownership (TCO), including the ability to coexist with Office 365 in a hybrid environment.
The migration tools and process are well defined, and there are many skilled resources in the market with expertise in these types of migrations. All major third-party integrators have solutions for Exchange 2010, and the product remains in mainstream support until 2015 and extended support until 2020.
This section provides some insights into problems that we have observed during migration projects and some possible ways to help you avoid them. All successful Exchange migration projects should be able to react well to unexpected events. As a mentor of mine used to say, “Expect failure.” He was right—any project that cannot deal with setbacks is destined to failure. However, our experience shows that “forewarned is forearmed,” and a little upfront planning can save you a world of pain down the line.
Exchange migrations are very public projects. Most if not all employees of an organization will be customers of the Exchange service. This means that if there are any problems during the migration, there is a strong possibility that you will affect someone's working day negatively.
Frequently migration project teams use the term “seamless” to describe a mailbox migration. Although it may be possible to migrate the majority of mailboxes in an organization without them noticing, there are often times when this is not the case. Things can get interesting, especially if you have not taken the time to engage directly with the business area that is experiencing the problem.
IT project teams sometimes have a tendency to plan and act within a bubble. Exchange migrations are often a good example of this behavior. Since the migration project team does not need any technical assistance with the Exchange mailbox migration, the migration is tested, planned, and executed without engaging with the business at all. Although this can work sometimes, it is our experience that something usually goes wrong that could have been avoided by consulting the business unit beforehand.
Working with business area representatives prior to a mailbox migration and discussing their needs and use of the service can pay huge dividends in the event of problems down the line. This is especially true if contact is made in person by the migration project team. This type of engagement is extremely common in smaller environments. However, as the organizations with which you are dealing get larger and larger, it becomes harder to achieve. Nevertheless, it is in these larger environments where the payback is the greatest. If the project team has a personal relationship and contact point with the business area where disruptions may occur, then that issue is far less likely to be escalated, and it can be dealt with at a project level. Being able to deal with problems at the ground level rather than having them escalated to senior management is without doubt a huge benefit.
Once a business area feels undervalued and insignificant, they can make life extremely difficult. We have seen Exchange migration projects put on hold for six months because a single business area was unhappy about their mailboxes being migrated without being consulted beforehand. When we became involved and made contact with representatives from the particular business area, they had no complaint with the migration process itself. Rather, their main complaint was about the potential risk to service and lack of consultation beforehand. This relationship took a long time to mend, and the whole thing could have been avoided by a simple meeting between the parties beforehand.
Although not always necessary, our advice is to make contact with key business representatives, present them with details about the proposed migration process, schedule dates, and the expected user experience, and ask them for feedback. Determine how they would prefer to be kept informed of progress on the migration project, and ask if they want to be involved in the migration design and testing signoff. Experience shows that, once involved, the business representatives are generally very helpful and truly want the project to be successful.
“Failing to plan is planning to fail” is a commonly quoted expression when it comes to project and design planning. Certainly, it is good advice to do adequate up-front planning, but what exactly is involved and why is it so important?
As it is for most projects, planning is vital for Exchange migration. However, by far the most important aspect of this is being practical. Many migration projects have a plan that looks just great on paper or when projected on a sparkly Gantt chart. When it comes down to implementing that plan, however, things often begin to unravel. This is not a failure to plan—it's because the plan itself is a failure. The tendency is for technical resources to try to work around a mess of a plan in order to get the job done. Sometimes this is successful, while at other times it's not. When it is unsuccessful, it can be extremely difficult to figure out exactly what has happened and to get back on track.
Our advice is to avoid very complex planning charts and keep migration planning as simple and practical as possible. Try to create a visual representation of the plan that can be presented to business areas and the project team. Most good project managers will maintain a complex Gantt chart for their own sanity, but this rarely is presented to or published for the business areas. Ideally, the plan should include all phases of the project, including the design, testing, piloting, and business area migration schedules.
Build slack into the schedule between phases to accommodate unexpected issues and to provide the design teams with adequate time to rethink and resolve issues appropriately. One of the most common mistakes we've observed is poor migration design decisions that were made because of rushing the design phase. Exchange migration design can be very complex, especially in large organizations.
Do not fall into the trap of thinking everything will work just fine because you purchased an expensive migration tool. It may simplify the migration process, but you still need to plan, design, and test your solution to ensure success.
Different organizations maintain different relationships between the IT department and their end users. For some organizations, IT will go to great lengths to make the life of the end user as simple as possible—even if it means spending colossal amounts of time and money to avoid the user having to perform mundane tasks. Other organizations pursue a different path, and they embrace programs such as allowing end users to use their own devices and welcoming end-user interaction during a migration project.
While there is no right or wrong here, it is important that you understand the organization's expectations before you begin a migration project. If the end users who will undergo migration have been pampered by IT in the past, and the migration process that you intend to deploy requires them to perform manual tasks, you may expect that this plan will not be well received. Likewise, if the users being migrated are used to performing manual tasks, then you should not over-design the migration process.
Be aware of both the implicit and explicit expectations of the end user, and design your migration solution accordingly. Over-designing can lead to unnecessary expense and complexity, whereas under-designing may lead to an unacceptable experience for the end user.
You will need to determine whether your plan is focused on migrating everyone as quickly as possible to the new platform in order to minimize the impact of coexistence issues, or if end users will migrate slowly and in batches in order to minimize disruption. This issue is not as important with an intra-org migration, but it becomes extremely relevant for inter-org and foreign system migrations, where coexistence problems are very likely.
Many organizations have attempted to identify end-user relationships via delegate permission mappings and organization charts in an effort to migrate mailboxes in batches. The aim here is to reduce the likelihood of two users who share mailbox data frequently from being migrated at different times and thus experiencing disruption if they are migrated independently. The outcome of such attempts has always been fruitless in our experience. The problem is that the delegate permission relationships are highly complex in nature, and it is impossible to determine if they are in active use or not. For example, this may occur when a user has granted a colleague access to her calendar in a former role. The user now has a different role, but the old delegate relationship still exists along with new delegate permissions. How do you know which permissions are in use and which are not? Likewise, attempting to group users by department, physical location, or project is unsuccessful since these factors are not boundaries for data sharing.
As a general rule, attempting to group users together is rarely successful, and it often results in a complex migration scheduling process that leads to uneven batches of mailboxes to migrate. The only exception to this is for shared mailboxes, where it can be very useful to migrate the shared mailbox and everyone who has access to it at the same time.
Our recommendation for both foreign and inter-org migrations is to migrate as quickly as possible after a successful pilot has been performed. Provide an emergency “quick migration” process to migrate users who have problems accessing a previously migrated mailbox; that is, add them to that night's migration schedule.
The golden rule for migrations is never to migrate users backward; always migrate them forward. For example, if you migrated someone's mailbox inter-org but not their personal assistant's mailbox, the assistant may lose access to that mailbox after it was migrated. The first course of action here is to migrate the assistant over as quickly as possible, either via a support process that would move it immediately or add the assistant mailbox to the next migration batch to minimize disruption.
The aim is to migrate everyone as quickly as possible by maximizing every minute of the available migration window. This approach will cause some temporary disruption, but it generally provides the best overall experience. Attempting to avoid end-user disruption entirely during an inter-org or foreign system migration is generally an exercise in futility in any sizeable organization.
IT experts have often frowned on migrating to a new version of Exchange early in its release cycle. Many insist on never deploying a Microsoft product prior to its first service pack, believing the initial release will surely be full of bugs. The reality is somewhat different these days: Exchange Server 2010 had over 20 million hosted mailboxes running at the time it was made generally available, and it was proven to be a high quality piece of software very early on.
Exchange Server 2013 is a major new product release. This means that it has many more areas of significant development than Exchange 2010. Nevertheless, the same engineering quality processes have been used during its deployment, and it has been tested and operated within Office 365 by customers in the Technical Adoption Program and internally at Microsoft during its development phase.
Unfortunately, the quality of the Exchange release is not the only concern. Most organizations rely on third-party applications that must integrate with their Exchange infrastructure. These systems provide mobile device access, fax integration, customer records management, archiving and compliance, antivirus and message hygiene, and so forth. The bottom line is that a messaging infrastructure will typically rely on many vendors and software products, not just Exchange Server. When a new version of Exchange is released, the vendors of each of these supplemental products potentially will be at different phases of their own product release cycle and may not have a version of their product that supports the version of Exchange Server that you are deploying.
Our recommendation is to perform an early discovery operation and make sure that all of your dependent services and applications support Exchange Server 2013. Most vendors will share their planned product development roadmaps with existing customers and, in many cases, will work with customers to run and test pre-release software. For many organizations, it is a valuable process to be able to deploy early and potentially provide feedback for products in development.
Many organizations operate in areas that have operating standards defined by a governing body. These standards often dictate rules defining how data should be kept and for how long and, potentially, in which country the data must remain. Exchange migrations must be designed to meet these requirements before, during, and after the mailbox is migrated.
Our advice is to get clear guidance on these compliance requirements and design a migration solution with them in mind. There is no more certain way to shut down a migration project than to discover a breach in data compliance. Some organizations may even be in danger of losing their operating license if they are found to be in breach of their compliance standards. Once you have a migration process designed, take the time to speak with the IT risk and compliance teams and get their input about whether it is going to meet their compliance requirements.
Exchange Server 2013 builds on the Mailbox Replication Service used in Exchange Server 2010 and provides a few new features to help with mailbox migrations. Some of these new features are described next.
A migration batch is a group of mailboxes that is moved in one batch. With Exchange Server 2010, this approach was commonly achieved by scheduling a move request with the -batchname and -suspend options. These requests would then be started at the same time via the resume-moverequest cmdlet.
The new-migrationbatch cmdlet in Exchange Server 2013 provides this ability and retrieves the mailboxes to add to each batch from a predefined CSV file.
The new cmdlet features and examples are detailed at
http://technet.microsoft.com/en-us/library/jj219166
Although this new feature is hardly groundbreaking, it does simplify the creation of batch migrations via PowerShell.
Migration endpoints are designed to simplify remote mailbox moves, such as those made during an inter-org or hybrid cloud migration. Each endpoint defines specific requirements to move mailboxes to that target environment, such as the type of mailbox move, the remote servername, and the credentials to use.
In Exchange Server 2010, these items had to be specified on each move request. By storing them as migration endpoints in Exchange Server 2013, they need only be defined once, and then each migration batch simply has to reference the name of the migration endpoint to determine the right location and credentials to use to move the mailbox.
Again, this was achievable in Exchange 2010 via PowerShell and saving credentials. The new-MigrationEndpoint cmdlet, however, makes this whole process much simpler and easier to manage.
Detailed information for the new-MigrationEndpoint cmdlet can be found here:
http://technet.microsoft.com/en-us/library/jj218611
Migrations can be monster projects that run for many years, while others are short and sweet. This chapter covered the most important aspects of a migration project, but it should be viewed merely as a starting point for your planning and not a complete reference on migration.
It is a relatively straightforward process to migrate to Exchange Server 2013 if you are running Exchange Server 2007 or Exchange Server 2010. The golden rules for this type of intra-org migration are to communicate with the business effectively, understand your application integration remediation steps, deploy your Exchange 2013 environment in coexistence according to Microsoft's recommended guidelines, and perform good quality testing prior to migration.
Legacy Exchange Server migrations, for example, Exchange 5.5, Exchange 2000, and Exchange 2003, require a more complex solution. Most of these environments will require a third-party migration solution due to the lack of continued support from Microsoft. Exchange Server 2003 customers wishing to migrate to Exchange Server 2013 should strongly consider Office 365, with Exchange Server 2010 on-premises being the next best alternative. If you must migrate from Exchange Server 2003 to Exchange Server 2013 on-premises, you will need to follow an involved migration path or speak to Quest or Binary Tree.
Foreign system migrations, such as Lotus Notes and Novell GroupWise, will require third-party tools for success. Again, Quest and Binary Tree have solutions available that are proven and reliable.