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
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
- Open the %SystemRoot%\Security folder, create a new folder, and then name it “OldSecurity”.
- 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.)
- Find the Secedit.sdb file in the %SystemRoot%\Security\Database folder, and then rename this file to “Secedit.old”.
- Click Start, click Run, type mmc, and then click OK.
- Click Console, click Add/Remove Snap-in, and then add the Security and Configuration snap-in.
- Right-click Security and Configuration and Analysis, and then click Open Database.
- Browse to the %TEMP% folder, type Secedit.sdb in the File name box, and then click Open.
- When you are prompted to import a template, click Setup Security.inf, and then click Open.
- Copy %TEMP%\Secedit.sdb to %SystemRoot%\Security\Database.
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.