In-Depth

Planetary Domain

This manufacturing company is seeing its operations spread out around the planet and using Windows 2000 to tie it all together.

• By David Poppel
• October 01, 2001

We're part of a German organization that's currently connected globally only through e-mail, via a Lotus Notes Domino domain and opened ports (restricted to specific IPs) on our Internet firewalls. The main North American office is in Connecticut, and there are approximately 300 users on the network worldwide. There are a number of different domains, including several Novell domains, Windows NT 4.0, domains, and workgroups, as shown in Figure 1.

What We Envisioned for Our Infrastructure
The final goal was to have a global Win2K AD domain, connected via a VPN, in addition to the Lotus Notes Domino domain. The U.S. domain would have two sites. The Connecticut site had two main buildings about four miles apart, connected by two T-1 lines. Two DCs for the empty root domain would sit in one building, plus two DCs for the U.S. domain. There are 140-plus user PCs and a total of 18 servers for this site. Another U.S. site will be created next year in South Carolina for a new manufacturing plant. After completing the Connecticut site, we'll work on adding two sites in the Germany domain, one site in the China domain, and one site in the Singapore domain. Figure 3 shows the final domain configuration.

Reasons for the Switch
The first reason for our implementation was just the basic need of having to stay up with software advances. Everyone knows that eventually new applications will require Win2K, that support for NT 4.0 will be harder to come by, and new features that Win2K brings will be ones we just can't live without. I'm certainly not saying this is going to happen tomorrow (in fact, I'm sure it will be some time yet). Nevertheless, that day will come.

The second major driving force is the fact that, every day, we were seeing a greater need to get our global networks communicating together. We had more salespeople, plant operators, accountants and so on making trips around the globe than ever. These users needed to be able to tie their notebooks into any of our global subnets and access all of the resources and documents they need.

We also wanted new, dedicated servers for the Win2K domain because we'd been trying to do too much with the NT 4.0 DCs. It wasn't a question of the old DCs being able to handle the work load; instead, it was more a problem of administration and maintenance. It becomes an issue, for example, when you want to add a service pack to a DC and that server is also acting as a file server.

With at least two DCs dedicated only to functions like user authentication, DHCP, DNS and so on, an administrator can easily take one DC offline temporarily for whatever administration, maintenance or testing is needed. Spreading server applications and domain services among multiple servers had been an ongoing project, separate from Win2K.

Figure 1. The old domain structure worked but was badly out of date for the company's needs.

Figure 2. As of late July, the empty root Win2K domain had been created, as well as the U.S. domain. Much still remains to be done, however.

Figure 3. The final structure eliminates the Novell domains and workgroups and makes administration and management much easier.

In-place Upgrade vs. Migration
We decided to go with migration. We chose to create a pristine Win2K domain with the new servers instead of an in-place domain upgrade for various reasons. First, we wanted to have a clean installation of the domain and DCs, so there would be no legacy NT 4.0 configuration choices or registry entries.

Next, we wanted to migrate servers, client computers, and users slowly over to the Win2K domain due to resource and time restraints.

Another issue was learning Win2K well enough to be comfortable with it, testing it, and creating an AD structure that would be the foundation of our global network. The domain naming convention also needed to be radically different. It's certainly not a project to pull off in a weekend.

Notebook EFS: Just Don't Do It Thinking of incorporating the Encrypting File System (EFS) with your notebook computers? My advice: Don't do it! Go with a third-party solution that will protect the entire partition or even the entire hard drive. I spent many months, much research, and multiple test scenarios finding out that it just isn't worth the aggravation. The obvious shortcomings are that EFS won't encrypt system files, can't be set up to work with groups, and is time-consuming to plan and implement in an enterprise environment. Since you must carefully choose what to encrypt, you're tasked with a configuration nightmare from the beginning. I decided to create a folder called "Encrypted_Data," and set up NTFS permissions that wouldn't allow the user to create another data folder—they could only create sub-folders under this folder. Then I encrypted that folder with the user's logon. The NTFS permissions got way too complicated to spell out here, but I had to think about all the various software installed and all the many sub-folders where the user would need wider permissions than I was allowing off of the root directory by default through inheritance. Then I decided to encrypt the places where other data files could be stored. I encrypted the temp folders and desktop. (Note: Remember the part about not being able to encrypt system files? I found out the hard way that if you want to encrypt the desktop, encrypt only that folder, and not the entire user folder under Documents and Settings. You won't always get an error message if you try to encrypt something you shouldn't.) Then I encrypted other data folders for the specific applications installed—all this while being sure to use the user's logon and only after the applicable NTFS rights were configured. Finally, I exported the local administrator's recovery key and stored it in a safe place. Then we ran into a major snare. If anything out of the ordinary happens to the Local Administrator account before the recovery key can be exported, kiss your recovery options goodbye. (See Knowledge Base Q259732, "EFS Recovery Agent Cannot Export Private Keys," for more information.) In our case, we weren't able to export the recovery key on a number of notebooks after we tried using a ghost image to deploy partially configured systems. (The ghost image was created before any EFS configuration was done.) Just say no to EFS on laptops. You'll thank me in the long run.

March 15, 2001: Knowledge Base to the Rescue—Again
Another hurdle was overcome by the sweat of my brow and the good ol' Microsoft Knowledge Base. Now that Dynamic DNS appeared to be running smoothly, with a delegated DNS namespace for our child U.S. domain, I thought I'd do a little work on DHCP.

Installing the DHCP Server service was a snap through the Add/Remove Programs applet, but configuring it took a little work. We were using a 10.x.x.x/20 IP scheme for this site and using reservations for the JetDirect printers. Because there's a bit of work setting up exclusions for the IPs the servers use (there are more than a dozen servers total), and especially setting up reservations for 30-plus printers, I wanted an easy way to copy over the DHCP server database from one DC to the other. (By the way, we weren't concerned about the PTR records security issue with DHCP running on a DC since our network is isolated from the outside.) I found my answer in Knowledge Base Q130642, "How to Move a DHCP Database to Another Windows NT Server."

There was a bit of trepidation due to Microsoft's warning that you could really screw up a server if you make a mistake; but what the heck—it's a test environment! I followed the steps religiously, and added one more step—since I wasn't replacing a DHCP server—by changing the IP range being handed out. I'm happy to say it all worked out as planned. Now I had two DHCP servers with identical settings, including reservations, with just the one difference mentioned. I tested it out, and the servers started handing out IPs to clients with no difficulties, even clients on the NT 4.0 domain. There was a problem when an NT 4.0 domain client got an IP from one of the Win2K DHCP servers that had to do with seeing our e-mail server, but that's for another day. I turned off the two scopes for now, knowing that overall it was a success.

The Week of April 20: Fun With RRAS
This week we moved our Win2K Remote Access Server from the NT 4.0 domain to the Win2K domain. This was an interesting experiment. Before this moment, we hadn't yet migrated any of the users over, so all we wanted to change was the domain membership of the server. The goal was to continue using the NT 4.0 accounts to access the NT 4.0 resources via the external trust that existed. I had no idea if this would work, but we were brave enough to give it a try.

Various problems confronted us from the start. Eventually we'd set up L2TP, IPSec, certificates and so on, but for the moment PPTP would serve our purposes. Even though my Win2K Pro DUN connection was set to auto for this setting, I kept getting a certificate error. Configuring the connection to use PPTP specifically solved that error. (RRAS in Win2K Server creates five PPTP connections and five L2TP connections automatically, by default.)

I was still having difficulties connecting remotely through this server, though. After a little searching in the Knowledge Base, I ran across Q227747, "Routing and Remote Access Server Stops Authenticating Dial-Up Networking Clients." If RRAS is configured after the server is already a member of a Win2K domain, the server is automatically registered as a remote server in AD. This, however, wasn't the case with our server. Because our server was added to the domain after it was already a RRAS server, it needed to be registered manually into the AD.

One more problem confronted us. I received domain validation and was able to read my Lotus Notes e-mail; but when I tried to access my network shares, I received nothing but a blank screen. This one had us going for a while, but Offline Files turned out to be the culprit. Once I forced a synchronization, I had access to all of my shares and files. It was a good day.

Why Windows 2000 Kicks NT 4.0's Butt One of my favorite new features is Offline Files. This entire feature requires only a single client running Win2K Pro. No need for a Win2K domain or even Win2K servers, although these would make Offline Files a little more manageable with more options. Hasn't managing the users' desire to have offline copies of their documents been a thorn in the flesh to all administrators? If two different users wanted to do this, two different solutions had to be fashioned. Since implementing Win2K, I've seen far fewer blue screens. I'd still be a little nervous if I found out the Federal Reserve banks were running Win2K, but a little less blue is always a good thing. Another great feature is group policy. I never even tried to work with NT 4.0 System Policies due to the complexities and horror stories; group policies are a whole different animal. I'd been setting up so many that I was losing track and had to get back to documenting (be sure to do a lot of that). It's a powerful feature that really adds to the administrator's ability to control the network, which becomes more important as the network grows. There are, however, some drawbacks. Not everything you'd like to control is available, and you'll have to sharpen your programming skills to add those missing settings. Another negative is that it's very easy to disagree with Microsoft's organization of the settings. I currently have three settings in a group policy for the redirection of the user's My Documents folder, and all three are in different areas of the group policy settings. I could also mention how nice it is to have DNS entries "magically" appear through Dynamic DNS and how great it is to have Organizational Units with the ability to delegate administrative rights without giving away the keys to the castle. Overall, I believe the project has been very much worth the effort.

April 20: User and Group Migration Day!
This was user and group migration day. From what I've read, there are four choices to migrate users and groups from an NT 4.0 to a Win2K domain. There's the obvious choice of doing it manually, but with more than 130 users and 50 groups, this would be tedious. Then there are the built-in tools: ClonePrincipal, Netdom and Active Directory Migration Tool (ADMT). Note that MoveTree isn't a choice, as it can only be used within a Win2K forest and not from a migration from NT 4.0 to Win2K. I picked ADMT since it appeared to be the most robust of the choices.

TechNet has an NT 4.0 to Active Directory Domain Migration Cookbook (available at www.microsoft.com/WINDOWS2000/techinfo/planning/activedirectory/
cookbook.asp.) Chapter 9, which has an example scenario using ADMT to migrate users and groups from an NT 4.0 domain to a Win2K domain, was instrumental in making our migration of users and groups a relatively easy task. Just remember a few points when using ADMT (which is available for download at www.microsoft.com/windows2000/downloads/tools/admt/default.asp):

• The Win2K domain must be in native mode. This shouldn't be a problem, as there's no need for NT 4.0 BDCs in a Win2K domain in this scenario. After this, there are a couple of things to do in the NT 4.0 domain. There's a specific local group needed for ADMT's use, and a registry change on the PDC that requires a reboot. I made the registry change manually, but Microsoft states that ADMT will make the change for you (though I wonder about this, since ADMT is installed on the server in the Win2K domain.) Just be sure to remember the reboot, or—as I found out—the migration will fail.
• Be sure to migrate the groups first, then the users. That way the users will be put into the applicable groups automatically when they're migrated over. The instructions mentioned only global groups, but it appeared to work for both global and local groups.
• Passwords aren't maintained from one domain to the next. The migration of accounts isn't a copy in the true sense of the word. A completely new SID is created in the Win2K domain, then the NT 4.0 SID information is added to the SID history of this new object. In doing this, the user passwords aren't copied over. The two choices are to create a password that's the same as the user name (security alerts should be going off in your head about now) or to have ADMT come up with a "complex" password on its own. ADMT creates a text file of the user names and passwords it gives them so you can create a script to send in e-mail to users to notify them of their new password.

July 2001: Where We Are Now
It's been 18 months since the first proposal to migrate to Win2K and almost a year since the project's approval. I spent about nine months preparing for the actual rollout and now it's been about three months since we've really started implementing Win2K on a large scale. We currently have 75 percent of all computers, including clients and servers, running Win2K. All of the servers (most are running Win2K) have now been moved to the Win2K domain. What's left is to get the rest of the servers and client computers running the new OS and then added to the new domain. The current domain structure is shown in Figure 2.

Then we need to get the rest of the users using their Win2K domain accounts (currently, only about 30 percent are doing so).

Finally, we need to start rolling out Win2K in our plants in other countries. I hope to have the local migration completed in two to four months. (The biggest problem right now is time and manpower. This isn't our only on-going project.) The biggest task of all is yet to come: the global rollout. Due to the great distances, cultural differences, language barriers and so on, this will be challenging—but I hope also rewarding in the end.