W7 Workstations in Domain periodically disconnect from DC/FS.

You didn't mention which version of Windows the workstations are running. There have been changes to the SMB protocol recently since SMB 1.0 is completely compromised. In addition there was something about "hardened paths" to the Logon folder starting a couple of years ago. For a while on my own local network I had to Delay start the Network Location Awareness service because it wasn't always detecting a Domain network. Somewhere here on Technibble I posted stories about my issues with this. Although in my case stuff just didn't work right from the beginning, it didn't work for a time and then disconnect later. One more thing to throw out there, are your workstation's using an AV with integrated firewall that might be blocking domain authentication traffic?
 
You didn't mention which version of Windows the workstations are running. There have been changes to the SMB protocol recently since SMB 1.0 is completely compromised. In addition there was something about "hardened paths" to the Logon folder starting a couple of years ago. For a while on my own local network I had to Delay start the Network Location Awareness service because it wasn't always detecting a Domain network. Somewhere here on Technibble I posted stories about my issues with this. Although in my case stuff just didn't work right from the beginning, it didn't work for a time and then disconnect later. One more thing to throw out there, are your workstation's using an AV with integrated firewall that might be blocking domain authentication traffic?

It's an up to date version of W7 ... and no they don't run a software firewall on each workstation.
 

Bingo. Likely Comcast? Anyways...the ISP provided "gateway" likely has IP6 enabled, and DHCP handing out both IPv4 and IPv6 addresses. The DNS for IPv6 is public DNS servers, thus internal name resolution and internal browsing 'n such will fail.

This is an easy fix, disable DHCP for IPv6 on the gateway.

We usually don't allow ISP gateways to be the firewall for our clients, we usually bridge 'em or put public IP passthrough mode on with them, using our own firewall/routers. But on the few wee small clients we have with this setup, I always avoid issues like yours and others by simply disabling the IP6 DHCP on the gateway.

The workstations 'n servers will APIPA their IPv6..and things will work fine.
Actually disabling IPv6 on workstations and servers can cause other headaches you don't want. Really no need to actually disable IPv6 on the computers. And, it's only a few seconds and a quick gateway reboot to disable it there in that one spot and cure your issues.
 
Bingo. Likely Comcast? Anyways...the ISP provided "gateway" likely has IP6 enabled, and DHCP handing out both IPv4 and IPv6 addresses. The DNS for IPv6 is public DNS servers, thus internal name resolution and internal browsing 'n such will fail.

This is an easy fix, disable DHCP for IPv6 on the gateway.

We usually don't allow ISP gateways to be the firewall for our clients, we usually bridge 'em or put public IP passthrough mode on with them, using our own firewall/routers. But on the few wee small clients we have with this setup, I always avoid issues like yours and others by simply disabling the IP6 DHCP on the gateway.

The workstations 'n servers will APIPA their IPv6..and things will work fine.
Actually disabling IPv6 on workstations and servers can cause other headaches you don't want. Really no need to actually disable IPv6 on the computers. And, it's only a few seconds and a quick gateway reboot to disable it there in that one spot and cure your issues.

The server is doing DHCP, which I setup from the beginning and DHCP is disabled in the gateway. Maybe I enabled IPv6 in the DHCP options when I set it up ... I cant remember
 
Ahh gotcha...well, it's proper to do DHCP on the server, just...saw this and I (incorrectly) assumed the gateway was doing it.

I'd triple check things here...once a workstation joins a domain Windows "should" set the firewall to domain network (same as "work").
The fact that it isn't..making me think something is wrong with active directory.
Confirm...servers TCP/IP v4 properties..it looks at itself as the one and only DNS server (post IPCONFIG /ALL of server)
Confirm..workstations ONLY getting server IP for their primary DNS, no secondary DNS. (post IPCONFIG /ALL of a workstation)
 
Ahh gotcha...well, it's proper to do DHCP on the server, just...saw this and I (incorrectly) assumed the gateway was doing it.

I'd triple check things here...once a workstation joins a domain Windows "should" set the firewall to domain network (same as "work").
The fact that it isn't..making me think something is wrong with active directory.
Confirm...servers TCP/IP v4 properties..it looks at itself as the one and only DNS server (post IPCONFIG /ALL of server)
Confirm..workstations ONLY getting server IP for their primary DNS, no secondary DNS. (post IPCONFIG /ALL of a workstation)

This is done via two settings...

1.) The IP range in Sites and Services, if the network was renumbered, perhaps the wrong IP range is in there?
2.) Group policy

The combination of the two on network connection causes the Network Location Awareness service to set the local firewall profile. Honestly, the mechanism is rather annoying, and the primary reason why I no longer have Hyper-V Hosts as domain members.
 
Yeah, but you can't use Hyper-V fully without it being a domain member!

Which is not a role or service, but...I actually prefer not to have it be a member..I keep them (all of them..quite a few) in workgroup mode. been stuck before when DC not up and they can't log in. The GUI Hyper-V in single install environments. Realizing benefits to being a domain member of non GUI mode and clusters...and we have those too.
 
Which is not a role or service, but...I actually prefer not to have it be a member..I keep them (all of them..quite a few) in workgroup mode. been stuck before when DC not up and they can't log in. The GUI Hyper-V in single install environments. Realizing benefits to being a domain member of non GUI mode and clusters...and we have those too.

Yeah, if you have enough servers to ensure that a DC is always up, domain member is the way to go. But if you do the SMB single server thing member server all the way!

Oh, and I'm not sure if you're seeing this but I'm having problems with VMs not booting properly on my 2016 guests if they're auto-started too soon after the April update rollup... so there's that too.
 
Oh, and I'm not sure if you're seeing this but I'm having problems with VMs not booting properly on my 2016 guests if they're auto-started too soon after the April update rollup... so there's that too.

I've always started with a 30 second delay for the first guest (DC)...and then often a minute delay for the remaining guests (or staggered even more if many guests...but honestly for many guests I usually step up to VMWare by this point)

Have not seen the issue, you get it with BroadlessCom NICs or also with Intel NICs? I stared avoiding broadcom quite a few years ago..way too many issues. G1 or G2 guests?
 
I've always started with a 30 second delay for the first guest (DC)...and then often a minute delay for the remaining guests (or staggered even more if many guests...but honestly for many guests I usually step up to VMWare by this point)

Have not seen the issue, you get it with BroadlessCom NICs or also with Intel NICs? I stared avoiding broadcom quite a few years ago..way too many issues. G1 or G2 guests?

G2 guests, Intel NICs, the issues aren't all network. I had a DC report sysvol was corrupt, reboot and WHAM online.

Doesn't happen as much on normal reboots, just update reboots... drives me nuts. 30 second delay on the first guest is a solid one, that's where I am. I noticed the guests that started 30-45 seconds late seemed to have less issues. The server in question was fine from Dec to April... so four months and four reboots without issue, then BOOM problems.

So now all my hosts are manual updates and I'll update them when I feel like it.
 
Back
Top