RE: [ActiveDir] Audit Policies are not applying in windows 2000

[Schmieder, Marc]

Darren,   Thank you very much for the suggestions.  Unfortunately everything checked out with the DB integrity and deleting the files in the policies folder didn’t seem to get the policies to apply correctly, although the files came back.  What is interesting is the gpt00002.ini file and the tmpgptfl.ini files both have the correct audit settings as shown below, but the MMC still doesn’t show the correct settings and the server is still auditing the wrong things.  I would appreciate any other suggestions you might have.    [Event Audit] AuditSystemEvents = 3 AuditLogonEvents = 0 AuditObjectAccess = 0 AuditPrivilegeUse = 0 AuditPolicyChange = 0 AuditAccountManage = 3 AuditProcessTracking = 0 AuditDSAccess = 0 AuditAccountLogon = 3 [Registry Values]             From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Wednesday, April 06, 2005 11:33 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Audit Policies are not applying in windows 2000   You could have a corrupt local secedit.sdb database on these machines, which would prevent the policy from being applied correctly. This file is typically stored on c:\windows\security\database. You can run the following command on one of these machines to check its integrity.   esentutl /g c:\windows\security\database\secedit.sdb   If it finds errors, that utility has a command line repair option that you can try.   If that doesn't show errors, another thing you can try is to delete the cached copies of the policy files from the local machines and then force a GP refresh. Those files are stored under c:\windows\security\templates\policies   Darren     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schmieder, Marc Sent: Wednesday, April 06, 2005 11:13 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Audit Policies are not applying in windows 2000 We have many servers that are not getting the correct auditing policies applied, although all other policy settings are working correctly.  I’ve already checked for Blocked Inheritance, enabled UserEnv.log and I cannot find anything that indicates any problems.  When I change the audit policies on the Domain, these problematic servers don’t seem to see the change when they do a policy refresh.  It doesn’t seem to matter what OU the servers are in either.  Some machine work in the same OU as another machine that doesn’t.  Another thing is that the userenv.log entries for the security extension seem to change.  They are listed below from earliest to oldest.  Does anyone know why this would occur, or how to fix it?        USERENV(d0.358) 09:56:30:107 ProcessGPOs: Processing extension Security USERENV(d0.358) 09:56:30:107 CompareGPOLists:  The lists are the same. USERENV(d0.358) 09:56:30:107 CheckGPOs: No GPO changes and no security group membership change and extension Security has NoGPOChanges set.   USERENV(d0.350) 10:00:00:515 ProcessGPOs: Processing extension Security USERENV(d0.350) 10:00:00:515 CompareGPOLists:  The lists are the same. USERENV(d0.350) 10:00:00:515 CheckGPOs: No GPO changes but extension Security's MaxNoGPOListChangesInterval has been exceeded.   USERENV(d0.350) 10:00:00:515 ProcessGPOs: Processing extension Security USERENV(b7c.bb8) 10:20:51:039 ProcessGPOs: Extension Security skipped with flags 0x6.     Thank you,   Marc Schmieder