Strange! And prolly for the best to just rebuild. -- Espi
On Fri, Aug 25, 2017 at 4:51 PM, Kurt Buff <[email protected]> wrote: > 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-BC >>> 68-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 >>> >> >> >>> >> > >>> >> >>> >> >>> > >>> >>> >>> >> >
