Results 1 to 2 of 2

Thread: Group Policy secedit.sdb used for?

  1. #1
    PreviousPoster is offline 100+ Helpful Posts! 50+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    1,254

    Default

    I have an issue were the security updates(We have a splash screen,etc.) do not apply unless I delete the file secedit.sdb

    C:\WINDOWS\security\Database

    This does not happen at every computer.

    I noticed the default size is 1MB and when the policies apply the size is 3 MB.

    Does anyone know why the file gets corrupted?

    Thanks
    Bill

  2. #2
    PreviousPoster is offline 100+ Helpful Posts! 50+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    1,254

    Default

    From what we have been able to determine...

    We think that when the Domain Security Settings are sent to the workstation they land in the %WinDir%\Security\Templates\Policies directory. The workstation will then attempt to apply the settings to the security database SecEdit.SDB. If there is a problem or the system is unable to post the settings to the database I think they will be stored in files in the %WinDir%\Security directory, ...EDB.chk, EDB.Log, Res1.Log, Res2.Log are examples we have seen.

    After a reboot, or sometimes more then one, the system will write the settings to the database and delete these files. We have observed this behaviour in freshly imaged workstations that, after imaging are left with the Local Admin account logged in. The files mentioned above are in the Security directory and after rebooting are gone.

    This implies that on broken workstations the end target of the Security GPOs is the SecEdit.SDB database. These files, if they exist on the workstation, are/might be settings that are 'stuck in the pipe'. Some of these files are, at times, locked by the system. This indicates a need for a reboot and a forced deletion before the system locks them again or attempts to apply them to the fixed SecEdit.SDB database.

    Comments ? Is this true ?

    As far as why the SecEdit.SDB gets corrupted... we have noticed this behaviour when the DST ( Daylight Savings Time ) of the image is different from the current DST... or if the time isn't set correctly when imaging a new system. Currently our solution was to remove the TimeZone=035 from SysPrep.INF so that when re-applying the image you are asked and can change the time and region to the correct...



    1202 with 0x4b8 Errors will be posted to the Event Log...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Search Engine Friendly URLs by vBSEO