WINS - What Is It, How To Install It, and how to Configure DHCP Scopes For WINS Client Distribution
WINS - What Is It, How To Install It, and how to Configure DHCP Scopes For WINS Client Distribution
Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services
Active Directory, Exchange and Windows Infrastructure Engineer
WINS is a Microsoft NetBIOS Name Server (NBNS) that's still widely used in the industry. WINS provides a dynamic NetBIOS name to IP address database. It also interacts with the Browser Service, which assembles and provides the Browse List, or what's better known as Network Neighborhood.
Many folks rely on browsing the Neighborhood to "look" for resources and shares on servers, such as browsing for shared drives, shared printers, etc (if not using AD to search for published printers), including mapped drive UNC paths, etc.
The Browser service relies on NetBIOS. This works fine on single subnets, however if the environment contains multiple subnets, or VPN subnets, then the Browser will fail going across subnets. Workstations on each subnet will only "see" the computers on that specific subnet.
This is due to the fact NetBIOS broadcasts are blocked by routers (including VLAN configurations), therefore browsing across subnets, such as between multiple company locations, or across client VPN connections fails.
Lack of NetBIOS support will also affect mapped drive paths in a login script, or manually created on a workstation, especially if the mapped drives were configured in the form of \\serverName\sharename, where the 'serverName' is a single name, hence either DirectSMB or NetBIOS kicks in (in that order with Windows 2000 and newer) to resolve it.
To support this lost functionality and provide NetBIOS name resolution across subnets, VPN Tunnels and Client VPNs, you will need WINS.
In addition, the Browser Service works hand in hand with WINS to assemble the Browse List. Many in the industry use WINS as a defacto in environments to eliminate NetBIOS broadcasts.
More specifics on the interaction of WINS and the Browser Service can be found here:
DNS, WINS & the Client Side Resolver, NetBIOS, Browser Service, Disabling NetBIOS, Direct Hosted SMB (DirectSMB), If One DC is Down, Does a Client logon to Another DC, and DNS Forwarders Algorithm
Active Directory and the need for WINS?
Active Directory itself does not need WINS. However some legacy apps may need it.
Active Directory supports single name resolution using DirectSMB (TCP Port# 445), however many will argue that they've found it doesn't perform as expected, however that's a discussion for another time, since this doesn't fall under the scope of this writing.
What I can say is that some legacy applications and services still require WINS that AD DirectSMB doesn't support, some of these apps include, but not limited to are:
- Exchange 2003 with certain Outlook features
- McAfee Enterprise ePolicy Orchestrator
- Symantec Endpoint Protection
- Symantec Backup Exec
- Computer Associates AV
- Mapped Drives
- Printer sharing (not published in AD)
- and many more....
More info on Exchange 2000/2003 and WINS:
WINS is still required with both Exchange 2000 and 2003
Aug 8, 2005 ... See why Exchange needs WINS and how you can get a WINS server up and running and configure Exchange to use it. ...
WINS and Exchange 2003 Server Dependencies:
I had been labouring under the delusion that Windows and Exchange 2003 servers no longer need WINS, it seems that I was wrong. However, what I now believe ...
Exchange Server 2003 and Exchange 2000 Server require NetBIOS name ...
You may have to use NetBIOS name resolution across different subnets for the ... The following Exchange functionality still depends on WINS name resolution: ...
Setting up a WINS Server
Keep in mind, when setting up a WINS server, it is suggested to install it on a DC that holds the PDC Emulator Role because that DC is the one that will become the Master Browser. Also, when setting the WINS server IP address on any WINS server, if you have more than one WINS server, it must only point to itself if it is a WINS server, no secondaries, whereas a workstation can be configured with multiple WINS servers, but a WINS server must only point to itself. This is due to name registration and ownership of the WINS registered entries. If you only have one WINS server, no problem, just point it to itself. This is a little different than DNS, where you can provide multiple internal DNS addresses (no outside DNS addresses, of course).
To configure the WINS addresses in DHCP Scope or Server Options, add the following options:
Option 044: <WINS Server IP Address> This sets the WINS IP addresses to offer DHCP Clients
Option 046: 0x8 This sets the NetBIOS Node Type
WINS Installation Steps and DHCP Configuration:
1. Install WINS
For Windows 2008 or 2008 R2:
- Do one of the following:
- In Initial Configuration Tasks in Customize This Server, click Add Features. The Add Features Wizard opens.
- Click Start, click Administrative Tools, and then click Server Manager. In the left pane of Server Manager, click Features, and in the details pane, in Features Summary, click Add Features. The Add Features Wizard opens
- In Select Features, in Features, scroll down the list, select WINS Server, and then click Next.
- In Confirm installation selections, click Install.
- In Installation Results, review your installation results, and then click Close.For WIndows 2003, WINS is installed using the Control Panel Add/Remove Programs applet, WIndows Components.
For Windows 2003:
WINS is installed in Control Panel, Add/Remove, Windows Component
More specifics in the following links:
WINS server role: How to setup WINS Servers in Windows 2003:
WINS Server Role: How to Install Windows Internet Name Service (WINS) in Windows 2008 and 2008 R2
2. Configure the IP address of the WINS server to itself. To do this on the WINS server, go to NIC properties, Advanced, WINS tab. Type in ONLY the IP address of itself. THis is because a WINS server can only point to itself.
3. On all other IP static configured machines, add the WINS address under IP properties. Advanced, WINS tab. If you have more than one, you can specify as many as you like.
More information on how to configure your network adapter to use WINS:
To configure TCP/IP to use WINS - Windows XP
4. For DHCP properties, you will need to add two DHCP Scope Options:
DHCP Scope Option 044, provide the WINS server IP address. If you have more than one, provide them in the order you would like them to be configured on your DHCP clients.
DHCP Scope Option 046, type in 0x8
More specifics on how to configure DHCP Options:
Configuring DHCP Options
5. Allow a day or two for all the machines to register, and for the browser service to stabilize.
Multiple Sites or Locations
If you have a remote Site, for example across a VPN Tunnel, you can safely configure all the machines in the other sites to use the central Site. However, to reduce WAN traffic, and just in case the VPN/WAN link goes down, you may want to setup a WINS server at the other site. You can then configure the remote Site WINS server as a replication partner with the WINS server in your location.
If you have more than one Site, you can configure a multiple partnership. However to insure WINS functionality, you don't want to create a "mesh." In this case, you would be better off creating a Star topology, with the Central Site being the center of the star and each remote site is partnered with the Central Site.
How to setup a WINS Replication Partnership
To add replication partners, open the WINS console, then click and expand the Server name. Under it you will see "Replication Partners."
Right Click Replication Partners, choose ADd
Type in the WINS server's IP address that you want to make a replication partner.
Choose both Push and Pull partnership
You can leave the rest at defaults, but here are some specifics about the settings in case you're curious:
The "Configure" button is used to set replication intervals, retry counts, and the number of changes before sending updates. The WINS Configuration menu controls the following:
Renewal interval - Default of 96 hours, sets the amount of time between which a client must renew its name.
Extinction Interval - Default of 96 hours - Time between when a name is released and marked as extinct.
Extinction Time-out - Default of 96 hours with a 24 hour minimum. Time between when a name is marked as extinct and removed from the database.
Verify Interval - Default of 576 hours (24 days). - The interval between which WINS entries owned other WINS servers are verified.
The "Advanced" button allows the following selections:
Logging enabled - To log Events in the Event Viewer
Log Detailed Events - Increases logging specifics for troubleshooting.
Replicate Only with Partners - Enabled by default, this will allow a pull server to send to WINS servers.
Backup On Termination - When WINS Manager is closed, the database is backed up.
Migrate On/Off - Static entries are changed to dynamic when a conflict between a static and dynamic entry is found.
Starting Version Count - Only needed if the database becomes corrupt. Each database is identified by an ID Number.
Database Backup Path - A local path for database backups
WINS Muti-Partner Replication Design Guidelines
- Each WINS server must only point to itself in the ipconfig /all (network card settings). This is a must, or it will cause problems with WINS records ownership and trying to replicate records.
- For any replication partnerships, it's recommended to create a PUSH & PULL partnership at time of creation, and not just a PULL partner, or a PUSH partner. This insures that all records get replicated.
- If you must add a replication PUSH or PULL in the registry, because it was not added at time of creation, then your choice is either to delete and recreate the partnerships as a PUSH/PULL, or manuall add it in the registry.The preferred choice is to remove and recreate the partnership.
- With multiple WINS servers, choose a HUB & SPOKE topology. Do not choose a MESH design, or expect numerous problems and errors, such as EventIDs 4102, 4243, 4242, and 4286 messages.
- Make absolutely sure TCP 42 and all AD ports are opened and fully allowed between all partners.
More info on WINS Replication Errors:
Troubleshooting WINS error event ID 4102, 4243, 4242, and 4286 messages
The difference between push and pull partners:
- PUSH parrtners will "push" a change as soon as it occurs.
- PULL partnerships run on a schedule.
I hope the following diagram will clear things up. Notice the purple IPs and how each server only points to itself for WINS in its ipconfig. Also notice there are two WINS servers in NYC. THe one on the left is the central WINS HUB, and the one on the right is a "spoke" partner just like all the others in the other sites.
(Click on the image for the full version)
WINS Partners and the DHCP Lease Length
With multiple WINS servers you also want to be careful on how short the DHCP Lease is.
Keep in mind with a DHCP lease, a DHCP client will attempt to renew its lease at 50% of the lease period. If it fails at that point after a certain time out period, it will retry at 87.5% of the lease.
When a DHCP client acquires a new config or renews it's current config, it will re-register or refresh it's WINS registration. This will cause a replication request between WINS server partners. However, if the DHCP lease is say one day, the WINS servers just can't keep up with the constant changes, especially in a Mesh topology.
If you shorten the lease to something along the lines of one day, or even 4 hours (as I've seen some installations have done), keep tabs on any WINS errors that may be generated. It's suggested the default 8 day DHCP Lease period is sufficient for most needs, including laptops that come and go even just for a day.
DHCP - DNS registration Duplicates with Dhort LeasesAlso, on a side note, if you notice that you are seeing duplicate DNS registrations for laptops that frequently come and go, you can configure DHCP to own the records. This way when a laptop comes back up online and acquires a new lease, it will not create a duplicate, and once DHCP is configured to own all records it registers, it can update the laptop's current entry with the new IP.
More information on this and how to configure it can be found in the following blog.
DHCP, Dynamic DNS Updates, Scavenging, static entries & timestamps, and the DnsProxyUpdate Group (How to remove and prevent future duplicate DNS host records)
Browser Service Elections
Also, I mentioned about Browse Master elections. When someone is sitting on a workstation, server, or DC, and selects to "browse" for something in the Neighborhood, the machine contacts the Master Browser on the subnet. If one does not exist, it will send out an election packet so it can become the Master Browser for the subnet. The order of which one will win depends on the operating system version and service installed, such as the PDC Emulator will win hands down, then if the PDC Emulator is not available, a replica DC, and if that is not available, a member server, and if one is not available, then a workstation, and the newer operating system workstations will win over an older one. Therefore, if you do not have at least one server on that subnet, one of the workstations will win. This can be prevented by setting a registry entry on each workstation in the subnet. The registry entry to prevent workstations from attempting to become a Domain Master Browser and compete with Domain Controllers:
Change the value "AUTO" to "FALSE" (without the quotes) in the following registry key:
However I do not suggest changing this setting on domain controllers or servers.
More info on possible Browser Service errors you may encounter if separating workstations on a separate subnet, such as an EventID 8003, as well as info on the registry setting, can be found in the following links:
Event ID 8003, Source Name: Browser
Event ID 8003 Source Namne: MRxSmb
How to Fix Master Browser (MRxSmb) Event ID 8003 errors
8003 browsing errors with UDP forwarding:
Windows 2000 Professional Workstations (and newer) on Microsoft Networks and the Browser Service Details, Browser Service Browsing Roles, the Browser Election Process, as well as info on Publishing Objects in Active Directory:
Windows Browser Registry entry "MaintainServerList" settings information:
Suggestions, corrections and comments are welcomed.