Before you tread the path to Exchange migration, here's a look at where that well-worn path leads.
- By Bill Boswell
Just about everything you need to know about being a successful e-mail
administrator can be learned from reading Alice in Wonderland
In an encounter between Alice and the Cheshire Cat, the cat remarks that
everyone in Wonderland is mad.
“But I don’t want to go among mad people,” Alice remarked.
“Oh, you can’t help that,” said the Cat.
“We’re all mad here. I’m mad. You’re mad.”
“How do you know I’m mad?” said Alice.
“You must be,” said the Cat, “or you wouldn’t have come here.”
Alice would certainly understand the plight of a modern-day e-mail administrator
who faces a migration from Exchange 5.5 to Exchange 2003. The piles of
manuals, procedures, checklists, and references you accumulate during
your pre-migration research can convince you that you’ve entered a mad,
The problem is not so much with the Exchange documentation or with people
like me who try to put the documentation into a real-world context. The
problem lies with the complexity of the migration itself. The road to
a full, native-mode Exchange 2003 organization wends its way through multiple
directory services with conflicting and often incompatible operating system
interactions, a complete change in message routing, a complete rewrite
of the management interface, an unprecedented level of interoperability
between Exchange and Outlook, and a host of features that absolutely rely
on a properly tuned DNS and Active Directory infrastructure. Getting out
of Wonderland once you’ve fallen down the rabbit hole is a feat to be
House of Cards
When laying out your Exchange 2003 migration plans, the hard part
is figuring out where exactly to get started. Fortunately, you don’t need
to worry about AD compatibility. Yes, it’s true that Exchange 2003 Setup
makes extensive changes to the AD schema, modifies the Configuration naming
context to incorporate the Exchange organization, and modifies each domain
to include new Exchange accounts and groups, but these changes are fully
compatible with both Windows Server 2003 and Windows 2000 Server AD.
There are a couple of caveats. If you have a Win2K forest, it’s highly
recommended that you run Win2K SP3 on all domain controllers. Otherwise,
you’ll wait for hours—even days—while the tables in AD are re-indexed
following the Exchange 2003 changes. Also, some of the high-end features
in Exchange 2003, such as cross-forest Kerberos authentication for Outlook
2003 and linked value replication of individual group members, rely on
a Windows 2003 forest that has been set to the highest functional level,
meaning that all Win2K DCs have been upgraded or removed from service.
Also, before you deploy Windows 2003 DCs into a mixed environment of
Exchange 2000 and Win2K, it’s important to correct an issue with the InetOrgPerson
attributes in the schema. Check out Knowledge Base 325379,
“How to upgrade Windows 2000 domain controllers to Windows Server 2003,”
Now you face a more difficult decision: the choice of an operating system
to use for your Exchange servers. The myriad combinations of Exchange
and Windows server versions quickly start to blur. Here are the combinations
that Microsoft supports: n Exchange 2003 Standard Edition on Windows 2003
Standard Edition. This combination supports four-way Xeon hyperthreaded
processors, RPC over HTTP, advanced memory tuning, IIS 6 application pools,
OWA compression, and shadow copy backups. You can run this configuration
in a Win2K domain, if you wish.
- Exchange 2003 Enterprise Edition on
Windows 2003 Enterprise Edition. This gives the additional advantage of
eight-node clustering and eight-way processing. Don’t waste money loading
more than 4GB RAM because Exchange 2003 can’t and won’t use it.
- Exchange 2003 Standard Edition on Win2K Standard Server. This
combination is fully supported and works fine as long as you run Win2K
SP3 or higher on the Exchange server and all DCs. You won’t get support
for four-way Xeon multithreading because Win2K assigns a CPU license
to each virtual processor, and Win2K Standard Server only supports four
- Exchange 2003 Enterprise Edition on Win2K Enterprise Server.
Technically, this combination is supported, but the only feature that
Win2K Enterprise Server brings to the table in this situation is two-node
clustering with inferior memory management compared to Windows 2003,
so there’s hardly any reason to consider this as an alternative.
The following combinations aren’t supported and shouldn’t be implemented,
even if you can come up with a workaround:
- Exchange 5.5 on Windows 2003.
If you try to install Exchange 5.5 on a Windows 2003 server, you’ll be
blocked at the outset by a warning message from the OS. If you try to
upgrade a Win2K server that already has Exchange 5.5 installed, you’ll
be notified by Windows 2003 Setup that Exchange 5.5 isn’t supported.
- Exchange 2000 on Windows 2003. Yes, I know that you’ll hear
stories that you can upgrade a Win2K server to Windows 2003 and Exchange
2000 “works great.” You can believe those stories if you like, but do
you really want to put your production Exchange servers into an unsupported
configuration? I say no, and I’m sure you’ll agree.
- Exchange 2000 or Exchange 2003 on Windows 2003 Web Edition.
The Web Edition of Windows 2003 was designed for Web services and doesn’t
support any version of Exchange.
With all this in mind, you have a limited set of in-place upgrade options.
You can’t do an in-place upgrade from Exchange 5.5 to Exchange 2003, even
if you have Exchange 5.5 running on Win2K. You can upgrade from Exchange
2000 to Exchange 2003, but make sure you’re confident of your change control.
You don’t want applications running on the Exchange 2000 server to cause
compatibility or security problems when married to Exchange 2003.
If you run Exchange 2000 as a component of Small Business Server 2000,
you can do an in-place upgrade to SBS 2003. If you run Exchange 5.5 as
a component of SBS 4.5, Microsoft has a 48-page document detailing the
required steps for replacing an SBS 4.5 server with an SBS 2003 server.
Playing Croquet with a Flamingo
Now you’re ready to do the upgrade. If you’re starting with an NT domain,
your first job is to upgrade to Windows 2003. Don’t deploy Win2K. Why
spend time deploying four-year-old technology that’s not as stable, secure,
or streamlined as the current version? The roadmap for a typical single
domain upgrade looks like this:
- Upgrade the current PDC to Windows 2003. Use a leapfrog upgrade
by installing a new server as an NT BDC, promote it to PDC, then upgrade
it to Windows 2003.
- Install additional Windows 2003 DCs. Don’t tempt fate by having
any fewer than three DCs in a domain. This lets you take one DC down
for maintenance and still have two up and running.
- Decommission all NT BDCs. This eliminates the need to support
legacy DC replication.
- Shift the domain and forest to Windows 2003 functional level.
This enables you to create Universal Security Groups, a requirement
for proper Exchange operation in a multiple domain forest, and for supporting
high-end Exchange features.
If you consolidate NT domains as part of your Exchange deployment, you
need to first stuff AD with the user, group and computer accounts from
the source domains. Then you can start your Exchange 2003 deployment.
An account migration populates an AD attribute called SIDHistory, which
contains the SID from the source domains to retain access to legacy resources
such as their Exchange 5.5 mailboxes.
Once the domain’s been upgraded, focus on upgrading the messaging infrastructure.
There’s no direct upgrade path from Exchange 5.5, so you’ll need to deploy
new Exchange 2003 servers and move mailboxes and connectors to the new
servers. The roadmap for the second phase looks like this: n Install SP4
and the latest security patches on all Exchange 5.5 servers. This gives
each Exchange server the ability to read and write to the legacy Exchange
directory service via LDAP, a critical feature to support connectivity
with Exchange 2003.
- Normalize mailboxes. Spend an afternoon, maybe a long afternoon,
validating that you have a one-to-one match between each legacy Exchange
mailbox and an AD user. At the same time, verify that each mailbox owner
actually exists in AD. The AD Connector (ADC) tools in Exchange 2003
will also perform this check, but you don’t want to wait until the middle
of the deployment to find out that you have a problem.
- Verify public folder permissions. Spend another long afternoon
going through the permission list for each public folder to ensure that
the recipients and distribution lists actually exist. This avoids having
zombies on the permission lists; that is, distinguished names that don’t
point at a valid account in the legacy Exchange directory service. Exchange
2003 contains safeguards against problems caused by zombies, but you’ll
have more success in your deployment if you avoid them entirely. The
Pfadmin tool does a great job of identifying zombies. KB
188629, “XADM: Using PFADMIN to Remove Public Folder Permissions,”
discusses how to remove invalid permission entries using Pfadmin.
- Install the AD Connector (ADC). This updates the AD schema
to include all changes required by Exchange Server 2003. Fortunately,
the Exchange 2003 ADC Setup makes the same schema and forest changes
as Exchange 2003 Setup, so you only need to do this work once.
- Configure Recipient and Public Folder connection agreements. A
Connection Agreement (CA) defines a pathway between AD and the legacy
Exchange directory service. The ADC uses CAs to transfer mailbox information
from legacy Exchange to mailbox-enabled users in AD and to create Distribution
Groups and Contact objects in AD that match the distribution lists and
custom recipients in legacy Exchange.
- Install the first Exchange 2003 server. This creates a Configuration
connection agreement in the ADC that copies information about the legacy
Exchange organization into AD. This server also runs an instance of
the Site Replication Service (SRS) so the Exchange 2003 server can replicate
directly with legacy Exchange servers in its site.
- Move Connection Agreement endpoints. An Exchange 2003 server
running SRS can act as an endpoint for connection agreements. The ADC
Connection Agreement Wizard initially assigns endpoints to legacy Exchange
servers. You have to manually move the endpoints of Recipient and Public
Folder CAs to an Exchange 2003 SRS server.
A Mad Tea Party
In the final phase, you’ll decommission your legacy Exchange servers and
shift the organization to Exchange Native mode to get full access to all
Exchange 2003 features. Here’s what the last mile of the roadmap looks
- Move mailboxes. You can move mailboxes to the new Exchange
server from legacy Exchange servers in the same site. The Exchange organization
is still in Mixed mode, so you can’t move mailboxes directly between
servers in different legacy sites, which correspond to Exchange 2003
Administrative Groups. This requires using Exmerge or third-party utilities
such as Aelita
Exchange Migration Manager.
- Move connectors. The legacy Exchange server probably hosts
a variety of connectors, such as the Internet Mail Service (IMS) connector,
Site connector, Directory Replication connector, and possibly additional
connectors for X.400 or third-party e-mail systems. (If you have an
X.400 connector, you’ll need Exchange 2003 Enterprise Edition.) Create
new connectors on the Exchange 2003 server and make sure that those
connectors work satisfactorily before removing the legacy connectors.
- Decommission legacy servers. At this point, you no longer
need the legacy Exchange servers in this particular site. De-install
Exchange from those servers. This removes their objects in the legacy
Exchange directory service and, thanks to the ADC, from AD.
- Repeat for other sites. During the time you’re upgrading the
first Exchange site to Exchange 2003, you can start upgrading the other
sites using the same steps. This invariably takes twice as long as you
originally had in the schedule, but at some point, the work will be
- Shift to Exchange Native mode. Once all legacy servers have
been removed from the organization, you can remove the Site Replication
Service from all Exchange 2003 servers, then set the Native flag in
the organization to release it from compatibility with legacy Exchange.
This has a long list of advantages, including the ability to move mailboxes
between servers in different sites, faster SMTP message transfers between
routing groups and the ability to send e-mail to Query-based Distribution
Groups (QDGs), which have dynamic membership based on LDAP queries.
If you’re already in the midst of an Exchange 2000 migration from Exchange
5.5, avoid deploying Exchange 2003 until you’ve finished. Microsoft refers
to this as "TIPTOS," derived from the chemical symbols of the
code names for the three Exchange products: Titanium for Exchange 2003,
Platinum for Exchange 2000 and Osmium for Exchange 5.5.
You don’t want to get involved with a TIPTOS migration. You’d need to
include multiple strategies for directory service replication, multiple
strategies for message routing, and keep track of the eccentricities of
each type of server with a possibly different mix of antivirus, antispam
and back-up agents. Imagine diagnosing and fixing problems when you can’t
get the servers to interoperate for some inexplicable reason. Then imagine
what your resume might look like after you explain to your boss for the
hundredth time why the CEO isn’t getting her e-mail.
It’s been nearly four years since the release of Exchange 2000 and a year
since the release of Exchange 2003. The support clock on Exchange 5.5
is ticking and time is just about to run out. If you have specific issues
holding you back from proceeding with your migration, you should contact
Microsoft and get them resolved. You can also drop me a note in care of