Introduction
Some things never seem to die and Windows Internet Name Service (WINS) may be one of them. WINS has been included in all versions of Windows Server since Windows NT 4.0 and provides a centralized way of managing and facilitating NetBIOS name resolution. Beginning with the introduction of Active Directory in Windows 2000 Server, Microsoft has pushed customers towards using Domain Name System (DNS) as a name resolution service with the implication that eventually WINS will no longer be need.
So let’s say that you’re in the process of migrating your Active Directory infrastructure to Windows Server 2012 or Windows Server 2012 R2. Once you’ve finished this migration, will WINS no longer be needed for your environment? Can you finally shut the door on WINS and decommission those WINS servers running in the far corner of your datacenter?
Maybe.
Let’s examine this matter more deeply.
When WINS is still required
If you still have any client computers running (OMG) Windows 95, Windows 98 or Windows ME in your environment, you’ll still need WINS around so these clients can find domain controllers so their users can log on to your network. And if you still have any member servers running (golly!) Windows NT 3.51 or Windows NT 4.0 kicking around, they’ll need WINS as well. I can’t imagine any sensible customers who might still have these ancient platforms running, but you never know. Sometimes an organization will keep an old server or client computer around because it controls or monitors some industrial system and they don’t want to (or have any idea how to) upgrade the system while ensuring the legacy control software still works properly.
WINS will also be required if you have any legacy applications still running that have a dependency on NetBIOS name resolution either because of the way the application is configured or how it has been coded. Finding such applications can be a challenge–see the next section below for a possible approach.
When WINS might still be required
If you still have a WINS server or two on your network and you’re not sure whether they might still be needed or not, try capturing the inbound and outbound network traffic on the server over a period of time. Then filter the captured traffic for anything on UDP port 137 which is the port that WINS uses for NetBIOS Name Service. The WINS Server services listen on UDP port 137 for incoming NetBIOS name resolution requests, and if you see any such requests in your captured traffic you should be able to trace which Windows computers (which may be either clients or servers) are issuing these requests from their WINS service.
Once you’ve identified the computers issuing NetBIOS name requests, you can examine them and determine why they’re using WINS instead of DNS for resolving NetBIOS names on your network. It may be that the TCP/IP configuration of these computers is the culprit, in which case you should reconfigure them to use DNS instead of WINS for name
resolution. Or it may be because of some ancient, long-forgotten legacy application running on them that is hard-coded to use NetBIOS name resolution instead of using DNS for name resolution. If that is the case they you have several options you could pursue:
- You could contact the application vendor to see whether there is a more recent version of the application that isn’t hard-coded to use NetBIOS name resolution.
- You could replace the application with a different one that doesn’t use NetBIOS name resolution.
- You could re-code the application to use DNS for name resolution if it was developed in-house.
- You could decommission your WINS servers, cross your fingers and hope that any computers running this application can use NetBIOS broadcasts instead of WINS-directed traffic to continue functioning properly.
- You could keep that old WINS server around for another hundred years or so.
Be aware that such applications may be tied to specific hardware such as legacy Network Attached Storage devices which may only know how to register themselves on the network using NetBIOS traffic.
WINS might also still be required because of poor choices in how you or your predecessors have configured your environment as administrators. For example, let’s say you’ve implemented the Distributed File System Namespace (DFSN) feature of Windows Server in your environment. Did you know that you might have just created a WINS dependency? See KB244380 for more details.
Decommissioning WINS
If you’ve determined that your environment no longer has any dependency on NetBIOS name resolution, you can go ahead and decommission your WINS servers. Just be sure to decommission all of them! How can you find all the WINS servers in your organization? If it’s a very large organization that was originally running Windows NT 4.0 years ago, there may be some undocumented WINS servers hiding in the corners or even under the rug. How can you find these culprits?
A good way is to use the fact that WINS servers were designed to replicate their name registration databases with each other using something called WINS replication. By examining the configuration of one of your WINS servers, you should be able to identify its WINS replication partners. You may also need to capture network traffic on TCP port 42 on your backbone as this port is used for WINS replication traffic, and the presence of such traffic can help you identify any additional WINS servers on your network–at least by their IP addresses which can at least help you nail down which subnet these servers are on.
Be aware however that decommissioning WINS doesn’t just mean pulling the plug on all your WINS servers. To properly decommission WINS in your environment, you will also need to remove any WINS settings in the TCP/IP configuration of clients and servers on your network. After all, you don’t want any of the servers or clients on your network trying to contact a decommissioned WINS server to look up a NetBIOS name. For computers that use DHCP, you can simply remove any DHCP options configured for Option Type 44 WINS server (NetBIOS name server) see this link for more information. You will need to remove this option from server, scope, class and client-specific levels of your DHCP servers. And for clients or servers that have their TCP/IP settings manually configured, you’ll need to remove the WINS configuration from these clients too.
If you have any legacy hardware like NAS devices that are hardcoded to use NetBIOS for registering themselves on the network, and you can’t or won’t replace these devices, then you will need to implement some workarounds so they can continue working properly once your WINS servers have been removed. Typically this will mean creating static DNS records for such devices to register them with your DNS servers.
What if you’re in the process of upgrading your environment to use IPv6? The latest versions of Microsoft Windows, both client and server, have IPv6 functionality not only enabled but preferred over IPv4. WINS however only supports IPv4, so if you are planning on going IPv6-only then you should look into using DNS Global Names to provide NetBIOS name resolution for applications that use IPv6. DNS Global Names is described at http://technet.microsoft.com/en-us/library/cc816610(v=WS.10).aspx and http://technet.microsoft.com/en-us/library/cc731744.aspx, and a good discussion of how it relates to WINS can be found at http://social.technet.microsoft.com/Forums/windowsserver/en-US/f7649be9-e702-42e5-9a2a-d78e78909a72/gnz?forum=winserverNIS.
Conclusion
From the above discussion you can see that decommissioning WINS in an enterprise environment isn’t a trivial task. You either need to approach this as you would any other large-scale project, or you could pull the plug on your WINS servers and see if anything breaks. Or you can do what most organizations would probably do when faced with this decision–leave their WINS servers running.
