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
<[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
>> >>
>> >
>>
>>
>


Reply via email to