GPP processing woes

1,080 views
Skip to first unread message

Kurt Buff

unread,
Sep 10, 2021, 6:40:33 PM9/10/21
to ntsys...@googlegroups.com
All,

We're on top of opening a new location, and we've got helpdesk guys setting machines in that location. They telling me that our GPOs aren't applying. I've done some troubleshooting with a sysadmin, and we've adjusted the firewall rules, so now the logs of traffic to/from the DCs (all are in the corporate office) are clean. What's worse is that GPOs in error are the same across all of our locations - it's just this new location that's experiencing this problem. There is no security filtering on them - it's just Authenticated Users.

But, several of our GPOs aren't applying, including installing/configuring/enforcig LAPS installation, setting up scheduled tasks, and a few other things.

At the command line the output for 'gpupdate /force' shows one of two messages consistently [1],[2] and in the event logs I'm seeing multiple instances of event id 4098 category Group Policy Files [3]

In [1], the GUID that starts F4437 is for the GPO that configures the workstation LAPS installs (renames the local administrator, etc.), but does not install the package. The second GUID references our Default Domain Policy GPO.

I've looked at articles on MSFT and Spiceworks, and I've taken some PCAPs on one of the machines, and I'm getting fairly frustrated at not finding anything that seems to be relevant or helpful.

We don't have AGPM, but do have a central store.

Any pointers on this would be appreciated.

Thanks,
Kurt

[1]
Updating policy...

Computer policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows attempted to read the file \\example.com\SysVol\example.com\Policies\{F4437443-422F-4CCA-B6CC-240B80C03B88}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.
User Policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows attempted to read the file \\example.com\sysvol\example.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

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.

[2]
Updating policy...

Computer Policy update has completed successfully.

The following warnings were encountered during computer policy processing:

The Group Policy Client Side Extension Software Installation was unable to apply one or more settings because the changes must be processed before system startup or user logon. The system will wait for Group Policy processing to finish completely before the next startup or logon for this user, and this may result in slow startup and boot performance.
User Policy update has completed successfully.

For more detailed information, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

Certain Computer policies are enabled that can only run during startup.

OK to restart? (Y/N)

[3]
Log Name:      Application
Source:        Group Policy Files
Date:          9/10/2021 2:34:21 PM
Event ID:      4098
Task Category: (2)
Level:         Warning
Keywords:      Classic
User:          SYSTEM
Computer:     comp1.example.com
Description:
The computer '2.2.0.2' preference item in the 'Comp-WSUS_ClientScheduledTask {0F632F8D-09FA-451C-9FB0-26374DB9F1ED}' Group Policy Object did not apply because it failed with error code '0x80070041 Network access is denied.' This error was suppressed.

Log Name:      Application
Source:        Group Policy Files
Date:          9/10/2021 2:34:21 PM
Event ID:      4098
Task Category: (2)
Level:         Warning
Keywords:      Classic
User:          SYSTEM
Computer:      comp1.example.com
Description:
The computer 'logging.json' preference item in the 'Comp-Install-WSP {FE2CAF7E-AB17-4EAF-B9BE-F9ADC0B372C5}' Group Policy Object did not apply because it failed with error code '0x80070041 Network access is denied.' This error was suppressed.


Aakash Shah

unread,
Sep 11, 2021, 10:32:17 PM9/11/21
to ntsys...@googlegroups.com

The errors appear to indicate problems accessing the DFS path. Try instead to manually browse to each of the DCs explicitly. If example.com has the DCs dc1.example.com and dc2.example.com, try to connect to \\dc1.example.com\SysVol\example.com\Policies\{F4437443-422F-4CCA-B6CC-240B80C03B88} and the same on dc2 and confirm that in both cases gpt.ini can be opened as both a user as well as the computer account (psexec can help). If any of these fail, this can be troubleshooted further.

 

It may also be worth running the Port Query GUI to test the domain ports too.

 

-Aakash Shah

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce6L6nMjxpZb7fNmr03x-0FKCojxNwFVYwFQdvhcOtMFaA%40mail.gmail.com.

don.l....@gmail.com

unread,
Sep 12, 2021, 1:22:34 AM9/12/21
to ntsys...@googlegroups.com

It sounds a little bit like a Kerberos authentication failure is occurring?

If the firewall/ports are ok (135/445/etc) and if the authorization (permissions) are ok, then authentication failure is likely.

Check for SPNs are ok and KRB tickets are ok, DNS suffix of the clients, etc.

 

DonP

Kurt Buff

unread,
Sep 12, 2021, 12:38:39 PM9/12/21
to ntsys...@googlegroups.com

Kurt Buff

unread,
Sep 12, 2021, 12:40:47 PM9/12/21
to ntsys...@googlegroups.com
A useful line of inquiry - I shall pursue it.

Kurt
> To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2DE81AF9-6D33-4EDE-8BCE-042DF42FA8A7%40hxcore.ol.

Kurt Buff

unread,
Sep 14, 2021, 11:55:16 AM9/14/21
to ntsys...@googlegroups.com
I found the problem with accessing the gpt.ini file to be intermittent. I opened a cmd prompt as system using psexec, and tried 'dir <path>.gpt.ini', and was sometimes able to do so, and sometimes not.

Someone grabbed the machine I was testing against, so haven't been able to use portquery, but I've got pcaps from wireshark.

I went down some other rabbit holes, but could find nothing conclusive.

I've submitted them and event logs from the machine to our vendor, who will probably end up referring this to MSFT. I have other tasks on a tight deadline, so have to set this aside for the moment - I hope to work with MSFT to work through this in a more efficient manner than I've been able to achieve so far.

If I can get this resolved, I will report back, as this is a most interesting/frustrating problem.

Kurt

On Sat, Sep 11, 2021 at 8:32 PM Aakash Shah <aakas...@uci.edu> wrote:

Kurt Buff

unread,
Sep 14, 2021, 12:46:37 PM9/14/21
to ntsys...@googlegroups.com
I checked out the SPNs for the machine in question, and they look god. I've checked that port 88 is being used, and it is.

The only thing I see that's interesting is that these machines were imaged with a name of "it-<servicetag>", then renamed in the new location as they are deployed. I've seen the pre-renamed name in a couple of the KRB packets - but that's in addition to the new name of the machine.

Other than that, it looks OK

Kurt

On Sat, Sep 11, 2021 at 11:22 PM <don.l....@gmail.com> wrote:

Joe Powers

unread,
Sep 14, 2021, 2:24:26 PM9/14/21
to ntsys...@googlegroups.com

Possibly not Generalized properly after Sysprep ??

 

Joe Powers

160 Elmview Avenue, Hamburg, NY 14075   │   USA

Office - 716.312.0088 ext. 135   │   Mobile - 716.698.2831   │   Fax - 716.312.0028

cid:image001.jpg@01D1B0E8.6C6A1D90   cid:image002.jpg@01D1B0E8.6C6A1D90

www.khindustries.com

Kurt Buff

unread,
Sep 14, 2021, 2:42:47 PM9/14/21
to ntsys...@googlegroups.com
Possible. I'm not in the least familiar with the imaging process here, except that they use a KACE box to do it. But the process hasn't changed in a long time, and I haven't seen/noticed this problem in other newly deployed systems..

Kurt

Roberts, James

unread,
Sep 14, 2021, 3:07:26 PM9/14/21
to ntsys...@googlegroups.com

Possibly try deleting the registry.pol files and see if they get recreated after reboot.

 

Sent: Tuesday, September 14, 2021 1:43 PM
To: ntsys...@googlegroups.com
Subject: [EXTERNAL] Re: [ntsysadmin] GPP processing woes

 

This message is from an external sender; be cautious with links and attachments.

Possible. I'm not in the least familiar with the imaging process here, except that they use a KACE box to do it. But the process hasn't changed in a long time, and I haven't seen/noticed this problem in other newly deployed systems..

 

Kurt

 

On Tue, Sep 14, 2021 at 12:24 PM Joe Powers <jppo...@khindustries.com> wrote:

Possibly not Generalized properly after Sysprep ??

 

Joe Powers

160 Elmview Avenue, Hamburg, NY 14075   │   USA

Office - 716.312.0088 ext. 135   │   Mobile - 716.698.2831   │   Fax - 716.312.0028

  

Kurt Buff

unread,
Sep 14, 2021, 3:40:03 PM9/14/21
to ntsys...@googlegroups.com
Tried that a couple of weeks ago.

I'm waiting on a MSFT support rep to contact me - supposedly within a couple of hours.

Kurt

Markus Klocker

unread,
Sep 14, 2021, 4:34:28 PM9/14/21
to ntsys...@googlegroups.com
Did you look at advanced GPO troubleshooting logs?
If no than maybe something good in the link:
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/a-treatise-on-group-policy-troubleshooting-8211-now-with-gpsvc/ba-p/400304

It once helped me to resolve a "permission denied" issue which caused GPOs to fail in a very random way.

    Markus

Kurt Buff

unread,
Sep 14, 2021, 5:34:10 PM9/14/21
to ntsys...@googlegroups.com
I don't think I've run across that article before. Thanks, and I'm configuring and testing with it now.

Kurt

Kurt Buff

unread,
Sep 20, 2021, 7:30:50 PM9/20/21
to ntsys...@googlegroups.com
Update on this:

1) The MSFT rep is definitely first line - I'm going to have to escalate.

2) I think I've narrowed down one problem pretty well. If I reboot one of the machines at the site, then immediately log in, I can raise a CMD prompt as admin, and do a 'gpupdate /force' This immediately generates an error in the System event log stating that the Default Domain GPO gpt.ini is not accessible. and using 'dir' to look at the file fails. In parallel with that, if I use PSExec to start a CMD prompt as System, it says network access denied, and that also generates a 1058 error in the System log. 10-15 minutes thereafter, I have success doing a 'dir' against that file. This is repeatable at will on any of the three machines on which I've tried it, against both the domain UNC and directly against the DCs themselves. This is something I've never seen nor even heard of before now - tres strange..

Kurt

Micheal Espinola

unread,
Sep 20, 2021, 7:58:35 PM9/20/21
to ntsys...@googlegroups.com
Tres strange indeed. Any chance of any 'delayed start' services or 'fast/optimized' login options?

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.


--
Espi

Philip Elder

unread,
Sep 21, 2021, 3:08:44 PM9/21/21
to ntsys...@googlegroups.com

For ghits and siggles:

$cred = Get-Credential

 

# cmdlet Get-Credential at command pipeline position 1

# Supply values for the following parameters:

# Credential

Test-ComputerSecureChannel -Credential $cred -Repair

# True

Test-ComputerSecureChannel

# True

 

Right after you log on to one of the problematic machines.

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

E-mail: Phili...@mpecsinc.ca

Phone: +1 (780) 458-2028

Web: www.mpecsinc.com

Blog: blog.mpecsinc.com

Twitter: Twitter.com/MPECSInc

Skype: MPECSInc.

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

Philip Elder

unread,
Sep 21, 2021, 3:09:30 PM9/21/21
to ntsys...@googlegroups.com

An aysync setting for group policy synchronization would indeed be a consideration.

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

E-mail: Phili...@mpecsinc.ca

Phone: +1 (780) 458-2028

Web: www.mpecsinc.com

Blog: blog.mpecsinc.com

Twitter: Twitter.com/MPECSInc

Skype: MPECSInc.

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

 

Kurt Buff

unread,
Sep 21, 2021, 3:22:33 PM9/21/21
to ntsys...@googlegroups.com
Yep - I got what you got:

 $cred = get-credential


cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential
PS C:\Windows\system32> Test-ComputerSecureChannel -Credential $cred -Repair
True
PS C:\Windows\system32> Test-ComputerSecureChannel
True

Markus Klocker

unread,
Sep 21, 2021, 3:23:08 PM9/21/21
to ntsys...@googlegroups.com

I was thinking secure channel as well but login seem to work which normally results in an error...

I'm more into replication / dfs issue when I read that right. It's always been a pain and maybe will be :)

    Markus

Kurt Buff

unread,
Sep 21, 2021, 3:38:14 PM9/21/21
to ntsys...@googlegroups.com
Not sure where I'd look to find those.

However I do see that the IPHelper service is automatic, but not started. Going along with that I see that the Network Connectivity Assistant service is not started (set to Manual (Trigger Start), and in the accompanying event in the System log there's an error stating that it depends on the IP Helper service (which is set to Automatic, and is not started) which in turn has its own event log entry stating that it depends on the WinHTTP Web Proxy Auto-Discovery service - and this last service does not appear AT ALL in the list of services.

Whiskey Tango Actual Foxtrot, over? I see the WinHTTP Web Proxy Auto-Discovery service in my list, and it's enabled/running.

Kurt

Kurt Buff

unread,
Sep 21, 2021, 3:48:43 PM9/21/21
to ntsys...@googlegroups.com
OK - this might be a red herring.

My machine has the service, ad the machine at our new location doesn't, but I've checked a couple of other machines in locations not experiencing this problem, and they don't seem to have this service listed either. A mystery for another day, AFAICT.

Kurt
Reply all
Reply to author
Forward
0 new messages