- Introduction
- Introduction to DNS
- Planning a DNS Namespace Design
- Planning DNS Zone Requirements
- Planning DNS Forwarding Requirements
- Configuring DNS Security
- Integrating with Third-Party DNS Solutions
- Introduction to WINS
- Implementing WINS Replication
- Implementing NetBIOS Name Resolution
- Troubleshooting Name Resolution Problems
- Chapter Summary
- Apply Your Knowledge
This chapter is from the book
This chapter is from the book
This chapter is from the book
Introduction to WINS
If you are at all familiar with Windows NT 4.0 networks, you are undoubtedly familiar with the intricacies of a WINS infrastructure. You may also be wondering why Microsoft didn't get rid of WINS in Windows Server 2003. Well, the good news is that with Windows Server 2003, WINS is used for backward compatibility only. Windows Server 2003 Active Directory networks do not need WINS at all.
So that means we don't need to talk about WINS, right? Sorry, but you don't get off that easily. Until your network is 100% Windows 2000 or later, you still need WINS to provide backward compatibility for legacy Windows operating systems, particularly with your NT domains. With that in mind, let's talk about what WINS is and how it works.
In the Internet-centric environment that most companies are designing and maintaining, Transmission Control Protocol/Internet Protocol (TCP/IP) has become the ubiquitous networking protocol. For old-time Unix users, using TCP/IP is a good thing. TCP/IP came out of the Unix arena and has been the native protocol for Unix systems since the late 1980s.
Microsoft, on the other hand, started with a different protocol as its LAN Manager operating system's native protocol—NetBIOS Extended User Interface (NetBEUI). NetBEUI was a pretty good protocol for small networks; it required no configuration and didn't require complex addressing like TCP/IP does. However, NetBEUI cannot handle routing and does not perform well in large environments. Microsoft needed to add TCP/IP support.
When Microsoft began to add TCP/IP support to its LAN server products, the company ran into a little problem. The naming system used on Microsoft networks at that time would not function on routed TCP/IP networks. Microsoft LAN Manager computers used the computer's NetBIOS names for identification. Although this makes maintaining the network very simple for an administrator—because servers are automatically advertised on the network by name—this naming system was a problem with TCP/IP.
NetBIOS has a design limitation that shows up in routed networks because NetBIOS relies heavily on broadcast messages to advertise servers and their shared resources. Broadcast messages are messages that are received by every computer on a network segment, rather than by a specific computer. This paradigm is useable on smaller networks but can add overwhelming amounts of broadcast traffic on an enterprise network. If you have ever suffered from a broadcast storm on your network, you are familiar with the issue. To confine the impact of broadcast messages on a TCP/IP network, IP routers do not forward broadcast messages. Unlike the Microsoft NWLink protocol for IPX compatibility, which was written by Microsoft to support broadcasts, TCP/IP conforms to very strict standards. To function in a TCP/IP environment, Microsoft's TCP/IP implementation had to conform to the standard. Therefore, Microsoft had to find a way to make NetBIOS naming work in a standard TCP/IP network.
Microsoft's first solution, introduced in its older LAN Manager server, was to use a LAN Manager HOSTS (LMHOSTS) file on each computer on the network. Similar to the HOSTS file used before DNS was available, LMHOSTS consists of records matching NetBIOS names to IP addresses. When a computer couldn't find a particular NetBIOS computer on the local network, it would consult its LMHOSTS file to see whether the computer could be found elsewhere.
An LMHOSTS file is a text file that must be edited manually. After creating a master LMHOSTS file, an administrator must copy the file to every computer on the network. Every time a computer was installed or removed, the master LMHOSTS file had to be updated and redistributed. The architects of TCP/IP faced a similar issue with HOSTS files before the DNS specification was written.
WINS and DNS Integration
Although it would be nice if you no longer had to support WINS clients, this is not always the case—thus the reason that Microsoft still provides a very robust and powerful WINS server in Windows Server 2003. What's more, DNS and WINS can be integrated to provide a more complete name resolution solution for all clients on your network.
You can configure a DNS server to query a WINS server by configuring a DNS zone setting. This is helpful when some of the clients you support require NetBIOS name resolution, such as legacy Windows 9x clients, or cannot register themselves with DNS. In effect, you are providing a means for DNS clients to look up WINS client names and IP addresses without needing to contact the WINS server directly. This is accomplished by adding a WINS lookup record to the authoritative zone. After it is configured, the DNS server will query a WINS server for every request made to it for which it does not have a valid record. If the requested name is located on the WINS server, the information is returned to the requesting client via the DNS server. The process is invisible to all clients. Note that you can configure this for both forward and reverse lookup zones.
If you have a mixture of Windows and third-party DNS servers in your organization, you will run into problems if you attempt to replicate WINS lookup records to these third-party DNS servers. Only Microsoft DNS servers support WINS lookup records; thus, zone transfers to third-party DNS servers will fail. In this situation, you should use WINS referral to create and delegate a special "WINS zone" that refers queries to WINS when needed. This zone does not perform any registrations or updates. Clients need to be configured to append this additional WINS referral zone to their queries for unqualified names, thus allowing clients to query both WINS and DNS as required. You also need to ensure that this WINS referral zone is not configured to transfer to any third-party DNS servers.
Microsoft also needed a dynamic name service that would keep itself current on computers on the network—a name service that could work in routed TCP/IP environments. Microsoft's answer was the WINS. Four elements can be found in a WINS network:
WINS servers—When WINS client computers enter the network, they contact a WINS server using a directed message. The client computer registers its name with the WINS server and uses the WINS server to resolve NetBIOS names to IP addresses.
WINS client computers—WINS client computers use directed (P-node) messages to communicate with WINS servers and are typically configured to use H-node communication. Windows 2000, Windows NT, Windows 95 and 98, and Windows for Workgroups computers can be WINS client computers.
Non-WINS client computers—Older Microsoft network client computers that can't use P-node can still benefit from WINS. Their broadcast messages are intercepted by WINS proxy computers that act as intermediaries between the B-node client computers and WINS servers. MS-DOS and Windows 3.1 client computers function as non-WINS clients.
WINS proxies—Windows NT, Windows 95 and 98, and Windows for Workgroups client computers can function as WINS proxies. They intercept B-node broadcasts on their local subnet and communicate with a WINS server on behalf of the B-node client computer.
As we discuss in the "Implementing WINS Replication" section of this chapter, WINS servers can replicate their databases so that each WINS server can provide name resolution for the entire network. Whenever possible, it is desirable to have at least two WINS servers. This way, name resolution can take place when one name server is down. Also, administrators can distribute WINS activity across multiple servers to balance the processing loads. WINS server addresses are one of the configuration settings that can be issued with DHCP.
What's New in Windows Server 2003 WINS
If you're moving from a Windows NT 4.0–based WINS implementation, some great changes are in store for you in Windows Server 2003. The following improvements have been made to WINS since Windows 2000 Server:
Record filtering—Using improved filtering and search functions, you can quickly locate records by showing only the records that fit the specified criteria. This capability can be useful when you are managing larger WINS databases. You can now specify multiple criteria to perform advanced searches. Also, you can combine filters for customized results. The available filters include record owner, record type, NetBIOS name, and IP address (with or without the subnet mask). Lastly, because the results of the query are stored in the local NetBIOS cache on your computer, the performance of subsequent queries and name lookups is improved.
Specified replication partners—You can define a list of WINS servers that are allowed to be the source of incoming WINS records during pull replication events. You can opt to block specific WINS servers from being able to replicate with your WINS servers. Alternatively, you can opt to allow a specific list of WINS servers to perform replication, blocking all other WINS servers from replicating with your WINS servers.
The following improvements were also made to WINS in Windows 2000 Server and are carried over into the WINS implementation in Windows Server 2003:
Command-line management—You can use the netsh command with the WINS context to manage WINS servers from the command line and to use batch files.
Persistent connections—Each WINS server can be configured to maintain a persistent connection with one or more of its replication partners. This configuration increases replication speed and eliminates network overhead associated with building and tearing down connections for replication.
Manual tombstoning—Records can be marked for deletion (tombstoning). This tombstoned state is replicated to all WINS servers preventing an active copy of the record on a different WINS server from being propagated.
Improved management—The WINS console is Microsoft Management Console based and can be added to customized MMCs, resulting in a user-friendly, powerful, and customized management interface.
Dynamic record deletion and multiselect—Using the WINS console, you can you easily manage the WINS database. You can point, click, and delete one or more WINS static or dynamic entries.
Record verification—Record verification performs a comparison of the IP address returned by a NetBIOS query of different WINS servers. This feature helps to check the consistency of names stored and replicated on your WINS servers.
Version number validation—Version number validation examines the owner address–to–version number mapping tables. This feature helps to check the consistency of names stored and replicated on your WINS servers.
Export function—The WINS database can be exported to a comma-delimited text file for importation into Excel or another application for offline analysis.
Increased fault tolerance—Windows 98 and later clients can specify up to 12 WINS servers per interface, up from the previous limit of 2. These extra WINS servers can be queried should the primary and secondary WINS servers not respond.
Dynamic renewal—WINS clients are no longer required to restart after renewing their NetBIOS name registration.
Nbtstat -RR option—The Nbtstat -RR option provides the ability to release and renew the NetBIOS name registration.
WINS Users group—A special local group, WINS Users, is created when WINS is installed; this group provides read-only use of the WINS console. Members of this group can view but not change information and properties of the WINS servers.