Wouldn't it be nice to get rid of WINS in your environment?

But have you stopped to think about why that would be a nice thing? Could it be because of the years of plaque-like build up of erroneous records in your WINS databases? Is it because of the many people with varied thoughts and ideas that have "owned" WINS in your company over the years?

Is WINS just a victim of its own success? Or could it be because if you must install WINS you now have to maintain two name resolution environments that are similar yet different if you deploy Active Directory?

I suppose it could just be because there hasn't been a large amount of tools available to help troubleshoot it.  I mean, it pretty much worked or didn't right?  If it didn't, you had to open a fat GUI client that seems to always take much longer than you feel is necessary.

During all the years I've dealt with WINS, whether in design, deployment, troubleshooting or just plain trying to understand how it's deployed at a given client site, I've always had the following thoughts about it:

• 1) It's a pre-cursor to the dynamic DNS we know and love today whether in the Windows or opensource environment. Ok, that's a relatively new thought comparatively speaking.
• 2) It really does do quite well, although it can't scale nearly as well as DNS.
• 3) There are just no good command line tools to help troubleshoot. At least in DNS there's dig or nslookup or even ping with the -a switch to find particular addresses and corresponding information.

But this evening, while working on a separate WINS issue, I ran across this:

http://support.microsoft.com/kb/830578/

Wow.

Want to query for a specific name? Yep, it can do that.

Want to query for a specific record type? Yep, it can do that too. 

Most recently, I was interested in enabling replication between two environments that were previously only connected via DNS so that we could work in a trust relationship.  The source domain is a NT4 domain and the target is Windows 2003 running at 2003 Forest Functional Level (FFL) and Domain Functional Level (DFL). The source servers are located in Australia as are the target domain controllers.  But I'm located in North Carolina (USA) and I'm not fond of remote control over high-latency connections if I can help it.  Also, the WINS topology is such that the records have to go from the source domain to the target domain in the local site, then to a central WINS server in a different site and then back to my local WINS server before I can start. How to watch the progress so I know it's complete?  Before I would have had to enumerate the entire WINS db. Yikes. Now, I can instead use this command line tool to query the WINS db for my needed records like this:

nblookup /s server.sourceDomain.com.au /x 1C targetDomain

That returns the following:

server.sourceDomain.com.au resolved to 10.1.1.1

Default Server: 10.1.1.1

Recursion is on

Querying WINS Server: 10.1.1.1

NetBIOS Name: target

Suffix: 1C

Name returned: TARGET

Record type: Group

IP Address: 10.1.1.65

Record type: Group

IP Address: 10.1.1.65

Pretty nice.  Now I know that the records exist on that server and all I need to do is change the server I query from server.sourceDomain.com.au to the targetDomain WINS servers in the chain and I can find out the information I need.  That's quite a time saver in my opinion and a tool that was long overdue.

There are many other options available.  Check out the kb article for more information and other command line options.