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.

  • 1
    This does not happen when the drive is connected manually? – Daniel Sep 28 '15 at 8:09
  • @Daniel correct, all works OK when connecting manually. – Lenniey Sep 28 '15 at 9:20
  • 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). – Daniel Sep 28 '15 at 13:25
  • @Daniel just did that with the latest drivers, but nothing changed. I'll try the network ports approach. – Lenniey Sep 29 '15 at 6:50
  • 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! – Daniel Sep 29 '15 at 14:36
up vote 2 down vote accepted

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.

  • 1
    "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? – Daniel Nov 4 '15 at 12:57
  • 1
    @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. – Lenniey Nov 4 '15 at 13:06

This issue in my environment manifest only with DFS maps and appears sometimes till from 8 and 8.1 but in 10 Anniversary is sistematic.

This Is my personal workaround: in GPO I create a Scheduled Task that runs every time a user logon that launch the logon script

It works like a charm ...

Try Turning off UAC on the client, it helped us.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.