Windows 2000 Interoperability

Windows 2000 Professional

This is the next generation of Windows NT Workstation. It is most likely be deployed in place of existing instances of Windows 95, Windows 98, and Windows NT Workstation. Workstations running this operating system are most likely be clients to all major network services, although they could be configured to allow the sharing of files between individuals or groups of users. In a TCP/IP network environment, most computers running this operating system are probably configured as DHCP clients and will function like existing Windows 95, 98, or NT Workstation systems. Windows 2000 Professional has only a mild impact on existing intranetworked environments.

Windows 2000 Server, Advanced Server, and Data Center

These represent the next generation server platforms from Microsoft. Windows 2000 Server can be considered the direct linear descendant of Windows NT 4.0 Server. Windows 2000 Advanced Server can be considered the next generation of Windows NT 4.0 Enterprise Server. Windows 2000 Data Center is a new offering from Microsoft that provides the advanced functionality of Enterprise Server, along with support for eight or more processors.

Windows 2000 offers a number of new features and design paradigms, which significantly change the level of importance of TCP/IP networking. The DNS and DHCP standards, and directory technology (LDAP) are all critical in Windows 2000. The impact of these paradigm changes will be felt across the entire IP network infrastructure. Additionally, with the new Data Center offering, Microsoft has an operating system that can compete with high end UNIX workstations for service provider data center and network operation center (NOC) applications. The impact of these server operating systems to existing intranetworked environments will be high.

Windows 2000 domain controllers and Active Directory

Windows 2000 deployment requires the existence of Windows 2000 domain controllers. These are similar to Windows NT 4.0 domain controllers, with two notable exceptions:

• The distinction between primary domain controllers (PDCs) and backup domain controllers (BDCs) is now gone. Multiple domain controllers are replicated through the embedded directory technology in Windows 2000. This means that all Windows 2000 domain controllers are of equal rank.
  
  

• The embedded directory technology known as Active Directory. Active Directory is an integral part of the Windows 2000 operating system. It is, on the surface, a directory similar in function to NetWare Directory Services (NDS) or any LDAP directory. However, Active Directory is embedded in Windows 2000, and unlike its competitors in the directory market space, is packaged with Windows 2000.
  
  

Windows 2000 domain controllers and Active Directory (continued)

Hence, Active Directory, in all likelihood, will become the directory of choice for many enterprises. Also of note, Active Directory will be the first hands-on experience many enterprises have with directory technology. Any further progression toward deploying the Directory-Enabled Networks (DEN) or CIM specifications will be dramatically impacted by the embedded directory in Windows 2000.

Windows 2000 DNS and Active Directory

Windows 2000, like Windows NT 4.0 Server before it, is shipped with a DNS server you can install and configure. The DNS server in Windows 2000 is a superset of the functionality of the Windows NT 4.0 DNS server. The major new feature of the Windows 2000 DNS server is that you can configure it to use Active Directory to store DNS information. Once configured to store information about zones in Active Directory, directory replication is used in lieu of DNS zone transfers to share information between multiple DNS servers.

This provides DNS with Microsoft-proprietary functionality known as multimaster DNS. In multimaster DNS, the traditional hierarchy of master primary and slave secondary DNS servers is abandoned. Multimaster DNS allows any DNS server to accept edits to the data in a given zone. While this sounds like an appealing feature, this produces a concurrency problem. If two updates for the same data are received simultaneously, on two separate multimaster DNS servers, there will be a DNS name conflict. Rather than blocking the update on the way in, multimaster DNS uses a last update wins model of directory replication to synchronize multiple versions of a zone's data. In this model, the first update will be deleted by the second update. It is anticipated that Windows 2000 DNS with multimaster replication through Active Directory will have a serious impact in networks where this technology is deployed.

Windows 2000 and other DNS servers

Microsoft states, and Cisco has verified in testing, that Windows 2000 does not require or necessitate the Microsoft DNS server deployment. You can deploy Windows 2000 in an existing DNS infrastructure as long as the DNS server supports certain features of the DNS protocol. The core requirements for a DNS server to interoperate with Windows 2000 domains are:

• Support of dynamic DNS updates
  
  
• Support of SRV resource record types
  
  

Versions of BIND prior to 8.2 do not support these features. Hence, Windows 2000 deployments stand to have an extreme impact on some sites, because support of Windows 2000 necessitates mass upgrades of DNS servers to modern RFC-compliant versions of BIND, or to a commercially supported DNS solution, such as Network Registrar.

Existing Network Registrar users need to upgrade their Network Registrar installations to the required patch levels, as indicated in the "Version Compatibility" section.

SRV records

Windows 2000 domain controllers use the SRV DNS resource record type to advertise their services to the network. This DNS resource record type is defined in the experimental RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)." The RFC defines the format of the SRV record (DNS type code 33) as:

Service.Proto.Name TTL Class SRV Priority Weight Port Target
 

There should always be an A record associated with the SRV record's target, so that the client can resolve the service back to a host. In the Microsoft Windows 2000 implementation of SRV records, the records might look like this:

myserver.example.com A 10.100.200.11
_ldap._tcp.example.com SRV 0  0  389  myserver.example.com
_kdc._tcp.example.com SRV 0  0  88  myserver.example.com
_ldap._tcp.dc_msdcs.example.com SRV 0  0  88  myserver.example.com
 

These SRV records are automatically placed in DNS by the Windows 2000 domain controllers.

How SRV records are used

When a Windows 2000 client boots on the network, it tries to initiate the network login process, to authenticate against its Windows 2000 domain controller. The client must first discover where the domain controller is. The clients use the dynamically generated SRV records to locate their domain controllers.

Prior to launching the net-login process, the client queries DNS with a service name, such as _ldap._tcp.dc_msdcs.example.com. The DNS server then returns the target portion of the SRV record, for example, my-domain-controller.example.com. The Windows 2000 client then queries DNS with the host name my-domain-controller.example.com. DNS then returns the IP address of this host, and the client uses this IP address to find the domain controller. Without the existence of these SRV records, the net-login process will fail.

Dynamic DNS updates

When a Windows 2000 server is configured to be a domain controller, the name of the domain it is managing is statically configured through the Active Directory management console. This Windows 2000 domain should have a corresponding DNS zone associated with it. The Windows 2000 domain controller should also have a series of DNS resolvers configured in its TCP/IP properties control panel.

When the Windows 2000 domain controller boots on the network, it performs the following steps to register itself in DNS and advertise its services to the network:

Server boot process Network Registrar log file examples

The Network Registrar primary DNS server writes the following log entries under normal operating parameters, when a Windows 2000 domain controller boots on the network and creates its SRV records:

08/10/2000 16:25:09 name/dns/1 Activity Protocol 0 Added type 33 record 
to name "_ldap._tcp.w2k.example.com", zone "w2k.example.com"
 
08/10/2000 16:25:09 name/dns/1 Activity Protocol 0 Update of zone 
"w2k.example.com" from address [10.100.200.2] succeeded.

This log shows only one dynamic DNS update for a single SRV record. A Windows 2000 domain controller will typically register 17 of these SRV records when it boots up on the network.

Invisible dynamically created resource records

Network Registrar, when properly configured, accepts dynamic DNS updates from both DHCP servers and Windows 2000 servers. However, users may mistakenly believe that the dynamic DNS updates are not being created because they are not visible in the Network Registrar graphical user interface (GUI). This is not a product defect. Dynamic data is not displayed in the Network Registrar GUI. This is because the Network Registrar system administrator should not, under normal operation, edit or delete resource records that were created dynamically. Only display static resource records displays in the GUI. However, the command-line interface allows the system administrator access to the dynamic portion of the DNS zone for viewing and deleting resource records.

Enter this command to view all dynamic DNS resource records in a given zone:

nrcmd> zone myzone listRR dynamic myfile 
 

This command pipes the output of the listRR command to the file myfile. The output of this command is shown in Example E-1 at the end of this appendix.

You can delete dynamically generated resource records by entering this command:

nrcmd> zone myzone removeDynRR myname 

Additionally, you can use the publicly available nslookup tool to verify the existence of dynamically generated resource records. The most commonly available version of the nslookup tool is version 4.0 from Microsoft. You cannot use this version to look up SRV records. However you can use nslookup version 5.x (shipped with Windows 2000) to view dynamic SRV records. In this version, use the set type=SRV command to enable viewing SRV records.

DNS resolver list for domain controllers

A Windows 2000 domain controller has to register itself in DNS using dynamic DNS updates. The DNS RFCs dictate that only a primary DNS server for a particular zone can accept edits to the zone data. Hence, the Windows 2000 domain controller has to discover which DNS server is used primary for the zone corresponding to its Windows 2000 domain name.
(continued)

(Resolver list, continued)

The Windows 2000 domain controller discovers this by querying the first DNS server in its resolver list (configured in the TCP/IP properties control panel). The initial query is for the SOA record for the zone corresponding to the domain controller's Windows 2000 domain. The SOA record contains the name of the primary DNS server for the zone. Once the Windows 2000 domain controller has the name of the primary DNS server for its domain, it then begins sending dynamic DNS updates to this server to create the necessary SRV records.

System administrators should ensure that the name of the primary DNS server for a zone is in the SOA record for that zone.

Failure of A record DDNS updates

When a Windows 2000 domain controller attempts to advertise itself to the network, it sends several dynamic DNS updates to the DNS server of record for its domain. Most of these update requests are for SRV records. However, the domain controller also requests an update for a single A record of the same name as the domain.

For example, the Windows 2000 domain controller may control the domain w2k.example.com. In this case, the DNS server must have a zone file called w2K.example.com. When booting up, the Windows 2000 domain controller sends several SRV records, then a request for a single dynamic A record update.

The Network Registrar DNS server then refuses this update. The data for w2k.example.com already exists and is static data. By rule, the Network Registrar DNS server does not allow a dynamic update to edit static data. If a name was created statically with any type of resource record, no dynamic update for that name is accepted, even for a different resource record type. This is to prevent possible security infractions, such as a dynamic host registering itself as www.example.com and spoofing Web traffic to a site. When the Windows 2000 domain controller boots, a DNS log file entry such as the following appears:

08/10/2000 16:35:33 name/dns/1 Info Protocol 0 Error - REFUSED - 
Update of static name "w2k.example.com", from address 
[10.100.200.2]
 

This is how Network Registrar responds to dynamic updates of static DNS data. Additionally, this dynamic DNS update failure can be ignored. Windows clients do not use this A record. Allocation of domain controllers is done through the SRV records. The A record was added by Microsoft to serve as a hook for non-Microsoft users of the domain controller.

Windows 2000 RC1 DHCP client

Microsoft released Windows 2000 build 2072 (known as RC1) with a broken DHCP client. This client sends a misformed packet that Network Registrar cannot parse. The packet is dropped and a DHCP client running Windows 2000 RC1 cannot be served a DHCP address by Network Registrar. Microsoft delivered a patch to early deployment customers shortly after RC1 was released. However, there may be a significant number of Windows 2000 installations that do not have this patch installed.
(continued)

(RC1 client, continued)

If a Windows 2000 system with the Release Candidate 1 DHCP client attempts to get a DHCP lease from a Network Registrar DHCP server, it will be unsuccessful. The Network Registrar DHCP server logs the following error:

08/10/2000 14:56:23 name/dhcp/1 Activity Protocol 0 10.0.0.15 
Lease offered to Host:'My-Computer' CID: 01:00:a0:24:1a:b0:d8 
packet'R15' until True, 10 Aug 2000 14:58:23 -0400. 301 ms.
 
08/10/2000 14:56:23 name/dhcp/1 Warning Protocol 0 Unable to find 
necessary Client information in packet from MAC 
address:'1,6,00:a0:24:1a:b0:d8'. Packet dropped!
 

Network Registrar includes error checking specifically designed to deal with errors in the DHCP client, such as this improperly built FQDN option. However, if you encounter this problem, install the Microsoft patch to the RC1 client on the DHCP client. You must obtain this patch from Microsoft.

Windows 2000 plug-and-play network interface card (NIC) configuration

If configured to use DHCP, a Windows 2000 system attempts to obtain a DHCP lease on startup. If no DHCP server is available, Windows 2000 may automatically configure the computers interface with a plug-and-play IP address. This address is not an address configured by or selected by the network administrator or by the DHCP server.

These plug and play addresses are in the range 169.254.0.0/16. If devices in this address range are seen on a network, it means that Windows 2000 auto-configured the interfaces because it was unable to obtain a lease from a DHCP server.

This can cause significant network and troubleshooting problems. The Windows 2000 system will no longer inform the user that the DHCP client was unable to obtain a lease. Everything will appear to function normally, but the client will not be able to route packets off its local subnet. Additionally, a Network Registrar administrator may see the DHCP client attempting to operate on the network with an address from the 169.254.0.0/16 network. The administrator might be led to think that the Network Registrar DHCP server is broken and is handing out the wrong range of IP addresses.
(continued)

If this problem occurs, perform these steps:

(Plug-and-play configuration, continued)

If the network is correctly configured, and if the DHCP client is not broken, Network Registrar should receive the packet and log it. If there is no log entry for a packet receipt, then there is a problem somewhere else in the network.

DNS server freeze

Under certain circumstances, Windows 2000 environments can cause the Network Registrar DNS server to use 100 percent of the server's CPU for short periods. This is due to a bug in early versions of the Network Registrar software, which is encountered when the DNS server attempts to build a query-response containing large numbers of identical SRV records. This bug was fixed in releases 3.0P4 and 3.0(0.3)T. This problem causes periodic DNS server freezing.