Planetary Domain

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.

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.