Moving to Exchange 2000 offers a valuable opportunity for jumpers and their more methodological counterparts to learn that permissions define possibilities and practicalities.
Today, a loom I ordered in July finally arrived. It came in 11 boxes
(some of them weighed more than 100 pounds) with about a gazillion pieces.
When I ordered it, the thought of putting together this swing-set-sized,
computer- controlled, 24-harness, fabric-producing miasma of wood, bolts,
strings, gears and other assorted mechanical/digitized panoply really
didn’t faze me. I can build networks, I thought, I could do this. Now
12 hours, 10 tons of packing material, socket sets, screw drivers, wrenches
and no floor space in my seven-bedroom house later, I don’t know. I’ve
found the instruction book though (it’s about the size of my Microsoft
Official Curriculum Trainer’s Manual for course 1572, the Webster’s
Unabridged Dictionary and the King James Bible all rolled into
one), so there’s hope.
Today it’s weaving looms, last week it was helping Exchange 5.5 gurus
move their 5.5 servers to 2000. What it really boils down to in both scenarios
is that you need to make sure you do things in the right order and that
you have all the parts and tools you need to do the job. Like me in my
rush to unpack the loom parts and pieces, the Exchange admins I visited
got charged and excited about the new features in Exchange 2000 and forgot
those simple facts. On one side, they had a fully functioning Exchange
5.5 infrastructure; on the other, they knew they wanted Exchange 2000.
No problem. The Exchange migration team said, “We’re messaging superstars—we
can figure this out.” Fortunately, calmer heads prevailed (actually some
troublesome attempts at migration made them think more clearly), and we
decided to meet for some trial runs.
Ducks in a Row
I often work that way with folks—shepherding technical wizards through
their first experiences with some new technology. I set the scene, do
the prep, collect the resources; they provide the bodies and, if I’m lucky,
the sushi and sake on Friday night.
On Sunday I arrived in sunny-rolling-blackout-California—where the elevators
don’t work in hotels and women carry flashlights to the ladies room—and
proceeded to set up the test lab. I loaded three boxes with Windows 2000
Server: one to serve as the DNS server (I didn’t want the total destruction
of one team’s forest to destroy the other’s chances), and the other two
for my crew. All three servers were dcpromoed, but in three separate forests.
Additional machines (one for each participant) were loaded with Windows
NT 4.0, Service Pack 6a and Exchange 5.5. One NT box served as the PDC
and also had Exchange 5.5 loaded. (It’s common to find Exchange 5.5 on
a DC in smaller organizations, and I knew they’d want an opportunity to
My plan was simple: divide the team into two groups and provide them
with instructions, encouragement and a leg-up or a hand-out in times of
need. The team’s goal? Successfully migrate/upgrade all NT/Exchange 5.5
servers and/or their recipients to native mode Exchange 2000 organizations.
Along the way, the crew would move mailboxes from an Exchange 5.5 server
to an Exchange 2000 server and upgrade at least one Exchange 5.5 server
To get the job done right, you have to have the right
tools. To migrate to Exchange 2000 from Exchange 5.5
Operating System/Domain Structure Requirements
Windows 2000 Service Pack 1
Hotfixes described in the following Q article: Q272691:
XADM: Windows 2000
Requirements to Run Exchange 2000
Win2K Active Directory directory service (DS) domain.
All Win2K domain controllers in the organization must
also be running Win2K SP1, along with the hotfixes.
Exchange Server Upgrade-Version Prerequisites
Exchange 5.5 SP3 (AD service must connect to 5.5 SP3
server to synchronize directory of two systems.) A multiple
server organization can have some Exchange 5.5 servers
that don’t meet this requirement.
- The Exchange 5.5 server(s)
- Exchange SP3
- Win2K SP1
- Exchange hotfix
- Exchange 2000 CD-ROM
- Exchange Admin privileges in Exchange 5.5
- Schema Admin and Enterprise Admin permissions in
the AD forest
- Large pot of coffee and/or buckets of organic fruit
As the migration team members arrived, I let them choose their seats.
Ever notice the troublemakers always sit on the right side of the room?
It certainly was true here. To my left was the quiet, contemplative, methodical
group. To my right the jump-in-and-hack-out-the-answer group. Do both
approaches work? Well, they can, as long as the jumpers are willing to
expend twice the energy and completely rebuild their systems occasionally—in
short, OK in a test lab, verboten in a production environment.
The first assignment was to assemble the tools they’d need; so I provided
a parts list (see “The Tools You’ll Need”). Once the members had assembled
the CD-ROMs, downloads and goodies and once they verified that the Exchange
Servers and their Win2K servers were functioning, they headed down the
yellow brick road.
I’m Not the One...
Fortunately, this crowd’s not shy and, sure enough, Joel wanted to know
why the Exchange Servers weren’t all running SP3.
“Fair question,” I answered. “What do you think you ought to do about
it? Anyone else checked out the system configuration?” Grumbles from the
back of the room.
“Hey,” I tell them. “Your production servers may be patched and up to
date, but how many out there in the real world are?”
While each team collectively checked and added service packs and hotfixes,
I explained the Active Directory Connector (ADC). It’s the first magic
in this show. Because Exchange 2000 uses the AD and Exchange 5.5 has its
own directory, a connector must be created for them to share information.
To make this happen, install the ADC—the right ADC. There are two versions
of the ADC. The first one, available on the Win2K installation disk, allows
Exchange 5.5 servers to replicate their directory information with Win2K
AD. This isn’t the ADC to install if you’d like Exchange 2000 and Exchange
5.5 to coexist. Having them coexist during migration is a good thing (your
options are extensive). In addition to being able to upgrade in-place,
install a new Exchange 2000 server and simply move mailboxes and other
items to the new Exchange 2000 server. The ADC that allows this coexistence
comes on the Exchange Server 2000 installation CD-ROM. Before you install
it, create a service account for the ADC and keep this information for
Each group tackled the task. I purposefully created for the teams administrative
accounts that had no special privileges beyond Domain Admin. You can probably
guess the result—installation failure. Because loading the ADC modifies
the schema, you must be a member of Enterprise Admins and Schema Admins
to run it successfully. The group figured this out after they failed.
Was I cruel? I didn’t want them to fall into the trap of thinking I was
going to hold their hands. I wanted them to think about what they were
doing. If they failed, it was OK. It was a test lab and they’d remember
it better for later playbacks. Finally, properly permissioned, the teams
got their ADC installed.
Adam commented, “Remember, in the real world, if you have more than one
domain, changes to the schema may take some time to replicate to all domains.
You’ll want to add appropriate ‘wait’ time to your migration plans.” Head
Second trick: Their next chore was to configure the Connection Agreement
“Whoa,” Fred said, “CA? I thought that stood for Certificate Authority.”
I agree. I wish Microsoft would get its acronyms straightened out—Connection
Agreement has no relationship to Certificate Authority. Configuring the
Connection Agreement isn’t hard; but you must enter the account names
and the passwords of the Exchange 5.5 service account and the ADC service
account. These are the accounts that’ll be used to replicate data back
and forth between the two directories. And there’s one additional bugaboo
that can make a 10-minute job stretch into hours. The account of the administrator
who is configuring the CA must have Admin Permissions on the Exchange
5.5 site and configuration container as well as permission on the Win2K
side of things. It seems such an obvious thing, once you’ve fought through
it, but it often catches a good team with its proverbial appendage covers
in the down position. When permissions aren’t in order, configuration
will fail. Multiple error messages are produced. If you’re lucky, one
of them may actually point you to the answer.
At this point, the jumpers had already tried to create the CA, failed,
and were arguing among themselves over whether they should give the Exchange
5.5 service account Schema Admin privileges in the AD or give the Win2K
account they were using Exchange 5.5 service account privileges.
“You can’t do either,” I told them, only to be ignored. I knew I risked
returning to some dead systems, but I took a coffee break while they puzzled
From around the corner I heard a loud “ahhhh.” Someone from the left
side of the room had gotten it. In their rush to work magic, they’d forgotten
that they were working with two different domains here—an AD domain and
an NT domain. So the answer was...create a trust between the two domains,
then give the Win2K Admin Account Admin permission in the site and configuration
containers in 5.5—at which point, the CA could be correctly configured.
A quick look at AD Users and Computers showed that the NT domain accounts
had been replicated to AD.
Like most technical teams,
mine had a mixture of personalities
to doing new things technical.
Some need to jump right in and
break things, others are so
anal they’ll never try it on
their own. Ever notice how these
types drive each other crazy?
Part of my job is to be the
buffer. One technique I use
is to call a halt to the discussion
and make them go do research.
Let them back up their opinions
with a knowledge-base article.
On one of these forays, Cheech
came up with the following article.
It didn’t prove his point but
it did change the discussion.
I’ll let you check it out on
Blendolini Causes Choco-Banana
Snake Bites on Leg
While we munched on sandwiches, I filled them
in on the next steps. At this point, before an
Exchange 2000 server can be installed, run forest
prep, to modify the schema for Exchange, and domain
prep, to make domain-related changes. The jumpers
wanted to install Exchange and let the install
program play these processes for them, but the
other group argued for the cautious approach.
The other group was right.
In a large enterprise, the schema changes need time to replicate (there
are a tremendous number of changes made; this is no simple operation),
so it makes sense to do forest prep and then wait before installing Exchange.
There’s an additional precaution at this point. When forest prep is run,
you must choose the option for installing Exchange 2000 in an Exchange
5.5 organization. Otherwise, when you install Exchange, you must create
or join a pure Exchange 2000 organization. Make sure this step happens
before you install Exchange or you won’t be able to have your Exchange
5.5 servers in the forest. Both teams avoided this trap. They were learning
to ask questions of each other and not just go with their first instincts.
A successful forest prep followed by a domain prep completed this cycle.
Breathe In, Breathe In ...
Finally, after hours of working as a team, each member would get to install
Exchange 2000. One of the installs in each team was clean (we moved mail
boxes and decommissioned the 5.5 server), while several were in-place
While the team began the process, I continued to babble. Installing Exchange
2000 is easy and instructions are available many places. Upgrading in-place
also works well. To do so, first upgrade the NT server upon which the
Exchange server resides to Win2K. Test Exchange functioning and then upgrade
Exchange 5.5 to 2000. There are three important points to note.
First, when you create the first Exchange 2000 server in the forest,
an additional ADC connector is created. This connector performs synchronization
between the directories and allows the smooth movement of mailboxes and
such from Exchange 5.5 to Exchange 2000.
Second, it’s not necessary to create or select an account for the use
of the Exchange 2000 services. In Win2K the local systems account has
powers beyond its counterpart in NT. This allows the account the necessary
access, eliminating the need for a separate service account.
Fred heard me say this and heaved a sigh of relief. He recalled dealing
with nightmares created by installations of Exchange that improperly used
the Administrator account for this purpose.
Third, if this is the first Exchange 2000 server, a Site Replication
Service connector is created. This is responsible for replication of configuration
information between the two versions of Exchange.
Back to the lab: Upgrades of Exchange 5.5 to Exchange 2000 on member
servers went smoothly. Now it was time for the PDC. I asked the team if
it could think of any reason not to upgrade the PDC.
“Is there a permission issue?” Brian asked. Grins all around. “No,” I
answered, “but there’s an issue.” Brian explained that he already had
upgraded the PDC to Win2K and attempted to upgrade Exchange. He failed,
of course, as was my plan. You see, there’s this little problem of port.
(See “What We Have Here is a Failure to Communicate.”)
We Have Here is a
Failure to Commuicate
When Brian charged ahead and upgraded the NT PDC he
learned a lesson. The upgrade from PDC to Win2K DC went
smoothly, but Exchange wouldn’t start. The problem occurred
because Exchange 5.5 and the AD use LDAP. By default,
port 389 is used. This causes no problems when Exchange
5.5 is on a member server, but when Exchange 5.5 is
resident on a domain controller, a conflict can occur
when performing an upgrade in-place.
Here’s the scenario: While it isn’t a good idea
to install Exchange on a domain controller, many companies
have done just that. If you’re responsible for upgrading
these servers, you may argue that you should take the
time to invest in a separate Exchange 2000 box and move
the old Exchange 5.5 objects to the new, separate server.
However, financial resources, politics and so on may
So how do you make it work? The issue has to do with
the need of the system to communicate domain queries
using LDAP vs. Exchange 5.5’s need to use the same port.
Internally, because the same port is specified, communications
get confused and the upgrade just doesn’t occur. (I’m
told by Microsoft that the AD locks the use of 389 for
itself and therefore Exchange 5.5 is just left out in
There’s a simple solution—in the configuration container
of the Exchange 5.5 server, locate the Protocols container.
On the Properties page for LDAP, change the port to
something else—say, 390. (Do this before you upgrade
Adam Goes Native
Finally, all Exchange 5.5 servers on both sides of the room had been migrated
to Exchange 2000 or decomissioned. Mail was zipping around the room, I
hoped, about the progress we were making and not about my funny shoes.
The teams were proud of themselves and ready to go off and save the world
when I offered them one final challenge.
“Now that you have no Exchange 5.5 server in your forest, don’t you think
you should put the Exchange 5.5 organization in native mode?”
Native mode Win2K domains have no NT domain controllers. Exchange Server
native mode organizations have no Exchange 5.5 servers. Native mode Exchange
has advantages over mixed mode—but, before you take this step, be aware
you can’t go back. In our case (wanting to try everything), it was the
right choice to make, right at that moment. But how to do it? It was late
and everyone wanted this to be a trivial process. Adam stared at the Exchange
Properties page. He found where to make the change, but the button was
grayed out. He announced what a crock that was, but I was careful with
my response. If I responded in kind, Adam would be off hacking the registry,
the AD, the schema—all in an attempt to make his org 5.5-free. This late
in the game, I didn’t want to risk a total disaster, so I went for the
Wham! I slammed my hand down on the desktop then, in my best drill sergeant
impersonation, assigned tasks to the entire group.
“Adam, you’re the only one allowed to touch the keyboard or mouse.” (He
grinned.) “Simon, you’re the only one who can tell Adam what to do with
that keyboard or mouse. Adam, you have to wait for Simon to tell you—you
do nothing on your own.” (The smile faded). “The rest of you, let’s get
a game plan together!”
I asked for suggestions. “What about the current AD telling the Exchange
Org that there are still Exchange servers out here? To put another way,
what have we done that might need to be undone?”
I got a number of responses, which I placed on the board.
- Trust relationship
- ADC account
- 5.5 server objects in AD
It wasn’t orderly, but the team began to make decisions. I had to remind
them to follow the chain of command. “Let’s remove the ADC,” they suggested.
“Simon,” I asked, “Should this be done?”
“Yes,” Simon said, “Adam, remove the ADC.” Adam tried and failed. As
a group, they recognized that the CA must be removed first. Adam turned
to the keyboard. “Wait!” I shouted. “Simon says?”
“Oh,” Simon said, “Adam, remove the CA.”
And so it proceeded. Some time later, with extensive wandering through
the AD using adsiedit (this wasn’t necessary but it sure was fun), the
team thought it had every reference to Exchange 5.5 removed. Was the property
page “un-grayed”? Nope.
“Think,” I challenged them.
A couple of the guys gave up and went to make phone calls. (Adam was
still wandering through the AD with adsiedit.)
“Think. What else occurred when you were working on this project?” Joseph
joined me at the white board and we began to draw pictures. As we drew,
we talked. A 5.5 server, an NT DC, a Win2K DC, an AD triangle. ADC, CA,
arrows from point to point—Exchange 5.5 directory to AD. First Exchange
2000 server. New groups in the AD. New CA—new CA.
Finally Joe asked, “How do sites in Exchange 5.5 communicate between
Fred answered, “You need a replication object.”
David queried, “How do Exchange 5.5 servers communicate with Exchange
2000. Is something created? What’s the new CA created for?”
Dead silence. Someone left to get a drink, and I announced a 15-minute
While they chattered and answered their pagers I returned to the room.
It was late in the day and time for a little voodoo magic.
When the first Exchange 2000 server is installed, the Site Replication
Service (SRS) is also created. This service allows synchronization between
the Exchange 5.5 directory configuration information to AD and the Exchange
2000 server configuration information from AD to the Exchange 5.5 Directory.
In fact, the first Win2K server installed will have a “replica” of the
Exchange 5.5 directory—hence, the name. When all Exchange 5.5 servers
have been upgraded or decommissioned, the SRS is no longer required. But
as long as it’s present in the AD, the Exchange 2000 Organization cannot
be converted to native mode even though all Exchange 5.5 servers are gone.
So, while the guys weren’t looking, I snuck up on Adam’s DC. The Exchange
2000 console was already open, so it was a one-minute task to expand the
folders until the SRS appeared, then delete it.
Gathering the troops was difficult, but I managed. I told them that only
their combined psychic power and a little voodoo magic would solve the
“Place your hands on the monitor tops and chant with me,” I commanded.
Amazingly, they all fell in line. I felt like a televangelist. Now it
was time for the magic dust, so I sprinkled some dinosaur glitter over
the DC. With great flourish, I asked Adam to open the Exchange Properties
page. Amazing! No more gray-out. Adam gleefully clicked the button and
went native (whoop, holler and a little dance).
On the second domain controller I explained the trick. The team took
this org native as well, and we called it a day. (For my next act—and
the next four days—I planned a magical mystery tour through Exchange 2000.)
So now I’m back in the Midwest staring at loom parts and getting e-mails
from the team. Some are frantic—as in, “Help! What did I do wrong?” Others
are simply reporting in, “I just removed the SRS and took ’em native.”
There are even some pats on the back and nice murmurs from the company,
too. I love it when all my hard work pans out.
And the loom? It must be a permission problem.
Can someone delegate me the administrative rights
on raddle and tension box assembly or the single-box
flyshutter beater? Where’s the MMC snap-in for
the 24-harness Dobby cam so I can tighten its
My comments here aren’t meant to be
the definitive guide to migrating to
E2K. You’ll need more extensive help
and training on the migration process
before you migrate all those old 5.5
friends to an unfamiliar interface.
As of this writing, there’s no MOC on
migrating Exchange available (it’s planned,
just not out yet). The 1572 course doesn’t
include a murmur about migration.
Fortunately, there are some white papers.
where you’ll find a planning guide,
a deployment guide and other helpful
tools. Another excellent source can
be found at www.microsoft.com/Exchange/using/training/mec00.asp,
which offers the recorded sessions from
the conference on Exchange last fall.
The scenario described here is a fictional
account based on an actual experience presenting
the first part in the Voodoo Exchange ©
2001 series developed by Have Computer Will Travel
Inc. (Names have been changed to protect the innocent
and others.) It isn’t meant to be a step-by-step
approach, but rather to emphasize the permission
issues and other stumbling blocks in such a major
undertaking. Before you begin your Exchange 5.5
migration do further research.