Over the life of an operating system install, configuration changes can occur that prevent the operating system or applications from functioning correctly. Symptoms that can be caused by overly restrictive security settings include but are not limited to:
When a formerly working installation suddenly fails, a natural troubleshooting step is to return to the last working configuration that existed when the operating system, service or application last worked, or in an extreme case, return the operating system to its out-of-the-box configuration.
This article describes supported and unsupported methods to undo or rollback changes to the following elements:
The previous version of this article states a method to use the “secedit /configure” command with the caveat that the procedure does not restore all security settings that are applied when you install Windows and may result in unforeseen consequences.
The use of "secedit /configure" to import the default security template, dfltbase.inf, is unsupported nor is it a viable method to restore default security permissions on Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 computers.
Beginning with Windows Vista, the method to apply the security during operating system setup changed. Specifically, security settings consisted of settings defined in deftbase.inf augmented by settings applied by the operating installation process and server role installation. Because there is no supported process to replay the permissions made by the operating system setup, the use of the “secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose” command line is no longer capable of resetting all security defaults and may even result in the operating system becoming unstable.
For Microsoft Windows 2000, Windows XP or Windows Server 2003 computers, the “secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose” command is still supported in the very few scenarios where security settings need to be restored using the secsetup.inf template. Since importing the Secsetup.inf or any other template only resets what’s defined in the template and does not restore external settings, this method may still not restore all operating system default, including those that may be causing a compatibility problem.
The use of "secedit /configure" remains fully supported for importing custom templates.
The following is a list of supported methods (in a loose order of preference) to restore the Windows system to its previously working state.
- OS, service or application startup failures
- Authentication or authorization failures
- Resource access failures on the local or a remote computer
- OS upgrades, QFE service pack and application installs
- Group policy changes
- User rights assignments
- Security templates
- The modification of security settings in Active Directory and the registry and other databases
- The modification of permissions on objects in AD, the file system, the Windows registry
When a formerly working installation suddenly fails, a natural troubleshooting step is to return to the last working configuration that existed when the operating system, service or application last worked, or in an extreme case, return the operating system to its out-of-the-box configuration.
This article describes supported and unsupported methods to undo or rollback changes to the following elements:
- Permissions in the Registry, File System and Services
- User rights assignments
- Security policy
- Group membership
The previous version of this article states a method to use the “secedit /configure” command with the caveat that the procedure does not restore all security settings that are applied when you install Windows and may result in unforeseen consequences.
The use of "secedit /configure" to import the default security template, dfltbase.inf, is unsupported nor is it a viable method to restore default security permissions on Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 computers.
Beginning with Windows Vista, the method to apply the security during operating system setup changed. Specifically, security settings consisted of settings defined in deftbase.inf augmented by settings applied by the operating installation process and server role installation. Because there is no supported process to replay the permissions made by the operating system setup, the use of the “secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose” command line is no longer capable of resetting all security defaults and may even result in the operating system becoming unstable.
For Microsoft Windows 2000, Windows XP or Windows Server 2003 computers, the “secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose” command is still supported in the very few scenarios where security settings need to be restored using the secsetup.inf template. Since importing the Secsetup.inf or any other template only resets what’s defined in the template and does not restore external settings, this method may still not restore all operating system default, including those that may be causing a compatibility problem.
The use of "secedit /configure" remains fully supported for importing custom templates.
The following is a list of supported methods (in a loose order of preference) to restore the Windows system to its previously working state.
- Restore using System State: (For all Windows clients/servers)
If you have a System State backup that was created for the particular Windows system prior to the incident, use the same to restore the security settings to a working state. Any changes to the applications on the system since the system state may need to be reapplied for successful recovery. This may not be helpful to restore security settings on application related data or any non-operating system files. You may need a Complete System backup including the system state to restore it back to its original state. - Restore using System Restore: (For Windows client operating systems only)
The built-in System Restore feature automatically creates restore points at regular intervals and when applications are added via supported installer methods. Each restore point contains the necessary information needed to restore the system to the chosen system state. This method can be used to recover the system back to a specific state. As mentioned earlier in the previous method, this may not be helpful to restore security settings on application data and a Complete System backup may be needed for the same. - Restore using a preconfigured template:
For systems built with a template, you can use Security Configuration Wizard if a template was created for the problem machine. - Restore file permissions only:
For file permissions, you can use the built in command line tool ICACLS/restore to restore file security that has been backed up using the /save switch on the same machine from a prior working state. This method can be used to compare the results from an identical working machine to a failing one.
When none of the above methods apply or no backup is available from which to restore, please undo the change by following your change control list or refer to the troubleshooting section of this article to a specific security setting or by process of elimination.
Here is a table comparing the methods mentioned earlier:Method Supported operating systems Pro’s Con’s Pre-work needed Windows Backup All Windows Servers/Clients Can be used to backup data & restore system state Potentially Large data set to manage. Also, you may need to replay changes after the backup that was restored.
Yes System Restore All Windows clients –Windows XP, Windows Vista, Windows 7 Can be configured to perform automatic system state backups Doesn’t restore application data which may be inadvertently changed. Yes Security Configuration Wizard Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2 Can provide a template to restore/apply security Only applies or views data contained within the template used Yes ICACLS /Restore Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2 Useful for backing up NTFS file permissions for reuse later if needed It currently doesn’t offer saving permissions for other locations such as registry, services etc. Yes Troubleshooting methods Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2 Useful when none of the above mentioned tools/backup are available This may not put the entire machine configuration in its original state before the permissions change occurred. Also, undoing such changes may break dependencies set by an application or OS component. No