Planning the SCW Deployment
Updated: March 28, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2
This topic discusses planning for SCW deployment.
Safe use of any technology that affects the settings, configuration, or behavior of multiple computers requires planning before deployment. Safe use of SCW includes lab-testing of tools and policies prior to live rollout into a production environment. This and other best practices for SCW are covered in this section.
After a discussion of additional resources that can help you become familiar with SCW, this section includes guidelines for defining exactly which computers support local installation of SCW and the tools included with SCW and which computers are valid targets for policy that you author by using SCW.
Review SCW resources
Additional information about SCW is available at the following sources:
SCW documentation from the Download Center on the Microsoft Web site (http://go.microsoft.com/fwlink/?linkid=45183)
SCW Quick Start Guide
SCW Deployment Guide
- SCW Troubleshooting Guide
- SCW Quick Start Guide
SCW online Help
Each page of SCW contains a link to online help that is specific to that wizard page. You can view the online help file in its entirety from the command line by hh scwhelp.chm. There is also a link to the help file on the desktop once SP1 is installed. The help file is available in SP1 regardless of whether SCW itself is installed.
Scwcmd.exe command-line tool help
After SCW is installed, help for the command-line tool can be obtained from the command line by typing scwcmd. This displays the following:
Syntax: scwcmd [ analyze | configure | register | rollback | transform | view ]
Help for each of these six options is obtained by typing scwcmd option_name.
Note The scwcmd view command allows the use of a template (.xsl file) to format the display in the SCW viewer. The correct syntax is to have the template first, for example scwcmd view /s:scwpolicy.xsl /x:main.xml. The command-line help that you get by typing scwcmd view incorrectly shows the /x: parameter first.
Review requirements for local installation of SCW
You can install SCW only on computers running Windows Server 2003 with Service Pack 1 (SP1), which includes SCW as an optional Windows component. SCW is not installed by default, but you can install it by clicking Add/Remove Windows Components in Add or Remove Programs in Control Panel. To install SCW, you need to be a member of the Administrators group on the server.
SCW should not be used with Windows Small Business Server 2003 or client operating systems like Windows XP Professional.
Determine valid targets for applying SCW security policy
The security policies that are created with SCW should be applied only to servers and groups of servers. They should not be applied to client operating systems such as Windows XP Professional, nor should they be applied to systems running Windows Small Business Server 2003.
Identify valid targets for SCW policy prototyping
In the context of SCW, “policy prototyping” means using SCW to author security policy for groups of similarly configured computers by targeting SCW at a prototype computer: a model server whose configuration is representative of every computer in the group. Only computers running Windows Server 2003 with SP1 are valid targets for SCW security policy authoring.
When SCW is installed and run locally but targeted at a remote server for authoring policies, it is best for the remote server to also have SCW installed. This is because SCW includes so-called “helper functions” that inspect the computer. If SCW is installed on the remote computer, the locally-run wizard can make these determinations about the remote computer:
Whether unknown services are listening on a port.
Whether approved applications are installed.
The list of named pipes.
Whether an IPsec policy is applied
Review SCW Best Practices
This section explains how to get the most out of SCW by following best practices.
Identify and target similar servers.
SCW helps to reduce the attack surface of servers by creating a security policy that is specifically designed for their specific roles. Administrators can simplify policy authoring and distribution by identifying groups of servers that perform the same, or similar, tasks.
Author one policy for a group of servers.
SCW authors a security policy based on the roles and functions performed by a server. Others servers that perform the same, or very similar, functions can be configured with the same security policy. Administrators can use SCW once to author a security policy, save it, and apply it to all servers that perform the job function. A single security policy that contains all desired security settings for a server also simplifies configuration, rollback, and analysis.
For simple configuration and rollback, a single security policy for a computer, or set of computers, is much easier to understand and update than a series of policies. The scwcmd analyze command has a p:/policyname parameter that only accepts a single SCW native policy file as a parameter.
Group similar servers in one organizational unit (OU).
Grouping servers by OUs in Active Directory domains facilitates the application of security policy through Group Policy. The SCW transform operation can create an unlinked security policy containing GPO in Active Directory. To simplify policy distribution, an administrator can group servers that perform similar functions into a single OU, and link the GPO to the OU.
Create different policies for different platforms.
For services or ports specific to 64-bit computers, create the policies on a 64-bit computer. Then deploy these policies to other 64-bit computers only (not 32-bit computers) to ensure the services are properly identified and configured.
It is highly recommended that the prototype server from which the security policy will be created resembles the target servers to be configured as closely as possible. Not only are there options in the wizard that are not shown unless the prototype server has those options, the modifications done to services and other items could cause severe interoperability problems unless the prototype resembles the target.
The security policy might disable any service that was not present on the prototype server when the policy was created. Any service defined in the security configuration database but not present on the prototype server will be disabled. The configured state of a service that is not present on the prototype and that is not in the security configuration database is configurable in the wizard. For example, if the DCOM Server Process Launcher service is listed in the Security Configuration Database, but is not present on the prototype server, the security policy created from the prototype server will set the DCOM Server Process Launcher state to disabled. When you apply the security policy to other servers, the DCOM Server Process Launcher service will be disabled on those servers.
Test new security policies before deployment.
The settings configured in the new security policies may cause compatibility issues with applications or services. Therefore, thoroughly test new security policies in a test environment before applying the policies to production servers. Virtual machines are particularly well suited for this purpose.