Tuesday, August 3, 2010

SceCli Warning: Event 1202 on Windows XP

Here's an error that was found on two of our workstations recently:

Event Type: Warning

Event Source: SceCli
Event Category: None
Event ID: 1202
Computer: COMPUTERNAME


Description:
Security policies were propagated with warning. 0x4b8 : An extended error has occurred.

For best results in resolving this event, log on with a non-administrative account and search http://support.microsoft.com for "Troubleshooting Event 1202's".


The warning was repeated several times a day and it looked like the machine might not be process all our group policies correctly.   A check in the "%windir%\security\logs\winlogon" log file repeatedly showed "Error 1208: An extended error has occurred. Error creating database."

I did a little searching around on the web and suspected that the local security database, secedit.sdb was damaged.  There were a couple of KB articles that danced around what seemed to be going on (KB278316 and KB818464), but either the OS indicated wasn't XP or I wasn't seeing all the errors listed.  But they seemed promising, so I tried one on each workstation.

Option 1 - ESENTUTL /p


Run ESENTUTL to repair the database using the command line below.  Follow with the ever popular "gpupdate /force".

esentutl /p %windir%\security\database\secedit.sdb

Later, I came across a mention in KB884018 that indicated using ESENTUTIL /P on Windows XP could result in tattooing some previous GPO settings in the registry, but that wasn't a big concern for me.  We don't often rely on GPOs to rollback to their previous settings if they are removed, we usually actively change each setting if we want to alter a GPO that was previously set. I not worried that I did anything that will affect our future policies, however if you are skeptical, use the next option instead.
Option 2 - Rebuild the Security Database

  1. Open the %SystemRoot%\Security folder, create a new folder, and then name it "OldSecurity".
  2. Move all of the files ending in .log from the %SystemRoot%\Security folder to the OldSecurity folder. (You may need to use SAFE MODE to copy all of these, however I just skipped the ones that I couldn't copy.)
  3. Find the Secedit.sdb file in the %SystemRoot%\Security\Database folder, and then rename this file to "Secedit.old".
  4. Click Start, click Run, type mmc, and then click OK.
  5. Click Console, click Add/Remove Snap-in, and then add the Security and Configuration snap-in.
  6. Right-click Security and Configuration and Analysis, and then click Open Database.
  7. Browse to the %TEMP% folder, type Secedit.sdb in the File name box, and then click Open.
  8. When you are prompted to import a template, click Setup Security.inf, and then click Open.
  9. Copy %TEMP%\Secedit.sdb to %SystemRoot%\Security\Database.
  10. Reboot.
This was a longer process that the first option, but seemed to be just as effective. As I mention in the steps, I didn't bother with using safe mode to ensure I could copy or rename all the files.  There seemed to be no ill effects with doing that, at least not in the short term.


Finally, I added a rule to System Center Essentials 2010 to watch for this error message on workstations in the future. I'd like to know sooner than later if some of the workstations in our organization are having issues processing GPOs.  We aren't sure exactly why those two machines had issues, though they have had viruses removed from them in the past.  Perhaps trashing parts of the local security database was a result of some malware action.

9 comments:

  1. I appreciate you taking the time in posting this, though i cant change or muck with our policy on my domain its good to know... thank you

    ReplyDelete
  2. Glad you enjoyed it. Thanks for reading!

    ReplyDelete
  3. Excellent - This solution is just what I needed - Have about 11 machines with this issue all in the same OU - Made the local changes to a few for test and it works*

    "Only gonna know if it works if u try - "

    ReplyDelete
  4. Awesome! I have been digging into this error for days. The fix worked. Sadly our master image has this error so we have to try and deploy a global fix.

    I can add the ESENTUTL /p to the login script but a warning window appears. I thought about running it using psexec, but it get's hung up in the process.

    I haven't figured out a way to do this silently and esentutl doesn't have a quiet option.

    ReplyDelete
    Replies
    1. Has anybody figured out how to do this silently? I have 319 terminals that I need to run this on in the background.

      Delete
  5. Found it. If you use the help and look at the /P option it says to use /0 to suppress the logo. I just tested it on my PC and it worked.

    ReplyDelete
    Replies
    1. Nice. Hopefully others can use that to their advantage.

      Delete
  6. Very helpful. Thanks very much!

    ReplyDelete

MS ITPro Evangelists Blogs

More Great Blogs