With the release of Exchange 2000 Server firmly on the horizon, you can start developing a strategy for moving your current infrastructure to Windows 2000 and Exchange 2000. Migrating from Windows NT/Exchange Server 5.5 to Win2K/ Exchange 2000 isn't a simple task, and the migration will probably take longer than you imagine. However, creating and following a plan can help you get through the migration period as quickly as possible. Migrating quickly not only minimizes additional costs that result from running two infrastructures but also reduces stress on users, administrators, computers, and the network.
Exchange 2000 differs greatly from its predecessors, so simply adapting your current infrastructure won't work. Instead, you need to start with a clean slate. To help you plan your migration, I've developed a list of obstacles that frequently hinder migrations. These obstacles are real-world problems that companies have faced while migrating their Exchange systems. The obstacles are
- Too many NT domains
- Too many servers in production
- Too many Exchange sites
- Too many connectors
- Too many people with administrative privileges
- Too much replication between servers
Discussing each of these topics in detail could fill a book, so here are just some essential points to consider when you're creating your migration plan.
Too Many NT Domains
Exchange Server 5.5 depends on NT for authentication and security. Users must secure credentials from a domain controller before Exchange lets them connect to a mailbox, and administrators must log on to an account that has Exchange-specific permissions to perform administrative tasks. You can use two designs in Exchange Server 5.5. You can either place the Exchange servers in a master account domain or create a separate resource domain to hold just the Exchange servers. Small to midsized implementations typically use the former approach; corporate deployments favor the latter.
In NT/Exchange Server 5.5 systems, resource domains are a good way to isolate Exchange servers from other applications so that people who hold administrative rights for other reasons (such as to manage user accounts or file and print services) can't make changes to an Exchange server.
However, in Win2K, child domains replace resource domains. Thus, you don't need separate resource domains to create administrative and security boundaries. The more granular Win2K security model lets you use ACLs to protect servers. As a result, you must review each domain's role to determine whether you still need the domain and, if so, how you can best implement it inside a Win2K forest. (You can't assume that every resource domain automatically becomes a child domain.)
Too Many Servers in Production
In 1996, a server could support 500 to 1000 mailboxes. Today, improvements in Exchange and NT, symmetric multiprocessing, clusters, CPU speed, and disk controllers have raised the practical limit to 3000 mailboxes; and hardware vendors and Microsoft promise to support even more. The result of limiting the number of mailboxes on a server is that companies tend to deploy more servers than they would like.
The partition of the Information Store (IS) into multiple databases and the advent of active/active clustering are the two most important improvements in Exchange 2000 that enable servers to support more mailboxes. You can build 2-way clusters with Win2K Advanced Server, and Win2K Datacenter Server promises 3-way and 4-way clusters. Exchange 2000 virtual servers run on clusters; each virtual server has a distinct set of databases and mailboxes and runs on a physical computer within the cluster. All the virtual servers are active at the same time, and a failure forces a virtual server to fail to another node. The faster transition lessens the effect on users. Soon, clusters will be able to support more than 10,000 mailboxes, which obviously means that you can consolidate many smaller servers into large clusters. Not every installation is suitable for consolidation, but many are. The advantage of this development is that a reduced number of servers is easier to manage and cheaper in terms of system hardware, software, and maintenance charges.
Win2K servers are also candidates for consolidation. For example, a properly designed Win2K deployment is likely to require a smaller number of domain controllers. However, Win2K domain controllers need hardware resources that are significantly more capable to handle Active Directory (AD) demands, so don't expect to make great savings here.
Too Many Exchange Sites
Sites create administrative, routing, and replication boundaries for Exchange. The requirement to support Remote Procedure Call (RPC) connectivity between servers in a site defines the basic limit of connectivity for a site. RPCs are sensitive to network bandwidth and latency, so common wisdom is that you need at least 64Kbps between servers; 128Kbps is even better to ensure connectivity. Exchange 2000 uses RPCs only when it needs to connect to legacy servers. Exchange 2000 servers communicate with SMTP, which is better able to support connections across low-bandwidth, low-latency links. The benchmark for connectivity within a routing group (i.e., the closest Exchange 2000 structure to a site for interserver connections) is likely to be closer to 32Kbps. Therefore, you have an opportunity to create a site structure that has a smaller number of routing groups to reduce administrative and routing complexity.
Some circumstances demand creation of a special site. For example, in Exchange Server 5.5 you probably created sites to hold connector servers, to serve as the hub in a hub-and-spoke network, or to host mailboxes of specific users, such as company executives. Exchange 2000, however, supports routing groups and administrative groups instead of sites.
Routing groups implement a common set of policies for message routing across the organization. Because routing groups define how Exchange routes messages, you must use routing groups to evolve the sites that hold connector servers or serve as routing hubs.
Administrative groups define administrative access and control over servers and, therefore, provide a means to establish a specific environment for special users. You can place servers from multiple administrative groups in a common routing group so that the servers share a common routing scheme but you can manage them differently. For example, Figure 1 shows an administrative group created specifically to hold routing groups.
Too Many Connectors in Use
Every operational connector in an Exchange organization increases the complexity of message routing. Therefore, you want to minimize the number of connectors you deploy. However, the static nature of the Gateway Address Routing Table (GWART) that the Exchange Server 5.5 Message Transfer Agent (MTA) uses leads system designers to factor in multiple X.400 or SMTP connectors to ensure that messages get through if a connector becomes inoperative as a result of a system failure. Some deployments have implemented innovative routing schemes with varying degrees of success; some schemes fail because of the esoteric nature of the MTA and the algorithms it uses to route messages.
Exchange 2000 moves away from the X.400-based MTA, although Exchange 2000 still supports X.400 as a protocol and still uses the MTA. However, Exchange 2000 now firmly supports SMTP and uses a new routing engine based on the standard SMTP service present on all Win2K servers.
Exchange 2000 extends the standard SMTP service with several new transport events to enable the full spectrum of messaging connectivity that you'd expect from a high-end email server. Among the changes is the implementation of Link State Algorithm (LSA) routing, which means that servers can inform one another of the current state of the network and connectors. The Routing Group Master, a server allocated to this role in each routing group, uses this information to calculate a new routing map. Figure 2 shows the membership of a routing group and the option to move the master role to a selected server. The routing engine quickly detects failures and reacts to them, so messages don't get stuck in the ping-pong rerouting between servers that you commonly see in Exchange Server 5.5 organizations. These features let you redesign the existing connector structure, remove unneeded connectors, and take advantage of LSA routing.
Too Many People with Administrative Privileges
NT has one set of privileges, and Exchange has another set of permissions, which it stores with mailbox information in the Directory Store. Privileges, permissions, and server management get complicated when you have multiple account domains*a common situation in a distributed implementation. The complicated interaction between accounts, mailboxes, NT privileges, and Exchange permissions means that the easiest choice is often to overassign permissions to users to get a job done. Having many users be administrators causes no great damage, but this situation is certainly not optimal because people with privileges can make mistakes when they run utilities they don't fully understand.
An associated problem is that over time people obtain privileges because they need them to do a job and keep the privileges after they move on. Unless your company performs audits to check that the right people have the right level of permissions and privileges, you accumulate a set of permissioned individuals, some of whom don't need to enjoy privileged access to Exchange servers.
Exchange 2000 is tightly integrated with Win2K and discards the old permissions model in favor of Win2K ACLs. Therefore, you can now take an integrated approach to system and application security that depends on one set of privileges that can both allow and deny access to specific elements of the system. In your migration plan, include a review of privileges before you allocate any privileges. Your migration gives you another chance to tighten system security.
Too Much Replication Between Servers
Exchange Server 5.5 servers replicate directory and public folder data. Replication is either automatic (e.g., intrasite directory replication among servers) or performed according to a connector structure (e.g., public folders and intersite directory replication). Replication saps network bandwidth and strains servers, which have to process replication messages and update directories and folders. An optimal replication schedule makes sure that Exchange replicates data quickly and effectively in line with the needs of users and the organization to keep the directory and public folders up-to-date. Unfortunately, too often administrators assume that optimal replication means frequent and fulsome replication, and they don't think through whether the organization needs such frequent current data and public folder replication. The bigger the organization, the greater the number of possible replication partners, and therefore the more important it is to take control of replication.
Exchange 2000 uses AD instead of a separate Directory Store, so directory replication is part of the Win2K infrastructure. Win2K needs to replicate far more information than Exchange requires, so you must ensure that replication works well because any problem will affect basic Win2K functions (e.g., user authentication) and applications that depend on AD. Although every Exchange Server 5.5 server participates in directory replication, only domain controllers replicate AD information; therefore, Exchange 2000 has fewer replication partners.
Public folder replication in Exchange 2000 is similar to replication in Exchange Server 5.5, with the obvious difference that routing and administrative groups have replaced sites. Replicas are the same, and you need to consider how many replicas to create and how to use connectors to link them. You'll probably have to replicate data between Exchange 2000 servers and Exchange Server 5.5 servers during the migration. However, Exchange 2000 can exist in a mixed mode organization and therefore can work with legacy servers as if they were all in an Exchange Server 5.5 organization.
Special Requirements for Clusters
Clustered Exchange Server 5.5 servers deserve special attention during the migration process. You can perform a "rolling upgrade" of a Microsoft Cluster Server (MSCS) cluster. That is, the process upgrades the OS from NT Server, Enterprise Edition (NTS/E) to Win2K AS on each node in the cluster separately. When this process is complete, you have a Win2K cluster. However, applications don't necessarily support such upgrades, and you must be careful that all the software running on the cluster functions correctly under Win2K. Exchange Server 5.5 will run on a Win2K cluster, but you need to verify whether your backup software, virus checker, messaging connectors, and so on will continue to run.
Upgrading Exchange Server 5.5 to Exchange 2000 on a cluster is the next challenge. As I write, it doesn't seem likely that Microsoft will support an automated method to upgrade Exchange on a cluster. Instead, Microsoft provides a set of documented steps for carefully preserving databases while you remove Exchange and then install and rebuild it on the Win2K cluster. However, this approach can take days. You must perform backups, remove any components such as connectors to ensure that messages keep flowing for the rest of the organization, remove Exchange Server 5.5, install Exchange 2000, restore the databases, check that everything is working, bring the cluster back online, and then complete the task by performing more backups. Always be paranoid when you're rebuilding servers and perform backups to ensure that you don't have to redo work if something goes wrong.
The messaging service isn't available to users while these operations are proceeding, so this method can significantly affect service level agreements (SLAs) and uptime statistics. Additionally, you must practice before trying an upgrade on a production cluster to be sure you know how to perform the steps.
An alternative approach is to install a new Exchange 2000 cluster into the same site as the existing Exchange Server 5.5 cluster and then move mailboxes from the old cluster to the new one. This approach is attractive because it restricts the impact of the migration to the user whose mailbox you're moving at a particular time. Eventually, when you've moved all the mailboxes to the Exchange 2000 cluster, you can decommission the Exchange Server 5.5 cluster by removing it from the organization. You can then reallocate the old cluster hardware for performing other tasks, such as a new Win2K domain controller.
Easing the Migration Pain
All migrations are painful. You can mitigate the pain by taking the time to acquire knowledge about Exchange 2000, understand how it works with Win2K and legacy Exchange servers, and create a migration plan before you begin. Exchange 2000 is different from its predecessors. You can't assume that you know Exchange 2000 just because you know Exchange Server 5.5. The unwise will proceed in a state of blissful ignorance and forgo the opportunity to address the sins of the past. Those who take the time to understand and plan will use the migration to improve the stability, manageability, and reliability of their Exchange organization.
