Windows 8.1 / 10 GPO mapped drives won't connect

Question

UPDATE: not solved...

The issue persists, I also tried the hardened UNC paths approach, still no luck. I'll keep updating this thread if I encounter something new.

UPDATE and solved (hopefully)

Seems like the problem was triggered by the "fast boot" option in Windows 10 (and 8.1). There even is a TechNet article describing something like it. I went and deactivated fast boot for all clients via a registry GPO (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled, REG_DWORD 0x0 (0))

Right now the network shares are mapped upon boot and reboot. I hope it stays that way.

---

In my environment (Server 2012 R2 domain with three DCs, all GCs) there are some issues with mapped drives via GPPs, but only with Windows 8.1 and Windows 10 clients (all updates installed).

The GPPs map 7 drives, 4 of them are on the main DC and fileserver, the other 3 on DFS shares.

If the Win8.1 / Win10 clients connect, sometimes the drives appear, but most of the time they don't. If I run a gpupdate /force via commandline all of them connect. When after some time idle the user wants to browse a share (doesn't matter if DFS or fileserver), an error pops up:

Error 0x80090006: Invalid Signature

But if they click on the drive again, all is well. I tried every possible fix I can imagine, setting the GPPs to wait for network before starting, setting the autodisconnect time on the servers to infinite via net config server /autodisconnect:-1, deleting the GPPs and starting from scratch, checking and rechecking sysvol permissions, but all to no avail.

The clients also sometimes display an error in the eventlog that no DC can be accessed, which is nonsense because all other GPOs and GPPs (printers, for example) are processed every time, only mapped drives are faulty.

Did someone encounter anything like that, too? Any tip will be highly appreciated.

UPDATE

Right after starting the client, sometimes this error appears in eventlogs (on the client), too:

Event ID 1058, GroupPolicy (Microsoft-Windows-GroupPolicy)

The processing of Group Policy failed. Windows attempted to read the file \domain.local\SysVol\domain.local\Policies{5898270F-33D0-41E8-A516-56B3E6D2DBAB}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following: a) Name Resolution/Network Connectivity to the current domain controller. b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller). c) The Distributed File System (DFS) client has been disabled.

I will try and look at that.

Solution

After a LOT of testing and waiting for user feedback, I tried the above mentioned Hardened UNC approach, but this time not via GPO itself, but via a GPP to set the appropriate registry entries (HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths\\\*\NETLOGON || SYSVOL - RequireMutualAuthentication=0, RequireIntegrity=0) directly. Lo and behold! It works...I have no idea why the implemented GPO options don't, though. Maybe I did something wrong, but at this time I really don't care anymore, as long as it works. Microsoft will probably release a (new) hotfix soon anyway.

EDIT: Please remember that the hardened UNC Paths were implemented to fix a "critical" Windows security issue, which can be dated back to the year 2000. By deactivating the hardened UNC paths you actively open that hole again, if it's worth it depends on your topology and / or needed infrastructure security.

Comments

[Daniel]

This does not happen when the drive is connected manually?

[Lenniey]

@Daniel correct, all works OK when connecting manually.

[Daniel]

Try updating your network drivers on the client. If that does not solve it, do the same on the file server. If that also does not solve it, try to use a different network port on the file server (if possible).

[Lenniey]

@Daniel just did that with the latest drivers, but nothing changed. I'll try the network ports approach.

[Daniel]

Great to see that you might have found a solution to your problem. Please remember to add the solution as an answer, if it's a definite fix. Cheers!

[Greg Askew]

@Lenniey: Is that the GPO with the drive mappings? Is the gpt.ini present, ,readable, and the same on all domain controllers?

[strongline]

gpt.ini missing is a result of same problem, not the cause. I did a bit googling, people suggesting checking NIC drive and AV. Try to disable as much 3rd party as possible just to isolate the issue.

[Lenniey]

@GregAskew No, the gpt.ini errors affect random policies, sometimes proxy configuration, sometimes drive maps, sometimes WSUS...only a generic error sometimes. I disabled everything there is to disable I think, even Windows defender, updated all drivers and so on, to no avail I'm afraid

[Lenniey]

@strongline see above

[Greg Askew]

@Lennie:are you saying there are event id 1058 events with different gpt.ini files?

[Lenniey]

@GregAskew exactly. They slighlty differ from time to time, so there are not always the same gpt.inis referenced. If I want to browse the sysvol with the "faulty" gpt.ini right after boot, an error is raised, if I wait for 30sec or so, everything works. (Just like the mapped drives).

[Greg Askew]

That isn't a problem with the GPO. The GPO/mapped drives are a symptom of a more fundamental problem.

[Lenniey]

@GregAskew Yeah I know that, that's why I tried the "fast boot" approach. Funny thing is: if the client gets the mapped drives from the GPP only ONCE, from that time on it seems like it always maps the shares...I'm at a loss here.

[Greg Askew]

@Lenniey: I would not be too distracted by one symptom.

[Lenniey]

@GregAskew Nah, I'm not, at the moment I'm searching for any signs of problems with DNS, AD, and so on. Can't find anything + Win7 works flawlessly, I have no idea...right now we're using the workaround to wait ~1min till the users log into Windows, but that's what it is, a temporary workaround till I fix the main problem.

[Daniel]

I had a similar problem. Drives were shown under 'net use' but not in Explorer. I was able to browser the drives in cmd.exe. Workaround was to kill explorer.exe and restart it. Then it would show up in Explore, too .. No idea why, tho.

[Daniel]

"Microsoft will probably release a (new) hotfix soon anyway." Out of curiousity, not because I want to be a dick about it: Have you talked to Microsoft (opened a call), or is that an assumption?

[Lenniey]

@Daniel Well I thought I read about it somewhere, but can't find it anymore, meh. Funny thing is, while searching for the information I came about this thread which answers the exact same problem nearly the same way, even with the disclaimer and all.