Windows 8.1 / 10 GPO mapped drives won't connect

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 1:

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.