Está en la página 1de 8

E-Guide

Ensuring Exchange 2010 migration success


The arrival of Exchange 2010 means exciting new features and management capabilities for many administrators, but before reaping the rewards of this upgrade you first must tackle the migration process. In this expert e-guide from SearchExchange.com, learn best practices for migrating to Exchange Server 2010. Let this resource be your checklist as you map out your deployment strategy. Learn key steps that cant be overlooked and find out how to ensure success whether youre upgrading from Exchange 2007 or 2003.

Sponsored By:

SearchExchange.com E-Guide Ensuring Exchange 2010 migration success

E-Guide

Ensuring Exchange 2010 migration success


Table Of Contents
Issues to Watch for During an Exchange Server 2010 Migration Smoothly transition from Exchange Server 2003 to Exchange 2010 Resources from Dell, Inc. and Intel About Dell, Inc. and Intel

Sponsored By:

Page 2 of 8

SearchExchange.com E-Guide Ensuring Exchange 2010 migration success

Issues to Watch for During an Exchange Server 2010 Migration


Brien Posey, Contributor When upgrading from Exchange Server 2007 to Exchange 2010, Microsoft requires that you perform a clean Exchange 2010 installation onto a separate server and then migrate mailbox and public folder content to the new server. You can no longer perform an in-place upgrade. Because of this, Exchange 2007 and Exchange 2010 must coexist from a short period of time while data is being migrated, to as long as "indefinitely." No matter how long the coexistence lasts, many Exchange organizations experience unexpected issues during that time. Here are a few problems you may encounter and their fixes.

Edge Transport Server Issues


There appears to be some confusion as to how the edge transport server works in an Exchange 2007/Exchange Server 2010 coexistence situation. When you deploy an Exchange 2007 edge transport server, you must create an edge subscription on your hub transport server. The edge subscription links the edge transport server to Exchange Server 2007's transport pipeline. Like Exchange 2007, Exchange Server 2010 also includes both a hub transport server role and an edge transport server role. During coexistence, an Exchange 2007 hub transport server resides alongside an Exchange 2010 hub transport server without any problems. And you can continue to use an Exchange 2007 edge transport server indefinitely. However, things get tricky when you begin to phase out your Exchange 2007 servers. Exchange 2007 doesn't allow you to uninstall the hub transport server role without first deleting the edge subscriptions that are bound to that server. When you delete these subscriptions, it has an effect similar to orphaning your edge transport server.

Sponsored By:

Page 3 of 8

SearchExchange.com E-Guide Ensuring Exchange 2010 migration success

If you're trying to phase out your Exchange 2007 servers, the method is to deploy an Exchange 2010 edge transport server. Not only can this server peacefully exist with your edge transport servers, but you can load balance SMTP traffic across multiple edge transport servers. When you deploy your first Exchange 2010 edge transport server, it must be subscribed to an Exchange 2010 hub transport server. You can't subscribe an Exchange 2010 edge server to an Exchange 2007 hub transport server. Once you have two parallel edge servers and two parallel hub transport servers in place, you can change the MX record to point to your Exchange 2010 edge transport server. After verifying that mail flow is working, you can remove the edge subscription from the Exchange 2007 hub transport server and decommission both the Exchange 2007 hub transport and edge transport servers.

Issues When Managing Distribution Groups


A common complaint after migrating to Exchange 2010 is that the new server breaks distribution group management. When a user opens Outlook 2007 and attempts to manage his or her distribution groups, he received the following error message: Changes to the distribution list membership cannot be saved. You do not have sufficient permissions to perform this operation on this object. By default, Microsoft designed Exchange Server 2010 so that users cannot manage their own distribution groups unless they have specific permissions to do so. To give users the ability to manage their distribution groups, go into the Exchange Control Panel and follow these steps: 1. 2. 3. 4. Choose the option to manage My Organization. Select the User Roles option, which is found in the Users and Groups section. Select the Default Role Assignment Policy and click the Details button. Check the My Distribution Groups box (Figure 1).

Sponsored By:

Page 4 of 8

SearchExchange.com E-Guide Ensuring Exchange 2010 migration success

Figure 1. By selecting the My Distribution Groups check box, you can allow users to manage their own groups in Exchange 2010. If you don't want to give users the ability to create and remove distribution groups, Microsoft created a script that removes the option completely.

Sponsored By:

Page 5 of 8

SearchExchange.com E-Guide Ensuring Exchange 2010 migration success

Smoothly Transition from Exchange Server 2003 to Exchange 2010


When migrating from Exchange Server 2003 to Exchange Server 2010, you can't perform an in-place upgrade to Exchange Server 2010. Microsoft requires that organizations perform a clean Exchange Server 2010 installation onto a separate server and then to migrate mailboxes and public folder content to the new Exchange 2010 server. This means that you'll need Exchange Server 2003 and Exchange 2010 to coexist either short-term -- a couple of hours -- or long-term. In either case, coexistence can be difficult because Exchange Server 2003 and Exchange 2010 are very different. This tip explains some of the key differences between the two versions and some of the tasks you'll have to perform as part of the transition.

Active Directory Issues


Before deploying Exchange Server 2010 in an Exchange 2003 organization, you must prepare Active Directory and existing Exchange servers. This process isn't too laborintensive; however, it does involve making a few irreversible changes to both Exchange and Active Directory. It's good practice to backup of all your Exchange servers and at least a couple of your domain controllers before starting. You'll have to perform some the following configuration tasks: Verify that any domain containing users with Exchange server mailboxes are set to Windows Server 2003 domain native mode. Make sure that all of your global catalog servers are running Windows Server 2003 SP1 or higher. It's also acceptable to run Windows Server 2003 R2 or Windows Server 2008. Ensure that your Active Directory schema master is running Windows Server 2003 SP1 or higher. Again, Windows Server 2003 R2 or Windows Server 2008 is acceptable.

Sponsored By:

Page 6 of 8

SearchExchange.com E-Guide Ensuring Exchange 2010 migration success

Check that any domain controller that's hosting a flexible single master operations role is running at least Windows Server 2003 SP1. Set the Active Directory forest to Windows Server 2003 forest functional level. Remove any Exchange 2000 or Exchange 5.5 servers from your organization and set the existing Exchange server to native mode.

Disable Link State Updates


Exchange Server 2003 uses link state updates to keep track of which routes are used for to communicate between routing groups; however, Exchange Server 2010 doesn't use linkstate updates. In smaller organizations, this architectural difference doesn't pose a problem; Exchange 2003 will continue to use link-state information. Exchange 2010 servers will ignore link-state updates. In larger organizations, there are often multiple Exchange Server 2003 routing groups. You may have to create multiple routing group connectors between Exchange Server 2003 and Exchange 2010. In these situations, you must suppress minor link-state updates or routing loops may occur. To disable minor link-state updates, modify the registry on each Exchange 2003 server. But this can be dangerous; making a mistake can often destroy Windows and Exchange Server. To suppress link-state updates, open the Registry Editor and navigate to:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc\Parameters Right-click on the Parameters container and select the New | DWORD Value command. Name the new parameterSuppressStateChanges and assign it a value of 1. To finish, close the Registry Editor and restart the SMTP service, the Microsoft Exchange MTA stacks service and the Microsoft Exchange routing engine service.

Sponsored By:

Page 7 of 8

SearchExchange.com E-Guide Ensuring Exchange 2010 migration success

Resources from Dell, Inc. and Intel

Presentation Transcript: Exchange 2010 Roadmap Series - Transition and Migration Exchange 2010 Roadmap Series: Virtualization Podcast: Exchange 2010 Roadmap Series: Performance And Sizing

About Dell, Inc. and Intel


Dell and Intel are strategic partners in delivering innovative hardware solutions to solve your most challenging IT problems. Together we are delivering virtualization optimized solutions to maximize the benefits of any virtualization project. www.dell.com

Sponsored By:

Page 8 of 8

También podría gustarte