I have configured several avanced audit policy settings under:

Computer Configuration => Policies => Windows Settings => Security Settings => 
Advanced Audit policy Configuration => Audit Policies => ...

Also the following setting is set to "Enabled":

Computer Configuration => Policies => Windows Settings => Security Settings =>
Local Policies => Security Options => Audit: Force audit policy subcategory settings
(Windows Vista or later) to override audit policy category settings.

However none of the advanced audit settings is getting applied. Running

auditpol /get /category:* 

shows all options set to "No Auditing". Also there are none of the deprecated audit policies set.

What surprises me, is that neither gpresult nor rsop.msc show up the "Advanced audit policy" category. What am I doing wrong here? I am running out of ideas. Thanks in advance for your input!

[1. Addendum]

  1. Other settings configured in the same group-policy object are getting applied. So the common pitfalls can be ruled out.

  2. The originally GPO contains MSS settings

  3. Creating a new, empty GPO and only setting the advanced audit configuration items, make them appear on the target server (checked with auditpol). So there must be something wrong with the GPO itself.

[2. Addendum]

  1. Comparing both {GUID}\Machine\Microsoft\Windows NT\Audit\Audit.csv files with each other reveals the following difference. Note the double occurence of "audit".

Non working version of audit.csv:

,System,Audit Policy Change,{0CCE922F-69AE-11D9-BED3-505054503030},Success and Failure,,3

Working version of audit.csv:

,System,Audit Audit Policy Change,{0cce922f-69ae-11d9-bed3-505054503030},Success and Failure,,3

Whats going on here? Any compelling reasons to not edit this file manually?

  • Just to get the typical pitfall out of the way: Have you linked the GPO to an OU containing the server, and verified that the GPO itself is getting applied to the machine ? Aug 4 '14 at 9:18
  • Yes, I should have added that information. Other settings configured in the same GPO are getting applied. So that pitfall is out of the way. Aug 4 '14 at 9:26
  • Known issue: when viewing audit policy settings with auditpol, the local security policy (secpol.msc) may not show results when deploying Advanced Auditing via GPO.
    – Lee
    Dec 29 '17 at 16:47
  • 1
    "Audit Policy Change" is the actual name of the setting. So the second "Audit" is part of the setting name, and therefore not an error.
    – Aura
    May 29 '19 at 20:54

I realize this is an older question, and that you resolved the issue a different way, however, the reason it wasn't working originally was due to "Audit: Force audit policy subcategory settings" being enabled. As explained in this article on Technet:

The lack of Object Access auditing is expected: as soon as you start applying Advanced Audit Configuration Policy, legacy policies will be completely ignored. The only way to get a Win7/R2 computer to start using legacy policy is to set the security policy “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” to DISABLED. That disables the use of the newer policy type. Then you must clear the existing advanced policy from the machines (auditpol.pol /clear, having a blank audit.csv file, etc). The system isn't optimal, but the intention was never for you to go back.


I solved it by the following procedure:

  • Set every advanced audit configuration item to "Not configured"
  • Run gpupdate /force on the relevant systems
  • Re-set all advanced audit configuration according to your requirements

I have created the failing GPO from a template which already had set the advanced audit settings. I guess there was an internal mismatch of the GUIDs...


Old post but I just had and worked through the same problem and did not have success with the accepted solution.

@matze got me thinking about the backend of the Audit Policy process. I found the following article which laid out the process in wonderful detail (I highly recommend the read): https://blogs.technet.microsoft.com/askds/2011/03/11/getting-the-effective-audit-policy-in-windows-7-and-2008-r2/

In review, I found that the %systemroot%\system32\grouppolicy\machine\microsoft\windows nt\audit\audit.csv file was updating correctly but the %systemroot%\security\audit\audit.csv file had a timestamp from years ago.

In looking at the properties, c:\windows\security\audit\audit.csv was set to Read-Only which apparently was preventing the OS from updating the file.

To resolve I did the following:

  1. I removed the 'read only' attribute
  2. Used GPEdit to export the Advanced Audit Policy settings and manually set everything to not configured.
  3. Used Auditpol /backup /file:<file> to make a backup of the Auditpol
  4. Used auditpol /clear to clear the Auditpol
  5. Gpupdate /force
  6. auditpol /get /category:* to ensure everything was cleared
  7. Re-imported the Advanced Audit Policy settings into GPEdit
  8. Gpupdate /force
  9. auditpol /get /category:* to ensure everything was set correctly again

To confirm the fix, I made a change to a setting in GPEDIT, gpupdate again, auditpol /get again. The change showed up correctly.


I just ran into the same problem. It turned out to be an order-of-operations issue. I set all of the advanced log settings and then set Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings to Enabled. While other settings clearly applied to the affected test system, the logging settings did not. They didn't appear in the Settings summary although they appeared in the actual editor.

I was puzzled about this until I worked through the process and the XML file (which was nearly empty). Settings are added to the file as they are made unless something else overrides the setting, like a master setting that is required to enable them. If that master setting is in another part of the GPO, the write-on-change process may not see the entire policy.

Solution: Go back to the advanced settings, disable one setting and click OK, then go back and re-enable it. The entirety of the logging settings will then appear. Close the editor. The GPO will go to affected systems on the next refresh, and will take effect the next reboot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.