JA EN
shiichan

Group Policy troubleshooting gets easier: six enhancements from 2026.02

JP Windows Support ★★★★ View Markdown
#microsoft#infrastructure#security

Hi, it's Shii-chan!

JP Windows Support jpwinsup.github.io

Have you ever been stuck on a Group Policy issue with no idea what caused it? There are some enhancements that help in exactly those moments, so let me walk you through them!

What was announced?

The JP Windows Support blog (from the Windows Commercial Support Directory Services team) introduced six Group Policy enhancements released in February 2026. All of them help with troubleshooting.

Here are the targets and when they are enabled by default.

  • Windows 11 24H2 / 25H2: the update released on February 24, 2026
  • Windows Server 2022 / 2025: the update released on June 9, 2026

The story so far

Until now, logs had no date, error messages like "The data is invalid." and "Access is denied." made causes hard to narrow down, and manual refreshes were recorded without telling you who ran them. These enhancements fill in those missing pieces.

What changes

The six enhancements are:

  • Richer GPSVC log timestamps: they used to show time only, and now include the date
  • registry.pol corruption detection (Event ID 1096): error messages are more specific
  • More detailed GPP error information (Event ID 4117): failure reasons are easier to understand
  • Attribution of refresh processing (Event ID 5321): you can see who or which process triggered a refresh
  • GPP debug logging: can now be enabled from local GPO on client OSes too
  • Critical Section lock detection: you can identify apps that keep holding the lock

For admins, this makes hunting down hard-to-reproduce problems much easier!

Dive Deep

registry.pol corruption detection (Event ID 1096)

The target file is C:\WINDOWS\System32\GroupPolicy\Machine\registry.pol.

  • Corruption: the old "The data is invalid." changed to "Error during registry file parsing: Invalid file signature" (ErrorCode 13)
  • SYSTEM account lacks permission: the old "Access is denied." changed to "Error during registry file parsing: CreateFile failed with 5" (ErrorCode 5)

GPP error details (Event ID 4117)

The existing Event ID 4098 lets you check the item name and error code, but finding the cause sometimes needed extra logging. The new Event ID 4117 (source: Group Policy Files, log: Application) records details that help with the investigation. In the article's example, it shows why a copy failed because the source file was missing, including the source and destination paths (error 0x80070002).

Attribution of refresh processing (Event ID 5321)

Previously, a manual refresh only logged Event ID 4004 (Microsoft-Windows-GroupPolicy/Operational). Now Event ID 5321 is logged to the same log, and the GPSVC log shows "GP Refresh Attribution" with the parent process, PID, account, and more.

Here is what gets recorded for each path.

  • Manual gpupdate: parent process (such as cmd.exe), target (User / Machine), and more
  • Periodic automatic refresh: svchost.exe [Schedule], NETWORK SERVICE, and more
  • Via API (RefreshPolicy / RefreshPolicyEx): the fact it came over RPC and the calling client
  • Via Task Scheduler (including GPMC remote refresh and Invoke-GPUpdate): check together with Task Scheduler Event ID 129 (Microsoft-Windows-TaskScheduler/Operational)
  • Audit policy changes in secpol.msc: mmc.exe [SECPOL.MSC] is recorded as the RPC client

Enabling GPP debug logging

On client OSes, the Local Group Policy Editor used to have no setting for GPP debug logging. After the update, you can set it in gpedit.msc under Computer Configuration > Administrative Templates > System > Group Policy, in "Logging and tracing". You can also set it locally using ADMX. It requires the update released on February 24, 2026 (preview) or later.

Critical Section lock detection

You can now investigate cases where an external application keeps holding the Group Policy lock, using the GPSVC log. The flow looks like this.

  • gpupdate /force starts
  • The writer waits for the lock ("Writer has to wait for lock"; the external reader timeout is changed to 10 minutes)
  • Error 0x5b4 (ERROR_TIMEOUT, 1460) is returned to gpupdate.exe
  • After the timeout, the lock is forcibly released, and the PID and executable path of the holding process are logged (powershell.exe in the article's example)
  • Registry extension and security extension processing completes

How to collect the GPSVC log

From an elevated command prompt, start and stop like this.

reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v "GPSvcDebugLevel" /t REG_DWORD /d 0x30002

reg delete "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v "GPSvcDebugLevel" /f

The output goes to %windir%\debug\usermode\gpsvc.log. Create the usermode folder if it doesn't exist.

Wrap-up

  • Log timestamps now include the date, so timelines are easier to follow
  • registry.pol corruption and permission problems can be told apart by their error messages
  • Event ID 4117 explains GPP failures and Event ID 5321 shows who triggered a refresh
  • GPP debug logging can be enabled from local GPO on client OSes
  • GPSVC logs can identify the process holding the lock

This is for admins running Active Directory and Group Policy who are fighting unexplained apply errors!

Related posts