This post is not about how to install WINS, it’s about why you actually need it. Yes, that’s right folks, you need WINS, even today in 2010, with Windows 7 and 2008 R2 firmly deployed in your network.Windows has NetBIOS names encoded in its DNA, and we’re probably NEVER going to get away from that.
As administrators, we are often our worst enemy in this regard. Over the past year of independent consulting, I have seen time and again, clients who set themselves up to need WINS without even knowing it, and thinking that WINS was an NT4 thing which they don’t need. Consider the following…a login script that maps drives to various shares, using then UNC pathway \\servername\sharename. Seems pretty straightforward, and I bet you have similar in your environment. Go check them. Are the server names FQDNs, or hostnames?
Odds are, they are hostnames, which is fine. A little lazy, but heck, I can throw no stones there. We don’t need to fully qualify our domain names as long as the proper DNS suffix is in our search path, a part of our own name configuration, or assigned by DHCP. What bites us in the arse though, is this. If that hostname could be a NetBIOS name, then our Windows clients will attempt to resolve it as if it were. Remember this post? If your hostname is 15 characters or less long, and does not contain a "." then it could be a NetBIOS name. As such, our Windows clients will try to resolve it like one. No WINS means we’re going to BROADCAST for the name.
Think about what that means. Your box will do a NetBIOS broadcast to the subnet broadcast address asking to resolve the name. Unless you have a flat LAN, or a NetBIOS proxy, nobody will respond. It will try twice more before giving up and taking whatever DNS responses that were being resolved in parallel. Sure, the client will get there eventually, but the time it takes for the NetBIOS broadcast requests to expire, coupled with the noise generated, just aren’t worth it.
The same thing happens when folks type ‘intranet’ into IE instead of ‘intranet.example.corp.’ Their client sees a name that could be a NetBIOS name so it tries to resolve it as one, even while it tries to append the various suffixes to the name so it can be resolved by a DNS query. If you don’t think this is going on in your network, try this simple test. Open a cmd prompt on your workstation, and enter this cmd.
nbtstat –r [enter]
Here is mine from my Windows 7 workstation, running on a Windows 2008R2 based domain, where the most legacy server I have running is Windows 2003R2 for WSS3. There are two XP workstations still around, but they have nothing shared, so no reason my PC would ever have to connect to them or resolve their name.
I have no login script, and my homedir is mapped to the FQDN of my fileserver. It has been about four days since I last rebooted, and I have had to go to WINS over 400 times for name resolution. Why? Because NetBIOS names are just a part of Windows networking, like it or not. Sure, you could disable NetBIOS on all your machines, make sure that each mapping uses FQDNs, put bookmarks for all your internal web sites so that no one types in a short name, and you can map all hostnames into the GlobalNamesZone (because you have no legacy hosts in your network, right?) and guess what….you’ll still see NetBIOS on your network.
If you (or more likely, your boss) is still not convinced, consider this. There is a new name resolution method in Windows versions starting with Vista, called Link-Local Multicast Name Resolution (LLMNR.) Defined in RFC4795, if for some reason you lose access to DNS and WINS (or you don’t have it) LLMNR capable hosts will do multi-cast name resolution on the local LAN by sending UDP queries to 224.0.0.252:5355. If that is not WINS mark two (and it’s not…it can do FQDNs as well as single-label names) it is awfully close to the same thing.
Now that you know you need WINS, set it up. You need to have at least two servers (fault tolerance and in larger networks, capacity.) As with hostname resolution, you want to keep that traffic local to your clients as much as possible, so you may have WINS servers in any major location, not just your datacenters. Any location that justifies the expense of a local domain controller can have WINS (and DNS of course) running on that domain controller. While WINS was the first real service that Microsoft actually recommended multi-processor hardware for, on today’s servers it is a blip in your load calculations. Using domain controllers is an excellent way to get a little more use out of that hardware, and you are probably already using them for DNS. Configure all your hosts so that they have two WINS servers. If both servers cannot be local, try to make sure the primary is not on the other side of a WAN link. If you have two or more servers running WINS at a location, alternate the assignment of the primary and secondary, much like you would for DNS. This is just to spread the work load out a little bit, like this…
You should take this approach further by also alternating primary and secondary assignments in all of your DHCP scopes, and consider alternating them on static assignments. Remember, the goals here are to…
1. spread the load across your servers
2. ensure that if a server does go offline, no host is left without the services it requires
3. keep name resolution (host or NetBIOS) local to the client as much as possible
4. ensure that no host providing services uses itself as the primary provider for a service. See this post on DNS Islanding, and apply the same concepts to WINS when you are configuring your domain controllers, DNS servers, and WINS servers.
5. of course, server1 and server2 should be WINS replication partners.
Now, what do you do for your clients? Updating DHCP scopes will take care of workstations as T1 arrives, but what about servers? You can’t do this with a GPO, but you can use a script to configure your DNS and WINS server assignments for all hosts that have static ip.addrs. Assign it as a start-up script, or just save it to your homedir and run it as you log on to each server. This script will not configure a DHCP client, but it will hit every interface on a statically configured host, with no concern for multi-homed servers, VM host servers with virtual interfaces, etc. Nor does it care if this results in a server pointing to itself for any service, so don’t just use this blindly…think and test, and then double-check.
@ echo on
ipconfig /all |find "DHCP Server" >nul
if errorlevel=1 goto DNSWINS
goto end
: DNSWINS
setlocal ENABLEDELAYEDEXPANSION
for /f "tokens=*" %%i in (‘netsh interface show interface ^| findstr /b "Enabled"’) do (
set STRING=%%i
set STRING=!STRING:~47!
if not "!STRING!"=="Internal" (
if not "!STRING!"=="Loopback" (
netsh interface ip delete dns "Local Area Connection" all
netsh interface ip delete wins "Local Area Connection" all
netsh interface ip set dns name="!STRING!" static 1.2.3.4
netsh interface ip add dns name="!STRING!" 1.2.3.5
netsh interface ip set wins name="!STRING!" static 1.2.3.5
netsh interface ip add wins name="!STRING!" 1.2.3.4
)
)
)
:end
with thanks to alisafia for the bulk of this script, from this forum post on ExpertsExchange.
If you do a CTRL-C CTRL-V with this script, be careful that your editor doesn’t put smart quotes in the place of the regular double quotes above. Notice also that I swap the servers doing the primary role. Again, this is to try to spread the work across the two servers.
With the above, you are set to ensure your clients have optimum name resolution, you’ve eliminated single points of failure, and you have maximised the return on investment by taking advantage of untapped resources of your domain controllers. Now, take the rest of the day off on me…it’s okay, tell your boss I said so.
And about this post…catchy title, yeah? I know, that just happened.
Sorry, Talladega Nights is guilty little pleasure of mine. I’m happy to take any follow up questions about this post, or razzing about this movie, in a comment. Tell me how you feel…
You might also enjoy:
