WINS Clients

     NetBIOS clients must be configured with a node-type that defines how they process NetBIOS queries. The four nodes b, p, m, and h stand for Broadcast, Peer, Mixed, and Hybrid Mode, respectively. The node type can be changed manually by editing the registry or assigned using a DHCP server.
	HKLM\System\CurrentControlSet\Services\NetBT\Parameters:
		Entry = "NodeType" of Type = "REG_DWORD"
		Values: b="0x1", p="0x2", m="0x4", h="0x8"
B-Node (broadcast node) clients use broadcasts instead of a WINS server. A client with no WINS server configured as a b-node client. The order of resolution is:
  1. NetBIOS cache
  2. Broadcast
  3. LMHOSTS
  4. HOSTS
  5. DNS Server
     A b-node subset is Microsoft enhanced b-node. These clients use the #PRE tag in the LMHOSTS file and parse them before broadcasts.

P-Node (peer node) clients use a WINS server and does not issue broadcasts. The can be used to reduce broadcast traffic across a segment. The order of resolution is:
  1. NetBIOS cache
  2. WINS Server
  3. LMHOSTS
  4. HOSTS
  5. DNS Server
M-Node (mixed node) clients use both broadcast and WINS servers to resolve NetBIOS names to IP addresses. The mixed mode client uses broadcast before WINS. The order of resolution is:
  1. NetBIOS cache
  2. Broadcast
  3. WINS Server
  4. LMHOSTS
  5. HOSTS
  6. DNS Server
H-Node (hybrid node) clients use both broadcast and WINS servers to resolve NetBIOS names to IP addresses. The hybrid mode client uses WINS before broadcast. The order of resolution is:
  1. NetBIOS cache
  2. WINS Server
  3. Broadcast
  4. LMHOSTS
  5. HOSTS
  6. DNS Server
     Hybrid node clients are best suited for a multiple segment LAN / WAN environment, where destination NetBIOS clients and resources are located on remote segments.

The default order of NetBIOS name resolution on a Windows 2000 WINS-enabled client (default h-node):
  1. The NetBIOS remote name cache is checked.
  2. The WINS client contacts the WINS server(s) whose addresses have been given.
  3. The WINS client issues a broadcast on its subnet.
  4. If an LMHOSTS file is configured, it will be queried (\WINNT\system32\drivers\etc\LMHOSTS).
  5. If an HOSTS file is configured, it will be queried.
  6. The WINS client contacts the DNS server.
     If a WINS client does not refresh its name record in 50% of it's TTL, the record is marked inactive (or released). An inactive record can be dynamically updated without being challenged by the WINS server.

To test WINS on the client:
	c:\>netdiag /test:WINS.


WINS Servers

     A single WINS server and backup WINS server can easily accomodate up to 10,000 clients. No more than 20 WINS servers should exist on a network due to log in databases.

To specify the WINS server in DHCP, use option 44 WINS/NBNS and option 46 WINS/NBT.

     If you plan to integrate WINS with DNS, you should create a dedicated WINS referral zone so that all WINS referrals are performed from lookups emanating from requests to that zone. In this way, all names resolved via WINS referrals have the domain name of the WINS referral zone appended to them.

     The WINS server and WINS client participate in four basic activities: name registration, name renewal, name release, and name resolution.

     A WINS Proxy is similar to a DHCP relay agent. It resolves WINS for non-WINS clients (broadcast clients), and must be located on the same subnet as the client(s) it will serve. A WINS proxy can also be used for b-node clients to cross a segment. It must be configured in the Registry of the WINS server and is enabled immediately.
	HKLM\System\CurrentControlSet\Services\NetBT\Parameters\
	Entry = "EnableProxy" of Type = "REG_DWORD", Value = 1
	Entry = "CacheTimeout", Value = 600000 (10 min)
Burst Mode is used for example, when a power outage brings multiple WINS clients offline and then suddenly online simultaneously. These simultaneous name registration requests which may overwhelm the WINS server. In Burst Mode, the WINS server issues immediate acknowledgements without the server checking NetBIOS names against its database. It does not record these names in its database as it issues them, either.      When upgrading 2000 WINS from NT4, you must convert the WINS database to the 2000 format. Use the edbutil.exe from the \WINNT\system32 folder. Restart WINS. If you are upgrading from NT3.51, you must first run upg351db.exe, then edbutil.exe.

To compact the WINS database:
	c:\>net stop WINS
	c:\>cd %SYSTEMROOT%\system32\wins\
	c:\>jetpack wins.mdb winstemp.mdb
	c:\>net start WINS
To scavenge the WINS server database:
	c:\>winscl t sc
	    ip address of WINS
	    sc 192.168.1.1
To restore the WINS database:
  1. Stop the WINS service.
  2. In the WINS console, "restore database" will appear.
  3. Direct to the directory where you configured the backup setting.

    You may want to add the WINS backup directory to the tape software on local drive to backup the WINS database.


WINS Replication

A pull partner receives replication data based on a time interval.

A push partner transmits replication data based on changes in data.

     For Automatic Partner Discovery of WINS servers, the multicast address of 124.0.1.24 is used to find other WINS servers. Your routers must be set up for IGMP (multicasting). All autodiscovery partners have a replication pull interval of 2 hours.

     Microsoft recommends that replication partners be configured as both push and pull partners. Except when spread by a slow link (WAN), where you would most likely set both as pull partners.

     When placing a WINS server outside of a firewall or in a screened subnet, use pull-only replication and encryption via VPN or IPSec.

WINS replication uses TCP port 42. WINS RPC management uses TCP port 135.

To monitor WINS replication with Network Monitor:
  1. install wins.dll
  2. edit tcpip.ini and parser.ini
	#\parsers\TCPIP.INI
	[TCP_HandoffSet]
		42=WINS

	#\netmon\PARSER.INI
	[PARSERS]
		WINS.DLL=D:WINS
	[WINS]
		Comment="WINS Server Replication"
		FollowSet=
		HelpFile=
     The "Migrate On" feature allows static mappings to be overwritten when an upgrade is performed for hosts which can then update their own WINS records with the WINS server. All replicated entries must be deleted from ALL WINS servers, otherwise they will be replicated back.

When DNS resolves a hostname via WINS lookup, Nslookup will show it marked Authoritative and the TTL will be shorter on subsequent requests. If the hostname was in a local zone file, it would be authoritative but the TTL would be the same.