| Downloads |
|---|
| 22252.zip |
The move from Microsoft Exchange Server 5.5 to Exchange 2000 Server and the corresponding move from Windows NT to Windows 2000 are some of the most significant changes you'll make to your infrastructure in the near future. Because an Exchange 2000 migration requires some fundamental changes to your environment, setting out on the road to Exchange 2000 without understanding every detail of the migration isn't smart. In my experiences as a consultant with Compaq—migrating many tens of thousands of users—I've learned several tips that can help smooth that road from beginning to end. However, the tips assume you understand the basic concepts behind Exchange 2000 migrations; if you don't, you might want to save this article until after you've acquired foundational migration knowledge (for helpful Exchange 2000 migration references, see "Related Reading," page 96).
TIP 1: Recruit Sponsorship
Attracting the right level of organizational sponsorship might be an obvious first step on the road to migration, but broad-based management and technical support are crucial to a successful migration. Migration to Exchange 2000 cuts across many aspects of your environment. For example, you might need to significantly alter your Windows infrastructure, especially if you're migrating to Win2K at the same time you're migrating to Exchange 2000, and you'll need to modify your DNS infrastructure to support Active Directory (AD). You'll also probably need to revisit the hardware configurations for your Exchange servers.
Such infrastructure modifications typically involve multiple business units and locations and require financial backing from various parts of the organization. Consequently, you might meet resistance. To help ensure success, publicize the benefits of the migration within the organization, organize the migration effort as a series of separate subprojects centered on the individual technologies that you need to revamp, and make sure all key managerial and technical players buy into the effort.
TIP 2: Prepare your domain environment
Typically, the Exchange 5.5 and NT partnership gives rise to unwieldy domain infrastructures. Such domain models aren't ideal for Win2K, which is better suited to leaner domain models. Before you migrate, you should streamline your domain structure. (For information about consolidating domains, see Robert McIntosh, "Windows 2000 Domain Consolidation," http://www.win2000mag.com, InstantDoc ID 8933.)
Exchange 2000 requires you to run Domainprep in every domain that will host Exchange 2000 user or server accounts. Thus, the fewer domains you have, the less work you need to do to prepare those domains. Furthermore, a simple domain model can help reduce the number of connection agreements (CAs) you need. Typically, you need a CA from each Exchange 5.5 site. So long as the recipients from each Exchange 5.5 site are homed within one domain, the number of CAs you need is minimized. Increasing the number of domains means that recipients from one Exchange 5.5 site might need to replicate to another domain, increasing the number of CAs you need for that Exchange site.
Compaq's NT domain model consisted of more than 1800 domains. In the move to Win2K, Compaq flattened that structure to the four-domain model that Figure 1 shows. In the new model, each parent domain acts merely as a name placeholder; the child domains hold all user and machine accounts. In an ideal world, you'd be able to flatten all your domains into one domain. However, for various political and security reasons, that structure often isn't possible.
When preparing your domains, also ensure that the Win2K domains that will host your user accounts and groups are in native mode. This mode supports the use of Universal Security Groups (USGs), which Win2K typically requires to enforce access controls on Exchange 2000 public folders.
TIP 3: Ensure that AD is replicating
AD is crucial to the correct operation of Exchange 2000. Before you install Exchange 2000, you run Forestprep to add Exchange 2000 schema extensions and define the Exchange organization hierarchy in AD. Exchange 2000 stores all its configuration information, including that about servers, connectors, and routing groups, in AD's Configuration naming context (NC). By default, the Configuration NC replicates to all domain controllers (DCs) within the forest. When you run Forestprep on the first Exchange server you install, the server expects to find a definition of the Exchange organization in the Configuration NC. But if replication of the Configuration NC hasn't occurred (e.g., because of latency), the Exchange 2000 installation fails with errors. I've seen these failures occur time and again in Exchange 2000 deployments. In addition to migrating organization definitions, AD replication functionality is important for synchronizing information about users and contacts to all Global Catalog (GC) servers throughout the forest.
To assure successful installation, you need to devote sufficient attention to AD replication. You can use the ADSI Edit utility from the Win2K Server installation CD-ROM's Support Tools directory to check that data has been replicated. (For information about how to use this utility, see Sean Daily, Daily Answers, "The ADSI Edit Utility," March 2001.) Alternatively, you can use the Microsoft Windows 2000 Server Resource Kit's Replmon tool to monitor replication status. Replmon has the advantage of letting you force replication.
TIP 4: Clean up the DS
If you intend to use the Active Directory Connector (ADC) to synchronize Exchange 5.5 Directory Service (DS) information with AD, you don't want to waste time by replicating irrelevant information. Unless you've kept a close eye on your Exchange 5.5 DS over the years, the service is probably littered with obsolete mailboxes, unnecessary container hierarchies, and unneeded or duplicate custom recipients. I recommend that before you even test the ADC operation, you sanitize the DS. (For more information about ADC processing, see "Real-Life ADC Deployment, Part 1," May 2001 and "Real-Life ADC Deployment, Part 2," June 2001.)
To clean up the DS, you can choose from several possible approaches. For example, you can produce Comma Separated Value (CSV) export files that contain all the mailboxes, distribution lists (DLs), or custom recipients in the Exchange 5.5 directory, then manually inspect the files. You can also use VBScript to write a simple application that trawls through the DS and detects duplicate custom recipients and mailboxes.
TIP 5: Replace invalid characters
Another DS cleanup action you can take is to detect and remove or replace characters that are valid in the DS but not in AD. For example, the ADC and the Exchange 2000 upgrade procedure use an Exchange 5.5 site's display name to name the site's corresponding AD administrative group. If a site's display name contains characters other than the alphanumeric characters, the space character, and the hyphen character, you must remove those characters before you migrate. If you don't remove invalid characters from DS names, the related objects will be inaccessible from AD.
TIP 6: Prevent resource mailbox problems
Resource mailboxes (aka process mailboxes) can cause problems when the ADC processes Exchange 5.5 mailboxes for synchronization with AD. When processing an Exchange 5.5 mailbox, the ADC creates a Win2K user account for the mailbox, then uses the SID of the mailbox's associated NT account to populate the new user account's msExchMasterAccountSID attribute. The NT account associated with a resource mailbox (e.g., a mailbox for a conference room or overhead projector) often is also associated with the mailbox for the "real" NT user who manages that resource. For example, Figure 2 shows that the mailbox for Conference Room 7 is associated with the Vickers user account. However, within a Win2K forest, no two objects can have identical msExchMasterAccountSID values. Thus, the first mailbox that the ADC processes (e.g., the Conference Room 7 mailbox) "uses up" the shared msExchMasterAccountSID value. As a result, when the ADC processes the other mailbox (e.g., the Vickers mailbox), that mailbox won't synchronize with AD, and the Global Address List (GAL) won't show Exchange 2000 the mailbox (this scenario can also cause problems with permissions).
The ideal solution is to create a new NT account for each resource mailbox. But if identifying resource mailboxes and creating new accounts for them will take too long, you might want to take another approach. In the CA configuration, you can use either a Lightweight Directory Access Protocol (LDAP) search filter or an object-matching rule to exclude resource mailboxes from processing. You can then manually or programmatically recreate the resource mailboxes in Exchange 2000. (For more information about this approach, see "ADC Filtering and Object-Matching," http://www.exchangeadmin.com, InstantDoc ID 16139.)
In many organizations, Exchange 5.5 mailbox aliases and their associated NT accounts' SAM account names are different. For example, the alias name for Don Vickers's Exchange 5.5 mailbox might be DonV, but his SAM account name might be Vickers. If you intend to use the Microsoft Exchange 2000 Server Resource Kit's Ntsdnomatch utility to identify resource mailboxes so that you can assign them to independent NT accounts, you need to make sure user mailboxes' aliases coincide with SAM account names.
Ntsdnomatch is a useful tool for premigration audits. The tool scans each Exchange 5.5 site to identify mailboxes with alias names that differ from the associated SAM account name. Ntsdnomatch would identify the resource mailbox that Figure 2 shows as a resource mailbox but would also identify the mailbox with the alias of DonV and the SAM account name of Vickers. Although Ntsdnomatch's resource mailbox detection logic is quite unsophisticated, the tool is still useful.
TIP 7: Ensure unique DL names
When the ADC synchronizes the Exchange 5.5 DS's DLs with AD, the ADC creates a Universal Distribution Group (UDG) in AD for each DL. Each UDG has the same name as the corresponding DC, but the ADC truncates long names to 20 characters to enable interoperation with NT's User Manager for Domains utility. When the ADC processes DLs with names that aren't unique within the first 20 characters (e.g., AllUsersWhoHaveBlackHair, AllUsersWhoHaveBlackShoes), those names cause name collisions and result in errors during synchronization. When you perform premigration audits of objects in the Exchange 5.5 DS, you need to identify and modify the DL names that will cause problems.
TIP 8: Weigh the benefits of speed
Speed might factor in to the Exchange migration method you choose. The in-place upgrade approach simply converts both the private and public Information Stores (ISs) to Exchange 2000's new database format on the same server. Figures from Microsoft show that the average rate for upgrading ISs to Exchange 2000 is about 25GB per hour.
The alternative migration approach—installing Exchange 2000 on a separate server, then using the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in's Move Mailbox feature to move mailboxes one at a time—provides much slower data migration primarily because Move Mailbox uses remote procedure call (RPC)based Messaging API (MAPI) connections to find and retrieve the source mailbox objects to migrate. Of course, transfer rates will depend largely on your systems' hardware configurations, especially those of the I/O subsystems. My experience is that Move Mailbox transfer rates between minimally configured (i.e., one I/O controller, one hard disk for the database, and one hard disk for logs) Exchange servers are about 1GB per hour; however, high spindle counts and high-speed controllers will improve this rate, whereas more primitive I/O subsystems will reduce performance.
But don't oust Move Mailbox from contention as a possible migration technique just because it's slower than an in-place upgrade. Moving mailboxes one at a time has advantages: You minimize service interruptions because you don't need to take the Exchange 5.5 server offline; you can schedule migrations with much finer granularity and synchronize those migrations with specific NT account migrations; and, if something goes wrong, the problem affects few users.
TIP 9: Analyze your Single Instance Ratio
Your system's Single Instance Ratio might also help you determine which approach you want to take to migration. Single Instance Storage (SIS) lets multiple users share one copy of an email message and is a much-touted benefit of the Exchange IS database model.
The Performance Monitor's Single Instance Ratio counter can show you how effective SIS is on your system (to view the counter, select the Single Instance Ratio counter on the MSExchange IS Private object). Figure 3, page 98, shows the Single Instance Ratio to be 1.384. The higher the ratio, the more efficient the storage. For example, a ratio of 2 (i.e., 2:1) means an average of two pointers exist to each message the system stores.
Although SIS is certainly advantageous in some environments, many large organizations observe low sharing ratios and dispute the benefit of SIS. If Performance Monitor shows that your private IS has a high Single Instance Ratio and maintaining that ratio under Exchange 2000 is important to you, you need to consider doing an in-place upgrade. An in-place upgrade maintains your database's SIS characteristics, but the Move Mailbox approach doesn't.
TIP 10: Downsize the IS
Regardless of your migration approach or the characteristics of your I/O subsystems, you can speed the migration process by simply reducing the amount of information in the Exchange databases. Before you upgrade, encourage users to decrease the size of their mailboxes. Gentle email reminders about mailbox size might induce users to clean out their mailboxes. Alternatively, you can employ more draconian measures: implementing mailbox size limits that, if exceeded, impose send restrictions; using Mailbox Manager; or even writing and executing scripts that identify email hoarders and disable their accounts.
TIP 11: Rehome the CAs & DRCs to SRS servers
Exchange 5.5 environments with multiple sites often use directory replication connectors (DRCs) between two Exchange 5.5 bridgehead servers in adjacent sites. When you configure CAs between these sites and AD, common practice is to host CA endpoints against sites' bridgehead servers rather than member servers. When a bridgehead server hosts the CAs, you can't upgrade the server until after you've introduced your first Exchange 2000 machine to the site. After you install that Exchange 2000 system, you should rehome the DRC and CA as quickly as possible to that machine's Site Replication Services (SRS) on port 379.
Rehoming the connections guarantees a source of Exchange 5.5 DS information for that site, regardless of what happens to the other servers (e.g., you take the other servers down because you're consolidating to a smaller number of larger Exchange 2000 servers). If you subsequently upgrade the Exchange 5.5 bridgehead server immediately after you introduce your first Exchange 2000 server and that server isn't a clustered system, you'll enable the SRS on that server, too. However, moving the DRC and CA to another system before you upgrade the bridgehead server protects the site from DS unavailability while the bridgehead server is down. Figure 4, page 100, shows premigration configurations and the changes you need to make to your CAs and DRCs when you install the first Exchange 2000 machine.
TIP 12: Build a realistic test environment
Regardless of your environment's complexity, embarking on a migration to Exchange 2000 without first analyzing each aspect of your migration plan is foolish. To perform this analysis, you need to build a realistic test lab that's separate from your production environment but that reflects that environment as closely as possible. If your production environment's network links are slow, use modem eliminators in your test environment to simulate those link speeds. If you're upgrading multiple NT domains, reproduce some of them so that you understand what happens when you migrate accounts to Win2K. Recreating these domains can also help you determine how to configure CAs that span domain boundaries or, for example, how to distribute users from one Exchange 5.5 site into two Win2K domains. Use your test environment to validate the behavior of your CAs: Test how the migration affects the replication hierarchy, how distinguished names (DNs) will map, and how effective CAs will be after you move objects within the AD topology.
TIP 13: Evaluate migration tools
Your test lab will also give you a good way to evaluate Microsoft and third-party migration tools. Both Win2K and Exchange 2000 provide out-of-the-box migration tools, but those tools have limited functionalities. For example, you can use the Active Directory Migration Tool (ADMT), but when the ADMT migrates NT accounts, the tool often doesn't work well in matching with the msExchMasterAccountSID attributes. Trying out a few third-party Win2K- and Exchange 2000oriented migration tools is good practice. The broad selection of deserving products includes BindView's bv-Admin, Quest Software's FastLane DM/Suite, Aelita Software's Controlled Migration Suite and Exchange Migration Wizard, and NetIQ's Exchange Migrator.
TIP 14: Configure hardware sensibly
When the time comes for you to size hardware for your Exchange 2000 servers, you need to think carefully about the differences between Exchange 2000 and Exchange 5.5. Unlike Exchange 5.5, Exchange 2000 can use multiple ISs (i.e., databases) and can group as many as five databases into a storage group (SG). The databases in each SG share a set of transaction logs. Furthermore, Exchange 2000's Streaming Store has particular I/O requirements for audio and video data sets. Although I won't go into detail about how these differences affect optimal Exchange 2000 mailbox allocation against databases, SGs, and physical disk volumes, you need to be aware that the disk layouts you use for Exchange 5.5 are likely too primitive for Exchange 2000. (For more information about server sizing and mailbox allocation, see Jerry Cochran's Exchange & Outlook UPDATE article, "Exchange 2000 Server Sizing: Memory and Disk Subsystems," http://www.win2000mag.com, InstantDoc ID 16499.)
Mailbox redistribution might not be a major concern to small organizations, but organizations that have many users per server and that want to improve service levels by redistributing mailboxes over multiple databases will need to reconfigure I/O subsystems. In these cases, upgrading servers is unlikely to be the best solution. The hardware configuration must remain intact during an upgrade, and reconfiguring the I/O subsystem after you complete the upgrade could cause significant service outages when you take the server offline to add disks and controllers. In this situation, installing Exchange 2000 on new hardware, then moving users to the new server, is eminently more sensible.
TIP 15: Consider a greenfield approach
Several experts, including a few from Microsoft, recommend an interorganizational approach over the intra-organizational approaches (e.g., in-place and Move Mailbox migrations) that most of my tips assume you'll use. Although I don't necessarily agree with the greenfield strategy migration, the method deserves discussion.
Rather than upgrading existing servers or introducing Exchange 2000 servers into the existing environment, an interorganizational migration separates the target Exchange 2000 organization from the original Exchange 5.5 organization. In this approach, you use the ADC to synchronize Exchange 5.5 mailboxes into AD as mail-enabled (not mailbox-enabled) objects and you use Exchange 2000 Service Pack 1's (SP1's) Mailbox Migration Wizard to export mailbox content to the Exchange 2000 organization's ADC-created objects.
The greenfield approach has its merits. Because the migration doesn't use Configuration CAs to synchronize Exchange 5.5 configuration information to AD, none of the legacy Exchange 5.5 organization's configuration overhead carries over. Consequently, you can build a brand new topology in an Exchange 2000 native-mode organization and bypass the intra-organization migration's mixed-mode phase, which reduces your flexibility for configuring routing and administrative groups. Plus, you can start afresh with a new Exchange organization name.
Although a greenfield migration has its positive points, the method's drawbacks cause me to steer clear of it. No straightforward mechanism exists for providing public folder interoperability between the Exchange 5.5 and Exchange 2000 organizations. Also, the Mailbox Migration Wizard leaves the old Exchange 5.5 mailboxes intact, so you need to remove them manually. The approach also doesn't migrate Inbox Assistant rules and Out of Office Assistant settings, mail delegation settings, or Calendar functionality across organizations.
TIP 16: Start with delete-disabled 1-way CAs
If you use 2-way CAs to synchronize Exchange 5.5 mailboxes to AD, any changes you make to ADC-created objects in AD are reflected in the Exchange 5.5 DS. So, deleting an ADC-created object removes the Exchange 5.5 DS objects and mailbox. Inadvertent deletion of mailbox-enabled user objects is a common problem in the early days of coexistence, as Win2K administrators come to grips with the new environment. At first, you should configure these CAs as 1-way CAs. This configuration lets you synchronize Exchange 5.5 mailboxes to AD while preventing inadvertent modifications. After you trust that Win2K administrators won't unwittingly delete a mailbox, you can reconfigure the CAs as 2-way and enable their delete functionality.
TIP 17: Consider writing your own migration tools
The Move Mailbox tool lets you select a user or users, then move their mailboxes from an Exchange 5.5 server to an Exchange 2000 server. In general, this mechanism works well for moving a few users. But if you're doing an Exchange 2000 migration at a large installation, you might need to move hundreds or thousands of users at a time. In this case, you should consider using Collaboration Data Objects (CDO) and Collaboration Data Objects for Exchange Management (CDOEXM) to develop a migration script.
Custom-developed migration tools let you migrate users unattended and use Win2K scheduling tools to do the migration over a weekend or at night. You can also develop a tool that uses a feed from another data source—such as a procedure that migrated NT accounts to Win2K—to input a list of accounts that you want to migrate. Listing 1 shows a rudimentary CDO code extract that, given a mailbox-enabled user's DN and the target database's DN, moves the user's mailbox to the target database. Although this sample code is somewhat simplistic, it demonstrates how straightforward the coding effort can be. Even those of us who aren't "real programmers" should be able to develop such utilities. However, be aware that if you don't thoroughly test and debug your code, your utility can cause serious damage.
TIP 18: Phase in CAs
If you've configured multiple CAs for your environment, don't enable all of them at the same time. When activated, CAs generate a surge of network traffic in the DS and in AD. Staggering the times at which you enable CAs reduces the wave of replication activity to a more manageable flow.
For example, Compaq distributed more than 40 CAs across seven ADC servers and used them to replicate Exchange 5.5 mailbox information to AD. After initiating the coexistence environment, we enabled one ADC server's CAs per day. After 7 days, all CAs were in operation and replication activity was suitably controlled.
TIP 19: Perform a postmigration audit
Just as important as the premigration audits that identify resource and user mailboxes that share NT accounts and help you ensure uniqueness in Exchange 5.5 mailbox aliases is a postmigration audit. Postmigration audits help you ensure that all Exchange 5.5 objects that you expected to be synchronized to AD were, in fact, synchronized. The third-party migration tools you might have used for premigration audits typically don't provide functionalities for postmigration audits. For peace of mind and to guarantee the integrity of your environment, I recommend developing your own utility to check that all Exchange 5.5 DS objects have a partner object based on the legacy DN attributes.
TIP 20: Minimize user impact
Here's a tip that's more of an overriding principle than a step in your migration plan: Try to ensure that the changes you make to your Windows and messaging infrastructure have the least possible impact on your user community. For example, sequence migration activities so that users can access Exchange 5.5 mailboxes from Win2K accounts and Exchange 2000 mailboxes from NT accounts. When moving NT accounts and Exchange 5.5 mailboxes, choose tools that let you maintain passwords and make mailboxes available quickly. You don't want your infrastructure changes to cause an upturn in Help desk calls. At Compaq, we moved about 3000 users from Exchange 5.5 to Exchange 2000 each weekend, which typically generated about one or two calls to the Help desk each Monday. Generating even fewer Help desk calls is our goal.
Closing Thoughts
Although these tips outline the techniques that have helped Compaq and several other companies migrate to Exchange 2000, your environment will have its idiosyncrasies and will require a unique approach. Whatever migration approach you take, be sure to plan thoroughly and build a test environment that lets you exercise every aspect of that plan. Migrating to Exchange 2000 isn't a trivial task, but with proper planning and exhaustive testing, it can be straightforward.
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com. WINDOWS 2000 MAGAZINE ARTICLES TONY REDMOND "Planning an Exchange 2000 Migration Strategy," July 2000, Web Exclusive, InstantDoc ID 8863 "Exchange 2000 Server over Active Directory," September 2000, InstantDoc ID 9666 EXCHANGE & OUTLOOK UPDATE JERRY COCHRAN "Preparing for Exchange 2000 Server, Part 2," March 31, 2000, InstantDoc ID 8499 "Preparing for Exchange 2000 Server, Part 4," April 7, 2000, InstantDoc ID 8538 "Choosing an Exchange 2000 Upgrade Strategy" July 14, 2000, InstantDoc ID 9141 |
