Share via


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

Do not modify the default domain policy.

  • 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.

Create a separate Group Policy object for software restriction policies.

  • 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).

If you experience problems with applied policy settings, restart Windows in Safe Mode.

  • 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.

Use caution when defining a default setting of Disallowed.

  • 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.

For best security, use access control lists in conjunction with software restriction policies.

  • 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.

Test new policy settings thoroughly in test environments before applying the policy settings to your domain.

  • 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.

Filter user policy settings based on membership in security groups.

  • 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).

  • Linking to a GPO in another domain or site can result in poor performance.