RE: [ActiveDir] Secedit Errors

[Darren Mar-Elia]

Title: Message

Jef- Sorry for the delay. So, just for your info, the 145 is derived from the userenv.h header file within the Platform SDK. If you convert that value to hex, it represents an XOR'd combination of userenv flags, which repesent the stuff I described below.   In terms of identifying possible corruption in the template file, you could have a look in SYSVOL under the following path sysvol\<domain>\Policies\<GPOGUID>\Machine\Microsoft\Windows NT\SecEdit   The gpttmpl.inf file in that folder stores the security settings for the GPO. I'm not sure what you'd look for in that file to find corruption--it could be subtle. However, it is just a text file so you can open it in notepad and peruse to your heart's content. One alternative, if its not too much work, is to simply recreate the security settings in a new GPO and see if that helps.   Darren -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jef Kazimer Sent: Friday, October 03, 2003 5:22 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Secedit Errors Darren,   Ahhh...that is what 145 meant!   I couldn't find a lookup on that one anywhere.  I am seeing these come from maybe 30+ servers in a domain.   I see a mix of error code #5 which was access denied (this was due to a mistake in a policy setting and is fixed) and then I see the 1208 errors which leads me to find the secedit.sdb file is corrupt and needs to be rebuilt.  The "cannot write shadowed header" error would be seen, and an error code of "3" made me think this was the case.    AV virus scan for I/O is set on the C:\winnt\security directory so I think the secedit.sdb file is being held open when GPO is applied and corrupting the DB.  I confirmed with MS that this might be the case, and have informed our security group they need to change this.   Yet even if I exclude that directory manually,  this corruption and secedit/userenv errors keep coming back.   Yes,  after cleaning up group policy I had noticed they were not being applied on the boxes where I get these errors.  After I fix the SDB they apply, but I will see the errors come back.   Looking at the extendedDebugLevel winlogon.log GPO processing dies when the DB is said that it can't be open, and GPO never gets applied unless I fix the DB on that database.   I am wondering if there is a central corruption in the template file somewhere..but I don't know how to "verify" a GPO for integrity.   Thanks!   Jef   ----- Original Message ----- From: Darren Mar-Elia To: [EMAIL PROTECTED] Sent: Thursday, October 02, 2003 1:54 PM Subject: RE: [ActiveDir] Secedit Errors Jef- I don't know if it helps but the flags (145) thing means the following:   Machine Policy is being applied as opposed to user policy This policy is being applied as a background refresh (rather than foreground) No changes were detected to the GPO during this processing cycle (so nothing was applied)   The failure status code is just a Win32 error code, which in this case means, "An extended error has occurred."-- Not very helpful.   Are you seeing other problems in terms of policy application other than these errors?  How often do these errors occur?   Darren -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 02, 2003 10:41 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] Secedit Errors Hello all, I am getting repeated secedit errors which seem to be due to a corrupted secedit.sdb file on the DCs.  After using ESENTUTL to repair the DB,  and group policy applies correctly. A day or so later, those that were repaired now have the same errors.   Anyone have any idea where to halt this cycle?  What am I missing? Source:  Userenv Name:  Unexpected Error applying group policy to machine account Description:  The Group Policy client-side extension Security was passed flags (145) and returned a failure status code of (1208). There were originally some group policy errors, which were fixed.  Policy applies correct as per the winlogon.log after it is fixed,  but the problem returns. any help would be appreciated. Jef Kazimer