No one is right all the time, not even highly paid external consultants who plan Exchange deployments. However, Exchange consultants need to get a deployment's organization design right the first time they plan it. Organization design is a major part of an Exchange project. The Exchange organization establishes how all of a deployment's servers communicate with one another. Deployment designers spend hours deciding how to group servers into sites, how to use different types of connectors to link sites, and how to build a corporate Directory that Exchange Server synchronizes among sites. After planners implement an organization design, making changes to fundamental parts of the organization becomes prohibitively difficult. For example, until recently changing the name of an organization required you to reinstall Exchange Server on all the organization's servers.
This difficulty of changing an organization creates problems even when organization planners make no mistakes. Administrators of networks with appropriate designs sometimes need to integrate two sitesfor example, when they upgrade the bandwidth of intersite connections. Network availability, in terms of speed and quality, is an enormous influence on site design. I recommend connecting servers to form a site only when you can provide at least 128Kbps of bandwidth between all the servers. However, the fewer sites you have in an organization, the easier the organization generally is to administer. So if bandwidth between two existing sites increases, administrators might want to combine the sites.
Business developments can also impose stress on a messaging system. Consider the position of messaging administrators when their company acquires another company. Both companies might use Exchange Server, but they're unlikely to use the same name for their organizations. Merging multiple sites takes a huge amount of coordinated effort from all administrators involved, and such a merger can grind an internal messaging system to a halt.
Technology improves, business arrangements change, and network planners make mistakes. Expecting Exchange to be flexible enough to accommodate change seems reasonable. Microsoft has finally provided a tool to help you migrate servers from existing sites and merge Exchange sites. Microsoft's release of the Exchange Move Server Wizard (formerly code-named Pilgrim) makes rebuilding an Exchange organization more feasible than the task was previously. Moving servers from one organization to another still requires a lot of planning, but the wizard is the tool you need to perform the brain surgery.
Why Is Moving Servers Complicated?
Comparing the intersite migration of Exchange Server machines to brain
surgery might seem extreme, but integrating two large Exchange sites requires a
great deal of effort and attention to detail. To understand how complex the
process is, think about how the Directory names objects.
The Directory allocates a unique distinguished name to all objects--including servers and mailboxes--within the Directory. Exchange ensures each object name's uniqueness by using the organization name as the root, so objects inherit their organization and site names as part of their distinguished name. Every object in the Directory has a root of
/o=<Organization Name>/ou=<Site Name>
Any change at an organizational or site level (such as moving a server from one site to another) requires you to change the distinguished name for every object associated with the move. You can't just drag a server from one site to another.
Examine the distinguished name of my server DBO-EXCHANGEIST, which Screen 1 shows. To view this information, I started Exchange Administrator in raw mode by appending the /r switch to admin.exe. I selected DBO-EXCHANGEIST and selected File, Raw Properties. The Obj-Dist-Name property contains the distinguished name. In Screen 1, Obj-Dist-Name is
/o=Digital Equipment Corporation/ou=Dublin/cn=Configuration/cn=Servers/cn=DBO-EXCHANGEIST
This distinguished name tells me that this server is in the Dublin site in the Digital Equipment Corporation Exchange organization.
To move this server to another site in the same organization, I would have to change the /ou=Dublin part of the distinguished name of all the objects that Exchange associates with the server, including mailboxes, public folders, and distribution lists. I would need to adjust the Directory's organizational information about the source and target sites so the source site knows that the server left it and the target site knows that the server joined it. This move would also affect the contents of the Information Store (IS) because Exchange Server stores message recipients' distinguished names alongside mailbox data. Finally, if I use intersite replication, I would need to make sure Exchange Server replicated all my changes to all the other servers in the organization.
A Wizard Appears
Microsoft knew for a long time that it needed to produce a tool for moving
servers, and recent high-profile mergers of companies that use Exchange Server
added fuel to the fire. Compaq and Digital both use Exchange Server, and
the companies have a total of more than 400 Exchange Server systems worldwide.
Imagine merging 400 servers into one organization if the task involved manually
changing the name of every object in one of the organizations.
The Move Server Wizard was originally part of Exchange Server 5.5 Service Pack 1 (SP1), but Microsoft removed the wizard from SP1 at the last minute to iron out a few bugs. The Move Server Wizard is now available for downloading at http://backoffice.microsoft.com/downtrial/moreinfo/ex55sp1wizard.asp.
The wizard helps administrators perform four functions. The rename function lets you move a server from a one-server site to form a new site. The split function lets you move a server from a multiserver site to form a new site. The move function lets you move a server from a multiserver site to another site. When you merge two sites, you use the move function to move all the site's servers that don't host message or directory replication connectors. Then, you use the merge function to move the site's last server, which hosts the site's connectors, to the other site.
Microsoft deliberately chose these terms to identify the type of operation each function offers. Forming a new site and joining an existing site are fundamentally different operations. When you form a new site, the site inherits its configuration data and schema directly from the server that you've renamed or split off from an existing site. When a server moves into an existing site, the server inherits that site's configuration. For example, a server that moves into an existing site picks up the site's email addressing defaults, and Exchange Server generates new email addresses for all the server's mailboxes. When a server forms a new site, its mailboxes keep their existing addresses.
Preparing Servers for the Move
Before you can use the Move Server Wizard to rename, split, or move a server
or merge sites, the servers you're planning to move must run Exchange Server 5.5
SP1. SP1 makes several changes to the IS that support moving a server and takes
advantage of an Exchange Server 5.5 update to the Message Transfer Agent
(MTA) that allows redirection of mail to a moved server. Exchange Server
accomplishes MTA redirection through a new address type that Microsoft calls
X.500. (These addresses have no connection with the international X.500
standard; Microsoft uses the address type only to differentiate the wizard's
addresses from the addresses of day-to-day messaging operations.) A server's
X.500 addresses hold the old internal addresses for mailboxes you move with a
server. After users' mailboxes move, you can reply to messages the users sent
before the move as if the users' addresses hadn't changed. Your replies will
contain the users' old addresses. When the MTA receives your replies, it uses
the X.500 addresses to resolve the old and new addresses, then sends the reply
to the server's new location. When you move a server into an existing site, the
server in the destination site that you tell the wizard to query for
configuration information about the site must also run Exchange Server 5.5 SP1.
The other servers in the site can run Exchange Server 5.5 or Exchange Server
5.0.
Generally speaking, the Move Server Wizard can move only server-specific data. You must review everything that a server shares (or potentially shares) with other servers before the move, and move those items manually. Items that servers can share include public folder replicas (including a replica of the site's Offline Address Book), messaging connectors, directory replication connectors, the Key Management Server (KMS), and Outlook Web Access (OWA). The most important items that you need to manually move are public folder replicas and messaging and directory replication connectors. Not many servers run KMS because few organizations implement Exchange Server's advanced security features. More servers host OWA than KMS, but moving OWA is straightforward; it requires only reconfiguring the software after the server moves to its new site.
Moving public folders and connectors requires more care and time. First, you must identify the set of public folder replicas on the system you're planning to move. Use Exchange Administrator to examine the properties of the Public IS and retrieve a list of public folders. Then, select each folder and remove the replica from the server you're moving. If the replica is the only instance of the folder in your server's site, you need to arrange for another server in the site to hold a new instance of the public folder if you want the site to retain a replica of the folder. If a remote site that has limited administrative access to your server's site owns the public folder in question (this capability is a new feature in Exchange Server 5.5), you must ask the administrator of the owning site to create the new instance. After you have removed all the public folder replicas from your server and created new instances on other servers, wait about a day before moving the server to ensure that Exchange Server has replicated your new public folder replica list to the other servers in the organization.
Moving connectors requires coordination across multiple sites. In the simplest scenario, the server you want to move is a target for a remote site connector. In this case, you merely remove the server's name from the list of target servers in the sites on both sides of the connector. Moving a bridgehead server is more difficult. X.400, Simple Mail Transfer Protocol (SMTP), and directory replication connectors operate on the bridgehead principle, by which a bridgehead server hosts a connector on behalf of a site. If the server you want to move serves as a bridgehead for any connectors, you must move the connectors to another server. Exchange Server automatically announces bridgehead servers to the sites on either side of the connection, so when you move the connector to another server, you must make sure to change the connector's configuration in the same way on both sites. Let replication carry details of a connector's configuration changes to all parts of the organization before you move the server that originally held the connector.
Finally, when you work with the Move Server Wizard, make sure your server's MTA queues don't contain messages waiting to go to other sites. A queue that has more than 100 messages is a danger signal. Investigate why the queue accumulated the messages and reduce its size before you proceed with moving your server.
Preparing Users for the Move
Moving a server affects users in several ways. The server is obviously
unavailable to users during its move. In addition, you need to ask remote users
to connect to the server and send mail they have queued up before you commence
the move. After the server moves, all users who connect to the Exchange Server
computer via a Messaging API (MAPI) client--such as the Exchange client or
Outlook--must recreate their user profile before they can connect to the
server. (User profiles contain the distinguished name of the user's mailbox, so
after the server that holds the mailbox moves, the old profiles won't work.)
Users' offline stores hold slave replicas of folders on an Exchange Server computer; they synchronize their contents with the server folders you specify and make those folders available for offline access. (For more information about offline stores, see "Exchange and Groupware," July 1997.) Remote users who have an offline store must delete and recreate their offline store if you move a server that hosts folders the offline store points to. The move affects the contents of the IS, so the offline store is no longer valid. You can't scan through an offline store and update its contents to match the IS; your only alternative after moving a server is to recreate all offline stores that include replicas of folders on that server. Be aware that offline stores can be large. My offline store is larger than 250MB. Recreating large files takes time, especially across slow links.
Finally, if your organization uses advanced security, moving a server invalidates your current X.509 certificates. You need to issue new keys after the move, so before the move, your users must use their existing keys to decrypt all encrypted messages. If users fail to decrypt their messages, you permanently lose the contents of the encrypted messages.
The Wizard Begins
Immediately after the Move Server Wizard starts, it checks the
server's configuration. Screen 2, page 136, shows the first screen you see in
the wizard. Microsoft takes great care to outline the risks of attempting a move
without proper preparation. I agree with all the warnings. Only fools rush to
move servers without good, detailed planning.
After you review Microsoft's warnings and click I Understand to express that you are prepared to proceed, the wizard checks the server's configuration. It carefully examines messaging connectors to ensure that moving the server won't affect message flow within the organization. If the wizard discovers that the target server connects its site to another site, you'll see a message similar to the one Screen 3, page 136, shows.
If the wizard doesn't detect any connectors on the server you want to move, it prompts you to decide whether to move the server into an existing site or create a new site. This decision is the most fundamental choice you make in the process of moving a server. Screen 4 shows the dialog box in which you make this choice. (This dialog box looks similar to the dialog box in which you decide whether to create a new site or join an existing site when you first install Exchange Server on a new server.)
Exchange Server associates every mailbox with a Windows NT user account. If your server move also involves changes to your NT environment, you must account for those changes in your plan for moving the server. For example, suppose each department of your company operates a separate NT domain. If you want to move an Exchange Server machine from one department to another, you need to update the server's mailboxes to run under NT accounts in the new department's domain. The wizard makes all the necessary changes to the Exchange Server Directory, but you need to create the new NT accounts and inform users when their NT accounts and passwords change.
Go or No Go?
After the Move Server Wizard finishes checking your environment, it displays a status report, as Screen 5, page 138, shows. At this point, you must decide whether to go ahead with the server move. The wizard hasn't yet made any changes to the Directory or IS, but the wizard's preparatory checks have confirmed thatit can move the server. You can run the wizard several times up to this point to confirm that everything's ready to go before you commit yourself to the move. The wizard displays a dialog box or error message for any problems it detects. These boxes let you make decisions (such as how to handle distribution lists) or tell you to perform certain tasks before proceeding.
Running the wizard to test move conditions is an excellent way to ensure that you're ready to perform a move. You might want to run it a few days before the move just to make sure you don't need to perform any additional preparatory steps. Preparing for a weekend move only to find at the last minute that a messaging connector at a remote site still points to the server you want to move is not pleasant.
After you click I Understand, the Move Server Wizard swings into action and begins processing the move. Screen 6, page 138, shows the progress report that Exchange Server displays as the wizard proceeds. The wizard does all of its work on the server you're moving. This work doesn't affect any of the other servers in the organization until Exchange Server introduces the server into the target site when the Exchange services start after the move is complete.
The Wizard at Work
Behind the scenes of a server move, the wizard does a lot of work similar to
the processing that installing Exchange Server on a new server requires. In new
installations, Exchange Server prompts you for the name of a new site or the
name of a server in an existing site from which Exchange Server can fetch
information about the site. Equipped with this information, the installation
procedure builds a Directory for the new Exchange Server system. When the
installation procedure is complete and the Exchange services start, the
Directory holds enough information for the server to establish a new site or
begin intrasite replication with other servers in an existing site. Intrasite
replication completes the process of integrating a server into an existing site;
through replication, Exchange Server populates the new server's Directory with
details about the configuration of servers, connectors, mailboxes, and other
objects in the site.
The Move Server Wizard must perform similar tasks, but it starts with a full Directory that contains objects' distinguished names, which must change for the move to be successful. To change objects' distinguished names, the wizard creates a temporary database at the beginning of the move process, then populates that database with objects that must move and configuration data for the target site. This configuration data includes details about other servers in the site and the site's default addressing or protocol support. If the server forms a new site, it inherits this configuration information from its old site. If the server joins an existing site, the wizard extracts the necessary configuration data from a server in the target site and inserts that information into the temporary database.
Because the IS links mailbox data to users' distinguished names, the wizard also needs to update the IS. Rebuilding an IS is a far more serious undertaking than rebuilding the Directory. The IS is usually several orders of magnitude larger than the Directory, and many installations don't have the disk space necessary to build a temporary IS to contain changes to mailbox data. For this reason, the wizard makes the necessary changes to the server's IS rather than creating a temporary database for changes. My tests of the wizard reveal that servers make necessary changes to distinguished names in the IS at around 3GB to 4GB per hour. This figure varies depending on the server's hardware configuration.
When the wizard has verified that your server is ready to move, it shuts down the Exchange services and tells Exchange Server to replace the old site's Directory with the temporary database. When the wizard restarts the Exchange services, the services use the contents of the new database as the server's Directory, and the server either forms a new site or joins the existing site that the new Directory describes. Intrasite Directory replication can take a few hours because Exchange Server must completely synchronize the new server's Directory with the Directories of the site's other servers. Most servers in my tests synchronized in less than 2 hours, but the time synchronization takes depends on the size of the Directory. The Directory my tests replicated was 60MB; it contained information about 16 sites and approximately 17,000 recipients. Smaller organizations' Directories will take less than 2 hours to synchronize; larger organizations will take more time. Replicating the Global Address List (GAL) appears to take the longest time. Compare the total number of objects that the GAL on the moved server reports with the total number of objects in the GAL on another server in the site to determine when replication has finished.
After the Wizard Finishes
When the wizard finishes, it displays a screen that contains instructions
detailing the tasks that you must complete to finish the move, as Screen 7
shows. Make sure the Exchange services restart successfully on your moved
machine, and use the Exchange Administrator to verify that the server is now
part of the new site. Then back up the system. Review the Exchange Server
documentation or Help files before beginning your post-move tasks.
You can't move an Exchange Server system without breaking links between objects that depend on the Directory. After the wizard completes its work and the server is part of its new site, you need to apply the finishing touches to your move and reestablish all the links that the wizard doesn't handle. Reinstall OWA on the moved server. Configure new replicas for all the public folders you want on the server. Reset permissions on public folders to let users on the moved server retain their access rights. Issue new advanced security keys. Update management utilities such as link and server monitors and references to the server in third-party system-management tools. Review the content of distribution lists to make sure that everyone who needs to be on each list is on the list. Check to see whether the move broke any directory links, such as links between a manager and the manager's subordinates, and repair any broken links. Delete any duplicate address book views you find. (Duplicate address book views can occur when the source and target sites define the same address book view. For more information about address book views, see "Microsoft Exchange Server 5.0 Smoothes the Rough Edges," April 1997.)
If you split off a server to form a new site, you must also create messaging and directory replication connectors to link the new site to the remainder of the organization. Verify that your connectors work before you set up Directory and public folder replication for a new site. (For more information about establishing directory replication connectors, see "Exchange Directory Replication," November 1998.)
The final step in the process is to restart the MTA on the moved server. You might be tempted to get all the services up and running as soon as possible after the wizard finishes, but you'd be wise to wait a while. I like to wait until intrasite replication is complete and the whole site stabilizes before restarting the MTA. Exchange Server uses the MTA only for sending messages outside the site, so waiting to restart the MTA doesn't affect intrasite replication or users' ability to send messages. Waiting ensures that when the MTA comes back online, it is ready to accept incoming messages that the senders addressed to the server in its old site and redirect them to the valid addresses in the new site.
Be Paranoid!
Proceed carefully when you make changes of this magnitude to an Exchange
organization. Before you start moving a server, make sure that the network is in
good health and no replication messages exist in MTA queues. Perform a full
backup of the Directory and ISs on the server that you're going to move. As soon
as the wizard moves a server to a new site, perform full backups of the moved
server and all the servers in the target site. The move applies a huge number of
changes to the Directories on all the servers that the move affects, so be sure
to protect yourself with backups. Nothing is worse than having to restart
the process if you're unlucky enough to face a catastrophic hardware failure
after you move servers to a new site.
The Move Server Wizard isn't perfect, but it takes some of the pain out of reorganizing an Exchange organization or site. Moving a server still requires a lot of work. The wizard does its best, but it's generic software that can't be aware of all the twists and turns that exist in the wildly different implementations of Exchange Server around the world. Take the time to properly plan your move, run the wizard a couple times to verify that everything's ready before you start moving anything, and proceed with caution. And keep in mind that backups are your best friend. Always know how you can back out of a situation if you need to.
