Local Security Policy Values May Revert to the Values That Are Stored in SecEdit.sdb After You Install Windows 2000 Service Pack 4

This article has been archived. It is offered "as is" and will no longer be updated.
After you install Microsoft Windows 2000 Service Pack 4 (SP4), some settings that you configured outside the Group Policy editor or the Local Security Policy editor may revert to their original values in certain rare instances. This may occur with settings that you make by using any one of the following methods:
  • Manual changes to registry settings
  • Custom scripts that modify settings
  • Applying a security template by using the Security Configuration Editor (SCE), including the Secedit.exe command line tool
This problem may occur only when the settings are changed within 16 hours of installing SP4.
The master database for security settings is contained in the Secedit.sdb database file. A conflict may occur when the Group Policy engine tries to update the Secedit.sdb database while the SP4 installation has the database open.

SP4 creates two new privileges. To make sure that the security settings for those privileges are reflected in the database, the SP4 installation program will modify and then reapply the Secedit.sdb database during the first restart after SP4 is installed.

When changes to security settings are made outside the Local Security Policy editor or the Group Policy editor, the Secedit.sdb file may not be immediately updated with those changes. For example, if a template that contains a "Registry Values" section is applied using the SCE, the settings in the "Registry Values" section are set in the registry. However, these settings are not updated in the Secedit.sdb database until the next refresh event. By default, the policies in the Secedit.sdb database are refreshed and reapplied every 16 hours. The policies will also be refreshed on restart if a certain flag has been set by the SCE. This flag is set when a security template is applied that contains certain sections in addition to a "Registry Values" section. The sections that cause this to occur are:
  • System Access
  • Event Audit
  • Privilege Rights
After SP4 is installed on a computer, the computer will restart. During this restart the SP4 installation process opens the Secedit.sdb database to apply the new privileges. If the flag is set the Group Policy engine will also try to open the Secedit.sdb database during the restart. If this problem occurs while the SP4 installer has the Secedit.sdb database open, the Group Policy engine will not successfully open the Secedit.sdb database. In this case, the Group Policy engine fails to record the changes made in the registry in the Secedit.sdb database. The SP4 installation then triggers a reapplication of the Secedit.sdb database, permanently recording the settings that are stored in the Secedit.sdb database and overwriting the settings that are set in the registry.

This problem may occur if registry values are changed manually or using a script. However, the problem is most likely to occur when SP4 is installed before the system is rebooted after a security template is applied using the SCE. If the values in the registry were set manually, as opposed to using the SCE, the problem would only occur if the next policy refresh event occurs while the SP4 installer is holding the database open.
To work around this issue, open Local Security Policy before you install Windows 2000 SP4. When you do this, the values that are stored in the registry are propagated to the Secedit.sdb file. To do this, follow these steps:
  1. Click Start, point to Settings and then click Control Panel.
  2. Double-click Administrative Tools.
  3. Double-click Local Security Policy.
  4. On the Tree tab, expand Local Policies, and then click Security Options.
  5. Double-click one of the policies in the Policy list.
  6. Do not change the policy settings. Click OK to close the Local Security Policy Setting dialog box.
  7. Close the Local Security Settings dialog box.
You may also trigger the refresh from the command line. This could be used in an automated script to install SP4. The following command will trigger the refresh and make sure that the Secedit.sdb file contains the updated settings:
secedit /refreshpolicy machine_policy /enforce
After you complete this procedure, install Windows 2000 SP4.

For additional information about how to work around this issue, click the following article number to view the article in the Microsoft Knowledge Base:
329055 Security Option Settings Are Not Shown in Gpedit.msc After You Apply a Security Template with Secedit.exe on a Stand-Alone Server
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.

For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
318711 HOW TO: Use the Secedit.sdb Database to Perform a Security Analysis in Windows 2000

Article ID: 827664 - Last Review: 02/27/2014 21:19:55 - Revision: 5.1

Microsoft Windows 2000 Service Pack 4, Microsoft Windows 2000 Professional Edition, Microsoft Windows 2000 Advanced Server

  • kbnosurvey kbarchive kbpending kbbug kbfix kbqfe kbwin2000presp5fix KB827664