Audit batch file

I have created a batch file. This batch file contains several DOS command to enable audit policy. For example, it contains:  Auditpol /set /subcategory:"Logon" /success:enable /failure:enable
                                         Auditpol /set /subcategory:"Logoff" /success:enable /failure:disable

When I ran the batch file, it said : the command was successfully executed. Though when I did gpedit and checked the setting, it seem the setting did not change.

Anyone knows the reason why it said successful but the settings still did not change?
Who is Participating?
mark1208Connect With a Mentor Commented:
Hi dongocdung,

I wanted to follow-up and simplify things a bit. To get the Advanced Audit Policy configuration to match across both Auditpol.exe and the GUI snap-ins (secpol, gpedit, etc.), do the following:

1) Use gpedit.msc or secpol.msc to set the "Force ... subcategory settings" policy to Enabled. This will ensure that the newer subcategory settings take precedence over any legacy category settings within Group Policy.
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings = Enabled

2) Use gpedit.msc or secpol.msc to configure Advanced Audit Policy settings as desired.

3) Audit policy settings are immediately effective and should now match what Auditpol.exe shows from the command line (i.e. auditpol /get /category:"Logon/Logoff")
NOTE: The instructions above assume you are testing implementation from a single client  workstation using Windows 7 or Vista. If configuring from a domain  controller or as part of the default domain policy, use GPMC instead.

Hope this helps!

can you start rsop.msc and check it the settings are enabled?
RSOP is the Result Set of Policies which should show you the current configured policies
dongocdung, thanks for the intriguing question! Gave me a chance to dig a little further on new Vista/Win7 client behavior regarding these policies.

Based on the Advanced Security Auditing FAQ in TechNet:
"Editing and applying the advanced audit policy settings in Local  Security Policy modifies the local Group Policy object (GPO), so changes  made here may not be exactly reflected in Auditpol.exe if there are  policies from other domain GPOs or logon scripts."

In the case of my client workstation (Win7 joined to a WS2008 AD domain), the reverse is also appears to be true. The advanced subcategory settings shown in Auditpol.exe are actually active even though RSoP and the Local Security Policy GUI show "Not configured."

Attached are screenshots of my sample configuration. Notice the inconsistent state between what Auditpol.exe shows at the command line compared to the settings of "Not Configured" within the Local Security Policy and RSoP snap-ins. This seems to mirror the same behavior you are running into.


1) Per kb921468, review the policy "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" (Local Security Policy > Security Settings > Local Policies > Security Options). This new setting specifically determines if Vista/Win7 clients use the traditional GPO/category level or the newer audit policy/subcategory level.

Windows Vista and later versions of Windows allow audit policy to be managed in a more precise way using audit policy subcategories.  Setting audit policy at the category level will override the new subcategory audit policy feature.  Group Policy only allows audit policy to be set at the category level, and existing group policy may override the subcategory settings of new machines as they are joined to the domain or upgraded to Windows Vista or later versions.  To allow audit policy to be managed using subcategories without requiring a change to Group Policy, there is a new registry value in Windows Vista and later versions, SCENoApplyLegacyAuditPolicy, which prevents the application of category-level audit policy from Group Policy and from the Local Security Policy administrative tool.

If the category level audit policy set here is not consistent with the events that are currently being generated, the cause might be that this registry key is set.

Default: Enabled

2) kb921468 also mentions a registry key override: (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\SCENoApplyLegacyAuditPolicy). Check for this one as well!

Apologies for the lengthy response, though hopefully this addresses the "Why" part of your question!

Other than that, even Microsoft's own step-by-step guide recommends using auditpol.exe /get /category:* as a way to verify advanced audit policy settings (or reveal inconsistencies, as we're both seeing!). I would also cross-reference the Security log in Event Viewer to make sure that the desired audit events are showing up. In my case, appropriate Event IDs are present where "Success" and "Failure" are configured in Auditpol.exe.

Whew ... hopefully this helps!  :)

Hi dongocdung, did the instructions above resolve your issue? Please follow-up so us experts  can research further or  attempt a different troubleshooting approach.   :)

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.