I have seen a similar phenomen.
Symptoms sound not too similar at first sight: Windows Explorer sometimes hangs for a few seconds regardless whether a local disk or a network share is accessed.
But after some investigation I believe the hang is caused by a similar NetBIOS issue.
Some system details:
- Windows XP Pro SP3
- VMware Server 1.0.9 installed
- VMNet1 (host-only) network adapter
and NetBOIS over TCP/IP enabled
- VMNet8 (NAT) network adapter and
NetBOIS over TCP/IP enabled
- The system's only physical network
adapter's static IP address is
192.168.10.111. This adapter is configured to use 192.168.10.192 as
its only WINS server. MAC address:
00-16-17-FA-2C-D4
- On the VMNet1 adapter the system's
static IP address is 192.168.137.1.
No WINS server configured. MAC
address: 00-50-56-C0-00-01
- On the VMNet8 adapter the system's
static address is 192.168.145.1. No
WINS server configured. MAC address:
00-50-56-C0-00-08
- All VMs are configured to use NAT but
are stopped anyway.
I was running Wireshark all day sniffing packets on the physical adapter. I noticed that whenever Explorer hung for a few seconds simultaneously a NetBIOS Name Service query packet was sent to the WINS server. These packets contained one of the VMNet adapter's address as its source IP address!
Here's one of the suspicious packets:
Frame 25475 (92 bytes on wire, 92 bytes captured)
Ethernet II, Src: 00:16:17:fa:2c:d4 (00:16:17:fa:2c:d4), Dst: 00:15:c5:87:4f:6a (00:15:c5:87:4f:6a)
Internet Protocol, Src: 192.168.145.1 (192.168.145.1), Dst: 192.168.10.192 (192.168.10.192)
User Datagram Protocol, Src Port: netbios-ns (137), Dst Port: netbios-ns (137)
NetBIOS Name Service
Transaction ID: 0x82a5
Flags: 0x0000 (Name query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>: type NBSTAT, class IN
I think this is not correct. The packet's source IP address should be set to 192.168.10.111 instead.
I haven't sniffed packets on the WINS server's interface. But I expect it to send a reply to 192.168.145.1 via its default gateway since it is not connected to the 192.168.145.0 network. The gateway should reject this packet with "network unreachable".
As this is a UDP packet there's no connection in SYN_SENT state. But a TCP SYN packet that is "corrupted" in the same way should leave the connection in SYN_SENT state until a timeout occurs.
Some things I tried to work around this problem:
- Disable both the VMNet adapters:
Problem solved. No suspicious
packets.
- Re-enable VMnet1: Explorer starts
again hanging sometimes. Suspicious
packets with source 192.168.137.1.
- Disable VMNet1 and re-enable VMNet8:
Explorer hangs sometimes. Suspicious
packets with source 192.168.145.1.
- Enable both the VMNet adapters, but
disable NetBIOS over TCP/IP for
both: Problem solved. No suspicious
packets.
- Re-enable NetBIOS over TCP/IP for
VMNet1: Explorer starts again
hanging sometimes. Suspicious
packets with source 192.168.137.1.
- Disable NetBIOS over TCP/IP for
VMNet1 and re-enable it for VMNet8:
Explorer hangs sometimes. Suspicious
packets with source 192.168.145.1.
- Change interface metrics from
automatic metric to static values
for all interfaces. The LAN adapter
having the lowest metric: Explorer
still hangs sometimes and suspicious
packtes captured.
I have checked adapter ordering in Network Connections->Advanced->Advanced Settings as well as by running netsh interface ip show config. Local Area Connection is the first connection listed in both places.
Additionally I noticed some NTP packets with source IP address 192.168.137.1 as well as 192.168.145.1 being sent to 192.168.10.192 (it's an AD DC) via the physical adapter.
Ok, after spending 3 weeks with Microsoft's technical support department we have solved the problem.
The problem is with Dual Scan trying to connect to Windows Update (online) and failing. When it fails the system just stops trying and refuses to connect to WSUS.
The added problem is the server install media has a bug in it which prevents the Dual Scan from changing. It just ignores the policy and keeps the default update source Windows Update.
Here is what you have to do to fix it:
Run the following commands in Powershell on the offending server
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
$MUSM.Services | select Name, IsDefaultAUService
You will get something back like this:
Windows Update Standalone Installer - False
Windows Server Update Service - False
Windows Update - True
If it says "Windows Update - True" Then that is your default source, no matter what your GPO says...
The first thing you have to do is make sure the following patches are installed on your server.
kb4103720 and kb4462928
You need them BOTH. They are both huge, they both take forever and a day to install and they both require a server reboot.
These KBs fix the dual scan issue so the server will respond to the GPO telling it which default source to use.
Now you need to configure Group Policy to tell the server to only use the WSUS server. Per Microsoft these are the required settings (I am dubious on some of them, but I haven't tested each one... I am just happy the thing is finally working)
Computer Configuration > Policies > Administrative Templates > System > Device Installation
Specify the search server for device driver source locations
Set to "Enabled"
Select search order: "Do not search Windows Update"
Specify the search server for device driver updates
Set to "Enabled"
Select Update Server: "Search Managed Server"
Computer Configuration > Policies > Administrative Templates > System > Internet Communication Management > Internet Communication Settings
Turn off access to all Windows Update features (In Microsoftspeak that means their online server, not 'make so it can't get updates')
Set to "Enabled"
Turn off access to the Store
Set to "Enabled"
Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update
Do not allow update deferral policies to cause scans against Windows Update
Set to "Enabled"
No auto-restart with logged on users for scheduled automatic updates installations
Set to "Enabled"
Specify intranet Microsoft update service location
Set to "Enabled"
Set the intranet update service for detecting updates: "http://[YOUR SERVER]:8530"
Set the intranet statistics server:"http://[YOUR SERVER]:8530"
Set the alternate download server: "http://[YOUR SERVER]:8530"
Uncheck the box Download files with no Url in the metadata if alternate download server is set
Move your servers into an OU with this GPO enabled. I created a separate OU in my Servers OU just for 2016 server and linked this GPO to it.
Run the above powershell commands again.
It should now say
Name IsDefaultAUService
------- --------------------------
Windows Server Update Service True
Windows Update False
If you get "Windows Server Update Service" True, then it should work!
I hope this helps someone else. This has certainly been a frustrating issue...
I accept donations in unmarked bills, gold bars and scotch.
Best Answer
The interface that works has NetBIOS over TCP/IP enabled.
It actually makes sense that this would solve the issue if you truly don't have a DNS server configured on your network interfaces. The image you show does not show a DNS server configured.
Being this is a domain controller, you should have 127.0.0.1 as the primary DNS server, and any other domain controllers as the secondary, tertiary, etc. All OTHER machines on the network that are not domain controllers should have one or more of your domain controllers configured as their DNS server - preferably via DHCP options.
Without a valid DNS setting this domain controller is going to have all kinds of problems, and NetBIOS is an alternative name resolution service for file sharing.