Audit policy not registering audits


So there was an interesting case which floated my way the other day.

The Audit policies in the domain controllers policy was set to the following, and there were no other policies blocking or changing these.



After a policy update the following events were logged:

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          5/23/2011 7:58:56 PM

Event ID:      4719

Task Category: Audit Policy Change

Level:         Information

Keywords:      Audit Success

User:          N/A



System audit policy was changed.



                Security ID:                         SYSTEM

                Account Name:                 DomainControllerName$

                Account Domain:                             DomainName

                Logon ID:                             0x3e7


Audit Policy Change:

                Category:                            DS Access

                Subcategory:                     Directory Service Changes

                Subcategory GUID:         {0cce923c-69ae-11d9-bed3-505054503030}

                Changes:                             Success removed


In addition, auditpol /get /category:* simply would show no auditing after policy update:



So,  where was this crazy thing being overwritten? It wasn’t in the policies, since we checked all of them carefully for inheritance etc..

Looking at where a client actually stores audit policy may give us a clue (C:\Windows\system32\grouppolicy\machine\microsoft\windows nt\audit\audit.csv  and C:\Windows\security)

But there was nothing there of interest.  So, the last place to look was the sysvol data:

M:\SYSVOL\domain\Policies\{CEF3323C-FD89-4C03-9410-18F7A4922E5A}\Machine\microsoft\windows nt\Audit

Aha! Under here was the .CSV file with the headings  - but no configuration data in it!


We removed this file and now audit policies flowed properly to the DCs and audit event were generated.

Odd. It turns out that they had applied the policies via a GPOBackup and perhaps something had occurred prior to the backup.

Anyway – hope it helps someone someday



Comments (27)
  1. dcw says:

    Thanks Spat, your blog just helped me solve a frustrating problem with a stand-alone Windows 7 system. I would set local audit policy the way I wanted and check that events were being properly logged. But after a computer restart, my audit settings were replaced with no audits!!!   Based on your blog, I deleted the two files:

    C:WindowssecurityAuditaudit.csv &

    C:WindowsSystem32GroupPolicymachinemicrosoftWindows NTauditaudit.csv

    These files had no configuration data – just the headings. Now my local audit settings are preserved – even after computer restart. Thank you!

  2. vimals says:

    I had a similar issue wherein i renamed the audit.csv under C:windowssecurityauditaudit.csv to audit.csv.old

    and ran auditpol /clear and gpupdate /force. After that the issue got resolved.

  3. Hampton Mills says:

    SPAT!  Hope you are well, old friend.  This blog post just solved my problem.

  4. Pavel Egorov says:

    Thanks. This post just solved my problem too

  5. vermin says:

    thx mate! it helped us too. a lot 🙂

  6. gmj says:

    Thank you!  This solved my problem!  I still don't know how that audit.csv file appeared on my server in both folders, but it was there.  I compared it to another Windows 2008 R2 server which did not have this issue, and the CSV files did no exist.

  7. pocoloco says:

    thanks!  renaming the audit.csv file started the audit working.

  8. behrooz says:

    You are awesome, It resolved where I was stock!!!!


  9. Thankful says:

    Great info!  My problematic blank CSV was at c:windowssystem32GroupPolicyMachineMicrosoftWindowsNTAuditaudit.csv

    Renamed to .OLD and now our policies are sticking properly.  Thanks for the info

  10. Admin says:

    Superb… Thanks a lot… finally solved a mystery I've been fighting with

  11. Napster says:

    Thanks a lot….it solved my problem..!

  12. Eric says:

    Hmm. mine is populated correctly in sysvol,  windows/security. I dont have a system32/grouppolicy folder though.  I am on a Windows 2008 R2 DC.

    I run a weekly report of failed logons for a control we have in place.

    It stopped working.

    Frustrating. i had high hopes after reading this.  I guess i have a different issue?

  13. newkansan says:

    I had the same issue and this solved it.  However, I now see under Applications and Services LogsMicrosoftWindowsSecurity-Audit-Configuration-Client the following event every 5 minutes:

    Event 107

    Failed to downloaded the audit settings file as follows.

    Remote File: \domain.netsysvoldomain.netPolicies{31B2F340-016D-11D2-945F-00C04FB984F9}MachineMicrosoftWindows NTAuditaudit.csv

    Local File: C:Windowssecurityauditaudit.csv

    GPO Name: Default Domain Policy

    Error: 0x2

    The Remote File path points to the audit.csv file I removed from that path.

  14. oweindl says:

    i want to add a note here: just deleting a Audit.csv might not always solve the issue or cause different issues.

    i have had the Situation where a setup used several policies and merged settings in Audit.csv for a resultant set.

    there was one policy in the chain which still had the Audit CSE enabled but the Audit.csv was missing.

    In this Case the Audit Settings have not been applied on the Client and we needed to remove the Audit CSE GUID from the affected policy.

  15. Ben says:

    Thanks Spat!

    My problems started after enabling the Advanced Auditing Settings needed to track OU changes in AD as outlined here:…/organizational-unit-rename

    The new settings seemed to break my existing Audit Settings for the more basic things like user logons, account creations/modifications etc. in AD.

    Simply removing the new Advanced Auditing Settings configured above did not fix my problem. Removing the .CSV file did the trick, and my Auditing is back to normal!

    You are awesome!


  16. TechGuruGal says:

    Had same problem when enabling the Advanced Audit configurations, this article just solved my issue!  Thank you!

  17. Ryan Chau says:

    Old Posted but it solved my problem too.  Thanks Spat.

  18. santity says:

    Thank you very much for the explanation!!

  19. talishka vonzua says:

    Thank you very much, it worked like a charm!

  20. Dinesh Jadhav says:


    We have done the given steps and its resolved.


    Dinesh jadhav

  21. Hoo See Soon says:

    This really solved my issue. I really thank you from the bottom of my heart.

    I just want to add on that either you have all sub-categories or all main categories. You cannot mix. It seems like a audit.csv file is produced when the sub-categories are set.

    If you want the main categories back, you need to follow the steps in this post. I.e. search all the audit.csv, rename them to .old and do a gpupdate /force to get back the main categories.

  22. anon says:

    government department of 4,000 staff saved by your blog post. thanks.

  23. Pete says:

    5 years after the post and you’re still helping folks out. Thank you for detailing the process so well!

    1. Spat-MSFT says:

      thanks Pete! Nice to see these posts are still helping – I really should find the time to post more but I changed roles at MS and work on the O365 services and not as many applicable\public items to be posted

  24. Rich says:

    Thank you thank you…I’ve been banging my head on a wall for a while on this one. Very obscure.

  25. H3nnin9 says:

    same issue here …. thx!!!

  26. Joey says:

    Thank you so much. Been pulling my hair out as to why one of our domain controllers (W2016) wasn’t performing it’s basic auditing. While the others (older OSes) didn’t have an issue. Turns out four months we experimented with sub category logging. Even know we removed every subcategory audit, the mere presence of the the audit.csv with only it’s csv headers in sysvol and in c:\windows\security\audit\ was the source of the problem.

    Good troubleshooting and explanation Spat.

Comments are closed.

Skip to main content