So the Auditor.exe process is kicked off via a scheduled task based upon specific Group Policy event IDs. An example task can be seen below.
Since it can be a little hard to read, here’s what event IDs will trigger the running of the Auditor:
Events 8000 - 8007 are SUCCESS events when Group Policy succeeds. Events 7000 - 7007 are FAIL events when Group Policy fails to process. The SUCCESS IDs translate to the following:
When clients OSs update: Note that on Windows 8.1 and later you will typically not find event IDs 8004 and 8005.. even when the computer is left to perform background policy processing. This is because the Group Policy Service comes into memory every 90 minutes or so, then creates a scheduled task to perform a GPupdate. Therefore, When server OSs update: On Servers you will see event IDs 8006 and 8007 because they are considered “Always on, Always connected.” You can change the CLIENT OS behavior back to the Windows 7 behavior with the following policy setting “Turn off Group Policy Client Service AOAC optimization.”
So, after the Auditor.exe is run because of an event ID, it sends (or doesn’t send) information back to the server based upon its defaults -or- what’s set in the PPGPCR ADMX settings.
Here are defaults for PPGPCR Auditor:
If you turn on enhanced PPGPCR Auditor logging (as explained in this article) you can illuminate: