Software Restriction Policies Best Practices

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Best practices

If you do not edit the default domain policy, you always have the option of reapplying the default domain policy if something goes wrong with your customized domain policy.

If you create a separate Group Policy object (GPO) for software restriction policies, you can disable software restriction policies in an emergency without disabling the rest of your domain policy.

For more information, see Group Policy (pre-GPMC).

Software restriction policies do not apply when Windows is started in Safe Mode. If you accidentally lock down a workstation with software restriction policies, restart the computer in Safe Mode, log on as a local administrator, modify the policy, run gpupdate, restart the computer, and then log on normally.

For more information about restarting the computer in Safe Mode, see Start the computer in Safe Mode. For more information about gpupdate, see Gpupdate.

When you define a default setting of Disallowed, all software is disallowed except for software that has been explicitly allowed. Any file that you want to open has to have a software restriction policies rule that allows it to open.
To protect administrators from locking themselves out of the system, when the default security level is set to Disallowed, four registry path rules are automatically created. You can delete or modify these registry path rules; however, this is not recommended.

For more information, see Setting the default security level to Disallowed.

Users might try to circumvent software restriction policies by renaming or moving disallowed files or by overwriting unrestricted files. As a result, it is recommended that you use access control lists (ACLs) to deny users the access necessary to perform these tasks. For information about access control, see Access Control.

New policy settings might act differently than originally expected. Testing diminishes the chance of encountering a problem when you deploy policy settings across your network.
You can set up a test domain, separate from your organization's domain, in which to test new policy settings. You can also test the policy settings by creating a test GPO and linking it to a test organizational unit. When you have thoroughly tested the policy settings with test users, you can link the test GPO to your domain.
Do not set programs or files to Disallowed without testing to see what the effect may be. Restrictions on certain files can seriously affect the operation of your computer or network.
Information that is entered incorrectly or typing mistakes can result in a policy setting that does not perform as expected. Testing new policy settings before applying them can prevent unexpected behavior.

You can specify users or groups for which you do not want a policy setting to apply by clearing the Apply Group Policy and Read check boxes, which are located on the Security tab of the properties dialog box for the GPO.
When the Read permission is denied, the policy setting is not downloaded by the computer. As a result, less bandwidth is consumed by downloading unnecessary policy settings, which enables the network to function more quickly. To deny the Read permission, select Deny for the Read check box, which is located on the Security tab of the properties dialog box for the GPO.

For more information, see Group Policy (pre-GPMC).