Group Policy: Mapped Drives failing to load, Windows Server 2012 Active Directory and Windows Pro 10

Question

Network:

• Multi-site domain.
• Each site has 2 local (on-site, same subnet) Windows Server 2012 R2 Domain controllers.
• Sites are correctly defined in Windows Sites and Services.
• DNS records for each site ONLY have the two local DNS servers defined.
• ALL clients are Windows 10 Pro 64-bit with all updates.
• Both networks are fully gigabit running on Cisco switches with certified CAT6 cabling.
• Each site has a local (on-site, same subnet) Synology storage server.
• As part of Group Policy, two network drives are mapped to shares on the Synology server.

Connectivity Diagnostics:

• dcdiag /test:dns /v /c /e reports PASS for ALL servers and ALL tests
• echo %logonserver% always returns a local DC
• nltest /dsgetdc always shows a local DC and correct local IP
• On Site A, both network drives show up, with maybe a 0.5% chance of failure (I have experienced a few boots where the drives don't show up correctly).

Issue:

At Site B, network drives fail to show up perhaps 30% of the time. Sometimes it is both drives, sometimes it is one or the other. The problem is mostly random, and does not seem to follow any particular user or Workstation.

Symptoms:

Of the 30% of the time where a problem presents itself:

• 5% of the time a gpupdate or gpupdate /force will fix the problem and the drives will immediately appear. If the gpupdate doesn't work on the first attempt, it will pretty much never work after that (for that boot)
• 5% of the time a gpupdate or gpupdate /force will cause just one drive to appear
• 20% of the time, a gpupdate will not fix the problem, but the next boot will be fine
• 50% of the time, a gpupdate will not fix the problem, but after one boot and another gpupdate, the drives will appear

• 20% of the time, it will take multiple reboots (and gpupdate for each boot) before the drives appear. Sometimes it is 2 boots, but I have had to rarely reboot a computer sometimes 6 or 7 times before the drives appear.

  • For this last 20% of the time, I will sometimes get errors from the gpupdate process.

    The processing of Group Policy failed. Windows attempted to read the file 
    \domain\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.
    

  • This error is actually, usually but not always, a good sign because generally after I get this error, the next ´gpupdate´ or the next boot and ´gpupdate´ will make the drives reappear.

Drive Map Diagnostics:

1. gpresult /h gpresult.html shows:

   Drive Map (Drive: X)
    The following settings have applied to this object. Within this category, settings nearest the top of the report are the prevailing settings when resolving conflicts.
      X:
       Winning GPO  DriveMaps 
        General Settings
         Result: Success
   

2. I have enabled group policy environment debug logging (per http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx created registry entry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002). The log file in c:\Windows\debug\UserMode\gpsvc.log has not shown me any clear errors, nor have I been able to find much help through google. Here are some interesting messages I have received:

   GPSVC(158.33c) 23:33:24:921 CheckGPOs: No GPO changes but extension Group Policy Drive Maps's returned error status 183 earlier.  
   GPSVC(158.c24) 23:38:12:203 ProcessGPOs(Machine): Extension Group Policy Drive Maps skipped with flags 0x110057. 
   GPSVC(158.157c) 23:08:08:216 ProcessGPOs(User): Extension Group Policy Drive Maps ProcessGroupPolicy failed, status 0xb7.
   

3. I have enabled group policy preferences debugging for Drive Maps (as per http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat.aspx set Drive Map Policy Processing to Enabled and turned on Event Logging in properties of \Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing ). The log file in C:\ProgramData\GroupPolicy\Preference\Trace\User.log has not returned any errors.

   2015-11-21 17:47:38.849 [pid=0x22c,tid=0xcd0] Starting class <Drive> - X:.
   2015-11-21 17:47:38.864 [pid=0x22c,tid=0xcd0] Adding child elements to RSOP.
   2015-11-21 17:47:38.880 [pid=0x22c,tid=0xcd0] Beginning drive mapping.
   2015-11-21 17:47:38.896 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] User does not have a split token.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] Drive doesn't exist (full token).
   2015-11-21 17:47:39.114 [pid=0x22c,tid=0xcd0] Connected with access name x:.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification Session ID is 2.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification discovered drive mask of 8388608.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] SendNotification drive event broadcast sent.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] SendNotification to Shell.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Properties handled.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Handle Children.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] EVENT : The element of user preferences 'X:' of the group policy object 'DriveMaps {06FEB8B9-632C-4A1C-A7C9-5A05E1041BEE}' was applied correctly.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] Completed class <Drive> - X:.
   

4. I also have several netmon captures of a login with drives failing to load, but the capture has so much information I'm not sure where to begin.

5. If, after a failed login, I try to browse directly to \\SynologyServer\ShareName\, the share always loads immediately without any errors. There are no signs of connection or permission problems.

Question:

Why is this problem happening so frequently at one site, but almost never at the other site, when both are on the same domain, have the same policy, and are running the same software?

The only software difference I can think of is that at Site A, all the computers were running Windows 8.1 Pro and were upgraded to Windows 10 Pro, whereas at Site B, all computers have fresh installs of Windows 10 Pro.

Answer 1

Since I have almost no rep, I can't ask questions yet, so I'll attempt to ask a question whilst posting an answer and hope I don't get canned. ;)

I'm going to assume that you've insured that the GPO portion of this case is a non-issue, by testing this GPO against a "traditional" UNC share on another Windows system. The important missing information though in my opinion is whether or not the Synology devices are joined to the domain. A lot of Linux-based NAS units like Synology, QNAP, et al, have software components imbedded that allow them to participate in Active Directory domains. Whether or not this device is participating in the domain affects the solution.

That being said, I have remote facilities in my network interconnected with T1 circuits. We require the use of Acronis imaging backups on all systems due to system requirements. Thus, remotely backing up multi-GB images of Windows workstations over T1s is a non-starter. So we placed Drobo NAS units on each local segment to overcome this and give us a bit of fault tolerance. These particular Drobos do not have the ability to participate in the AD domain.

To enable the UNC shares as configured, we had to set up two main things. First, we created static DNS entries on the DNS servers to allow for proper name resolution. And second, we had to "loosen" two policies that DISA normally recommends for most domain members. We only loosened these policies on the backup server, and the workstations being backed up at "slow link" sites, as these were the only systems needing to access the respective shares:

• Computer Config\Windows Settings\Security Settings\Security Options:
  • Microsoft Network Client: Digitally Sign Communications (Always) = Disabled
  • Microsoft Network Client: Send Uncrypted Password to Third Party SMB servers = Enabled
  • Microsoft Network Server: Digitally Sign Communications (Always) = Disabled

The GPOs to "Digitally Sign Communications if Negotiated" are still set to Enabled, mitigating a bit of the security risk involved. Once we enabled these changes, the shares could immediately be accessed via UNC path, whereas previously it was impossible.

This is why I said earlier that depending on whether your NASes can participate in the domain or not determines the path of the solution. If they can participate, then DNS and the "SMB" group policies should be a non-issue for you, and thus the solution would lie elsewhere. If they CAN'T participate (like my NASes), then this may be your solution.

Answer 2

Well, I found these threads, and it sounds like a nearly identical situation to mine:

Windows 10: Group Policy fails to apply directly after boot, succeeds later

Windows 8.1 / 10 GPO mapped drives won't connect

Apparently this issue is caused by Microsoft enabling UNC Hardening in Windows 10 by default. This is to fix a security flaw, but apparently unintentionally causes Mapped Drives to mount unreliably. Not surprisingly, it seems Microsoft has yet to address this bug (or have they?)

This also explains why I was having no problems at Site A. Since all the computers there had been upgraded from Windows 8.1 Pro to Windows 10, I assume that settings regarding UNC Hardening transferred from Windows 8 and stayed off, whereas the computers with the fresh install of Windows 10 used the default of UNC Hardening on.

I haven't actually tried the solution yet, but it seems too perfect of a fit to my symptoms not to be relevant. I am worried about a solution that opens my system up to more security threats, so I am looking for alternatives. I don't like the idea of setting this via group policy, and I am wondering if it is possible to turn off UNC Hardening via manually editing of the registry only. I want to experiment on a few computers first before I decide what to do next. However, I can only find steps for changing the setting via GPO or GPP currently...

Any thoughts?

Answer 3

I just want to update this and say that at some point one of the major Windows 10 updates fixed this issue. This is an old question but I don't like to leave things hanging, just in case.

Answer 4

After reading through everything you provided in the update Daniel, I would actually suggest that UNC hardening, while related, is not the root cause here, and that it may actually be the "fastboot" option the OP of the 2nd post said fixed his problem. All of that information about UNC hardening referred to the SYSVOL and NETLOGON shares getting hardened by default. While that issue would prevent your clients from receiving GP updates, the fact is that the Drive Map GPO has already applied at least once to the clients in question, and doesn't NEED to reapply after every reboot (even though it does) to execute the mapping.

Obviously you'll want to test each option independently of the other, but regardless of which option may or may not work, this line of reasoning would appear to be close to the root cause of your issue.