Secedit.sdb corruption with sysprep?

[Guest]

We are currently developing a single image that we will use to deploy to our
Dell workstations and notebooks.

Here is what is happening:

1. Load XPSP2 from a slipstreamed XPSP2 CD
2. Run Sysprep -mini -reseal (using the SP2 version of sysprep)
3. Take image of workstation using Altiris.
4. Deploy the image to a workstation
5. In all cases, the mini-setup runs without errors and all drivers get
installed.
6. Manually add the workstation to the domain.
7. Move the workstation object into workstation OU
8. GPOs apply to most of the computers with the exception of GX280, D810,
D610 models. On these particular models, the secedit.sdb seems to be
corrupt. If I run "esentutl /g secedit.sdb", the database says it is "not up
to date". If i run "esentutl /m secedit.sdb" the database state shows a
"Dirty Shutdown"
9. When I run "esentutl /p secedit.sdb" then a gpudate, everything seems to
be fine.

The image works fine on just about every other piece of hardware that we
have. Only the newest systems seem to be experiencing the problem.

Anyone have an idea as to why the secedit.sdb is getting corrupted?

 

[Ray.Bowler]

What method are you using to deploy this image to the workstation?

 

[Guest]

Hello.

I have EXACTLY the same problem but with different hardware (HP/Compaq
laptops/desktops) and using different cloning software (Symantec Ghost 8.0
Corporate).

Yes there is a bug in XP with Service Pack 2 - it seems to corrupt the
secedit.sdb file (local security database). And yes this seems to happen most
often when a master XP machine has been imaged and then syspprepped/cloned to
another machine.

Look at Microsoft KB article 884018 here:
http://support.microsoft.com/?id=884018

For new installations you can obtain the hotfix from Microsoft and integrate
it into your distribution share containing your XP with SP2 i386 source files.

For existing XP SP2 machines already deployed it looks like you need to
rebuild the secedit.sdb file. Please note that using the "/p" option is not
recommended. Better to rebuild the file as per the article.

I have logged a support call with Microsoft and am currently testing the
hotfix. I have had a suggestion from the support guy that you may be able to
simply rename secedit.sdb, reboot, and logon to the domain. The domain group
policy should then get applied to the XP machine and automatically rebuild
secedit.sdb. Need to try this though...

 

[ian.short]

Hi MilkyMagic,

We have just started experiencing this same problem. How did you get on
with the hotfix? Did renaming secedit.sdb work? If so which secedit.sdb
(C:\Windows\Security or C:\Windows\Security\Database)?

Thanks,

Ian

 

[Guest]

The hotfix seems to have resolved the problem.

As for fixing existing XP machines, this worked for me:

1. Reboot the machine into Safe Mode (F8)
2. Logon with the local administrator account.
3. Click YES to use Safe Mode.
4. Locate C:\Windows\Security folder in Explorer.
5. Create a new folder within this directory called OldSecurity
5. MOVE all *.log files from the C:\Windows\Security folder to
C:\Windows\Security\OldSecurity folder (do NOT move any log files out of the
LOGS directory!)
6. Locate C:\Windows\Security\Database folder in Explorer.
7. Rename the file SECEDIT.SDB to SECEDIT.SDB.OLD
8. Reboot into normal Windows.
9. Logon with a domain user account.
10. Once logged in, go to the C:\Windows\Security\Database folder in Explorer.
11. Check that a new SECEDIT.SDB file has been created (from the AD domain).
12. Logoff.
13. Logon as an administrative account and you will now be able to add the
required Windows component(s).

Bingo!

 

[Mandalorian]

OK. Thanks for your help.

Ian

The hotfix seems to have resolved the problem.

As for fixing existing XP machines, this worked for me:

1. Reboot the machine into Safe Mode (F8)
2. Logon with the local administrator account.
3. Click YES to use Safe Mode.
4. Locate C:\Windows\Security folder in Explorer.
5. Create a new folder within this directory called OldSecurity
5. MOVE all *.log files from the C:\Windows\Security folder to
C:\Windows\Security\OldSecurity folder (do NOT move any log files out of
the
LOGS directory!)
6. Locate C:\Windows\Security\Database folder in Explorer.
7. Rename the file SECEDIT.SDB to SECEDIT.SDB.OLD
8. Reboot into normal Windows.
9. Logon with a domain user account.
10. Once logged in, go to the C:\Windows\Security\Database folder in
Explorer.
11. Check that a new SECEDIT.SDB file has been created (from the AD
domain).
12. Logoff.
13. Logon as an administrative account and you will now be able to add the
required Windows component(s).

Bingo!