Windows 10 machine won't browse network shares

[DocGreen]

Running into a weird issue on a W10 Pro machine. I've got it connected to my home network and registered through my Server2k12r2 domain server. When I browse attempt to browse the shares on my server (either by clicking on the server in Explorer, or entering the share path) it tells me that the path cannot be found (even though it clearly sees the server). It won't let me browse the shares until I've clicked "diagnose" on that popup window (which of course can't find an problem). Once I've tried diagnosing, it works just fine without any problems. It will continue to work fine until I go a short period of time without browsing the shares... in which case I have to rinse and repeat.

I'm also having trouble with saved RDP credentials to a Windows 7 machine on the same network. When I try to connect, I get an error saying "Your credentials did not work. Your system administrator does not allow the use of saved credentials to log on to the remote computer ____ because its identity is not fully verified." Entering the credentials manually allows me to connect just fine.

I don't have this problem on any other machine on my network. Googling the RDP error message returns a bunch of results telling me to change GP to allow the credentials to be saved, but I feel like that's not actually fixing the problem, which is that the W10 machine is unable to verify the identity of the remote computer... which I'm almost certain is related to the (if not the same) problem I'm having browsing server shares.

Anyone else run into this? I've looked for network services not running, but I haven't noticed anything out of the ordinary. Is there a particular service that may cause this if not running? I'm at a loss.

Thanks in advance!

 

[Computer Bloke]

Anything interesting in the Event Log?

 

[DocGreen]

Anything interesting in the Event Log?

Nothing that stands out to me.
I waited until 12:00:00am and tried the RDP connection (failed w/ saved credentials, succeeded w/ manual entry), then tried browsing the server share (same result as described above)... then filtered events to show all events from 12:00:00am to current.

All the security-auditing entries show "audit success", btw.

 

[Sky-Knight]

I've seen this once, kerberos was mangled. I fixed it by taking the machine off the domain, and putting it back on. Then running gpupdate /force, and rebooting once more.

My theory is that the windows firewall configuration for the domain got mangled, and network location wouldn't ever report it was on the domain network. Because the machine was using the public profile, no SMB traffic.

 

[DocGreen]

I've seen this once, kerberos was mangled. I fixed it by taking the machine off the domain, and putting it back on. Then running gpupdate /force, and rebooting once more.

My theory is that the windows firewall configuration for the domain got mangled, and network location wouldn't ever report it was on the domain network. Because the machine was using the public profile, no SMB traffic.

Thanks. I'll give that a go in the morning and report back.

 

[HCHTech]

I had one recently that would stubbornly keep changing it's network definition to "public". If I recall, the standard networking reset plus an uninstall and reinstall of the card fixed it.

 

[DocGreen]

I've seen this once, kerberos was mangled. I fixed it by taking the machine off the domain, and putting it back on. Then running gpupdate /force, and rebooting once more.

My theory is that the windows firewall configuration for the domain got mangled, and network location wouldn't ever report it was on the domain network. Because the machine was using the public profile, no SMB traffic.

Finally had a minute to try that... didn't help.

I had one recently that would stubbornly keep changing it's network definition to "public". If I recall, the standard networking reset plus an uninstall and reinstall of the card fixed it.

I thought about that too. The network is properly identifying as "domain" in both Network & Sharing and in Firewall.

 

[GTP]

Had a poke around in the Host file?

 

[DocGreen]

Had a poke around in the Host file?

Yeah... same file I use on all my other PCs
(bunch of ad-blocking stuff)

 

[YeOldeStonecat]

Network Discovery on in the clients?
They're ONLY using the IP of the DC(s) for their DNS, right? No router or ISP or other public DNS in the mix?

 

[Metanis]

I've had issues in the past that largely have seemed to resolve themselves by newer updates to Windows 10. Here are the 2 threads I started on them...

Please note it is NOT recommended to enable SMB 1.0 on a modern network due to known exploits in that code...

https://www.technibble.com/forums/t...orking-smb-configuration-in-windows-10.68432/

https://www.technibble.com/forums/t...rk-type-identification-issues-resolved.71506/

 

[DocGreen]

Network Discovery on in the clients?
They're ONLY using the IP of the DC(s) for their DNS, right? No router or ISP or other public DNS in the mix?

Discovery is on. DC's IP is the only one listed for DNS (defined in router's DHCP settings, verified on the client by ipconfig).

 

[DocGreen]

These are the differences between the two machines

Machine A - This one works fine
Workgroup machine (not connected to the domain)
Originally upgraded from Win7 Pro
Version 1709 (Build 16299.248)

Machine B - This one has the problem
Domain machine
Win 10 Pro pre-installed
Version 1709 (Build 16299.192)

There's a mix of other machines as well that don't have any problems, but they're not usually used.

 

[GTP]

Have you tried manually adding the IP's of the other computers to the host file?

 

[YeOldeStonecat]

Discovery is on. DC's IP is the only one listed for DNS (defined in router's DHCP settings, verified on the client by ipconfig).

Server should be doing the DHCP, not the router..but...that's not the cause of this problem. With certain services, if a DC isn't doing the DHCP some services can be unreliable.

 

[YeOldeStonecat]

You may have mentioned it above...
But if you try exploring \\servername\stuff ....(like if you type that into Search or top of an Explorer window) you mention it won't work until after you do "diagnose".
But without doing "diagnose"...will it work via IP address? Like \\192.168.11.11\stuff?

Is the "workstation" service and "DNS Client" service successfully running after each reboot? Check in services.msc

 

[YeOldeStonecat]

And confirming the Win10 box is being logged in as domainname\username not just username which can mistakingly lead to a local user account if one was on there already.

 

[DocGreen]

You may have mentioned it above...
But if you try exploring \\servername\stuff ....(like if you type that into Search or top of an Explorer window) you mention it won't work until after you do "diagnose".
But without doing "diagnose"...will it work via IP address? Like \\192.168.11.11\stuff?

Is the "workstation" service and "DNS Client" service successfully running after each reboot? Check in services.msc

I hadn't thought to try that. Yes, browsing via IP does work... going back after to browse by server name still doesn't work even after browsing by IP. I did verify that Workstation and DNS Client services are running after restart (DNS Client is listed as "Triggered Start" btw). Also verified that I'm logged in with a domain account.

Just to recap... the issues are isolated to this one workstation. It's affecting this workstation's access to multiple other machines, both domain and workgroup. It seems to be all related to stored credentials, and this workstations inability to verify the other machines' identities. (as mentioned in the RDP error above)

Have you tried manually adding the IP's of the other computers to the host file?

I thought of that, but I wanted to try to chase down the problem first before implementing a workaround.

 

[HCHTech]

I would say after 8 or 9 days now, just nuke & pave and throw in a new (good) NIC for good measure. Something is obviously FUBAR and I'll bet the client would like to get back to work.

 

[DocGreen]

I would say after 8 or 9 days now, just nuke & pave and throw in a new (good) NIC for good measure. Something is obviously FUBAR and I'll bet the client would like to get back to work.

It's my own machine, not a client's. I wouldn't waste this much time on someone else's machine, lol. (It's also a Dell MicroPC, so no option to change the NIC)