Two-way trust between WIN 2K3 and NT 4.0

jrm73 · Guest

I'm having a lot of difficulty creating two-way trusts between WIN 2003
and NT 4.0 domains. Lmhosts files will not work on the WIN 2003 side.
I created a new one with all the correct hex entries ("DOMAIN NAME
\0X1B") to point to the NT 4.0 PDC's but it won't work. The only way I
can get it to work is by setting the WINS server on the 2K3 box to
point to the NT 4.0 PDC. The prob is that I am preparing to migrate 50
NT domains to 2K3 AD and need two-way trusts for all of them. Can I
constatly change the WINS server on the WIN 2K3 box? AS is add te WINS
address, create trust and then remove. Then add the WINS for the next
NT server and so on.
Also, the 2K3 servers are R2 and I can resove servers by name both
ways.

Thanks-

RC · Guest

As long as they are able to communicate and ping by name there shouldnt
be any issues. When i did this i had to make sure I started the "trust"
on the NT side. on the PDC Trusting Domain: domain.com, then on the 2k3
side AD Domains and Trusts added the two way trans trust. believe it or
not i had the same prob as you when i tried to do it the other way,
2003 to NT4.

Jorge Silva · Guest

Hi

Why don't you point the WINNT servers to the Windows 2003 ?

Check some aditional information
Informative Sites:
Migrating from Windows NT Server 4.0 to Windows Server 2003
http://www.microsoft.com/downloads/details.aspx?FamilyID=e92cf6a0-76f0-4e25-8de0-19544062a6e6&DisplayLang=en
Upgrading from Windows NT Server 4.0
http://www.microsoft.com/windowsserver2003/upgrading/nt4/default.mspx
How to Upgrade from Windows NT Server 4.0
http://www.microsoft.com/windowsserver2003/upgrading/nt4/howto/default.mspx
Best Practice Active Directory Design for Managing Windows Networks
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx#E1AAG
Microsoft File Server Migration Toolkit
http://www.microsoft.com/windowsserver2003/upgrading/nt4/tooldocs/msfsc.mspx

Considerations:
- Install the latest service pack.
http://www.microsoft.com/downloads
- Check Hardware.
Windows Catalog and HCL
http://www.microsoft.com/whdc/hcl/default.mspx
Active Directory Sizer
http://www.microsoft.com/windows2000/techinfo/reskit/tools/new/adsizer-o.asp
- Windows Application Compatibility
http://www.microsoft.com/technet/prodtechnol/windows/appcompatibility/default.mspx
- Document everything network related (users, groups, permissions,
printers,etc).
Upgrade or migrate?
Reasons to Upgrade
Especially for small organizations, the ease of an upgrade rather than a new
installation can make sense. Generally, with an upgrade, configuration is
simpler, and your existing users, settings, groups, rights, and permissions
are retained. Also, with an upgrade, you do not need to re-install files and
applications.
Reasons to Migrate
There are good reasons to migrate rather than upgrade-especially when
dealing with large organizations. If you want to practice careful
configuration management, for example, for a server where high availability
is important, you might want to perform a new installation on that server
instead of an upgrade. This is especially true for servers on which the
operating system has been upgraded several times in the past.
Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory
http://technet2.microsoft.com/WindowsServer/en/Library/b170bdc5-ba55-4184-8a8f-acb7705ff04a1033.mspx
Migrating Windows NT Server 4.0 Domains to Windows Server 2003 Active
Directory
http://www.microsoft.com/windowsserver2003/evaluation/whyupgrade/nt4/nt4domtoad.mspx
Active Directory Migration Tool v.2.0
http://www.microsoft.com/downloads/details.aspx?FamilyID=788975b1-5849-4707-9817-8c9773c25c6c&DisplayLang=en

Planning:
- Failover.
* Backup the Servers.
* Take at least one BDC Offline (In case of UPGRADE FAILURE you always can
promote it to a PDC). The only drawback to this method is that all changes
that were made while the safe BDC was offline are lost. To minimize this
loss, you could periodically turn the safe BDC on and off (when the domain
is in a stable state) during the upgrade process, to update its safe copy of
the directory.
To convert the BDC to a PDC: Start -> Programs -> Administrative Tools ->
Server Manager -> Select the BDC, then go to the Computer Menu -> choose
Promote to primary Domain Controller.
* Make sure that the Hardware and apps meets the requirements.
* Make sure that all Apps installed are compatible with W2K3 and don't cause
problems with the upgrade process or pos upgrade process.
* Run from command prompt:
Cdsource\I386\winnt32.exe /checkupgradeonly

- Before Upgrade:
* You can install a new computer (more powerful) make it a BDC, SYNCRONIZE
and promote it to PDC and them perform the upgrade on the new PDC.
* Windows 2000/XP always prefer Kerberos authentication, so if the newly
upgraded NT4 to Windows 2003 goes down (Offline), the client machines won't
be able to authenticate in the domain.
* If this is the case, before upgrade the NT.4 PDC, make the necessary
changes on the registry (NT4Emulator). If the NT4Emulator is configured on
the newly PDC, and you want o upgrade the Existent BDCs, you also need to
create a registry entry on the BDCs (NeutralizeNT4Emulator) before the
upgrade.
Check:
Windows 2000-based clients connect only to the domain controller that was
upgraded from Windows NT 4.0 in a mixed-mode domain
http://support.microsoft.com/?kbid=284937
How to prevent overloading on the first domain controller during domain
upgrade
http://support.microsoft.com/kb/298713/
Once that all domain controllers are upgraded, remove the registry settings
created in the previous steps.
Note: This sometimes may not need: E.g - if all existent BDCs will be sun
upgraded to Windows 2003.

- Dns Planning:
Prior to beginning the upgrade from Windows NT Server 4.0 to the Windows
Server 2003 Active Directory service, ensure that you have designed a DNS
and Active Directory namespace and have either configured DNS servers or are
planning to have the Active Directory Installation Wizard automatically
install the DNS service on the domain controller.
Active Directory is integrated with DNS in the following ways:
Active Directory and DNS have the same hierarchical structure. Although
separate and implemented differently for different purposes, an
organization's namespace for DNS and Active Directory have an identical
structure. For example, microsoft.com is both a DNS domain and an Active
Directory domain.
DNS zones can be stored in Active Directory. If you are using the Windows
Server DNS service, primary zone files can be stored in Active Directory for
replication to other Active Directory domain controllers.
Active Directory uses DNS as a locator service, resolving Active Directory
domain, site, and service names to an IP address. To log on to an Active
Directory domain, an Active Directory client queries its configured DNS
server for the IP address of the Lightweight Directory Access Protocol
(LDAP) service running on a domain controller for a specified domain.
While Active Directory is integrated with DNS and they share the same
namespace structure, it is important to distinguish the basic difference
between them:
DNS is a name resolution service. DNS clients send DNS name queries to their
configured DNS server. The DNS server receives the name query and either
resolves the name query through locally stored files or consults another DNS
server for resolution. DNS does not require Active Directory to function.
Active Directory is a directory service. Active Directory provides an
information repository and services to make information available to users
and applications. Active Directory clients send queries to Active Directory
servers using LDAP. In order to locate an Active Directory server, an Active
Directory client queries DNS. Active Directory requires DNS to function.
If use BIND DNS servers Make sure that you have BIND 8.1.2
- Supports: Srv records, Dynamic Updates, Doesn't Support Secure Dynamic
Updates (this is one disadvantage over the MS Dns server Servers, and
represents security issues).
- Create Primary Zone
If Use 2003 DNS
* Create Primary Zone
* You can use an pre existent Dns or you can create it during the upgrade
process.
* Convert to AD-Integrated.
* NetDiag /fix (This is an extra measure, to register the necessary dns
records).
Check:
Troubleshooting DNS
http://technet2.microsoft.com/WindowsServer/en/Library/de2aa69d-1155-4dc9-a651-e8362f6a81c81033.mspx

How to Verify the Creation of SRV Records for a Domain Controller
http://support.microsoft.com/?id=241515

Verify DNS server responsiveness using the nslookup command
http://technet2.microsoft.com/WindowsServer/en/Library/f8761f04-d665-4507-9509-ebb92bbb66ef1033.mspx

- The Upgrade.
* Check if you're on the PDC -> Start -> Programs -> Administrative Tools ->
Server Manager.
Right click on Network Neighborhood -> check the name.
Run from command prompt:
Cdsource\I386\winnt32
* The first server running Windows NT Server 4.0 that you must upgrade is
the primary domain controller (PDC), then you upgrade all remaining BDCs. To
check if you're on the PDC: Start -> Programs -> Administrative Tools ->
Server Manager.

Check:
How To Upgrade a Windows NT 4.0-Based PDC to a Windows Server 2003-Based
Domain Controller
http://support.microsoft.com/?id=326209

If you don't have windows 2000 (Only NT4 and Windows 2003) in the domain
choose the FFL (Forest Functional Level) Windows 2003 interim.
* Make sure that your DCs Dns properties point to Right Dns server (usually
the Dc is also a Dns server so it must point to itself).
* Once you have upgraded the Windows NT Server 4.0 and earlier PDC, you can
proceed to upgrade all remaining BDCs.
* Make sure that you have 1 GC per site (GCs are needed unless: you only
have one domain, or the DFL is prior to Windows 2000 or Windows 2003).
* Make sure that network clients point to the Network Dns server only
(Usually the DC).
* If everything is ok, then and if all DCs are already Windows 2003, now
it's time to remove the registry entries (NT4Emulator,
NeutralizeNT4Emulator), and make the DFL and FFL windows 2003.

Verifying Active Directory Installation
http://technet2.microsoft.com/WindowsServer/en/Library/3d157c1a-5c80-4947-ba8b-a02e5fb1dada1033.mspx

--
I hop that helps

Good Luck
Jorge Silva
MCSA
Systems Administrator

"jrm73" <jayrmontana@yahoo.com> wrote in message
news:1147986730.645880.82580@y43g2000cwc.googlegroups.com...

Paul Williams [MVP] · Guest

Ideally the domains will temporarily share the WINS database. So configure
the different WINS servers to be replicas of each other. We have customers
running all versions of Windows setup in this way, e.g. four customers all
trust one another, therefore all four replicate the same WINS database.

If you can't share the WINS database, please post your LMHOSTS files here
and explain a little about the environment.

--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

jrm73 · Guest

Thanks for the info. At this point I am creating 2-way trusts on the
WIN 2K3 server for all my NT domains. After that I will create the
trust on the NT side one by one. All the NT servers are separte
domains, run WINS and point to themselves. Chaning WINS and rebooting
all of them will take to much time. So I am simply changing the WINS
address on my WIN 2K3 DC every time I create a 2-way trust for an NT
domain. After that, the NT servers let me createthe trusts to and from
the 2K3 domain. Not sure why my LMHOSTS file isn't working. Below is
a chuck of it.

192.168.55.13 DCICHISYS2 #PRE #DOM:DCIADMIN
206.208.193.25 "DCIINC \0X1B" #PRE
206.208.193.25 DCICORAD2 #PRE #DOM:DCIINC
192.168.55.4 DCICHISYS1 #PRE #DOM:DCIADMIN
192.168.55.6 DCICHIDEV2 #PRE #DOM:DCIADMIN
192.168.55.200 DCIADDC4 #PRE #DOM:DCIADTEST
206.208.197.65 ALBANY_GA #PRE #DOM:ALBANY_GA_D
206.208.197.65 "ALBANY_GA_D \0X1B" #PRE
206.208.197.66 ALBANY_BO #PRE #DOM:ALBANY_GA_D
192.168.25.65 ALBUQUER_NM #PRE #DOM:ALBUQUER_NM_D
192.168.25.65 "ALBUQUER_NM_D \0X1B" #PRE
206.208.196.161 ATLANTA_GA #PRE #DOM:ATLANTA_GA_D
206.208.196.161 "ATLANTA_GA_D \0X1B" #PRE
206.208.196.162 ATLANTA_BO #PRE #DOM:ATLANTA_GA_D
192.168.13.97 BILLINGS_MT #PRE #DOM:BILLINGS_MT_D
192.168.13.97 "BILLINGS_MT_D \0X1B" #PRE
192.168.12.34 BIRMINGH_BO #PRE #DOM:BRIMINGH_AL_D
192.168.12.34 "BIRMINGH_AL_D \0X1B" #PRE
206.208.192.9 BOSTON_MA #PRE #DOM:BOSTON_MA_D
206.208.192.9 "BOSTON_MA_D \0X1B" #PRE
192.168.4.161 CARSON_NV #PRE #DOM:CARSON_NV_D
192.168.4.162 CARSON_BO #PRE #DOM:CARSON_NV_D
192.168.4.162 "CARSON_NV_D \0X1B" #PRE