I have a new Windows Server 2003 machine I'm trying to configure as a DNS server and Domain Controller. Show
Whenever I add an XP client to the domain I get the following event log error on boot up: "Windows cannot determine the user or computer name. (The RPC server is unavailible). Group Policy processing aborted." This seems to be because it can't resolve the fully qualified domain name of the domain controller. I can ping the domain controller. Then I try to ping it's fully qualified domain name and it fails. Then I try to ping the fully qualified domain name with a . at the end and it succeeds. Now all attempts to ping it's fully qualified domain name succeed (until I reboot). (see below) I can work around this by adding a host file entry mapping the IP to the fully qualified domain name but I'd like to avoid that hack if I can. Any thoughts? Thanks. What follows is the attempt to resolve the domain controller from a XP machine on the domain (where dc-server is the domain controller): C:\>nslookup dc-server Server: dc-server.localdomain.org Address: 192.168.42.2 Name: dc-server.localdomain.org Address: 192.168.42.2 C:\>nslookup dc-server.localdomain.org Server: dc-server.localdomain.org Address: 192.168.42.2 Name: dc-server.localdomain.org Address: 192.168.42.2 C:\>ping dc-server Pinging dc-server [192.168.42.2] with 32 bytes of data: Reply from 192.168.42.2: bytes=32 time=1ms TTL=128 C:\>ping dc-server.localdomain.org Ping request could not find host dc-server.localdomain.org. Please check the name and try again. C:\>ping dc-server.localdomain.org. Pinging dc-server.localdomain.org [192.168.42.2] with 32 bytes of data: Reply from 192.168.42.2: bytes=32 time=1ms TTL=128 C:\>ping dc-server.localdomain.org Pinging dc-server.localdomain.org [192.168.42.2] with 32 bytes of data: Reply from 192.168.42.2: bytes=32 time=1ms TTL=128ipconfig /all on the client follows: C:\>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : LMCA8-E03 Primary Dns Suffix . . . . . . . : LOCALDOMAIN.ORG Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : LOCALDOMAIN.ORG Ethernet adapter Wireless Network Connection: Media State . . . . . . . . . . . : Media disconnected Description . . . . . . . . . . . : Dell Wireless 1397 WLAN Mini-Card Physical Address. . . . . . . . . : 00-22-5F-61-F5-08 Ethernet adapter Local Area Connection 2: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Intel(R) 82567LM Gigabit Network Con nection Physical Address. . . . . . . . . : 00-21-70-DE-43-69 Dhcp Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 192.168.42.13 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.42.1 DNS Servers . . . . . . . . . . . : 192.168.42.2
A fully qualified domain name (FQDN) is the complete domain name for a specific computer, or host, on the internet. The FQDN consists of two parts: the hostname and the domain name. For example, an FQDN for a hypothetical mail server might be mymail.somecollege.edu. The hostname is mymail, and the host is located within the domain somecollege.edu. In this example, .edu is the top-level domain (TLD). This is similar to the root directory on a typical workstation, where all other directories (or folders) originate. (Within the .edu TLD, Indiana University Bloomington has been assigned the indiana.edu domain, and has authority to create subdomains within it.) The same applies to web addresses. For example, www.indiana.edu is the FQDN on the web for IU. In this case, www is the name of the host in the indiana.edu domain. When connecting to a host (using an SSH client, for example), you must specify the FQDN. The DNS server then resolves the hostname to its IP address by looking at its DNS table. The host is contacted and you receive a login prompt. If you are using only the hostname (without the domain information) to connect to a server, the application you're using may not be able to resolve the hostname. This can happen if either the DNS suffix search order in your computer's TCP/IP properties is incorrect, or the DNS table is corrupted. In these cases, entering the host's FQDN will allow DNS to locate the server. Also, if you are trying to connect to a remote host that is not local to your internet service provider (ISP), you will probably have to use the FQDN. For example, it's unlikely that a DNS server at IU would have a listing for remote hosts at another university or an unrelated ISP.
This article provides a solution to name resolution and connectivity issues on a Routing and Remote Access Server that also runs DNS or WINS. Applies to: Windows Server 2012 R2, Windows Server 2016 SymptomsA computer that is running Microsoft Windows 2000 Server or Microsoft Windows Server 2003 may exhibit connectivity issues if the server is configured in the following manner:
After a remote computer connects to the Routing and Remote Access server by using a dial-up or a Virtual Private Networking (VPN) connection, one or more of the following symptoms may occur intermittently:
This issue typically affects computers that are running Small Business Server because this version of Windows Server is frequently the only server on the network. However, the issue can affect any Windows 2000-based server or any Windows Server 2003-based Routing and Remote Access server that is running the DNS or the WINS service. CauseWhen a remote computer connects to the Routing and Remote Access server by using a dial-up or a VPN connection, the server creates a Point-to-Point Protocol (PPP) adapter to communicate with the remote computer. The server may then register the IP address of this PPP adapter in the DNS or the WINS database. When the Routing and Remote Access server registers the IP address of its PPP adapter in DNS or WINS, you may receive errors on the local computers when you try to connect to the server. You receive these errors because the DNS or WINS servers may return the IP address of the PPP adapter to computers that query DNS or WINS for the server's IP address. The computers then try to connect to the IP address of the PPP adapter. Because the local computers can't reach the PPP adapter, the connections fail. Resolution
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information, see How to back up and restore the registry in Windows To resolve this issue, configure the Routing and Remote Access server to prevent it from registering the IP address of its PPP adapter in the DNS or the WINS database. To do it, follow these steps: Configure the Routing and Remote Access server to publish only the IP address of the local network adapter in DNSComplete the steps in this section only if the Routing and Remote Access server is running the DNS service. If the server isn't running the DNS service, go to the Configure the Routing and Remote Access server to register only the IP address of the local network adapter in WINS section. Add the PublishAddresses and RegisterDnsARecords registry values for the DNS and Netlogon services
Add the A Records in DNSComplete these steps only if the Routing and Remote Access server is a domain controller.
Configure the Routing and Remote Access Server to register only the IP address of the local network adapter in WINSComplete the steps in this section only if the Routing and Remote Access server is running the WINS service. Additionally, if the server is running Small Business Server 2000 SP1, Small Business Server 2000 SP1a, or Windows Small Business Server 2003, you don't have to complete the steps in this section. By default, these versions of the Windows server are configured to prevent the server from registering the PPP adapter's IP address in the WINS database. The DisableNetbiosOverTcpip registry value disables the NetBIOS over TCP/IP (NetBT) protocol for remote access connections. So the server won't register the PPP adaptor in the WINS database. Know that by adding this value, you'll prevent remote access clients from browsing the local network through My Network Places or Network Neighborhood. Sometimes, it may also cause remote access connections to be unsuccessful on computers that are running older versions of Windows. For example, remote access connections may be unsuccessful on Microsoft Windows 98 computers and on Microsoft Windows NT 4.0 Workstation computers. For an alternative to using the DisableNetbiosOverTcpip registry, see the Workaround section.
Important If the server is running Windows 2000 Server SP2 or an earlier version, you must update the server with SP3 or SP4 for the DisableNetbiosOverTcpip registry value to work. If you don't update the server, the Routing and Remote Access service won't use this registry value, and the issue won't be resolved.
The WINS server will rebuild the database automatically as computers on the network register their NetBIOS names. You can force Windows-based computers on the network to register their NetBIOS names immediately by running the nbtstat -RR command. WorkaroundAs a workaround for this issue, you can configure the remote access connections to use a static pool of IP addresses that is on a different IP subnet than the local computers. In this case, local computers won't try to connect to the PPP adapter if it registers in DNS or WINS because the PPP adapter is on a different IP subnet. To specify a static address pool in the Routing and Remote Access console, right-click ServerName, select Properties, select the IP tab, select Static address pool, and then select Add. Add a range that doesn't use the same IP subnet as the local computers. For example, if the local computers are using the 10.0.0.0 subnet, add a static pool that uses the 172.168.0.0 subnet. If the Routing and Remote Access server is running ISA Server 2000, you must add this subnet to the Local Address Table. This scenario is most common on Small Business Server 2000. |