Microsoft-Windows-GroupPolicy event 1502 not being logged after successful application of GPOs

  • Article

Recently I encountered a customer who had several Windows 7 clients which initially had the symptom of the group "Offer Remote Assistance Helpers" not being present, but the underlying cause turned out to be something entirely unrelated at first.

The group in question is actually created by an event-triggered task, visible in Task Scheduler here:
Microsoft > Windows > RemoteAssistance > RemoteAssistanceTask

Viewing the Triggers tab for this task, it is fired by the following:
Log: System, Source: Microsoft-Windows-GroupPolicy, Event ID: 1502

Manually launching the task made the group appear immediately, so we knew at this point that the problem lay with the event trigger.

 

Checking the System event log, there were 0 events matching the given source & ID, yet running GPRESULT /Z made it clear that the policies were applying successfully.

GPUDPATE /FORCE refreshed the policies correctly, but also failed to get the 1502 event logged.

So the first thing we did was to enable gpsvc debug logging, by setting the following registry value:
Path: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
Name: GpSvcDebugLevel
Type: REG_DWORD
Data: 0x30002

The debug logging is written to the following location:
%windir%\debug\usermode\gpsvc.log

 

After refreshing the policies we saw the following being recorded in gpsvc.log:
GPSVC(xxx.yyy) hh:mm:ss:sss Could not publish event id=1502 as it is disabled

This is logged because the Group Policy service makes a call to EtwEventEnabled and receives FALSE in response.

 

I stepped through the code for EtwEventEnabled, and there are 3 checks made, and if any of them fail then FALSE is returned.

The first check is that the ETW event is not marked as "disabled" through a dedicated flag (this was okay).

The second check is that the level of the event to log is not outside of the threshold for the provider (this was also okay).

The third check is the the Keyword matches the bitmask for event types to log - it turns out the REGHANDLE passed to this function referred to the ETW provider with bad types for MatchAllKeyword and MatchAnyKeyword values.

 

From the EtwEnableCallback routine page on MSDN:

MatchAnyKeyword [in]

The bitmask of keywords that the provider uses to determine the category of events that it writes.

This value is passed in the MatchAnyKeyword parameter of the EnableTraceEx function or the EnableFlag parameter of the EnableTrace function. MatchAnyKeyword is a 64-bit value and is basically an extended version of the 32-bit EnableFlag.

 

MatchAllKeyword [in]

This bitmask additionally restricts the category of events that the provider writes.

This value is passed in the MatchAllKeywords parameter of the EnableTraceEx function.

 

When we looked at these filter values for the EventLog-System provider on the broken clients, they were present and at a glance contained good data, but they were created as REG_SZ (string) values rather than the expected REG_QWORD (64-bit number, as the clients were x64).

The path to the key holding the values is:
HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-System\{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}

 

After replacing the REG_SZ values with the correct type, the clients started recording event ID 1502 when refreshing group policy.

 

References:
Userenvlog for Windows Vista/2008/7
EtwEventEnabled function
EtwEnableCallback routine
How To User the Registry API to Save and Retrieve Setting
RegQueryValueEx function
Registry Value Types