 | WINS Features |
| WINS Processes |
| Installing and Configurig WINS Server |
| WINS Proxy Server |
| ConfiguringWINS Client |
| WINS Database Replication |
| WINS Database Maintenance |
The Windows Internet Name Service (WINS), provides tools that enhance Windows NT to manage the names of servers and workstations in a TCP/IP networking environment. In order to understand WINS, it is necessary to understand the precursor to it, NetBIOS. NetBIOS names are 16 characters in length. The NetBIOS name space is flat, meaning that names may be used only once within a network. These names are registered dynamically when computers boot, services start, or users log on. NetBIOS names can be registered as unique or as group names. All Windows NT network commands, such as Explorer, use NetBIOS names to access services.
Unique names have one address associated with a name. Group names have more than one address mapped to a name. NetBIOS is responsible for establishing logical names on the network, establishing sessions between two logical names on the network, and supporting reliable data transfer between computers that have established a session.
Before WINS, the LMHOSTS file was used to assist with remote NetBIOS name resolution. The LMHOSTS file is a static file that maps NetBIOS names to IP addresses. This is similar to the HOSTS file in functionality; the only difference is that the HOSTS file is used for mapping host names to IP addresses.
Microsoft has developed a system for NetBIOS name resolution for Windows NT (see Figure 8-1). The first place checked is the local NetBIOS name cache. The command nbtstat –c, when issued at the command prompt, will show all resolutions in the NetBIOS name cache. This cache will contain resolutions for the most recently mapped names. After the cache is checked, the WINS Server, if present, will be queried. If WINS fails, a broadcast message will be sent. If the name is outside the subnet, the broadcast will fail at the router.
Figure 1: Microsoft’s Name Resolution Methods
If no name is found, the local machine's LMHOSTS file is read. The LMHOSTS file can be bypassed by unchecking the "Enable LMHOSTS Lookup" box on the WIN Address Tab, under TCP/IP Protocol. By checking the Enable DNS for Windows Resolution check box on this same dialog box, NT will continue and use the HOSTS file, and finally, the DNS Server, if present, to resolve the NetBIOS name.
WINS includes many features that allow simpler networking. By allowing computers to register NetBIOS names in one location, the maintenance and management becomes easier. A WINS Server eliminates the need for many network broadcasts, and therefore reduces network usage. This is accomplished by using directed, or point to point transmissions for name resolution. WINS is dynamic, and is updated when machines are started or stopped, or by replication with other WINS Servers. When a name is registered, it will be reserved for that one computer, further simplifying naming schemes. Each computer will always have its own unique name.
The WINS Server is any Windows NT Server on a TCP/IP network. This server should also have a static IP address, not one obtained dynamically from a Dynamic Host Configuration Protocol (DHCP) server. The WINS Server maintains a database of mappings for IP addresses to NetBIOS names. When a WINS Client requests an IP address, the WINS Server will check its database and return the address to the client. It is not required, but a secondary WINS Server can be implemented for larger networks.
A WINS Client is the machine that requests a NetBIOS mapping. This computer can use one of several operating systems. In addition to an acceptable operating system, a WINS Client must also be configured with the address of the WINS Server. For computers running Windows NT or 95, this will be entered under Network - Properties, select TCP/IP Protocol, and then the WINS address tab. The address of the WINS Server may be obtained dynamically from a DHCP server.
The LMHOSTS file contains mappings of IP addresses to NetBIOS names. Its greatest limitation is that it is a static file. As this file grows in size, it will take longer and longer to resolve names, because the file is always parsed from top to bottom sequentially. The LMHOSTS file resides in the \systemroot\system32\drivers\etc directory. Each computer on the network has its own file that must be maintained manually. This can rapidly become a nightmare for network administrators.
Because the LMHOSTS file is static, entries have to be updated if the name or the IP address of the computer changes. An IP address might change for several reasons. Physically moving the computer between subnets would require a new IP address, as would a remote user dialing in via the Remote Access Server (RAS). A new address might also be acquired from a DHCP Server after lease expiration. In addition to modifying the LMHOSTS file when such changes occur, these changes must be sent to all the computers needing access to the resource whose name to IP address mapping has been modified. A centrally maintained LMHOSTS file can reduce the manual administration effort involved in propagating these mappings to the required computers. Even for a central file, entering and changing the mappings is still a manual, labor intensive process.
The LMHOSTS file is searched sequentially, from top to bottom, each time it is read. The more mappings the file contains, the longer it takes to resolve the name. To speed up name resolution, the most commonly used names should be placed at the top of the LMHOSTS, or even the HOSTS, file. A typical LMHOSTS entry looks like this:
122.107.9.10 Accounting #Accounting Server
Each line contains an IP address, a NetBIOS name mapping, and possibly a # sign followed by a remark.
It is entirely possibly that an LMHOSTS file may contain duplicate IP mappings. In this case, the first mapping read is used, and all others are ignored. This not only increases the file size, but also may result in improper mappings. Spelling is extremely important in this file. Names must match exactly in order for the mapping to be successful.
In addition to supplying static mappings, an LMHOSTS file can be used to pre-load the NetBIOS name cache. The #PRE keyword defines which entries are pre-loaded in the cache when the machine is started:
122.107.9.10 Accounting #PRE #Accounting Server
Since the cache is read first to resolve names, this method will actually speed up name resolution. Remember, this is a static mapping, and will not be updated automatically.
Windows NT is not limited to a single LMHOSTS file. Virtually any number of files may be chained together to enable name resolution. The #INCLUDE keyword placed in the LMHOSTS file forces the inclusion of an additional file to the name resolution search. Another means of searching through other mappings files is to use the #BEGIN_ALTERNATE keyword. This marks the beginning of a list of other files to search, usually LMHOSTS files on other computers. The end of the list is marked #END_ALTERNATE.
Broadcasts messages can be used for NetBIOS name resolution. The biggest drawback to broadcasts is the inability to cross routers. Only machines on the local subnet will respond to a broadcast. Another problem with broadcast messages is increased network traffic. All computers will receive and process the broadcast. This may not be a problem for small networks, but several computers performing several broadcasts, combined with other network traffic, can certainly lead to bottlenecks.
Exercise 8-1 Using nbtstat and ping to View and Test Name Resolution
In this exercise you will open an NT Command Prompt and use nbtstat to view the entries in the NetBIOS Name Cache.
"reply from 127.0.0.1: bytes=32 time<ms TTL=128"
WINS provides a distributed database for registering and querying dynamic NetBIOS names to IP address mappings in a routed network environment. When a computer in a WINS-enabled network is started, it will automatically register all its NetBIOS names with the WINS Server. If the computer's IP address has changed, the WINS Server will know immediately. This is WINS’ strength, its ability to keep an accurate IP mapping database in an ever-changing network environment. It is the best choice for NetBIOS name resolution in a routed network because it is designed to solve the problems that occur with name resolution.
The LMHOSTS file addressed only one disadvantage of broadcast-based systems by allowing resolution of names across routers. Since the system itself was still broadcast based, the problems of broadcast traffic and load on local nodes were not solved. A protocol was defined that allows name registration and resolution through unicast datagrams to a NetBIOS Name Server. Since unicast datagrams are used, the system inherently works across routers. The only address needed for resolution is for the name server. This eliminates the need for an LMHOSTS file, restoring the dynamic nature of NetBIOS name resolution. This, in turn, allows the system to work seamlessly with DHCP. For example, when dynamic addressing through DHCP results in new IP addresses for computers that move between subnets, the changes are automatically updated in the WINS database. Network administrators and users no longer need to make manual changes for name resolution.
WINS provides for Point-to-Point name resolution, in that a computer requests an IP address mapping directly from the WINS Server. A broadcast, from point-to-all, is not generated. This reduces network traffic, and quickens response time. The WINS Server is always up to date since all computers register their NetBIOS names at startup. The WINS Server IP address may be obtained from DHCP, or be manually input. Obviously, if the WINS Server address changes, WINS Clients must be updated. By utilizing DHCP, this update occurs only on the DHCP server, and not on each local machine.
The WINS process is relatively simple, and, when implemented properly, will not significantly affect network utilization (see Figure 8-2). Typically, WINS accounts for no more than 1% of all network traffic. Again, on startup, each computer will register its name and IP address. These machines are the WINS Clients, and will be referred to as a Client. When a Client initiates a Windows NT command to communicate with another host, the name query is sent directly to the WINS Server. The WINS Server will then reply directly to the Client with the appropriate mapping. The Client will then store this mapping in its NetBIOS name cache for the appropriate time, 10 minutes by default. Remember, this cache is checked first for NetBIOS name resolution, so frequently requested addresses may not actually come from the WINS Server after an initial check.
Figure 2 The WINS Process
The first step in the WINS process is the Name Registration Request. A Name cannot be registered until a machine requests it from the designated WINS Server. This occurs each time a Client is started, and registers its NetBIOS names with the designated WINS Server. Each Client may register more than one name, one for the machine, and then others for different services or applications on that machine. For example, both the Workstation and Server Services will register their names with a WINS Server. Network Monitor also registers as an application with the WINS Server. These requests may be for unique names, or for shared (group) names. Most clients will register three or four names.
Each registration begins with the Client sending a Name Registration Request packet to the WINS Server. This frame is 110 bytes in size and includes the Client's address, WINS Server's address, and the name requested. An example frame summary would look like this:
Frame Time Source Destination Protocol & Description
10 10.135 CLIENT SERVER NBT_NS: Registration Req. for NAME <03>
This is a request from Client at address "CLIENT" to the WINS Server at address "SERVER" to register the NetBIOS Name of "NAME <03>." The <03> is one of several identifiers that tell WINS the use of the name, in this case it is for the messenger service so that the user may receive messages.
After receiving a registration request there are several possible scenarios for the WINS Server. The simplest is when the requested name is not in the database. This is a new name registration so the WINS Server will send a Positive Name Registration Response to the Client, and enter the mapping with a new version ID, a Time Stamp of Current Time + Renewal Interval, and the WINS Server's owner ID. Time Stamps will be discussed later with Name Renewal.
The next resolution scenario occurs when the name is already in the database with the same IP address as the Client. If this is an active entry, owned by this WINS Server, the Server will update the Time Stamp and send a Positive Name Registration Response back. If the entry is in the released state, or if another WINS Server owns the entry, the registration is treated as new. Time stamp, version ID, and ownership are all updated and a Positive Name Registration Response is sent.
If the name already exists in the database, but has a different IP address, WINS must not assign duplicate names. In this case, the status is checked first. If the name has been released, the WINS Server will treat the request as a new registration. However, if the name is active, the WINS Server will query the holder of the name. A Wait for Acknowledgment Response is first sent to the requesting Client, specifying a time to wait. The WINS Server then issues a Name Query Response to the IP address registered in the database. If this IP address is still valid, it will return a Positive Name Query Response to the WINS Server, which will then issue a Negative Name Registration Response to the Client. If no Positive Name Query Response comes back, the WINS Server will try two more times at 500 millisecond intervals. After the third attempt, if no Positive Name Query Response is returned, the WINS Server will treat this registration as a new name registration.
In any scenario, a name is not registered until the WINS Server replies with a Positive Name Registration Response. After determining success or failure, the WINS Server then sends the response. The response frame is 104 bytes in size, regardless of indicating success or failure:
Frame Time Source Dest. Protocol & Description
11 10.185 SERVER CLIENT NBT_NS: Registration (node status) resp. for NAME <03>, Success
At this point, since this frame indicates success, the name is successfully registered with the WINS Server. The name is entered into the database with a version ID, a Time Stamp of Current Time + Renewal Interval, and the WINS Server's owner ID. The Renewal Interval reflects the Time to Live (TTL) of the name. This entire transaction uses only 214 bytes of network traffic, and generally takes less than 100 milliseconds. Failures should be unusual, because each computer will be given a unique name for its network ID.
A Client will attempt to register with the primary WINS Server three times. If the WINS Server fails to respond, the Client will attempt to locate the secondary WINS Server. Both of these addresses can be obtained through DHCP, or input manually under Network - Properties, Protocols, TCP/IP - Properties, WINS Address. If no WINS Server responds, the Client will initiate a broadcast to attempt name registration. See Table 8-1 for a list of commonly registered names and their descriptions.
Name Registered Description
Unique Names
Group Names
Table 2 Commonly Registered Names
The owner must renew a name in order to continue to use the same NetBIOS name. It is the Client's responsibility to renew its names. A Name Renewal Request will stop the WINS Server from reassigning a registered name by keeping it in an active state in the database. Once the renewal occurs, the WINS Server will not assign the name to another Client.
When a name is registered, it is assigned a Time To Live (TTL). For WINS, the default TTL is 144 hours, so the WINS Server assigns a TTL of 518,400 seconds. This is the Renewal Interval, and, when used in conjunction with the Time Stamp, determines when Name Renewal occurs. There are two different procedures for Name Renewal.
The first procedure is used only the first time a name is renewed. After 1/8 the TTL has expired, by default 18 hours, the Client will send a Name Refresh Request to its primary WINS Server. If the Client does not a get a response, it will continue sending a Refresh Request every 2 minutes until 1/2 TTL has expired. At this point, the Client will wait again until 1/8 TTL has expired, and then send a Name Refresh Request to the secondary WINS Server. After four tries, 1/2 TTL, the Client will again attempt to locate the primary WINS Server.
After successfully renewing a name the first time, a Client will attempt to renew at only 1/2 TTL, or 3 days by default. Again, if the primary WINS Server is not found, the Client will attempt to contact the secondary WINS Server. After a successful renewal the WINS Server will update the database with a new TTL and Time Stamp.
In either case, the Name Refresh Request and Name Refresh Response frames contain the same information as a Name Registration Request and Response frames. Again, these frames generate a total 214 bytes of network traffic, 110 for the request and 104 for the response:
Frame Time Source Destination Protocol & Description
12 12.135 CLIENT SERVER NBT_NS: Registration Req. for NAME <03>
13 12.185 SERVER CLIENT NBT_NS: Registration (node status) resp. for NAME <03>, Success
The real function of WINS is the Name Lookup or Name Query (see Figure 8-3). It is for this purpose that WINS was defined. By using names instead of IP addresses, computers become much easier to use. It is much easier to remember www.microsoft.com than 207.68.156.52, although this is actuall a DNS resolution. As IP addresses change from their current 4-octet form to 8 octets, the need for name resolution becomes even greater. The process involves a series of packets, or frames, sent between the Client and WINS Server. The first is a Client request, followed by a WINS Server response. If resolution fails, a broadcast will be sent.
Figure 3 Name Resolution Sequence
The place checked for name resolution is the local NetBIOS name cache. All these entries are the most recently resolved names, or ones placed there upon startup. The default TTL for names in the cache is 10 minutes. This default is changed by entering a value in the Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\
Parameters\CacheTimeout
If a name is not resolved from the cache, a WINS Client will then issue a Name Query Request to its primary WINS Server. This request is only 92 bytes long:
Frame Time Source Destination Protocol & Description
14 24.548 CLIENT SERVER NBT_NS: Query req. for NAME
When this frame is received, the WINS Server checks its database for the requested name. If the primary WINS Server does not respond at all, the Client will attempt to locate it two more times. Should all three attempts fail, the secondary WINS Server is queried. When the name is found, a Name Query Response is generated and returned to the Client. This response has the IP mapping for the requested name, and will be 104 bytes in size:
Frame Time Source Destination Protocol & Description
15 24.551 SERVER CLIENT NBT_NS: Query (node status) resp. for NAME, Success
For names not found, a "Requested name does not exist" message is sent. The Client will then perform a broadcast over the local subnet to find the proper computer. After the broadcast, the LMHOSTS file, the HOSTS file, and the DNS server can be checked to resolve the name.
Because larger networks will have more then one subnet, WINS Servers can, and should, be configured to share their databases. This provides for the maximum in name resolution and flexibility. This process is known as Database Replication, and will be discussed later in this chapter. If the name is not found, the databases could be out of sync with a replication partner.
Name resolution traffic is the largest part of WINS network traffic. A completed query results in 196 bytes of traffic. Remember, name resolution occurs during logon validation, resource browsing, server connections, and print job notifications.
Once a computer registers a name, the host owns the name until it releases it. Only after a name has been released, can a different computer register it. When a Client stops a service, or is shut down, it releases the names that it holds. The WINS Server is then free to reassign these names to different machines.
Whenever a computer is shut down, or a service is stopped, a Name Release Request will be sent to the WINS Server. The Client will send this request to its primary WINS Server. The WINS Server will check its own database for the name. The entry is then changed from active to inactive, and the TTL is changed to zero. A Name Release Response frame is then sent to the Client. Once again, these two exchanges are 110 and 104 bytes in size, and look similar to these examples:
Frame Time Source Destination Protocol & Description
16 32.883 CLIENT SERVER NBT_NS: Release Req. for NAME <03>
17 32.936 SERVER CLIENT NBT_NS: Release (node status) resp. for NAME <03>, Success
Only if there is some sort of database error, or incorrect IP mapping, will the WINS Server return a failure message on a Release request. Since WINS is dynamic, an error here is extremely rare. Since most registered names are unique, the next time the Client is started the Registration process cleans up errors.
Very little optimization is needed for WINS as it typically accounts for less than 1% of all network traffic. Unnecessary services should be disabled for several reasons, one of which is to reduce WINS traffic. If a service is not needed and not allowed to register its name, network traffic is reduced, and the WINS database is smaller. Disabling services may also speed up the local machine where the service is turned off.
As mentioned earlier, the NetBIOS name cache is the first place checked for name resolution. The default TTL of 10 minutes (600,000 milliseconds) can be changed to a larger number, which may also reduce WINS traffic by keeping the most frequently used names in the cache. The downside is that updates to the cache will not be made as frequently. This change is made by increasing the value of the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\
Parameters\CacheTimeout
Using LMHOSTS to pre-load the cache with commonly used addresses can also reduce network traffic. This is done by using the #PRE key in the file. For efficiency, entries marked with the #PRE key should be placed at the end of the LMHOSTS file. Since these entries will be in the NetBIOS Name Cache, they should be read last if the file is checked for name resolution. Be careful, because the LMHOSTS file is not dynamic, and will need to be manually updated if changes occur.
The default renewal rate (TTL) can also be changed, but it is not recommended. It can be changed through WINS Manager, but the default of 72 hours is fine in all but the rarest of circumstances. Since renewals occur only every 3 days, there is not a lot of network traffic generated.
A relatively drastic means to make your WINS Server faster, is to tell it to stop logging all changes to its database. Open the WINS Manager, highlight a server, and click Server/Configuration. Click Advanced, and clear Logging enabled. This procedure tells WINS to stop creating a transaction log. Not having a transaction log will make rebuilding your WINS system's names database harder if a WINS Server crashes, but preventing logging also will roughly double the number of resolutions the WINS Server can handle per minute. WINS gets its information from computers doing name registrations whenever they boot, probably once a day for most machines. Rebooting the PCs in a network would let WINS restore its database in minutes.
For logging to be effective, fill in the text field Database Backup Path in Server/Configuration/Advanced to tell WINS to back up its database every three hours. If you don't fill in that field, your WINS Server won't back up its entire database, so logging changes to the database would not be useful.
Another way to speed up WINS a bit is to modify its runtime priority. Just go to the Registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WINS\Parameters and create an entry called PriorityClassHigh. Its type is REG_DWORD, and its value is either 1 or 0. Zero, the default, says to keep the priority at normal. Set it to 1, and you increase the WINS Server priority to high, and ensure that it is not preempted by other processes. Before you set the priority, look at the Performance Monitor to see whether the machine is usually busy. If it isn't, changing the priority of the WINS Server isn't going to matter much. A high priority setting won't make a WINS Server running alone on a slow machine run more quickly. The priority will help the WINS Server grab more CPU cycles from file and print services.
A final way to get faster name resolution is to add a CPU to a WINS Server. A second CPU improves performance about 25 percent. A third, fourth, or additional CPUs don't improve performance further.
Using WINS on a TCP/IP network is relatively simple process. As with all Network services, WINS is installed through the Network Properties, Services tab. Most configuration can be done through the TCP/IP protocol for Clients, and by using the WINS Manager for WINS Servers. There are several considerations before implementing WINS.
For WINS to work, there must be at least one WINS Server. To provide for fault tolerance, and load sharing, two or more WINS Servers may be ideal. There is no built-in limit to the number of requests that a WINS Server can handle, although a typical WINS Server can handle 1,500 name registrations and 4,500 name queries per minute. Based on these numbers, there should be one WINS Server and Backup for every 10,000 Clients; however, if the WINS Server has multiple processors, these numbers can be increased by about 25%.
WINS Servers can use logging, which is turned on and off through the WINS Manager, but this will impede performance. The advantage to logging is that it reduces the risk of losing the last few updates to the database before replication occurs.
To install the WINS Server Service, log on with Administrator privileges and open Network Properties either through the Control Panel or Network Neighborhood icon. On the Services tab, choose install Windows Internet Name Service. Windows will require access to the Windows NT installation files, either from the CD or from a hard disk location, to complete the installation. After the necessary files are copied, the WINS Server will need to be restarted for the changes to take effect.
Static mappings should be given to all non-WINS Clients to enable WINS Clients on remote network access to them. A WINS Proxy Agent can be configured to extend the name resolution capabilities to non-WINS Clients. DHCP Servers should also be enabled to support WINS, so IP addressing can be done automatically, and the WINS Server address given to Clients.
Exercise 8-2 Installing a WINS Server
In this exercise, you will install a WINS Server to automatically resolve NetBIOS names to IP addresses for WINS Clients.
To install the WINS Server service:
If desired, and if they exist, delete the HOSTS and LMHOSTS files from the %systemroot%\system32\drivers\etc folder to prevent them from interfering with WINS.
Exercise 8-3 Configuring Clients to Use WINS Service
In this exercise, you will install a WINS Client to use your WINS Server.
To install the WINS Client:
Your computer is now configured as a WINS Client, and can be tested by browsing the network for a remote resource. You can use either Network Neighborhood, or NT Explorer as a test. You should see all remotely registered names.
The WINS Configuration Manager is automatically installed and added to the Administrative Tools (Common) group when WINS is installed on an NT Server. Once the installation is complete on the computer running Windows NT Server, use WINS Manager to complete the configuration of WINS. Before you can administer and manage WINS Servers, you must add the WINS Servers to the Server List using WINS Manager. All computers running the WINS service can be added to the WINS Server List. Until the WINS Servers are added to the list, no WINS features are available. Once the servers are added to the list, administration of any computer running Windows WINS Service can take place from any other computer running the WINS Manager.
To Add a WINS Server to the Server List, open the WINS Manager Server menu (see Figure 8-4), click Add to see the Add WINS Server to Server List dialog box. In WINS Server, type the IP address of the WINS Server to be added to the list, and then click OK.
Figure 4 WINS Manager
Once a WINS Server is added to the list (see Figure 8-5), configuration of the server can take place. You must be a member of the administrators group of the WINS Server in order to perform the configuration. To configure a WINS Server, start WINS Manager and choose the WINS Server to be configured. From the Server menu, click configuration, and the WINS Server Configuration box opens (see Figure 8-6).
Figure 8-5 Add WINS Server
Figure 6 WINS Server Configuration
Select the configuration options you want:
| To specify how often a WINS Client will renew its name registration with the WINS Server, type a value in Renewal Interval. The default is 144 hours or 6 days. |
| To specify the interval between when an entry in the WINS database is marked as released (no longer registered) and when it is marked as extinct, type a value in Extinction Interval. |
| To specify the interval between when an entry is marked extinct and when the entry is removed from the WINS database, type a value in Extinction Timeout. |
| To specify when the WINS Server will verify that old names it does not own (those replicated from other WINS Servers) are still active, type a value in Verify Interval. |
| To specify pull parameters, select the Initial Replication check box under Pull. |
| To specify the number of times that the WINS Server will attempt to contact a replication partner for pulling new WINS database entries, type a value in Retry Count. |
| To have the WINS Server notify its replication partners of the status of its WINS database when the system is initialized, select the Initial Replication check box under Push Parameters. |
| To notify the replication partners of the WINS Server when a name registration changes the WINS database status, select the Replicate on Address Change check box. |
Click Advanced to configure these other options:
| To specify logging of database changes to Jet.log, select the Logging Enabled check box. |
| To log events in detail, select the Log Detailed Events check box. |
| To replicate only with WINS push or pull partners, select the Replicate Only With Partners check box. |
| To automatically back up the database when WINS Manager stops, select the Backup On Termination check box. The database backup path must have a directory specified. |
| To treat static unique and static multihomed records in the database as dynamic when they conflict with a new registration or replica, select the Migrate On/Off check box. This means that if they are no longer valid, the new registration or replica will overwrite them. By default, this option is not checked. |
| To set the highest version ID number for the database, enter that number in Starting Version Count. |
| To specify the directory where the WINS database backups will be stored, type the path in Database Backup Path. The database will not be backed up until this path is set. |
Some important notes and considerations when configuring a WINS Server:
| Logging events in detail requires considerable system resources and should be turned off if you are tuning for performance. |
| If the Replicate Only With Partners check box is not selected, an administrator can ask a WINS Server to pull or push from or to a non-listed WINS Server partner. By default, this option is checked. |
| Usually, you will not need to change the value in Starting Version Count unless the database becomes corrupted and needs to start fresh. In such a case, set this value to a number higher than appears as the version number counter for this WINS Server on all the remote partners that earlier replicated the local WINS Server’s records. WINS may adjust the value you specify to a higher one to ensure that database records are quickly replicated to other WINS Servers. |
| If you specify a backup path, WINS automatically performs a full backup of its database to this directory every 24 hours. WINS uses this directory to perform an automatic restoration of the database in the event that the database is found to be corrupted when WINS is started. Use only a local directory, not a directory on the network. |
How can I administer a remote WINS Server?
Use the Add WINS Server dialog box to add the WINS Server.
How can I register names for two weeks?
Change the default Renewal Interval from 144 hours, to 336 hours.
How can I keep all the databases as updated as possible.
Select Replicate on Address Change to replicate each time a registration occurs that changes the database
Where do I specify the Backup Directory?
In the Database Backup Path box, on the Advanced WINS Server configuration dialog box.
Can WINS replicate with a WINS Server that is not a replication partner?
Yes, uncheck the Replicate Only With Partners box, and specify the WINS Server
How often does WINS backup, once the directory is set?
Every 24 hours.
Static mappings are permanent lists of computer name-to-IP address mappings. In a static mapping table, the administrator indicates the computer name and matches the IP address with the computer. When a network client sends a name request to the WINS Server, it will always respond with the name entered by the administrator. In most cases, all DNS Servers, DHCP Servers, and other WINS Servers will be mapped statically. If DHCP is also used on the network, a static IP address will override any WINS Server settings. Static mappings should not be assigned to WINS Clients.
Static mappings may be added to the WINS database either by typing static mappings in a dialog box, or importing files that contain static mappings.
To type static mappings in a dialog box, open WINS Manager and the Mappings Menu (see Figure 8-7). Click Static Mappings to open the Dialog Box. Next, click Add Mappings, and, in the Name Box, type the computer name of the system for which you are adding a static mapping (see Figure 8-8). WINS Manager automatically adds the two backslashes (\\), which normally preceed the entry of a computer name. In IP Address, type the address for the computer, and in Type, click to indicate whether this entry is a unique name or a group with a special name, and then click Add. The mapping entry is immediately added to the database, and the check boxes are cleared so that you can add another static mapping entry.
Figure 7 Static Mappings Dialog Box
Figure 8 Add Static Mappings Dialog Box
The Unique Type is used for a unique name in the WINS database and permits only one address per name. The unique name is the WINS Client’s computer name. The Group Type indicates a normal group for which the IP addresses of the individual clients are not stored. A normal group is the name to which broadcasts are sent and is the domain name used for browsing purposes. A normal group name does not have an IP address associated with it and can be valid on multiple networks and registered with multiple WINS Servers. When a WINS Server receives a request for the group name, the WINS Server returns the broadcast address 255.255.255.255, which the Client will then use to broadcast to the network.
The Internet Group is a group that contains the IP addresses for up to 25 primary and backup domain controllers for the domain. The Internet group name is another instance of the domain name being registered; however, this instance is used for the domain controllers in the domain to communicate with each other. The Multihomed Type is similar to a unique name in that it is the WINS Client’s computer name, however, it can have up to 25 addresses and is for use by multihomed systems. A multihomed system is a system with more than one network interface and more than one IP address. If Internet Group or Multihomed is selected under Type, the dialog box shows additional controls for adding multiple addresses.
Entries for static mappings of unique and special group names can be imported from any file with the same format as the LMHOSTS file. Scope names and keywords other than #DOM are ignored. Static Mappings for normal group and multihomed names can be added only by typing entries in the Add Static Mappings dialog box.
To import a file containing static mapping entries, in the Static Mappings dialog box, click Import Mappings. In the Select Static Mapping File dialog box, enter the name of the file containing the names to be mapped. The specified file is read, and then a static mapping is created for each computer name and address. If the #DOM keyword is included for any record, an Internet group is created, and the address is added to that group.
A WINS Proxy Agent or Server (see Figure 8-9) extends the name resolution capabilities of WINS to non-WINS Clients, such as UNIX machines. The Proxy will listen for broadcasts for Name Registration and Name Resolution, and will then forward them to a WINS Server. These names are not fully registered with WINS, but are checked against the database. The Proxy can send a Negative Name Registration Response to the non-WINS Client so that there will not be duplicate names, but this is not the default setting.
Figure 9 WINS Proxy Agent (Server)
The Proxy must differentiate between local subnet queries and remote name queries. By checking the IP address and subnet mask of the broadcasting computer, the Proxy can tell whether or not it should respond to the request. If the Proxy's subnet matches that of the broadcaster, it will not respond to the broadcast. This guarantees that the Proxy will not respond to queries for names local to the subnet.
If the name is found in the Proxy's remote name cache, a response is sent to the non-WINS Client. If the name cannot be found, the WINS Server is queried and the name is entered into the remote name table in a "resolving" state. Should another query come in for the same name before the WINS Server has responded, the Proxy will not query the WINS Server again. When the response is returned from the WINS Server, the remote table entry is updated with the correct address and the state is changed to "resolved." When the next name query comes in for that name, a response is sent to the client.
In order to reduce duplicate traffic, it is recommended that only one or two Proxies be active on a subnet. Since the Proxy knows the WINS Server’s IP Address, this method can make WINS available to non-WINS Clients across routers. The Proxy must be a WINS Client but cannot be a WINS Server. To configure a Proxy, open the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters
and set the EnableProxy parameter to 1 (REG_DWORD). The computer must then be rebooted for the change to take effect.
Exercise 8-4 Installing a WINS Proxy Agent
For this exercise to work, a network that has two subnets must be set up. The WINS Server needs to be on a separate subnet from the non-WINS Client and WINS Proxy. Be certain to delete the WINS IP addresses on the TCP/IP Properties, WINS Address tab. Delete the LMHOSTS and HOSTS files on the non-WINS Client from the %systemroot%\system32\drivers\etc folder. It may be wise to clear the NetBIOS Cache as well, by opening a command prompt and typing nbtstat –R. These steps guarantee that no name resolution is available to the computer other than a broadcast.
In this procedure, you will configure one computer on each subnet to function as a WINS Proxy Agent. To be a WINS Proxy, the Client must first be configured as a WINS Client.
Test Remote NetBIOS Name Resolution with a WINS Proxy
In this procedure, you will test name resolution of a remote NetBIOS host without a mapping in the local LMHOSTS or HOSTS files, but with a WINS proxy agent configured on each subnet.
Even though the WINS Server is a remote host, resolution was successful using the WINS Proxy agent, because the Name Query Request was broadcast and received by the Proxy.
Remove the WINS Proxy
To register NetBIOS names across networks with a WINS Server, the prospective Clients must know the IP address of the WINS Server. Clients can receive this information in two ways,
dynamically through DHCP or
statically through TCP/IP Properties.
Obviously, it is easier to use DHCP to tell each client the WINS Server address. This is also handy if a secondary WINS Server is added later, or if the IP address changes. One change in the DHCP configuration will change all DHCP Clients the next time they reboot. Without DHCP, each WINS Client must be configured individually. This can be a time consuming process, especially as the network grows and Servers move.
For non-WINS Clients, the Proxy allows Name Resolution across networks and routers, but Name Registration will not occur. Proxies allow names to be checked only for active status, previously registered, not actual registration.
A WINS Client is any computer that requests name resolution from a WINS Server. The Client can use any of these operating systems:
Windows NT Server or Workstation 3.5 or later
Windows 95, or later
Windows for Workgroups 3.11 running MS TCP/IP - 32
MS Network Client for DOS
LAN Manager 2.2c for DOS
Please note that a computer running under UNIX cannot be a WINS Client, but may access WINS through a proxy. In addition, the Client must be configured for WINS.
WINS Clients are set up and configured differently than WINS Servers. Setup does take place through the Network icon, but it only requires that the WINS Server IP Address is given to the Client.
Again, both the primary and secondary WINS Server addresses may be input through Network Properties, under the TCP/IP Protocol, Properties Button, WINS Address tab. Be careful here, mistyping an entry will not allow the Client to find the WINS Server. Any manually input addresses will override the settings obtained from the DHCP Server.
Figure 10 WINS Address Tab
The WINS Address Tab contains several important options (see Figure 8-10). First is the adapter box. Choose the appropriate network adapter, if more than one is present. Next are the IP address boxes that are used to manually input the WINS Server addresses that the specified adapter should use. The two check boxes that follow tell NT whether or not to use DNS and / or LMHOSTS files for WINS resolution. Only after the NetBIOS cache, the WINS Server, and a broadcast, will NT use LMHOSTS. DNS is used if the LMHOSTS and HOSTS files are unsuccessful in resolving the name. The scope ID is usually left blank. It can be used if a DNS Server is not present for Host Name Resolution.
DHCP allows its Clients to obtain IP addresses and other information upon boot up. DHCP gives out IP addresses on a lease assignment basis. Each lease is good for a set time period, 6 days by default. DHCP can provide WINS Server addresses, as well as NetBIOS Node Type settings. Other settings that might be obtained by DHCP include router information for Gateways, Option 003, DNS Server address, Option 006, and NetBIOS Scope ID, Option 047. These are the only options that a Microsoft DHCP client can accept.
One of the most useful of all the DHCP options, Option 044 allows a DHCP Client to receive the IP addresses of both a primary and secondary WINS Server. The IP addresses that you configure in both the primary and secondary WINS Server boxes will take precedence over those received through DHCP. An advantage of DHCP is that correct configuration information ensures correct configuration. Many difficult-to-trace network problems can be eliminated by correct use of DHCP.
DHCP Option 046 sets the NetBIOS Node type, or the means of name-to-IP address resolution. There are four possible entries here, with H-Node being the best choice for WINS:
B-NODE Broadcast nodes communicate using a mix of UDP datagrams (both broadcast and directed) and TCP connections. They interoperate with one another within a broadcast area but cannot interoperate across routers in a routed network. B-nodes generate high-broadcast traffic. Each node on the LAN must examine every broadcast datagram.
P-NODE Point-to-point nodes communicate using only directed UDP datagrams and TCP sessions. They relay on NetBIOS name servers, local or remote. If the name server is down, the p-node cannot communicate with any other system, even those on the same local network.
M-NODE Mixed nodes are p-nodes that have been given certain b-node characteristics. M-nodes use broadcast first, to optimize performance, assuming that most resources reside on the local broadcast medium, for name registration and resolution. If this is unsuccessful, point-to-point communication with the name server is used. M-nodes generate high-broadcast traffic, but can cross routers and continue to operate normally if the name server is down.
H-NODE Hybrid nodes are also a combination of b-node and p-node functionality. H-node uses point-to-point communication first. If the NetBIOS name server cannot be located, it switches to broadcast. H-node continues to poll for the name server and returns to point-to point communication when one becomes available.
When using the H-Node setting, the Client first checks its NetBIOS cache, and then the WINS Server. If the WINS Server is not found, a broadcast is sent out. This is the most efficient setting for WINS, because it allows for both fast name resolution and minimum network traffic. The cache is the fastest way for resolution, and a direct exchange with the WINS Server uses the least amount of network resources. Only if the WINS Server fails will a broadcast (that all computers on the subnet must receive and process) be sent.
Exercise 8-5 Configuring a DHCP Server for WINS
In this exercise, you will configure the DHCP server to supply the appropriate WINS Server addressing information to DHCP Clients.
First, a server must be running DHCP. Install DHCP by following the instructions for Lab 8-1, but substitute DHCP for WINS. For this exercise to be utilized completely, the DHCP and WINS Servers must run on separate computers that are networked with a third computer configured as a DHCP Client.
Start the DHCP Server service, if it is not already running.
Note: Complete this procedure from the DHCP Server only.
Configure the DHCP Server to Assign WINS Server Addresses
In this procedure, you will configure the DHCP Server to automatically assign the WINS Server address and NetBIOS node types to DHCP Clients.
Note: Complete this procedure from the DHCP Server only.
Update the DHCP Client
In this procedure, you will renew your DHCP lease, which automatically assigns the new DHCP scope options of WINS Server addresses and node type to the client.
Note: Complete this procedure from the DHCP Client only.
When multiple WINS Servers are used, either for load sharing or redundancy, a method must be implemented to ensure that all resolution requests are handled by up-to-date databases. This method of sharing database information is known as replication. Replication can be a resource intensive operation, but there are several ways to reduce its overall impact on a network. Replication of registered names to all WINS Servers is necessary to allow resolution of names registered to different servers.
Each WINS Server will be given at least one replication partner, and be designated as either a push or pull partner. Eventually, through these partnerships, replication will occur across the entire network. Remember, networks with fe5we5r than 10,000 clients require only one WINS Server and one Backup, so all databases are accurate after one exchange. Since there is no upper limit to the number of WINS Servers, replication partners must balance the issues of accuracy, availability, server load, and network traffic usage.
This occurs when each configured WINS server initializes during startup.
Pull partners will query other WINS Servers for updates at a specified time.
Push partners will advertise updates when the threshold is reached.
The replication process is configured in WINS Manager. Each WINS Server will be assigned one or more replication partners. These partners are defined as being either a push or pull partner. A pull partner is a WINS Server that pulls in replications of database entries from its partner by requesting and then accepting the replications. A push partner is a WINS Server that sends update notification messages to its partner when its WINS database has changed. This configuration ensures that the WINS database on each server contains the names and addresses for every network computer. In larger networks, with multiple WINS Servers, one WINS Server may be defined as the Central WINS Server, and all others will be its push or pull partners.
Figure 8-11 shows the Replication Partners Box. Each WINS Server is listed by IP address, and can then be assigned as either a push or pull partner. The administrator can force replication between partners at any time by using the Replicate Now button. The Configure buttons allow the partnerships’ Replication Options to be defined.
Figure 11 WINS Manager Replication Partners Box
Once implemented, replication is a very straightforward process. One WINS Server will notify its partners of a change to its database. After the notification, the actual update will occur. The update will either be pushed to a WINS Server, or a WINS Server will pull the updates from the source WINS Server.
Each WINS Server will be either a push or pull partner. A pull partner is a WINS Server that requests new database entries from its push partners. This is done by requesting entries with a higher version number that the last entry it received during the last replication. Please note that only the new entries are updated. This reduces replication traffic on the network.
A push partner is a WINS Server that sends a message to its pull partners notifying them when its WINS database has changed. When a WINS Server’s pull partners respond to the message with a replication request, the push WINS Server sends a copy of its new database entries to the requesting partner. Again, only the changes or additions are actually replicated.
When replication is configured between two WINS Servers, it is recommended that both servers be push and pull partners of the other. The Primary and Secondary WINS Server of any network must have a push and pull relationship with each other. In general, NetBIOS names are presented as a flat namespace. Attempts to impose a hierarchy on this namespace through one-way replication schemes result in problems with name uniqueness and resolution.
Pull partners are given a set time interval to request updates, if updates are not announced by push partners. In the example shown in Figure 8-12, the pull partner will request updates every 6-½ hours, beginning at midnight. This is done by requesting entries with a higher version ID than the last entry received from a partner during the last replication. Pull partners can and should be used between sites, especially across slow WAN links, because of the ability to designate a time for the update. The update should occur at times when the WAN is least used, usually at night, to conserve network resources.
Figure 12 Pull Partner Properties
A push partner can be configured to notify its pull partners by setting the update count, or by turning on replicate on address change. The update count has a minimum value of 5. When configured to Push With Propagation, these WINS Servers will tell their pull partners when they have received changes from another source. These partners will then pull the changed entries.
The Update Count box contains the minimum number of changes that must occur before the push partner notifies its pull partners to replicate. WINS Servers that handle large numbers of name registrations when users first log on should not be configured to replicate a small number of registrations.
Notification occurs when a push partner tells its pull partner, or partners, that the database has changed, and an update is due. This notification is set to occur after a set number of changes have happened in the database, and is configured in the Push Partner Properties box (see Figure 8-13). Obviously, a smaller update count number will cause more updates. More updates lead to more accurate name resolution, but can be detrimental to overall network performance.
Figure 13 Push Partner Properties
Most changes happen when computers are started, usually when a shift begins, or after a meal break. If one WINS Server handles all these registrations, then an update is almost sure to be needed, and a notification will be sent out. As we will see, registrations are kept in the database even after being released because a name release will not propagate as fast as a name registration. This is necessary because it is common for names to be released and then reused with the same mapping as PCs are rebooted or turned off for the evening or the weekend. Replicating each of these releases would unnecessarily increase the network load of replication. If a client node crashes or is simply powered off, the registered name is not cleanly released by a NetBIOS Name Release datagram. Therefore, the presence of a name-to-address record in the WINS database does not necessarily mean that the node is running. It only means that at some reasonable time in the past, that node claimed the IP address.
After being notified, a pull partner will begin the update process by making a request from its partner. When the push partner receives a request from another WINS Server it retrieves the required records from its local database and sends them the response. It retrieves the records by seeking the record that starts the range, and then moving sequentially over the records until the last one in the range has been retrieved. When the data is received from the push partners, the pull partner updates its database.
All entries with version IDs higher than those in the pulling database get replicated. However, not every change to a database causes the version ID of a record to be incremented. Records in the WINS database contain state and ownership information. Records may be in an active, released, or extinct state. They are owned by the local database or are replicas from another WINS Server. A record is also static or dynamic.
When names are registered with a WINS Server, they are entered in the database in an active state and Time Stamped with Current Time + Renewal Interval. The version ID is taken from the version ID counter, which is then incremented. If a name is explicitly released or fails to refresh during the Renewal Interval, it enters the released state. The entry is Time Stamped with Current Time + Extinction Interval. The version ID is not changed. Therefore, records in the released state will not be replicated. If a record remains in the released state for more than the Extinction Interval, it enters the extinct state. It is Time Stamped with Current Time + Extinction Time-out, and receives a new version ID to cause it to be replicated. If a record remains in the extinct state for more than the Extinction Time-out, it is deleted from the database.
Only records in the active or extinct states are replicated. In the replica database these records are entered with the fields received from the owner database with the exception of ownership and Time Stamp. The ownership field is taken from the local IP address’ Owner ID mapping table. The ownership of the replica does not change. It means that the value used to represent a particular WINS Server differs from server to server. For example, a 2 on WINS_B and a 3 on WINS_A might represent WINS_D. An active record is Time Stamped with (local) Current Time + Verify Interval. An extinct record is Time Stamped with (local) Current Time + Extinction Time-out.
Configuring the replication process can be an important issue for networks with thousands of name registrations. Even though only changes are actually sent across the network, a large number of changes, sent to many WINS Servers, will slow down an entire network. Updates across slow links, especially WANs, should be keyed to occur when the network load is lightest, usually at night, unless the need for more current databases is required.
Due to the time differences between name registration and name release, computers that don’t change IP addresses will usually never be updated in the database. This alone reduces the need for many updates. In some cases, updating may need to occur only daily; in others, replication may be needed hourly. Each network will be unique, but the settings, which are all made in the WINS Manager, depend on network size, usage, and configuration.
Name conflicts are normally handled at the time of name registration. However, it is possible for the same name to be registered at two different WINS Servers. This could happen if the same name was registered at a second WINS Server before the database from the first WINS Server had been replicated. In this case, the conflict will be noted and resolved at replication time.
Conflicts at replication can occur between two unique entries, between a unique entry and a group entry, or between two group entries.
There are three criteria used for resolving conflicts between unique entries. The first is the state of the entries. While the database entry can be in the active, released, or extinct state, the replica can be either in the active or extinct state. An active record takes precedence over an extinct one.
Ownership of the entries is the second criteria for conflict resolution. The WINS Server may or may not own the database entry. The final criteria checked are the actual addresses of the entries. These addresses may or may not be the same.
When the conflict is between a unique entry and a group entry, the group entry is kept. Finally, if the conflict is between two group entries, the replica replaces the database record, unless the database record is active. If it is active, its version ID is incremented so that the record gets propagated at replication time. If the replica is also in the active state, the member list of the database record is updated with any members in the replica that are not already present. If the list of members in the active state grows to more than 25, the extra members are not inserted.
Exercise 8-6 Configuring WINS for Replication
In this exercise, you will configure the WINS server to perform database replication with another WINS server. To be effective, two WINS Servers are required.
Configure the WINS Client
In this procedure, you will configure the WINS client (this is necessary for the WINS Server to work correctly).
Configure WINS Replication Partners
In this procedure, you will configure another WINS Server as a replication partner.
Important: The other Server (#2) must also add your WINS Server (#1) as a replication partner, by repeating the first three steps.
Force Replication
In this procedure, you will force WINS to replicate the WINS database.
Note: If the replicated WINS database shows a version ID of 0, repeat steps 1 through 3 again to force replication.
The WINS Database is actually composed of four files (see Figure 8-14), all located in the \systemroot\system32\WINS directory. These files must not be removed or changed, except when restoring a corrupted database.
Figure 14 WINS Database Files
The WINS Database can be maintained from the WINS Manager. The ability to view the actual entries, and search for specific entries, is provided under the Mappings menu. The WINS database actually consists of two tables: the IP address - Owner ID mapping table and the Name to IP address mapping table.
The IP Address - Owner ID Mapping Table contains a row for each WINS Server that has entries in the Name to IP address mapping table. A row gives the mapping between the IP address of a WINS Server and its identifier as stored in the Owner ID. The Name to IP Address Mapping Table stores the name to IP address mappings. The entries in this table are created as a result of name registration requests received from NetBIOS over TCP/IP nodes and replicas received from other WINS Servers.
The Show Database box shows these mappings in an easy-to-read format. Each row contains the NetBIOS name, IP Address, the entry’s state, an Expiration Date and Time, and the Version ID.
Another means to look at the database is to use Winsdmp. Winsdmp is a command-line interface tool to dump a comma-separated list of the WINS database entries. This tool is part of the Windows NT Resource Kit. These are the comma-separated value fields output by Winsdmp:
As with any other system file, it is important to back up the WINS Database in case of failure or corruption. By default, NT will not back up the database;, it must be started manually the first time. Once started, backups occur every 24 hours.
To start the first backup, open the WINS Manager Mappings menu and select Back Up Database. Specify a location for the backup, and exit. The Registry entries for WINS can also be backed up. These entries are located in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WINS.
Open this key in the registry editor, regedt32, and choose Save Key from the Registry menu. Again, specify a location for the saved key.
There are two methods to restore the Database if it becomes corrupted. The first requires you to stop and restart the WINS Service. If the WINS Server detects a corrupt database, it automatically restores a backup. To restore a backup, even if the current database is not corrupt, use the Restore Database command on the WINS Manager Mappings menu. This method will allow you to choose the location of the backup to be restored.
Windows NT Server includes a utility called Jetpack, which can be used to compact a WINS or DHCP database. Microsoft recommends that you compact the WINS database whenever it approaches 30 MB. The biggest benefit of a compacted database is speed. A smaller database increases the resolution speed, the replication speed, and the backup speed.
Service must be stopped, from either Control Panel, or at the command prompt. Jetpack is then run from the command prompt using this syntax:
JETPACK.EXE <database name> <temp database name>
Figure 8-16 shows an example of how to compact the WINS database from the command prompt. In this example, tmp.mdb is a temporary database that is used by Jetpack, and wins.mdb is the WINS database.
Figure 15 Using Jetpack to Compact the WINS Database
Jetpack compacts the WINS or DHCP database by copying the database information to a temporary database file called Tmp.mdb. The original database is then deleted. The tmp.mdb database, which is a compacted version of the original, is renamed to the original filename. Jetpack creates another temporary file called temp.mdb during the compacting process. Temp.mdb is removed when the compact process is complete.
Therefore, do not specify a filename of temp.mdb on the Jetpack command line. A duplicate file error message appears if temp.mdb is used. Also, make sure you do not have a file called temp.mdb in your WINS or DHCP folder.
Microsoft Windows NT Server 4.0 WINS and DHCP Server Services have a new feature that dynamically compacts their databases. This is in addition to, and not a replacement for, the Jetpack utility. Windows NT 4.0 dynamic compacting decreases the frequency for which the Jetpack utility is needed by compacting the database as it is written.
WINS is Microsoft’s NetBIOS name server. WINS takes the place of local LMHOSTS files that can quickly become outdated and are difficult to maintain. Since DHCP dynamically distributes IP addresses, WINS is needed to resolve them. This simplifies the duties of the network administrator who no longer has tomanually update NetBIOS name mappings. Network traffic is reduced because queries are directed to the WINS Server, not broadcast.
WINS provides a method for maintaining names and resolutions within an ever-changing network. Since registrations happen dynamically, WINS is always accurate, and, via replication, several WINS Servers can be used when needed. The simple process of Request, Registration, Renewal, and Query, does not adversely affect even the largest networks. Proxies allow non-WINS Clients to gain the use of a WINS Server for name resolution.
Installation and maintenance of a WINS Server are relatively easy. Because it runs as a background service, little, if any, day-to-day upkeep is needed. After proper configuration at installation, WINS will do its job with little input required. Backups, replications, and most compressions, occur automatically. DHCP can be used to automate configuration of WINS Clients. This includes the distribution of the WINS Server IP address and Node type for name resolution.
Replication occurs between partners. Each partner, whether push or pull, can initiate the process, or the administrator can force a replication. This is the most network-intensive feature of WINS, and should be scheduled around peak network use.
The Jetpack utility, which is included with NT Server, should be used to keep the database compacted. The maximum recommended database size is 30 MB.
| A WINS Server eliminates the need for many network broadcasts, and therefore reduces network usage. |
| The WINS Server is any Windows NT Server on a TCP/IP network. |
| The WINS Server maintains a database of mappings for IP addresses to NetBIOS names. |
| A WINS Client is the machine that requests a NetBIOS mapping. |
| The LMHOSTS file contains mappings of IP addresses to NetBIOS names. Its greatest limitation is that it is a static file. |
| Remember that an LMHOSTS file is used for NetBIOS name mappings and a HOSTS file is for host name mappings. These roughly correspond to a WINS Server and a DNS Server. You need to know which file corresponds to which server. |
| WINS provides a distributed database for registering and querying dynamic NetBIOS names to IP address mappings in a routed network environment. |
| WINS provides for Point-to-Point name resolution, in that a computer requests an IP address mapping directly from the WINS Server. |
| The WINS process is relatively simple, and, when implemented properly, will not significantly affect network utilization. |
| The first step in the WINS process is the Name Registration Request. |
| It is the Client's responsibility to renew its names. |
| The real function of WINS is the Name Lookup or Name Query. |
| Once a computer registers a name, the host owns the name until it releases it. |
| Very little optimization is needed for WINS as it typically accounts for less than 1% of all network traffic. |
| Keep each of the optimization tips in mind when determining proper placement and configuration of WINS. Know which methods work best in both large and small networks. |
| For WINS to work, there must be at least one WINS Server. To provide for fault tolerance, and load sharing, two or more WINS Servers may be ideal. |
| To install the WINS Server Service, log on with Administrator privileges and open Network Properties either through the Control Panel or Network Neighborhood icon. On the Services tab, choose install Windows Internet Name Service. |
| The WINS Configuration Manager is automatically installed and added to the Administrative Tools (Common) group when WINS is installed on an NT Server. |
| A WINS Proxy Agent or Server extends the name resolution capabilities of WINS to non-WINS Clients, such as UNIX machines. |
| Proxies do not register names. They just aid in the resolution process by listening for name resolution broadcasts from non-WINS Clients. These broadcasts will not cross a router, so placement of the Proxy is critical. |
| Clients can receive this information in two ways; dynamically through DHCP or statically through TCP/IP Properties. |
| A WINS Client is any computer that requests name resolution from a WINS Server. |
| Both the primary and secondary WINS Server addresses may be input through Network Properties, under the TCP/IP Protocol, Properties Button, WINS Address tab. |
| DHCP allows its Clients to obtain IP addresses and other information upon boot up. |
| When multiple WINS Servers are used, either for load sharing or redundancy, a method must be implemented to ensure that all resolution requests are handled by up-to-date databases. This method of sharing database information is known as replication. |
| A pull partner is a WINS Server that pulls in replications of database entries from its partner by requesting and then accepting the replications. |
| A push partner is a WINS Server that sends update notification messages to its partner when its WINS database has changed. |
| Replication is the most network- intensive part of WINS. Be certain that you configure replication to occur so that it will not overwhelm the network. Slow links will definitely need to be replicated when they are least used by other network communication. |
| The WINS Database is actually composed of four files all located in the \systemroot\system32\WINS directory. |
| It is important to back up the WINS Database in case of failure or corruption. |
| Windows NT Server includes a utility called Jetpack, which can be used to compact a WINS or DHCP database. |