Re: can NT4 servers and 2003 server play nicely together?

From: Jim (nobodyhome_at_antispam.tv)
Date: 02/27/05 

Date: Sun, 27 Feb 2005 05:06:31 -0600

"bvonh" <bvonh@discussions.microsoft.com> wrote in message
news:597B0573-1E0C-4D9C-A064-9F3F5D6F78E1@microsoft.com...
> We have two NT4 servers for our domain. I was recently told by a
consultant
> that I could install the new 2003 server (using a different domain name)
on
> the same network at the same time without causing problems for our NT
domain.

This is correct.

> The thought process being to install the new 2003 box, migrate from the
NT
> domain to the AD domain of a different name (using the migration tools).

This will also work, as long as the NT4 domain is not a NT 4.0 Small
Business Server domain. I found from bitter experinence that you can't
migrate a NT 4.0 SBS domain to a 2003 domain because you cannot establish a
trust to the 2003 domain from the SBS domain.

You can migrate the server's files and their ACLs to the 2003 domain using
any of a number of tools, but the domain stuff (user accounts, groups) will
need to be done manually in the NT 4.0 SBS scenario. None of the migrations
tools work with NT 4.0 SBS because of the inability for NT 4.0 SBS to
establish trusts to another domain. NT 4.5 SBS is a different story, and it
can establish a trust with a 2003 domain with a one or two line registry
edit on the NT PDC side.

>He
> then told me we could take down the NT4 domain and then use a tool to
> "rename" the AD domain server back to the name of the old existing NT
domain.

Hmmm.

I've never actually tried this. My recollection of the Active Directory
documentation says that the highest-level (or "master" in NT 4-speak) domain
cannot be renamed even though lower domains under it can be. Your scenario,
if I understand it correctly, results in two "master domains" (again, in NT
4-speak), and I don't think you can rename the 2003 one.

Another solution is possible if the old NT 4.0 domain is *NOT* NT 4.0 SBS.
Why not build a 2003 server and then dcpromo it to run in NT 4.0 BDC
emulation mode. Then when you get rid of the old NT 4.0 PDC and any 4.0
BDCs, use a tool to migrate and upgrade the remaining 2003 "BDC" into a
full-fledge 2003 domain controller.

This way you do not have to dork around with domain accounts, groups, SIDs,
etc., nor do you have to play with domain renames.

Nor will you have to play the editing game I describe below.

> This would keep us from having to touch every computer for reconfiguring
> domain stuff.

This has always been a royal pain in the *** for me when migrating from a
workgroup (or an NT 4.0 SBS domain) environment to a 2003 domain. Manually
moving email messages and settings, etc., to the new profile on the same
machine is a real pain and a time waster, as is moving all the start menu,
programlist stuff.

I found a shortcut that works on such cases where the workstation is running
XP Professional. It is not as reliable when trying it on 2000 Pro
workstations, however.

When you first log onto an untrusted (the case with the NT 4.0 SBS
migration) domain or from a workgroup environment, Windows creates a new
profile in "%systemdrive%\Documents and Settings" for you and uses the new
domain name as a suffix to the userid in the profile image path variable for
uniqueness. And, of course, the old stuff (like email, etc.) is no longer
accessible as it's now in a different folder.

I was able get logon to use the old profile directory (and to retain
"settings" for email, web browser, etc., and "desktops" backgrounds, icons,
etc.), by doing the following:

First, log the workstation into the new domain to create the new profile.

Then using regedit on each workstation and for each user on that
workstation, edit the profile image path value for the NEW profile
associated with the SID for the user on the new domain to point back to the
old \Documents and Settings directory. The registry key to use is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\ProfileList\sidvalue\ProfileImagePath.

In the entry that corresponds to the new domain (the "sidvalue" in the
subkey), you can use the old profile list by simply truncating the new
domain name from the ProfileImagePath variable (typically) or by replacing
the old domain name suffix with the new domain one.

Example: Change "%SystemDrive%\Documents and Settings\userid.domainname" in
the value name for "ProfileImagePath"
to "%SystemDrive%\Documents and Settings\username" in the ProfileList subkey
for the entry corresponding to the new domain. This will cause logon to use
the old or former "settings" in the old \Documents and Settings directory to
provide consistancy.

Several words of caution, however: This is a "use at your own risk" trick.
It may not work in your environment. Second, don't forget that data files
come with SID on ACLs, on both the file servers and the actual workstation
itself. These ACLs MUST be reset to reflect the new domain user SID to
remain accessable.

Third: It is MUCH, MUCH easier, IMHO, to add a 2003 BDC to the NT 4.0,
populate it with the domain stuff, then cut out the NT 4 PDC/BDCs, and
finally migrate the "BDC" emulation mode into a 2003 native domain.

When I was faced with the NT 4.0 SBS domain migration, I ultimately had no
choice but to play games with registry entries and add file ACLs for the new
domain to retain continuity to the old desktops and settings and the user's
files. Believe me, I tried every tool, and every trich I could find to try
to avoid it but nothing worked. And it was a royal pain in the ***, let me
tell you; it teetered on the brink of being unmanageble.

>I guess my main question is whether or not these servers can
> both be on the wire at the same time.

Yep. And not only that, but "network neighborhood" and "my network places"
will see BOTH domains as well. If you have accounts in both, you can even
map drives and shares..

> Thanks in advance.

I hope this helped.

Good luck.