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.

  • Curious if this is related: social.technet.microsoft.com/Forums/en-US/… No group policy is involved, but it is related to mapped network drives. Particularly interesting is this observation: "I have noticed that if you upgrade to windows 10 from windows 8, you can access to the NAS and have your drive mapped. However, if you install windows 10 'clean' or from scratch, it is impossible to map the drive." – Daniel Nov 22 '15 at 1:55
  • Another similar report, but also from Windows 10 Preview. Not sure if these are still relevant: answers.microsoft.com/en-us/insider/forum/… – Daniel Nov 22 '15 at 1:59
  • As interesting as it is, why not solve it with a simple "net use" (or "wshNetwork" if you prefer) script? Anyway, have you tried configuring the GPO of Fast Logon Optimization? technet.microsoft.com/en-us/magazine/gg486839.aspx, technet.microsoft.com/library/jj573586.aspx – EliadTech Nov 22 '15 at 15:48
  • 1
    Try setting this Control How Group Policy Is Applied At Logon. It ensures your system waits for the network on the local system to always be available before processing GPOs. – AndreVSWorld Nov 25 '15 at 3:01
  • Research (google) showed me that mapping drives via logon scripts is no longer supported for Windows 8+ and that mapping via Group Policy is the recommended method – Daniel Nov 25 '15 at 4:43

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.

  • The Synology servers are joined to the domain. This is how users (and groups) are able to access their mapped drives. The shares on the Synology servers have permissions based on the AD users and groups. – Daniel Nov 25 '15 at 4:40
  • 1
    You don't need to earn reputation for the privilege to ask questions. Anyone can ask unless your account gets banned by the system or a moderator, which is as far as I can tell not the case. – HBruijn Nov 25 '15 at 10:04
  • Please do not post Answers unless they actually answer the Question. ServerFault is a Q&A platform and not a forum. If you have new Question, please ask it by clicking the Ask Question button from the menu at the top of this page. If you have sufficient reputation, you may upvote this question to give it more attention. Alternatively, "star" it as a favourite and you will be notified of any new answers.Thank you. – HBruijn Nov 25 '15 at 10:05
  • 1
    @HBrujin, what I meant is that this site tells you that until your rep is 50 or higher, you're not supposed to ask questions of the person who posts the original issue. You're only supposed to offer solutions. Which I totally understand, to a degree. Daniel, my next recommendation would be to test the GPO against a traditional Windows computer hosting a shared folder. If you've already tested this, well then that would leave me stumped for a while. I wish I could test this in my lab, but we're on Win7/2008R2 right now, and won't be on your versions until next year. – El Zilcho Nov 25 '15 at 13:13
  • My apologies, I read "ask a question", but apparently what you intended is called, in ServerFault jargon, to post a "comment", which is indeed a privilege for which one needs 50 points. - We do occasionally get people who are unfamiliar with the Q&A format hence my second comment. – HBruijn Nov 25 '15 at 14:41

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?

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.

  • That doesn't explain why my Windows 8.1 Pro -> Windows 10 clients have no issue, but my clean-install Windows 10 clients all have the issue. As far as I know, fastboot hasn't changed significantly from 8 to 10, but UNC Hardening has changed from default off to default on. – Daniel Nov 27 '15 at 13:57
  • I will admit, I've had to do some rapid reading to bring myself somewhat up to speed on UNC hardening. However, checking the local GP of the non-domain joined Windows 10 client I have, as well as my 2008R2 domain's default GPs (with no Win10 clients), I can confidently say UNC hardening is not enabled by default. Further still, all of the information I've read this morning states that even IF you enable UNC Hardening, it's still an inclusive policy. Meaning, any UNC paths you enter into the policy get hardened. All other paths remain un-hardened. – El Zilcho Nov 27 '15 at 15:06

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.