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 testsecho %logonserver%
always returns a local DCnltest /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 problema, 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.
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
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 setDrive 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 inC:\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.