The drive letter is mapped to a 2012R2 file server, fully patched. The client is Win10 1607, fully patched.
Here's the very, very weird thing that just happened. The GPO error that I saw in the event log was for item-level targeting to put this machine into a WSUS group. I finally deleted and recreated the GPO, and was able to do 'gpupdate /force', and the error was gone, using my workstation administrator login to do the gpupdate. I sent the user an email, asking him to log in, make the SSL VPN connection, and do a 'gpupdate /force' - which he did. But, the command produced the same error he got earlier - on the recreated GPO! I'm pretty much done with this, so I've advised him that the next time he's in the office, he needs to save his data, wipe and reload the machine. Kurt On Fri, Aug 25, 2017 at 4:32 PM, Micheal Espinola Jr < [email protected]> wrote: > Sorry if I missed it, but what are the client and server OSs? > > -- > Espi > > > On Thu, Aug 24, 2017 at 6:04 PM, Kurt Buff <[email protected]> wrote: > >> The plot sickens... >> >> After I updated a GPO to disable slow link detection, I ran a gpupdate >> /force on the users machine (over a teamviewer session), and am now >> getting the error and event ID shown below. I did some research >> suggesting that there might be an AD replication problem, but a quick >> analysis with adreplstatus shows no problems, so I'm thinking a >> possible corrupt GPO somewhere. I'll have to do some research to >> figure out which it might be. >> >> C:\temp>gpupdate /force >> Updating Policy... >> >> User Policy update has completed successfully. >> Computer policy could not be updated successfully. The following errors >> were enc >> ountered: >> >> The processing of Group Policy failed. Windows could not apply the >> registry-based policy settings for the Group Policy object >> LDAP://CN=Machine,cn={6ADA2CCE-5829-472C-BC68-1B2CEEEE2E5D}, >> cn=policies,cn=system,DC=example,DC=com. >> Group Policy settings will not be resolved until this event is >> resolved. View the event details >> for more information on the file name and path that caused the failure. >> >> To diagnose the failure, review the event log or run GPRESULT /H >> GPReport.html from >> the command line to access information about Group Policy results. >> >> >> Log Name: System >> Source: Microsoft-Windows-GroupPolicy >> Date: 25/08/2017 10:32:42 AM >> Event ID: 1096 >> Task Category: None >> Level: Error >> Keywords: >> User: SYSTEM >> Computer: GBOTLEY1.example.com >> Description: >> The processing of Group Policy failed. Windows could not apply the >> registry-based policy settings for the Group Policy object >> LDAP://CN=Machine,cn={6ADA2CCE-5829-472C-BC68-1B2CEEEE2E5D}, >> cn=policies,cn=system,DC=example,DC=com. >> Group Policy settings will not be resolved until this event is >> resolved. View the event details for more information on the file name >> and path that caused the failure. >> Event Xml: >> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event";> >> <System> >> <Provider Name="Microsoft-Windows-GroupPolicy" >> Guid="{AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9}" /> >> <EventID>1096</EventID> >> <Version>0</Version> >> <Level>2</Level> >> <Task>0</Task> >> <Opcode>1</Opcode> >> <Keywords>0x8000000000000000</Keywords> >> <TimeCreated SystemTime="2017-08-25T00:32:42.831463400Z" /> >> <EventRecordID>858000</EventRecordID> >> <Correlation ActivityID="{5D2DE826-983B-4914-A319-7076D07A641B}" /> >> <Execution ProcessID="1092" ThreadID="1804" /> >> <Channel>System</Channel> >> <Computer>GBOTLEY1.example.com</Computer> >> <Security UserID="S-1-5-18" /> >> </System> >> <EventData> >> <Data Name="SupportInfo1">2</Data> >> <Data Name="SupportInfo2">1254</Data> >> <Data Name="ProcessingMode">0</Data> >> <Data Name="ProcessingTimeInMilliseconds">9562</Data> >> <Data Name="ErrorCode">5</Data> >> <Data Name="ErrorDescription">Access is denied. </Data> >> <Data Name="DCName">\\zAUDC02p.example.com</Data> >> <Data Name="GPOCNName">LDAP://CN=Machine,cn={6ADA2CCE-5829-472C- >> BC68-1B2CEEEE2E5D},cn=policies,cn=system,DC=example,DC=com</Data> >> <Data Name="FilePath">\\example.com\sysvol\example.com\Policies\{6 >> ADA2CCE-5829-472C-BC68-1B2CEEEE2E5D}\Machine\registry.pol</Data> >> </EventData> >> </Event> >> >> On Thu, Aug 24, 2017 at 12:22 AM, Micheal Espinola Jr >> <[email protected]> wrote: >> > You should be able to raise the threshold of slow link detection to >> > compensate. If you dont allow ping to traverse, the link will always >> > register as slow. >> > >> > -- >> > Espi >> > >> > >> > On Wed, Aug 23, 2017 at 7:21 PM, Kurt Buff <[email protected]> wrote: >> >> >> >> That's interesting. So, if it detects a slow link the GPO "unapplies", >> >> and the mapped drive stops working? >> >> >> >> I shall take a look at that. >> >> >> >> Kurt >> >> >> >> On Wed, Aug 23, 2017 at 3:57 PM, Joseph L. Casale >> >> <[email protected]> wrote: >> >> > Default behavior of slow link detection? >> >> > >> >> >> -----Original Message----- >> >> >> From: [email protected] >> >> >> [mailto:[email protected]] On Behalf Of Kurt Buff >> >> >> Sent: Wednesday, August 23, 2017 4:47 PM >> >> >> To: ntsysadm <[email protected]> >> >> >> Subject: [NTSysADM] Odd problem with GPO-mapped drives and SSL VPN >> >> >> >> >> >> I've got a user in the field out of our AU office. >> >> >> >> >> >> We have a SonicWall SSL VPN to which he connects. >> >> >> >> >> >> We map a drive for him to the DFS share (\\example.com\au\share) >> via >> >> >> GPO, but it doesn't work well while he's in the field. >> >> >> >> >> >> While in the field, if he opens a command prompt, and does a >> 'gpupdate >> >> >> /force', the drive mapping works for a while, then he says it >> >> >> disconnects after about an hour or so. >> >> >> >> >> >> When he's in the office, it's solid. >> >> >> >> >> >> While in the field, if he maps another drive letter to >> \\machine\share >> >> >> that works either in or out of the office. >> >> >> >> >> >> I've not seen anything in particular in the event logs that seems >> >> >> relevant, but I'm going to look again when he's free. >> >> >> >> >> >> Has anyone seen behavior like this, and can point me in the general >> >> >> direction of an answer? >> >> >> >> >> >> I understand that drive mappings via GPO over a VPN connection are >> >> >> problematic, because the GPO is applied at login, and before VPN >> >> >> connection is made, but the fact that it fails after a 'gpupdate >> >> >> /force' is truly weird. >> >> >> >> >> >> Kurt >> >> >> >> >> > >> >> >> >> >> > >> >> >> >
