WINS Error 0x00002590: Missing WINS Servers Fix

You're seeing 0x00002590 and the message "Need servers" — usually when a legacy app tries to resolve a NetBIOS name and can't find a WINS server. I've seen this on everything from old Windows Server 2008 R2 print servers to XP-era apps running on Windows 10. The culprit here is almost always a missing or misconfigured WINS server entry.

1. Missing WINS Server IP in TCP/IP Settings

This is the most common cause. Your network adapter doesn't have a WINS server IP configured. Most modern networks don't use WINS (it's been superseded by DNS and LLMNR), but some old apps and print services still require it. When no WINS server is specified, NetBIOS name resolution fails and you get 0x00002590.

Fix it:

1. Open Network and Sharing Center → Change adapter settings.
2. Right-click your active network adapter → Properties.
3. Select Internet Protocol Version 4 (TCP/IPv4) → Properties.
4. Click Advanced → WINS tab.
5. Click Add and enter the IP address of your WINS server. If you don't have one, you'll need to set one up or skip to the DNS fix below.
6. Check Enable NetBIOS over TCP/IP if it's disabled.
7. Click OK all the way out.

Don't bother with the "Use NetBIOS setting from DHCP server" option unless you know your DHCP scope pushes WINS server info — most don't. Set it manually.

2. WINS Server Unavailable or Not Running

Sometimes the WINS server IP is configured, but the actual server isn't running WINS or is down. I've seen this after a domain controller migration where someone forgot to move the WINS role, or after a server reboot where the WINS service didn't start.

Check these:

• On the WINS server, open Services.msc and verify the Windows Internet Name Service (WINS) is running. If it's stopped, start it and set it to Automatic.
• Check the server's firewall — WINS uses UDP port 137 (NetBIOS name service) and TCP/UDP 138 (NetBIOS datagram) and 139 (NetBIOS session). Make sure inbound rules allow traffic from your client subnets.
• If the WINS server is on a different subnet, verify routing and that the WINS server's IP is reachable. Use ping <WINS_IP> and nbtstat -a <WINS_IP> to test.

A quick test: from the client, run nbtstat -n. If you see "Host not found" or no entries, WINS resolution is broken.

3. NetBIOS Over TCP/IP Disabled

If NetBIOS over TCP/IP is disabled on the client, WINS doesn't work at all. This happens sometimes on security-hardened systems or after group policy changes. The error still shows 0x00002590 even if a WINS server is set.

Fix it:

1. Go back to the same Advanced TCP/IP Settings → WINS tab (as in fix #1).
2. Select Enable NetBIOS over TCP/IP.
3. If group policy forces it disabled, you'll need to override via local policy or registry.

Registry fix if policy is blocking it:

HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{Interface GUID}
Value: NetbiosOptions (DWORD)
0 = Default (use DHCP)
1 = Enable NetBIOS
2 = Disable NetBIOS

Set it to 1 and reboot. Don't use the "Default" option unless your DHCP server pushes NetBIOS settings — most don't.

Quick Reference Table

If none of these work, you're likely dealing with a resolved name that's stuck in cache. Run nbtstat -R (capital R, reloads cache) and ipconfig /flushdns. Still failing? Consider migrating that legacy app to use DNS instead of WINS — WINS is deprecated and Microsoft recommends using DNS for name resolution. But if the app's hardcoded to use NetBIOS, you're stuck with WINS. I've kept a single WINS server running on a 2012 R2 box just for one ancient billing app. It happens.