WINS

Windows Internet Name Service (WINS) provides a dynamic replicated database service that can register and resolve NetBIOS names to IP addresses used on your network. Windows 2000 Server provides WINS, which enables the server computer to act as a NetBIOS name server and register and resolve names for WINS-enabled client computers on your network as described in the NetBIOS over TCP/IP standards.

  • Before you begin using this computer as a WINS server, see Checklist: Installing a WINS server.
  • To find features that have been moved in Windows 2000 Server, see New ways to do familiar tasks.
  • For tips about using WINS, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


Checklist: Installing a WINS server

Step | Reference
Review WINS concepts such as NetBIOS names, WINS servers, WINS clients, and replication partners. | Understanding WINS
Verify the need to install a WINS server on your network. | When to use WINS
Review best practices for implementing WINS on your network. | Best practices
Determine the number of WINS servers you need to install and where to locate each server on your network. | Planning WINS networks
Manually configure TCP/IP properties for the WINS server computer. | To configure TCP/IP for static addressing
Install a primary WINS server. | To install a WINS server
Open the WINS console. | To open the WINS console
Modify WINS server defaults, if needed. | Modifying server defaults
Install a secondary WINS server. | To install a WINS server
Configure replication settings on both primary and secondary WINS servers. Choose among these replication partnership methods:
  • Push partner only
  • Pull partner only
  • Push/pull partner (recommended)
 Configuring WINS replication; Configure replication
View and filter the WINS database view of active registrations as needed. | View WINS records
Add and remove mappings in the WINS database as needed. | Manage static mappings; To delete or tombstone an entry in the WINS database
Backup, scavenge, and compact the WINS database regularly. | Manage the WINS database
View WINS server statistics periodically to monitor performance. | To view WINS server statistics
Update client configurations on your network to correctly specify primary/secondary WINS servers based on any WINS servers you have added.

Depending on if you configure clients statically or dynamically for TCP/IP, either:

  • Configure WINS-related settings in advanced TCP/IP properties.
  • Configure and enable WINS-related options in DHCP scopes so that IP addresses of WINS servers and NetBIOS node types are provided to clients.
 To assign a scope-based option; NetBIOS over TCP/IP options ; To configure TCP/IP for WINS
Verify registration of client NetBIOS names in WINS as needed. | To verify WINS registration of client NetBIOS names
Troubleshoot common WINS-related problems. | Troubleshooting


New ways to do familiar tasks

The following table lists common tasks for managing WINS servers and shows where you can perform these tasks in Windows 2000. For current WINS administrators, the table also shows where these tasks are performed in Windows NT version 4.0.

If you want to | In Windows NT 4.0 use | In Windows 2000 use
Install a WINS server on this computer | Network in Control Panel | Windows Components wizard. For more information, see To install a WINS server.
Start WINS management tool | Start menu shortcut to WINS Manager listed in Administrative Tools. | WINS. For more information, see To open the WINS console.
Start or stop a WINS server | Services in Control Panel | Computer Management. For more information, see To stop or start a WINS server.
Add a server to WINS management tool and manage it. | Add WINS Server option on Server menu in WINS Manager. | See To add a WINS server to the console.
Add and configure a replication partner for a WINS server. | Replication Partners option on Server menu in WINS Manager. | See To add a replication partner.


Best practices

  • Use default settings to configure WINS servers.

    The preconfigured WINS settings provide the optimal configuration for most conditions and should be used in most WINS network installations. If you modify the default settings, be sure that the need to do so is clear and necessary, and that you understand all of the implications.

  • Avoid using static WINS entries.

    Static WINS entries require further administrative action to ensure their successful and intended use. However, static entries can be useful for specific purposes, such as to safeguard against WINS registration of the names used by critically important servers.

    For example, a static entry in WINS can be used to prevent other computers from taking over the use of the name of a critical server while that server is unavailable.

    The biggest disadvantage of using static WINS entries is that it complicates administration of name and address changes in your network. For example, if either the IP address or the computer name of a static WINS entry changes, you might have to manually update other configurations also, such as DHCP servers, DNS servers, end systems, and Lmhosts files.

    If you decide to use static WINS entries, the following are suggestions for configuring other WINS and DHCP service properties and avoiding common problems:

    • For each IP address used in static WINS mapping, consider using a corresponding client address reservation to reserve the IP address at the DHCP server. For more information, see Using client reservations.

    • If you use static WINS entries only to support temporary changes on your network, keep the default Migrate On setting selected in the WINS console.

      When Migrate On is selected, any temporary unique or multihomed static entries that you add can be challenged and dynamically updated by clients. An attempt later by any client to dynamically register a unique or multihomed name entry over an existing static entry of the same name results in a challenge process.

      In the challenge, the IP address in the static mapping is compared to any IP address that the named client attempts to dynamically register in WINS. If the two addresses are different and the static IP address is determined to no longer be active or in use, the IP mapping can be migrated (from a static to dynamic mapping) and the IP address is updated in WINS.

    • If you use static WINS entries on a permanent basis, you can disable Migrate On. This prevents a dynamic WINS entry from overriding a static WINS entry that maps to the name and address of a critical server on your network.

  • Schedule consistency checking for an off-peak time.

    For Windows 2000 Server, WINS consistency checking is available through the WINS snap-in. Periodically, you should use this feature to check the WINS database for consistency. However, consistency checking is network and resource intensive for the WINS server computer. For this reason, run WINS consistency checks during times of low traffic, such as at night or on weekends.

  • Select Push/Pull when configuring replication partners.

    In general, Push/Pull is a simple and effective way to ensure full WINS replication between partners. For most WINS installations, avoid the use of limited replication partnerships (Push Only or Pull Only) between WINS servers. In some large enterprise WINS networks, limited replication partnering can effectively support replication over slow wide area network (WAN) links. However, when you plan limited WINS replication, note the design and configuration when choosing to use limited replication partnerships.

  • For best results in WINS replication and convergence, use a hub-and-spoke design model.

    Convergence is a critical part of WINS planning. To review convergence for your WINS network design, ask the following question for each of your WINS servers:

    How long does it take for a change in WINS data at one WINS server to replicate and appear at other WINS servers in the network?

    In most cases, the hub-and-spoke model provides a simple and effective planning method for organizations that require full and speedy convergence with minimal administrative intervention. For example, you can use this model for organizations with centralized headquarters or a corporate data center (the hub) and several branch offices (the spokes). A second, redundant hub (that is, a second WINS server in the central location) can increase the fault tolerance for WINS.

    For more information on how to configure a simple hub-and-spoke model, view the following graphic.

    Example of WINS replication using hub-and-spoke model

  • Use only as many WINS servers as you need.

    Too many WINS servers on a network can complicate any problems that arise. Be conservative when adding WINS servers to your network, using the least number of WINS servers to support all clients while maintaining acceptable performance from each server. If you are currently designing a WINS installation that includes more than 20 WINS servers, seek assistance from Microsoft Product Support Services before finalizing your plans.

    WINS network traffic during client registration can be much less than for DHCP, which uses client broadcasts to discover servers. By default, most WINS clients first try to communicate using directed point-to-point datagrams with their configured primary WINS servers. One WINS server adequately supports a small routed internetwork. However, at least two WINS servers are recommended, to provide a fault-tolerant WINS installation.

    For more information on WINS server planning, see Planning WINS networks.

  • To maximize server performance, purchase hardware with optimal disk performance characteristics to handle WINS.

    WINS causes frequent and intensive activity on server hard disks. To provide for the best performance, consider RAID solutions that improve disk-access time when you purchase new hardware to use as a WINS server. You should view WINS as part of a full performance evaluation of the server. By monitoring system hardware performance in the most demanding areas of utilization (that is, CPU, memory, and disk input/output) you make the best assessments of when a WINS server is overloaded and should be upgraded.

  • When using multihomed servers, follow well-known considerations for configuring WINS and TCP/IP properties.

    When using multihomed WINS servers, it is best to configure all server IP addresses as replication partners with other WINS servers. Using a multihomed WINS server as a router or gateway between disjointed networks is not recommended.

  • Monitor and perform regular, offline compaction.

    Although manual compaction of the WINS server database is not as important for Windows 2000 Server as it was for earlier versions, it is still useful. For disk defragmentation and improved server disk performance, use offline WINS compaction regularly (such as monthly or weekly). Then, monitor any changes to the size of the server database file, Wins.mdb, which is located in the systemroot\System32\WINS\ folder.

    At each offline compaction, it is useful to check the file size of Wins.mdb both before and after compaction, to measure growth and reduction. This information can be helpful in determining the actual benefits to using offline compaction. Based on this information, you can then gauge how often to repeat offline compaction for measurable gains.

  • Perform regular backups of the WINS database.

    Besides using server tape backup of the WINS server computer, the WINS console offers a backup option which you can use to restore a server database if corruption occurs. For more information, see Troubleshooting WINS databases.

  • Configure clients with more WINS server IP addresses.

    In earlier versions of Windows NT, you could manually configure clients to use only a primary and secondary WINS server. For Windows 2000, you can configure WINS clients (either manually or through DHCP) to use up to 12 WINS servers. You can either statically configure this list (using the Internet Protocol (TCP/IP) Properties dialog box) or distribute it to DHCP clients (using option 44). A larger list of WINS servers gives clients additional fault tolerance for WINS when their configured primary WINS server is not available.

  • Use NBTSTAT –RR to register and troubleshoot client connectivity.

    For Windows 2000, the NBTSTAT –RR command-line option supports purging of remote names from the local NetBIOS names cache and forces immediate renewal and re-registration of local client names. You can use this command-line option to refresh the client entries in WINS and replicate them to other replication partners without requiring a client reboot.

  • Configure each WINS server computer to point to itself.

    Each WINS server that you install on your network must register its own set of NetBIOS unique and group names in WINS. To prevent WINS service problems that can occur when a WINS record becomes split (that is, when names registered for a particular WINS server are owned by different WINS servers), each WINS server computer should point only to its own IP address when configuring its TCP/IP properties.


How to...

This section provides step-by-step instructions for working with the Windows Internet Name Service (WINS) software provided with Windows 2000 Server.

  • Install and manage WINS servers
  • Modify server properties
  • Manage WINS console data
  • Manage WINS clients
  • View WINS records
  • Manage the WINS database
  • Configure replication
  • Manage replication
  • Use persistent connections
  • Manage static mappings
  • Use WINS command-line tools


Install and manage WINS servers

  • Install a WINS server
  • Open the WINS console
  • Add a WINS server to the console
  • Remove a WINS server from the console
  • Start or stop a WINS server
  • Decommission a WINS server
  • Remove or uninstall WINS


Install a WINS server

To install a WINS server

  1. Open Windows Components wizard.
  2. Under Components, scroll to and click Networking Services.
  3. Click Details.
  4. Under Subcomponents of Networking Services, click Windows Internet Name Service (WINS), and then click OK.
  5. If prompted, type the full path to the Windows 2000 distribution files and click Continue.

    Required files are copied to your hard disk, and server software can be used after restarting the system.

Notes

  • To open the Windows Component wizard, from the desktop, click Start, point to Settings, click Control Panel.

    When Control Panel opens, double-click Add/Remove Programs, and then click Add/Remove Windows Components.

  • It is strongly recommended that you manually configure the computer to use a static IP address.
  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.

Related Topics


Open the WINS console

To open the WINS console

  • Open WINS.

Notes

  • The WINS console is an administrative tool for managing WINS servers. For more information, see Related Topics.

Related Topics


Add a WINS server to the console

To add a WINS server to the console

  1. Open WINS.
  2. In the console tree, click WINS.
  3. On the Action menu, click Add Server.
  4. In Add Server, for WINS Server type the appropriate server information.

    Optionally, click Browse to locate the WINS server computer by name on your network.

Notes

  • To configure a WINS server, you must be logged on as a member of the Administrators group for the server.
  • If WINS is locally installed on a server, the local WINS server is added to the console automatically. For remote WINS servers, you must add them to the console and then save the file.

Related Topics


Remove a WINS server from the console

To remove a WINS server from the console

  1. Open WINS.
  2. Click the WINS server that you want to remove.
  3. On the Action menu, click Delete.
  4. When prompted "Are you sure you want to remove WINS server servername from this list?," click Yes.

Notes

  • This procedure affects only the management console at which you are working, not the WINS server itself which continues to provide service and registration on the network.

Related Topics


Start or stop a WINS server

To start or stop a WINS server

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, point to All Tasks and then click one of the following:
    • To start the service, click Start.
    • To stop the service, click Stop.
    • To interrupt the service, click Pause.
    • To stop and then automatically restart the service, click Restart.

Notes

  • After you pause or stop the service, the Resume option appears and can be clicked to immediately resume WINS service.
  • You can also perform most of these tasks at a command prompt by using the following commands:
    • net start wins
    • net stop wins
    • net pause wins
    • net continue wins

Related Topics


Decommission a WINS server

To decommission a WINS server

  1. Review Important information prior to performing this procedure.
  2. Open WINS.
  3. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  4. On the Action menu, click Delete Owner.
  5. In Delete Owner, for Delete this owner, click the IP address for the WINS server you want to decommission.

    If the WINS server is not running locally on this computer, it might take awhile to load the records for the selected server.

  6. For Use this operation to delete the selected owner and its records, click Replicate deletion to other WINS servers (tombstone), and then click OK.

    When prompted to confirm tombstoning, click Yes.

  7. In the console tree, click Replication Partners.
  8. On the Action menu, click Replicate Now.
  9. Once you have verified that records tombstoned in step 6 have been replicated to other partner servers, stop and remove WINS on the decommissioned server.

Important

  • Before decommissioning a WINS server, make sure that any computers previously configured to be WINS clients of this server are reconfigured to point to other servers as their primary or secondary WINS servers. Reconfiguration is necessary only if these clients are to continue using WINS to register and resolve network names.

Notes

  • If the WINS server you want to decommission does not appear in the console tree, you can add it.
  • Tombstoning ensures that the WINS servers that are replication partners with the decommissioned WINS server are updated properly so that they release the records. If tombstone status is not properly replicated, you can manually delete the records at each WINS server on which tombstone replication failed.
  • WINS supports remote record deletion for servers running Windows NT Server 4.0, if updated to Service Pack 4 (SP4) or later.

Related Topics.


Remove or uninstall WINS

To remove or uninstall WINS

  1. Stop the WINS service on this computer.
  2. Open Add/Remove Programs.
  3. Click Add/Remove Windows Components.
  4. In Windows 2000 Components, select Networking Services from the list of components, and then click Details.
  5. In Subcomponents of Networking Services, scroll to Windows Internet Name Service (WINS) and clear the check box.

Notes

  • To open Add/Remove Programs, click Start, point to Settings, click Control Panel, and then double-click the appropriate icon.
  • When you remove WINS, all WINS files are deleted from the server except program files that are in use. When the system is restarted, these files are removed as well.
  • If you do not stop the WINS service in step 1, this procedure only deletes the WINS server registry entries.
  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.

Related Topics


Modify server properties

  • Modify backup settings
  • Modify name record settings
  • Modify WINS logging properties
  • Modify burst handling properties
  • Set the WINS database path
  • Increase the starting version count
  • Disable LAN Manager compatibility


Modify backup settings

To modify backup settings

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Properties.
  4. On the General tab, under Database backup, modify default backup settings as needed.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Note

Related Topics


Modify name record settings

To modify name record settings

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Properties.
  4. Click the Intervals tab.
  5. Modify default settings as needed.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Notes

  • For most networks the default interval settings, Renew interval, Extinction interval, Extinction timeout, and Verification interval, are acceptable and do not require modification.
  • As an option, you can click Restore Default to restore WINS default intervals used for registering, renewing, and verifying name records in the database.

Related Topics


Modify WINS logging properties

To modify WINS logging properties

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. Select the Log detailed events to Windows event log check box.

Notes

  • When Log detailed events to Windows event log is checked, WINS logs additional detailed information to the system event log, which can be viewed by using Event Viewer. Because this feature can degrade system performance when enabled, it is turned off by default.

Related Topics


Modify burst handling properties

To modify burst handling properties

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. In Enable burst handling, modify default settings as needed.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Notes

  • By default, burst handling is enabled and the burst queue sized to Medium.

Related Topics


Set the WINS database path

To set the WINS database path

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. In Database path, modify the database path as needed.

    To view a description of a dialog box item, right-click the item, and then click What's This?.

Important

  • This setting affects WINS backup and restore operations. If you change the path used here, be sure to run WINS backup again to archive the database with the updated path information. Otherwise, WINS cannot restore previously archived copies of the database where another path was specified, for either the WINS database path or the WINS database backup path.
  • This procedure describes how to set the path used by WINS to store the database on the applicable server. It does not specify the path that WINS uses when backing up the database. For more information, see Related Topics.

Note

Related Topics


Increase the starting version count

To increase the starting version count

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. For Starting version ID (hexadecimal), enter a new number to be used by WINS as the new starting version ID when WINS is next restarted.

Notes

  • Because a higher version ID is used by WINS during replication to determine between two servers storing the same record which version is more recent, increasing the starting version ID count can be useful in some cases where you are attempting to affect a forced update and replication of names between servers. For more information, see Related Topics.
  • If you enter a number that is less than the actual value of the highest version ID currently in use by the selected server, WINS might increase the actual number used for its start version count when service is restarted.

Related Topics


Disable LAN Manager compatibility

To disable LAN Manager compatibility

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Properties.
  4. Click Advanced.
  5. Clear the Use computer names that are compatible with LAN Manager check box.

Notes

Related Topics


Manage WINS console data

  • View WINS server statistics
  • Reset WINS server statistics
  • Modify auto-refresh of WINS statistics
  • Export WINS console data to a text file
  • Modify the WINS console view


View WINS server statistics

To view WINS server statistics

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Show Server Statistics.

Notes

  • To update the display while viewing WINS statistics, click Refresh.

Related Topics


Reset WINS server statistics

To reset WINS server statistics

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Show Server Statistics.
  4. Click Reset.

Notes

  • To update the display while viewing WINS statistics, click Refresh.

Related Topics


Modify auto-refresh of WINS statistics

To modify auto-refresh of WINS statistics

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Properties.
  4. Under the Automatically update statistics every check box, modify as needed the refresh interval in hours, minutes, or seconds.

Notes

  • By default, statistics automatically refresh every 10 minutes. As an option, you can also disable this feature by clearing the Automatically update statistics every check box.

Related Topics


Export WINS console data to a text file

To export WINS console data to a text file

  1. Open WINS.
  2. In the console tree, click the node item for which you want to export all currently displayed console data.

    For example, if you want to export all console data about a specific WINS server, click this server in the console tree.

  3. On the Action menu, click Export List.
  4. Enter a name for the text (*.txt) file to be used to export the output of this operation.

Note

  • For the Active Registrations node, you need to use either Find by Name or Find by Owner to load and display records for the applicable server in the console prior to performing this procedure. For more information, see Related Topics.

Related Topics


Modify the WINS console view

To modify the WINS console view

  1. Open WINS.
  2. In the console tree, click WINS.
  3. On the Action menu, click Properties.
  4. Modify console defaults to specify how WINS servers added to the console are displayed.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Notes

  • By default, the WINS console orders servers by name and uses only short (host-only) DNS names when displaying WINS servers that are added to the console. In addition, WINS does not validate its cache of WINS servers, which can prolong the length of time needed to load the WINS console when started.

Related Topics


Manage WINS clients

  • Configure WINS for non-DHCP clients
  • Configure WINS for DHCP-enabled clients
  • Disable WINS/NetBT name resolution
  • Verify WINS registration of client NetBIOS names


Configure WINS for non-DHCP clients

To configure WINS for non-DHCP clients

  • WINS servers must be manually added for each network connection that does not use DHCP. For more information, see Related Topics.

Notes

  • If you manually configure a list of WINS servers for the connection which later leases and obtains its IP address using DHCP, the list you configure supercedes any WINS servers returned in an options list provided by the DHCP server.

Related Topics


Configure WINS for DHCP-enabled clients

To configure WINS for DHCP-enabled clients

  • Windows 2000 clients are configured by default to use a DHCP server to obtain an IP address. No further client-side configuration is needed.

    Instead, configure your DHCP server to assign WINS-related option types needed to enable DHCP-enabled clients on your network to use WINS. For more information, see Related Topics.

Notes

  • In most cases, WINS clients only need to be provided the following NetBIOS over TCP/IP (NetBT) option types for basic WINS configuration: 44 (WINS servers) and 46 (WINS node type). These options must be configured at the DHCP server providing each client its dynamically leased IP address.

Related Topics


Disable WINS/NetBT name resolution

To disable WINS/NetBT name resolution

  1. Open Network and Dial-up Connections.
  2. Click the Local Area Connection to be statically configured and then, from the File menu, click Properties.
  3. In the list of components, click Internet Protocol (TCP/IP), and then click Properties.
  4. Click Advanced.
  5. Click the WINS tab.
  6. Click Disable NetBIOS over TCP/IP.

    Optionally, you can select Use NetBIOS setting from the DHCP server if you are using a DHCP server that can selectively enable and disable NetBIOS configuration through DHCP option types.

Important

  • Before you perform this procedure, refer to Migrating from WINS to DNS, the overview topic that describes the process of migrating from the use of WINS to DNS on your network.

Notes

  • NetBIOS over TCP/IP can also be disabled for computers running Windows 2000 using DHCP option types supported by the Windows 2000 DHCP Server service. For more information, see Related Topics.

Related Topics


Verify WINS registration of client NetBIOS names

To verify WINS registration of client NetBIOS names

  1. On the WINS client computer, at the command prompt, type nbtstat -n.

    The local NetBIOS names table for the WINS client computer is listed. Verify that each name indicates Registered in the Status column, such as shown in the sample command output below:

    Node IpAddress: [10.0.0.1] Scope Id: []

            NetBIOS Local Name Table

   Name               Type         Status
---------------------------------------------
BRADMA8        <20>  UNIQUE      Registered
BRADMA8        <00>  UNIQUE      Registered
WORKGROUP      <00>  GROUP       Registered
INet~Services  <1C>  GROUP       Registered
IS~BRADMA8.....<00>  UNIQUE      Registered
BRADMA8        <03>  UNIQUE      Registered
ADMINISTRATOR  <03>  UNIQUE      Registered
WORKGROUP      <1E>  GROUP       Registered
WORKGROUP      <1D>  UNIQUE      Registered
..__MYBROWSE__.<01>  GROUP       Registered

  2. The Status column should indicate a status of either Registered, Registering, or Conflict.

    For cases where the name is shown to be either Registered or Registering, you can type nbtstat -RR to release and refresh registration of the local NetBIOS names of the client with WINS.

    For cases where the Status column indicates a conflict for the name, try either of the following to resolve the conflicted name state at the client computer:

    • For Windows 2000 WINS clients, you can selectively disconnect and reconnect the network connection in the Network and Dial-up Connections folder to force release and refresh of all client NetBIOS names in WINS.

      For more information, see Related Topics.

    • For other earlier versions of Windows, shut down and restart the system to achieve similar results.
  3. After the release/refresh process is completed, repeat nbtstat -n to verify that all local names have a status of Registered in WINS.

Notes

  • For name conflicts, you may only need to perform step 2 if the name in conflict is critically necessary for the WINS client to maintain visibility or locate other computers on the network. Names that fit this description might include the [00h] and [20h] type names, if they match the client NetBIOS computer name. The need to resolve a name conflict for other types of names might be less critical to support needs.
  • The nbtstat command can also be used to perform other useful procedures related to WINS client support. For more information, see Related Topics.

Related Topics


View WINS records

  • Search for names that begin with a specified set of characters
  • Show all records in the WINS database
  • View properties for a selected WINS record
  • View or download the WINS database by owner
  • Filter the WINS database view
  • Clear all WINS data filters
  • Add, modify, or remove a filter type


Search for names that begin with a specified set of characters

To search for names that begin with a specified set of characters

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click Find by Name.
  4. In Find names beginning with, type or select a set of specific characters to be used in the search.
  5. Click Find Now to begin the search.

    WINS searches the server database and displays any names that begin with the specified characters.

Notes

  • As an option, you can click Match case to enable a case-sensitive search.

Related Topics


Show all records in the WINS database

To show all records in the WINS database

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click Find by Owner.
  4. For Display records for, click All owners, and then click OK.

    The entire WINS database appears in the details pane.

Notes

  • Loading and displaying all records for all owners in the WINS database can take a long time.

Related Topics


View properties for a selected WINS record

To view properties for a selected WINS record

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click either Find by Name or Find by Owner to display WINS records in the details pane.
    • For Find by Name, specify the leading characters for the name or names you want to view, then click Find Now.
    • For Find by Owner, click either All owners or This owner to use in displaying WINS database records, and then click OK.
  4. In the details pane, click the record that you want to view.
  5. On the Action menu, click Properties.

Notes

  • For more information on selecting a view as mentioned in step 3, see Related Topics.

Related Topics


View or download the WINS database by owner

To view or download the WINS database by owner

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click Find by Owner.
  4. Under Display records for, click This owner, and then click a selected owner from the list.

    After you click OK, the filtered WINS database appears in the details pane, showing only those records which are registered to the selected owner.

Notes

  • If the selected owner is a remote computer, a brief delay might occur.

Related Topics


Filter the WINS database view

To filter the WINS database view

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click Find by Owner.
  4. Click the Record Types tab.
  5. Clear the check box for any name record types you want excluded from filtered viewing of the WINS database.

    When you click OK, the filtered WINS database appears in the details pane.

Note

  • By default, all predefined NetBIOS name type filters are included in the filter mask. To clear all filters, click Clear all. To restore the default settings, click Select all.
  • A brief delay might occur while WINS searches the database to sort and load only the records that match the selected filter criteria.

Related Topics


Clear all WINS data filters

To clear all WINS data filters

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click Find by Owner.
  4. Click the Record Types tab.
  5. Click Clear all.

Note

  • By default, all predefined NetBIOS name type filters are included in the filter mask. To restore the default settings, click Select all.

Related Topics


Add, modify, or remove a filter type

To add, modify, or remove a filter type

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click Find by Owner.
  4. Click the Record Types tab.
  5. Click either Add, Edit, or Delete to add, modify, or remove name type filters.
  6. When adding a new filter type, click Add and complete the following for Add Record Type:
    • For ID (hexadecimal), specify a unique 2-digit hexadecimal number that can be used to identify a distinct set of records in the WINS database.
    • For Description, enter descriptive text that indicates how the new filter type is to be used.

Notes

  • Only user-defined filters can be modified or deleted. Pre-defined filters provided for default use by WINS cannot be modified or deleted.

Related Topics


Manage the WINS database

  • Scavenge the WINS database
  • Backup the WINS database
  • Restore the WINS database
  • Delete or tombstone an entry in the WINS database
  • Delete an owner from the WINS database
  • Enable periodic consistency checking of the WINS database
  • Manually check database consistency
  • Check version number consistency between servers


Scavenge the WINS database

To scavenge the WINS database

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Scavenge Database.

Notes

  • Like other databases, you must periodically maintain the WINS database to remove outdated information. This process is called scavenging, which removes old and released entries that were registered at another WINS server and replicated to the server being maintained.
  • WINS automatically scavenges the server database at intervals you specify in server properties.

Related Topics


Backup the WINS database

To backup the WINS database

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Backup Database.
  4. When prompted to confirm, click Yes. After backup is completed, click OK.

Important

  • Do not specify a network drive as the backup location. In addition, if you change the WINS backup or database path in server properties, perform new backups to ensure successful future restorations of the WINS database.

Notes

  • The WINS console provides backup tools so that you can back up and restore the WINS database. After you specify a backup folder for the database, WINS performs complete database backups every three hours, using the specified folder.
  • WINS can also be configured to backup the database automatically when the service is stopped or the server computer shut down. For more information, see Related Topics.
  • When WINS backs up the server database, it creates a \Wins_bak\New folder under the backup folder you have have specified for Default backup path in server Properties. Actual backups of the WINS database (Wins.mdb) are stored in this folder. By default, the backup path is the root folder on your system partition, such as C:\.

Related Topics


Restore the WINS database

To restore the WINS database

  1. Stop WINS.

    For more information, see Related Topics.

  2. Delete all files in the folder path on the WINS server computer where you are restoring the database.

    This path is determined by the current setting of Database path, which is located on the Advanced tab in server Properties.

  3. Open WINS.
  4. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  5. On the Action menu, click Restore Database.
  6. In the Browse for Folder dialog box, click the same folder (such as C:\) that was used previously to backup the local WINS database, and then click OK.

Notes

  • In step 1, wait for WINS to completely stop before proceeding. A busy server might require several minutes before it can stop WINS and you can proceed with restoring the database.
  • When restoring the database, WINS requires that the backup path used for restoration match the path that was originally specified in server Properties as the Backup path. By default, this path is the root folder on the system partition. If you specify a different path, be sure to use that same path in step 6.
  • WINS does not permit you to restore the server databases remotely from another computer.
  • The restore option is only available when viewing a computer on which WINS is stopped. In some cases, you might need to refresh the WINS console to activate the restore option. If necessary, click Refresh from the Action menu to refresh the server node so that the WINS console detects that WINS is stopped on the server.
  • In case of database corruption, the WINS database can be restored from the backup. You can sometimes repair WINS database corruption by incrementing the starting version count for the WINS server and restarting the server.

Related Topics


Delete or tombstone an entry in the WINS database

To delete or tombstone an entry in the WINS database

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click either Find by Name or Find by Owner to display the names you want to delete from the database.
  4. In the details pane, click the entry you want to delete.

    You can hold down the CTRL or SHIFT keys to select multiple entries.

  5. On the Action menu, click Delete.
  6. In the Delete Record dialog box, click one of the following options for deleting the selected records:
    • Delete the record only from this server.
    • Replicate deletion of the record to other servers (tombstone).

Notes

  • Tombstoning marks records as inactive for a period of time. When the WINS database on this server replicates these records to other WINS servers, the other servers preserve the tombstone state and can eventually remove these entries from a replicated WINS network of server databases.
  • In step 6, if you click Delete the record only from this server and another WINS server owns the records, then deleted records can reappear after WINS replication occurs with other partner servers. To avoid this, click Replicate deletion of the record to other servers (tombstone).
  • Once an entry has been tombstoned and its status is replicated to other servers, the tombstoned entries can be removed from WINS, in either of two ways:
    • Automatically, using the Extinction Interval, which is set from the Intervals tab in WINS server properties.
    • Manually, by performing a scavenging operation.

Related Topics


Delete an owner from the WINS database

To delete an owner from the WINS database

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click Delete Owner.
  4. In Delete Owner, click the the owner you want to delete.
  5. Select from the following options for deleting records in the WINS database associated with the owner you are deleting:
    • To delete the owner and all of its records from this WINS server only, click Delete from this server only.
    • To replicate deletion of the selected owner and all its records at this and other WINS servers, click Replicate deletion to other servers (tombstone).

Notes

  • Tombstoning marks records as inactive for a period of time. When the WINS database on this server replicates these records to other WINS servers, the other servers preserve the tombstone state and can eventually remove these entries from a replicated WINS network of server databases.
  • In step 5, if you click Delete from this server only, records first introduced by the deleted owner can reappear after WINS replication with other partner servers that have replicated these records. To avoid this, click Replicate deletion to other servers (tombstone).
  • Once an entry has been tombstoned and its status is replicated to other servers, the tombstoned entries can be removed from WINS, in either of two ways:
    • Automatically, using the Extinction Interval, which is set from the Intervals tab in WINS server properties.
    • Manually, by performing a scavenging operation.

    For more information, see Related Topics.

Related Topics


Enable periodic consistency checking of the WINS database

To enable periodic consistency checking of the WINS database

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Properties.
  4. Click the Database Verification tab.
  5. In Database Verification settings, select the Verify database consistency every number of hours hours check box.
  6. If necessary, modify default settings to be used when consistency checks are performed.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Notes

  • Because consistency checking might affect WINS server performance, this feature is not enabled by default.
  • When enabled, the default settings for this feature provide for up to 30,000 records in the WINS server database to be checked on a daily basis, beginning at 2:00AM each night. During each of these scheduled consistency checks, the selected WINS server compares local copies of records it stores with the same record as stored at the WINS server listed as the owner for each record.

Related Topics


Manually check database consistency

To manually check database consistency

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Check Database Consistency.
  4. When prompted if you want to continue, click Yes to start consistency checking.

Notes

  • Checking consistency can be resource-intensive when there is a large number of names to be checked or a large number of WINS servers involved. You might want to perform this only during off-peak hours to minimize the impact on your WINS servers and network.
  • Consistency checking can also be scheduled through server properties. For more information, see Related Topics.

Related Topics


Check version number consistency between servers

To check version number consistency between servers

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click Check Version Number Consistency.
  4. When prompted if you want to continue, click Yes to start this operation.

Notes

  • This operation gets the Owner-to-Highest-Version-ID mappings from different WINS servers. It checks the consistency of the WINS databases at all tested servers by ensuring that each server always has the highest version ID among the network of WINS servers for any records that it owns.
  • Checking version ID number consistency can be resource-intensive when there are a large number of WINS servers tested.

Related Topics


Configure replication

  • Add a replication partner
  • Delete a replication partner
  • Enable replication with non-partner WINS servers
  • Modify push partner properties
  • Modify pull partner properties
  • Enable automatic partner configuration


Add a replication partner

To add a replication partner

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click New Replication Partner.
  4. In New Replication Partner, type the name or IP address of the WINS server to add as a replication partner.

Notes

  • By default, replication partners are configured as push/pull type partners. Once you have added a partner, however, you can change it to be a Push only or Pull only type partner. For more information, see Related Topics.

Related Topics


Delete a replication partner

To delete a replication partner

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. In the details pane, click the replication partner you want to remove.
  4. On the Action menu, click Delete.
  5. When prompted, click Yes to confirm that you want to delete the partner.

Note

Related Topics


Enable replication with non-partner WINS servers

To enable replication with non-partner WINS servers

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click Properties.
  4. Clear the Replicate only with partners check box, and then click Apply.

Notes

  • By default, WINS only replicates with other WINS servers configured as replication partners.

Related Topics


Modify push partner properties

To modify push partner properties

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click Properties.
  4. Click the Push Replication tab.
  5. As needed, reconfigure push partner defaults to be used by this server when it performs replication with any of its newly added push partners.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Note

Related Topics


Modify pull partner properties

To modify pull partner properties

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click Properties.
  4. Click the Pull Replication tab.
  5. As needed, reconfigure pull partner defaults to be used by this server when it performs replication with any of its newly added pull partners.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Note

Related Topics


Enable automatic partner configuration

To enable automatic partner configuration

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. Select the Enable automatic partner configuration check box.
  6. If necessary, modify the multicast interval and multicast Time-to-Live (TTL) parameters to be used by this server when automatic partner configuration is enabled for use by WINS.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Note

Related Topics


Manage replication

  • Start replication immediately
  • Send a replication trigger to a selected partner
  • Send a replication trigger to any specified WINS server
  • Block replication of records owned by a specified server
  • Change a replication partner type


Start replication immediately

To start replication immediately

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click Replicate Now.
  4. When prompted, click Yes to start replication immediately.

Note

  • This operation queues replication requests for triggering replication with any of its push and pull partner servers. For this operation to have any affect, replication partners must already be added at this server.
  • Using Event Viewer, you can monitor the system event log at this server for more information about the status of when actual replication is completed between this server and its partner servers.

Related Topics


Send a replication trigger to a selected partner

To send a replication trigger to a selected partner

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. In the details pane, click the partner that you want to start replication with.
  4. On the Action menu, click either Start Push Replication or Start Pull Replication depending on whether you want to start push or pull replication to the selected partner.
  5. Confirm starting of either push or pull replication to the selected partner:
    • If using pull replication, in Start Pull Replication, click Yes to confirm.
    • If using push replication, in Start Push Replication, choose a push replication method, and then click OK:
      1. Click Start for this partner only to start push replication for the selected partner only.
      2. Click Propagate to all partners to request that the selected partner in turn propagate a push replication request to its configured partners.

Notes

  • When this procedure is completed, replication with the partner server might not start immediately. Actual replication depends on server activity and the priority of other requests queued at the selected partner.
  • By default, WINS only enables replication between configured replication partners. To replicate with non-partners, see Related Topics.
  • When a push replication is started using this procedure, actual replication requires the selected partner to complete a subsequent pull replication. This occurs because WINS replication is essentially a pull operation. For more examples and information, see Related Topics.

Related Topics


Send a replication trigger to any specified WINS server

To send a replication trigger to any specified WINS server

  1. Open WINS.
  2. In the console tree, click the applicable WINS server.

    Where?

    • WINS
    • applicable WINS server
  3. On the Action menu, click either Start Push Replication or Start Pull Replication.
  4. In Start Replication, for WINS server, type or browse for the specified WINS server with which you want to start replication, and then click OK.
  5. Confirm starting of either push or pull replication:
    • If using pull replication, in Start Pull Replication, click Yes to confirm.
    • If using push replication, in Start Push Replication, choose a push replication method, and then click OK:
      1. Click Start for this partner only to start push replication for the selected server only.
      2. Click Propagate to all partners to request that the selected server in turn propagate a push replication request to its configured partners.

Notes

  • By default, WINS only enables replication between configured replication partners. To use this procedure, first configure the server to enable it to replicate with non-partners. For more information, see Related Topics.
  • When this procedure is completed, replication with the specified server might not start immediately. Actual replication depends on server activity and the priority of other requests queued at the server.
  • When a push replication request is started using this procedure, actual replication requires the specified WINS server to complete a subsequent pull replication. This occurs because WINS replication is essentially a pull operation. For more examples and information, see Related Topics.

Related Topics


Block replication of records owned by a specified server

To block replication of records owned by a specified server

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. Click Add.
  6. In Add Server, enter the NetBIOS name or IP address of the owner (a WINS server) that you want to block any of its records from being replicated to this server.

Notes

  • Once a server has been added to the list of blocked partners, any records shown to be owned by the listed servers are not entered into the local database of this server during subsequent replication cycles with other partner servers.
  • This feature was previously implemented as a registry-only configuration in Windows NT Server, using the PersonaNonGrata registry parameter.

Related Topics


Change a replication partner type

To change a replication partner type

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. In the details pane, click the partner at which you want to change the type of replication it uses with the applicable WINS server.
  4. On the Action menu, click Properties.
  5. Click the Advanced tab.
  6. For Replication partner type, select a new type such as Push, Pull, or Push/Pull.

Note

Related Topics


Use Persistent Connections

  • Enable the use of persistent connections with a partner server
  • Enable the use of persistent connections with pull partners
  • Enable the use of persistent connections with push partners


Enable the use of persistent connections with a partner server

To enable the use of persistent connections with a partner server

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. In the details pane, click the partner server for which you want to enable the use of persistent connections for replication purposes.
  4. On the Action menu, click Properties.
  5. Click the Advanced tab.
  6. Select the appropriate Use persistent connection for replication check box, depending on whether the partner server is a Push, Pull, or Push/Pull partner of this server.

Notes

  • In step 6, if the partner is configured as a Push/Pull partner of this server, you can select both Use persistent connection for replication check boxes.

Related Topics


Enable the use of persistent connections with pull partners

To enable the use of persistent connections with pull partners

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click Properties.
  4. Click the Pull Replication tab.
  5. Select the Use persistent connections for pull replication partners check box.

Notes

Related Topics


Enable the use of persistent connections with push partners

To enable the use of persistent connections with push partners

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click Properties.
  4. Click the Push Replication tab.
  5. Select the Use persistent connections for push replication partners check box.

Notes

Related Topics


Manage static mappings

  • Add a static mapping entry
  • Edit a static mapping entry
  • Import a file containing static mapping entries
  • Enable static mappings to be overwritten during replication


Add a static mapping entry

To add a static mapping entry

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click New Static Mapping.

    The New Static Mapping dialog box appears.

  4. Enter the following information to complete the static mapping:

    • In Computer name, type the NetBIOS name of the computer.
    • In NetBIOS scope (optional), you can type a NetBIOS scope identifier, if one is used, for the computer. Otherwise, leave this field blank.
    • In Type, click one of the supported types to indicate whether this entry is a Unique, Group, Domain Name, Internet, or Multihomed type entry.
    • In IP address, type the address for the computer.
  5. Click Apply to add the static mapping entry to the database.

    Or, you can add additional static mapping entries. Click Apply each time you complete an entry, and then click Cancel to close when you finish adding static mapping entries.

Important

  • Because each static mapping is added to the database when you click Add, you cannot cancel work in the dialog box. If you make a mistake when entering a name or address for a mapping, delete the errored mapping and add a new one using the correct information.

Notes

  • In general, only use static WINS mappings for computer names (not group names) that do not directly use WINS to register their names. Static mappings can overwrite dynamic mappings at other WINS servers and can be increasingly difficult to remove from all servers once they are introduced into a replicated WINS environment.

Related Topics


Edit a static mapping entry

To edit a static mapping entry

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. In the details pane, double-click the static mapping you want to edit.
  4. Edit the following information for the existing static mapping, as needed:
    • For IP Address, you can change the address or, for supported types, you can add or remove addresses from the address list and change the order of addresses.

Notes

  • Only the IP address for an entry can be edited. To change other properties for an entry, you must delete the existing entry and add a new entry.

Related Topics


Import a file containing static mapping entries

To import a file containing static mapping entries

  1. Open WINS.
  2. In the console tree, click Active Registrations.

    Where?

    • WINS
    • applicable WINS server
    • Active Registrations
  3. On the Action menu, click Import LMHOSTS File.
  4. In the Open dialog box, locate and click the Lmhosts-formatted file that you want to use to import static mappings, and then click Open.

    WINS immediately begins importing the file into the server database. Wait for WINS to finish this before you click OK.

Notes

  • Typically, the Lmhosts file is stored in the systemroot\System32\Drivers\Etc folder.

Related Topics


Enable static mappings to be overwritten during replication

To enable static mappings to be overwritten during replication

  1. Open WINS.
  2. In the console tree, click Replication Partners.

    Where?

    • WINS
    • applicable WINS server
    • Replication Partners
  3. On the Action menu, click Properties.
  4. If needed, click the General tab.
  5. Select the Overwrite unique static mappings at this server (migrate on) check box, and then click Apply.

Notes

Related Topics


Use WINS command-line tools

  • Optimize the command prompt for use with command-line tools
  • Use WINS commands interactively at the command prompt
  • Use WINS commands non-interactively or in scripts


Optimize the command prompt for use with command-line tools

To optimize the command prompt for use with command-line tools

  1. Open Command Prompt.
  2. Click the upper left corner of the command prompt window and then click Properties.
  3. Click the Options tab.
  4. Modify command prompt options.

    For command history, increase Buffer Size to 500 and Number of Buffers to 5. Under edit options, click Quick Edit Mode and Insert Mode.

  5. Click the Layout tab.
  6. Increase Screen Buffer Size to 2500.
  7. Click OK to apply changes.

    When prompted, select Modify shortcut that started this window.

Notes

  • To open Command Prompt, click Start, point to Programs, and then click Command Prompt.
  • As a keyboard option for step 2, access Command Prompt Properties by doing the following: press the ALT key and the spacebar at the same time, then press "P" to select Properties.
  • By optimizing the command prompt window using this procedure, you can use Windows Explorer features, such as scrolling, and quickly mark, copy, and paste to and from the command prompt window. By increasing the screen buffer size, you can scroll back to previous command output and more easily view command-line help text.

Related Topics


Use WINS commands interactively at the command prompt

To use WINS commands interactively at the command prompt

  1. Open Command Prompt.
  2. Type netsh.
  3. At the netsh> (Net Shell) command prompt , type wins.
  4. At the wins> (WINS helper) command prompt , type either server \\servername or server ip_address for the server you want to manage.

    Once a server that you have rights to manage has been successfully contacted, you should see "You have Read and Write access to the server servername"

  5. Once you are connected to this WINS server, you can use any supported command.

    Type /? or help to display the immediate WINS subcommand menu. Or, type list to display all NetShell subcommands available for use with WINS.

Notes

  • To open Command Prompt, click Start, point to Programs, and then click Command Prompt.
  • In order to have administrative rights to manage a WINS server, you must be logged on with a user account that has membership in the local WINS Users group. For Windows NT Server, you must belong to the local Administrator group on the server.

Related Topics


Use WINS commands non-interactively or in scripts

To use WINS commands non-interactively or in scripts

  1. Open Command Prompt.
  2. At the command prompt or in scripted form, you can use NetShell commands for WINS non-interactively by using the following fully-qualified command syntax:

    netsh wins server [\\servername] subcommand.

Notes

  • To open Command Prompt, click Start, point to Programs, and then click Command Prompt.
  • The \\servername parameter is optional when performing WINS commands locally on the same computer where the command is executed. If the WINS server being managed is on a remote computer, this parameter is required and the remote server name must be used.
  • In order to have administrative rights to manage a WINS server, you must be logged on with a user account that has membership in the local WINS Users group. For Windows NT Server, you must belong to the local Administrator group on that server.

Related Topics


Concepts

This section provides general background information about Windows Internet Name Service (WINS) and NetBIOS over TCP/IP (NetBT) support provided by Microsoft Windows operating systems.

  • WINS overview
  • Understanding WINS
  • Using WINS
  • Resources


WINS overview

  • WINS defined
  • Benefits of using WINS
  • When to use WINS
  • How WINS works
  • WINS tools
  • New features


WINS defined

Windows Internet Name Service (WINS) provides a distributed database for registering and querying dynamic mappings of NetBIOS names for computers and groups used on your network. WINS maps NetBIOS names to IP addresses and was designed to solve the problems arising from NetBIOS name resolution in routed environments. WINS is the best choice for NetBIOS name resolution in routed networks that use NetBIOS over TCP/IP.

NetBIOS names are used by earlier versions of Microsoft operating systems to identify and locate computers and other shared or grouped resources needed to register or resolve names for use on the network.

NetBIOS names are a requirement for establishing networking services in earlier versions of Microsoft operating systems. Although the NetBIOS naming protocol can be used with network protocols other than TCP/IP (such as NetBEUI or IPX/SPX), WINS was designed specifically to support NetBIOS over TCP/IP (NetBT).

WINS simplifies managing the NetBIOS namespace in TCP/IP-based networks. The following illustration shows a typical series of events involving WINS clients and servers.

WINS exemplified

In this example, the following occurs:

  1. A WINS client, HOST-A, registers any of its local NetBIOS names with WINS-A, its configured WINS server.
  2. Another WINS client, HOST-B, queries WINS-A to locate the IP address for HOST-A on the network.
  3. WINS-A replies with the IP address for HOST-A, 192.168.1.20.

WINS reduces the use of local IP broadcasts for NetBIOS name resolution and enables users to locate systems on remote networks easily. Because WINS registrations are done automatically each time clients start and join the network, the WINS database is automatically updated when dynamic address configuration changes are made. For example, when a DHCP server issues a new or changed IP address to a WINS-enabled client computer, WINS information for the client is updated. This requires no manual changes to be made by either a user or network administrator.

Notes

  • The WINS protocol is based on and is compatible with the protocols defined for NetBIOS name service specified in RFCs 1001 and 1002, so it is interoperable with any other implementations of these RFCs. For more information, see WINS RFCs.
  • In order to more fully understand WINS, knowledge of the history and need for NetBIOS naming is helpful. For more general background information, see NetBIOS over TCP/IP (NetBT) concepts.
  • Replication of NetBIOS names data in WINS is Microsoft proprietary technology and is not interoperable with other NetBIOS name servers.


Benefits of using WINS

WINS provides the following benefits for administering your TCP/IP-based network:

  • A dynamic name-to-address database that maintains support for computer name registration and resolution.
  • Centralized management of the name-to-address database, alleviating the need for managing Lmhosts files.
  • Reduction of NetBIOS-based broadcast traffic on subnets, by permitting clients to query WINS servers to directly locate remote systems.
  • Support for earlier Windows and NetBIOS-based clients on your network, permitting these types of clients to browse lists for remote Windows domains without requiring a local domain controller to be present on each subnet.
  • Support for DNS-based clients by enabling those clients to locate NetBIOS resources when WINS lookup integration is implemented.


When to use WINS

For networks with servers running Windows 2000 Server and all other computers running Windows 2000 Professional, NetBIOS is no longer required for TCP/IP-based networking. Because of this change, WINS is needed for most networks but might not be required in some instances. When deciding whether you need to use WINS, you should first consider the following questions:

  • Do I have any legacy computers on my network that require the use of NetBIOS names?

    Remember that all networked computers that run under any previously released Microsoft operating system, such as versions of MS-DOS, Windows, or Windows NT, require NetBIOS names support. Windows 2000 is the first Microsoft operating system that no longer requires NetBIOS naming. Therefore, NetBIOS names can still be required on your network to provide basic file and print services and support for many legacy applications used.

  • Are all computers on my network configured and able to support the use of another type of network naming, such as DNS?

    Network naming is still a vital service for locating computers and resources throughout your network, even when NetBIOS names are not required. Before you decide to eliminate WINS or NetBIOS names support, be sure that all computers and programs on your network are able to function using another naming service, such as DNS.

    In general, Windows operating systems support two major methods of performing network name resolution. These are:

    • Host name resolution. This is Windows sockets-based name resolution which implements the gethostbyname () API to search for a host IP address based on a queried host name. This method relies on either a Hosts file or querying DNS to perform resolution of the name.
    • NetBIOS name resolution. This is name resolution that uses the NetBIOS redirector to search for an address based on a queried NetBIOS name. This method relies on either an Lmhosts file or querying WINS to perform resolution of the name.

    WINS clients running under Windows 2000 are configured by default to first use DNS to resolve names that are longer than 15 characters or that make use of periods (".") within the name. For names that are less than 15 characters and do not use periods, DNS is also used again as a final option after a WINS query fails if the client is configured to use a DNS server.

    If you are running either a pure Windows 2000 environment, review that DNS is currently configured and can be used by all client computers on your network to resolve names. If you run a mixed environment of computers running under Windows 2000 and other platforms (such as UNIX), confirm that these other hosts can rely on using only DNS for host name resolution.

  • Is your network a single subnet or routed with multiple subnets?

    If your entire network is made up of a single small local area network (LAN) that occupies one physical network segment and has less than 50 clients, you can probably do without a WINS server. All computers that run under Windows 2000--and most earlier Microsoft-based WINS clients--are are configured as hybrid node (h-node) type clients and can use either of the following methods to handle NetBIOS requests to resolve or register names:

    • Direct (point-to-point) contact with a WINS server, if one is configured.
    • Broadcast of the NetBIOS request to the local subnet.

    For small networks, the latter option is typically an effective and simple solution for providing NetBIOS name service to a small number of LAN-based clients.

Note

  • To provide for the full use of DNS query as it is described in this section and used in the NetBIOS name resolution process for Windows 2000, you can selectively enable the Enable DNS For WINS Resolution for some earlier Windows-based clients, such as Windows 95 or Windows NT 4.0 client computers that support this option as a configurable TCP/IP property setting.


How WINS works

By default, when a computer running Windows 2000 is configured with WINS server addresses (either manually or through DHCP) for its name resolution, it adheres to using hybrid node (h-node) as its node type for NetBIOS name registration unless another NetBIOS node type is configured. For NetBIOS name query and resolution, it also adheres to h-node behavior, but with a few differences.

For NetBIOS name resolution, WINS client typically performs the following general sequence of steps to resolve a name:

  1. Client checks to see if the name queried is its local NetBIOS computer name, which it owns.
  2. Client checks its local NetBIOS name cache of remote names. Any name resolved for a remote client is placed in this cache where it remains for 10 minutes.
  3. Client forwards the NetBIOS query to its configured primary WINS server. If the primary WINS server fails to answer the query--either because it is not available or because it does not have an entry for the name--the client will try to contact other configured WINS servers in the order they are listed and configured for its use.
  4. Client broadcasts the NetBIOS query to the local subnet.
  5. Client checks the Lmhosts file for a match to the query, if it is configured to use the Lmhosts file.
  6. Client tries the Hosts file and then a DNS server, if it is configured for one.

Note

  • For a more detailed description of the default NetBIOS name resolution process as it is performed by computers running Windows 2000, see Resolving names.


WINS tools

The primary tool that you use to manage WINS servers is the WINS console, which is added to the Administrative Tools when you install WINS. For Windows 2000 Server, the WINS console works within the Microsoft Management Console (MMC), to further integrate WINS administration into your total network management.

After you install a WINS server, you can use the WINS console to perform these basic server administrative tasks:

  1. View and filter NetBIOS name registrations stored at the WINS server for client names used on your network.
  2. Add and configure replication partners for the WINS server.
  3. Perform maintenance-related tasks, including backup, restoration, compaction, and scavenging, on the WINS server database.

In addition, you can also use the WINS console to perform the following optional or advanced setup tasks:

  • View and modify WINS properties, such as the Renew Interval and other intervals that are used when registering, renewing, and verifying name records stored in the server database.
  • Add and configure static WINS mappings, if they are needed for use on your network.
  • Delete or tombstone WINS records that appear in WINS server data used throughout your network.

Notes

  • Windows 2000 Server includes many new features beyond those provided in earlier versions. For more information, see New features.
  • The WINS console provides new ways to perform familiar WINS administrative tasks previously performed in Windows NT Server 4.0 using WINS Manager. For more information, see New ways to do familiar tasks.
  • For Windows 2000 Server, WINS administration can also be performed using command-line based tools. For more information, see Netshell commands for WINS or Use WINS command-line tools.


New features

For Windows 2000, WINS provides the following feature enhancements:

  • Persistent connections

    You can now configure each WINS server to maintain a persistent connection with one or more replication partners. This increases the speed of replication and eliminates the overhead of opening and terminating connections. For more information, see Persistent connections.

  • Manual tombstoning

    You can manually mark a record for eventual deletion (tombstoning). The tombstone state of the record replicates to other WINS servers, preventing any replicated copies of the deleted records from re-appearing at the same server where they were originally deleted. For more information, see Deleting and tombstoning records.

  • Improved management utility

    The WINS console is fully integrated with the Microsoft Management Console (MMC), a powerful and more user-friendly environment you can customize for your efficiency. Because all server administrative utilities included for your use in Windows 2000 Server are part of MMC, new MMC-based utilities are easier to use as they operate more predictably and follow a common design.

  • Improved ease of use for both using and managing advanced WINS features

    Several useful WINS features from earlier versions of Windows NT Server that were only configurable through the registry are now more directly usable. These include the ability to block records by a specific owner or WINS replication partner (formerly known as Persona Non Grata), or allow override of static mappings (formerly known as Migrate On/Off). For more information, see either Blocking replication partners or Using static mappings.

  • Enhanced filtering and record searching

    Improved filtering and new search functions help you locate records by showing only those records that fit the criteria you specify. These functions are particularly useful in analyzing very large WINS databases.

  • Dynamic record deletion and multi-select

    These features help you more easily manage the WINS database. With the WINS snap-in, you can simply point, click, and delete either one or more WINS static or dynamic-type entries. Previously, this functionality was only available when using command-based utilities, such as Winscl.exe, designed for earlier versions of WINS. It is also possible now to delete records that use names based on non-alphanumeric characters.

  • Record verification and version number validation

    These features quickly check the consistency of names stored and replicated on your WINS servers. Record verification compares the IP addresses returned by a NetBIOS name query of different WINS servers. Version number validation examines the owner address-to-version number mapping tables. For more information, see Checking the WINS database for consistency.

  • Export function

    When you export, you place WINS data in a comma-delimited text file. You can export this file to Microsoft Excel, reporting tools, scripting programs, or similar programs for analysis and reporting. For more information, see To export WINS console data to a text file.

  • Increased fault tolerance for clients

    Clients running Windows 2000 or Windows 98 can specify more than two WINS servers (up to a maximum of 12 addresses) per interface. The extra WINS server addresses are used only if the primary and secondary WINS servers fail to respond. WINS clients also benefit from the use of burst handling, which is enabled by default. For more information, see Primary/secondary WINS servers and Burst handling.

  • Dynamic re-insertion of client names

    WINS clients no longer have to be restarted after they use WINS to force re-insertion and update of local NetBIOS names. The Nbstat command includes a new option, -RR, which provides this functionality. If WINS clients are running Windows NT 4.0, updated to Service Pack 4 or later, the -RR option can also be used with those clients. For more information, see To verify WINS registration of client NetBIOS names.

  • Read-only console access to the WINS console.

    This feature provides a special purpose local users group, the WINS Users group, which is automatically added when WINS is installed. By adding members to this group, you can provide read-only access in the WINS console to WINS-related information on this server computer for users that are not administrators. You can allow a user in this group to view, but not modify, information and properties stored at a specific WINS server. For more information, see Using Local Users and Groups.

  • Command-line administration of WINS servers.

    In addition to a full graphical user interface for managing WINS servers, Windows 2000 Server provides a fully equivalent WINS command-line based tool. For more information, see Netshell commands for WINS.

  • Improved database engine.

    WINS uses the same performance-enhanced database engine technology that is also used in Active Directory.


Understanding WINS

  • NetBIOS over TCP/IP (NetBT) concepts
  • Locating network services
  • WINS components
  • WINS replication
  • WINS resolution
  • WINS features


NetBIOS over TCP/IP (NetBT) concepts

  • Background on NetBIOS
  • NetBIOS names
  • Disabling NetBIOS over TCP/IP
  • Lmhosts files


Background on NetBIOS

The NetBIOS interface was first developed by Sytec Inc. (currently Hughes LAN Systems) for the International Business Machines Corporation (IBM) in 1983. It operated over proprietary Sytec protocols on IBM's PC Network, an early form of broadband LAN technology that accommodated up to a maximum of 72 connected devices. From its early origins, it is important to emphasize that NetBIOS was never originally designed to scale and grow into use in large networks.

At Microsoft, NetBIOS started as a high-level programming language interface for MS-DOS programs used to network IBM PC-compatible microcomputers introduced during the late 1980s. To build LANs based on the networking hardware and software available for those computers, Microsoft and other vendors standardized on using the NetBIOS interface to design their networking system components and programs. This interface uses single-part names, which are limited to 16 characters in length to identify each network resource.

The NetBIOS namespace is flat, meaning that names can be used only once within a network. These names are dynamically registered when computers start up, services start, or users log on. NetBIOS names can be registered as unique or as group names. Unique names have one address associated with a name. Group names have more than one address mapped to a name.

Prior to Windows 2000, all MS-DOS and Windows-based operating systems required the NetBIOS naming interface to support network capabilities. With the release of Windows 2000, support for the NetBIOS naming interface is no longer required for networking computers. For example, an environment consisting of host computers and programs that support the use of the Domain Name System (DNS) could be built to run using Windows 2000 and other operating systems not requiring NetBIOS names, such as some versions of UNIX. However, most networks still need to integrate legacy operating systems that require NetBIOS network names with computers running Windows 2000.

For this reason, Microsoft has continued with Windows 2000 to provide default support for NetBIOS names to ease interoperability with legacy operating systems that require their use. This support is provided mainly in two ways:

  • By default, all Windows 2000 computers that use TCP/IP are enabled by default to provide client-side support for registering and resolving NetBIOS names.

    This support is provided through NetBIOS over TCP/IP (NetBT) and can, if desired, be manually disabled. For more information, see Disabling NetBIOS over TCP/IP.

  • Windows 2000 Server continues to provide server-side support through Windows Internet Name Service (WINS). WINS can be used to effectively manage NetBT-based networks.


NetBIOS names

A NetBIOS name contains 16 bytes. The first 15 bytes of each name are user-specified indicating either:

  • a unique name identifying a resource associated with a single user or computer on the network.
  • a group name identifying a resource associated with a group or collection of users or computers on the network.

The 16th character in each NetBIOS name is used by Microsoft NetBIOS clients as a name suffix to identify the name and indicate information about the resource that the name is being used to register on the network. Each NetBIOS name is configured as either a unique (exclusive) or group (non-exclusive) name.

Unique names are typically used to send network communications to a specific process on a computer. Group names are used to simultaneously send information to multiple computers.

Example: How a NetBIOS Name is used

For example, the Server service uses a NetBIOS name. When the server computer starts, this service registers a unique NetBIOS name, based on its configured NetBIOS computer name--SERVER1, in this example--on the network. The exact name registered is a combination of the characters "SERVER1" assigned for the NetBIOS computer name plus a 16th character that contains the hexadecimal byte value of "20" (or [20h] as it appears when viewing records in the WINS console).

When other computers on the network use the net use command to attempt to connect to SERVER1, a name-query request searches for this NetBIOS name. The query uses direct contact with a WINS server or a broadcast to the local network to process the query. When the matching named server process is found--for example, a NetBIOS name entry of "SERVER1" with a name suffix value of "20" for the 16th character--the IP address contained in this name record is returned to the requesting computer. Communications can then be established using underlying network transport protocol services.

NetBIOS Before Windows 2000

In earlier versions of Windows NT, all network services were registered using only NetBIOS names. For Windows 2000, the Netlogon service and potentially other network services will register in DNS instead. Also, legacy network command-line applications (such as the various net commands) use NetBIOS names to access these services.

NetBIOS names are also used by other NetBIOS-based computers, such as Windows for Workgroups, LAN Manager, and LAN Manager for UNIX hosts. For more information on NetBIOS names and how they are used to register and indicate named types of service on the network, see NetBIOS names reference.

Inside NetBIOS

NetBIOS defines two components:

  • A session-level interface

    The NetBIOS interface is a standard API that applications can use. These applications submit network input and output and control directives to an underlying network protocol software for transfer through the network. You can run any application program using the NetBIOS API for network communication on any protocol software that supports the NetBIOS interface.

  • A protocol for session management and data transport

    The protocol used here can be any networking protocol and its related software used to perform the actual transport and communication of the NetBIOS interface command set. Two examples are TCP/IP and NetBEUI protocol software, both of which are provided with most earlier versions of Windows operating systems.


Disabling NetBIOS over TCP/IP

Windows 2000 provides for the ability to disable NetBIOS over TCP/IP (NetBT) for select clients where it is useful to do so. If you require or would prefer to only use DNS to provide name registration and resolution on a specified computer used in a specialized or secured role for your network (such as an edge proxy server or bastion host in a firewall environment), you can select to disable NetBT services for one or all installed network adapter interfaces on that computer.

When NetBT is disabled, the following considerations are to be noted for computers running Windows 2000:

  • The computer no longer listens for traffic to the NetBIOS datagram service at User Datagram Protocol (UDP) port 138, the NetBIOS name service at UDP port 137, or the NetBIOS session service at Transmission Control Protocol (TCP) port 139.
  • If WINS is installed on the computer, the computer can no longer function as a WINS server to service WINS clients over this connection unless NetBT is re-enabled.
  • If the computer needs to participate in WINS as a client, it must be physically multihomed (that is, it must have other physical network connections active and available for its use) for it to continue communicating with and using a WINS server.
  • For computers operating as WINS clients, any WINS servers configured in TCP/IP properties for the disabled network adapter do not apply for other installed network adapters. For those adapters to use WINS, you must either manually configure a list of WINS servers on the NetBT-enabled connections or provide such a list to these connections from a DHCP server.

One possible use for this configuration setting is a case where a server computer is dual-homed on an internal private network and an exposed external network, such as the Internet. In this example, disabling NetBT for the installed external network connection makes sense. This allows the dual-homed computer to continue to function as either a WINS server or client for the internal network, and WINS clients can still be serviced for connections made using other physical network adapter installed on the computer.

Notes

  • For any Windows 2000 computers, NetBIOS can be disabled through manual configuration of TCP/IP settings. For more information, see To disable WINS/NetBT name resolution.
  • If you are using Windows 2000 DHCP servers, you can use DHCP options to dynamically update and disable NetBT at any Windows 2000 DHCP clients located on your network. Microsoft provides a vendor-specific option for performing this configuration. For more information, see Microsoft vendor-specific options.


Lmhosts files

The Lmhosts file is a static file that assists with remote NetBIOS name resolution on computers that cannot respond to NetBIOS name-query broadcasts. It contains NetBIOS name-to-IP addresses mappings. Its function is similar to that of the Hosts file; the difference is that the Hosts file can be used to map DNS domain names for host computers to their IP addresses.

Computers in a Microsoft-based network can resolve NetBIOS names in several ways. If one method fails, they try the next method, in a fixed order. In a broadcast-based network, the computer first checks its NetBIOS name cache. Normally, the cache only contains the name if it was used recently, but names can be preloaded from an Lmhosts file into the cache.

If static name-to-address mappings are entered in the Lmhosts file using the #pre notation, then these names are considered to be pre-loaded into the NetBIOS names cache and are used first to resolve name query, before a NetBIOS subnet broadcast or WINS query are used.

After checking the local cache, WINS servers are contacted (if they are configured and reachable) first before the name query is broadcast locally on the client subnet to further attempt resolution of the name. If these methods fail, the client (if enabled to do so) can later refer to an Lmhosts file again to further search for and obtain the name-to-IP address mapping. For example, to resolve a name used by another computer located on another subnet located across a router from the client.

Limitations of Lmhosts files

Despite the many uses of the Lmhosts file, there are some limitations to its design. Its greatest limitation is that it is a static file. Because of this, entries must be updated if the name or the IP address of the computer changes.

An IP address for a client might change for several reasons, such as:

  • It changes (physically moves) to another subnet within your routed local area network (LAN).
  • The computer is a portable and changes to another site location, such as a remote dial-up user dialing in from home through remote access to your network.
  • The DHCP server leases the client a different IP address after its lease expires.

When such changes occur, they must also be propagated to all the computers that need access to the resource with the changed name-to-IP-address mapping. A centrally maintained Lmhosts file can reduce some of the manual administration needed to propagate new or revised mappings to the required computers. However, entering and changing the mappings is still a manual, labor-intensive process. While maintaining an Lmhosts file centrally is certainly preferable to keeping an Lmhosts file on each computer, this solution can only be feasible for an organization with a small number of servers and clients. On larger networks, it becomes too complicated to maintain and is not a viable or recommended solution.

Note

  • The WINS console supports the ability to import static mappings from an Lmhosts file into a WINS server database, creating static type WINS entries. For more information, see To import a file containing static mapping entries.


Locating network services

  • Browsing overview
  • Browsing WANs with TCP/IP
  • Browsing WANs using WINS
  • Locating domain controllers using NetBIOS over TCP/IP (NetBT)


Browsing overview

The information in this topic is provided to explain how browsing a network is done for domains in routed WAN networks that use NetBIOS over TCP/IP (NetBT). Domains used in this type of environment are likely to be controlled by computers running earlier versions of Windows NT operating systems. In this environment, the use of WINS is needed to provide effective browsing of shared resources located in remote domains on other physical networks.

The Computer Browser service is used by Windows-based computers operating on each subnet. Computers designated as browsers maintain the browse lists, which contain all shared resources used on the network. Browsing is required by some network applications provided in earlier versions of Windows such as My Network Places, the NET VIEW command, and Windows NT Explorer.

For example, when a user at a computer running Windows 95 opens My Network Places, the displayed list of domains and computers is generated. This is done by the computer obtaining a copy of the browse list from a browser computer functioning in that role on the same subnet.

Most computers on the network operate as non-browsers but computers running the Computer Browser service can become potential browsers for each subnet. For computers active as browsers on the network and maintaining copies of the browse list, Windows NT assigns special roles.

The following table describes the various roles computers operating this service can perform for the purpose of network browsing:

Browser role Description
Domain master browser
  • Used only in domain environments. By default, the primary domain controller (PDC) for a domain operates in this role.
  • Collects and maintains the master browse list of available servers for its domain, as well as any names for other domains and workgroups used in the network.
  • Distributes and synchronizes the master browse list for master browsers on other subnets that have computers belonging to the same domain.
Master browser
  • Collects and maintains the list of available network servers in its subnet.
  • Fully replicates its listed information with the domain master browser to obtain a complete browse list for the network.
  • Distributes its completed list to backup browsers located on the same subnet.
Backup browser
  • Receives a copy of the browse list from the master browser for its subnet.
  • Distributes the browse list to other computers upon request.
Potential browser
  • Under normal conditions, operates similarly to a non-browser.
  • Capable of becoming a backup browser if instructed to by the master browser for the subnet.
Non-browser
  • Does not maintain a browse list.
  • Can operate as a browse client, requesting browse lists from other computers operating as browsers on the same subnet.
  • Configured so it cannot become a browser.

Under some conditions, such as failure or shutdown of a computer designated a specified browser role, browsers (or potential browsers) may change to a different role of operation. This is typically performed through a process known as a browser election.

Browsing services in earlier versions of Windows operating systems can be understood in terms of three key processes:

  • Collection of browsing information

    Browse lists are made up of computers that share resources through the use of the Server service. Periodically, every computer running this service broadcasts a host announcement message for its configured domain or workgroup name to the local subnet. These announcements are collected and processed on an ongoing basis by the master browser for each subnet.

    When the master browser on a subnet receives a host announcement, it compares the name of the sending computer to its current browse list. If the name already appears, it is refreshed in the list. If the name does not appear, it is added to the list.

  • Distribution of browsing information

    Browse lists are distributed to backup browsers by the master browser for the subnet. Periodically, the master browser must broadcast an announcement message for its configured domain or workgroup name to the local subnet. This message confirms the master browser's presence on the network. If the master browser fails to announce itself for a period of time, a browser election can occur.

    Once a master browser is either present or (in the event of a failure) replaced, other backup browsers periodically contact it to obtain an updated copy of the browse list that it maintains for the subnet.

  • Servicing of browse requests from clients

    When a browse client computer starts on a subnet, it broadcasts a request to the master browser for a list of the backup browsers on the subnet. The master browser responds to this request and provides the client a list of three backup browsers. The browse client then randomly selects one of the backup browsers from the list and contacts it for a copy of the browse list.

    For subsequent browse list requests, the client continues to use the list of backup browsers provided by the master browser during its startup and does not repeat the broadcast. The success of this process depends first upon the client getting a response from its master browser and secondly, its ability to resolve the names of backup browsers it selects from the list.

Example: How browsing works

The following graphic shows an example of these processes for an example domain called MIS.

Example: How browsing works to collect, distribute, and merge lists [image] .

In this example, the MIS domain has three master browser computers--PDC-MIS, A-MB1, and C-MB1--present on subnets A, B and C. In addition, PDC-MIS, has special significance as the domain master browser for the domain as well as acting as the subnet master browser for subnet B.

As the master browsers on each subnet, these three computers perform the following to create and manage the update and distribution of the MIS domain browse list across all three subnets:

  • Process browser announcements that are broadcast by any servers on each of their respective local subnets.
  • Replicate their local subnet browse lists with one another. This eventually builds and replicates a complete browse list for the domain that can be distributed and used on each of the three subnets that have computers participating in the domain.
  • Replicate their current browse list to backup browsers on each of their respective subnets for fault tolerance and load balancing.
  • As clients request the browse list, the master browsers for each subnet answer their local clients with the list of backup browsers to use in contacting and obtaining the browse list. Clients then use this list to contact the backup browsers and obtain copies of the actual browse list.

Notes

  • NetBIOS-based browsing services involve many other details not fully described here. For more in-depth information about browsing, see Updated technical information.
  • For Windows 2000, browsing functionality in many cases can be accomplished by publishing them in the Active Directory through the use of global catalogs. For more information, see Global catalog.


Browsing WANs with TCP/IP

The Computer Browser service relies almost entirely on using broadcast communication on each subnet in a network. In a wide area network (WAN) that uses TCP/IP, where domains can be separated by routers, special problems for browsing can occur. Most IP routers are not configured to forward broadcasts.

For browsing in these environments, there are two issues to consider:

  • How browsers separated by a router perform browser functions, such as updating and maintaining a complete browse list of all network servers, domains, and workgroups
  • How local browse clients on each subnet browse remote domains not present on the same subnet.

These issues can be addressed in three possible ways: using WINS, maintaining an Lmhosts file for each subnet master browser, or enabling NetBIOS broadcasts through IP routers.

The last option, enabling broadcasts across IP routers, is not recommended for most routed TCP/IP networks. The second option, using Lmhosts files, offers a partial solution to these issues, by providing a way to maintain browse lists for all master browsers in a single domain. Only the first option, the use of WINS, offers a preferred solution to both issues and permits browsing of remote domain resources by browse clients.

Example: Browsing domains in a routed IP network

As shown in the following graphic, PDC-MASTER is the computer name of a Primary Domain Controller (PDC) running an earlier version of Windows NT Server for a domain named MIS that spans two subnets, Subnets 1 and 2. PDC-MASTER acts as the domain master browser for the MIS domain and also functions as a master browser for Subnet 2. On Subnet 1, a computer named BROWSER1 acts as the master browser for that subnet and is configured to use the same LAN group (the MIS domain) as PDC-MASTER.

Browsing domains in a routed IP network

In this example, BROWSER1--which could be any Windows-based computer on Subnet 1 able to operate as a browser--periodically contacts PDC-MASTER on Subnet 2 to exchange information contained in their respective browse lists. Because the router that separates Subnets 1 and 2 does not forward NetBIOS over TCP/IP (NetBT) broadcasts, BROWSER1 must use direct communication to contact PDC-MASTER.

If BROWSER1 is WINS-enabled, it can directly query a WINS server for the "MIS [1b]" name. This name maps the IP address for the computer (PDC-MASTER) that is performing in this role for the MIS domain. Otherwise, it must pre-load a mapped entry for this computer from its Lmhosts file to make direct contact possible across subnets.

For example, if the domain master browser (PDC-MASTER) has an IP address of 192.168.5.8, the entry in the Lmhosts file at BROWSER1 (if it is running Windows NT) would need to be:

    192.168.5.8    PDC-MASTER   #PRE   #DOM:MIS

If BROWSER1 is running under another Windows platform that supports browsing services, such as Windows 95 or Windows for Workgroups, the entry would be:

    192.168.5.8   "MIS            \0x1B"  #PRE

WAN browsing considerations

The following are additional considerations to keep in mind when planning browsing services across a routed TCP/IP-based network:

  • Computers running earlier versions of Windows operating systems (Windows NT Workstation, Windows NT Server, Windows for Workgroups, and Windows 95 and Windows 98), can perform the master browser and backup browser roles.
  • Only computers running an earlier version of Windows NT Server and operating as the PDC for a domain typically perform the domain master browser role.
  • Only domains can span multiple subnets. Workgroups cannot span multiple subnets and can only view other workgroups on the same subnet.


Browsing WANs using WINS

WINS acts as a directory service for NetBIOS names and IP addresses. The use of WINS can improve browsing for wide area networks through the following enhancements:

  • WINS-enabled clients can directly query their configured WINS server for NetBIOS names used to implement browsing and domain services.
  • If a domain master browser is a WINS-enabled client, it queries WINS periodically (every 12-15 minutes) to obtain a list of all domains stored in the WINS database.

These enhancements make it possible for WINS to assist in fully browsing the entire network and resources shared in remote domains. The process of implementing this enhanced browsing involves the use of WINS in two ways:

  • Names for remote domains are registered in WINS and replicated to all WINS servers used in the network.
  • WINS-enabled clients use a modified process of WINS query and directed communication with computers in the remote domain to obtain browse list information about servers and shared resources in these remote domains.

How remote domains register in WINS

For example, as shown in the following graphic, three PDCs for three separated domains (ADMIN, FINANCE, MIS) are operating as domain master browsers for their respective domains. All of these computers are WINS-aware computers running as WINS clients.

How domain master browser information is shared and replicated through WINS

When each of the PDC computers starts for its domain, it registers the [1b] name for the domain with its preferred WINS server. For example, in the ADMIN domain, the computer PDC-ADMIN registers its IP address (192.168.1.2) as the domain master browser. These [1b] names then appear at other WINS servers as WINS database replication occurs in the routed network.

Because each of the four PDC computers operating as the domain master browser for their respective domains are configured to use WINS, they query WINS every 15 minutes to update their respective browse lists to include all other domains used in the network. Once all domains are registered in WINS, domain master browsers operating locally for each domain can use a two-part process to query the WINS server and discover remote domains:

  1. The local domain master browser does a wild card query of WINS for domain names ending with a name suffix of [1b].

    Note that the result of this query--a list of domain names--only contains the names and a single IP address corresponding to the domain master browser (or PDC computer) for the domain. It does not contain all of the names of master browsers for each domain, as would normally be obtained if the remote domains had member computers located on the same subnet. For domains active on the local subnet, this information is normally obtained through master browser announcements that are broadcast to the local subnet.

  2. To obtain a master browser for one of the remote domains, the local domain master browser does a reverse query based on the IP address returned for each remote domain [1b] name collected in step 1.

    The reverse query is used to learn the name of the computer that registered the remote domain name. In this way, the local domain master browser completes its list of remote domain names and their corresponding domain master browsers.

Notes

  • Only WINS-aware domain master browsers (those in Windows NT Server 3.5 or later) register their domain [1B] names with the WINS server and perform enhanced WINS queries for learning about remote domains. Domain master browsers running Windows NT Server 3.1 do not use WINS.
  • This information describes browsing enhancements for server and client computers that are WINS-aware. For more information about specific differences in browsing service for different versions of Windows operating systems, see Microsoft Support Online.

Browsing remote domains with WINS clients

In wide area networks, the use of a replicated WINS database that contains reference information about each of the domains can assist WINS-enabled clients in browsing remote domains.

As described earlier, NetBT clients can use broadcasts to their local subnets for <domain> [1D] names. When this happens and the domain is located at a remote subnet or site, the query fails. Under these circumstances, browsing is not possible unless special configurations are made and maintained. Without WINS, each domain master browser would need static information entered in an Lmhosts file to further process a client request. This requires careful administration to maintain and update static Lmhosts files at each domain master browser in the enterprise.

With WINS, clients can leverage the replicated names database more effectively and administrators can eliminate reliance on Lmhosts management. The process used by WINS clients to resolve a browser request for a remote domain name is different from the process used by non-WINS (NetBIOS broadcast-only) computers or to obtain information about local domains that are present on the same subnet.

Example: How WINS clients obtain remote domain browse lists

The following graphic shows how a WINS client located in Sydney, SYD-PC-2, is able to obtain browse list information about the remote SEA domain located in Seattle:

Browsing remote domains in a wide area network using WINS
  1. After the WINS client (SYD-PC-2) fails to locate a master browser for SEA domain using a broadcast for the [1D] name, it queries its configured WINS server (SYD-WINS1) for the <SEA> [1b] name.

    The [1B] query is used to learn the IP address of the domain master browser (the PDC) for the remote domain. If all PDCs are configured to use WINS as described earlier in How remote domains register in WINS, the queried names should be present in the replicated WINS database.

  2. The WINS server resolves the request for "SEA [1B]" and returns the answer to the client.

    The WINS response includes the IP address of SEA-PDC, the domain master browser for the remote SEA domain to the client.

  3. The client then uses the IP address to send a direct request to SEA-PDC to obtain a list of backup browsers for the requested domain.
  4. The remote domain master browser (SEA-PDC) responds with a list of up to three backup browsers for the requested SEA domain to the client.

    For this example, the list of backup browsers returned by SEA-PDC includes the computer names of SEA-BB1, SEA-BB2 and SEA-BB3.

  5. The WINS client then randomly selects one of the backup browsers from the list and queries WINS again.

    For instance, if the client randomly selects SEA-BB3, it then attempts to have WINS resolve the name "<SEA-BB3> [20]" to get the IP address of this computer.

  6. The WINS server resolves the request for "SEA-BB3 [20]" and returns the answer to the client.

    The WINS response includes the IP address of SEA-BB3, the selected backup browser for the remote SEA domain to the client.

  7. The client then sends a request directly to the backup browser, SEA-BB3, located within the remote domain in Seattle, requesting a copy of the browse list for the SEA domain.
  8. The remote backup browser then returns the browse list for the remote domain to the client.

If WINS query for the remote domain fails

In some instances, the WINS client can receive a negative name response from the WINS server during step 2 of the previous process, changing how the client attempts to request and obtain browse list information for the remote domain.

Some reasons for a negative response from a WINS server include:

  • The remote [1b] name queried was found to be for a workgroup, not a domain.
  • The PDC for the remote domain is not a WINS client.
  • The PDC for the remote domain is a WINS client, but the PDC and the browsing client are not sharing a common WINS database (replication is not occurring).

In this case, the WINS client does the following:

  1. It makes a connection with its local master browser (on the same subnet as the client) and requests the name of the master browser of the desired domain or workgroup.
  2. The local master browser returns the name of the master browser that advertised the domain or workgroup.
  3. The client resolves the unique name of the <master_browser> [20] that advertised the domain or workgroup.
  4. The client then makes a connection with that master browser to request a list of servers in the domain or workgroup.
  5. The list of servers in the domain or workgroup is returned to the client.


Locating domain controllers using NetBIOS over TCP/IP (NetBT)

A domain is a logical grouping of network servers and other computers that share common security and user account information. In a domain-based network, Windows NT computers are configured as members of a specified domain.

When domain computers require access, such as network logon or access to a shared resource in the domain, authentication of the user in the domain security database is needed to control access. Domain controllers are computers running Windows NT Server that perform the specialized function of controlling this access. If a domain controller for the domain cannot be located, the user is denied access. For this reason, it is critical that member computers in each domain be able to locate domain controllers.

For environments with domains running Windows NT Server 4.0 and earlier versions, the process of locating domain controllers involves the resolution of the <domain> [1C] name. This name is registered for use by the domain controllers within each domain and can contain up to 25 IP addresses.

The first IP address is always for the primary domain controller (PDC). The additional (up to 24) IP addresses are for backup domain controllers (BDCs). Because this name is treated as a domain group by WINS, each member of the group (a domain controller) must renew its name individually in WINS, or its IP address entry in the list is released and can be eventually overwritten.

Each time a domain controller starts, it registers its <domain>[1Ch] name. This record can then be updated dynamically in the WINS database and replicated to other WINS servers located throughout the network.

In addition to locating domain controllers, some domain functions are reserved for handling only by the domain master browser or PDC. Because the PDC or domain master browser is a single server computer, locating it involves resolution of a special record type, the <domain> [1B] name. This record can be registered by the PDC in WINS and is used to map the domain name to a single IP address of the server computer performing in this domain role.

Note

  • For Windows 2000 Server, domains are established with Active Directory, which uses a method based on DNS query to locate Windows 2000 domain controllers.

How <domain> [1B] names are used

Queries for <domain> [1B] names are made by:

  • Domain-based password changes

    When a user in a Windows NT domain attempts to change their password at a domain member computer, a WINS query is used to locate the configured <domain>[1B] name of the domain master browser (typically, also the primary domain controller) to authenticate the current password and process the request to update the password in domain data.

  • Obtaining browse list information for remote domains

    The <domain>[1B] names are used to assist in obtaining browse list information for remote Windows NT domains on your network. For more information, see Browsing WANs using WINS.

How <domain> [1C] names are used

Queries for <domain> [1C] names are made by:

  • Users logging on to a domain

    When a computer that participates in a domain starts on the network, it queries for its configured <domain> [1C] name to locate a domain controller that can authenticate the logon request.

  • Domain controllers replicating the domain user account database

    A broadcast is sent from the primary domain controller (PDC) to the backup domain controllers (BDCs) in the domain instructing them to request replication of the new changes to the domain accounts database.

Since these broadcasts do not cross IP routers, directed traffic must be used to accomplish these tasks. When a broadcast is sent to the domain for these tasks, the message is also sent directly to remote domain controllers. Either WINS or entries in the Lmhosts file can determine the list of computers receiving the direct message.

  • WINS clients

    These clients contact WINS and ask for the list of domain controllers in the domain. WINS replies with a list of up to 25 domain controllers. The client then sends the domain message directly to these domain controllers.

  • Non-WINS clients

    The client broadcasts the message directly to the domain and also looks for any #DOM entries in the Lmhosts file with a matching domain name. If it finds a matching entry, it sends the same message directly to the computer listed.

    It is recommended to add remote domain controller #DOM entries to each client. This way, if the local domain controllers are offline, the user is still able to log on. If there are no local domain controllers, a #DOM entry is required if the user wants to log on.

    A Non-WINS PDC must have #DOM entries for all BDCs. All of the BDCs must have an entry for the PDC. One recommended practice here is for all domain controllers to use #DOM entries for each other as well. This way, if a BDC is later promoted to a PDC, all of the remaining BDCs still have a #DOM mapping to the new PDC.

How WINS clients locate domain controllers

When a WINS-enabled client is configured to use a WINS server, it queries the WINS server for its <domain>[1C] name if it needs to locate a domain controller.

When a WINS server receives a <domain> [1C] name query from a WINS client, either a domain controller or a computer logging on to the domain, it replies with up to 25 IP addresses of domain controllers for the queried domain name.

In the reply, IP addresses for any domain controllers that registered with the queried WINS server are returned first, sorted by registration date and time. The response list is ordered so the first entry in list is the IP address that matches the mapped address for the <domain> [1B] name registered with the queried WINS server. After locally owned entries are listed in the response, any IP addresses of domain controllers for the domain that are owned by WINS servers (other than the one queried) are included.

WINS interaction for static <domain> [1C] names

WINS applies the following handling for static <domain>[1C] names when they are found in database changes:

  • If a static <domain>[1C] name is added at the local WINS server, and a dynamic mapping for the same already exists, the listed entries from both are merged and a union of the two mappings is formed.
  • When a static <domain>[1C] name is replicated and it clashes with a dynamically registered version of the <domain>[1C] name, the static mapping overwrites the dynamic mapping.
  • If the <domain>[1C] name in use at a WINS server is static, the members of the list do not have to renew their IP addresses.

When used in WINS, static <domain>[1C] names can eventually cause other problems in your network. For example, if an IP address for a domain controller changes, or if a domain controller is retired or removed from the network, the static <domain>[1C] record might list stale members. This can cause failures for clients if they then query WINS and use the stale members provided there when attempting to locate domain services.


WINS components

  • WINS servers
  • WINS clients
  • WINS proxies
  • The WINS database


WINS servers

WINS consists of two main components, the WINS server and WINS clients.

The WINS server handles name registration requests from WINS clients, register their names and IP addresses, and responds to NetBIOS name queries submitted by clients, returning the IP address of a queried name if it is listed in the server database.

Also, as the following graphic shows, WINS servers can replicate the contents of their databases (which contain NetBIOS computer name mappings to IP addresses) to other WINS servers. When a WINS-enabled client computer (such as a workstation computer on either Subnet 1 or Subnet 2) starts on the network, its computer name and IP address are sent in a registration request directly to its configured primary WINS server, WINS-A. Because WINS-A is the server that registers these clients, it is said to be the owner for the records of the clients in WINS.

WINS servers

In this example, server WINS-A has clients registering with it that are both local (that is, clients on Subnet 2 where it resides) and remote (clients located across a router on Subnet 1). A second WINS server, WINS-B, is located on Subnet 3 and only owns mappings for local clients registering from its same subnet. WINS-A and WINS-B can later complete replication of their databases so that records for clients on all 3 subnets are in the WINS database at both servers. For more information, see WINS replication.

Primary/Secondary WINS servers

WINS servers are used by clients in one of two ways: either as a primary or secondary WINS server.

The difference between primary and secondary WINS servers is not based in any way on the servers (which for all functional purposes are the same in WINS). The difference occurs at the client which differentiates and orders the list of WINS servers when provided more than one WINS server to use.

For most cases, the client contacts the primary WINS server for all of its NetBIOS name service functions (name registration, name renewal, name release and name query and resolution). The only case where secondary WINS servers are ever used is when the primary WINS server is either:

  1. not available on the network when the service request is made, or
  2. the server is unable to resolve a name for the client (in the case of a name query).

In the case of a failure by the primary WINS server, the client requests the same service function from its secondary WINS servers. If more than two WINS servers are configured at the client, the additional WINS servers are tried until the list is exhausted or one of the secondary WINS server succeeds in processing and responding to the request. After a secondary WINS server is used, a client periodically tries to switch back to its primary WINS server for future service requests.

For most recent WINS clients (Windows 2000 and Windows 98), a list of up to 12 secondary WINS servers can be configured (either manually through TCP/IP properties or dynamically by a DHCP server providing a list using DHCP option type 44). This feature is useful in an environment where there are a large number of mobile clients and NetBIOS-based resources and services are used often. Because in these types of environments, the WINS database may not be consistent throughout the network of WINS servers because of convergence issues, it can be helpful for clients to be able to query more than two WINS servers.

However, this option should not be overused needlessly as it produces a tradeoff in terms of the actual benefit for adding fault tolerance by listing additional WINS servers. The benefit of this feature must be weighed against the fact that for each additional WINS server listed, the time to process a query request fully in WINS takes incrementally longer to achieve. For example, if a WINS client tries three or more WINS servers before failing, it can substantially delay the processing of the name query before alternative methods for resolution are tried, such as searching of a local Hosts file or querying a DNS server.


WINS clients

WINS clients attempt to register their names with a WINS server when they start or join the network. Clients thereafter query the WINS server to resolve remote names as needed.

WINS-enabled clients are computers that are able to be configured to make direct use of a WINS server. Most WINS clients typically have more than one NetBIOS name that they must register for use with the network. These names are used to publish various types of network service, such as the Messenger or Workstation service, that each computer can use in various ways to communicate with other computers on the network.

Microsoft supports WINS clients running on the following platforms:

  • 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 the WINS server to:

  • 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 user names, NetBIOS names, DNS names, and IP addresses.

Clients that are not WINS-enabled can participate in these processes in a limited way by using WINS proxies. For more information, see WINS proxies.


WINS proxies

A WINS proxy is a WINS client computer configured to act on behalf of other host computers that cannot directly use WINS. WINS proxies help resolve NetBIOS name queries for computers located on routed TCP/IP networks.

By default, most computers not able to use WINS use broadcasts to resolve NetBIOS name queries and register their NetBIOS names on the network. You can configure a WINS proxy to listen on behalf of these computers and to query WINS for names not resolved by broadcast.

WINS proxies are only useful or necessary on networks that include NetBIOS broadcast-only (or b-node) clients. For most networks, WINS-enabled clients are common and WINS proxies are typically not needed.

WINS proxies are WINS-enabled computers that listen for b-node NetBIOS name service functions (name registration, name release, and name query) and can respond for those names that are remote and not used on the local network. Proxies communicate directly with a WINS server to retrieve the information necessary to respond to these local broadcasts.

WINS proxies are used in the following ways:

  • When a b-node client registers its name, the proxy checks the name against the WINS server database. If the name exists in the WINS database, the proxy might send a negative registration response back to the b-node client attempting to register the name.
  • When a b-node client releases its name, the proxy deletes the client name from its remote name cache.
  • When a b-node client sends a name query, the proxy attempts to resolve the name using information either locally contained in its cache of remote names or through the use of information it obtains from the WINS server.

How WINS proxies resolve names

The following graphic illustrates the use of a WINS proxy, HOST-B, for a subnet containing a b-node client, HOST-A.

Example of WINS proxy

In this example, the following steps are used by the WINS proxy to resolve names for the b-node computer:

  1. HOST-A broadcasts a NetBIOS name query to the local subnet.
  2. HOST-B accepts the broadcast and checks its cache for the appropriate NetBIOS computer name-to-IP address mapping.
  3. HOST-B processes the request.

    If HOST-B has a name-to-IP address mapping cached that matches the one HOST-A requested, it returns this information to HOST-A. If not, HOST-B queries a WINS server for the mapping requested by HOST-A.

  4. When HOST-B receives the requested name-to-IP address mapping from its configured WINS server (in this example, WINS-A), it briefly caches this information.

    By default, WINS proxies cache remote name mappings that it queries in WINS for 6 minutes, but this value is configurable with a minimum value of 1 minute.

  5. HOST-B can then use this mapping information to respond to subsequent NetBIOS name queries broadcast from either HOST-A or other b-node computers on the subnet.

Notes

  • Because WINS servers do not respond to broadcasts, you should configure a computer as a WINS proxy on each subnet that contains non-WINS computers that must use broadcasts to resolve NetBIOS names.
  • When a WINS proxy is used to answer a query for a multihomed client or a group record containing a list of IP addresses, only the first listed address is returned to the b-node client.
  • For more in-depth information on configuring or using WINS proxy, see Updated technical information or Windows 2000 Resource Kit.


The WINS database

The WINS database stores and replicates the NetBIOS name-to-IP address mappings for your network. In Windows 2000 Server, the WINS database uses the performance-enhanced Exchange Server storage engine

Compacting the database

There is no built-in limit to the number of records that a WINS server can replicate or store. The size of the database depends on the number of WINS clients on the network. The WINS database changes over time as clients log on and log off the network.

However, the size of the WINS database is not directly proportional to the number of active client entries. Over time, as some WINS client entries become obsolete and are deleted, the size of the WINS database grows larger than the actual space currently in use by the database. This is because the space used to store obsolete records is not automatically reclaimed by the server once the space is freed and no longer in use.

Compacting the WINS database recovers the unused space. Dynamic database compaction occurs on WINS servers as an automatic background process during idle time after a database update. Compaction can also be done manually offline. Windows 2000 Server and Windows NT Server 4.0 support both dynamic and manual compaction. Windows NT Server 3.51 (or earlier) supports only manual compacting of the WINS server database.

Although dynamic compacting greatly reduces the need for offline compaction, offline compaction reclaims the space better and should be done periodically. How frequently you manually compact the WINS database depends on your network. For large, busy networks with 1,000 or more WINS clients, you should compact offline each month. Smaller networks usually require less frequent manual compaction.

Because the dynamic database compaction occurs while the database is in use, you do not need to stop the WINS server during this process. However, for manual compacting, you must stop the WINS server and take it offline.

Backing up the WINS database

The WINS console provides the tools you need to maintain, view, back up, and restore the WINS server database. You should back up the database whenever you back up other files on the WINS server.

WINS database files

WINS uses the Jet database format for storing its data. Jet produces J<n>.log and other files in the systemroot\System32\Wins folder to increase the speed and efficiency of data storage.

The following table discusses the files that are created and used by the Jet database in each WINS server.

File | Description
J50.log and J50#####.log A log of all transactions done with the WINS database. This file is used by WINS to recover data if necessary.

To increase speed and efficiency of data storage, the Jet database writes current transactions to log files rather than directly to the database. Therefore, the most current view of the data includes both the database and any transactions in the log files. Both of these files are used for recovery if the WINS service abruptly or unexpectedly stops. If the service stops in an unexpected manner, the log files are automatically used to re-create the correct state of the WINS database.

Log files maintain a specific size; however, they can grow quickly on a busy WINS server. Inevitably, WINS writes more transactions to a log than the log size can accommodate. When a log file is filled, it is renamed, indicating that it is an older log and not in use. A new transaction log is created with the J<n>.log file name, where <n> is a decimal number, such as J50.log. The naming format of the previous log file is JetXXXXX.log, where each X denotes a hexadecimal number from 0 to F. Previous log files are maintained in the same folder as the current log files.

The log files are processed (all entries written to the database) and deleted when a successful backup occurs or when the WINS server is shut down properly. If many J<n>.log files accumulate, you should schedule frequent backups to maintain the logs.

After the entries are processed, you can manually delete the log files; however, this prevents a successful recovery of the database if it should be needed. For this important reason, do not manually delete or remove the log files from the system until a backup has been performed.
J50.chk | A checkpoint file that indicates the location of the last information successfully written from the transaction logs to the database. In a data recovery scenario, the checkpoint file indicates where the recovery or replaying of data should begin. This checkpoint file is updated every time data is written to the database file (Wins.mdb).
Wins.mdb | The WINS server database file, which contains two tables: the IP address-to-Owner ID mapping table and the Name-to-IP address mapping table.
Winstmp.mdb | A temporary file that is created by the WINS server service. This file functions as a swap file during index maintenance operations and can remain in the systemroot\System32\Wins directory after a system failure.
Res#.log | These are reserved log files, which function in emergencies when the server runs out of disk space. If a server attempts to create another transaction log file and there is insufficient disk space, the server flushes any outstanding transactions into these reserved log files. The service then shuts down and logs an event to Event Viewer.

Important

  • The J50.log, J50#####.log, Wins.mdb, Winstmp.mdb, and Res#.log files should not be removed or altered.


WINS replication

  • Replication overview
  • Pull partners
  • Push partners


Replication overview

Where multiple WINS servers are used on your network, they can be configured to replicate records in their databases to other servers. This process is shown in the following figure. Two WINS servers, WINS-A and WINS-B, are both configured to fully replicate their records with each other.

WINS replication overview

By using replication between these WINS servers, a consistent set of WINS information is maintained and distributed throughout the network. For example, in the previous figure a WINS client (HOST-1) on Subnet 1 registers its name with its primary WINS server, WINS-A. Another WINS client (HOST-2) on Subnet 3 registers its name with its primary WINS server, WINS-B. If either of these hosts later attempts to locate the other host using WINS--for example, HOST-1 queries to find an IP address for HOST-2--replication between the WINS servers (WINS-A and WINS-B) makes resolving this query possible.

For replication to work, each WINS server must be configured with at least one other WINS server as its replication partner. This ensures that a name registered with one WINS server is eventually replicated to all other WINS servers in the network. A replication partner can be added and configured as either a pull partner, a push partner or to use both types of replication as a push/pull partner. The push/pull partner type is the default configuration and is the type recommended for use in most cases.

When WINS servers replicate, a latency period exists before a client name-to-address mapping from any given server is propagated to all other WINS servers in the network. This latency is known as the convergence time for the entire WINS system. For example, a name release request by a client will not propagate as fast as a name registration request. This is intended by design because it is common for client names to be released and then reused with the same mapping as computers are restarted or periodically shut down. Replicating each of these name releases would unnecessarily increase the network load of replication.

Also, when a WINS client computer is shut down improperly, as in the case of an unexpected power outage, the registered names of the computer are not released as they normally would be by sending a name release request to the WINS server. Therefore, the presence of a name-to-address record in the WINS database does not necessarily mean that a client computer is still using the name or its associated IP address. It only means that at some recent time in the past, a computer by the registered name claimed the mapped IP address for its use.

Notes

  • The primary and secondary WINS servers of any client should typically have a push and pull relationship with each other. However, a direct push/pull configuration is not required as long as similar results can be indirectly achieved during a normal replication cycle.
  • WINS replication is always incremental, meaning that only changes in the database are replicated each time replication occurs, not the entire database.


Pull partners

A pull partner is a WINS server that pulls or requests replication of updated WINS database entries from other WINS servers (those configured to use it as a push partner) at a configured interval. This is done by requesting entries with a higher version ID than the last entry received from its configured partner.

You can enable WINS to pull (request) a replication with its configured partners when one of the following events occurs:

  • When the WINS server starts.
  • When a set amount of time has elapsed.

The amount of time between pull replications is indicated in the Replication interval, which can be specified either globally for all pull partners or individually for specific partners. When the time has elapsed for each interval, WINS sends a pull replication trigger to its pull partners. The partners can then respond with incremental changes, if any have been made since the last time replication occurred.

To configure which of these options WINS uses, you need to configure pull parameters, either the default parameters that the server uses for all pull partners or the parameters in effect for a specific partner. For more information, see To modify pull partner properties.

Additionally, you have the administrative option of manually sending a pull replication trigger to another pull partner of the selected WINS server. For more information, see To send a replication trigger to a selected partner.

How WINS determines which entries to pull replicate

Because push-based replication uses notification, it does not transfer any records until a subsequent pull trigger is returned by the notified partner. For this reason, pull replication can be viewed as the single process used to replicate WINS data between servers.

All WINS servers maintain an internal mapping table—an owner-version mapping table—which is used to complete the replication process. This table is built dynamically at startup by the server and is held in memory.

The owner-version mapping table contains the following:

  1. An owner ID that maps to the IP address for each WINS server that appears in the database as an owner for records currently stored there.

    For practical purposes, WINS automatically assigns and increments an integer value for the owner ID and then maps that value to a corresponding server IP address. However, when you examine this information in the WINS console, only the owner IP address is actually displayed.

  2. When replication occurs with another WINS server, the version ID field for all records currently in the database is scanned for the highest version ID associated with each identified distinct owner.

A sample Owner/Version ID table for WINS-A when it is started might look like the following, if viewed using View Records in the WINS console:

Owner ID (not displayed) | Owner | Name | Highest ID
(0) | 192.168.1.5 | WINS-A | 1F
(1) | 192.168.2.5 | WINS-H | 125
(2) | 192.168.3.5 | WINS-B | 31
(3) | 192.168.4.5 | WINS-C | 100
(4) | 192.168.5.5 | WINS-D | 200

The owner-version mappings are used by WINS to determine the state of the database at any point in time before or after replication. The following example provides more detailed information about how WINS manages replication.

Example: How pull replication works

The following graphic demonstrates how four WINS servers—WINS-A, WINS-B, WINS-C, and WINS-D—are all configured to be spokes (push/pull partners) of a central hub server, WINS-H.

Example: How pull replication works

Before replication with WINS-H, the owner-version mapping table at WINS-A contains a set of highest version IDs for all owners in its database. For the purpose of this example, assume these values are the same as those shown in the sample table provided in the previous section.

In reality, pull replication might be occurring dynamically between all four spokes at various times with WINS-H, so this table might not remain static for long. For a basic understanding of the details of a individual pull replication cycle, however, it is easier to focus on what might happen when just one of the spokes—for example, WINS-A—replicates its database with WINS-H.

In the graphic shown, the following changes in the replicated WINS network occur:

  1. The three other spokes (WINS-B, WINS-C and WINS-D) each replicate with WINS-H, based on the highest version ID.
    1. WINS-B has added or updated one new record since its last replication cycle, which WINS-H replicates and adds to its database.
    2. WINS-C has the same version ID and does not have any new records to be replicated at WINS-H.
    3. WINS-D has updated a total of 20 records since its last replication cycle, which WINS-H replicates and adds to its database.
  2. WINS-H sends a trigger to WINS-A initiating replication.

    The updated owner-version mapping table information is provided as part of the trigger.

  3. WINS-A responds by pulling entries from WINS-H.

    WINS-A determines which owner servers to pull from based on the difference between its locally held highest version ID for each owner and the corresponding updated highest version IDs provided by WINS-H. WINS-A specifies the range of records to be pulled and replicated by comparing versions.

Notes

  • In the case where another pull replication to the same partner is already queued, WINS sees the subsequent request as further down in the queue and discards it in favor of keeping the one with a higher placement in the service process queue.
  • In addition to modifying settings for pull replication properties, WINS also provides the option to enable the use of persistent connections with either a specified pull partner or all pull partners of a WINS server.

    For more information, see either Persistent connections or To enable the use of persistent connections with a partner server.


Push partners

A push partner is a WINS server that pushes or notifies other WINS servers (those configured to use it as a pull partner) of the need to replicate their database entries at a configured interval. To configure a WINS server to use push replication, you can choose from several WINS console configurable options. For example, you can enable WINS to push notify configured partners when one of the following events occurs:

  • When the WINS server starts.
  • Whenever an IP address change occurs for a name-to-address mapping in the WINS server database.
  • When a value for Number of changes in version ID before replication is specified—either globally for all push partners or individually for specific push partners—WINS can use this value as a threshold for determining how many incremental changes must be made to the database before it starts push replication to its partners.

To configure any of these options for WINS use, you need to configure push parameters, either the default parameters that the server uses for all push partners or the parameters in effect for a specific partner. For more information, see To modify push partner properties.

Additionally, you can manually start push replication to other WINS servers. For more information, see To send a replication trigger to a selected partner or To send a replication trigger to any specified WINS server.

How updates and WINS settings affect push replication

By default, WINS does not perform push replication unless other related settings are also configured on the Push Replication tab in Replication Partners Properties. For example, WINS uses a an update count value of 0. This is set using Number of changes in version ID before replication.

Push replication only occurs at configured replication intervals, unless other push replication settings are configured as well, such as:

  • For Start push replication, selected events such as the At service startup or the When address changes check boxes are selected.
  • The Use persistent connections for push replication partners check box is selected, which can affect how the value of Number of changes in version ID before replication is handled by WINS.

By default, persistent connections are not used and replication with partners does not occur except at configured intervals. This default can be changed, but a specified minimum number of update changes to WINS must be set first. Without the use of persistent connections, a minimum value of 20 for Number of changes in version ID before replication is required.

With persistent connections enabled for push replication, the default value of 0 causes the local WINS server to send a push trigger and notify its push partners each time an update occurs. An update is defined as an incremental increase to the highest version ID in the local WINS database for records the server owns. This can occur when a new name record is registered and added locally or if an IP address change occurs for an existing record.

With persistent connections, you can reduce the update frequency for push notifications, by specifying a non-zero value instead. If a value greater than zero is used, WINS only starts push replication when the highest ID for records it owns has increased an equal number of times.

For example, the current highest version ID for an example server, WINS-A, is currently 1C4 (which is 452 in converted decimal notation). WINS-A also has its Number of changes in version ID before replication set to 2 for either all or some of its push partners.

Suppose that the following four distinct sets of database changes are then made to the WINS server database at WINS-A:

  1. HOST-A refreshes its previously registered name record, though it does not change its IP address.
  2. HOST-B registers a name record, creating a new dynamic name-to-address mapping to the database.
  3. HOST-C registers a previously released name record and, in the process, reports an updated change of IP address for this record.
  4. A pull replication occurs at a specified interval with another WINS server.

Once these changes are entered into the database, the newly revised highest version ID for WINS-A is 1C6 (454 decimal). This is because the changes made to WINS server data that were caused by items 2 and 3 (either a client registering a new mapping or updating the IP address used with a previous mapping) each caused the version ID at that server to increment.

For items 1 and 4 in the previous list of changes, the highest version ID at the WINS server does not increase.

After these changes occur, any or all partners of WINS-A that are configured with a Number of changes in version ID before replication of 2 would then be push notified by WINS sending a replication trigger to those servers.

Example: How push with propagation works

The following figure shows an example of the use of push partners in a replicated WINS network of four servers. In this example, two of the servers—WINS-A and WINS-B—are located at regional data center locations.

Example: WINS push with propagation in a push replication design

These servers are both central hub servers in a multiple hub-and-spoke enterprise WINS replication design. In order to ensure frequent convergence of names data between the separate regional hubs, both WINS-A and WINS-B maintain a full push/pull relationship with each other.

WINS-C and WINS-D are site or branch-level spoke servers used on the same replicated WINS network. Respectively, they are both configured as push-only partners of WINS-A and WINS-B.

If updates occur at one hub WINS-A, it is unlikely a remote spoke operating as a push-only partner (WINS-D) would receive those updates in a timely or predictable manner. Although replication between the hubs might occur frequently enough to pose no significant issues, setting the update count to an arbitrarily high value at WINS-B might delay convergence at WINS-D until more than one replication cycle has been completed.

To administratively correct this delay, you can initiate a push replication trigger at WINS-A to be sent to WINS-B, which would queue a replication immediately between the hubs. In doing so, if you also chose the Propagate to all partners when manually starting push replication, then WINS-B would propagate the push replication trigger to WINS-D. This would result in an early notification to WINS-D of the need to use a pull replication to WINS-B, obtaining any interim updates from WINS-A.

Note

  • In addition to modifying settings for push replication properties, WINS also provides you the option to enable the use of persistent connections with either a specified push partner or all push partners of a WINS server.

    For more information, see either Persistent connections or To enable the use of persistent connections with a partner server.


WINS resolution

  • Resolution overview
  • Registering names
  • Releasing names
  • Renewing names
  • Resolving names


Resolution overview

WINS is used to resolve NetBIOS names, but in order for name resolution to be effective, clients need to be able to dynamically add, remove, or update their names in WINS. The following sections provide a functional description of each of these processes, specifically how names are registered, renewed, released, and resolved for clients on a WINS-based network.

This process of WINS client/server communications is outlined in the following graphic:

WINS resolution overview

In a WINS system, all names are registered with a WINS server. The names are stored in a database on the WINS server which answers requests for name-to-IP address resolution based on the entries in this database.

Redundancy and load balancing are maintained with more than one WINS server in the network. Periodically, servers replicate their database entries among one another in order to maintain a consistent view of the NetBIOS namespace.

Each name has an entry in the database. It is owned by the WINS server it registered with and is a replica on all other WINS servers. Each entry has a state associated with it--the entry can be in the active, released, or extinct (also known as tombstone) state. Entries are also assigned a version ID. This number is used in the replication process and is discussed in more detail in WINS replication. For more information, see Push partners.

WINS also allows the registration of static names. This enables the administrator to register names for servers running operating systems that are not capable of dynamic name registration. WINS distinguishes between dynamic and static entries. Static names are treated somewhat differently than dynamic names. For more information, see Using static mappings.


Registering names

Name registration is a WINS client requesting the use of a NetBIOS name on the network. The request may be for a unique (exclusive) or a group (shared) name. NetBIOS applications can also register one or more names.

As illustrated in the following figure, a WINS client (HOST-C) sends a Name Registration Request directly to its configured WINS server, WINS-A.

How clients register in WINS

WINS-A can accept or reject the name registration request by issuing either a positive or negative name registration response to HOST-C. The action taken by WINS-A depends on several factors:

  • Whether the name already exists in the server database at WINS-A
  • If a record of the name exists, the state in the server database of the record at WINS-A might make a difference. Also, if the recorded IP address for the name is the same or different from the IP address of the requesting client, HOST-C.
  • Whether the request is for a unique or group name entry.

If the name does not exist in the database, it is accepted as a new registration and the following steps occur:

  1. The name for HOST-C is entered with a new version ID, given a time stamp, and marked with the owner ID of the WINS server.

    The time stamp is calculated based on adding the value of the Renew interval (which by default, is 6 days) set on the WINS server to the current date and time of the server.

  2. A positive registration response is sent back to HOST-C with a Time-to-Live (TTL) value equal to the time stamp recorded for the name at WINS-A.

Name registered for same IP address

If the name HOST-C is already entered in the database with the same IP address as that being requested, the action taken depends on the state and ownership of the existing name.

  1. If the entry is marked as active and the entry is owned by the server (WINS-A), the server updates the time stamp for the record and returns a positive Response back to the client.
  2. If the entry is marked as being either released or tombstoned, or if the entry is owned by another WINS server, the registration is treated as a new registration. Time stamp, version ID, and ownership are all updated and a positive response is returned.

Name registered for different IP address

In the case where the name exists in the WINS database but with a different IP address than that being requested, the WINS server is expected to avoid duplicate names. If the database entry is in the released or tombstone state, the WINS server is free to assign that name.

If, however, the entry is in the active state, the node holding the name is challenged to determine if it still exists on the network. In this case, the WINS server (WINS-A) could perform a challenge of the name and do the following:

  1. WINS-A sends a Wait for Acknowledgment (WACK) response to the requesting client (HOST-C), specifying a time in the TTL field that the client should be prepared to wait for a response.
  2. WINS-A then issues a name query request to the node currently registered for this name in the server database.
  3. If the node still exists, it sends a positive response back to WINS-A.
  4. WINS-A, in turn, sends a negative name registration response back to the requesting client (HOST-C), rejecting the name registration.
  5. If a positive response is not received back from the first challenge query made by WINS-A, two subsequent name query requests are made. After three attempts with no response, the challenge process is complete and a positive registration response is returned to the requesting client (HOST-C) and the name updated in the server database for the new client registration.

Notes

  • Unlike WINS-enabled clients, which can directly contact a WINS server, non-WINS clients (such as NetBT b-node clients) must register and then continuously defend their names by sending and replying to broadcast name queries within the local network.
  • NetBIOS names are registered with the Windows Internet Name Service (WINS) and are normally released when the computer is properly shutdown. If the computer was not properly shutdown, or the computer was not able to contact a WINS server during shutdown, the nbtstat command can be used to refresh in WINS the local names for this computer. This can be useful for mobile or portable computers that are moved between different locations on a network.

    For more information, see To verify WINS registration of client NetBIOS names.


Releasing names

Name release occurs when a WINS client computer finishes using a particular name, when a proper shutdown occurs. In releasing its name, a WINS client notifies its WINS server (or potentially other computers on the network) that it is no longer using its registered name.

As shown in the following figure, when a WINS-enabled client (HOST-C) releases its name, the following steps occur:

How clients release names in WINS
  1. The computer named HOST-C either shuts down properly or a user enters the nbtstat -RR command, initiating a name release request to be sent to the WINS server, WINS-A.
  2. WINS-A marks the related database entry for HOST-C as released.

    If the entry remains released for a period of time, WINS-A marks the entry as tombstoned, updates the version ID for the entry, and notifies other WINS servers of the change.

  3. WINS-A returns a release confirmation message to the WINS client, HOST-C.

If a name entry is marked as released, the WINS server can immediately update or revise a marked name entry when a new registration request arrives from a WINS client with the same name but with a different IP address. This is possible because the WINS database shows that the WINS client at the old IP address is no longer using that name. For example, this can happen when a DHCP-enabled laptop changes subnets.

Name release is most often used to simplify WINS registration for clients that shut down and restart on the network. If a computer released its name during a normal shutdown, the WINS server does not challenge the name when the computer reconnects. If a proper shutdown did not occur, the name registration with a new IP address causes the WINS server to challenge the previous registration. When the challenge fails (because the client computer is no longer using the old IP address), the registration succeeds.

In some cases, a client is not able to release its name by contacting the WINS server, so broadcasts must be used to release a name. This can happen when a WINS-enabled client shuts down without receiving confirmation of its name release by the WINS server.


Renewing names

Periodic name renewal is required for WINS client computers to renew their NetBIOS name registrations with the WINS server. The WINS server treats name renewal requests similarly to new name registrations.

When a client computer first registers with a WINS server, the WINS server returns a message with a Time-To-Live (TTL) value that indicates when the client registration expires or needs to be renewed. If renewal does not occur by that time, the name registration expires on the WINS server and the name entry is eventually removed from the WINS database. However, static WINS name entries do not expire, and therefore, do not need to be renewed in the WINS server database. For more information, see Using static mappings.

The default Renew interval for entries in the WINS database is six days. Renewal occurs every three days for most WINS clients because WINS clients attempt to renew their registrations when 50 percent of the TTL value has elapsed.

A name must be refreshed before this interval ends or it will be released. Names are refreshed by sending a name refresh request to the WINS server, as shown in the following figure.

How clients refresh names in WINS

It is the responsibility of the client (HOST-C) to refresh its name before the Renew interval expires. If the WINS server, WINS-A, does not respond to the refresh request, the client (HOST-C) can increase the rate at which it attempts to refresh its name.

Important

  • In most cases, the default value is the appropriate Renew interval. You should always set the same Renew interval for all server replication partners whenever multiple WINS servers are used.
  • Incorrectly adjusting the Renew interval can adversely affect system and network performance.


Resolving names

Name resolution for WINS clients is an extension of the same name resolution process used by all Microsoft NetBIOS over TCP/IP (NetBT) clients to resolve NetBIOS name queries on your network. The actual method of name resolution is transparent to the user.

For Windows 2000, WINS clients use the following sequential flow of options for resolving a name once the query has been made by using net use or a similar NetBIOS-based application.

  1. Determine if the name is longer than 15 characters or if it contains periods ("."). If so, query DNS for the name.
  2. Determine if the name is stored in the remote name cache at the client.
  3. Contact and try configured WINS servers to attempt to resolve the name using WINS.
  4. Use local IP broadcasts to the subnet.
  5. Check an Lmhosts file if Enable LMHOSTS Lookup is enabled in the Internet Protocol (TCP/IP) properties for the connection.
  6. Check a Hosts file.
  7. Query a DNS server.

For a more detailed explanation and flowchart of this process, see the Windows 2000 Server Resource Kit Networking Guide.


WINS features

  • Persistent connections
  • Burst handling
  • Deleting and tombstoning records
  • Blocking replication partners


Persistent connections

For Windows 2000 Server, WINS introduces persistent connections between WINS server replication partners. This feature is helpful because typically WINS servers disconnect from their replication partners each time replication is completed. In many cases, where WINS servers are interconnected through high speed local area network (LAN) links it is preferable to keep connections open, instead of closing them after replication is completed.

For earlier versions of WINS, servers had to establish new WINS-server connections each time replication was performed. Each connection required a modest number of processor cycles. For efficiency, network managers often configured systems to accumulate a larger number of changes before connecting for replication. These reconnections sometimes caused delays (perhaps as long as several minutes) in the replication process, which meant that inconsistencies in server data commonly existed when WINS was updated.

Persistent connections increase the speed of replication because a server can immediately send records to its partners, without incurring the cost of establishing temporary connections each time. Every record is immediately updated across the network upon registration in WINS, making replication more consistent. The bandwidth used by persistent connections is minimal because the connection is usually idle.


Burst handling

WINS servers can now support handling of high-volume (burst) server loads. Bursts occur when a large number of WINS clients actively and simultaneously try to register their local names in WINS, such as when a power failure occurs. When power is later restored, many users start and register their names simultaneously on the network, which creates high levels of WINS traffic. With burst-mode support, a WINS server can respond positively to these client requests, even before it processes and physically enters those updates in the WINS server database.

How burst handling works

Burst mode uses a burst-queue size as a threshold value. This value determines how many name registration and name refresh requests sent by WINS clients are processed normally before burst-mode handling is started. By default, the value is 500. A WINS server initiates burst handling whenever the number of WINS client registration requests exceeds the burst queue size.

In burst handling, additional client requests are immediately answered with a positive response by the WINS server. The response also includes a varied Time-To-Live (TTL) to clients, which helps regulate the client registration load and distribute processing of the requests over time. This slows the refresh and retry rate for new WINS clients and regulates the burst of WINS client traffic.

For example, if the burst queue size is 500 entries and more than 500 requests are active, the WINS server replies immediately to the next 100 WINS client registration requests by sending early success responses with a starting TTL value of 5 minutes. For each additional round of 100 client requests, 5 minutes more are added to the TTL up to a maximum of 50 minutes. If WINS client traffic still arrives at burst levels, the next round of 100 client requests are answered with the initial TTL value of 5 minutes, and the entire process for incrementing the response TTL is repeated.

This behavior continues until the WINS server reaches its maximum intake level of 25,000 name registration and refresh queries. At this point, the WINS server begins dropping queries.

Using the WINS console, you can choose to configure the level of burst handling used by the server which modifies the size of the burst queue to accommodate either a low, medium or large burst situation.

Note

  • Any WINS server running either Windows 2000 Server or Windows NT Server 4.0 (with Service Pack 3 or later installed) can use burst handling.


Deleting and tombstoning records

WINS now provides improved database management through support for the following deletion operations:

  • Simple deletion, for deleting WINS database records stored on a single server database.
  • Tombstoned deletion, for deleting WINS database records replicated to databases on other WINS servers.
  • Multiple-group selection of displayed database records, for either simple or tombstoned deletion.

The WINS console also provides a simple and convenient utility for administratively removing records of any type, regardless of whether they are statically or dynamically added. In previous releases of Windows NT Server, other available WINS management tools could only administratively delete entries (such as static mappings) that were added in the same way.

How simple deletion works

Simple deletion removes the records that are selected in the WINS console only from the local WINS server you are currently managing. If the WINS records deleted in this way exists in WINS data replicated to other WINS servers on your network, these additional records are not fully removed. Also, records that are simply deleted on only one server can reappear after replication between the WINS server where simple deletion was used and any of its replication partners.

How tombstoning works

Tombstoning marks the selected records as tombstoned, that is, marked locally as extinct and immediately released from active use by the local WINS server. This method allows the tombstoned records to remain present in the server database for purposes of subsequent replication of these records to other servers.

When the tombstoned records are replicated, the tombstone status is updated and applied by other WINS servers that store replicated copies of these records. Each replicating WINS server then updates and tombstones these records. When all WINS servers complete replication of these records and a specified length of time (determined by the Verification Interval for each WINS server) elapses, then the records are automatically removed from WINS.

In most cases, WINS records should be tombstoned at the WINS server that originally owned them, to prevent deleted records from reappearing in WINS after subsequent replication with other servers.

The owner of a given WINS server record is typically the first server contacted by the WINS client during the registration process and the server first actually used to register the local names of the client in WINS. In most cases, the WINS server that owns a client name record in WINS corresponds to the primary WINS server configured on the WINS client computer. If the configured primary WINS server is not available during client registration, a configured secondary WINS server can perform the actual registration of the client name and become the owner.

Example: Tombstoned deletion in replicated WINS

Where tombstoned deletion is used at an owner WINS server in a replicated WINS network, the following sequence of events occurs to effect full removal of the selected records from all WINS servers that replicate the selected records.

  1. The owner WINS server marks and changes the status of the selected WINS records in its local WINS server database from Active to Tombstoned.

    WINS then treats the records as inactive and released from use. When these records are tombstoned locally, the owner WINS server does not respond to or resolve NetBIOS name queries for these names unless the records are registered again by the WINS client.

  2. The owner WINS server replicates the selected records as tombstoned at subsequent replication cycles.

    The records are not forcibly and immediately removed from WINS, but are flagged or marked for eventual deletion. The exact replication cycle interval is configured by the server Intervals properties, which you set in the WINS console. Records are not removed from WINS data until the time specified in the Extinction Interval has elapsed. This allows other WINS servers to be notified that these records are no longer in use, update their replicated mappings for these records, and further replicate this updated WINS data to other servers.

  3. Records become extinct on all replicated WINS servers and are eventually removed physically from all WINS servers.

    After all WINS servers that participate in replication complete a full replication cycle and arrive at a consistent state, the tombstoned records expire and are removed from the WINS database of each server at the next database scavenging operation. After scavenging occurs on all servers, the records no longer appear in the WINS console and are no longer physically stored in the WINS database.

Note

  • Even if records are manually tombstoned (or otherwise marked as released by WINS), released records remain in the WINS database for some time before being completely removed during subsequent scavenging operations. Typically, the period before records extinction is the sum of the following settings:

    • Extinction interval
    • Extinction time-out
    • Verification interval

    You can view and configure these settings on the Intervals tab, located in the WINS <Server name> Properties dialog box. By default, the sum of these settings is 36 days.


Blocking replication partners

After a WINS server is removed from a network, records it owns often continue to be distributed to other servers in a replicated WINS environment. In some cases, WINS either does not delete entries owned by servers no longer active on the network or, by default, preserves stale mappings for an extended period of time. The reasons for this can include:

  • Static mappings originally made at the inactive WINS server replicate indefinitely among the other active WINS servers in the network, unless manually deleted or tombstoned.

    By default, WINS servers preserve static name-to-address mappings whenever such mappings are challenged. This can occur when a WINS client attempts to register or update a static mapping with a dynamic-type mapping of the same name. This behavior, however, can be modified. For more information, see Using static mappings.

  • Dynamic mappings originally registered at the inactive WINS server are not immediately removed from the WINS database.

    In the case of dynamic entries, WINS must check with an owner server before entries are deleted. If a WINS server is no longer in use, other WINS servers conservatively retain records they cannot verify as expired on an owner server. For example, even if an owner is deleted in the WINS console for a particular server, these unwanted or stale names can continue to be replicated throughout the WINS network from other servers storing replica entries of these names.

    WINS processes removal of dynamic-type records according to the Intervals tab settings for WINS Server Properties, which can be configured at each server. In most default cases, a typical extinction period of 36 days passes before a record is fully removed from the database through the scavenging process.

For Windows 2000 Server, the Block records for these owners feature (formerly known as PersonaNonGrata) provides a way to block further replication of entries owned by inactive servers. It allows you to specify the IP addresses of inactive WINS servers that own records you want to assure are removed from WINS in a timely manner.

Because it can prevent any further replication of unwanted or stale mappings between active WINS servers remaining on the network, this feature is most useful when you need to remove WINS servers from your network.

Example: Blocking records owned by a WINS server

The following graphic shows a typical WINS replication design based on the recommended hub-and-spoke WINS replication design model.

Blocking WINS replication in a hub-and-spoke configuration [image] .

In the example replicated WINS network, WINS-D, is an inactive spoke server in the process of being removed from the network. Because WINS-A is the hub in this design, it must be configured to block records for WINS-D in order to prevent replica entries for WINS-D that are present at other spokes from replicating back to WINS-A and reappearing throughout the network.

When WINS-D server is given blocked partner status, it can be deleted as an owner in the WINS console at WINS-A and its entries will not be replicated back from other spoke servers, such as WINS-B, WINS-C or WINS-E. For more information, see To delete an owner from the WINS database.

Notes

  • If you are not using a hub-and-spoke WINS replication model, it might be necessary to enforce blocking at other servers in your network. If this is the case, you might need to list the blocked partner by blocking records owned by servers or for WINS running on earlier versions, add and configure the PersonaNonGrata registry parameter at each server. These steps can help achieve the intended results of full replication for records owned by the partner to other WINS servers in the network.
  • After adding IP addresses to the list of blocked partners at a WINS server, it is recommended to stop and restart WINS to ensure that the change is in effect the next time replication at that WINS server occurs. For more information, see To start or stop a WINS server.


Using WINS

  • Planning WINS networks
  • Configuring WINS replication
  • Using static mappings
  • Modifying server defaults
  • WINS database management
  • Interoperability issues
  • Migrating from WINS to DNS


Planning WINS networks

Before you install WINS servers on your network, plan the following tasks:

  1. Determine the number of WINS servers that you need.

    One WINS server can handle NetBIOS name resolution requests for a large number of computers. However, consider the location of routers on your network and the distribution of clients in each subnet when you decide how many WINS servers are actually required. For more information, see Planning how many WINS servers to use, below.

  2. Plan the replication partnerships.

    Determine whether to configure WINS servers as either pull or push partners, and set partner preferences for each server. For more information, see Configuring WINS replication.

  3. Assess the impact of WINS communication traffic on slower links.

    Although WINS is designed to help reduce broadcast traffic within between local subnets, it does create some traffic between servers and clients. This can be particularly important if you use WINS on routed TCP/IP networks.

    Also consider the effects of slower speed links (such as those typically used for wide area networks) on both replication traffic between WINS servers and NetBIOS registration and renewal traffic required for WINS clients. For more information, see Planning for network performance, below.

  4. Assess the level of fault tolerance within your network for WINS.

    Consider how shutting down a WINS server (even temporarily) affects your network. Use additional WINS servers for disaster recovery, backup, and redundancy. For more information on planning a fault-tolerant WINS installation, see Planning for fault tolerance, below.

  5. Test and revise your planned WINS installation.

    By testing the performance of your network installation of WINS, you can better identify potential problems before they occur. Use WINS server performance counters, which are available through the use of System Monitor. For more information, see WINS performance monitoring reference.

Planning how many WINS servers to use

On a smaller network, a single WINS server can adequately service up to 10,000 clients for NetBIOS name resolution requests. To provide additional fault tolerance, you can configure a second computer running Windows 2000 Server as a secondary (or backup) WINS server for clients. If you use only two WINS servers, you can easily set them up as replication partners of each other. For simple replication between two servers, one server should be set as a pull partner and the other as a push partner. Replication can be either manual or automatic, which you can configure by selecting the Enable automatic partner configuration check box on the Advanced tab of the Replication Partner Properties dialog box.

A larger network sometimes requires more WINS servers for several reasons including, most importantly, the number of client connections per server. The number of users that each WINS server can support varies with usage patterns, data storage, and the processing capabilities of the WINS server computer. Some enterprise network environments require more robust hardware to handle WINS activity, so you might benefit from upgrading the server computer.

When planning your servers, remember that each WINS server can simultaneously handle hundreds of registrations and queries per second. The WINS development and testing team compiled the following statistics as a profile of WINS performance during preliminary testing of Windows 2000 Server:

Average registrations/second | 300
Average queries/second | 350

These measurements were based on a server computer running WINS with no other additional services running and installed on currently available hardware. The list of specific hardware used includes the following: a single Intel Pentium II 350 MHz processor, 128 MB of RAM, and a standard IDE hard drive, which was used to store the WINS database. As a point of reference, WINS records data exchanged between servers and clients is typically small. On average, WINS records are about 40 bytes in size.

A conservative recommendation for large networks is to install one WINS server and a backup server for every 10,000 computers on the network. This reflects the previously suggested baseline performance and provides for large-scale power outages that could cause many WINS computers to restart simultaneously. Capacity is dependent upon server and network resources. Processor speed, available RAM, database storage space, and network resources can have a significant impact.

Two factors can enhance WINS server performance:

  • Using two installed processors on the computer running WINS. This can increase performance by almost 25 percent.
  • Using a dedicated high-performance disk drive, separate from the system drive, for WINS replication.

After you establish WINS servers on your intranet, you can adjust the renew interval, which is the time between a WINS client name registration and name renewal. By using this setting to reduce the numbers of registrations, you can tune server response time. The Renew interval is set in the WINS server properties dialog box.

Planning for fault tolerance

To ensure you are planning a fault-tolerant WINS design, ask the following question for each server on your network: What happens to WINS if this server shuts down or if clients cannot reach it?

To help answer the question, consider the two common scenarios in which a WINS server could fail to perform in its role on a network:

  1. Hardware or power failures that require downtime for server repair or maintenance.
  2. A network link or router failure that isolates a WINS server from clients.

To plan for these, determine the maximum length of time any given WINS server could be out of service on your network, factoring in the length of both planned and unplanned outages.

Also consider what happens to your WINS clients if their primary WINS server is shut down. By maintaining and assigning secondary WINS servers for clients, you can reduce the effects of a single WINS server being offline.

Planning for network performance

Begin planning by estimating the amount of network traffic between WINS clients and WINS servers under normal conditions. You should predict and monitor the following:

  • NetBIOS names commonly registered by WINS clients.
  • WINS registration and renewal caused by daily startup of clients.
  • Roving users and their effect when moving within a routed network.
  • WAN links and their effect on replication performance and convergence.

When planning for WINS network performance, its important to understand the types of traffic that WINS clients typically generate on a network, as listed below.

  • Name registration

    For more information, see Registering names.

  • Name refresh

    For more information, see Renewing names.

  • Name release

    For more information, see Releasing names.

  • Name query

    For more information, see Resolving names.

Daily startup of WINS clients

When a WINS-enabled client starts on the network, it sends a name registration request for the computer name, user name, domain name, and any additional Windows NT network client services running on the computer.

A WINS client running Windows 2000 (or earlier versions of Windows NT) usually registers more NetBIOS names than other WINS-enabled clients. The name registration requests generated by a computer running under these versions of Windows can include the following: File Server, Domain, Replicator service, Messenger service, Computer Browser service, and additional network service names.

An active WINS client name registration in a WINS server database replicates to all pull partners configured on that WINS server. Eventually, the active name registration replicates to all WINS servers on the network.

When a WINS client is shut down at the end of a workday, it releases the name. When the computer is restarted at the beginning of next workday, the WINS client registers the name again with the WINS server and receives a new version ID. This new, active name registration entry replicates to the pull partners of the WINS server.

Assuming that this cycle occurs each day for each computer, the number of name registration entries replicated each day is approximately the number of computers that start each day multiplied by the number of NetBIOS names registered at each computer.

On large networks (50,000 or more computers), the biggest traffic load represents the name registration requests generated when WINS clients start on the network.

Planning considerations for routed WINS networks

When planning for WINS client traffic on large routed networks, consider the effect of name query, registration, and response traffic routed between subnets. Name requests and responses that occur at the daily startup of computers must pass through the traffic queues on the routers, and can cause delays at peak times.

Roving or mobile users also present challenges for planning WINS in routed networks. When a user stops a computer and then moves it to another location--starting the computer on a different subnet with a different primary WINS server--the resulting changes can generate name-challenge traffic for WINS.

Typically, the name registration request is answered with a brief "Wait for Acknowledgment" message. Assuming the name being registered was previously replicated to the new server, it challenges the IP address currently in its database for this name with a brief query. When, as expected, there is no reply, the WINS server retries the challenge two more times for a total of three attempts. If all three attempts fail, the challenge is successful and the new WINS server updates the name registration entry in its database with the new IP address, incrementing the version ID. The new version ID indicates that the entry must be replicated from its new owner--the new WINS server--to other WINS servers on the network.

You can estimate WINS client traffic based on the behavior of the WINS clients, as described in the preceding sections. However, when estimating WINS client traffic, also consider the network topology and the design or configuration of the network routers. In some cases, it is not possible to predict the traffic load on a specific network router because the routers are configured to autonomously route traffic based on factors other than traffic load.


Configuring WINS replication

Before configuring replication, you should first carefully design and review your WINS replication topology. For wide area networks (WANs), this planning can be critical to the success of your deployment and use of WINS. In general, WINS offers you the following options and possibilities to choose from when you are configuring replication:

  • You can manually configure WINS replication for a WAN environment.
  • For some larger campus networks, you might also configure WINS to replicate within a LAN environment.
  • In smaller or bounded LAN installations, you might consider enabling and using WINS automatic partner configuration for simplified setup of WINS replication.
  • In some larger or more global installations, you might have to configure WINS across untrusted Windows NT domains.

Replication across wide area networks

When configuring WINS replication, the two most important planning issues are:

  • Whether your WINS replication occurs over slower WAN links.
  • The length of time required for all replicated changes in the WINS database to converge and achieve consistency on the network.

The frequency of WINS database replication between WINS servers is a major planning issue. The WINS server database should be replicated frequently enough to prevent the downtime of a single WINS server from affecting the reliability of the mapping information in other WINS servers. However, the time interval between replications should not be so small that it interferes with network throughput.

Network topology can influence your decision on replication frequency. For example, if your network has multiple hubs connected by relatively slow WAN links, you can configure WINS database replication between WINS servers on the slow links to occur less frequently than replication on the local area network or on fast WAN links. This reduces traffic across the slow link and reduces contention between replication traffic and WINS client name queries.

For example, as shown in the following figure, the intervals used for configuring pull replication for WINS servers could be set according to proximity between servers and the likelihood of a high-speed link connecting servers configured as replication partners of each other.

WINS convergence in a wide area network (WAN)

In this example, two WINS servers--SEA-WINS and ATL-WINS--are located in Seattle and Atlanta. Another two servers--MEX-WINS and SYD-WINS--are located outside the United States in Mexico City and Sydney. Because SEA-WINS and ATL-WINS are located across a higher-speed WAN link, they are configured to replicate once every hour. For the servers outside the United States, replication intervals might be set higher, such as either 3 or 12 hours, because lower-speed links are associated with these connections.

Planning the convergence time

Convergence time is the time needed to replicate a new entry in a WINS database from the WINS server that owns the entry to all other WINS servers on the network. When planning for WINS servers, you must decide what is acceptable as the convergence time for your network.

Using the previous example, if a WINS client in Seattle registers its name with the WINS server in the figure labeled SEA-WINS, other WINS clients in remote locations might query for the client name and not find it in WINS. In some cases, if the address of the client has been changed, the remote locations would only have a mapping for the previous IP address of the client in their local server databases.

WINS clients that query any of the other WINS servers in the figure (that is, ATL-WINS, MEX-WINS, SYD-WINS) only receive a positive and correct response when the new or updated mapping for the client has been fully replicated from the owning WINS server, SEA-WINS, to all of the other servers. Replications from SEA-WINS could be triggered in one of two ways:

  • A push replication trigger is sent based on the frequency of updates made at SEA-WINS.
  • A pull replication trigger is sent to other WINS servers based on the configured Replication interval set in Replication Partners Properties at SEA-WINS.

Given this configuration, a new or updated entry at SEA-WINS is only replicated when the pull replication interval expires, but queries at remote sites for the new name mapping might not succeed until later. This is because the time interval for replication to ATL-WINS is one hour; it is three hours for MEX-WINS; and it is 12 hours for SYD-WINS. In this case, WINS convergence time is calculated as:

12 hours + 2 * (1 hour) = 14 hours

In reality, name query requests can succeed before the convergence time elapses. This happens when the entries replicate over a shorter path than the worst-case path. It also happens when the Number of changes in version ID before replication threshold in push replication settings passes before the Replication Interval expires in pull replication settings. This results in earlier replication of the new entry. The longer the replication path, the longer the convergence time.

Notes

  • After each administrator configures the respective WINS server, you can use Replicate Now (in the WINS console) to start immediate replication between the configured WINS servers.
  • When replication occurs, you can use Find by Owner to view records for the remote WINS server database. However, to make changes to the remote WINS database, you must be logged on under an account with required permissions in the respective domains for both servers involved.
  • Replication can also occur between two separate stand-alone servers that participate in a workgroup.

Replication across local area networks

When configuring WINS replication for local area networks (LANs), the issues are similar to those that occur in WAN environments, although less critical.

Because the speed of the underlying network links for LANs are much greater than for WANs, it might be acceptable to increase the frequency of WINS database replication, by optimizing push and pull parameters for LAN-based replication partners. For push/pull partners, you can do this by decreasing the Number of changes in version ID before replication and Replication interval settings accordingly, from what you would use for WAN-based partners on slower links.

For example, between LAN-based replication partners it often works to enable WINS to use a persistent connection between the servers. If a persistence connection was not used, the normal update count threshold would default to a minimum of 20. With persistence, a smaller update count value can be specified.

Next, you could specify a much smaller number, such as a value of one to three in Number of changes in version ID before replication before WINS sends a push replication trigger to the other partner. For pull partners, you might also consider setting the Replication interval to a value in minutes, instead of hours.

As in WAN replication planning, the WINS server database should be replicated frequently enough to prevent the downtime of a single WINS server from affecting the reliability of the mapping information in other WINS servers. However, the time interval between replications should not be so small that it interferes with network throughput.

For network-intensive environments, it is a good idea to use a network monitoring tool such as Network Monitor to help measure and determine how to optimize your WINS replication strategy.

Automatic partner configuration

You can configure a WINS server to automatically configure other WINS server computers as its replication partners. With this automatic partner configuration, other WINS servers are discovered when they join the network and are added as replication partners.

Automatic configuration is possible because each WINS server announces its presence on the network through periodic multicasts. These announcements are sent as IGMP messages for the multicast group address of 224.0.1.24 (the well-known multicast IP address reserved for WINS server use).

Automatic replication configuration monitors multicast announcements from other WINS servers and automatically performs the following configuration steps:

  • Adds the IP addresses for the discovered servers to its list of replication partner servers.
  • Configures the discovered servers as both push and pull partners.
  • Configures pull replication at two-hour intervals with the discovered servers.

If a remote server is discovered and added as a partner through multicasting, it is removed as a replication partner when WINS shuts down properly. To have automatic partner information persist when WINS restarts, you must manually configure the partners.

To manually configure replication with other WINS servers, use the WINS console to specify roles for each partner and any related information.

Notes

  • Automatic partner configuration is typically useful in small networks, such as single subnet LAN environments. It can, however, be used in routed networks. For WINS multicast support in routed networks, the forwarding of multicast traffic is made possible by configuring routers for each subnet to forward multicast traffic for the reserved WINS server multicast group. The destination IP address for this group is 224.0.1.24 between routed subnets.
  • Because periodic multicast announcements between WINS servers can add traffic to your network, automatic partner configuration is recommended only if you have a small number of installed WINS servers (typically, three or fewer) on the reachable network.

Replication between untrusted domains

It is possible to set up WINS replication between one or more WINS servers in domains that do not have a trust relationship. You can do this without a valid user account in the untrusting domain. To configure replication, an administrator for each WINS server must use the WINS console to manually configure that server to permit this replication.


Using static mappings

Mapped name-to-address entries can be added to WINS in either of two ways:

  • Dynamically, by WINS-enabled clients directly contacting a WINS server to register, release, or renew their NetBIOS names in the server database.
  • Manually, by an administrator using the WINS console or command-line tools to add or delete statically mapped entries in the server database.

Static entries are only useful when you need to add a name-to-address mapping to the server database for a computer that does not directly use WINS. For example, in some networks, servers running other operating systems cannot register a NetBIOS name directly with a WINS server. Although these names might be added to and resolved from an Lmhosts file or by querying a DNS server, you might consider using a static WINS mapping instead.

Migrating static mappings to dynamic mappings

Unlike dynamic mappings, which can age and be automatically removed from WINS over time, static mappings can remain in WINS indefinitely unless administrative action is taken.

By default, if during an update process WINS is presented with both a static and dynamic-type entry for the same name, it preserves the static-type entry. You can, however, use the Overwrite unique static mappings at this server (migrate on) feature provided with WINS to change this behavior.

For example, the following graphic shows the default migration behavior for a WINS server, WINS-A, when presented with a registration request by a WINS client, Host C, that challenges a static mapping already in the server database.

Example: Migrate off

In this example, WINS-A prevents the client from registering and updating the statically mapped information for Host C. In the next graphic, the same situation is repeated but in this example, the Migrate feature has been turned on at WINS-A.

Example: Migrate on

As shown in the revised graphic, enabling the Migrate feature at WINS-A permits previously entered static mappings for Host B and C to be overwritten by WINS client computers that attempt to register dynamically and update entries for these same names. This feature is useful in simplifying the update of legacy NetBIOS b-node (broadcast-only) type clients that are later upgraded to support WINS.

Important

  • Never add static mappings for computers that can directly use WINS. Doing so can cause undesirable problems, such as demanding additional work to migrate, delete, or tombstone these mappings in a replicated WINS environment.

Notes

  • You can add static entries either interactively using the WINS console or command-based tools, or by importing an Lmhosts file.
  • The Overwrite unique static mappings at this server (migrate on) feature was designed primarily to migrate records for older non-WINS clients that do not dynamically register themselves in WINS. Some special group names, such as domain [1Ch] names are not affected by this setting.


Modifying server defaults

WINS uses several default server configuration parameters that determine how NetBIOS name records are managed in the WINS server database. These parameters affect the default settings applied by each WINS server for any records stored locally.

The following sections describe the default, minimum, and maximum settings that can be applied for database records. Included is the examination of behavior differences in servers running under each of the released versions of WINS. In most cases, default values are acceptable. In some cases, you might choose to modify the defaults to accommodate special circumstances, such as when a host name change must be made or when you renumber your network so that hosts use different IP addresses.

All of these settings are configured on the Intervals tab of the WINS <Server name> Properties dialog box.

Renew interval

The WINS renew interval setting specifies how often a client renews registration of its names. The following table shows the supported range of values for Renew interval:

Default: | 5 hours (Windows NT Server 3.5) 4 days/96 hours (Windows NT Server 3.51) 6 days/144 hours (Windows 2000 Server and Windows NT Server 4.0)
Maximum: | 999 hours (Windows NT Server 3.5, 3.51, and 4.0) 365 days (Windows 2000 Server)
Minimum: | 40 minutes (Windows 2000 Server and all versions of Windows NT Server)

When adjusting this value from its service default, consider the following guidelines:

Increasing the renew interval ... | Decreasing the renew interval ...
Causes client names to be renewed with WINS less often. | Causes client names to be renewed with WINS more often.
Reduces client registration activity and performance loads on the WINS server. | Increases client registration activity and performance loads on the WINS server.
Allows WINS data to become less consistent with the current state of the network (when WINS names are changed or modified, changes are reflected less quickly in the WINS database). | Allows WINS data to become more consistent with the current state of the network (when WINS names are changed or modified, changes are reflected more quickly in the WINS database).

Important

  • Any changes made to the WINS renew interval also directly affect the extinction interval and extinction time-out values, which are dependent on this setting.

Extinction interval

The WINS extinction interval specifies the time interval between when an entry is marked as Released and when it is marked as Extinct in the WINS database. The default value is dependent on the renew interval and, if the WINS server has replication partners, on the maximum replication time interval. The following table shows the supported range of values for Extinction interval:

Default: | (Dependent on Renew interval)
Maximum: | 999 hours (Windows NT Server 3.5, 3.51, and 4.0) 365 days (Windows 2000 Server)
Minimum: | 40 minutes (Windows NT Server 3.5, 3.51, and Windows 2000 Server) 1 hour (Windows NT Server 4.0)

Extinction timeout

The WINS extinction timeout specifies the interval between when an entry is marked extinct and when the entry is scavenged from the database. The default value is dependent on the renew interval and, if the WINS server has replication partners, on the maximum replication time interval. The following table shows the supported range of values for Extinction time-out:

Default: | (Dependent on Renew interval)
Maximum: | 999 hours (Windows NT Server 3.5, 3.51, and 4.0) 365 days (Windows 2000 Server)
Minimum: | 24 hours (Windows 2000 Server and all versions of Windows NT Server)

Verification interval

The WINS verification interval specifies the time after which the WINS server must verify that old names that it does not own are still active. The default is dependent on the extinction interval. The following table shows the supported range of values for Verification interval:

Default: | (Dependent on Renew interval)
Maximum: | 9999 hours (Windows NT Server 3.5, 3.51, and 4.0) 365 days (Windows 2000 Server)
Minimum: | 24 days (Windows 2000 Server and all versions of Windows NT Server)


WINS database management

  • Finding and viewing WINS records
  • Maintaining the WINS database
  • Checking the WINS database for consistency


Finding and viewing WINS records

The WINS console provides two primary methods for displaying WINS database records:

  • Find by Name is used to query and filter displayed results to a limited number of NetBIOS name records that start with a specified set of one or more characters.
  • Find by Owner is used to display WINS server data for one or more owners (WINS servers). This feature also supports additional filtering of the displayed results to show only records of selected NetBIOS name record suffix types.

Finding records by name

Find by Name locates records through either a full NetBIOS name or a specified set of matching characters. When typing characters in Find by Name, you can enter some or all of the characters in the name.

For WINS to include a targeted name in the results of a find operation, the name must begin with and contain all of the characters selected in Find names beginning with. However, names that match the search criteria can contain additional characters that follow the string specified.

For example, if the following are all name records that begin with the letter A in the WINS database:

A, AB, AXB

then entering "A" as the search string finds all three records. If you enter "AB" as the search string, only the record "AB" (which matches both of the specified characters) is found. If you enter "ABC" as the search string, none of the three example records would be found or returned in your search results.

When finding records by name, you can control whether WINS uses case-sensitive searching when it checks for specified search string matches in the server database.

By default, WINS searches for all records by name that match the specified search string, and does not perform case-sensitive searches. Names that have a mixture of upper and lower case letters are viewed as being equal. If the Match case option is used, case-sensitive searches occur instead.

For example, the following are all name records in the WINS database:

ABC, Abcd, aBcE

If you were to enter "Ab" as the search string, WINS performs the search depending upon whether Match case is selected. If selected, only the "Abcd" record is found. If cleared, all three example records are found.

Find by Name is ideal for either targeting a known name or similar names located on a specific WINS server. For example, it can be used to troubleshoot WINS name resolution problems in a wide area network (WAN) by verifying that a known NetBIOS name exists in data stored at any of your remote WINS servers. This command typically generates minimal network traffic and can be used routinely for locating the source of "name not found" errors that result from NetBIOS name resolution.

Viewing records by owner

Find by Owner is ideal for doing full display searches and obtaining either a full or filtered view of the WINS database, for one or more servers that own records registered in the database.

Because this type of viewing potentially requires WINS to pull data from one or more servers, its use should be handled carefully in WINS networks where either a large amount of data is stored and replicated or a large number of WINS servers are involved. However, for in-depth troubleshooting and close viewing of local WINS databases (either local viewing on the same WINS server computer or viewing a WINS server on the same local area network), this feature should not present an overly demanding load for either the WINS server or the local area network involved.

However, if for Display records for either All owners or a remote owner (such as another WINS server located on a WAN) is selected when using This owner, this command might generate a substantial or undesirable increase in network traffic. For this reason, it should be used either sparingly or during off-peak hours.

When viewing records by owner, you can additionally filter WINS data to be included in the view by selecting and using NetBIOS name suffix types as criteria.

For example, to isolate browsing problems associated with the Computer Browser service when WINS clients are using browsing on a WAN, you can filter WINS data by including only those records that use the [1Bh] suffix type, which maps the domain master browser record for each primary domain controller (PDC) in a Windows NT domain environment. For more information on browsing and WINS, see Locating network services.

The WINS console provides you with the ability to add, edit, and remove your own NetBIOS name suffix filter types. It also provides a pre-defined list that is sufficient for typical use.


Maintaining the WINS database

The WINS console provides tools for maintaining the WINS server database. For example, you can use the WINS console to backup and restore WINS server database files. This should be done periodically in a way that is similar to other backup operations that are planned and used for saving files on a server computer.

Scavenging and compaction are additional maintenance operations that can be used selectively to help reduce database size and reclaim disk space that is no longer used by the database. For Windows 2000 Server, dynamic compaction is performed automatically by WINS at periodic intervals and manual compaction is not generally necessary.

Backing up the database

The WINS console provides its own backup feature for backing up the WINS server database during normal operation. After you specify a backup directory for the database, WINS performs complete database backups every three hours, by default.

You should also periodically back up the registry entries for the WINS server.

Scavenging the database

Scavenging the WINS server database is the process of deleting and removing obsolete information that remains after changes occur. Like any database, the WINS server database of address mappings needs to be periodically scavenged and backed up.

The local WINS server database sometimes retains both released and old entries that were registered at another WINS server (and replicated to the local WINS server). Automatic scavenging takes place at intervals defined by the relationship between the Renewal and Extinct intervals you define. You can also manually clean the database.

The following table describes the results of scavenging the WINS database for a WINS server. The first column shows the record criteria and state of any database entries before scavenging is started. The second column indicates the state of the same entries after the scavenging process.

Entry state before scavenging | Entry state after scavenging
Active names owned by this WINS server for which the Renew Interval has expired | Marked as Released.
Released names owned by this WINS server for which the Extinction interval has expired | Marked as Tombstoned.
Tombstoned names for which the Extinction timeout has expired | Deleted and removed from the database.
Tombstoned names, replicated from other servers for which the Extinction timeout has expired | Deleted and removed from the database.
Active names replicated from other servers for which the Verification interval has expired | Revalidated.
Tombstoned or deleted names replicated from other servers | Removed from the database.


Checking the WINS database for consistency

Consistency checking helps maintain database integrity among WINS servers in a large network. When you initiate consistency checking at the WINS console, all records are pulled from each owner listed in the current server database, including other WINS servers that are indirect (not directly configured) replication partners.

All records pulled from remote databases are compared to records in the local database, using the following checks for consistency:

  • If the record in the local database is identical to the record pulled from the owner database, its time stamp is updated.
  • If the record in the local database has a lower version ID than the record pulled from the owner database, the pulled record is added to the local database, and the original local record is marked for deletion.

Verifying registered name records on WINS servers

The WINS console provides a Check Registered Names command that enables you to perform the following verification process among WINS servers on your networks:

  • A NetBIOS name records list, that can be specified either manually or within a stored file called Names.txt, that contains names to be used for testing and verification.
  • A WINS server list, that can be specified either manually or within a stored file called Servers.txt, that contains a list of WINS servers to be used in verifying NetBIOS names you specify for testing and verification checking.

WINS uses a NetBIOS names list (such as Names.txt) to build a query and test for those records with any matched records currently registered and stored in local databases at other WINS servers. The list of WINS servers used for checking the specified names is determined by the IP addresses of WINS servers included in a server list (such as Servers.txt) which is the list of WINS servers to query.

Once initiated, WINS completes the name verification check as follows:

  1. The names list is used to build a name query list.
  2. Names are verified by query for the first listed name, starting with the WINS server specified in the server list.
  3. For each name in the names list, WINS queries each server to verify that the name is registered.

    If a failure is encountered, WINS can retry the query up to three times at the same server.

  4. Once the first listed name has been queried and checked at all servers, WINS proceeds to the next name in the list.

The process is repeated until all listed names have been checked at all listed servers. The results and outcome of each name/server query are displayed in Checking Name Registrations.

Typical results include the following:

Status | Description
ok | Indicates both that the query was successfully completed and that the specified name was verified at the current WINS server.
no response | Indicates that the current WINS server did not respond to the NetBIOS name query.
name not found | Indicates that the current WINS server responded to the NetBIOS name query but could not resolve the specified name.

When all specified names have been queried at all specified servers, a summary is provided, which includes the following information:

  • Any specified NetBIOS names that were verified to their mapped IP address.
  • Specified NetBIOS names for which not all WINS servers resolved to the same IP address, indicating that the name is stored and used inconsistently in WINS.
  • WINS servers that generated an incomplete response, indicating that they did not have all of the names specified for verification.
  • WINS servers that did not respond.
  • Specified names for which an IP address could not be verified.

Notes

  • If a WINS database is extremely large, the consistency checking process can be highly resource intensive, affecting network, disk, and processor usage. For this reason, consider doing this during off-peak hours when other network traffic loads and usage are minimal.
  • If the Verify name records with all partners of each selected server check box is cleared, listed names are only verified at each of the specified servers. When this option is selected, replication partners of each listed server are additionally queried for any specified names.
  • For Windows 2000 Server, use the WINS console to perform consistency checking. For earlier versions, consistency checking must be enabled, either through changes to the Windows NT registry or triggered through use of the WINSCL utility, provided as part of the Windows NT 4.0 Server Resource Kit.


Interoperability issues

Using DHCP with WINS

When using DHCP and WINS together on your network, consider the following options for interoperation:

  • Use additional DHCP scope options.

    Specifically, use DHCP options to assign WINS node types (option type 46) and to identify WINS servers for use by DHCP clients (option type 44). In some cases, this can involve adjusting these option types for each physical subnet in which DHCP and WINS are implemented.

  • Assign a length of time for DHCP lease durations comparable to the time WINS uses for renew intervals, when both services are deployed.

    By default, DHCP leases are three days in length and the WINS renew interval is six days. If lease lengths for DHCP widely differ from WINS renew intervals, the effect on your network can be an increase in lease-management traffic and might cause a WINS registration for both services. If you shorten or lengthen the DHCP lease time for clients, then modify the WINS renew interval accordingly.

Using DNS with WINS

When using DNS and WINS together, consider the following options for their interoperation:

  • If a large percentage of clients use NetBIOS and you are using DNS, consider using WINS lookup on your DNS servers. If WINS lookup is enabled on Microsoft DNS Service, WINS is used for final resolution of any names that are not found using DNS resolution. The WINS forward lookup and WINS-R reverse lookup records are supported only by DNS. If you use servers on your network that do not support DNS, use DNS Manager to ensure that these WINS records are not propagated to DNS servers that do not support WINS lookup.
  • If you have a large percentage of computers running Windows 2000 on your network, consider creating a pure DNS environment. This involves developing a migration plan to upgrade legacy WINS clients to Windows 2000. Support issues involving network name service are simplified by using a single naming and resource locator service (such as WINS and DNS) on your network. For more information, see Migrating from WINS to DNS.

Multihomed WINS servers

For multihomed WINS servers, where more than one local network connection appears in the the Network and Dial-up Connections folder, Windows 2000 does not guarantee the binding order for NetBIOS when more than one connection is present and active. Therefore, for a multihomed WINS server to function properly, all installed connections should be configured as routable interfaces.

All multihomed WINS servers should have their primary IP addresses assigned to each network connection, configured as push and pull replication partners at other servers that can be reached through each of the respective connections. When configuring replication partners, you can ensure that a specific network connection is used by specifying an IP address for the remote multihomed server you are adding at a WINS server.

Otherwise, when replication partners are specified and resolved by a name entered in the WINS console, it is possible that a packet generated by WINS could use any of the installed interfaces and their respective IP addresses. This seemingly random behavior results from WINS referring to its local IP routing table, which contains all of the installed IP interfaces, before it sends packets to the remote server.


Migrating from WINS to DNS

For pure Windows 2000 Server environments, it is not possible to reduce or even eliminate WINS on your network. The process of removing installed WINS servers from your network is called decommissioning. Before you decide to decommission WINS on your network, consider the following issues:

  • Whether there are Windows-based computers on your network running earlier versions of Windows or Windows NT.
  • Whether client computers in your enterprise run legacy MS-DOS or Windows-based programs that still require NetBIOS name service, such as NET command-line utilities.

If either of these issues describe your network, you must keep WINS active on your network to provide compatibility with legacy clients and programs. If not, you might proceed with decommissioning WINS servers used on your network.

For example, NetBIOS naming is still required for some BackOffice applications, such as client/server mail configurations that use Microsoft Exchange Server. For more information, search for the title "Microsoft applications that do not require NetBIOS" when using the Business Support Center located at the Microsoft Web site. To access this site, see Updated technical information.

When redesigning or preparing your network for eventual WINS decommissioning, you must first complete a full implementation of DNS as your primary naming service for all Windows-based computers installed and active on your network. For more information on planning and designing your DNS network, see Planning issues.

Once DNS is implemented, the process of decommissioning WINS follows this general sequence:

  1. Reconfigure client computers not to use WINS.

    You must reconfigure your WINS clients to stop the registering and renewing of their names with the WINS servers you want to remove.

    Clients are configured to use WINS based on their TCP/IP configuration. This is done in one of two ways:

    • For clients that are manually configured to use TCP/IP, remove IP addresses for either primary WINS or secondary WINS servers from configured TCP/IP properties for each network connection used by the client computer.
    • For clients that are dynamically configured by a DHCP server for TCP/IP usage, reconfigure options at your DHCP server (including any server, scope, or client-configured options) to no longer provide distribution of option code 44 to clients. This option type is used to provide a list of WINS server IP addresses to clients.

    You can also reconfigure your WINS clients to disable NetBIOS over TCP/IP, though this step is not a required procedure for migrating from WINS to DNS. For more information, see Disabling NetBIOS over TCP/IP.

  2. While reconfiguring clients, verify that DNS is configured and functioning for them.

    When reconfiguring WINS clients to stop registration of their names and use of WINS servers, verify that DNS is fully configured for all clients before removing WINS servers from your network.

    Clients register in DNS on the basis of their being configured for TCP/IP. This reconfiguration is done in one of the two following ways:

    • For clients that are manually configured to use TCP/IP, add IP addresses for either Primary DNS or Secondary DNS servers in the configured TCP/IP properties for each network connection used by the client computer.
    • For clients that are dynamically configured by a DHCP server to use TCP/IP, reconfigure options at your DHCP server (including any server, scope, or client-configured options) to provide distribution of option code 6 to clients. This option type provides a list of DNS server IP addresses to clients.

  3. Turn off WINS servers and remove them from your network.

    After you reconfigure clients to use DNS and stop using WINS for name service, you can begin eliminating WINS servers. For more information, see To decommission a WINS server.

Notes

  • When removing a WINS server, it is important that, whenever possible, any records owned by the server are tombstoned at the server. You can use the Delete Owner command to select the local server from the list of owners and then select Replicate deletion to other servers (tombstone) to accomplish this within a single command operation at the WINS console.
  • If owner or record deletion was performed at another WINS server, consider using the Block records for these owners feature in Replication Partner Properties to prevent the deleted owner or its records from replicating back to the non-owner server used to decommission another server.
  • Even when WINS remains a requirement in your environment, many sites can still benefit from implementation of the DNS and DHCP capabilities provided by Windows 2000.

    For example, you can use DNS dynamic updates and DHCP-DNS integration for proxy update of host (A) and pointer (PTR) resource records registration for earlier non-dynamic clients. In many cases, this helps reduce NetBIOS and WINS traffic.

    For more information, see Dynamic update or Using DNS servers with DHCP


Resources

  • NetBIOS names reference
  • Netshell commands for WINS
  • WINS RFCs
  • WINS performance monitoring reference
  • WINS updated technical information
  • WINS bibliography


NetBIOS names reference

For all Microsoft operating systems that support and use NetBIOS names, the first 15 characters of a name can be specified by a user. However, the 16th character of the name (00-FF hex) always indicates a resource type.

This section contains additional information and examples of NetBIOS names used by Microsoft networking components.

NetBIOS name types: an overview

The following are the most common types of NetBIOS names that can be used in the WINS database. When creating static mappings, these general types are available for selected use.

Type | Description
Unique | Used to associate the computer specified by name in Computer name and a single IP address in IP address for this static mapped entry. When this type is selected, three types of records are statically added to the WINS database for the specified computer name. These are the [00h]WorkStation, [03h]Messenger and [20h] File Server types.
Group | Also referred to as a normal group. This type is used to add a static entry for the computer, specified by name in a static mapping, to a workgroup used on your network. If this type is used, the IP address for the computer is not stored in WINS, but is resolved through local subnet broadcasts.
Domain Name | Indicates a domain name [1C] mapped entry for locating Windows NT domain controllers. For more information, see Locating domain controllers using NetBIOS over TCP/IP (NetBT).
Internet Group | Used for special user-defined administrative groups. You can use this to group resources. For example, you can indicate a group of file or print servers for organizing shared resources that are visible when browsing your network places. Each Internet group is represented by a shared group name of [20h] type in the WINS database.
Multihomed | Used to register a unique name for a computer that has more than one IP address (either multiple adapters each using a single address or one network adapter configured with multiple IP addresses).

NetBIOS Unique Names

Format | Description
computer_name[00h] | Registered by the Workstation Service on the WINS client. In general, this name is called the NetBIOS computer name.
computer_name[03h] | Registered by the Messenger Service on the WINS client. This service is used by the client when sending and receiving messages. This name is usually appended to both the NetBIOS computer name for the WINS client computer and the name of the user currently logged on to that computer when sending messages on the network.
computer_name[06h] | Registered by the Routing and Remote Access service on the WINS client (when the service is started).
domain_name[1Bh] | Registered by each Windows NT Server 4.0 domain controller running as the domain master browser. This name record is used to allow remote browsing of domains. When a WINS server is queried for this name, a WINS server returns the IP address of the computer that registered this name.
computer_name[1Fh] | Registered by the Network Dynamic Data Exchange (NetDDE) services. This appears only if the NetDDE services are started on the computer.
computer_name[20h] | Registered by the Server service on the WINS client. This service is used to provide points of service to the WINS client to provide sharing of its files on the network.
computer_name[21h] | Registered by the RAS Client service on the WINS client (when the RAS Client is started).
computer_name[BEh] | Registered by the Network Monitoring Agent Service and appearing only if the service is started on the WINS client computer. If the computer name has fewer than 15 characters, the remaining character spaces are padded with plus (+) symbols.
computer_name[BFh] | Registered by the Network Monitoring Utility (included with Microsoft Systems Management Server). If the computer name has fewer than 15 characters, the remaining character spaces are padded with plus (+) symbols.
username[03h] | User names for currently logged-on users are registered in the WINS database. Each user name is registered by the Server service component so that users can receive any net send commands sent to the user name. If more than one user logs on with the same user name, only the first computer logged on with that name registers the name.

NetBIOS Group Names

Format | Description
domain_name[00h] | Registered by the Workstation Service so that it can receive browser broadcasts from LAN Manager-based computers.
domain_name[1Ch] | Registered for use by the domain controllers within the domain. These contain up to 25 IP addresses.
domain_name[1Dh] | Registered for use by master browsers, of which there is only one per subnet. Backup browsers use this name to communicate with the master browser, retrieving the list of available servers from the master browser. WINS servers always return a positive registration response for domain_name[1D], even though the WINS server does not register this name in its database. Therefore, when a WINS server is queried for the domain_name[1D], the WINS server returns a negative response, which forces the client to broadcast for name resolution.
group_name[1Eh] | A normal group name. Any computers configured to be network browsers can broadcast to this name, and listen for broadcasts to this name, to elect a master browser. A statically mapped group name uses this name to register itself on the network. When a WINS server receives a name query for a name ending with [1E], the WINS server always returns the network broadcast address for the local network of the requesting client. The client can then use this address to broadcast to the group members. These broadcasts are for the local subnet and should not cross routers.
group_name[20h] | A special group name called the Internet Group is registered with WINS servers to identify groups of computers for administrative purposes. For example, "printersg" could be a registered group name used to identify an administrative group of print servers.
--__MSBROWSE__[01h] | Registered by the master browser for each subnet. When a WINS server receives a name query for this name, the WINS server always returns the network broadcast address for local network of the requesting client.


Netshell commands for WINS

The NetShell commands for WINS offer a fully equivalent command-line tool for administering WINS servers that can be used as an alternative to console-based management. This is useful in the following situations:

  • When managing WINS servers in wide area networks (WANs), commands can be used in interactive mode at the NetShell command prompt to better manage over slow-speed network links.
  • When managing a large number of WINS servers, commands can be used in batch mode to script and automate recurring administrative tasks that need to be performed for all WINS servers.

The following tables list commands available at the NetShell command prompt (as distinguished from the Windows 2000 command prompt) to manage WINS servers. For more information on how to use NetShell commands provided for WINS, see Use WINS command-line tools.

For more information on NetShell, see The netsh command-line utility.

Command | Description
list | Lists all available WINS commands.
dump | Dumps WINS server configuration to command output.
add name | Registers a name to the server. For more information, type add name /?
add partner | Adds a replication partner to the server. For more information, type add partner /?
add pngserver | Adds a list of Persona Non Grata servers for the current server. For more information, type add pngserver /?
check database | Checks the consistency of the database. For more information, type check database /?
check name | Checks a list of name records against a set of WINS servers. For more information, type check name /?
check version | Checks the consistency of the version number. For more information, type check version /?
delete name | Deletes a registered name from the server database. For more information, type delete name /?
delete partner | Deletes a replication partner from the list of replication partners. For more information, type delete partner /?
delete records | Deletes or tombstones all or a set of records from the server. For more information, type delete records /?
delete owners | Deletes a list of owners and their records. For more information, type delete owners /?
delete pngserver | Deletes all or selected Persona Non Grata servers from the list. For more information, type delete pngserver /?
init backup | Initiates backup of the WINS database. For more information, type init backup /?
init import | Initiates import from an Lmhosts file. For more information, type init import /?
init pull | Initiates and sends a pull trigger to another WINS server. For more information, type init pull /?
init pullrange | Initiates and pulls a range of records from another WINS server. For more information, type init pullrange /?
init push | Initiates and sends a push trigger to another WINS server. For more information, type init push /?
init replicate | Initiates replication of the database with replication partners. For more information, type init replicate /?
init restore | Initiates restoring of the database from a file. For more information, type init restore /?
init scavenge | Initiates scavenging of the WINS database for the server. For more information, type init scavenge /?
init search | Initiates search on the WINS database for the server. For more information, type init search /?
reset statistics Resets the server statistics. For more information, type reset statistics /?
set autopartnerconfig | Sets the automatic replication partner configuration information for the server. For more information, type set autopartnerconfig /?
set backuppath | Sets the backup parameters for the server. For more information, type set backuppath /?
set burstparam | Sets the burst handling parameters for the server. For more information, type set autopartnerconfig /?
set logparam | Sets the database and event logging options. For more information, type set logparam /?
set migrateflag | Sets the migration flag for the server. For more information, type set migrateflag /?
set namerecord | Sets Interval and Timeout values for the server. For more information, type set namerecord /?
set periodicdbchecking | Sets periodic database checking parameters for the server. For more information, type set periodicdbchecking /?
set pullpartnerconfig | Sets the configuration parameters for the specified pull partner. For more information, type set pullpartnerconfig /?
set pushpartnerconfig | Sets the configuration parameters for the specified push partner. For more information, type set pushpartnerconfig /?
set pullparam | Sets the default pull parameters for the server. For more information, type set pullparam /?
set pushparam | Sets the default push parameters for the server. For more information, type set pushparam /?
set replicateflag | Sets the replication flag for the server. For more information, type set replicateflag /?
set startversion | Sets the start version ID for the database. For more information, type set startversion /?
show browser | Displays all active domain master browser [1Bh] records. For more information, type show browser /?
show database | Displays the database and records for the specified server. For more information, type show database /?
show info | Displays configuration information. For more information, type show info /?
show name | Displays detailed information for a particular record in the server. For more information, type show name /?
show partner | Displays pull or push (or both) partners for the server. For more information, type show partner /?
show partnerproperties | Displays default partner configuration. For more information, type show partnerproperties /?
show pullpartnerconfig | Displays configuration information for a pull partner. For more information, type show pullpartnerconfig /?
show pushpartnerconfig | Displays configuration information for a push partner. For more information, type show pushpartnerconfig /?
show reccount | Displays number of records owned by a specific server. For more information, type show reccount /?
show recbyversion | Displays records owned by a specific server. For more information, type show recbyversion /?
show server | Displays the currently selected server. For more information, type show server /?
show statistics | Displays the statistics for the WINS server. For more information, type show statistics /?
show version | Displays the current version counter value for the WINS server. For more information, type show version /?
show versionmap | Displays the owner ID to Maximum Version Number mappings. For more information, type show versionmap /?


WINS RFCs

Requests for Comments (RFCs) are an evolving series of reports, proposals for protocols, and protocol standards used by the Internet community. Although TCP/IP standards are always published as RFCs, not all RFCs specify standards.

RFCs are authored by individuals who voluntarily write and submit a draft proposal for a new protocol or specification to the Internet Engineering Task Force (IETF) and other working groups. Submitted drafts are first reviewed by a technical expert, a task force, or an RFC editor, and then assigned a status.

Windows Internet Name Service (WINS) is based on the standard RFCs for designing and implementing NetBIOS over TCP/IP, and are published by the Internet Engineering Task Force (IETF) and other working groups.

RFCs for WINS in Windows 2000

Following are the RFCs supported by WINS in Windows 2000.

RFC number | Title
1001 | Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods
1002 | Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications

Obtaining RFCs

You can obtain RFCs from the Request for Comments Web site. This Web site is currently maintained by members of the Information Sciences Institute (ISI) who publish a classified listing of all RFCs. RFCs are classified as one of the following: approved Internet standards, proposed Internet standards (circulated in draft form for review), Internet best practices, or For Your Information (FYI) documents.

Note

  • RFCs 1001 and 1002 define a standard protocol to support NetBIOS services in a TCP/IP environment. These RFCs describe NetBIOS-over-TCP (NetBT) protocols in a general manner, emphasizing the underlying ideas and techniques used by all NetBT implementations.

    WINS complies with these RFCs and provides an open and standards-based interoperability as a NetBIOS name service. However, because Windows 2000 has added enhancements beyond those specified in the RFCs, WINS servers are more accurately described as enhanced NetBIOS name servers.


WINS performance monitoring reference

For Windows 2000 Server, the WINS Server service includes a set of performance counters that can be used to monitor various types of server activity. To access these counters, you must use System Monitor. For more information, see Using System Monitor.

By default, after WINS is installed on Windows 2000 Server, the following WINS performance counters are available for use in monitoring server activity:

Name | Description
Queries/sec | The rate, in seconds, at which NetBIOS name queries are received by the WINS server. A large number indicates heavy WINS-related message traffic to the server.
Releases/sec | The rate, in seconds, at which NetBIOS release messages are received by the WINS server.
Successful Queries/sec | The rate, in seconds, at which NetBIOS name queries are successfully processed when received by the WINS server.
Successful Releases/sec | The rate, in seconds, at which NetBIOS release messages are successfully processed when received by the WINS server.
Total Number of Conflicts/sec | The rate, in seconds, at which all name conflicts are detected by WINS. This total is determined by averaging the sum of all unique and group name conflicts.
Total Number of Registrations/sec | The rate, in seconds, at which all name registrations are detected by WINS. This total is determined by averaging the sum of all unique and group name registrations.
Total Number of Renewals/sec | The rate, in seconds, at which all name renewals are detected by WINS. This total is determined by averaging the sum of all unique and group name renewals.
Unique Conflicts/sec | The rate, in seconds, at which unique name conflicts are detected by the WINS server. This total is determined by averaging conflicts for unique names only.
Unique Registrations/sec | The rate, in seconds, at which unique name registrations are detected by the WINS server. This total is determined by averaging registrations for unique names only.
Unique Renewals/sec | The rate, in seconds, at which unique name renewals are detected by the WINS server. This total is determined by averaging renewals for unique names only.

Note

  • Values for the following registry key can be used by a member of the local Administrators group:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WINS\Performance

    By changing values stored at this registry path location, you can deny or modify permissions, determining who can view the System Monitor counters used for WINS on the server computer. Values under this key are used by the System Monitor dynamic-link library (Perfctrs.dll) to identify each counter described.


WINS updated technical information

Updated technical information for WINS can be obtained by searching technical articles available from the Personal Support Center at the Microsoft Web site. For more information, see Updated technical information.

You can also obtain additional in-depth information on WINS in the Windows 2000 Server Resource Kit. For more information, see Windows 2000 Resource Kit.


WINS bibliography

For detailed technical information about using WINS, refer to the following texts:

Hunt, C. and R.B. Thompson. Windows NT TCP/IP Network Administration. Sebastopol, CA: O'Reilly and Associates, 1998.

Microsoft Corporation. Managing a Microsoft Windows NT Network. Redmond, WA: Microsoft Press, 1999.

Microsoft Corporation. Optimizing Network Traffic. Redmond, WA: Microsoft Press, 1999.

Minasi, M., Lammle, T. and M. Lammle. Mastering TCP/IP For NT Server Alameda, CA: Sybex, 1997.

Parker, T. TCP/IP Unleashed. Indianapolis, IN: Sams Publishing, 1996.


Troubleshooting

  • Troubleshooting WINS clients
  • Troubleshooting WINS servers
  • Troubleshooting WINS databases
  • Troubleshooting WINS replication


Troubleshooting WINS clients

What problem are you having?

Name resolution failed at client computer.

Cause: The type of name resolution used is not appropriate. Determine whether WINS or DNS is being used for name resolution and if the name failure is occurring for a NetBIOS or fully qualified domain name (FQDN).

Solution: NetBIOS names are 15 characters or less and are typically used to provide named access to NetBIOS services based on a computer or group name, such as Messenger, Server, or Workstation. For example, the short NetBIOS name "PRINT-SRV1" might refer to a computer used for print and file sharing. It might also be known as by a full DNS computer name "print-srv1.example.microsoft.com" when referring to this same computer as a Windows 2000 shared or published printer resource.

For the DNS example name used above, Winsock-based host name resolution is used to associate an IP address to a named computer and further identify it in a system of domains, either on an intranet or the Internet. This is needed for an entirely different set of applications such as to access Web, SMTP mail, FTP, or LDAP servers.

The key point is that each of these name schemes, WINS or DNS, require name resolution for different names used in different applications, and for locating different types of network services. NetBIOS has its own set of applications that demand NetBIOS name resolution, the absence of which can cause network failures. These can be repaired or detected through an Lmhosts file used temporarily to troubleshoot or correct the name resolution failure.

DNS and FQDNs use Winsock-style host name resolution and are primarily used in Windows 2000 and for Active Directory and Internet use. For this type of name resolution, you can also repair or detect most problems through a Hosts file used temporarily to troubleshoot or correct the name resolution failure.

Verify the exact form of the name that has failed during resolution and determine whether the correct type of name resolution was involved.

See also: NetBIOS name resolution, Host name resolution, Lmhosts files.

Cause: The client could be using an application or version of Windows that requires the use of WINS to resolve names.

Solution: Not all Windows computers or applications require WINS or NetBIOS over TCP/IP (NetBT). For example, if the failed name resolution occurred as part of a URL entered in a Web browser or FTP program or as part of an address in an Internet e-mail program, the problem is more likely related to DNS.

In a pure Windows 2000 environment, DNS can be used instead of WINS as a naming service. For a pure environment to exist, both the client and the resource server (the computer the client has targeted for locating by name) must be running Windows 2000. For other cases where either the client or resource server is running an earlier version of Windows or MS-DOS, a mixed environment exists.

In mixed environments, name resolution could fail when any clients need access to shared resources not published through Active Directory. For example, resources such as these could include legacy file and print servers, or domain controllers or member servers used to complete logon or browsing of Windows NT domains. Some examples of applications that a client might use and need WINS to assist in name resolution include My Network Places, the Map Network Drive feature in Windows Explorer, or the net command (Net.exe) and any of its supported options, such as net use or net view.

See also: When to use WINS.

Cause: The client computer may not be correctly configured, or may not be able to use WINS.

Solution: First, determine whether the client is configured or enabled to use both TCP/IP and WINS. Client configuration of WINS-related settings can be done in one of the two following ways:

  1. Manually, by an administrator setting the client TCP/IP configuration.
  2. Dynamically, by a DHCP server providing the client with TCP/IP configuration.

In most cases, computers running earlier versions of Microsoft operating systems are already able to use WINS once TCP/IP is installed and configured for the client. For Windows 2000, administrators can optionally disable NetBIOS over TCP/IP (NetBT) for each client. By disabling NetBT, WINS cannot be used at the client.

In addition, determine whether the client has a valid IP configuration. To check a client IP configuration, use the ipconfig /all command. You can use ipconfig /all|more as a way to slow or pause viewing of the output of this command for screen-by-screen review.

In the command output, verify that the client computer has the following configured for the network where it is connected:

  • a valid IP address
  • a valid subnet mask
  • a default gateway
  • Primary and secondary WINS servers

If the client does not have a valid configuration, you can either use the ipconfig /renew command to force the client to obtain a renewal of its IP configuration with the DHCP server or you can update the TCP/IP configuration for the client manually.

See also: To configure WINS for non-DHCP clients, To configure WINS for DHCP-enabled clients.

Cause: The client may not have basic connectivity with its configured WINS servers.

Solution: To verify whether a client has basic TCP/IP access to the WINS server, first try pinging the WINS server by its IP address.

For example, if the client uses a primary WINS server of 10.0.0.1, type ping 10.0.0.1 at the command prompt on the client computer. If you are not sure what the IP address is for the WINS server, you can usually learn it by repeating the previous command, using ipconfig /all|more if necessary to pause the displayed command output so you can read the WINS server information.

If the WINS server responds to a direct ping of its IP address, try using the nbtstat -RR command at both the client and also at the resource server that the client is attempting to locate by name. This command forces the WINS client services on each computer to send name release and refresh requests to the WINS server and re-register their names.

If the WINS server does not respond to direct pinging of its IP address, this indicates that the source of the problem more likely stems from network connectivity issues between the client and WINS server. If this is the case, follow basic TCP/IP network troubleshooting steps to fix the problem.

See also: To verify WINS registration of client NetBIOS names; Troubleshooting.

Cause: The primary or secondary WINS server may not be able to service the client.

Solution: At the primary or secondary WINS server for the client, use either Event Viewer or the WINS console to see if WINS is started and currently running. If WINS is running on the server, search for the name previously requested by the client to see if it is in the WINS server database. If the name does not appear in the server database, check whether replication is configured correctly and operational between your WINS servers.

See also: View Event Logs, To search for names that begin with a specified set of characters, Troubleshooting WINS replication.

Clients do not use load balancing when connecting to a multihomed server.

Cause: The WINS server providing name resolution for the multihomed server name to network clients is running an earlier version of Windows NT Server that has not been updated.

For all versions of Windows that support NetBIOS over TCP/IP (NetBT), network clients configured to use WINS attempt to resolve any NetBIOS-based name for a computer to its IP address or addresses. To perform this resolution, clients query the WINS server for the address of the multihomed server and receive a list of addresses that are always in the same order. NetBT then takes and sorts the list, arranging multiple IP addresses according to the following three categories:

  • Any IP addresses located on the same subnet as the client are given first priority in the list.
  • Next, IP addresses located within the same network class are listed.
  • Finally, any remaining addresses are listed.

Then, NetBT starts at the top of this list and pings the first address to make sure it is valid. If it gets a reply, it uses the address. If there is no reply, it goes on to the next address.

The problem is that for earlier versions of WINS, within these three categories, the order of addresses is left unchanged from the list provided by the WINS server. This means that, as long as the first address in the list is online, it will be the one that is always used by every WINS client. This does not provide load balancing or 'round-robin' rotation, as DNS servers can perform when more than one name-to-address mapping is available.

Solution: Upgrade WINS servers to Windows 2000 Server or update those running earlier versions of Windows NT Server to the most current Service Pack.

Clients appear to be affected by another problem not described above.

Cause: My problem is not described above.

Solution: Search the Microsoft Web site for updated technical information that might relate to the problem you have observed. If necessary, you can obtain information and instructions that pertain to your current problem or issue.

If you have connection to the Internet, you can obtain the latest updates for Windows 2000 Server at the Microsoft Web site (http://www.microsoft.com/).

For obtaining the latest Service Pack updates for Windows NT Server, see the Microsoft Web site (http://www.microsoft.com/).

Familiarize yourself with other useful documentation and resources for WINS, such as the Windows Internet Name Service (WINS) Troubleshooter.

See also: WINS updated technical information, WINS, Windows 2000 Resource Kit, Microsoft Web site (http://www.microsoft.com/).


Troubleshooting WINS servers

What problem are you having?

The server cannot resolve names for clients.

Cause: Configuration details might be incorrect or missing.

Solution: To help prevent the most common types of problems, review WINS best practices for deploying and managing your WINS servers. Most WINS-related problems start as failed queries at a client, so it is best to start there.

See also: Best practices; Troubleshooting WINS clients.

Cause: The WINS server might not be able to service the client.

Solution: At the primary or secondary WINS server for the client that cannot locate a name, use Event Viewer or the WINS console to see if WINS is started and currently running. If WINS is running on the server, search for the name previously requested by the client to see if it is in the WINS server database.

See also: To search for names that begin with a specified set of characters.

Cause: WINS server is failing or registering database corruption errors.

Solution: Use WINS database recovery techniques to help restore WINS operations.

See also: Troubleshooting WINS databases.

Cause: The name does not appear in the server database.

Solution: Check whether replication is configured correctly and is operational between your WINS servers.

See also: Troubleshooting WINS replication.

Cause: The WINS server answering clients might be returning stale or incorrect information to clients. The WINS server might be affected by a static mapping blocking the dynamic registration of a valid name-to-address mapping for the computer hosting the service or resource in question.

Solution: In general, static mappings are not recommended for clients that can dynamically use WINS to update their name and address information. If the information returned to a client during name resolution is incorrect or stale, check to see if the name entry in the WINS server database was entered statically. If the name was entered using a static type entry, you can choose from the following options to update WINS:

  • Enable Migrate (Overwrite unique static record with dynamic record) in Replication Partners Properties.
  • Edit the static mapping to update the mapped address information.
  • Delete the static entry from WINS.

See also: To enable static mappings to be overwritten during replication; To edit a static mapping entry; To delete or tombstone an entry in the WINS database.

Cause: Replication might not be occurring between all WINS servers.

Solution: In some WINS designs, the use of one-way replication partnerships, such as push-only or pull-only partners, can create situations where WINS names data is not regularly replicated to all network servers.

See also: Troubleshooting WINS replication.

The server intermittently loses its ability to resolve names.

Cause: There might be a split registration problem, where the WINS server is registering its names in WINS at two servers on the network. This is possible when the WINS server settings configured in TCP/IP properties at the server computer are pointing to IP address of remote WINS servers and are not configured to use the IP address of the local WINS server.

Solution: Re-configure client TCP/IP properties at the WINS server to have its primary and secondary WINS servers point to the IP address of the local server computer.

See also: To configure TCP/IP to use WINS, Best practices.

The server appears to be affected by another problem not described above.

Cause: My problem is not described above.

Solution: Search the Microsoft Web site for updated technical information that might relate to the problem you have observed. If necessary, you can obtain information and instructions that pertain to your current problem or issue.

If you have connection to the Internet, you can obtain the latest updates for Windows 2000 Server at the Microsoft Web site (http://www.microsoft.com/).

For obtaining the latest Service Pack updates for Windows NT Server, see the Microsoft Web site (http://www.microsoft.com/).

Familiarize yourself with other useful documentation and resources for WINS, such as the Windows Internet Name Service (WINS) Troubleshooter.

See also: WINS updated technical information, WINS, Windows 2000 Resource Kit, Microsoft Web site (http://www.microsoft.com/).


Troubleshooting WINS databases

What problem are you having?

WINS backups are failing consistently.

Cause: The specified WINS backup directory might be a remote drive.

Solution: Make sure that the path for the WINS backup directory is on a local disk on the WINS server. WINS cannot back up its database files to a remote drive.

See also: To modify backup settings.

My WINS database might be corrupt.

Cause: The WINS database might need to be deleted, either fully or partially, so its contents can be replaced from another WINS server to restore consistency and data integrity between WINS servers on your network.

Solution: Depending upon the extent of the corruption, and whether the corrupted records are at an owner or replica WINS server, you can rebuild the local WINS database through replication with another WINS server.

To remove corrupted data at a replica (non-owner) server, use the Delete Owner command option in the WINS console. When using this feature, you can delete the owner and any of its associated records in question from local WINS data.

For an owner WINS server, you can restore data integrity by starting WINS with a fresh database and then initiating replication with a configured replication partner. At the local WINS server that has ownership of corrupted records, perform the following steps:

  1. Stop WINS.
  2. Delete all current WINS database files.

    These files are located at the path currently set in Database path on the Advanced tab in WINS server Properties for the local WINS server.

  3. Restart WINS.

When WINS is started with a blank database, it will replicate back all records (including those for which it is the registered owner) that are contained in data stored at other servers. This is because it starts with a fresh version ID that is lower than the highest version ID in use for data at any of the other WINS servers on your network.

WINS servers use record version IDs to keep track of which records are new and which need to be replicated to other WINS servers. Every record in a WINS database has an owner associated with it. This owner is generally the server with which the WINS client originally registered.

Normally, the owner (in this case, the local WINS server) does not receive its own records from its replication partners. For this reason, if records are lost from the local WINS database, it can typically be difficult to replace these records, even if they exist at other partners. In this solution, this difficulty is solved because records that exist on other WINS servers are certain to have higher version IDs than the local server after you delete the local database and restart WINS.

On a WINS network with many records, two registry entries affect the ability of WINS to perform local database replacement as described in earlier steps. The first value, InitTimeReplication, keeps the server from accepting queries or registrations until the database is reconstructed. The second, InitTimePause, causes WINS to pause while the replication takes place. The location and configurable settings for these keys are discussed more in the following tables.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

InitTimeReplication

Location: | HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WINS\Partners
Type: | REG_DWORD
Default: | 1
Values: | 1 = The WINS server pulls replicas of new WINS database entries from its partners when the system is initialized or when a replication-related parameter changes. 0 = Replication occurs only as often as specified in the value of TimeInterval.

InitTimePause

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WINS\Parameters
Type: REG_DWORD
Default: 0
Values: 0 = WINS does not start in paused state.

1 = WINS starts in paused state.

The value set determines whether WINS starts in a paused state and remains in that state until its first replication is completed. In the paused state, WINS does not accept any name registrations, releases, or queries. WINS remains in the paused state until it has replicated with its partners or until its first replication attempt has failed.

If the value of InitTimePause is set to 1, then InitTimeReplication (in the Pull partners subkey) should either be set to 1 or deleted from the registry.

Additional information about these and other WINS server registry parameters is available in the Windows 2000 Server Resource Kit.

See also: To delete an owner from the WINS database, To start or stop a WINS server, To set the WINS database path, Windows 2000 Resource Kit.

I am still having WINS database problems, different from the ones that are described above.

Cause: My WINS database problem was not described above.

Solution: Search the Microsoft Web site for updated technical information that might relate to the problem you have observed. If necessary, you can obtain information and instructions that pertain to your current problem or issue.

If you have connection to the Internet, you can obtain the latest updates for Windows 2000 Server at the Microsoft Web site (http://www.microsoft.com/).

For obtaining the latest Service Pack updates for Windows NT Server, see the Microsoft Web site (http://www.microsoft.com/).

Familiarize yourself with other useful documentation and resources for WINS, such as the Windows Internet Name Service (WINS) Troubleshooter.

See also: WINS updated technical information, WINS, Windows 2000 Resource Kit, Microsoft Web site (http://www.microsoft.com/).


Troubleshooting WINS replication

What problem are you having?

I can't locate the source of "duplicate name" error messages.

Cause: You might need to manually remove static records, or enable static mappings to be overwritten during replication.

Solution: If the duplicate name exists already as a static mapping, you can tombstone or delete the entry. If possible, this should be done at the WINS server that owns the static mapping for the duplicate name record. As a preventive measure, in cases where a static mapping needs to be replaced and updated by a dynamic mapping, you can also enable Overwrite unique static mappings at this server (migrate on) in Replication Partners Properties.

See also: To delete or tombstone an entry in the WINS database, To enable static mappings to be overwritten during replication.

I need to locate the source of "network path not found" error messages on a WINS client.

Cause: The network path might contain the name of a server computer configured as a p-node, m-node, or h-node and its IP address is different from the one in the WINS database. In this case, the IP address for this computer might have changed recently and the new address has not yet replicated to the local server.

Solution: Check the WINS database for the name and IP address mapping information. If they are not current, you can start replication at the WINS server that owns the name record requiring an update at other servers.

See also: Manage replication.

Cause: If the computer name is configured as b-node, its name might be missing in the WINS database.

Solution: Check the WINS database for the name. If the name is not present in WINS and clients on other subnets need to locate the b-node computer by name, you can add a static mapping in WINS for the computer name and IP address.

See also: Manage static mappings.

The WINS server cannot pull or push replications to another WINS server.

Cause: If the other WINS server is located across a router, there might be a failed router or other network problem.

Solution: Check for network connectivity to the server. Ping the other WINS server and troubleshoot any network or TCP/IP-related problems.

See also: Troubleshooting

Cause: If the other WINS server is located on the same network or can be successfully pinged, the server might not be configured correctly as either a push or pull partner of the other server.

For example, suppose the two WINS servers are called WINS-A and WINS-B. If WINS-A needs to perform pull replications with WINS-B, make sure it is a push partner of WINS-B. Likewise, if WINS-A should push replications to WINS-B, it should be a pull partner of WINS-B.

Solution: Determine the current configuration of replication partners between the servers. If partnerships are missing at either server, add the missing partner IP addresses as needed for the appropriate server. If needed, you can also change the replication partner type, such as from either Pull only or Push only, to Push/Pull.

See also: Configure replication, Change a replication partner type.

I am having intermittent problems with WINS not replicating between servers on my network.

Cause: The replication pattern in use on your network might not be correct or appropriate to use.

Solution: In general, deployments of more than 20 WINS servers are strongly discouraged. Also, for best results and simpler administration, follow a hub-and-spoke replication topology when designing your replicated WINS network that utilizes push/pull partnerships between each WINS hub server and its member spoke servers.

If a single hub-and-spoke exceeds the recommended total of 20 WINS servers for a single enterprise, you should contact Microsoft Consulting Services or Microsoft Product Support Services about how to better revise or reduce your current WINS installation. For larger or enterprise installations, multiple hub-and-spoke designs are acceptable to use.

In rare cases, the limited use of push-only and pull-only partner relationships might be needed. You should, however, carefully review added WINS administration issues when these configurations are deployed. At a minimum, establish reliable support procedures for occasions when you might need to manually trigger replication between WINS servers configured to operate using these types of limited replication partnering.

Cause: The version ID might not be incrementing for WINS entries when replicating on all servers.

Solution: The version ID is incremented in the WINS database by each server that owns and registers a name record. This identifier is a hexadecimal value stored with each name record in the database and is used for version tracking when the record is replicated to other servers.

Version IDs are only incremented for certain types of record changes. For example, a typical refresh of a name in WINS does not increment the version ID, but other changes, such as an updated IP address, can cause the version ID to increment in most cases.

When the version ID is not consistently incrementing for a name record at all servers in the replicated WINS network, you can use either the WINS console or command-line options to administratively increase the starting version count for the server and correct the problem.

See also: To increase the starting version count, Best practices.

I still have a problem with WINS replication not described above.

Cause: My problem is not described above.

Solution: Search the Microsoft Web site for updated technical information that might relate to the problem you have observed. If necessary, you can obtain information and instructions that pertain to your current problem or issue there.

If you have connection to the Internet, you can obtain the latest updates for Windows 2000 Server at the Microsoft Web site (http://www.microsoft.com/).

For obtaining the latest Service Pack updates for Windows NT Server, see the Microsoft Web site (http://www.microsoft.com/).

Familiarize yourself with other useful documentation and resources for WINS, such as the Windows Internet Name Service (WINS) Troubleshooter.

See also: WINS updated technical information, WINS, Windows 2000 Resource Kit, Microsoft Web site (http://www.microsoft.com/).