Security Advisor

Voodoo Exchange

Moving to Exchange 2000 offers a valuable opportunity for jumpers and their more methodological counterparts to learn that permissions define possibilities and practicalities.

• By Roberta Bragg
• 05/01/2001

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 upgrade one.)

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 in-place.

Monday Morning
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 later steps.

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 nod.

Second trick: Their next chore was to configure the Connection Agreement (CA).

“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 it out.

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.

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 upgrades.

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.”)

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 managed-mayhem approach.

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.

• ADC
• CA
• 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 themselves?”

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 break.

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 problem.

“Place your hands on the monitor tops and chant with me,” I commanded. “Ohmmmmmmm...Ohmmmmmm....”

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.)

Toute Suite
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 hex bolts?

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.