This chapter is from the book
This chapter is from the book
This chapter is from the book
WINS in the Mix
WINS is still around in Windows Server 2003 for backward-compatibility with older programs and client systems still used in some enterprises. You can add it to your Windows Server 2003 system through the Configure Your Server Wizard or by clicking Control Panel, Add or Remove Programs, Add/Remove Windows Components.
Only a couple of new features have been added to WINS (sometimes referred to as a NetBIOS name server) since the updates released in Windows 2000 Server. In Windows Server 2003, WINS has new filtering and search functions; to help you locate records, only those records that fit search criteria you have set are shown. Some of the available search filters include record owner, record type, NetBIOS name, and IP address with or without subnet mask.
When administrators are configuring a domain's replication strategy, they can define a list that controls the source of incoming name records during pull replication between WINS servers. They can also accept only name records owned by specific WINS servers during replication and exclude the name records of all other WINS servers.
The Windows Server 2003 DNS service enables administrators to configure WINS servers to look up hostnames not found in the DNS domain namespace. To do this, NetBIOS namespaces managed by WINS are checked, so systems that cannot query WINS directly can still resolve a system NetBIOS name to find the resource in WINS via DNS.
You can use WINS forward lookup resource records with a name query to WINS servers as a way to get further name resolution when machine names aren't found in DNS. The Windows Server 2003 WINS service supports WINS clients running on the following platforms:
Windows Server 2003 (all versions including 64-bit)
Windows XP (all versions including 64-bit)
Windows Me
Windows 2000 Server
Windows 2000 Professional
Windows NT Server
Windows NT Workstation
Windows 98
Windows 95
Windows for Workgroups
Microsoft LAN Manager
MS-DOS clients
OS/2 clients
Linux and Unix clients (with Samba installed)
WINS-enabled clients communicate with a WINS server to do the following:
Register client names in the WINS database.
Renew client names with the WINS database.
Release client names from the WINS database.
Resolve names by obtaining mappings from the WINS database for usernames, NetBIOS names, DNS names, and IP addresses.
Clients that are not WINS enabled can use some WINS services through the use of WINS proxies. WINS proxies are WINS clients configured on a specific subnet to act on behalf of other host computers that cannot use WINS directly to resolve NetBIOS names. NetBIOS names are 15 characters long, with a 16th reserved character that uniquely identifies a service the particular system is running.
WINS is mainly designed to resolve NetBIOS names to IP addresses, but in the past, this was often done via broadcast as well. Depending on system configuration and type, some systems use broadcasts only to resolve NetBIOS names on the network. You can configure a WINS proxy to listen on behalf of these systems and to query WINS for names not resolved by broadcast and send the resolution back to the querying client. Normally, WINS proxies are used only on networks that include NetBIOS broadcast-only (B-node) clients.
Systems that are configured to use WINS are normally configured as a hybrid (H-node) client, meaning they attempt to resolve NetBIOS names via a WINS server and then try a broadcast (B-node) if WINS is unsuccessful. Most systems can be configured to resolve NetBIOS names in one of four modes:
Broadcast (B-node)—Clients use a broadcast only to resolve names. An enhanced B-node setting has the client use an LMHOST file as well. The hex value for this setting is 0x1.
Peer-to-Peer (P-node)—Clients use WINS only to resolve names. The hex value for this setting is 0x2.
Mixed (M-node)—Clients first use a broadcast in an attempt to resolve NetBIOS names. If this fails, they attempt the resolution via the WINS server. The hex value for this setting is 0x4.
Hybrid (H-node)—Clients first use the WINS service in an attempt to resolve NetBIOS names. If this fails, they attempt the resolution via broadcast. The hex value for this setting is 0x8.
Enhanced B-node systems (specifically, others can be configured to use it as well) use the LMHOSTS file, a text file that is manually updated with NetBIOS name–to–IP address mapping information on a network. The file is located in the %SystemRoot%\System32\Drivers\Etc folder by default on Windows 2000, XP, and Server 2003 systems.
Additional information on LMHOSTS files is available in "Need To Know More?" at the end of this chapter. Using LMHOSTS files and manually updating them are usually administratively viable only when fewer than 25 systems total are in use. WINS is the best resolution in an environment with multiple subnets.
The following is a quick overview of the straight WINS registration process:
Systems receive their IP addresses from a DHCP server, which also configures them to use a specific WINS server or servers.
The client sends a name registration request directly to that WINS server.
If the system's NetBIOS name is not already in the WINS server's database, it is accepted as a new registration.
The name is entered with a new version ID, given a timestamp, and marked with the WINS server's owner ID. The timestamp is the length of time the system can use the name it has registered on the network.
A registration response is sent back to the registering client system from the WINS server with a TTL value equal to the timestamp recorded for the name.
The default renewal interval for WINS names is six days. Clients attempt to renew their registrations when 50% of the TTL value has elapsed. A name must be refreshed before this interval ends, or the WINS server force-releases it.
WINS servers support burst handling for name registration during peak traffic times. Name registration bursts normally occur first thing in the morning if a location has a set start time, and a large number of users come in to work at once and simultaneously start up their PCs.
WINS has a normal name registration operating threshold (called a queue value) of 500 by default. If registering systems stay below this value, they are handled via the normal registration process. If this queue value is exceeded, the WINS server responds to new client registration requests with a shorter lease threshold. The TTL is set much lower than the default six days (or whatever the current setting is), which forces clients to reregister with WINS.
The first 100 clients over the set queue value are given a TTL setting of five minutes on their names. The next 100 receive a TTL of 10 minutes, and so on, until a maximum of 50 minutes is reached. Then the 100-count process starts over at five minutes. As the load on the WINS server falls below the queue value, clients reregister and receive the full lease time for their NetBIOS names.
A single WINS server can handle up to 10,000 clients for NetBIOS name resolution requests, based on a decent CPU and adequate memory and disk throughput, but other factors need to be considered, such as fault tolerance, server hardware, other services running on the server, network topology, number of remote users, and so on.
WINS Replication
In most cases, especially in larger environments, multiple WINS servers are running. Some clients might be configured to use one WINS server, and other sets of clients might be configured to use another. This causes a problem if a client using WINS1 needs to resolve the name of a system that registered on WINS2. Convergence time is the time it takes to replicate a new entry in a WINS database to all the other WINS servers in the environment.
NOTE
When a client registers its name with a WINS server and an entry is made to that database, it is called an originating update. When that change is replicated to other WINS databases, it is referred to as a replicated update.
When planning placement and replication for WINS servers, you must decide on an acceptable convergence time for your network. Replication is used to synchronize WINS databases across the different WINS servers.
WINS servers are configured to sync with replication partners. Those partner WINS servers can be configured as pull partners, push partners, or a combination push/pull partner. Pull partners pull database entries from their WINS replica partners at a predetermined time. This means that no matter how many (or how few) changes have been made to the WINS database, at the time of pull replication, the server gets the updates. Push partners work off a quota number. When a WINS server has accrued a predetermined number of updates to its database, it pushes those changes out to its replication partners. In other words, push partners send updates out as soon as they have enough accumulated database updates, regardless of how long it has been since the last updates were sent.
There are issues with both designs. Pull partners, which might be configured to get databases only once every hour, are not properly updated during high-volume registration hours, such as the beginning of the workday. Push partners, which might be configured to replicate only when they have 300 new records, do nothing if the count stops at 153. The solution is to set up push/pull partners. These WINS servers are normally paired up, or if there are enough of them, configured in a hub and spoke setup to push and pull their changes among each other, thus solving both problems mentioned previously.