The sooner you start, the sooner you can migrate
Your Exchange Server 5.5 system is running efficiently, and you're content with Windows NT 4.0's behavior. You know how to make messages flow without hindrance, and you understand the ins and outs of the OS. Enjoy your fleeting comfort, because your technical landscape is about to change with the arrival of Windows 2000 (Win2K) and Microsoft's next major functionality release of Exchange ServerPlatinum. The new OS and messaging server are so different from previous versions that they'll force you to reassess how you design and plan an Exchange Server implementation before you proceed with a migration to Platinum. You need to keep in mind lessons you learned from previous successful implementations.
Platinum offers abundant functionality. If you're interested in collecting, categorizing, and using knowledge more efficiently than you do today, you'll want to move to Platinum sooner rather than later. In this article, I discuss the eight steps you need to take to prepare for Platinum. You can take some of these steps immediately, but you'll need to complete others later. The sooner you start, the sooner you can migrate.
Your complete Platinum deployment plan needs to describe in detail each of the eight steps that follow. The plan must also state when each activity will occur, who is responsible for the task, and what dependencies exist (e.g., the availability of essential Exchange Server add-ons).
1. Gather Knowledge
Software installation routines attempt to make everything appear simple and straightforward. But if you rush to install software without understanding the technology, you'll probably make a mistake. If you err while installing Win2K or Platinum, you might need to completely reinstall the software. Before you attempt deployment, take the time to learn about the new technology.
Attend training classes and seminars so that you can set the scene and understand the work you'll have to do to install Win2K and Platinum. Getting your hands dirty reinforces book learning, so when you return from training, take the time to install public betas on your test systems. Don't stop at only one server, unless your production environment includes only one server. We live in a networked and distributed world, which your test environment needs to reflect. Install at least two servers to test the network components.
2. Prepare Your Exchange Server Environment
Exchange Server 5.5 is the gateway to Platinum. You can't upgrade to Platinum from any other version of Exchange Server, so ensure that all your servers are running version 5.5 with the latest service pack (Service Pack 2SP2at press time). Many servers still run Exchange Server 5.0 or 4.0, simply because no one has upgraded the software (or applied all the associated NT upgrades and third-party add-ons). Why upgrade a server that's doing its job?
A Platinum installation requires upgrades to many database internals, but performing several successive internal upgrades during an installation isn't feasible. Suppose you have an Exchange Server 4.0 system with a 6GB Information Store (IS). The database will upgrade when you move to Exchange Server 5.0 and will upgrade again when you move to Exchange Server 5.5. The time that each upgrade will require depends on your computer's speed and the size of the databases. Each of these database migrations might take 3 hours or more (and you'd still have other upgrade operations to perform). If you're planning to upgrade from Exchange Server 4.0 to Platinum, you'll require an extra migration step that will make the elapsed time unacceptable. If anything goes wrong in such a complex undertaking, the recovery will be time-consuming. Thus, you need to apply upgrades over time and stabilize the system between each step.
Simplifying the upgrade process isn't the only reason why Exchange Server 5.5 is the gateway to Platinum. Exchange Server 5.5 is the first release to support a read-write version of Lightweight Directory Access Protocol (LDAP) 3.0. The Active Directory Connector uses LDAP to linkand provide bidirectional synchronization betweenthe Exchange Server 5.5 Directory Store and Win2K's Active Directory (AD). Platinum doesn't have a built-in directory. Instead, Platinum stores details about mailboxes, distribution lists (DLs), and recipients (contacts in Win2K) in AD and extends the AD schema to store additional attributes that Exchange Server requires, including details about email servers. You can't complete a Platinum migration overnight, so synchronizing the two directories is important. If you don't synchronize them, Exchange Server 5.5 users won't be able to see Platinum users in their Global Address List (GAL), and vice versa.
Finally, understand that you must have Exchange Server 5.5 SP2 before your server meets Microsoft's Year 2000 (Y2K) readiness criteria. Depending on your components, Exchange Server 5.0 and 4.0 systems might run successfully in 2000, but Microsoft won't support them.
3. Prepare Your IP Infrastructure
Win2K depends on a solid TCP/IP infrastructure. Although Win2K supports NetBIOS, IP is the OS's default network protocol. You need to review your network to make sure that all IP addresses and subnets are valid. You also need to understand DNS. Win2K still supports WINS, but only for backward compatibility with NT 4.0. Win2K and Platinum use DNS for routing information, so you need to plan to introduce DNS if it's not already in use. If DNS is in place, you must decide whether you need to modify the existing DNS server to accommodate your move to Platinum. For example, you might decide to group all Platinum servers in one DNS zone.
You also need to decide what type of DNS server to use. Win2K uses service records (SRV records) to register services such as domain controllers, Global Catalogs, and LDAP for the AD. SRV records map services to hosts and let clients find services they need. Typically, Dynamic DNS automatically adds the SRV records each time a domain controller boots. (Newer DNS servers support Dynamic DNS.) The DNS server that Win2K includes (and UNIX DNS servers that support Berkeley Internet Name DomainBIND8.0) supports both SRV records and dynamic updates. If your network currently uses an earlier version of DNS (such as BIND 4.0), you don't have support for Dynamic DNS and SRV records, so you need to upgrade.
4. Plan Your Win2K Rollout
Now you can proceed to draw up your Win2K design. You need to decide what domains you want to use and how to arrange those domains in AD's forest and tree structure. You also need to decide which computers will serve as domain controllers and which computers will act as Global Catalogs. The Global Catalog is Platinum's incarnation of the Directory Store. Like the Directory Store, which contains replicated information about mailboxes, distribution lists, and other email addresses (e.g., external users addressed through SMTP) from sites throughout an Exchange Server organization, the Global Catalog contains a replicated read-only subset of information about users and contacts from a forest of domains. Fortunately, the subset that the Global Catalog maintains is enough to provide a GAL to MAPI clients such as Microsoft Outlook 2000. Instead of connecting to the Directory Store to resolve email addresses and otherwise access the GAL, a Platinum server redirects connecting MAPI clients to a Global Catalog. POP3 and IMAP4 clients will simply switch to the nearest Global Catalog to access the Directory Store and will continue to use LDAP to retrieve information.
The correct order for implementing the underlying infrastructure for Platinum is Win2K, DNS, then AD. All these components must be in place before you install your first Platinum server. Exchange Server 5.5 SP2 runs on Win2K, so you can initially implement Win2K for authentication purposes, then swap out NT 4.0 domain controllers before proceeding with the migration.
After you have some domain controllers in place and a basic AD store up and running, you can use the ADS to connect AD to the Exchange Server 5.5 Directory Store. You'll need one connection agreement between each Exchange Server site and the AD. One Active Directory Connector can handle multiple connection agreements, but in a distributed organization you'll probably run several connectors to split the load and management tasks. The synchronization will populate AD and let you acquaint yourself with the management tasks that you need to perform to keep AD healthy.
.microsoft.com/y2k.
Fernando E. Lopez December 13, 1999