Managing TCP/IP with Windows NT 4.0
John Tiso
Under Windows NT 4.0, Microsoft provides the system administrator with a complete set of utilities for managing the TCP/IP name and address space: Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and Windows Internet Name Service (WINS). The greatest strength of these tools is the ability to be integrated and provide automation and ease of administration. As a former sys admin, automation and ease are magic words to me, and one misconception that I tend to face is lack of interoperability with non-Microsoft products and lack of support. However, the tools provided with NT 4.0, if configured correctly, will interoperate with non-Microsoft products. They are also fully supported by Microsoft (previous versions of Windows NT could be configured with a BIND-based DNS server through the Windows NT resource kit that was not supported by Microsoft.) In this article, I discuss the configuration of these services, as well as their integration.
Windows NT Installation Issues A common pitfall that I see with Windows NT is improper installation. Two frequently overlooked areas in normal Windows NT installation are service packs and the Microsoft Hardware Compatibility List (HCL). A "service pack" is the Microsoft term for a group of operating system patches. When installing NT, the latest NT server service pack should be applied. Service packs must be reapplied whenever system settings are changed that result in any files being loaded from the original Windows NT distribution, such as adding DNS, WINS, or DHCP after initial installation. Windows NT service packs can be obtained from a variety of sources, such as WWW, Microsoft Technet, and directly from Microsoft on CD for a minimal fee.
The Microsoft HCL contains a list of systems and components that are tested by Microsoft and are certified to function under Windows NT. Any system or third party adapter cards running Windows NT should be listed in the Microsoft HCL. For example, there are many NE2000 compatible Ethernet controller cards that may be compatible with other software, however, they do not function with Windows NT. The Microsoft HCL comes in hard copy with the Windows NT CD-ROM or can be obtained from the Microsoft World Wide Web site.
(http://www.microsoft.com/isapi/hwtest/hcl.idc )
For more information on service packs and the HCL, see the recommended reference at the end of this article. Another point to note is that some OEM manufacturers such as Compaq and DEC provide OEM installation procedures of Windows NT (such as SmartStart and ServerWorks). Prior to installing Windows NT using one of these methods, you should check with your OEM for information relating to any special instructions for installing service packs or other drivers using an OEM installation. Microsoft, on occasion, provides additional patches outside the service pack called hot fixes. Currently a hot fix is recommended on top of service pack 3 for DNS. I recommend its use and have used it to resolve DNS-related lookup problems.
WINS WINS, the Windows Internet Name Service, is a proprietary host resolution method developed by Microsoft for Windows NT networks that resolves TCP/IP addresses to NETBIOS node names. Although NETBIOS node names are separate from TCP/IP host names, generally, most clients will use the same name for NETBIOS and TCP/IP names. WINS is dynamic, thus overcoming one of the major shortcomings of DNS. WINS allows clients to dynamically register their host names with the WINS server. Configuring a WINS server involves the following steps:
- Install and configure TCP/IP.
- Establish connectivity and proper configuration through PING and IPCONFIG /ALL (similar to UNIX ifconfig -a).
- Install the WINS service into Windows NT. The initial installation of WINS is similar to DNS (see Figure 1), using the same area of the control panel.
- Multiple WINS servers can be configured for redundancy as "push" and "pull" partners. This optional step provides WINS servers with the ability to replicate data to each other. Unlike DNS, WINS has no concept of primary and secondary servers. "Push" as well as "pull" partners can be mutually exclusive.
DNS In Windows NT 4.0, Microsoft has provided an implementation of DNS based on BIND. This version of DNS, unlike previous versions, is fully tested and supported by Microsoft. The steps to configuring DNS are similar in concept to the UNIX/BIND environment:
- Install and configure TCP/IP.
- Establish connectivity and proper configuration through PING and IPCONFIG /ALL (similar to UNIX ifconfig -a).
- Install the DNS service into Windows NT. Figure 1 shows how DNS is installed through the services option in the network control panel.
- Configure DNS either through the DNS Manager GUI or by placing BIND style files into the directory %systemroot%\system32\dns. Ater the initial configuration, DNS stores the data from the DNS boot file in the Windows NT registry. To reload the registry from a text boot file, edit the registry value KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\
Parameters and delete the value EnableRegistryBoot. Place the text boot file into the DNS directory and either stop and start the DNS service in control panel or reboot the system.
- Create your DNS zone(s) and enter your DNS records. Either use the DNS manager or hand edit the zone file. Figure 2 shows the creation of a zone file via the DNS manager GUI. When creating a new zone (primary server), the GUI will default the zone file name to the name of the zone and add the file extension of .dns. The GUI will also add the SOA and first NS records to the zone.
- For more information on configuring DNS, see the suggested reading list at the end of this article.
One of the areas in which Windows NT differs from BIND is the ability to do reverse lookups into the Microsoft WINS service. Adding a "WINS" record to a particular DNS zone enables this ability. This WINS record maps the IP address to one or more WINS servers that DNS will use to resolve any unknown host names. The results, if successful, will be added to the DNS zone. Figure 3 shows how to configure DNS to perform reverse lookups into WINS. When using Windows NT as a primary DNS server and BIND as a secondary server, the WINS record must be kept local, or it will cause the zone transfer to the BIND secondary server to fail. Clicking on the "settings only affect local server" box will keep DNS from exporting the WINS record in a zone transfer to a secondary server.
Two areas here are important to note. The first is that WINS records would absolutely cause zone transfers to fail using a non-Microsoft DNS server as a secondary DNS server. I mostly see this as an issue when using an ISP (Internet Service Provider) as a secondary DNS server. This is common in many installations, since the INTERNIC requires two DNS servers for registration. The second area to note is that the "WINS" record will need to be configured for reverse lookup zones also, so lookups by TCP/IP addresses will be able to utilize this feature. Each zone, including the reverse lookup zones will need to be configured.
DHCP DHCP is an extension of the original BOOTP protocol. BOOTP was designed to provide for the assignment of TCP/IP addresses to diskless devices. DHCP extends this functionality by allowing the automatic assignment of a TCP/IP address, as well as other parameters. Therefore, it can also reduce administrative overhead of client configuration parameters. These client parameters can be specified in a global or scope (subnet). Some of the more notable parameters are WINS server(s), DNS server(s), default router, NETBIOS node type for name resolution, and subnetwork mask. Other parameters such as NTP and NIS servers can be specified to service non-Microsoft hosts. The steps to installing DHCP are:
- Install and configure TCP/IP.
- Establish connectivity and proper configuration through PING and IPCONFIG /ALL (similar to UNIX ifconfig -a).
- Install the DHCP service into Windows NT. DHCP is installed through the services option in the network control panel.
- Configure a scope of addresses. This scope is a block of contiguous IP addresses, on the same IP subnet. IP addresses that are used for hosts that do not support DHCP, can be "excluded" here. Figure 4 shows the configuration of a scope that spans an entire network. "Reservations" for hosts that need static addresses can be added after creation of the scope through the add reservations panel. An example of a host needing a reservation would be a network-based printer. These reservations are made on the basis of MAC address.
- Configure any "scope" specific data such as subnetwork mask. Figure 5 shows the configuration of scope-specific parameters. In this graphic, we would click the "value>>" button to add the TCP/IP address of our router.
- Configure any global information, such as DNS or WINS servers on the Internetwork. Global parameters should be used when a DHCP server services multiple scopes that will share common data, such as DNS servers.
- Configure clients to use the DHCP protocol for configuration. Leave all areas blank that are to be configured via DHCP. Figure 6 shows a simple DHCP client configuration. I recommend setting as many parameters in the server as possible, since the goal is to reduce the number of parameters that must be manually configured on each client station.
One of the shortcomings of DHCP is that it provides no redundancy by default. However, you can add redundancy to the Internetwork by having multiple DHCP servers and a DHCP scope for each half of a subnet on different servers. This provides an element of redundancy, and the servers naturally "load balance" with the fastest server responding to DHCP requests. DHCP servers can also be placed across TCP/IP subnets provided that the routers that connect the subnets will act as DHCP forwarding agents. In practice, I try to avoid this, because most routed connections can do without the extra traffic.
Putting It All Together In the DNS section, I discussed putting WINS records into DNS. In the DHCP section, I discussed using DNS and WINS records. To fully integrate these tools, there are a few more steps needed. In DNS, WINS records must be used for all DNS zones, including the reverse lookup zones. In the DHCP configuration, the DNS server(s), WINS server(s) and DNS domain names must be specified. You must also be careful to configure your clients correctly. Looking back at Figure 6, note that the first page of the TCP/IP properties has only the "Obtain an IP address from a DHCP server" option. The only other option that should be selected on a client is on the next page: DNS. The hostname should be entered so that it matches the computer name (i.e., the NETBIOS name). No other option should be filled in. We want all other options to be supplied by the DHCP server. Configuring a client this way will cause assignment of all other values via DHCP on bootup. The client will then register its NETBIOS name with the WINS server. Since we configured our DNS server to lookup from our WINS server, using the client NETBIOS name as a TCP/IP hostname, this will provide automated addressing and dynamic resolution.
As you can see from the discussion of the configuration and integration of DHCP, DNS, and WINS and some of the common misconceptions discussed above, these services can be used to dynamically configure TCP/IP name and address space. Although future releases of Windows NT may eliminate the WINS service, the concept of Name and Address integration discussed here will remain a viable solution in the remaining and enhanced tools.
Recommended References Albitz, Paul and Cricket Liu. 1996. DNS and BIND, Second Edition. O'Reilly and Associates.
Heywood, Drew. 1997. Networking with Microsoft TCP/IP, Second Edition. New Riders Publishing.
The Microsoft Windows NT Hardware Compatibility List: http://www.microsoft.com/isapi/hwtest/hcl.idc
The Microsoft Windows NT Service Pack home page: http://support.microsoft.com/support/ntserver/ \ content/ServicePacks/Default.asp
The Microsoft Windows NT 4.0 Resource Kit. Microsoft Press.
About the Author
John Tiso is a Senior Integration Engineer for Boston-based Bay State Computer Group. John holds a BS degree in Mathematics and Computer Science from Adelphi University, Garden City, NY. In addition, John holds the following industry certifications: Microsoft Certified Systems Engineer, Microsoft Certified Trainer, Novell Master CNE, Compaq ASE, Sun Microsystems Enterprise Computing Certified Systems Engineer, IBM AIX Certified Systems Administrator, and HP 9000 Certified on Workstations and Servers. John can be reached at johnt@bscg.com.
|