Windows Internet Name System (WINS) is a dynamic distributed database for resolving NetBIOS names to IP addresses. (NetBIOS name server) It is used in a routed environment where NetBIOS clients can register and query NetBIOS names for computers and groups.
NETwork Basic Input/Output System (NetBIOS) is a session layer interface that clients can use to communicate with each other. It provides the following services :
| Network name registrations and verification |
| Session establishment and termination |
| Reliable connection-oriented session data transfer |
| Unreliable connectionless datagram data transfer |
| Support protocol and adapter monitoring and management |
NetBIOS knows two types of 16-byte names, unique and group names. Unique
names are used to communicate with a specific process on a single computer,
group names to send data to multiple computers at once.
The 16-byte name uses 15 bytes for the computer or group name, the 16th byte
describes the service offered. The 16th byte can be :
Unique names :
| [00h]. Workstation service. |
| [03h]. Messenger service. This name is registered for the computer name and the user logged on. |
| [06h]. Routing and Remote access client. |
| [1Bh]. NT 4.0 server running as a domain master browser. |
| [1Fh]. Networking Dynamic Data Exchange (NetDDE) client. |
| [20h]. Server service. |
| [21h]. Remote Access Service client. |
| [BEh]. Client running the network monitor agent. If the computer name is shorter than 15 character it is complete with +'s. |
| [BFh]. Client running network monitor utility. (incl. SMS) If the computer name is shorter than 15 character it is complete with +'s. |
Group names :
| [00h]. Registered by the workstation service so it can receive browser broadcasts. |
| [1Ch]. Domain controllers. This group can contain a maximum of 25 clients. |
| [1Dh]. Master browsers. (one per subnet) |
| [1Eh]. Normal group. Used to elect master browsers. |
| [20h]. Internet group. Can be used for administrative purposes. |
Microsoft clients can use various systems to resolve NetBIOS names to IP addresses :
| B-node (broadcast). This mode is used by default if no WINS server is specified. When a client want to resolve a NetBIOS name, it sends a broadcast on the network. If the searched client is on the same subnet, it will respond with it's IP address. The main disadvantages are that amount of network traffic that is created for each network node on the subnet and that routers normally do not forward broadcasts. This will cause that NetBIOS clients on the other site of the router will not be found. |
| P-node (peer-peer) P-node will use a NetBIOS name server (e.g WINS) to resolve NetBIOS names. P-node will not use broadcasts. |
| M-mode (mixed). Mixed mode first uses a broadcast (B-node) to resolve the NetBIOS name. If this does not work a NetBIOS name server (P-node) is used. |
| H-node (hybrid). This is the default mode used when a WINS server is used. First the NetBIOS name server(s) is/are queried (P-node). If this fails, broadcasts are send (B-node) |
WINS is used to offer NetBIOS clients the ability to resolve NetBIOS names
without broadcasts within a routed environment. This causes the network traffic
to be reduced. Each client can register it's services at the WINS server when
starting and query the WINS server to resolve NetBIOS names of other clients.
Within Windows 2000, clients are automatically installed to provide client-side
support for registering and resolving NetBIOS names. This can be disabled by disabling
NetBIOS over TCP/IP in the WINS tab of the TCP/IP protocol.
The LMHOSTS file is a static ASCII file on a client containing NetBIOS names and IP addresses. The file is stored in the %systemroot%\system32\drivers\etc folder and called lmhosts. There is also a sample file, lmhosts.sam. A lmhosts file contains rows of an ip address and a network clients, e.g :
102.54.94.97 rhino
102.54.94.102 popular
102.54.94.106 etcetera
With these lines you can add the following characters :
| #pre. An entry followed with #pre will be preloaded in the name cache when the WINS client is initialized or when the 'nbtstat -RR' command is used. Put these entries at the end of the lmhosts file for the best performance. |
| #dom:<domain>. This will associate the name with the domain. It is used by the browser and logon services. |
| #include<filename>. Loads and searches NetBIOS entries in a separate
file. This could be a centrally located lmhosts file. When using a NetBIOS
servername in the path to the file, the lmhosts entry of this servername
should be before the #include entry with a #pre entry. The share name that is used to access the central lmhosts file must be in the LanManServer list of NullSessionShares. This can be done by adding the share to the hklm\system\CurrentControlSet\Services\LanManServer\Parameters\NullSessionsShare entry. |
| #begin_alternate, #end_alternate. Within these entries you can define a redundant list of alternate locations for lmhosts files. |
| #nofnr. Avoids NetBIOS-directed name queries for older LAN Manager Unix systems. |
| #mh. Adds multiple entries for a multi homed computer. |
Lines starting with a # are ignored in the lmhosts file. Keep in mind that a
lmhosts file is parsed from above to beneath. Reduce the number of #-lines and
put the #pre entries at the end of the file.
You can disable the use of the lmhosts file in the WINS tab of the TCP/IP
properties. By default it is on.
When a client starts it's services like workstation, server, messenger etc.
they are registered with the computer name in WINS. First the client tries to
register the services with the primary WINS server for three times. If this
fails, the secondary servers are used. (if configured) If this fails or if there is/are
no secondary server(s), a broadcast is send. A client that is not able to
register it's NetBIOS name, will try to register again every 10 minutes.
When a WINS server is available to register the client, it will check if the
name is still available. If the computer name is already in the WINS database,
the WINS server will three times (500 ms intervals) send a challenge to the
machine already in the database. If this machine responds, the other machine is
not able to register it's computer name. If the machine does not respond, the
new owner of the name will be registered. When a client has registered it's
computer name and services within the WINS database, it will be provided by the
WINS server with a successful registration message. This message contains the
Time To Live (TTL) of the entries made.
Non WINS clients can be registered in WINS via Static mappings. First select the Active Registrations in the WINS database. After this choose New Static mapping and enter the computer name, NetBIOS scope (optional), type of service and ip address. You can select the following types of service :
| Unique. The mapping of a computer name to an ip address for the workstation- [00h], server- [20h] and messenger service [03h] |
| Group. Also known as normal group. It adds a computer name to a workgroup. For these records the ip addresses are not stored in the database but resolved via broadcasts. [1eh] This group is used for browsing services. |
| Domain name. [01c]A domain group can contain a maximum of 25 members. After the 25th registration first the replica addresses are overwritten. If they do not exist anymore, it overwrites the oldest registration. |
| Internet group. Groups that can be used for administrative tasks. It can contain a maximum of 25 clients. [20h] |
| Multihomed. A unique computer name can have up to 25 ip addresses. After the 25th address, first the replicas are overwritten. If they are not available anymore, the oldest registration is overwritten. |
Keep in mind that with a group a static member (added via WINS manager or importing a lmhosts-file) does not replace a dynamic member.
When a client has registered it's computer name and services it receives a
TTL for which the entries are valid within the WINS server. By default at the
half of this TTL, the client will send a name refresh request to the primary
WINS server. If this request is accepted, a new TTL is send to the WINS client
by the WINS server.
If the primary WINS server is not available, the client tries to re-register
it's name every 10 minutes with the primary WINS server for the maximum of 1
hour. If this fails, it will try to refresh it's name with the secondary WINS
server. Again every 10 minutes for one hour. If this also fails, the primary
WINS server is tried again for one hour, then the secondary again, etc. This
until the lease time is expired.
If the client is not able to refresh it's computer name, the name is released.
When is WINS client properly shuts down it sends a name release request to the WINS server for each registered name. The WINS server checks the database for the computer name and the ip address. If they match, the WINS server sends a positive name release and sets the computer name to inactive. If the computer name and ip address do not match the name is not released.
When a client wants to make a connection via a NetBIOS name, the following process starts :
| The client checks the NetBIOS name cache. Every NetBIOS name resolved is stored in the NetBIOS name cache for 10 minutes. You can view the NetBIOS cache via 'nbtstat -c' |
| A request is send to the primary WINS server three times. (750 ms interval) |
| A request is send to the secondary WINS server(s) if available. There can be up to 12 secondary WINS servers configured for a client. |
| NetBIOS broadcasts are send over UDP ports 137 (NetBIOS name service) and 138 (NetBIOS datagram service) for three times with a 750 ms interval. |
| LMHOSTS file. |
| HOSTS file. The first 15 characters before the dot of the names in the hosts file are used to try to resolve a NetBIOS name to an ip address. |
| DNS server. |
You can install WINS on a member server or a domain controller. The number of WINS servers required depends on the network infrastructure and the amount of redundancy required. Keep the following things in mind :
| A typical WINS server can handle 1500 name registrations and 4500 name queries per minute. |
| Microsoft recommends one primary and one secondary WINS server for each 10.000 WINS clients. |
| An additional processor will increase performance by approx. 25 % |
| Turning database logging of will increase performance but increases the risk of losing data when a crash occurs. |
You can install WINS via Add/Remove programs, Windows components, Networking services, Windows Internet Name Service. (0.9 MB)
The WINS console is integrated with the MMC. Within this console you can do the following things :
| View active registrations. Each line contains the name of the
record, the type (00h, 03h, etc.), the ip address, the state (active,
released, thombstoned or scavenged), if it is static, the owner, the version
and the expiration time. (TTL) Within this window you can search for entries by name or owner, modify the entries, create new static entries, import a lmhosts file, verify name records and delete owners. | ||||||||||||||||||||||||||||
| Replication partners. Create replication partners, replicate now
and set replication properties. At the replication properties there are the
following tabs :
| ||||||||||||||||||||||||||||
| Wins server configuration. When selecting a WINS server you can
view/modify the following entries :
|
All WINS servers can be configured to replicate their data so NetBIOS clients
are able to contact hosts that registered with another WINS server. Within
replication there are two types of servers. Push servers send a message to their
pull-partners when data has changed. These pull servers can than request the
push server to send the latest updates. Only records on the push server with a
higher version number than the records on the pull server are replicated.
Configure the servers as push servers when they are connected with fast
connections. Use pull servers on slow connections are pull replication can be
configured to take place at specific intervals. If both servers need to
replicate with each other, configure them both as push and pull server.
Replication takes place when there is at least one push and pull partner.
Replication can start at the following moments :
| System startup. WINS automatically pulls database entries when starting. It can also be configured to push entries at start up. |
| At a configured interval. |
| Threshold. Pull partners are informed when a specific number of changes is made in the database. |
| Forced replication. By selecting 'Replicate now' in the WINS mmc. |
On the advanced tab of a replication you can set if it is a push, pull or push/pull replication, if you want to use a persistent connection for pull replication or set a start time and interval and if you want to use a persistent connection for push replication or a number of changes before push replication takes place.
At the properties of the Replication partners there are four tabs in which replication can be configured :
| General. Replicate only with partners (default on) and overwrite unique static mappings at this server (migrate on). This option determines if static mappings can be overwritten be dynamic entries if a conflict occurs. The option is off by default. |
| Push replication. Start push replication at service startup (default off), when address changes (default off), set a number of changes in version id before replication should take place (default 0) and set if a persistent connection for push replication partners should be used. (default on) |
| Pull replication. Set the start time, the interval (default 30 minutes), the number of retries (default 3), if replication should start at service startup (default on) and if persistent connections should be used. (default on) |
| Advanced. Set ip addresses of owners of records that should be blocked within the replication and enable automatic partner configuration (default off), Automatic partner configuration sends by default every 40 minutes a multicast on address 224.0.1.24 to find replication partners. WINS servers found are automatically added as push and pull replication partner with a pull replication interval of two hours. The push parameter is set to 0, so that no push triggers will be send. |
WINS uses port 42 for replication.
There are four phases in the lifecycle of the WINS record. First the record is active. In this phase the client will try to renew it's registration at the half of the TTL. When a client shuts down, a release is send to the WINS server. After this, the record will be in the released state for the time being specified in the extinction interval. In this state the server will make no challenge if a(nother) computer tries to register the address. After the extinction interval the record becomes tombstoned for a period specified in the extinction timeout. When this period is finished the record becomes in the scavenged phase and can be deleted from the WINS database.
A WINS proxy is a client that supports non-WINS clients by capturing NetBIOS
name query broadcasts from a network. It forwards them to the WINS server or
it's local cache for name resolution. You can create a WINS proxy on a client by
changing the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Netbt\Parameters\EnableProxy registry key.
A NetBIOS name cannot be registered in WINS via a WINS proxy. Use static entries
to register non-WINS clients.
When a WINS server gets more registration requests than it can handle, e.g. after a power down of a site, it can get into burst-mode. During this period, it will first queue the registration requests into memory. If this does not solve the problem, WINS will acknowledge all registrations but not store them in the database. The clients will receive a registration acknowledgement, but one with a very short TTL between 5 and 60 minutes. Also are no checks made if the address was already registered. When the clients try to renew their record at half of the TTL, they definitively got registered in WINS with a normal TTL.
Specific new functions of WINS in Windows 2000 are :
| Persistent connections for optimized replication traffic. |
| Manual tombstoning to mark a record for deletion. |
| Improved manageability via the MMC snap-in. |
| Enhanced filtering and record searching. |
| Dynamic record deletion and multi-select. |
| Record verification and version number validation. (consistency check) |
| Database export functionality. |
| Client support for up to 12 WINS servers per interface. (was 2) |
| Read-only access to the WINS console. |
In a pure Windows 2000 environment, WINS should not be required anymore but probably older applications are still using it. Check the WINS performance counters 'Queries/sec' and 'Successful queries/sec' to see if WINS is still in use. If not, it can be disabled via the 'Disable NetBIOS over TCP/IP' option on the WINS tab of the client or via the DHCP advanced scope option 'Microsoft disable NetBIOS' option under Microsoft Windows 2000 options.
| Windows 2000 Server Windows Internet Naming Service (WINS) overview |
| Support webcast: Windows 2000: WINS and DNS: What's new |
| Support webcast: Using WINS and DHCP on Microsoft Windows 2000 clusters |
Last update : 13 February 2002
