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 <kurt.b...@gmail.com> 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\{
> 6ADA2CCE-5829-472C-BC68-1B2CEEEE2E5D}\Machine\registry.pol</Data>
> </EventData>
> </Event>
>
> On Thu, Aug 24, 2017 at 12:22 AM, Micheal Espinola Jr
> <michealespin...@gmail.com> 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 <kurt.b...@gmail.com> 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
> >> <jcas...@activenetwerx.com> wrote:
> >> > Default behavior of slow link detection?
> >> >
> >> >> -----Original Message-----
> >> >> From: listsad...@lists.myitforum.com
> >> >> [mailto:listsad...@lists.myitforum.com] On Behalf Of Kurt Buff
> >> >> Sent: Wednesday, August 23, 2017 4:47 PM
> >> >> To: ntsysadm <NTSysADM@lists.myitforum.com>
> >> >> 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
> >> >>
> >> >
> >>
> >>
> >
>
>
>
