Spat's WebLog (Steve Patrick)

When things go wrong...

Audit policy not registering audits

Audit policy not registering audits

  • Comments 20


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



Leave a Comment
  • Please add 2 and 8 and type the answer here:
  • Post
  • 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:\Windows\security\Audit\audit.csv &

    C:\Windows\System32\GroupPolicy\machine\microsoft\Windows NT\audit\audit.csv

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

  • I had a similar issue wherein i renamed the audit.csv under C:\windows\security\audit\audit.csv to audit.csv.old

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

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

  • Thanks. This post just solved my problem too

  • thx mate! it helped us too. a lot :)

  • 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.

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

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


  • Great info!  My problematic blank CSV was at c:\windows\system32\GroupPolicy\Machine\Microsoft\WindowsNT\Audit\audit.csv

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

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

  • Thanks a solved my problem..!

  • 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?

  • I had the same issue and this solved it.  However, I now see under Applications and Services Logs\Microsoft\Windows\Security-Audit-Configuration-Client the following event every 5 minutes:

    Event 107

    Failed to downloaded the audit settings file as follows.

    Remote File: \\\sysvol\\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\Microsoft\Windows NT\Audit\audit.csv

    Local File: C:\Windows\security\audit\audit.csv

    GPO Name: Default Domain Policy

    Error: 0x2

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

  • 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.

  • Thanks Spat!

    My problems started after enabling the Advanced Auditing Settings needed to track OU changes in AD as outlined here:

    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!


Page 1 of 2 (20 items) 12