Mastering Exchange Migrations: Controlling the Top Ten Critical Issues

Transcription

1 Mastering Exchange Migrations: Controlling the Top Ten Critical Issues Use the right combination of tools and processes to protect your messaging system during this critical process Sponsored by

2 Sponsored by Abstract With the release of Exchange Server 2007, Microsoft transformed its flagship engine into one of the most potent communications infrastructures in the industry. With its update to Exchange 2010 SP1, Microsoft honed the environment into a machine that can provide continuous service. Exchange 2010 s major improvements focus on ease of use, constant operation and controlled compliance. In addition, Exchange 2010 has been developed to be the central point of your unified infrastructure, linking all modes of communication , instant messaging, voice and fax into one integrated architecture. Yet, to take advantage of this infrastructure, you must move your current Exchange environment to the latest release. Even with the powerful feature set Exchange 2010 offers, planning, deploying and operating your new Exchange infrastructure can be challenging, especially if you choose to add capabilities such as mobile messaging, unified communications and instant messaging. With all of these moving parts, how can you know if you are ready to move on from your current Exchange system to Exchange 2010? And if you decide to make the move,, how should you proceed and avoid all of the ten most common pitfalls in an migration? About the Authors Nelson Ruest and Danielle Ruest are technology futurists focused on infrastructure design and optimization as well as continued service delivery. They have been working with complex infrastructures for over 20 years. Their systems designs include core application deployments such as and collaboration. They have also been working with virtualization for over ten years. Their recent books include Deploying Messaging Solutions with Microsoft Exchange Server 2007, an exam preparation guide for Microsoft Certification exam , Virtualization: a Beginner s Guide, a look at comprehensive virtualization infrastructure designs and Configuring Windows Server Virtualization with Hyper-V, an exam guide for exam number They both work for Resolutions Enterprises Ltd.

3 Table of Contents Overview... 1 State of Union... 1 Performing Exchange Migrations Identify when to migrate Prepare for the migration Plan for growth Prepare for change Keep it simple Build a unified infrastructure Integrate compliance Migrate with Confidence Focus on coexistence Finalize with flair... 9 Key Migration Issue Recap Final Thoughts... 10

4 OVERVIEW With the release of Exchange Server 2007, Microsoft transformed its flagship engine into one of the most potent communications infrastructures in the industry. With its update to Exchange 2010 SP1, Microsoft honed the environment into a machine that provides continuous service. Exchange 2010 s major improvements focus on ease of use, constant operation and controlled compliance. In addition, Exchange 2010 has been developed to be the central point of your unified infrastructure, linking all modes of communication , instant messaging, voice and fax into one integrated architecture. Yet, to take advantage of this infrastructure, you must move your current Exchange environment to the latest release. Even with the powerful feature set Exchange 2010 offers, planning, deploying and operating your new Exchange infrastructure can be challenging, especially if you choose to add capabilities such as mobile messaging, unified communications and instant messaging. With all of these moving parts, how can you know if you are ready to move on from your current Exchange system to Exchange 2010? And if you decide to make the move,, how should you proceed and avoid all of the ten most common pitfalls in an migration? Read on to learn the answer to these questions and better yet, perform your most successful Exchange migration. STATE OF UNION Microsoft has parlayed Exchange Server into one of the most popular messaging infrastructures in the industry. More than eighty percent of Fortune 100 companies currently run Exchange Server as their engine. Exchange Server is often the first choice for organizations implementing new systems. Exchange is also very popular with small to medium organizations through Microsoft`s all-in-one server offering: Windows Small Business Server. In addition, more and more clients are moving from other systems as migration and conversion tools improve with each new version of Exchange. Finally, Exchange is now the lead-in to the new Microsoft Unified Communications and Collaboration platform. The result is that Exchange is now more popular than ever. It all began when Microsoft released Exchange Server 2007 and delivered its first iteration of unified messaging services: blending , voice and fax into one seamless communication experience for users. Exchange Server 2007 also showed that messaging is much more than . Users were able to link to their messaging system through multiple platforms: Outlook, Outlook Web Access (OWA), Windows Mobile, Blackberry, iphone and other devices, and even through telephones with the new Exchange Attendant. In short, users could continually link to their communications lifeline no matter which device they used. Exchange 2007 also included built-in protection for this communications lifeline with anti-spam and antivirus scanning at the network perimeter or through hosted services. Exchange 2007 provided message and transport encryption both inside and outside the network if the destination servers support Transport Layer Security (TLS). It also added support for compliance requirements through transport rules, centralized message records management and journaling. In addition, Exchange 2007 protected core messaging databases through built-in data replication capabilities. The new release of Exchange Server 2010 adds even more functionality. This release includes integrated archiving and policy-based item retention. It provides a better mobile experience for users and their IT administrators with , voice mail, Really Simple Syndication (RSS) feed, Short Message Service (SMS) and instant messaging controls. Outlook Web Access, or as it is now called, the Outlook Web App now supports three major browsers: Internet Explorer, Firefox and Safari. Exchange 2010 also includes a role-based administration model, supporting delegation of administration. Mailbox storage can now run on any type of disk, even low cost Serial Advanced Technology Attachment (SATA) disks on Direct Attached Storage (DAS). Storage high-availability and disaster recovery has been improved through Database Availability Groups (DAG), a simpler data replication model than that included in Exchange Exchange 2010 provides better compliance support with direct intercept of messages, message encryption and new message blocking policies. With the release of SP 1 for Exchange 2010, Microsoft simplified the Exchange installation by providing a single-step install for all Exchange prerequisites. DAGs have been improved to support multiple sites, integrating site level protection into the Exchange high availability model. Archive mailboxes can now reside on any database and are no longer linked to the original user s mailbox. Retention policies can be created through the Exchange Management Console, making them more accessible to all administrators. Administrative mailbox search is easier to use. Mailbox imports and exports can run through the PST format and ActiveSync has been improved to provide much more detail on remote devices linked to the Exchange infrastructure. These features and more make a compelling argument for a rapid move to this new and improved engine. PERFORMING EXCHANGE MIGRATIONS But, despite these improvements, moving an Exchange infrastructure from one version to the next can be a daunting task. To reduce this level of complexity, you should focus on ten key aspects of an migration: 1. Identify when to migrate 2. Prepare for the migration 3. Plan for growth 4. Prepare for change 1

5 5. Keep it simple 6. Build a unified infrastructure 7. Integrate compliance 8. Migrate with confidence 9. Focus on coexistence 10. Finalize with flair Each of the following sections describes these aspects, then maps out some of the most common pitfalls you may face when moving from one infrastructure to another. With this information, you can move towards a new implementation of Exchange 2010 with full confidence. 1. Identify when to migrate The first place to start when you re looking at a potential system migration is identifying the right time to migrate. system migrations are not a simple task and can be overwhelming when undertaken. That s why you have to be sure that the moment you choose is the right time for you to migrate. With all of the moving parts of a complex project such as an migration, you want to guarantee that your operational disruptions will be kept to an absolute minimum when you actually perform the task. Migrations can be implemented for many reasons, but the three most common causes are: 1. Operational Your users and administrators become aware that the current system is simply not providing the functionality that it should. Outdated systems often lack the ability to integrate with the latest mobile devices or simply can t provide the services that a mobile or remote workforce requires. It becomes obvious that the system can no longer keep up with the structural changes of an increasingly dispersed workforce. When this occurs, you know it is time for change within your infrastructure. 2. Technological The technology used to run your operational systems is outdated and needs replacement. This opportunity for change occurs when you realize that your technological infrastructure needs to be updated, for example, when a new version of Windows Server is released. Microsoft has identified that 80 percent of their clients will perform a new network operating system (NOS) deployment when implementing new versions of Windows Server and Active Directory Domain Services (AD DS). This is no surprise since very few organizations will trust the operating system (OS) upgrade process when it comes to critical machines such as servers. Performing a NOS migration is also a very significant endeavor since it involves the replacement and update of all of the security principals in your network. These migrations are often performed by deploying parallel networks that gradually replace older systems as more and more functionality is integrated into the new network; in addition, these new networks can take full advantage of virtual machine technology, the latest data center trend. The best way to approach this is through a parallel network migration where you create a brand new network to host updated services (see Figure 1). Figure 1. The parallel network migration approach 2

6 3. Structural Complex technologies such as Active Directory Domain Services and Exchange Server are sometimes deployed in fast-track patterns that do not result in optimum configurations. This can often be caused by a lack of centralized planning and coordination during the deployment process. In these situations, administrators choose to restructure these foundational building blocks to streamline structural configurations, simplify operations and improve service levels. This second surgery approach will frequently require a complete overall of the infrastructure used to run these critical systems to provide for better efficiency and manageability. Any of these causes will have a direct impact on your system since they all require the upgrade or replacement of your mail servers. Once you identify your reason to migrate, you need to build a solid business case arguing for the migration. This business case should be presented to key stakeholders and provide solid documentation justifying the migration as well as its potential organizational benefits. Given these five different roles, many organizations will opt to start with the basic roles and then move on to additional functionalities, but even basic roles can be complex to architect. Basically, you need to answer key questions about your Exchange goals: Should you share roles on a same server? Which roles can be shared? Which should be? Where should each role be located? How should the roles be structured for later growth? The answers to these questions will help determine which type of Exchange organization you will run. For example, small to medium enterprises may decide to run simple Exchange organizations. The Single-Server Simple Organization has all of the Exchange Server roles except the Edge Transport Server hosted on the same server. Because of this, the Hub Transport Server role is directly connected to the Internet through the use of a firewall (see Figure 2. Prepare for the migration The next step requires you to focus on the Exchange building blocks and how they fit together into a single architecture. Exchange architectures range from very simple to highly complex structures. Running Exchange-only infrastructures still includes up to five server roles: Edge Transport Server (ETS), Hub Transport Server (HTS), Client Access Server (CAS), Mailbox Server (MBS) and Unified Communications Server (UCS). In addition, the new Database Availability Groups introduces a new server role, the File Share Witness (FSW), which is often integrated with the Hub Transport Server. Figure 2. The Single-Server Simple Organization Figure 3. The Standard Organization 3

7 2). Microsoft recommends using this configuration only if you are using Windows Small Business Server. Larger organizations will want to run more complex organizations. There are three possible models: The Standard Organization represents the most typical topology for Exchange deployment. Here, the internal Exchange server roles are not deployed on a domain controller, but rather, on member servers. This organization type remains standard however because the Service Delivery Location (SDL) the location that delivers the service and the Client Service Location (CSL) the location that clients link to while not necessarily being on the same server, will be within the same local area network (LAN) or physical site (see Figure 3). In a pure Exchange Server 2007 organization, this topology will include a single routing group since routing groups are no longer required. The standard organization is hosted within a single AD forest. The Large Organization represents a topology for Exchange deployment that is still hosted within a single AD forest but the forest includes more than five AD sites. It may also include more than five routing groups if older versions of Exchange are present. Also, the SDL and CSL are hosted in multiple sites and may even be separated to reside on different servers. There may be several AD domains within the forest, but the external messaging presence and the client namespace are common among all locations. This means that messages transfer to and from the Internet in a single location and are then routed to multiple points throughout the internal network infrastructure. It also means that while your different domains will have different fully-qualified domain names (FQDN), all of them will use the same root name. For example, The Phone Company has sites in different parts of the US and in Europe. Each area has its own domain to allow for different security strategies. While each domain has its own name, all domains use a common root: thephone-company.com (see Figure 4). The Complex Organization is the last deployment topology for Exchange and is designed for organizations that host multiple AD forests. Because of this, you need to synchronize multiple Exchange Global Address Lists (GAL). The best way to do this is to rely on Microsoft Identity Lifecycle Manager (MILM). Complex organizations usually stem from partnerships, acquisitions or mergers where each of the parties involved in the organization has its own identity and therefore, its own AD forest. There are several models of Complex Organizations: If you have multiple forests, but you have complete control of each of the forests, for example, when the forests are created within the same organization but are Figure 4. The Large Organization used to segregate business units, you can use an Exchange Resource Forest Topology. This enables you to maintain the strict boundaries between each forest. The Exchange Resource Forest uses a one-way trust towards the account forest(s), or the forests that contains the user accounts for each business unit. The Resource Forest contains duplicates of each user account within the account forests, but these duplicates are disabled. They are however linked to the user s mailbox. Mailbox creation is performed only in the Exchange Resource Forest and account creators in each of the account forests will not usually have the right to create these mailboxes unless that right has been specifically delegated to them. Additional account information such as phone numbers or office location must be added separately to the accounts in the Exchange Resource Forest. Be very careful about choosing the Resource Forest topology as it has very high administrative overhead because it does not rely on synchronization technologies to keep the data in each forest in synch. 4

8 Figure 5. Using Complex Organizations Figure 6. Increased disk activity in Exchange storage systems In situations where you must work alongside existing AD forests that may already contain their own Exchange organizations, you must use a Multiple Exchange Forest Topology. Because this topology includes multiple Exchange repositories, you must also synchronize information between the forests. This means synchronizing directory objects as well as replicating free/busy data (see Figure 5). Once again, this topology can be very complex to operate. As you can see, your Exchange topology can either be very simple or highly complex. Choose the best topology and aim for as simple an organization as possible. This will help control long-term administration costs. 3. Plan for growth infrastructures grow like nothing else, and you need to plan for it. Exchange 2010 makes this easy through a series of different features focused on potential infrastructure growth. For example, a key feature of Exchange is the storage of Exchange server configurations within AD DS. Each server role is Table 1. Exchange 2010 Server Role Requirements stored within AD DS. This means that whenever you want to add new server roles within your organization, all you need to do is actually add the role; it will then pick up its configuration parameters directly from the directory service. Two exceptions exist for this rule: The Client Access Server is based on the operation of Internet Information Server (IIS) and because of this, its configuration parameters are stored both within the directory and within the IIS Metabase. Because it is hosted in a perimeter network, the Edge Transport Server configuration is not stored in AD DS, but rather in AD Lightweight Directory Service (AD LDS). These characteristics of Exchange server roles make it easy to grow the infrastructure when needed, however, you should always keep track of system requirements when you add new servers into your infrastructure. Table 1 outlines the requirements for server roles for Exchange Note that in Exchange 2010, combining server roles aggregates requirements and lets you create massive machine configurations. This ensures better throughput. Another key area to watch and maintain is storage. You need to monitor user quotas to make sure there is enough space for them as usage grows. You also need to watch disk I/O performance to make sure systems meet the demand. Exchange Server 2010 increases disk I/O because of its new log shipping capabilities (see Figure 6). Ideally, you will rely 5

9 on the Exchange 2010 storage calculator to best determine your requirements. Note that Exchange 2010 can reduce I/O requirements by up to 50 percent or even more in some configurations compared to Exchange Learn to grow your infrastructure with care. Don t add additional servers unless they are absolutely necessary, but by being prepared for growth, your organization will be able to make the most of its migration. 4. Prepare for change Today s business market is rife with fast paced moves that often turn into mergers and acquisitions. When two organizations merge, they are likely to merge their IT infrastructures as well, including their messaging systems. In this case, two possible situations will occur: 1. One infrastructure will absorb the other. 2. A new infrastructure will be created to host the merged organizational systems. In the first case, the larger infrastructure will often be retained while the smaller will be absorbed and decommissioned once the migration is complete. In the second, both organizations will have the opportunity to create a brand new infrastructure, but as mentioned in the discussion on migration preparation, a parallel migration process will be required. While the parallel network is a proven process is a proven process that can minimize service disruption it can still cause strife for end users and administrators alike. However, if you make sure your infrastructure is ready for change if and when it happens, then you ll be ready to absorb new users and be able to dramatically reduce the possibility of service disruption. You can do this by planning for growth and preparing a world-class Exchange architecture. 5. Keep it simple This world-class infrastructure will most likely be kept as simple as possible. Multi-forest Exchange deployments require either additional management tools to synchronize changes between the forests or extensive administrative overhead to make changes in multiple environments. In addition, they may even run different versions of Exchange in each forest. This is why you should avoid complex Exchange designs such as multi-forest implementations. Figure 7. Using trees instead of forests for multiple public identities administrative reasons, for example, to maintain multiple public identities, then you should look to a single forest with multiple trees (see Figure 7). Multi-forest systems may be improved by new integrated forest environments that achieve the same goals. This Consolidation enables you to simplify your Exchange deployment and system administration, as well as ensure only one version of Exchange runs within your organization. If multiple forests are used for security purposes, then you can simplify your infrastructure through the use of a single produc- Large scale deployments can also increase administrative overhead because of server sprawl. Controlling the scale of your deployments when deploying always-on infrastructures will help minimize the operational requirements for the system. Organizations that run either multi-forest or large scale environments should definitely look to infrastructure simplification through consolidation If multiple forests are deployed for Figure 8. Using a single production forest 6

10 Figure 9. Completing the unified Exchange infrastructure tion forest along with multiple user identities for users that require access to other forests. For example, an organization that runs both a production forest and a development forest should run its system within the production forest and grant its developers standard user accounts within this forest. The developer can then rely on a different, perhaps administrative, level account, to access their work within the development forest (see Figure 8). Both models will greatly simplify administrative tasks and make it easier for organizations to take full advantage of the feature set of their system. However, in order to arrive at either infrastructure, you ll need to perform an consolidation through a migration process. 6. Build a unified infrastructure Exchange Server architectures include much more than simple services today. In fact, they also include unified communication services. These services are achieved through the addition of new features to the basic infrastructure. You can add on to Exchange through a series of different methods: 1. Integrate voic with unified messaging 2. Provide instant messaging using Microsoft Office Communications Server 3. Integrate audio and video with Microsoft Office Live Meeting 4. Add mobility by supporting Windows phones, BlackBerry devices or even the Apple iphone Integrating new functionalities will help increase user productivity, but each change will modify your overall infrastructure. Keep in mind that each new service also requires a high availability component (see Figure 9). If you have deployed a unified infrastructure with Exchange 2007 and are now moving on to Exchange 2010 SP1, then you ll need to include the integration of your unified services within your migration plan. 7. Integrate compliance Most organizations are bound by some form of regulation. Meeting compliance for these regulations means one main thing: providing valid documentation about content. Fortunately, Exchange includes several tools to support compliance. Transport policies control in transit. Journaling policies control messages by content. And messaging records management policies control message retention on mailboxes. All of these tools are improved in Exchange 2010: A new integrated archiving feature provides a better model for retention. Users can now integrate their local personal storage (PST) files into their centrally-stored mailbox and then use policies to archive older content. While it is stored centrally, archived content is always available to end users. 7

11 Figure 10. Supported transitions to Exchange 2010 The new multi-mailbox search feature can now be delegated to compliance officers. Organizations that need to verify content for compliance can now do so through this powerful feature. Better yet, this feature is not assigned to IT administrators, but to the officers that are responsible for the organization s compliance policies. New legal hold policies can protect even from deletion. If end users want to delete content that should be retained for compliance, administrators can set legal hold policies to protect it. Finally, you can gain even better compliance by integrating information rights management policies to your Exchange systems. This is most often done by deploying Active Directory Rights Management Services (AD RMS) to your infrastructure. AD RMS will then support retention policies and help generate secure templates for all of your organization s content. With Exchange 2010, there is no reason you cannot maintain compliance to any regulation affecting your organization. Once again, you ll need to ensure that these regulations, both existing and new, are integrated to your Exchange migration plan. 8. Migrate with Confidence Microsoft included very compelling features in Exchange 2010 that make a compelling business cause for immediate implementation. Because of this, many organizations will want to move rapidly to gain access to them. But before you can migrate, you need to fully understand your current infrastructure. Answer these questions: Are there any unused mailboxes? Is there content that should be archived? Can you improve your high availability infrastructure? Are there any roles that could be refined? Just how many mailboxes will be moved/transitioned? Once you have the data in hand, you can look to how you will move to Exchange Microsoft introduced the concept of transitions versus migrations with Exchange Transitions support the move to a newer version of Exchange while retaining the existing Exchange organization and migrations support the move to a newer version of Exchange through the creation of a new Exchange organization. To move to Exchange 2010, you can rely on either transitions or migrations. In this case, transitions are supported from Exchange 2003 or Exchange 2007 (see Figure 10) and migrations are supported from a variety of sources (see Figure 11). Once you ve identified which process you need to work with, you should dig deeper to identify which methodology best supports this process. 9. Focus on coexistence Moving hundreds and perhaps thousands of user mailboxes from one system to another cannot happen overnight. Because migrations take time, coexistence is an important part of any system migration plan.. Your coexistence plan should include both technological and administrative coexistence strategies. Technological coexistence should focus on the distribution of services between older and newer systems. Basically, you ll want to integrate the operation of mailbox services between the legacy system and the newly deployed Exchange 2010 servers. Other services, such as unified communications will run mostly on the new infrastructure. But mailbox delivery operations should continue and be directed to the appropriate mailbox database until all mailboxes are migrated. Issues will often arise when you try to synchronize more complex aspects of the infrastructure, such as calendaring and mobile device support. 8

12 Figure 11. Supported migrations to Exchange 2010 Administrative coexistence often means that administrators must learn to use both legacy and new tools to perform system maintenance and administrative tasks. Ideally, you ll be able to have two groups of administrators. You need one group to focus on legacy systems and one on new systems as well as the ability transit administrators as you transit mailboxes. While this often works best in large organizations with multiple administrators, and provides the simplest path to administrative coexistence. In the simplest transitions, you run multiple systems at the same time (see Figure 12) as follows: 1. Install a core set of new system roles. 2. Deploy new mailbox databases. 3. Move the mailboxes from legacy servers to Exchange 2010 servers. 4. When a legacy mailbox server no longer contains user data, move it offline. 5. Decommission the legacy server when it is no longer required. 10. Finalize with flair When you re ready, you can complete the migration and prepare for ongoing Exchange 2010 operation. Planning for scheduled administration as well as automating common administrative tasks is the final part of your migration process. Fortunately this is very easy to do in Exchange since the Exchange Management Shell is built on top of Windows PowerShell; all commands from either the graphical interface or the shell are always generated and executed in PowerShell. Administrators never need to write a script again just go through a graphical Wizard and capture the script it generates. Because of this, Exchange provides the simplest path to automation. In addition, new troubleshooting tools provide better insight into the Exchange ecosystem. Server configurations are stored into Active Directory Domain Services and are automatically replicated to new servers as they are added. And, the Exchange Best Practices Analyzer is integrated to the Management Console and is always available to optimize the ecosystem. The best way to ensure the proper operation of your system is to use a standard maintenance schedule. This schedule 9

13 should include daily, weekly, monthly and ad hoc activities. You should prepare the schedule and apply it rigorously. To simplify the schedule, categorize your maintenance activities and include the following: The physical environment servers and the datacenter Security elements of the infrastructure Disaster recovery components Resource utilization CPU, memory, disk and network Performance server, network, IIS and MAPI Mail flow status use test accounts to verify components Reporting review all logs and generate status reports Use PowerShell to automate most of the tasks and generate reports which that will be delivered to your Inbox. For a sample task automation schedule for Exchange, look up Deploying Messaging Solutions with Microsoft Exchange Server 2007 by Ruest and Ruest. FINAL THOUGHTS systems are the lifeline that many organizations rely on to make their operations a success. Exchange ecosystems are complex infrastructures even in the simplest organization configurations. And, when you unify Exchange, you add levels of complexity. The best way to ensure that the lifeline continues to work at its best during a migration is to rely on a specialized tool that is solely designed for the purpose of supporting the migration process. Such a tool will help ensure that this critical infrastructure move is the very best you can accomplish. This tool should include the following features: Support for the migration of multiple versions of Exchange. Support for the synchronization of both Active Directory and Exchange data. Support for the migration of general mailbox data as well as public folders, calendar information, and mobile device configurations. Figure 12. Maintaining coexistence during a migration Support for coexistence during the migration. Support for the update of Outlook user profiles. Centralized management capabilities. Migration status reporting. Secure migration control throughout the migration process. Quest Migration Manager for Exchange includes all of these features and more. If you want a world-class migration and you want a simplified migration process, then you should take the time to evaluate Quest Migration Manager for Exchange. Find out more at Using the right tools, focusing on the right issues and using the very best migration process can help you move on to the next generation of and unified communication services with Exchange 2010 as well as help make the move seamless and stress free. Sponsored by 10