Windows Server® 2008 retains SCW, which has been updated with new roles and integration with the new Windows® Firewall. However, it remains as advanced an administration tool as it ever was.

Windows Server 2008 also includes the new roles-based Server Manager tool and its kin, the Add Roles and Add Features Wizards. In Windows Server 2008, rather than adding individual components through the old-style Add/Remove Windows Components control panel, you now use the roles management tools to configure your server. Byron Hynes covers these tools in the article "Configuring Roles with Server Manager," also in this issue of TechNet Magazine.

The Add Roles and Add Features Wizards are designed to configure your server with the right components to support the roles you've chosen. These also configure the built-in firewall to ensure these roles function correctly. Given this, you may be wondering whether there is still any need for SCW. Granted, there are many administrators that will no longer have a need for SCW. However, there are two groups of people for whom SCW can be an invaluable tool. The first is the paranoid security folks. These are people that appreciate how SCW takes security to the next level.

You can think of the Add Roles and Add Features Wizards as the tools that take a default server and configure it to securely support the roles and features you want. SCW, on the other hand, is the tool that configures your server to support only the roles and features you want. SCW also has a pedagogical effect in that it helps you understand more about how the server is configured. Therefore, I highly recommend that you run SCW after the server has been configured with its complement of roles and features.

The second group consists of those users who want to understand the relationships between the various components. SCW comes with a set of XML files that document the relationships between roles and features, services, and network ports. If you are interested in understanding what various components need, SCW is a very valuable tool.

In this column, I will describe how SCW works and how you would use it to protect your server. And I will provide a comparison between SCW and the Server Manager tools. Note that this column is adapted from my book, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008).

To set the stage, I want to present some statistics about the attack surface on Windows Server 2008. Before you configure a server by adding your personal selection of roles and features, it still has a relatively significant footprint of services. By default, Windows Server 2008 has 105 services—42 of which are set to auto start, 55 are set to manual, and 8 are disabled. Contrast that with a clean installation of Windows Server 2003 R2 SP2, which has 86 services installed by default—34 of these are set to start automatically, 32 are set to demand start, and 20 are disabled.

Even with the roles metaphor and the reduction in default roles supported, Windows Server 2008 still has a larger footprint and requires that you take additional care when hardening your servers. SCW will walk you through creating a custom security configuration for your particular servers.

SCW takes a completely different approach to server hardening than existing tools. It works with a roles metaphor to configure the system to support those roles and little, if anything, else. While SCW helps configure the firewall, as the Add Roles and Add Features Wizards do, SCW also disables unnecessary services and configures some additional security settings. Finally, while the Add Roles and Add Features Wizards are only able to install and configure roles that are built into Windows, SCW is extensible. A developer or an administrator can write a custom role or feature configuration file and use SCW to configure any product.

SCW is designed to be used after you have installed all the roles and features the server is supposed to have. If you also have third-party applications on your server, you should install those, too, before you run SCW.

To demonstrate how this works, I have configured a server with three roles (Application Server, DNS Server, and Web Server) and two features (Microsoft® .NET Framework 3.0 Features and Windows Process Activation Service). This is not a particularly logical set of roles and features, but it serves as a good example for this discussion.

To start SCW, run it from the Administrative Tools menu. You will see the dialog shown in Figure 1.

The first step is to choose whether you want to create a new security policy, edit or apply an existing policy, or roll back a policy so the system will return to the original settings. The choices are relatively self-explanatory.

When you choose to create a new security policy, SCW creates a new policy using some computer as the template for what the policy must support. It analyzes the computer and determines what features and roles it supports, ensuring that those work but also that many unnecessary features are not enabled.

SCW works on a prototype model. It uses XML files to specify what the roles and features look like in terms of which files are installed, which services are configured, and so on. This is why you need everything installed on the computer that you are developing the policy against. If you have third-party programs that install SCW definitions when they install, those will integrate seamlessly. However, if your third-party programs do not install SCW definitions, you will need to configure them manually.

As you can see, you can create a policy on one system and then apply it to many systems. If you are building out a network with many systems, you should first define host classes that are all configured separately. Then you can create a policy using one of them as a prototype and easily apply the policy to all the others with little to no modifications.

When you click Next (in the dialog shown in Figure 1), the wizard asks which computer you want to use as the baseline, or prototype, for this new policy. You would typically choose the local computer, but you also have the option to use a remote computer as the prototype.

After specifying which system to use, you enter the analysis phase. Here, SCW enumerates which roles and features you have installed and matches those up against the database of roles and features. The database contains information regarding which services are used by each role and feature, what network ports they need, and other important configuration information. After the analysis is complete, you can click View Configuration Database to see what the Security Configuration Wizard has found. Note that this is a read-only view that presents comprehensive information about the configuration of the computer. In fact, if you are truly interested in understanding what is on your computer, you can spend a significant amount of time studying this information.

When you click Next, you enter the first of four sections in SCW: Role-Based Service Configuration. You might notice that the roles you find in SCW, as shown in Figure 2, are not the same set that you find in the Add Roles Wizard. Most of the roles available in the Add Roles Wizard are also present here, and SCW also offers some that are not included in the Add Roles Wizard. For example, the Application Server role that I selected is not present. This is because SCW uses a slightly different metaphor for roles. I will discuss this in more detail shortly.

You will often have the right set of roles already selected in this dialog. So just verify that the analysis found what you think it should have found. If something is wrong, check whether the role has been installed, and install it if it is missing before you rerun SCW. If you make a mistake, it is not the end of the world. The rollback feature in SCW will bring you back to where you started by undoing any changes the policy has made.

The answers you give in this section are very important because they determine what you will see later on in the network section. Fortunately, the detection logic is quite good and the correct set of roles is usually selected.

Note also that, by default, you see Installed Roles, which are the roles that the server is capable of supporting with the bits laid down on the disk. The selected roles are the ones that it is currently supporting. You can also elect to see all roles in the database. To do this, just select All Roles from the dropdown list. This is useful primarily when you have to build a policy using a prototype server that does not yet have all the roles it needs installed.

After roles configuration, you select the client features you want to support. The feature set is similar but not identical to that in the Add Features Wizard, and there are fewer features in the set. Again, the metaphors are not exactly the same, and SCW can be extended, so what you will see is different from the Add Features Wizard.

When you click Next on the Client Features page in SCW, you go to the Select Administration and Other Options dialog, as shown in Figure 3. An Option in SCW is something that does not neatly fit into either a role or a feature. It may provide administrative support, or it may just be a single service, such as the Interactive Services Detection. Again, most of the options you need should be selected here. It is worth pointing out the dropdown menu, too. This is populated with options relevant to the roles and features you selected earlier, and it will be different on different computers.

Next up is the Additional Services dialog. Although SCW ships with a very large database of services, not everything is described here. Those services that SCW finds on a computer that are not present in the database are shown on the Additional Services page. All built-in services should be described, and you should not see this dialog unless you have some third-party service installed.

The wizard then lets you select what to do with services that you are not configuring. This option is meant for when you plan to take the policy you are creating and apply it to a different computer. If that computer has different services than the one you created the policy on, SCW needs to know what to do with them. One option is to leave them alone, which is the default. The other option is to disable them, which is more secure but may break things. But if you follow the advice of only applying policies to servers that are identical to the one you created them on, your choice on this page will be irrelevant.

Now you are finished with the Roles Configuration portion of SCW, and the wizard recaps what you've done. As you can see in Figure 4, even if you just click right through, you will significantly affect the attack surface of the computer. For instance, because this computer is not a Print Server, and it has no printers installed, you have no reason to run the Print Spooler service. SCW disables all services that are not necessary. On our test server, SCW disables 17 services that were set to automatic start and sets 42 manual start services to disabled. Your results, of course, will vary depending on how your server is configured, but you can see that SCW lets you easily tailor a policy specific to your unique servers, thereby drastically reducing their attack surface.

You now move on to arguably the most important section of SCW: Networking. After the initial welcome page, you see the Network Security Rules dialog, which is shown in Figure 5. This contains a list of all the firewall rules SCW proposes, which are based on the role support you selected in the previous sections.

If no further configuration is made in the Network section, SCW will build firewall rules that lock down the network interfaces so that only these roles and features are supported but all clients can access them. But to really optimize security on your servers, you should use SCW as an integral part in building a Server Isolation strategy. To learn more about server isolation (and its close sibling, domain isolation), take a look at technet.microsoft.com/network/bb545651.

In Windows Server 2008 Security Resource Kit, there is a chapter on securing the network with server and domain isolation. It also discusses how you can use network threat modeling to analyze your network to help ease deployment of server isolation. SCW is a valuable tool in this process.

You can configure restrictions on the proposed rules by selecting the rule and clicking Edit. This takes you to the dialog shown in Figure 6. This is one of four pages that all let you put further restrictions on the networking rules. For instance, you can require IPsec authentication. If you choose this, you can also tie the port to only certain endpoints. For example, you can configure it so that you permit remote administration only from certain hosts. As you can see, this is a key advantage over the Add Roles and Add Features Wizards.

This ability to build connection security rules based on the roles you've selected serves two important purposes. First, it provides a golden learning opportunity to understand what your servers are doing. You don't even need to build out a server. You can just run the wizard, make different selections, and see how they affect the options on later pages. Second, it allows you to tie the very abstract concept of a port to a much more logical concept of a service and configure network restrictions based on exactly what the system is actually doing.

Done right, this permits you to develop a very tight configuration for your servers. The Networking section of SCW is undoubtedly the place where you should be spending the majority of your time when building the security policy for your servers.

The remainder of SCW allows you to configure auditing and a few registry settings. The default settings of these parameters are adequate for most organizations and, unless you have special requirements, you should not need to do much here.

After you create your policy, you can save it and apply it to the computer you are working on. Or you can apply it to other computers. You can also transform your policy to a Group Policy Object (GPO) using the scwcmd.exe /transform command.

However, if you have computer-specific settings in the policy, this may not succeed—or it may give very strange results. For instance, if you create endpoint restrictions that include local adapters in the networking section, the policy is deemed computer-specific and will not successfully transform. This is due to the fact that those adapters must be specified using GUIDs. The GUID for an adapter on one computer is meaningless on another computer.

Therefore, SCW is often better used on a server-by-server basis and as a learning tool. For large server farms, you can use SCW as a way to learn about the computers and develop a basic policy. Then you can take that policy and recreate it to be rolled out using whatever tool you use to configure the servers, such as Group Policy or an Enterprise Management System (such as Microsoft Systems Center).

One thing you've seen so far is that the metaphor used for roles and features differs. A "feature" in SCW is something the computer does to act as a client. A "role," meanwhile, is something it does to act as a server.

This differs from the metaphor used in the Server Manager tools, where a role is a collection of services and features that can be thought of as a unit and a feature is something that supports roles. In essence, Server Manager considers a role to be the thing you bought the server to do. Features are important, but not what you bought the server for. The two metaphors and the two different uses of the same terms are bound to confuse people. You will need to stop and think about this carefully before you switch between the tools.

In addition, the Server Manager tools are not extensible. They are designed to manage only the components that ship with Windows. By contrast, third-party programs that you install can add roles and features to SCW. You can even write your own roles and features. The white paper "Extending the Security Configuration Wizard" (available at go.microsoft.com/fwlink/?LinkId=107397) explains how to do this.

SCW also disables components you do not need. The Server Manager tools, on the other hand, merely deploy components that you ask for—they do not touch anything else on the computer. If you need help determining which components you may not need, SCW is the tool to use.

Moreover, while both the Server Manager tools and SCW will configure your network, SCW is far more powerful in this regard. If you are building out a server isolation strategy, SCW can be a gold mine of information and your best friend for deployment. This is obviously an advanced security administration topic, but SCW is an advanced security tool.

Finally, SCW will also configure some additional security settings that the Server Manager tools do not configure. However, those are largely superseded by more effective controls—or already set by default—on Windows Server 2008.