Partager via

Decommissioning WINS

  • Article

I’ve been working on helping remove WINS from a customers network. One of the big problems was identifying the remaining clients still using WINS, and just what they were using it for.

We used Network Monitor to capture WINS name resolution queries on the WINS to see which clients were querying for which server names.

What we found was quite interesting.

When a client is configured with a WINS server (via DHCP or statically), it will always attempt to resolve queries for SHORT names (i.e. names without dots in them) via both WINS and DNS at the same time. When it formulates the first DNS query to send out, it uses this logic:

  • If DNS Suffix Search Order list is empty, then use the primary DNS Suffix (typically the DNS name of the domain the client is joined to).
  • If there is a DNS Suffix Search Order list, then use the first entry.

It sends out BOTH a WINS query and a FQDN query to DNS at the same time because it doesn’t know which service can resolve the name, and rather than prefer one over the other and incur the delay, it just blasts both out at the exact same time.

If both replies result in an answer (i.e. an IP address) then the client will use the result from the service which happens to reply back the fastest.

If neither query comes back with a successful result, the DNS client takes over. It will either try DNS devolution on the primary DNS suffix (enabled by default), or will start walking down the DNS suffix search order, if that is configured. DNS devolution is the process of shortening the primary DNS suffix by dropping the left most parts of the DNS suffix until there is only 1 dot left in the DNS suffix.

An example of DNS devolution:

The primary DNS Suffix of the client is child.corp.contoso.com. The client is looking for the server called someserver.contoso.com by asking for server by the short name: someserver.

  1. someserver.child.corp.contoso.com [fails to resolve]
  2. someserver.corp.contoso.com [fails to resolve]
  3. someserver.contoso.com [success!]

(Note that DNS wildcard records can mess this logic up – but that’s the topic of my next blog.)

What does this matter for removing WINS?

Well, in our case we started looking at all the WINS queries hitting the server before we started. And there were lots of them. This confused us a bit as all the clients should be Windows XP or newer, they should all be domain joined and should all use DNS. We were seeing the WINS queries because of the method described above where the client will send out BOTH WINS and DNS at the same time when querying for a short name.

Step 1 in removing WINS from our clients was to export the static WINS entries and create static DNS records for them instead. This removed the reliance on WINS for the clients. There are still other devices (notably printers) which register in WINS and need WINS so the print operators can locate the new print devices appearing on the network. The DNS zones only allow for secure updates, so without some other method, WINS will still be needed for these devices. Altering the process for deploying print servers, by identifying them before they hit the field will solve that.

Once that was done we installed Network Monitor 3.3 on the WINS server, and used this capture filter to show the successful answers the WINS server is giving back to the WINS clients:

NbtNs.Flag.R == 0x1

AND NbtNs.Flag.AA == 0x1

AND NbtNs.AnswerCount > 0x0

AND (IPv4.DestinationAddress < 10.1.0.0 OR IPv4.DestinationAddress > 10.1.255.255)

AND (IPv4.DestinationAddress < 169.254.0.0 OR IPv4.DestinationAddress > 169.254.255.255)

AND NbtNs.AnswerRecord.RRName.Name != "*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>"

Line-by-line this says: Show all responses, which are answers,where there is more than 0 answers, where I am not replying to a client who is in the server subnet (10.1.0.0/16), nor am I replying to APIPA assigned addresses in my subnet (169.254.0.0/16) and the answer is not a response to a master browser announcement. While WINS uses port 42, it uses this for WINS server replication. WINS queries happen on 137/UDP.

We went through the results looking for names which weren’t in DNS. Which is like trying to find a straw in a great big stack of needles.

Then we disabled the WINS entries in the DHCP scopes for the clients.

Now we can see which clients are statically configured to use WINS. We’ll locate them first and correct them. Finding out exactly which host names they are relying on WINS for is still tricky, especially as the clients send out WINS and DNS queries simultaneously. But we’re on the right track.

We can then focus the filter on the server subnets to locate servers which are configured to register records in WINS:

(IPv4.SourceAddress > 10.1.0.0 AND IPv4.SourceAddress < 10.1.255.255)

AND NbtNs.Flag.OPCode == 0x8

AND NbtNs.NbtNsQuestionSectionData.QuestionName.Name != "CORP.CONTOSO.COM "

AND NbtNs.NbtNsQuestionSectionData.QuestionName.Name != "<01><02>__MSBROWSE__<02><01>"

Which says: Limit the traffic to source IP addresses within the server range (10.1.0.0 – 10.1.255.255) which are WINS Name Registration requests but exclude domain browser election requests for the domain corp.contoso.com (the 2 spaces at the end are important"), and also exclude master browser announcements. What remains are

I hope this helps you in your project to decommission WINS.

Comments

  • Anonymous
    January 01, 2003
    nice post. we talked about decomissioning WINS before although it wasnt fixed yet, but this info will be useful when it happens

  • Anonymous
    May 12, 2015
    What does remain? The post is incomplete.

  • Anonymous
    January 23, 2017
    The comment has been removed

    • Anonymous
      February 05, 2017
      @Peter Trast - In my network traces of many, many, many years ago, these were the results I found. If the name resolution in Windows has changed over the years, then please do post your trace findings to this post as comments for others to take advantage of.
      • Anonymous
        September 19, 2017
        I was teaching the name resolution order including network traces as far back as 2007, but I never saw this simultaneous behavior. I am wondering if there was something unique in your testing that may have caused this, but I did not duplicate it even in my 2003/XP lab (yes, I still have to support some legacy stuff :) ). Is it possible you used some non-default setting?...
        • Anonymous
          October 19, 2017
          @Peter Trast - I was onsite with a customer gathering these traces on their machines 7 years ago. I won't have bandwidth to create a lab to re-test this, and I am not familiar enough with the specifics of that customers' environment from that time. Again, if you have traces with differing results, please post them here. Otherwise, let's close this now.