Implementing and Managing WINS


If you are familiar with Windows NT 4.0 networks, you are undoubtedly familiar with the intricacies of a WINS infrastructure. With Windows Server 2003, WINS is intended and needed only for backward compatibility. A Windows Server 2003 network running in native mode does not need to use WINS at all as DNS is used to provide resole host names into IP addresses.

Until your network is running only Windows Server 2003 (or higher) and no applications on the network require NetBIOS name resolution, you will still need WINS to provide backward compatibility for legacy Windows operating systems, particularly with any NT domains.

Four elements can be found in a WINS network:

  • WINS servers When WINS client computers enter the network, they contact a WINS server using a directed message. The client computer registers its name with the WINS server and uses the WINS server to resolve NetBIOS names to IP addresses.

  • WINS client computers WINS client computers use directed messages to communicate with WINS servers. All versions of Windows since Windows for Workgroups can be WINS client computers.

  • Non-WINS client computers Older Microsoft network client computers that can't use direct WINS communications can still benefit from WINS. Their broadcast messages are intercepted by WINS proxy computers that act as intermediaries between clients that must broadcast and WINS servers. MS-DOS and Windows 3.1 client computers function as non-WINS clients.

  • WINS proxies All versions of Windows client computers since Windows for Workgroups can function as WINS proxies. They intercept broadcasts on their local subnets and communicate with a WINS server on behalf of the broadcasting client computer.

You can set the following intervals on your WINS server. These intervals determine how WINS records and the WINS database are handled:

  • Renew Interval Determines the frequency of record renewal.

  • Extinction Interval Determines the length of time before a released record is considered extinct.

  • Extinction Timeout Determines the length of time after a record has been marked as extinct before it is removed from the database.

  • Verification Interval Determines the frequency at which database records are verified for accuracy.

In most environments that rely on WINS for name resolution, you will want to have more than one WINS server for redundancy and increased availability. To ensure that each server has a current copy of the database, it is important to configure replication between your WINS servers. The following types of replication are available to be configured for the WINS service:

  • Pull replication In pull replication, your server pulls the database from the replication partner. A pull replication is time based and occurs at the time you have configured. You can decide whether to establish a persistent connection for replication, and you can set the start time and interval for replication.

  • Push replication In push replication, your server pushes its database to the replication partner. A push replication is event driven, and the number of database updates determines when the event occurs. You can decide whether to use a persistent connection for push activities, and you can set the number of changes in the version ID before replication.

  • Replication partner type The partner type can be push, pull, or push/pull, depending on your requirements. (In push/pull replication, database replication can occur using either push or pull.)

Whenever possible, it is preferable to communicate through directed messages. This cuts down on the amount of network traffic and ensures that only the affected hosts receive the message. This also ensures that the messages will propagate across routers. Specially, for WINS, Microsoft needed to ensure that WINS communicated primarily with directed messages. This requirement was accomplished by allowing several types of NetBIOS naming methods. These naming methods are commonly called node types. A node is simply a device on a network. Every computer running Windows is configured to use one of four node types. The node type determines whether the computer will register and resolve names through broadcast messages, directed messages, or some combination of broadcast and directed messages. The four node types include the following:

  • b-node (broadcast node) Relies exclusively on broadcast messages and is the oldest NetBIOS name registration and resolution mode. A host needing to resolve a name request sends a message to every host within earshot, requesting the address associated with a host name. b-node has two shortcomings: broadcast traffic is undesirable and becomes a significant user of network bandwidths, and TCP/IP routers don't forward broadcast messages, which restricts b-node operation to a single network segment.

  • p-node (point-to-point node) Relies on WINS servers for NetBIOS name registration and resolution. Client computers register themselves with a WINS server when they come on the network. They then contact the WINS server with NetBIOS name resolution requests. WINS servers communicate using directed messages, which can cross routers, so p-node can operate on large networks. Unfortunately, if the WINS server is unavailable or if a node isn't configured to contact a WINS server, p-node name resolution fails.

  • m-node (modified node) A hybrid mode that first attempts to register and resolve NetBIOS names using the b-node mechanism. If that fails, an attempt is made to use p-node name resolution. m-node was the first hybrid mode put into operation, but it has the disadvantage of favoring b-node operation, which is associated with high levels of broadcast traffic.

  • h-node (hybrid node) A hybrid mode that favors the use of WINS for NetBIOS name registration and resolution. When a computer needs to resolve a NetBIOS name, it first attempts to use p-node resolution to resolve a name via WINS. Only if WINS resolution fails does the host resort to b-node to resolve the name via broadcasts. Because it typically results in the best network utilization, h-node is the default mode of operation for Microsoft TCP/IP client computers configured to use WINS for name resolution. Microsoft recommends leaving TCP/IP client computers in the default h-node configuration.

The following counters are available for monitoring WINS server performance:

  • Failed Queries/Sec Gives you the number of failed WINS queries per second. If this number is very high or suddenly spikes, you might have an issue with WINS resolution.

  • Failed Releases/Sec Gives you the number of failed WINS releases per second. If this number is very high or suddenly spikes, you might have an issue with WINS resolution.

  • Group Conflicts/Sec The rate at which group registrations by the WINS server resulted in conflicts with the database.

  • Group Registrations/Sec The rate at which group registrations are being received.

  • Group Renewals/Sec The rate at which group registrations are being renewed.

  • Queries/Sec The rate at which queries are being received.

  • Releases/Sec The rate at which releases are being received.

  • Successful Queries/Sec The number of successful queries per second. This is useful if you are watching for trends in your WINS usage.

  • Successful Releases/Sec The number of successful releases per second. This is useful if you are watching for trends in your WINS usage.

  • Total Number of Conflicts/Sec This is the sum of the unique and group conflicts per second.

  • Total Number of Registrations/Sec This is the sum of the unique and group registrations per second.

  • Total Number of Renewals/Sec This is the sum of the unique and group renewals per second.

  • Unique Conflicts/Sec The rate at which unique registrations and renewals cause conflicts with the database.

  • Unique Registrations/Sec The rate at which unique registrations are received by the server.

  • Unique Renewals/Sec The rate at which unique renewals are received by the server.

The nbtstat command gives you statistics for NetBIOS over TCP/IP. The utility is used to determine which NetBIOS names the machine has cached and to which IP addresses those names resolved. You need to be aware of the options for using the nbtstat command, as outlined in Table 10.

Table 10. The nbtstat Command Switches

Switch

Description

-a

Displays the name table of a remote machine given its name.

-A

Displays the name table of a remote machine given its IP address.

-c

Displays the cache of NetBIOS names held by the local machine. This is useful for determining which names the local client has requested recently and how they were resolved.

-n

Displays a list of local NetBIOS names.

-r

Displays a list of names that have been resolved by broadcast and via WINS.

-r

Displays a list of names that have been resolved by broadcast and via WINS.

-R

Purges and reloads the remote cache name table.

-s

Displays a sessions table, showing the name of remote machines.

-S

Displays a sessions table, showing only IP addresses for remote machines.

-RR

Performs a release and refresh by sending name release packets to the WINS and then starting a refresh.


One of the easiest ways to ensure that name resolution is working is to hardcode it into the local files that Windows first looks to for information. By entering the information in the local files, you can ensure that the computer does not attempt to resolve the name and will use the address you've specified. Two files are used for name resolution. The first file, the hosts file, resolves IP names into IP addresses and can be thought of as an alternative to DNS. The second file, the lmhosts file, resolves NetBIOS names into IP addresses and can be thought of as an alternative to WINS.

On a Windows Server 2003 computer, the hosts file is located in the %windir%\system32\drivers\etc directory. This is the file you must modify to change the hard-coded host resolution. Entries in the hosts file are simple; they begin with the IP address and are followed by the host name. If you open the hosts file on your system, it will already contain the special localhost name, which you can use as a template for adding new names.

The format of the lmhosts file is different than the hosts file, but it is located in the same %windir%\system32\drivers\etc directory as the hosts file. Unlike the hosts file, no default lmhosts file is created when you install Windows Server 2003. However, Windows Server 2003 includes an lmhosts.sam file that is a sample file you can rename to lmhosts and use as a starting point.

The lmhosts file is similar to the hosts file, except that it has these additional options:

  • #PRE Placed after an entry, it causes the entry to be preloaded. The effect of this is that the entry is permanently loaded into memory. This is a good idea for hosts that will be accessed frequently.

  • #DOM:<domain> Associates an entry with the domain given. It helps the computer locate a domain controller for the network.

  • #INCLUDE <filename> Includes the named file as if it were located in the lmhosts file. This is infrequently used because it incurs additional overhead to process the file.




MCSA(s)MCSE 70-291(c) Implementing, Managing, and Maintaining a Microsoft Windows Server 2003 Network Infrastructure
MCSA/MCSE 70-291: Implementing, Managing, and Maintaining a Microsoft Windows Server 2003 Network Infrastructure (Exam Prep)
ISBN: 0789736497
EAN: 2147483647
Year: 2006
Pages: 196
Authors: Will Schmied

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net