In a Microsoft Windows NT 4.0 domain that includes Windows
Server or Windows XP-based member
computers, when you upgrade the Primary Domain Controller (PDC) to Windows
Server, you may experience the
following symptoms:
- The Windows
Server or Windows XP-based member
computers may continue to use a Windows NT 4.0 Backup Domain Controller (BDC)
for authentication.
- In Windows
Server, specific
attributes on the computer account (dNSHostName and servicePrincipalName) may
be missing.
- When you log on to the workstations, "Directory" may be
missing under "Entire Network" in "My Network Places".
- In network traces from affected domain members, you may see
Kerberos errors on logon. This is because many computer accounts do not have
the servicePrincipalName attribute that is required to issue Kerberos tickets.
- Windows
Server members only apply downlevel
machine policies and not machine policies that are defined on sites, domains
and organizational units in Active Directory.
- The domain that the computer is joined to lists the NetBIOS name
of the domain instead of the fully qualified domain name (FQDN) when Windows
Server members have established encrypted channels to Windows
Server domain controllers in a mixed-mode, mixed-version domain.
This behavior may occur because Windows
Server or Windows XP-based member
computers that are joined to a Windows NT 4.0 domain that is later upgraded to
Windows Server Active Directory do not actively
discover or establish encrypted channels with Windows
Server domain controllers. Because of
this, Active Directory features such as Kerberos authentication, Active
Directory policies, and site-based domain controller discovery are not enabled.
The only certain way for a Windows
Server or Windows XP-based member
computer to learn that its domain contains Windows
Server domain controllers is for the
member computer to query the primary domain controller for the version of its
operating system. In a large domain, this operation could overload the PDC with session and authentication requests. To avoid this
overload scenario, Windows
Server-based or Windows XP-based member
computers continue to establish encrypted channels with existing downlevel domain
controllers until Windows
Server domain controllers are
"discovered".
In a network trace you can see that the client sends
logon requests to all domain controllers that are returned in the WINS 1C response and also
tries other means (such as broadcasts) to locate domain controllers. Both Windows NT 4.0 and
Windows
Server domain controllers may respond to the logon
request, but in the end the client will establish an encrypted channel and
authenticate with the domain controller that first responds. The user logon
authentication may later occur by using Kerberos with a Windows
Server domain controller.
In Windows 2000 Service Pack 2, support was added for
Nt4emulator. Nt4emulator makes uplevel domain controllers in a Windows NT 4.0
domain behave as Windows NT 4.0 domain controllers. This prevents uplevel
clients from detecting and possibly overloading the uplevel domain controllers.
There are settings that can accelerate or delay the
discovery of Windows
Server domain controllers by domain
members with downlevel encrypted channels.
- For WINS, read the following Microsoft Knowledge Base
article:
269424Â
(http://kbalertz.com/Feedback.aspx?kbNumber=269424/EN-US/
)
WINS Prepend1BTo1CQueries Feature Aids Load-Balancing
- Stack the WINS 1C list on WINS servers with static
registrations for Windows
Server or Windows NT 4.0 domain
controllers to be used for logon authentication.
- The NETBIOS node type, this is configurable through
DHCP options on DHCP servers or the Windows registry that defines the order and
type of name resolution clients that are used to discover domain
controllers.
You can also use an LMHOSTS file to have better control of
which domain controllers the member will find.
For
additional information about this, click the article number below to view the
article in the Microsoft Knowledge Base:
180094Â
(http://kbalertz.com/Feedback.aspx?kbNumber=180094/EN-US/
)
How to Write an LMHOSTS File for Domain Validation
Windows
Server and Windows XP members will create a
encrypted channel with Windows
Server domain controllers when the following conditions are true:
- A Windows
Server domain controller responds first
to the logon requests when the member boots up.
- The encrypted channel is manually reset to a Windows
Server domain controller by using the netdom
reset or nltest /sc_reset
command.
- Create a new computer account and rejoin the domain member
to the domain.
At this point the member will learn the DNS name of the domain
and store it in an LSA secret. The next time the member computer is rebooted,
all components in the system will learn about the DNS domain name.
At
this time, the dnsHostName and servicePrincipalName properties will be updated
on the computer object in Active Directory, and the FQDN will appear
in My Computer, under Properties.