As suspected, Microsoft is dropping support for its most successful mail server product: Exchange Server 5.5. We knew it was inevitable because of Microsoft’s push to get all customers on the latest versions of its products.

Of course, many of us were relieved to hear that we have a little time. Microsoft has announced that regular support for Exchange Server 5.5 ends in December 2003. But, still, we have less than a year to make preparations for upgrading to Exchange 2000—and make no mistake: Exchange 2000 requires some serious preparation.

Baby steps to Exchange 2000
Upgrading from Exchange Server 5.5 to Exchange 2000 Server is slightly different from other Microsoft upgrades we’ve faced to date. For a start, Exchange 5.5 runs quite happily on both Windows NT Server 4.0 and Windows 2000 Server. The only major consideration is that if you run Exchange Server 5.5 on Windows 2000 domain controllers, you have to change the LDAP port number in the Exchange Administrator so there isn’t a clash when Active Directory uses the same port for LDAP calls (see Q224447).

The ability to run Exchange Server 5.5 on Windows 2000 meant that we got all the benefits of upgrading the operating system and migrating to Active Directory without having to make any changes to our working Exchange 5.5 infrastructure. So for a number of reasons, many administrators opted to stay with Exchange 5.5 than upgrade to Exchange 2000. As we all prepare to migrate to Exchange 2000 in the next 12 months, it’s important to keep those reasons in mind:

  • Active Directory—Exchange 2000 requires Windows 2000 and Active Directory. Many companies are still in the process of upgrading their servers and domains to Active Directory, even after deploying Win2K. With support for NT 4.0 servers declining, upgrades to Windows 2000 have taken precedence over Active Directory deployments.
  • Hardware—Exchange 2000 requires more memory and more processing, so a hardware upgrade or a server migration is often required. That means additional cost and/or downtime.
  • Security—Exchange 2000 has higher security implications. One example is that it must run in conjunction with IIS (and we all know how many security problems there have been with IIS).
  • Training—Exchange 2000 requires significant retraining to understand the new product set, including how and whether to use Instant Messenger, working with multiple storage groups and data stores, managing routing groups, and setting up policies.
  • Migration—Careful planning is needed for integration with existing Exchange 5.5 servers during the migration period to Exchange 2000.
  • Configuration—Some Exchange 5.5 configuration options cannot be directly upgraded.

The last point in this list is worth further explanation. Upgrading Exchange 5.5 is more complicated than upgrading an NT 4.0 domain to Windows 2000 domain, which was a conversion of one database to another. Upgrading Exchange 5.5 to Exchange 2000 is actually an amalgamation of two databases into one, and the two do not have a like-for-like structure. This means that some preparation work has to be done on the existing Exchange 5.5 database so it can be smoothly upgraded.

A clear example of this can be seen immediately in the relationship between user and mailbox. Exchange 5.5 has its own independent database for mailboxes, which it links to a Windows domain (either NT 4.0 or Windows 2000 Active Directory). Consequently, one user can have multiple mailboxes, or you can have a mailbox without a user. Exchange 2000 has only one database (Windows 2000 Active Directory), which contains user accounts. Mailboxes become an attribute of those accounts. This means that now each user can have only one mailbox, and each mailbox must belong to a user. If you upgrade your existing Exchange 5.5 database without preparing for this, you risk having inaccessible mailboxes.

Upgrading to Exchange 2000 has also been postponed on many production networks for another, highly compelling reason: It’s rightly perceived to be a risky upgrade. Mail exchange, both internal and external, has become a core IT service and is critical to almost every organization’s functioning. E-mail, together with Exchange’s public folder system (and calendaring system, task tracking, etc.), has become a common method of communication and an efficient method of transferring and disseminating data.

E-mail and groupware functionality have become services that everybody takes for granted—until they fail. This failure not only could impede business but also could become a career-limiting move if that failure is associated with your actions—or lack of Exchange 2000 migration planning. Understandably, nobody welcomes the risk of being responsible for breaking a working e-mail system, even if it is perceived as a necessary risk within a sanctioned upgrade project.

For all these reasons (and more), upgrading to Exchange 2000 has often been last on the list when it comes to upgrade projects on busy, production networks.

Get a head start
I recommend that companies use the grace period to their advantage and plan a gradual preparation for Exchange 2000 that can be completed over the next few months. If you take the appropriate steps to lay the groundwork, you’ll find the upgrade process much more manageable. You’ll also avoid a mad rush with bad decisions at the end of next year, and you’ll have more time to think through design issues that could stall your migration planning at several points.

Preparing for Exchange 2000 is more than simply upgrading hardware, upgrading servers and domains to Windows 2000 and Active Directory, and retraining staff—although all those issues need to be addressed. You’ll need to check, modify, and prepare for a number of key technological stumbling blocks so that the upgrade process will go smoothly and you won’t have any nasty surprises with unplanned downtime (and irate users).

So much reference material is available on installing, upgrading, and running Exchange 2000 that it can be a little overwhelming. You might want to start with this collection of Exchange 2000 deployment white papers. And, of course, it’s tempting to jump in and try out all the new features. By all means, try Exchange 2000 on an isolated network on a test machine, but don’t underestimate the risks involved in upgrading a production system. This is particularly relevant if you’re planning on an in-place upgrade, as many administrators are, instead of installing new servers and moving resources over.

Things to come
To help you develop a viable upgrade strategy and avoid the missteps that have brought some Exchange 2000 migrations to a screeching halt, I’m going to provide a series of articles that will cover the migration planning issues you need to consider. I’ll be covering the following topics:

  • Active Directory preparation
  • Exchange Server preparation
  • Exchange Server placement and roles
  • Exchange 2000 configuration planning

The next article, which will look at Active Directory preparation, will discuss issues such as DNS preparation (including RVP records, if you’re planning on using Instant Messenger), potential changes to network authorization, the importance and role of global catalog servers, and the version and mode of your domain controllers.