Server 2008

Creating and Deploying Active Directory
Rights Management Services Templates

Step-by-Step Guide
Microsoft Corporation
Published: May 2007

Author: Brian Lich
Editor: Carolyn Eller
Abstract
This step-by-step guide provides instructions for setting up a test environment for
creating and deploying Active Directory Rights Management Services (AD RMS) rights
policy templates on the Windows Server® Code Name "Longhorn" operating system.
This document supports a preliminary release of a software product that may be changed
substantially prior to final commercial release, and is the confidential and proprietary
information of Microsoft Corporation. It is disclosed pursuant to a non-disclosure
agreement between the recipient and Microsoft. This document is provided for
informational purposes only and Microsoft makes no warranties, either express or
implied, in this document. Information in this document, including URL and other Internet
Web site references, is subject to change without notice. The entire risk of the use or the
results from the use of this document remains with the user. Unless otherwise noted, the
example companies, organizations, products, domain names, e-mail addresses, logos,
people, places, and events depicted herein are fictitious, and no association with any real
company, organization, product, domain name, e-mail address, logo, person, place, or
event is intended or should be inferred. Complying with all applicable copyright laws is
the responsibility of the user. Without limiting the rights under copyright, no part of this
document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other

intellectual property rights covering subject matter in this document. Except as expressly
provided in any written license agreement from Microsoft, the furnishing of this document
does not give you any license to these patents, trademarks, copyrights, or other
intellectual property.
© 2007 Microsoft Corporation. All rights reserved.
Active Directory, Microsoft, MS-DOS, Vista, Windows, Windows NT, and Windows Server
are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
All other trademarks are property of their respective owners.

Contents
Creating and Deploying Active Directory Rights Management Services Rights Policy
Templates Step-by-Step Guide ....................................................................................... 5
About this Guide .............................................................................................................. 5
What This Guide Does Not Provide ............................................................................. 5
Deploying AD RMS in a Test Environment...................................................................... 6
Step 1: Creating a Shared Folder on the AD RMS Cluster................................................. 7
Step 2: Creating an AD RMS Rights Policy Template ........................................................ 9
Step 3: Configuring the AD RMS client ............................................................................. 10
Step 4: Verifying AD RMS Functionality using ADRMS-CLNT ......................................... 12

5
Creating and Deploying Active Directory

Rights Management Services Rights
Policy Templates Step-by-Step Guide
About this Guide

This step-by-step guide walks you through the process of creating and deploying Active
Directory Rights Management Services (AD RMS) policy templates in a test environment.
During this process you create a rights policy template, deploy this template to a client
computer running Windows Vista™ and Microsoft® Office Word 2007, and verify that the
client computer can rights-protect a document by using the newly-created rights policy
template.
Once complete, you can use the test lab environment to assess how AD RMS rights
policy templates can be created with Microsoft Windows Server® Code Name "Longhorn"
and deployed within your organization.
As you complete the steps in this guide, you will:
• Create an AD RMS rights policy template.
• Deploy the rights policy template.
• Verify AD RMS functionality after you complete the configuration.
The goal of an AD RMS deployment is to be able to protect information, no matter where
it is moved. Once AD RMS protection is added to a digital file, the protection stays with
the file. By default, only the content owner is able to remove the protection from the file.
The owner can grant rights to other users to perform actions on the content, such as the
ability to view, copy, or print the file.
What This Guide Does Not Provide

This guide does not provide the following:
• Guidance for setting up and configuring AD RMS in either a production or test

environment. This guide assumes that AD RMS is already configured for a test
environment. For more information about configuring AD RMS, see Windows Server
6
Active Directory Rights Management Services Step-by-Step Guide

(http://go.microsoft.com/fwlink/?LinkId=72134).
• Complete technical reference for AD RMS or deploying AD RMS templates within
your organization. In a large organization, Systems Management Server (SMS) or
Group Policy can provide a way to deploy AD RMS rights policy templates to several
workstations at a time.
Deploying AD RMS in a Test Environment

We recommend that you first use the steps provided in this guide in a test lab
environment. Step-by-step guides are not necessarily meant to be used to deploy
Microsoft products without accompanying documentation and should be used with
discretion as a stand-alone document. Before you start the steps in this guide, you will
need to use the steps provided in Windows Server Active Directory Rights Management
Services Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=72134), also in a lab
environment. That guide prepares the basic infrastructure for an AD RMS deployment,
with an AD RMS cluster, AD RMS Logging database, and domain controller. This step-
by-step guide builds on the previous guide, so it is important to complete it before starting
this one. On completion of this step-by-step guide, you will have a working AD RMS
rights policy template. You can then test and verify AD RMS rights policy template
functionality through the simple task of restricting permissions on a Microsoft Office
Word 2007 document with the rights policy template created in this guide.
The test environment described in this guide includes three computers connected to a
private network and using the following operating systems, applications, and services:
Computer Name Operating System Applications and Services
ADRMS-SRV Windows Server "Longhorn" AD RMS, Internet

Information Services
(IIS) 7.0, World Wide Web
Publishing Service, Message
Queuing (also known as
MSMQ), and Windows
Internal Database
CPANDL-DC Windows Server 2003 with Active Directory®, Domain

Service Pack 1 (SP1) Name System (DNS)
7
ADRMS-DB Windows Server 2003 with Microsoft SQL

SP1 Server™ 2005 Standard
Edition
ADRMS-CLNT Windows Vista Microsoft Office Word 2007

Enterprise Edition
The computers form a private intranet and are connected through a common hub or
Layer 2 switch. This configuration can be emulated in a virtual server environment if
desired. This step-by-step exercise uses private addresses throughout the test lab
configuration. The private network ID 10.0.0.0/24 is used for the intranet. The domain
controller is named CPANDL-DC for the domain named cpandl.com.
The following figure shows the configuration of the test environment:
Step 1: Creating a Shared Folder on the

AD RMS Cluster
To ease administration of the rights policy templates, you can store AD RMS rights policy
templates in a central location so that they can be copied to the AD RMS clients. Some
distribution methods include using Systems Management Server, Group Policy, or
manually copying the templates to the AD RMS client. In this guide, the rights policy
templates are copied manually.
8
Note
The AD RMS service account must have Write access to the rights policy
template shared folder in order for the rights policy template export function to
work correctly.
To create a shared folder for the AD RMS rights policy templates and set appropriate
permissions for the AD RMS service account, do the following:
To create an AD RMS rights policy templates shared folder

1. Log on to ADRMS-SRV as CPANDL\Administrator.
2. Click Start, click Computer, and then double-click Local Disk (C:).
3. Create a new folder named ADRMSTemplates. Click Organize, click New
Folder, type the name ADRMSTemplates, and then press ENTER.
4. Right-click the ADRMSTemplates folders, and then click Properties.
5. Click the Sharing tab, and then click Advanced Sharing.
6. Select the Share this Folder check box, and then click Permissions.
7. Click Add, in the Enter the object names to select box type
CPANDL\ADRMSSRVC, and then click OK.
8. In the Group or user names box, click ADRMSSRVC

(ADRMSSRVC@cpandl.com), and then, in the Permissions for ADRMSSRVC
box, select the Change check box in the Allow column.
9. Click OK twice.
10. Click the Security tab, and then click Edit.
11. Click Add, in the Enter the object names to select box type
CPANDL\ADRMSSRVC, and then click OK.
12. Click ADRMSSRVC (ADRMSSRVC@cpandl.com), and then, in the
Permissions forADRMSSRVC box, select the Modify check box in the Allow
column, and then click OK.
13. Click Close.
9
Step 2: Creating an AD RMS Rights

Policy Template
As mentioned earlier in this guide, AD RMS rights policy templates are created on the
AD RMS cluster and then exported to a shared folder. If your users will be using the
AD RMS-enabled application only when connected to the internal network, the templates
can be accessed from the shared folder by the clients as needed. In this case, all
AD RMS users should have Read access to this shared folder in order for them to use
the rights policy template.
Alternatively, the templates can be copied from the shared folder to the client computers.
This enables the templates to be used when users are not connected to the network,
such as when traveling with a laptop or from another mobile device. Because the most
common deployment is to copy the templates to the client computers, this is the
approach explained in this guide.
To create a new AD RMS rights policy template

1. Open the Active Directory Rights Management Services Administration console.
Click Start, point to Administrative Tools, and then click Active Directory
Rights Management Services.
2. In the Active Directory Rights Management Services Administration console, click

LocalHost.
3. In the Tasks box in the Results pane, click Manage rights policy templates.
4. To enable exporting of the AD RMS rights policy templates, click Properties in
the Actions pane.
5. Select the Enable export check box, type \\adrms-srv\ADRMSTemplates in the
Specify templates file location (UNC) box, and then click OK.
6. In the Actions pane, click Create Distributed Rights Policy Template to start
Create Distributed Rights Policy template wizard.
7. Click Add.
8. In the Language list, choose the appropriate language for the rights policy
template.
9. Type CPANDL.COM CC in the Name box.

10. Type CPANDL.COM Company Confidential in the Description box, and then
click Add.
10
11. Click Next.

12. Click Add, type employees@cpandl.com in The e-mail address of a user or
group box, and then click OK.
13. Select the View check box to grant the EMPLOYEES@CPANDL.COM group
Read access to any document created by using this AD RMS rights policy
template.
14. Click Finish.
Step 3: Configuring the AD RMS client

The AD RMS client is included in the default installation of Windows Vista. Previous
versions of the client are available for download for other Windows operating systems.
This guide assumes that an AD RMS cluster is already configured in a test environment.
Additionally, extra configuration is required on the AD RMS client workstation so that the
rights policy templates are accessible. To make the AD RMS rights policy templates
accessible, you must copy the AD RMS rights policy templates to the client computer and
create a registry entry that points to the location of the rights policy templates.
To create a folder for rights-protected content

1. Log on to ADRMS-CLNT as administrator.
2. Click Start, and then click Computer.
3. Double-click Local Disk (C:).
4. Create a new folder named ADRMSDocs. Click Organize, click New Folder, and
then type ADRMSDocs for the folder name.
5. Right-click the ADRMSDocs folder, and then click Properties.
6. Click the Security tab, and then click Edit.

7. Click Users (ADRMS-SRV\Users), and then in the Permissions for Users box
select the Modify check box in the Allow column.
8. Click OK twice.
11
In order for the AD RMS client computer to locate the templates, you must add a
registry entry and copy the AD RMS rights policy templates locally. To do this, you must
complete the following steps before rights-protecting a document:
To make AD RMS templates available to users on ADRMS-CLNT

1. Log on to ADRMS-CLNT as Nicole Holliday (nhollida@cpandl.com).
2. Click Start, type regedit.exe in the Start Search box, and then click the
regedit.exe icon under Programs.
3. Expand the following registry key:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\DRM
Note
If DRM was not already created as a part of the key, you must create it
manually.
4. Select DRM, click Edit, point to New, click Expandable String Value, and then
type AdminTemplatePath.
5. Double-click the AdminTemplatePath registry value and type
%UserProfile%\AppData\Microsoft\DRM\Templates in the Value data box
where %UserProfile% equals C:\Users\<user name>, and then click OK.
6. Close Registry Editor.
7. Verify that the path C:\Users\nhollida\AppData\Microsoft\DRM\Templates\ is
valid. If it is not, create the appropriate folders.
8. Click Start, type \\ADRMS-SRV\ADRMSTemplates in the Start Search box, and
then press ENTER.
9. Copy the exported AD RMS rights policy templates from \\ADRMS-

SRV\ADRMSTemplates to C:\Users\nhollida\AppData\Microsoft\DRM\Templates.
Note
Copying the AD RMS rights policy templates to the client computer is not
required if the rights policy templates do not have to be available offline.
12
Step 4: Verifying AD RMS Functionality

using ADRMS-CLNT
To verify the functionality of the AD RMS deployment, you log on as Nicole Holliday and
then restrict permissions on a Microsoft Word 2007 document by using the AD RMS
rights policy template created earlier in this guide. This policy gives CP&L employees the
ability to read the document but not to change, print, or copy. All other people have no
access at all to the document. You then log on as Stuart Railson and verify that Stuart
Railson, a member of the Employees group at CP&L, cannot print the document.
To restrict permissions on a Microsoft Word 2007 document

1. Log on to ADRMS-CLNT as Nicole Holliday (nhollida@cpandl.com).
2. Click Start, click All Programs, click Microsoft Office, and then click Microsoft
Office Word 2007.
3. Type CP&L Employees cannot print this document on the blank document
page, click the Microsoft Office button, point to Finish, point to Restrict
Permission, click Restrict Permission as, select nhollida@cpandl.com in the
Select User dialog box, and then click OK.
4. In the Permission dialog box, select the Restrict permission to this document
check box, click Read, type the name of the user or group to be restricted. In this
case, type employees@cpandl.com, and then click OK twice.
5. Click the Microsoft Office button, click Save As, and then save the file as
\\ADRMS-DB\public\ADRMS-TST.docx.
6. Log off as Nicole Holliday.
Next, log on as Stuart Railson and open the document, ADRMS-TST.docx.
To view a protected document

1. Log on as Stuart Railson (srailson@cpandl.com).
2. Click Start, point to All Programs, point to Microsoft Office, and then click
Microsoft Office Word 2007.
3. Click the Microsoft Office button, click Open, navigate to \\ADRMS-DB\public,
and then double-click ADRMS-TST.docx.
The following message appears: "Permission to this document is currently

restricted. Microsoft Office must connect to https://adrms-
13
srv.cpandl.com/_wmcs/licensing to verify your credentials and download

your permission."
4. Click OK.
The following message appears: "Verifying your credentials for opening

content with restricted permissions…"
5. When the document opens, click the Microsoft Office button. Notice that the
Print option is not available.
6. Click View Permission in the message bar. You should see that AD RMS rights
policy template has been applied to this document.
7. Click OK to close the My Permissions dialog box, and then close Microsoft
Word.
You have successfully deployed and demonstrated the rights templates policy feature of
AD RMS, using the simple scenario of applying a rights policy template to a Microsoft
Word 2007 document. You can also use this deployment to explore some of the
additional capabilities of AD RMS through additional configuration and testing.
Deploying Active Directory Rights
Management Services in an Extranet
Step-by-Step Guide
Published: May 2007
Author: Brian Lich
Abstract
This step-by-step guide provides instructions for setting up an Active Directory Rights
Management Services (AD RMS) cluster from an extranet in a test environment on
Windows Server® 2008. The extranet will be verified by attempting to open a rights-
protected file from a client computer that is not on the organization's internal network.

Microsoft, Active Directory, MS-DOS, Vista, Windows, Windows NT, and Windows Server
are either registered trademarks or trademarks of Microsoft Corporation in the

Contents
Deploying Active Directory Rights Management Services in an Extranet Step-by-Step
Guide ............................................................................................................................... 5
About this Guide .............................................................................................................. 5
What This Guide Does Not Provide ............................................................................. 5
Deploying AD RMS in a Test Environment...................................................................... 6
Step 1: Configuring AD RMS to Work in an Extranet ......................................................... 8
Step 2: Installing and Configuring ISA-SRV ..................................................................... 10

Configure the ISA Server (ISA-SRV) ............................................................................. 10
Publish AD RMS cluster to extranet .............................................................................. 13
Step 3: Configuring AD RMS Extranet Client ................................................................... 15
Step 4: Verifying AD RMS Functionality using ADRMS-CLNT ......................................... 18

5

Management Services in an Extranet
Step-by-Step Guide
About this Guide

This step-by-step guide walks you through the process of configuring Active Directory
Rights Management Services (AD RMS) in a test environment that includes an extranet.
An extranet is an extension of your organization's network to an external source. In this
guide, the AD RMS cluster is extended to the Internet so that users can consume rights-
protected content when not connected to the internal network. During this process, you
install Microsoft Internet Security and Acceleration (ISA) Server 2006 Standard Edition,
integrate it with AD RMS, and verify that you can open a rights-protected document from
a computer that is not a member of your organizational network.
Once complete, you can use the test AD RMS lab environment to assess how AD RMS
on Windows Server® 2008 can be created and deployed within your organization to
accommodate for extranet users.

• Install and configure ISA Server 2006 Standard Edition with AD RMS.
Note
ISA Server 2006 Standard Edition is not required for AD RMS. Any reverse proxy
server that has the ability to listen on TCP ports 80 and 443 can be used. For the
purposes of this guide, we will use ISA Server 2006 Standard Edition.

• Guidance for setting up and configuring AD RMS in either a production or test
environment. This guide assumes that AD RMS is already configured for a test
environment. For more information about configuring AD RMS, see the Windows
6
Server Active Directory Rights Management Services Step-by-Step Guide

• Complete technical reference for AD RMS or Microsoft ISA Server 2006 Standard
Edition. For more information about Microsoft ISA Server 2006 Standard Edition, visit
the ISA Server 2006 Technical Library

We recommend that you use the steps provided in the "Windows Server Active Directory
Rights Management Services Step-by-Step Guide" before completing the steps in this
guide. Step-by-step guides are not necessarily meant to be used to deploy
Windows Server® features without additional documentation and should be used with
discretion as a stand-alone document.
Upon completion of this Step-by-Step guide, you will have a working AD RMS test lab
environment configured for use in an extranet scenario. You can then test and verify
AD RMS extranet functionality through the simple task of restricting permissions on a
Microsoft Office Word 2007 document and attempting to open this document from a client
computer that is not part of your organization's network.
The test environment described in this guide includes six computers that use the
following operating systems, applications, and services:
Note
You will also need a USB flash drive or another medium to copy the files from the
AD RMS-enabled client to the AD RMS-enabled extranet client.
ADRMS-SRV Windows Server 2008 AD RMS, Internet

Information Services
(IIS) 7.0, Message Queuing,
and Windows Internal
Database
CPANDL-DC Windows Server 2003 with Active Directory, Domain

7
ADRMS-DB Windows Server 2003 with SP1 Microsoft SQL

Server™ 2005 Standard
Edition
ISA-SRV Windows Server 2003 with SP1 Microsoft ISA Server 2006
Standard Edition
Note
This computer must
have two network
adapters so that ISA
Server 2006 can
distinguish between the
public and private IP
addresses.
ADRMS-CLNT Windows Vista™ Microsoft Office Word 2007

Enterprise Edition
ADRMS-EXCLNT Windows Vista Microsoft Office Word 2007

Enterprise Edition
The first five computers in the table form a private intranet and are connected through a
common hub or Layer 2 switch. Additionally, ISA-SRV has a second network adapter
installed that is exposed to the Internet. This allows for the ISA Server to accept requests
from the Internet and forward them to the AD RMS server. ADRMS-EXCLNT is a
computer that is not part of the same network. This configuration can be emulated in a
virtual server environment if desired.
This step-by-step exercise uses private addresses throughout the test lab configuration.
The private network ID 10.0.0.0/24 is used for the intranet. The domain controller is
named CPANDL-DC for the domain named cpandl.com. ADRMS-EXCLNT is configured
with an IP address of 10.0.100.2/24 in order to simulate a client computer on an extranet.
The following figure shows the configuration of the test environment:
8
Note
In a production environment, the ISA server's external address would be an IP
address available to the Internet, giving extranet users the ability to consume
rights-protected content.
Step 1: Configuring AD RMS to Work in

an Extranet
In addition to the steps outlined in the "Windows Server Active Directory Rights
Management Services Step-by-Step Guide," you must also do the following:
• Configure the extranet cluster URL in the Active Directory Rights Management
Services console.
• Export the server authentication certificate, including the private key, on ADRMS-
SRV. This will be imported into the Personal certificate store on the ISA server (ISA-
SRV).
In order for users who are not connected to your organization's internal network to
consume rights-protected content, you must configure the AD RMS extranet cluster
URLs. These URLs are included in the AD RMS client licensor certificate and published
with all rights-protected content. These URLs should be an address that is available to all
computers on the Internet.
9
Note
You must configure the extranet cluster URLs before you can rights-protect
content. If you already have rights-protected content, the AD RMS-enabled client
must download a new client licensor certificate that includes the extranet cluster
URL.
Configuring the extranet cluster URLs is done through the Active Directory Rights
Management Services console. You should follow these steps to accomplish this task:
To configure the AD RMS extranet cluster URLs

1. Log on to ADRMS-SRV as CPANDL\ADRMSADMIN.
2. Click Start, point to Administrative Tools, and then click Active Directory
Rights Management Services.
3. If the User Account Control dialog box appears, confirm that the action it
displays is what you want, and then click Continue.
4. Right-click ADRMS-SRV (Local), and then click Properties.

5. Click the Cluster URLs tab, and then select the Extranet URLs check box.
6. In the Licensing box, select https://, and then type adrms-srv.cpandl.com.
7. In the Certification box, select https://, and then type adrms-srv.cpandl.com.
8. Click OK.
Next, export the ADRMS-SRV server authentication certificate with its private key. This is
required so that ISA-SRV can pass HTTPS requests from ADRMS-EXCLNT to the
AD RMS cluster.
To export the ADRMS-SRV server authentication certificate with private key

1. Click Start, type mmc.exe, and then press ENTER.
2. If the User Account Control dialog box appears, confirm that the action it
displays is what you want, and then click Continue.
3. Click File, and then click Add/Remove Snap-in.

4. Click Certificates, and then click Add.
5. Select the Computer account option, and then click Next.
6. Click Finish, and then click OK.
7. Expand Certificates (Local Computer), expand Trusted Root Certification
10
Authorities, and then click Certificates in the console tree.

8. Right-click ADRMS-SRV.cpandl.com, point to All Tasks, and then click Export.
9. On the Welcome to the Certificate Export Wizard page, click Next.
10. Select the Yes, export the private key option, and then click Next.
11. On the Export File Format page, click Next, accepting the default selections.
12. In the Password and Type and confirm password boxes, type the same strong
password, and then click Next.
13. In the File name box, type \\adrms-db\public\adrms-srv_with_key.pfx, and
then click Next.
14. Click Finish.

15. Click OK, confirming that the export was successful.
Step 2: Installing and Configuring ISA-

SRV
ISA Server 2006 Standard Edition is an integrated edge security gateway that can be
used with AD RMS to restrict Internet access to the AD RMS cluster. The ISA server
handles all requests from the Internet to the AD RMS extranet cluster URLs and passes
them to the AD RMS cluster, when necessary.
To install and configure ISA Server 2006 Standard Edition to work with AD RMS, you
must complete the following steps:
• Configure the ISA Server (ISA-SRV)

• Publish AD RMS cluster to extranet
Configure the ISA Server (ISA-SRV)

First, install Windows Server 2003 on a stand-alone server.
To install Windows Server 2003, Standard Edition

1. Start your computer by using the Windows Server 2003 product CD.
11
2. Follow the instructions that appear on your computer screen, and when prompted
for a computer name, type ISA-SRV.
Next, configure TCP/IP properties so that ISA-SRV has a static IP address of 10.0.0.5
and preferred DNS server with IP address 10.0.0.1 on the first network adapter. On the
second network adapter, use 10.0.100.1 as the IP address.
To configure TCP/IP properties on ISA-SRV

1. Log on to ISA-SRV as a member of the local Administrators group.
2. Click Start, point to Control Panel, point to Network Connections, click Local
Area Connection, and then click Properties.
3. On the General tab, click Internet Protocol (TCP/IP), and then click Properties.
4. Click the Use the following IP address option. In the IP address box, type
10.0.0.5. In the Subnet mask box, type 255.255.255.0. In the Preferred DNS
server box, type 10.0.0.1.
5. Click OK, and then click Close to close the Local Area Connection Properties
dialog box.
6. Click Start, point to Control Panel, point to Network Connections, click Local
Area Connection 2, and then click Properties.
8. Click the Use the following IP address option. In the IP address box, type
10.0.100.1. In the Subnet mask box, type 255.255.255.0.
9. Click OK, and then click Close to close the Local Area Connection 2
Properties dialog box.
Next, join ISA-SRV to the cpandl.com domain.
To join ISA-SRV to the cpandl.com domain

1. Click Start, right-click MyComputer, and then click Properties.
2. Click the Computer Name tab, and then click Change.
3. In the Computer Name Changes dialog box, select the Domain option, and
then type cpandl.com.
4. Click More, and type cpandl.com in Primary DNS suffix of this computer box.
5. Click OK, and then click OK again.
6. When a Computer Name Changes dialog box appears prompting you for
12
administrative credentials, provide the credentials for CPANDL\Administrator,

and then click OK.
7. When a Computer Name Changes dialog box appears welcoming you to the
cpandl.com domain, click OK.
8. When a Computer Name Changes dialog box appears telling you that the
computer must be restarted, click OK, and then click Close.
9. Click Restart Now.

Next, import the server authentication certificate that contains the private key into the
Trusted Certification Authorities store on ISA-SRV.
To import the server authentication certificate to the ISA-SRV computer

1. Log on to ISA-SRV with as a member of the local Administrators group.
2. Click Start, click Run, type mmc.exe, and then press ENTER.
3. Click File, and then click Add/Remote Snap-in.

4. Click Add, select Certificates, and then click Add.
5. Select the Computer Account option, click Next, and then click Finish.
6. Click Close, and then click OK.

7. Expand Certificates, and then expand Personal.
8. Right-click Certificates in the console tree, point to All Tasks, and then click
Import.
9. On the Welcome to the Certificate Import wizard page, click Next.
10. In the File name box, type \\adrms-db\public\adrms-srv_with_key.pfx, click
OK, and then click Next.
11. Type the password used to export the certificate, and then click Next.
12. Click Next, and then click Finish.
13. Click OK confirming that the import was successful.

14. Close the Certificates console.
Finally, install ISA Server 2006 Standard Edition.
To install ISA Server 2006 Standard Edition

1. Log on to ISA-SRV as a member of the local Administrators group.
13
2. Insert the ISA Server 2006 Standard Edition product CD.

3. Click Install ISA Server 2006.
4. On the Welcome to the Installation Wizard for Microsoft ISA Server 2006
page, click Next.
5. Select the I accept the terms in the license agreement option, and then click
Next.
6. Type your ISA Server product key in the Product Serial Number box, and then
click Next.
7. Select the Typical option, and then click Next.
8. Click Add, click Add Adapter, select the Local Area Connection check box,
click OK, and then click OK again.
9. Click Next three times, and then click Install.
10. When the installation is complete, click Finish.
11. Click OK. Read the information if desired, and then close Internet Explorer.
12. Click Exit to close Microsoft ISA Server 2006 Setup.
Publish AD RMS cluster to extranet

ISA Server 2006 Standard Edition requires that a Web listener be configured for a
specified port. In this guide, you use TCP port 443 (SSL) in order to help make data
transmission secure between the clients and ISA server. In this section, you publish the
AD RMS Web site through the ISA server. This involves publishing the AD RMS extranet
cluster URL to this ISA Server and then allowing the ISA server to pass the user
credentials directly to the AD RMS server. Because a self-signed certificate is used for
the AD RMS cluster in this guide, you must move it from the Personal certificate store to
the Trusted Certification Root Authorities store.
First, publish the AD RMS cluster on ISA-SRV.
To publish AD RMS in ISA Server 2006 Standard Edition

1. Click Start, point to All Programs, point to Microsoft ISA Server, and then click
ISA Server Management.
2. Expand ISA-SRV, and then click Firewall Policy.

3. Click the Tasks tab, and then click Publish Web Sites.
14
4. In the Web publishing rule name box, type AD RMS Extranet, and then click
Next.
5. Click Next twice accepting the default selections.
6. Select the Use SSL to connect to the published Web server or server farm
option, and then click Next.
7. In the Internal Site Name box, type adrms-srv.cpandl.com.
8. Select the Use a computer name of IP address to connect to the published

server check box, type 10.0.0.2 in the Computer name or IP address box, and
then click Next.
9. In the Path (optional) box, type /*, select the Forward the original host header
instead of the actual one specified in the Internal site name field on the
previous page check box, and then click Next.
10. In the Public name box, type adrms-srv.cpandl.com, and then click Next.
11. Click New to create a new Web listener.
12. In the Web listener name box, type HTTPS Port 443, and then click Next.
13. Select the Require SSL secured connections with clients option, and then
click Next.
14. Select the External check box, and then click Next.
15. Select the Use a single certificate for this Web listener option, and then click
Select Certificate.
16. Click the ADRMS-SRV.cpandl.com certificate, click Select, and then click Next.
17. In the Select how clients will provide credentials to ISA Server box, select
No Authentication, click Next, and then click Next again.
18. Click Finish to close the New Web Listener Wizard.
19. Click Next.

20. Click No delegation, but client may authenticate directly, and then click Next.
21. Click Next to apply this Web publishing rule to all users.
22. Click Finish.

23. Click Apply to save changes and update your configuration, and then click OK.
Finally, move the ADRMS-SRV server authentication certificate from the Personal
certificate store to the Trusted Root Certification Authorities store:
15
To move the ADRMS-SRV server authentication certificate

1. Click Start, and then click Run.
2. Type mmc.exe, and then click OK.
3. Click File, and then click Add/Remove Snap-in.

4. Click Add, click Certificates, click Add, select the Computer account option,
and then click Next.
5. Click Finish, click Close, and then click OK.

6. Expand Certificates (Local computer), expand Personal, and then expand
Trusted Root Certification Authorities.
7. Click Certificates under Personal in the console tree.

8. Select the ADRMS-SRV.cpandl.com certificate in the details pane and drag it to
the Certificates folder under Trusted Root Certification Authorities.
9. Close the Certificates console.
Step 3: Configuring AD RMS Extranet

Client
To configure the AD RMS extranet client computer (ADRMS-EXCLNT), you must install
Windows Vista, configure TCP/IP properties, create an entry in the local HOSTS file,
import the ADRMS-SRV server authentication certificate, and then install an AD RMS
enabled application. In this example, Microsoft Office Word 2007 is installed on ADRMS-
EXCLNT.
To install Windows Vista

1. Start your computer using the Windows Vista product CD.
2. Follow the instructions that appear on your screen, and when prompted for a
computer name, type ADRMS-EXCLNT.
Next, configure TCP/IP properties so that ADRMS-EXCLNT has a static IP address of
10.0.100.2.
16
To configure TCP/IP properties

1. Click Start, click Control Panel, click Network and Internet, double-click
Network and Sharing Center, click Manage Network Connections in the left
pane, right-click Local Area Connection, and then click Properties.
2. On the Networking tab, click Internet Protocol Version 4 (TCP/IPv4), and then
click Properties.
3. Select the Use the following IP address option. In IP address, type 10.0.100.2,
in Subnet mask, type 255.255.255.0.
4. Click OK, and then click Close to close the Local Area Connection Properties
dialog box.
5. Close the other open windows and return to the desktop.
In this guide, a test environment without an external DNS server is used. In order for the
extranet cluster URLs to resolve to its appropriate IP address, you must create a manual
entry in the HOSTS file that points to ISA-SRV.
Note
In a production environment, this step is not required because the extranet client
computer's Internet Service Provider will handle the DNS resolution.
To create an entry in the HOSTS file for AD RMS extranet cluster URL
1. Log on to ADRMS-EXCLNT as a member of the local Administrators group.
2. Click Start, point to All Programs, click Accessories, and then click Notepad.
3. Within Notepad, click File, and then click Open.
4. Navigate to C:\windows\System32\drivers\etc\HOSTS, and then click Open.
Note
To show the HOSTS file, when you get to the etc folder you must select
All Files (above the Open button).
5. On a new line at the bottom of the file, type 10.0.100.1 adrms-srv.cpandl.com.
6. Save and close the HOSTS file.

Next, import the ADRMS-SRV server authentication certificate into the Trusted Root
Certification store on ADRMS-EXCNT. This is only required when using self-signed
certificates. In a production environment, the certificate should be trusted by a
certification authority.
17
To import the server authentication certificate to the ADRMS-EXCLNT

computer
1. Log on to ADRMS-EXCLNT with a user account that is a member of the local
Administrators group.
2. Click Start, point to All Programs, and then click Internet Explorer.
3. In the Address bar, type https://adrms-

srv.cpandl.com/_wmcs/licensing/license.asmx, and then press ENTER.
4. On the Certificate Error: Navigation Blocked Web page, click Continue to
this website (not recommended).
5. In the User name box, type CPANDL\srailson. In the Password box, type the
password for Stuart Railson, and then click OK.
6. In the Address Bar, click Certificate Error, and then click View Certificates.
7. On the Certificate Information page, click Install Certificate.
8. On the Welcome to the Certificate Import Wizard page, click Next.
9. Select the Place all certificates in the following store option, click Browse,
click Trusted Root Certification Authorities, and then click OK.
11. Click Yes, accepting the security warning. This only happens because self-
signed certificates are used.
12. Click OK, confirming that the certificate import was successful.
13. Click OK to close the Certificate Information window.

14. Close Internet Explorer.
Finally, install Microsoft Office Word 2007 Enterprise.
To install Microsoft Office Word 2007 Enterprise

1. Double-click setup.exe from the Microsoft Office 2007 Enterprise product CD.
2. Click Customize as the installation type, set the installation type to Not
Available for all applications except Microsoft Office Word 2007 Enterprise, and
then click Install Now. This might take several minutes to complete.
18
Important
Only the Ultimate, Professional Plus, and Enterprise editions of Microsoft
Office 2007 allow you to create rights-protected content. All editions will allow
you to consume rights-protected content.

using ADRMS-CLNT
To verify the functionality of the AD RMS deployment, you will log on to ADRMS-CLNT as
Nicole Holliday and then restrict permissions on a Microsoft Word 2007 document so that
Stuart Railson is only able to read the document but unable to change, print, or copy. You
will then copy this document to a removable device (for example, a USB flash drive) and
log on to a client computer that is not part of the organizational network, such as a home
computer. In this example, ADRMS-EXCLNT serves as the home computer. After the file
is copied to the USB flash drive, Stuart Railson logs on to the extranet client computer
(ADRMS-EXCLNT) and verifies that he is able to open the rights-protected document
from the USB flash drive.
Note
A USB flash drive is not required in this scenario. Any means of getting the
document to the extranet client computer will work, such as attaching the
document to an e-mail message and sending it to Stuart. In that example, Stuart
would then open the document contained in the e-mail message on the extranet
client computer.
Use the following steps to restrict permissions on a Microsoft Word document:
To restrict permissions on a Microsoft Word document

1. Log on to ADRMS-CLNT as Nicole Holliday (cpandl\nhollida).
2. Click Start, point to All Programs, click Microsoft Office, and then click
Microsoft Office Word 2007.
3. Type This is a test of AD RMS Extranet functionality.into the blank document
page, click the Microsoft Office Button, point to Prepare, point to Restrict
Permission, and then click Restricted Access.
4. Select the Restrict permission to this document check box.
5. In the Read box, type srailson@cpandl.com, and then click OK to close the
19
Permission dialog box.

6. Click the Microsoft Office Button, click Save As, and then save the file as
ADRMS-TST.
7. Copy ADRMS-TST.docx to a USB flash drive.

Finally, open the document, ADRMS-TST.docx, on ADRMS-EXCLNT from the USB flash
drive.

1. Log on to ADRMS-EXCLNT with the local user account that you want to use for
consuming the rights-protected document.
Caution
Once this document has been consumed, any other user who logs on to
the computer with the same user account will also be able to consume
the document.
2. Insert the USB flash drive, and then double-click the ADRMS-TST.docx file.
3. In the User name box, type cpandl\srailson. In the Password box, type the
password for Stuart Railson, and then click OK.
The following message appears: "Permission to this document is currently
srv.cpandl.com/_wmcs/licensing to verify your credentials and download
your permissions."
4. Click OK.
The following message appears: "You are attempting to send information to

an Internet site (https://adrms-srv.cpandl.com) that is not in your Local,
Intranet, or Trusted zones. This could pose a security risk. Do you want to
send the information anyway?"
5. Click Yes.
The following message appears: "Verifying your credentials for opening
content with restricted permissions…".
6. When the document opens, click the Microsoft Office Button. Notice that the
Print option is not available.
7. Click View Permission in the message bar. You can see that
20
srailson@cpandl.com (Stuart Railson) has been restricted to so that he can only

read the document.
8. Click OK to close the My Permissions dialog box, and then close Microsoft
Word.
You have successfully deployed and demonstrated the functionality of AD RMS in an
extranet, using the simple scenario of applying restricted permissions to a Microsoft
Word 2007 document. You can also use this deployment to explore some of the
additional capabilities of AD RMS through additional configuration and testing.
Management Services with Microsoft Office
SharePoint Server 2007 Step-By-Step Guide
Published: September 2007
Author: Brian Lich
Abstract
This step-by-step guide provides instructions for deploying Microsoft Office SharePoint Server
2007 in an Active Directory Rights Management Services (AD RMS) environment. It includes the
necessary information for installing and configuring Office SharePoint Server 2007 in the newly
created AD RMS infrastructure, and verifying that Office SharePoint Server 2007 documents can
be rights-protected and consumed. In the appendix of this guide, you can also configure Office
SharePoint Server 2007 to work with Active Directory Federation Services (AD°FS) and AD RMS.
1
Copyright Information
substantially prior to final commercial release, and is the confidential and proprietary information
of Microsoft Corporation. It is disclosed pursuant to a non-disclosure agreement between the
recipient and Microsoft. This document is provided for informational purposes only and Microsoft
makes no warranties, either express or implied, in this document. Information in this document,
including URL and other Internet Web site references, is subject to change without notice. The
entire risk of the use or the results from the use of this document remains with the user. Unless
otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted herein are fictitious, and no association
with any real company, organization, product, domain name, e-mail address, logo, person, place,
or event is intended or should be inferred. Complying with all applicable copyright laws is the
responsibility of the user. Without limiting the rights under copyright, no part of this document may
be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by
any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose,
without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
Microsoft, Active Directory, MS-DOS, SharePoint, Vista, Windows, Windows NT, and
Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the
2
Contents
Deploying Active Directory Rights Management Services with Microsoft Office SharePoint Server
2007 Step-By-Step Guide ............................................................................................................ 5
About this Guide ........................................................................................................................... 5
What This Guide Does Not Provide .......................................................................................... 6
Deploying AD RMS in a Test Environment .................................................................................. 6
Step 1: Installing and Configuring SPS-SRV................................................................................... 7

Configure the Office SharePoint Server (SPS-SRV) ................................................................ 8
Install Office SharePoint Server 2007..................................................................................... 10
Step 2: Configuring AD RMS to Work with SPS-SRV ................................................................... 11
Step 3: Verifying AD RMS Functionality using ADRMS-CLNT ..................................................... 14
Appendix A: Configuring Active Directory Federation Services to work with Office SharePoint
Server 2007 ................................................................................................................................ 16
About this Appendix ................................................................................................................... 16
Configuring AD FS to work with Office SharePoint Server 2007 in a Test Environment ........... 16
Step 1: Setting up the infrastructure........................................................................................... 19
Step 2: Configuring Office SharePoint 2007 to work with AD FS .............................................. 21
Step 3: Verifying AD RMS functionality with Office SharePoint Server 2007 and AD FS. ........ 27
3
Management Services with Microsoft Office
SharePoint Server 2007 Step-By-Step Guide
About this Guide

This step-by-step guide walks you through the process of deploying Active Directory Rights
Management Services (AD RMS) and Microsoft Office SharePoint Server 2007 together in a test
environment. Specifically, this guide shows you how to add an Office SharePoint Server 2007 to
an existing AD RMS environment.
Important
Microsoft Windows SharePoint Services 3.0 does not have the Microsoft® Office
protector files that are required to automatically rights-protect a document when it is
uploaded. You must use Office SharePoint Server 2007 to do this.
This guide assumes that you previously completed the Active Directory Rights Management
Services Step-by-Step Guide, and that you have already deployed the following components:
• One Active Directory domain controller
• An AD RMS server
• An AD RMS database server
• An AD RMS-enabled client
In this guide, you will create a test deployment that includes an Office SharePoint Server 2007
server.
Office SharePoint Server 2007 provides an easy way to collaborate on documents by posting
them to an Office SharePoint Server 2007 site so that they can be accessed over the corporate
network. The goal of integrating an Office SharePoint Server 2007 deployment with an AD RMS
infrastructure is to be able to protect documents that are downloaded from the Office SharePoint
Server 2007 server by users of any given organization.
Note
Integrating Office SharePoint Server 2007 with AD RMS does not protect the documents
while they are on the server. When a document is uploaded to an Office SharePoint
Server 2007 site, the server removes all protection until a download request is received
by the Office SharePoint Server 2007 server. At this time, the Office SharePoint Server
2007 server applies the appropriate restrictions to the document before it is downloaded
to the client computer.
5
• An overview of AD RMS. For more information about the advantages that AD RMS can bring
to your organization, see http://go.microsoft.com/fwlink/?LinkId=84726.
• Guidance for setting up and configuring AD RMS in a production environment.
• Guidance for integrating Office SharePoint Server 2007 with AD RMS in a production
environment.
• Complete technical reference for AD RMS.
• Complete information about Office SharePoint Server 2007. For more information, see
http://go.microsoft.com/fwlink/?LinkId=74460.

We recommend that you use the steps provided in the "Windows Server Active Directory Rights
Management Services Step-by-Step Guide" before completing the steps in this guide. Step-by-
step guides are not necessarily meant to be used to deploy Microsoft products without additional
documentation and should be used with discretion as a stand-alone document.
Upon completion of this step-by-step guide, you will have a working AD RMS infrastructure
integrated with Office SharePoint Server 2007. You can then test AD RMS and Office SharePoint
Server 2007 functionality as follows:
• Create a Microsoft Office Word 2007 document in the CPANDL domain.
• Upload this document to the Office SharePoint Server 2007 document library.
• Have an authorized user in the CPANDL domain open and work with the document.
The test environment described in this guide includes five computers connected to a private
network and using a clean installation of the following operating systems, applications, and
services:
CPANDL-DC Windows Server® 2003 with Active Directory, Domain

ADRMS-SRV Windows Server® 2008 AD RMS, Internet Information

Services (IIS) 7.0, and
Message Queuing
ADRMS-DB Windows Server 2003 with SP1 Microsoft SQL Server™ 2005
with Service Pack 2 (SP2)
SPS-SRV Windows Server 2003 R2 Office SharePoint Server
6
Standard Edition. Windows 2007
Server 2003 R2 must be used if
federated identity support with
Office SharePoint Server 2007 is
required. Otherwise,
Windows Server 2003 with SP1
can be used.
ADRMS-CLNT Windows Vista® Microsoft Office Word 2007

Enterprise Edition
Note
Before installing and configuring the components in this guide, you should verify that your
hardware meets the minimum requirements for AD RMS
The computers form a private intranet and are connected through a common hub or Layer 2
switch. This configuration can be emulated in a virtual server environment if desired. This step-
by-step exercise uses private addresses throughout the test lab configuration. The private
network ID 10.0.0.0/24 is used for the intranet. The domain controller is named CPANDL-DC for
the domain named cpandl.com. The following figure shows the configuration of the test
environment:
Step 1: Installing and Configuring SPS-SRV

To prepare your AD RMS test environment in the CPANDL domain, you must complete the
following tasks:
7
• Configure the Office SharePoint Server (SPS-SRV)
• Install Office SharePoint Server 2007
Use the following table as a reference when setting up the appropriate computer name, operating
system, and network settings that are required to complete the steps in this guide.
Important
Before you configure your computers with static Internet Protocol (IP) addresses, we
recommend that you first complete Windows product activation while each of your
computers still has Internet connectivity. You should also install any available critical
security updates from Windows Update (http://go.microsoft.com/fwlink/?LinkID=47370).
Computer name Operating system requirement IP settings DNS settings
SPS-SRV Windows Server 2003 R2, IP address: 10.0.0.1

Standard Edition 10.0.0.6
Important Subnet mask:
In order to use Active 255.255.255.0
Directory Federation
Services (AD FS) with
Office SharePoint
Server 2007, you
must install Windows
Server 2003 R2 with
Service Pack 2 (SP2).
Configure the Office SharePoint Server (SPS-SRV)

To configure the Office SharePoint Server 2007 server SPS-SRV, you must:
1. Install Windows Server 2003 R2 Standard Edition.
2. Configure TCP/IP properties.
3. Join the computer to the cpandl.com domain.
4. Install the Rights Management Services (RMS) client with SP2.
To install Windows Server 2003 R2 Standard Edition

1. Start your computer by using the Windows Server 2003 R2 Standard Edition product CD.
2. When prompted for the installation type, choose Custom Installation.
3. When prompted for a computer name, type SPS-SRV.
4. Follow the rest of the instructions that appear on your screen to finish the installation.
8
Next, configure TCP/IP properties so that SPS-SRV has a static IP address of 10.0.0.6. In
addition, configure the Domain Name System (DNS) Server service by using the IP address of
CPANDL-DC (10.0.0.1).
To configure TCP/IP Properties

1. Log on to SPS-SRV with the SPS-SRV\Administrator account or another user account in
the local Administrators group.
2. Click Start, point to Control Panel, point to Network Connections, double-click Local
Area Connection, and then click Properties.
4. Select the Use the following IP address option. In the IP address box, type 10.0.0.6. In
Subnet mask box, type 255.255.255.0.
5. Select the Use the following DNS server addresses option. In the Preferred DNS
server box, type 10.0.0.1.
6. Click OK, and then click OK to close the Local Area Connection Properties dialog box.
Close the Local Area Connection Status dialog box.
Next, join SPS-SRV to the cpandl.com domain.
To join SPS-SRV to the cpandl.com domain

1. Click Start, right-click My Computer, and then click Properties.
2. Click Computer Name tab, and then click Change.
3. In the Computer Name Changes dialog box, click Domain, and then type cpandl.com.
5. Click OK twice.
6. When a Computer Name Changes dialog box appears prompting you for administrative
credentials, provide the credentials for CPANDL\Administrator, and then click OK.
8. When a Computer Name Changes dialog box appears telling you that the computer
must be restarted, click OK, and then click Close.
9. Click Yes to restart the computer.
Finally, install the RMS client with SP2 on SPS-SRV.
To install the RMS client with SP2

1. Download the RMS client from http://go.microsoft.com/fwlink/?LinkId=67736. If you are
using a 64-bit version Windows Server 2003, download the 64-bit version of the RMS
9
client from http://go.microsoft.com/fwlink/?LinkId=67935.
2. Double-click WindowsRightsManagementServicesSP2-KB917275-Client-ENU.exe to
start the installation.
3. Click Next.
4. Select the I agree option to accept the End User License Agreement, and then click Next
twice to start the installation.
5. Click Close to finish the installation.
Note
If you are using a self-signed certificate for your AD RMS cluster, you must import it into
the Trusted Certification Authorities certificate store on SPS-SRV before you can
consume rights-protected content.
Install Office SharePoint Server 2007

To install Office SharePoint Server 2007, you must complete the following steps in the following
order:
1. Add the Application Server role to SPS-SRV.
2. Install Microsoft .NET Framework 3.0.
3. Install Office SharePoint Server 2007.
Office SharePoint Server 2007 uses the Application Server role, which contains IIS and
ASP.NET, to host Office SharePoint Server 2007 document libraries. To install the Application
Server role, you must complete the following steps:
To add the Application Server role

1. Click Start, point to All Programs, point to Administrative Tools, and then click
Manage Your Server.
2. Click Add or remove a role.
3. On the Preliminary Steps page of the Configure your Server Wizard, click Next.
4. Click Application Server (IIS, ASP.NET), and then click Next.
5. Select the Enable ASP.NET check box, and then click Next twice.
Note
You will be asked for the Windows Server 2003 product CD in order to complete
the installation of the Application Server role.
6. Click Finish to complete the installation.
Next, install the .NET Framework 3.0. Office SharePoint Server 2007 requires the Windows
Workflow Foundation, which has been integrated into .NET Framework 3.0.
10
To install .NET Framework 3.0
1. Download Microsoft .NET Framework 3.0 from
2. Double-click dotnetfx3setup.exe, and then click Run in the Open File - Security
Warning dialog box.
3. Click the I have read and ACCEPT the terms of the License Agreement option, and
then click Install.
4. Click Exit to complete the installation.
Next, install Office SharePoint Server 2007.
To install Office SharePoint Server 2007

1. Double-click setup.exe from the Office SharePoint Server 2007 product CD.
2. Enter your Product Key, and then click Continue.
3. Select the I accept the terms of this agreement check box, and then click Continue.
4. Click Basic.
5. After installation has completed, select the Run the SharePoint Products and
Technologies Configuration Wizard now check box, and then click Close. The
installation might take 10 minutes to complete.
6. On the Welcome to theSharePoint Products and Technologies page, click Next. Click
Yes in the message confirming that the SharePoint services should be restarted. Office
SharePoint Server 2007 will also be configured at this time.
Step 2: Configuring AD RMS to Work with

SPS-SRV
After Office SharePoint Server 2007 has been installed, there are several tasks that must be
completed to integrate Office SharePoint Server 2007 with AD RMS:
• Add the Office SharePoint Server 2007 site to the Local Intranet Internet Explorer zone.
• Add three user accounts, CPANDL\Administrator, Nicole Holliday, and Stuart Railson, to the
SharePoint site.
• Add the Office SharePoint Server 2007 server to the AD RMS server certification pipeline.
• Enable Information Rights Management in Office SharePoint Server 2007.
11
• Restrict permissions by using AD RMS.
First, add the Office SharePoint Server 2007 site to the Internet Explorer Local Intranet zone on
the Office SharePoint Server 2007 computer.
To add SPS-SRV to Local Intranet

1. Log on to SPS-SRV as cpandl\administrator.
2. Click Start, point to Control Panel, and then click Internet Options.
3. Click the Security tab, click Local Intranet, and then click the Sites button.
4. Type http://SPS-SRV, and then click Add.
5. Click Close, and then click OK.
Next, give Nicole Holliday and Stuart Railson access to the SharePoint site so that the Office
SharePoint Server 2007 integration with AD RMS can be verified later in this guide:
To add Nicole Holliday and Stuart Railson to the SharePoint site

2. Type http://SPS-SRV in the address bar, and then click Go. This will open the default
Office SharePoint Server 2007 site that was created during installation.
3. Click Site Actions, point to Site Settings, and then click People and Groups.
4. Click New, and then click Add Users.
5. Type nhollida@cpandl.com;srailson@cpandl.com in the Users/Groups box, and then
click OK. A list of users who have permission to use the SharePoint site is displayed.
Next, add the Office SharePoint Server 2007 server and AD RMS Service Group to the AD RMS
cluster server certification pipeline.
Important
By default, the AD RMS cluster server certification pipeline ACL is configured to allow
only the local System account. You must add the permissions in order for Office
SharePoint Server 2007 to integrate with AD RMS.
To add SPS-SRV to the AD RMS Certification Pipeline

1. Log on to ADRMS-SRV as CPANDL\Administrator.
2. Click Start, and then click Computer.
3. Navigate to C:\Inetpub\wwwroot\_wmcs\Certification.
4. Right-click ServerCertification.asmx, click Properties, and then click the Security tab.
5. Click Advanced, click Edit, select the Include inheritable permissions from this
object's parent check box, and then click OK two times.
12
6. Click Edit, and then click Add.
7. Click Object Types, select the Computers check box, and then click OK.
8. Type SPS-SRV, and then click OK.
9. Click OK to close the ServerCertification.asmx Properties sheet.
By default the Read & execute and the Read permissions are configured for the SPS-
SRV computer account object and all other accounts inherited from the parent folder.
10. Click Start, and then click Command Prompt.
11. Type iisreset, and then press ENTER.
Once the AD RMS cluster certification pipeline has been allowed so that SPS-SRV can
communicate with it, you must configure Office SharePoint Server 2007 to use the AD RMS
cluster:
To enable Information Rights Management in Office SharePoint Server 2007

1. Log on to SPS-SRV as CPANDL\administrator.
2. Click Start, point to Administrative Tools, and then click SharePoint 3.0 Central
Administration.
3. Click Operations, and then click Information Rights Management.
4. Select the Use the default RMS server specified in Active Directory option, and then
click OK.
Create an Office SharePoint Server 2007 permission policy on the default document library. This
permission policy will be used to restrict the ability to print any documents that are uploaded to
the document library:
To restrict permissions using AD RMS

1. Log on as cpandl\Administrator.
3. Type http://SPS-SRV in the address bar, and then click Go.
4. Click Document Center, click Documents, click Settings, and then click Document
Library Settings.
5. Under the Permissions and Management heading, click Information Rights
Management.
6. Select the Restrict permission to documents in this library on download check box.
7. Type CPANDL Protected in the Permissions policy title box.
8. Type Restrict CPANDL employees from printing in the Permission policy
description box.
9. Click OK.
13
Note
Office SharePoint Server 2007 will automatically apply AD RMS rights to the document
when it is downloaded from the Office SharePoint Server 2007 site. These rights are
determined by the Office SharePoint Server 2007 group membership for that site. For
example, a user who is in the Visitors Office SharePoint Server 2007 group will not be
able to modify the document when it is downloaded from the Office SharePoint Server
2007 site.
Step 3: Verifying AD RMS Functionality using

ADRMS-CLNT
To verify the functionality of the AD RMS deployment, you log on as Nicole Holliday, create a new
Microsoft Word 2007 document, and upload it to the Office SharePoint Server 2007 site into a
rights-enabled document library configured such that users who download the document will not
be able to print it. You then log on as Stuart Railson, download the document from the Office
SharePoint Server 2007 site and verify that the ability to print the document has been restricted.
Before you can consume rights-protected content, you must add SPS-SRV to the Local Intranet
security zone.
To add SPS-SRV to Local Intranet security zone

1. Log on to ADRMS-CLNT as Nicole Holliday (CPANDL\nhollida).
2. Click Start, click All Programs, and then click Internet Explorer.
3. Click Tools, and then click Internet Options.
4. Click the Security tab, click Local intranet, and then click Sites.
5. Click Advanced.
6. In the Add this website to the zone, type http://sps-srv, and then click Add.
7. Click close.
8. Repeat steps 1–7 for Stuart Railson (CPANDL\srailson).
Next, log on a Nicole Holliday and create a Microsoft Word 2007 document and upload it to the
Office SharePoint Server 2007 site.
To create and upload a Microsoft Word document for testing

1. Click Start, point to All Programs, point to Microsoft Office, and then click Microsoft
Office Word 2007.
2. Type This document is read-only. You cannot print it. in the new document, click the
Microsoft Office Button, click Save As, and then save the file as ADRMS-TST.docx to
14
a location on ADRMS-CLNT. This document will be uploaded to the Office SharePoint
Server 2007 document library.
Note
Since Nicole Holliday is the author of this document, she will have full rights to
the document, regardless of the AD RMS rights that are applied to it.
3. Close Microsoft Office Word 2007.
5. Type http://SPS-SRV/in the address bar, and then click Go.
6. Click Document Center, and then click Documents.
7. Click Upload, click Upload Document, click Browse to locate and select ADRMS-TST,
and then click Open.
8. Click OK to upload the file, and then click Check In.
By uploading the document into this library, the document receives the restrictions set on
the library.
Finally, log on as Stuart Railson and open the document from the Office SharePoint Server 2007
site.
To open a protected document

1. Log on to ADRMS-CLNT as Stuart Railson (CPANDL\srailson).
3. Type http://SPS-SRV/ in the address bar, and then click Go.
5. Click ADRMS-TST, and then click OK to open the document as Read Only.
6. The following message will appear: "Permission to this document is currently
srv.cpandl.com/_wmcs/licensing to verify your credentials and download your
permission."
7. Click OK.
8. The following message will appear: "Verifying your credentials for opening content
with restricted permissions".
9. Click OK in the full screen reading view message, and then click Close to close the full
screen reading view.
10. Click the Microsoft Office button. The Print command is disabled.
15
You have successfully deployed, integrated, and demonstrated the functionality of AD RMS and
Office SharePoint Server 2007, using the simple scenario of uploading a Microsoft Office
Word 2007 document to an Office SharePoint Server 2007 site. You can also use this
deployment to explore some of the additional capabilities of AD RMS through additional
configuration and testing.
Appendix A: Configuring Active Directory

Federation Services to work with Office
SharePoint Server 2007
About this Appendix

This appendix walks you through the process of configuring Active Directory Federation Services
(AD FS) and Microsoft Office SharePoint Server 2007 together in a test environment to consume
content that is rights-protected by Active Directory Rights Management Services (AD RMS).
Specifically, this guide shows you how to consume rights-protected content from an Office
SharePoint Server 2007 document library through a federated trust.
This guide assumes that you previously completed the following step-by-step guides:
• Windows Server Active Directory Rights Management Services Step-by-Step Guide
(http://go.microsoft.com/fwlink/?LinkId=54964)
• Using Identity Federation with Active Directory Rights Management Services Step-by-Step
Guide (http://go.microsoft.com/fwlink/?LinkId=72135)
• The first three steps of Deploying Active Directory Rights Management Services with
Microsoft Office SharePoint Server 2007 Step-By-Step Guide
In this appendix, you will configure the test environment configured in the step-by-step guides
referenced above to include federated support for Office SharePoint Server 2007.
Configuring AD FS to work with Office SharePoint

Server 2007 in a Test Environment
We recommend that you first use the steps provided in this appendix in a test lab environment.
Step-by-step guides are not necessarily meant to be used to deploy Windows Server features
without additional deployment documentation and should be used with discretion as a stand-
alone document.
16
Upon completion of this appendix, you will have a working AD RMS and Office SharePoint Server
2007 infrastructure with federation support. You can then test and verify the functionality as
follows:
• Create a document in the CPANDL.COM domain.
• Upload the document to a rights-protected document library.
• Have an authorized user in the TREYRESEARCH.NET domain open and work with the
document.
The test environment described in this guide include nine computers connected to a private
network and using the following operating systems, applications, and services:
CPANDL-DC Windows Server 2003 with Service Active Directory, Domain

TREY-DC Pack 1 (SP1) Name System (DNS)
Note
Domain controllers
running Windows 2000
Server with Service
Pack 4 can be used.
However, in this step-by-
step guide it is assumed
that you will be using
domain controllers running
Windows Server 2003 with
SP1.

Services (IIS) 7.0, Message
Queuing, and World Wide
Web Publishing Service
Standard Edition
SPS-SRV Windows Server 2003 R2 with AD FS claims-aware agent,

Server Pack 2 (SP2). Office SharePoint Server
2007
Important
Windows Server 2003 R2
with SP2 is required for
federation support to work
17
with Office SharePoint
Server 2007.

ADRMS-CLNT2 Enterprise Edition
ADFS-RESOURCE Windows Server® 2008 Enterprise AD FS, IIS

ADFS-ACCOUNT
The computers form two private intranets and are connected through a common hub or Layer 2
switch. This configuration can be emulated in a virtual server environment, if desired. This
appendix exercise uses private addresses throughout the test lab configuration. The private
network ID 10.0.0.0/24 is used for the intranet. The domain controller for the domain named
cpandl.com is CPANDL-DC and the domain controller for the domain name treyresearch.net is
TREY-DC. The following figure shows the configuration of the test environment:
18
Step 1: Setting up the infrastructure
The following steps should be taken to prepare the existing test infrastructure for configuring
AD FS with Office SharePoint Server 2007:
• Install the claims-aware applications Windows component on SPS-SRV.
• Add a DNS host name record to the CPANDL.COM domain so that federated users can
access the Office SharePoint Server 2007 Web site.
• Add the external SharePoint Web site as a claims-aware application on ADFS-RESOURCE.
19
Note
Windows Server 2003 with SP2 is required for AD FS and Office SharePoint Server 2007
to work together. To download Windows Server 2003 with SP2, see
First, add the claims-aware application Windows component. This component is required for
AD FS and interfaces with the AD FS federation servers to submit claims.
To add the claims-aware applications Windows component

1. Log on to SPS-SRV as cpandl\administrator or another user account in the local
2. Click Start, point to Control Panel, click Add or Remove Programs, and then click
Add/Remove Windows Components.
3. Click Active Directory Services, and then click Details.
4. Click Active Directory Federation Services (ADFS), and then click Details.
5. Click ADFS Web Agents, and then click Details.
6. Select the Claims-aware applications check box, and then click OK three times.
7. Click Next.
Note
You will be asked for the Windows Server 2003 R2 product CD in order to
complete the installation of the claims-aware applications Windows component.
Next, add a DNS host name record is required in the CPANDL.COM domain so that federated
users in the TREYRESEARCH.NET domain can access the Office SharePoint Server 2007 Web
site.
To create a DNS host name record for the external Office SharePoint Server 2007 Web
site
1. Log on to CPANDL-DC as cpandl\administrator or another user account in the local
2. Click Start, point to Administrative Tools, and then click DNS.
3. Expand Forward Lookup Zones, right-click CPANDL-DC, and then click New Host (A).
4. In the Name box, type external-sps.
5. In the IP Address box, type 10.0.0.6, and then click Add Host.
6. Click OK, confirming that the host record was successfully created.
7. Click Done.
20
Finally, add the external SharePoint Web site as a claims-aware Windows application on ADFS-
RESOURCE: This should be done before a user is added to doc library.
To add the external SharePoint Web site as a claims-aware Windows application on

ADFS-RESOURCE
1. Log on to ADFS-RESOURCE as cpandl\adfsadmin or another user account in the local
2. Click Start, point to Administrative Tools, and then click Active Directory Federation
Services.
3. If the User Account Control dialog box appears, confirm that the action it displays is
what you want, and then click Continue.
4. Expand Federation Services, expand Trust Policy, and then expand My Organization.
5. Right-click Applications, point to New, and then click Application.
6. On the Welcome to the Add Application Wizard, click Next.
7. Select the Claims-aware application option, and then click Next.
8. In the Application display name box, type External SharePoint Web site.
9. In the Application URL box, type https://external-sps.cpandl.com, and then click
Next.
10. Select the E-mail check box, and then click Next.
11. Select the Enable this application check box, and then click Next.
12. Click Finish.
Step 2: Configuring Office SharePoint 2007 to

work with AD FS
To configure Office SharePoint Server 2007 to work with AD FS, several steps must be
completed:
• Add a claims-aware Windows application for the external Web site.
• Extend the internal Office SharePoint Server 2007 Web site.
• Add a Secure Sockets Layer (SSL) certificate to the external Web site.
• Configure the authentication provider on the external Web site.
• Edit the web.config file on the internal Web site.
• Add Terrence Philip to the default document library.
• Edit the web.config file on the external Web site.
First, extend the existing internal Web site, created earlier in this guide, and add it to the Extranet
zone.
21
To extend the internal Office SharePoint 2007 Web site and add it to the Extranet zone
on SPS-SRV.
1. Log on to SPS-SRV as cpandl\administrator or another user account in the local
Administration.
3. Click Application Management, click Create or Extend Web application, and then
click Extend an existing Web application.
4. Select the Create a new Web site option, and then type External Users Web site in the
Description box.
5. In the Web Application box, click Change Web Application, and then click http://sps-
srv.
6. In the Port box, type 443.
7. In the Host header box, type external-sps.cpandl.com.
8. In the Secure Sockets Layer (SSL) box, select the Yes option.
9. In the URL box, type https://external-sps.cpandl.com.
10. In the Zone box, click Extranet.
11. Click OK.
Before proceeding with this appendix, verify that the internal Web site was correctly extended. To
do this, open the Alternate Access Mappings and ensure that external-sps.cpandl.com is
available.
To verify that the external Web site is available

1. In the Central Administration 3.0 site, click Operations.
2. Under the Global Configuration heading, click Alternate access mappings.
3. Verify that the https://external-sps.cpandl.com is shown and the Zone is configured for
Extranet.
Next, add an SSL certificate to the external-sps.cpandl.com Web site by using IIS. AD FS
requires an SSL connection for all claims-aware Windows applications.
To add an SSL certificate to the external Office SharePoint 2007 Web site
1. Click Start, point to Administrative Tools, and then click Internet Information Services
(IIS) Manager.
2. Expand Web Sites, right-click External Users Web site, and then click Properties.
3. Click Directory Security, and then click Server Certificate.
4. On the Welcome to the Web Server Certificate Wizard page, click Next.
22
5. Choose whether to import from an existing certificate file or request a new certificate.
6. After the certificate is imported, close the External Users Web site properties sheet.
Next, configure the authentication provider on the external Web site to use Web Single Sign On
(SSO).
To configure the authentication provider of the Extranet Web application to use Web
SSO
Administration, and then click Application Management.
2. Under the Application Security heading, click Authentication providers.
3. In the Web application box, click Change Web Application, and then click SharePoint
- 80.
4. Click Extranet.
5. For Authentication Type, select the Web single sign on option.
6. In the Membership provider name box, type SingleSignOnMembershipProvider2.
7. In the Role manager name box, type SingleSignOnRoleProvider2.
8. For Enable client integration, select the No option, and then click Save.
Next, configure the internal Web application to accept claims from the external Web site by
editing the web.config file for the internal Web site:
To configure the internal Web site to accept claims from the external Web site
1. Navigate to C:\inetpub\wwwroot\wss\VirtualDirectories\80.
2. Right-click web.config, and then click Open.
3. Select the Select the program from a list option, click Notepad, clear the Always use
the selected program to open this kind of file check box, and then click OK.
4. Add the following text under the line that reads <authentication mode ="Windows" />:
<membership>
<providers>
<add name="SingleSignOnMembershipProvider2"
type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2,
System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" fs="https://adfs-
resource.cpandl.com/adfs/fs/federationserverservice.asmx" />
</providers>
</membership>
23
<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">
<providers>
<remove name="AspNetSqlRoleProvider" /> <add name="SingleSignOnRoleProvider2"

type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2,
PublicKeyToken=31bf3856ad364e35" fs="https://adfs-
resource.cpandl.com/adfs/fs/federationserverservice.asmx" />
</providers>
</roleManager>
5. Click File, and then click Save.

6. Close Notepad.
7. At a command prompt, type IISRESET, and then press ENTER.
Next, add Terrence Philip (TREYRESEARCH\tphilip) to the default document library.
To add Terrence Philip to the default document library

2. Type http://SPS-SRV in the address bar, and then click Go. This will open the default
Office SharePoint Server 2007 site that was created during installation.
3. Click Site Actions, point to Site Settings, and then click People and Groups.
4. Click New, and then click Add Users.
5. In the Users/Groups box, type tphilip@treyresearch.net, and then click OK.
Important
If the internal SharePoint Web site is not able to resolve Terence Philip using the
procedure above, you should ensure all of the previous steps were completed correctly
before continuing through the rest of this appendix.
Next, edit the web.config file on the external Web site. There are several entries that must be
made to put each individual entry into its own procedure.
To add a new entry in the <configSections> node

1. Navigate to C:\inetpub\wwwroot\wss\VirtualDirectories\external-sps.cpandl.com443.
2. Right-click web.config, and then click Open.
3. Select the Select the program from a list option, click Notepad, and then clear the
Always use the selected program to open this kind of file check box.
4. Add the following text in the <configSections> node:
<sectionGroup name="system.web">
24
<section name="websso"
type="System.Web.Security.SingleSignOn.WebSsoConfigurationHandler,
System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35, Custom=null" />
</sectionGroup>

Add a new entry in the <httpModules> node:
To add a new entry in the <httpModules> node

1. In the same file as the previous procedure, add the following line as the last entry in the
<httpModules> node:
<add name="Identity Federation Services Application Authentication Module"
type="System.Web.Security.SingleSignOn.WebSsoAuthenticationModule,
System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35, Custom=null" />

Add a new entry to the <system.web> node:
To add a new entry in the <system.web> node

1. In the same file as the previous procedure, add the following under the line that read
<authentication mode="None"/>:
<membership defaultProvider="SingleSignOnMembershipProvider2">
<providers>
<add name="SingleSignOnMembershipProvider2"
type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2,
PublicKeyToken=31bf3856ad364e35" />
</providers>
</membership>
25
<roleManager enabled="true" defaultProvider="SingleSignOnRoleProvider2">
<providers>
<add name="SingleSignOnRoleProvider2"
type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2,
PublicKeyToken=31bf3856ad364e35" />
</providers>
</roleManager>
<websso>
<authenticationrequired />
<auditlevel>55</auditlevel>
<urls>
<returnurl>https://external-sps.cpandl.com</returnurl>
</urls>
<fs>https://adfs-resource.cpandl.com/adfs/fs/federationserverservice.asmx</fs>
<isSharePoint />
</websso>

3. Close Notepad.
4. From a command prompt, type IISRESET, and then press ENTER.
26
Step 3: Verifying AD RMS functionality with Office
SharePoint Server 2007 and AD FS.
To verify the functionality of AD RMS using AD FS and Office SharePoint Server 2007, you log on
to ADRMS-CLNT as Nicole Holliday, create a new Microsoft Word 2007 document, and upload it
to the Office SharePoint Server 2007 site into a rights-enabled document library configured such
that users who download the document will be able to read it but will not be able to print it. You
then log on to ADRMS-CLNT2 as Terrence Philip, download the document from the Office
SharePoint Server 2007 site and verify that the ability to print the document has been restricted.
Before you can consume rights-protected content, you must add the external Web application
(external-sps.cpandl.com) to the Local Intranet security zone on ADRMS-CLNT2.
To add external-sps.cpandl.com to Local Intranet security zone

1. Log on to ADRMS-CLNT2 as Terrence Philip (TREYRESEARCH\tphilip).
5. Click Advanced.
6. In the Add this website to the zone, type https://external-sps.cpandl.com, and then
click Add.
7. Click close.
Next, log on to ADRMS-CLNT as Nicole Holliday and create a Microsoft Word 2007 document
and upload it to the Office SharePoint Server 2007 site.
To create and upload a Microsoft Word document for testing

Office Word 2007.
2. Type This document is read-only. You cannot print it. in the new document, click the
Microsoft Office Button, click Save As, and then save the file as ADRMS-TST.docx to
a location on ADRMS-CLNT. This document will be uploaded to the Office SharePoint
Server 2007 document library.
Note
Since Nicole Holliday is the author of this document, she will have full rights to
the document, regardless of the AD RMS rights that are applied to it.
3. Close Microsoft Office Word 2007.
27
5. Type http://SPS-SRV/in the address bar, and then click Go.
7. Click Upload, click Upload Document, click Browse to locate and select ADRMS-TST,
and then click Open.
8. Click OK to upload the file, and then click Check In.
By uploading the document into this library, the document receives the restrictions set on
the library.
Finally, log on to ADRMS-CLNT2 as Terrence Philip and open the document from the external
Office SharePoint Server 2007 site.
To open a protected document

1. Log on to ADRMS-CLNT2 as Terrence Philip (TREYRESEARCH\tphilip).
3. Type https://external-sps.cpandl.com/ in the address bar, and then click Go.
5. Click ADRMS-TST, and then click OK to open the document as Read Only.
6. The following message will appear: "Permission to this document is currently
srv.cpandl.com/_wmcs/licensing to verify your credentials and download your
permission."
7. Click OK.
8. The following message will appear: "Verifying your credentials for opening content
with restricted permissions".
9. Click OK in the full screen reading view message, and then click Close to close the full
screen reading view.
10. Click the Microsoft Office button. The Print command is disabled.
You have successfully deployed, integrated, and demonstrated the functionality of AD RMS,
AD FS, and Office SharePoint Server 2007, using the simple scenario of uploading a Microsoft
Office Word 2007 document to an Office SharePoint Server 2007 site. You can also use this
deployment to explore some of the additional capabilities of AD RMS through additional
28
Step-by-Step Guide: Deploying SSTP Remote
Access
Abstract
Secure Socket Tunneling Protocol (SSTP) is a new form of VPN tunnel with features that allow
traffic to pass through firewalls that block PPTP and L2TP/IPsec traffic. SSTP provides a
mechanism to encapsulate PPP traffic over the SSL channel of the HTTPS protocol. The use of
PPP allows support for strong authentication methods such as EAP-TLS. The use of HTTPS
means traffic will flow through TCP port 443, a port commonly used for Web access. Secure
Sockets Layer (SSL) provides transport-level security with enhanced key negotiation, encryption,
and integrity checking.
This paper provides detailed information about how you can use three computers to create a test
lab with which to configure and test virtual private network (VPN) remote access with
Windows Server® 2008 and Windows Vista® with Service Pack 1 (SP1). These instructions are
designed to take you step by step through the configuration required for a Secure Socket
Tunneling Protocol (SSTP) connection.
1
Microsoft, MS-DOS, Windows, Windows NT, and Windows Server are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
2
Contents
Step-by-Step Guide: Deploying SSTP Remote Access .................................................................. 5
Secure Socket Tunneling Protocol ............................................................................................... 5
Setting up the test lab for SSTP remote access VPN connections ............................................. 7
Configuring DC1 ........................................................................................................................... 8
Configuring VPN1....................................................................................................................... 11
Configuring CLIENT1 ................................................................................................................. 25
Simulating a PPTP-based connection failure ............................................................................. 29
Configuring an SSTP-based connection .................................................................................... 33
Additional Resources ................................................................................................................. 38
3
Step-by-Step Guide: Deploying SSTP Remote
Access
This guide provides detailed information about how you can use three computers to create a test
lab with which to configure and test virtual private network (VPN) remote access with
Windows Server® 2008 and Windows Vista® with Service Pack 1 (SP1). These instructions are
designed to take you step by step through the configuration required for a Secure Socket
Tunneling Protocol (SSTP) connection.
Note
The following instructions are for configuring a test lab using a minimum number of
computers and procedure steps. To minimize setup time and complexity, services were
combined on the network servers rather than using individual computers to separate the
services in a more secure manner. This configuration is designed to reflect neither best
practices nor a desired or recommended configuration for a production network. The
configuration, including IP addresses and all other configuration parameters, is designed
to work only on a separate test lab network.
Consider using Virtual PC or Virtual Server

Microsoft Virtual PC or Virtual Server allow you to create the computer lab used in this document
using only one or two physical computers. After the virtual lab is configured, you can switch
between the three virtual computers needed for this lab with the click of a button. For more
information, see the following resources:
• Virtual PC 2007 Product Information (http://go.microsoft.com/fwlink/?LinkId=69217)
• Virtual Server Product Information (http://go.microsoft.com/fwlink/?LinkId=69220)
• Do More With Less: Exploring Virtual Server 2005
• TechNet Webcast: Virtual Server 2005 - Setting Up a Virtual Test and Development
Environment—Level 200 (http://go.microsoft.com/fwlink/?LinkId=69222)
Secure Socket Tunneling Protocol

Secure Socket Tunneling Protocol (SSTP) is a new form of VPN tunnel with features that allow
traffic to pass through firewalls that block PPTP and L2TP/IPsec traffic. SSTP provides a
mechanism to encapsulate PPP traffic over the SSL channel of the HTTPS protocol. The use of
PPP allows support for strong authentication methods such as EAP-TLS. The use of HTTPS
means traffic will flow through TCP port 443, a port commonly used for Web access. Secure
5
Sockets Layer (SSL) provides transport-level security with enhanced key negotiation, encryption,
and integrity checking.
SSTP-based VPN connection process

The data flow for an SSTP-based VPN connection takes place as follows:
When a user on a computer running Windows Server 2008 or Windows Vista with SP1 initiates
an SSTP-based VPN connection, the following occurs:
1. The SSTP client establishes a TCP connection with the SSTP server between a dynamically-
allocated TCP port on the SSTP client and TCP port 443 on the SSTP server.
2. The SSTP client sends an SSL Client-Hello message, indicating that the SSTP client wants
to create an SSL session with the SSTP server.
3. The SSTP server sends its computer certificate to the SSTP client.
4. The SSTP client validates the computer certificate, determines the encryption method for the
SSL session, generates an SSL session key and encrypts it with the public key of the SSTP
server’s certificate, and then sends the encrypted form of the SSL session key to the SSTP
server.
5. The SSTP server decrypts the encrypted SSL session key with the private key of its
computer certificate. All future communication between the SSTP client and the SSTP server
is encrypted with the negotiated encryption method and SSL session key.
6. The SSTP client sends an HTTP over SSL request message to the SSTP server.
7. The SSTP client negotiates an SSTP tunnel with the SSTP server.
8. The SSTP client negotiates a PPP connection with the SSTP server. This negotiation
includes authenticating the user’s credentials with a PPP authentication method and
configuring settings for Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6)
traffic.
9. The SSTP client begins sending IPv4 or IPv6 traffic over the PPP link.
Figure 1. Protocol level view of SSTP system architecture.
6
Setting up the test lab for SSTP remote access
VPN connections
The infrastructure for the VPN test lab network consists of three computers, which perform the
following services:
• A server computer running Windows Server 2003 named DC1 that is acting as a domain
controller, a Domain Name System (DNS) server, and a file server on a private (intranet)
network.
• A server computer running Windows Server 2008 named VPN1 that is configured with
Routing and Remote Access and is acting as a VPN server. In addition, VPN1 is configured
with Active Directory Certificate Services and Internet Information Services (IIS) to allow Web
enrollment of the computer certificate required for an SSTP-based VPN connection. VPN1
has two network adapters installed.
• A client computer running Windows Vista with SP1 named CLIENT1 that is acting as a VPN
client on a public (Internet) network.
The following diagram shows the configuration of the VPN test lab.
Figure 2. Configuration of the SSTP connection test lab.
7
Configuring DC1
DC1 is a computer running Windows Server 2003 SP1 or R2, Standard or Enterprise Edition, that
is providing the following services:
• A domain controller for the Contoso.com Active Directory® domain.
• A DNS server for the Contoso.com DNS domain.
• A file server.
The configuration of DC1 requires the following steps:
• Install the operating system.
• Configure TCP/IP.
• Install Active Directory and DNS.
• Create a user account with remote access permission.
• Create a shared folder and file.
The following sections explain these steps in detail.
Install the operating system

Install Windows Server 2003
1. On DC1, start your computer using the Windows Server 2003 product disc.
2. Follow the instructions that appear on your screen. When prompted for a computer name,
type DC1.
3. Configure the administrator account with the password P@ssword.
Configure TCP/IP
Configure TCP/IP properties so that DC1 has a static IP address of 192.168.0.1 with the subnet
mask 255.255.255.0 and a default gateway of 192.168.0.2.
Configure TCP/IP properties

1. On DC1, click Start, point to Control Panel, point to Network Connections, right-click
Local Area Connection, and then click Properties.
2. In the Local Area Connection Properties dialog box, on the General tab, click Internet
8
Protocol (TCP/IP), and then click Properties.
3. Click Use the following IP address. In IP address, type 192.168.0.1. In Subnet mask,
type 255.255.255.0. In Default gateway, type 191.168.0.2. In Preferred DNS server,
type 192.168.0.1.
4. Click OK, and then click Close.
Install Active Directory and DNS

Configure the computer as a domain controller for the Contoso.com domain. This will be the first
and only domain controller in this network.
Configure DC1 as a domain controller

1. On DC1, click Start, and then click Run. In Open, type dcpromo, and then click OK.
2. On the Welcome page of the Active Directory Installation wizard, click Next, and then
click Next again.
3. Click Domain controller for a new domain, and then click Next.
4. Click Domain in a new forest, and then click Next.
5. In Full DNS name for new domain, type contoso.com, and then click Next.
6. In NetBIOS Domain name, type CONTOSO, and then click Next.
7. Click Next twice, click Install and Configure the DNS server on this computer, and
set this computer to use this DNS server as its preferred DNS server, and then click
Next.
8. Click Permissions compatible only with Windows 2000 or Windows Server 2003
operating systems, and then click Next.
9. In Restore Mode Password, type a password. In Confirm password, type the
password again, and then click Next.
10. Click Next.
11. The Active Directory Installation Wizard will begin configuring Active Directory. When
the configuration is complete, click Finish.
Note
You must restart the computer after you complete this procedure.
Create a user account with remote access permission

Create a user account and configure the account with remote access permission.
Create and grant permission to a user account in Active Directory

1. On DC1, click Start, point to Administrative Tools, and then click Active Directory
9
Users and Computers.
2. In the left side tree, expand contoso.com, right-click Users, point to New, and then click
User.
3. In Full name, type user1, and in User logon name, type user1.
4. Click Next.
5. In Password, type P@ssword and in Confirm password, type P@ssword again.
6. Clear the User must change password at next logon check box, and then select the
User cannot change password and Password never expires check boxes:
To grant remote access permission to user1:
1. In the left tree, click Users. In the details pane, right-click user1, and then click
Properties.
2. On the Dial-in tab, in Remote Access Permission (Dial-in or VPN), click Allow
access, and then click OK.
Note
In a real-world scenario, you would use Network Policy Server (NPS) to configure
and enable remote access policies.
3. Close Active Directory Users and Computers.
Create a shared folder and file

DC1 is a file server that should be accessible to a remote user after access and authentication
methods have been configured.
Create a shared folder and file

1. On DC1, click Start, and then click My Computer.
2. Double-click Local Disk (C:).
3. In the blank space in the Windows Explorer window, right-click, point to New, and then
click Folder.
4. Name the folder CorpData.
5. Right-click the CorpData folder, and then click Sharing and Security.
6. Click Share this folder, and then click Permissions.
7. Click Add.
8. Under Enter the object names to select, type domain users, and then click Check
Names. Domain users should resolve to the contoso.com domain.
9. Click OK.
10
10. Under Permissions for Domain Users, under Allow, click Full Control to enable
permissions for documents in this folder.
11. Click OK two times to close the Sharing dialog boxes.
12. Double-click the CorpData folder and then right-click in the blank space. Point to New,
and then click Text Document.
13. Name the document VPNTest.txt.
14. Open VPNTest.txt and add some text.
15. Save and close VPNTest.txt.
Configuring VPN1
VPN1 is a computer running Windows Server 2008 that is providing the following roles:
• Active Directory Certificate Services, a certification authority (CA) that issues the computer
certificate required for an SSTP-based VPN connection.
• Certification Authority Web Enrollment, a service that enables the issuing of certificates
through a Web browser.
• Web Server (IIS), which is installed as a required role service for Certification Authority Web
Enrollment.
Note
Routing and Remote Access does not require IIS because it listens to HTTPS
connections directly over HTTP.SYS. IIS is used in this scenario so that CLIENT1 can
obtain a certificate over the Internet from VPN1.
• Network Policy and Access Services, which provides support for VPN connections through
Remote Access Service.
VPN1 configuration consists of the following steps:
• Install the operating system.
• Configure TCP/IP for Internet and intranet networks.
• Join the Contoso.com domain.
• Install the Active Directory Certificate Services and Web Server (IIS) server roles.
• Create and install the Server Authentication certificate.
• Install the Network Policy and Access Services (Routing and Remote Access) server role.
• Configure VPN1 to be a VPN server.

To install Windows Server 2008 on VPN1:
11
Install Windows Server 2008
1. On VPN1, start your computer using the Windows Server 2008 product disc. Follow the
instructions that appear on your screen. When prompted for a computer name, type
VPN1.
2. In the Initial Configuration Tasks window, under Provide Computer Information, click
Configure networking.
Note
If the Initial Configuration Tasks window is not already open, you can open it
by clicking Start, clicking Run, typing oobe in the text box, and then clicking OK.
Figure 3. Initial Configuration Tasks window.
Configure TCP/IP
Configure TCP/IP properties so that VPN1 has a static IP address of 131.107.0.2 for the public
(Internet) connection and 192.168.0.2 for the private (intranet) connection.

1. On VPN1, in the Network Connections window, right-click a network connection, and
12
then click Properties.
2. On the Networking tab, click Internet Protocol Version 4 (TCP/IPv4), and then click
Properties.
3. Click Use the following IP address.
4. Configure the IP address and subnet mask with the following values:
a. On the interface connected to the public (Internet) network, type 131.107.0.2 for the
IP address, and type 255.255.0.0 for the subnet mask.
b. On the interface connected to the private (intranet) network, type 192.168.0.2 for the
IP address, type 255.255.255.0 for the subnet mask, and type 192.168.0.1 for the
preferred DNS server.
6. To rename the network connections, right-click a network connection, and then click
Rename.
7. Configure the network connections with the following names:
a. On the interface connected to the public (Internet) network, type Public.
b. On the interface connected to the private (intranet) network, type Private.
8. Close the Network Connections window.
Run the ping command from VPN1 to confirm that network communication between VPN1 and
DC1 is working.
Use the ping command to check network connectivity

1. On VPN1, click Start, click Run, in the Open box, type cmd, and then click OK. In the
command window, type ping192.168.0.1.
2. Verify that you can successfully ping DC1.
3. Close the command window.
Join the Contoso domain

Configure VPN1 to be a member server in the Contoso.com domain.
Join VPN1 to the Contoso.com domain

1. On VPN1, in the Initial Configuration Tasks window, under Provide Computer
Information, click Provide computer name and domain.
Note
13
2. In the System Properties dialog box, on the Computer Name tab, click Change.
3. In Computer name, clear the text and type VPN1.
4. In Member of, click Domain, type contoso, and then click OK.
5. Enter administrator for the user name and P@ssword for the password.
6. When you see a dialog box welcoming you to the contoso.com domain, click OK.
7. When you see a dialog box telling you to restart the computer, click OK. Click Close, and
then click Restart Now.
Install Active Directory Certificate Services and Web Server

To support SSTP-enabled VPN connections, first install Active Directory Certificate Services and
Web Server (IIS) to enable Web enrollment of a computer certificate.
Install VPN and certificate services roles

1. On VPN1, log on as administrator@contoso.com with the password P@ssword.
2. In the Initial Configuration Tasks window, under Customize This Server, click Add
roles.
Note
3. In the Add Roles Wizard dialog box, in Before You Begin, click Next.
4. Click Active Directory Certificate Services.
Figure 4. Select Server Roles window.
14
5. Click Next, and then click Next again.
6. In the Select Role Services dialog box, under Role services, click Certification
Authority Web Enrollment.
7. In the Add Roles Wizard dialog box, click Add Required Role Services.
Figure 5. Add Roles Wizard dialog box.
15
8. Click Next.
9. Click Standalone, and then click Next.
10. Click Root CA (recommended), and then click Next.
11. Click Create a new private key, and then click Next.
12. Click Next to accept the default cryptographic settings.
13. In the Configure CA Name dialog box, click Next to accept the default CA name.
Figure 6. Configure CA Name dialog box.
16
14. Click Next repeatedly to accept default settings.
15. In the Confirm Installation Selections dialog box, click Install. The installation might
take several minutes.
16. In the Installation Results dialog box, click Close.
Create and install the Server Authentication certificate

The Server Authentication certificate is used by CLIENT1 to authenticate VPN1. Before installing
the certificate, you must configure Internet Explorer to allow certificate publishing.
Configure Internet Explorer

1. On VPN1, click Start, right-click Internet Explorer, and then click Run as administrator.
2. If a phishing filter alert appears, click Turn off automatic Phishing Filter, and then click
OK.
3. Click the Tools menu, and then click Internet Options.
4. In the Internet Options dialog box, click the Security tab.
17
5. Under Select a zone to view or change security settings, click Local intranet.
6. Change the security level for Local intranet from Medium-low to Low, and then click OK.
Note
In a real-world scenario, you should configure individual ActiveX® control
settings using Custom level rather than lowering the security level.
Figure 7. Internet Options dialog box.
Use Internet Explorer to request a Server Authentication certificate.
Request a Server Authentication certificate

1. On VPN1, in the Internet Explorer Address bar, type http://localhost/certsrv, and then
press ENTER.
18
2. Under Select a task, click Request a certificate.
3. Under Request a Certificate, click advanced certificate request.
4. Under Advanced Certificate Request, click Create and submit a request to this CA.
5. Click Yes to allow the ActiveX control.
Figure 8. Advanced Certificate Request page.
6. Under Identifying Information, in the Name field, type vpn1.contoso.com, and in the
Country/Region field, type US.
Note
The name is the certificate subject name and must be the same as the Internet
address used in the SSTP connection settings configured later in this document.
7. Under Type of Certificate Needed, select Server Authentication Certificate.
8. Under Key Options, select Mark keys as exportable, and then click Submit.
19
9. Click Yes in the confirmation dialog box.
The Server Authentication certificate is now pending. It must be issued before it can be installed.
Issue and install the Server Authentication certificate

1. On VPN1, click Start, and then click Run.
2. In Open, type mmc, and then click OK.
3. In the Console1 snap-in, click File, and then click Add/Remove Snap-in.
4. Under Available snap-ins, click Certification Authority, then click Add.
5. Click Finish to accept the default setting of Local computer.
6. Click OK to close the Add or Remove Snap-ins dialog box.
7. In the newly created MMC console, in the left pane, double-click Certification Authority
(Local).
8. Double-click contoso-VPN1-CA, and then click Pending Requests.
Figure 9. Certification Authority console.
9. In the middle pane, right-click the pending request, point to All Tasks, and then click
Issue.
20
10. In Internet Explorer, in the Certificate Pending page, click Home. If this page is not
visible, browse to http://localhost/certsrv.
11. Under Select a task, click View the status of a pending certificate request.
12. Under View the Status of a Pending Certificate Request, select the just-issued
certificate.
13. Click Yes to allow the ActiveX control.
14. Under Certificate Issued, click Install this certificate.
15. Click Yes in the confirmation dialog box.
Move the installed certificate from the default store location.
Move the certificate

1. On VPN1, in the previously created MMC console, click File, and then click Add/Remove
Snap-in.
2. Under Available snap-ins, click Certificates, and then click Add.
Figure 10. Certificates snap-in dialog box.
3. Click Finish to accept the default setting of My user account.

4. Click Add, click Computer account, and then click Next.
21
5. In the Select Computer dialog box, click Finish to accept the default setting of Local
computer.
7. In the console tree pane, double-click Certificates - Current User, double-click
Personal, and then click Certificates.
8. In the middle view pane, right-click the vpn1.contoso.com certificate, point to All Tasks,
and then click Export.
9. In the Welcome page, click Next.
10. Click Yes, export the private key, and then click Next.
11. Click Next to accept the default file format.
12. Type P@ssword in both text boxes, and then click Next.
13. In the File to Export page, click Browse.
14. In the File name text box, type vpn1cert, and then click Browse Folders.
15. Under Favorite Links, click Desktop, and then click Save to save the certificate to the
desktop.
16. In the File to Export page, click Next.
17. Click Finish to close the Certificate Export Wizard, and then click OK in the
confirmation dialog box.
18. In the console tree pane, double-click Certificates (Local Computer), and then double-
click Personal.
19. Right-click Certificates, point to All Tasks, and then click Import.
20. In the Welcome page, click Next.
21. In the File to Import page, click Browse.
22. Under Favorite Links, click Desktop, and from the drop-down list, select Personal
Information Exchange for the file type.
Figure 11. Certificate Import Wizard.
22
23. In the middle view pane, double-click vpn1cert.
24. In the File to Import page, click Next.
25. In the Password text box, type P@ssword, and then click Next.
26. In the Certificate Store page, click Next to accept the Personal store location.
27. Click Finish to close the Import Export Wizard, and then click OK in the confirmation
dialog box.
Figure 12. Location of Server Authentication certificate.
23
Install Routing and Remote Access
Configure VPN1 with Routing and Remote Access to function as a VPN server.
Install VPN and certificate services roles

1. On VPN1, in the Initial Configuration Tasks window, under Customize This Server,
click Add roles.
Note If the Initial Configuration Tasks window is not already open, you can open it by
clicking Start, clicking Run, typing oobe in the text box, and then clicking OK.
2. In the Add Roles Wizard dialog box, in Before You Begin, click Next.
3. Click Network Policy and Access Services, click Next, and then click Next again.
4. In the Select Role Services dialog box, under Role services, click Routing and
Remote Access Services.
5. Click Next, and then click Install.
6. In the Installation Results dialog box, click Close.
24
Configure Routing and Remote Access
Configure VPN1 to be a VPN server providing remote access for Internet-based VPN clients.
Configure VPN1 to be a VPN server

1. On VPN1, click Start, point to Administrative Tools, and then click Routing and
Remote Access.
2. In the Routing and Remote Access console tree, right-click VPN1, and then click
Configure and Enable Routing and Remote Access.
3. In the Welcome to the Routing and Remote Access Server Setup Wizard page, click
Next.
4. In the Configuration page, click Next to accept the default setting of Remote access
(dial-up or VPN).
5. In the Remote Access page, click VPN, and then click Next.
6. In the VPN Connection page, under Network interfaces, click Public. This is the
interface that will connect VPN1 to the Internet.
7. Click Enable security on the selected interface by setting up static packet filters to
clear this setting, and then click Next.
Note
Normally, you would leave security enabled on the public interface. For the
purposes of testing lab connectivity, you should disable it.
8. Click From a specified range of addresses, and then click Next.
9. Click New, type 192.168.0.200 for the Start IP address, type 192.168.0.210 for the End
IP address, click OK, and then click Next.
10. Click Next to accept the default setting, which means VPN1 will not work with a RADIUS
server. In this scenario, Routing and Remote Access Server will use Windows
Authentication.
11. In the Completing the Routing and Remote Access Server Setup Wizard page, click
Finish.
12. If the dialog box that describes the need to add this computer to the remote access
server list appears, click OK.
13. In the dialog box that describes the need to configure the DHCP Relay Agent, click OK.
14. Close the Routing and Remote Access snap-in.
Configuring CLIENT1
CLIENT1 is a computer running Windows Vista with SP1 that functions as a remote access VPN
client for the Contoso.com domain.
25
CLIENT1 configuration consists of the following steps:
• Install the operating system
• Configure TCP/IP

To install Windows Vista with SP1 on CLIENT1:
Install Windows Vista SP1

1. On CLIENT1, start your computer using the Windows Vista with SP1 product disc. Follow
the instructions that appear on your screen.
3. When prompted for the user name, type user1.
4. When prompted for the computer name, type CLIENT1.
5. When prompted for the computer location, choose Home.
Configure TCP/IP
Configure TCP/IP properties so that CLIENT1 has a static IP address of 131.107.0.3 for the
public (Internet) connection.

1. On CLIENT1, click Start, and then click Control Panel.
2. Click Network and Internet, click Network and Sharing Center, and then click Manage
network connections.
3. Right-click Local Area Connection, and then click Properties. If a dialog box is
displayed that requests permissions to perform this operation, click Continue.
4. In the Local Area Connection Properties dialog box, click Internet Protocol Version 4
(TCP/IPv4), and then click Properties.
5. Click Use the following IP address. In IP address, type 131.107.0.3 for the IP address,
and type 255.255.0.0 for the subnet mask.
Configure the hosts file to have a record for VPN1. This simulates a real-world scenario in which
the corporate VPN server would have a publicly resolvable host name.
Configure the hosts file

1. On CLIENT1, click Start, click All Programs, click Accessories, right-click Command
26
Prompt, and then click Run as administrator.
2. In the User Account Control dialog box, click Continue.
3. In the command window, type the following and then press ENTER:
notepad %windir%\system32\drivers\etc\hosts
4. Add the following text in a new line at the end of the document:
131.107.0.2 vpn1.contoso.com
5. Save and close the hosts file.
Run the ping command from CLIENT1 to confirm that network communication between CLIENT1
and VPN1 is working.
Use the ping command to check network connectivity

1. On VPN1, click Start, point to Administrative Tools, and then click Windows Firewall
with Advanced Security.
2. In the console tree, click Inbound Rules.
Figure 13. Windows Firewall with Advanced Security snap-in.
27
3. In the details pane, scroll down and double-click File and Printer Sharing (Echo
Request - ICMPv4-In) for the Public profile. Verify that this rule is enabled.
Figure 14. File and Printer Sharing (Echo Request - ICMPv4-In) Properties dialog box.
4. Under General, select Enabled, and then click OK.

5. On CLIENT1, in the command window, type ping vpn1.contoso.com, and then press
ENTER.
6. Verify that you can successfully ping VPN1.
For the purpose of this test lab, this connection signifies that the remote user can connect
to the office VPN server over the public Internet.
7. Close the command window.
28
Simulating a PPTP-based connection failure
Now that the preceding steps have been completed, the lab infrastructure is in place. This section
will cover configuring your lab setup so that PPTP-based VPN connections will fail. This simulates
a real-world scenario in which the remote access server is behind a firewall that blocks PPTP
connections. This lab will use Windows Firewall with Advanced Security on VPN1 to serve as the
perimeter firewall.
Configure PPTP-based VPN connection

Begin by creating a PPTP connection.
Configure PPTP-based VPN connection

1. On CLIENT1, click Start, and then click Control Panel.
2. Click Network and Internet, click Network and Sharing Center, and then click Set up a
connection or network.
Figure 15. Set up a connection or network dialog box.
29
3. Click Connect to a workplace, and then click Next.
4. Click Use my Internet connection (VPN).
5. Click I'll set up an Internet connection later.
6. In Internet address, type vpn1.contoso.com, and then click Next.
Note
The Internet address must be the same as the subject name previously
configured in this document. This requirement is for the SSTP connection used
later in this document.
7. In the Type your user name and password dialog box, type the following information:
a. In User name, type user1.
b. In Password, type P@ssword.
c. Click Remember this password.
d. In Domain, type contoso.
8. Click Create, and then click Close.
Test PPTP-based connection

Test the PPTP connection. You should be able to successfully connect to VPN1 using the PPTP-
based VPN connection created on CLIENT1.

1. On CLIENT1, in Network and Sharing Center, click Manage network connections.
2. Double-click VPN Connection, and then click Connect.
Figure 16. VPN Connection dialog box.
30
3. Verify that the connection was completed successfully by right-clicking VPN Connection,
and then clicking Status. The Media State should be "Connected."
4. In the VPN Connection Status dialog box, click Disconnect.
Configure Windows Firewall with Advanced Security

PPTP traffic consists of traffic over TCP port 1723 for tunnel maintenance and traffic over IP
protocol 47 for Generic Routing Encapsulation (GRE) for tunneling data. Configure Windows
Firewall with Advanced Security to block inbound GRE traffic to VPN1. This simulates a remote
access server behind a firewall that blocks PPTP connections.
Configure Windows Firewall with Advanced Security to block PPTP-based connections

1. On VPN1, click Start, point to Administrative Tools, and then click Windows Firewall
2. In the console tree, click Inbound Rules.
3. In the details pane, scroll down and double-click Routing and Remote Access (GRE-
In).
31
4. Under Action, select Block the connections, and then click OK.
Figure 17. Routing and Remote Access (GRE-In) Properties dialog box.

Confirm that a PPTP-based connection to VPN1 is now blocked.

2. Double-click VPN Connection, and then click Connect.
3. Verify that the connection was not completed. You should see a dialog box similar to the
following:
Figure 18. PPTP-based VPN connection fails.
32
4. Click Close.
Configuring an SSTP-based connection

A VPN client using an SSTP connection must install the root CA certificate of the VPN server's
computer certificate. During the SSL authentication phase, the VPN client validates the Server
Authentication certificate using the certificate installed on the client.
Obtain a trusted root CA certificate

The root certificate can be obtained through auto-enrollment, if the client is joined to an Active
Directory domain, or through Web enrollment from the CA's certificate-issuing Web site. In this
scenario, CLIENT1 will obtain the root CA certificate from VPN1 using Web enrollment.
Obtain a computer certificate from VPN1

1. On CLIENT1, click Start, and then click Internet Explorer.
2. In Internet Explorer, clear the URL and type http://vpn1.contoso.com/certsrv, and
then press ENTER.
3. On the Welcome page, under Select a task, click Download a CA certificate,
33
certificate chain, or CRL.
4. If you receive an alert about the Information Bar, click Close.
5. Click Download CA certificate.
6. In the File Download dialog box, click Open.
Figure 19. File Download dialog box for the security certificate.
7. In the security alert dialog box, click Allow.

8. Click Install Certificate.
Figure 20. Certificate dialog box.
34
9. In the Certificate Import Wizard, click Next.
10. In the Certificate Store dialog box, click Next to accept the default automatic store
location.
11. Click Finish.
12. In the confirmation dialog box, click OK.
13. Click OK to close the Certificate dialog box.
Now that the computer certificate has been imported, it must be installed. The default automatic
location for the installed certificate is in the Current User, Intermediate Certification Authority
store. The certificate must be moved to the Local Computer, Trusted Root Certification Authority
store on CLIENT1. Begin by configuring an MMC with user and computer certificate snap-ins.
35
Configure an MMC
1. On CLIENT1, click Start, click All Programs, click Accessories, and then click Run.
2. In Open, type mmc, and then click OK.
3. In the User Account Control dialog box, click Continue.
4. In the Console1 snap-in, click File, and then click Add/Remove Snap-in.
5. Under Available snap-ins, click Certificates, and then click Add.
6. Click Finish to accept the default setting of My user account.
7. Click Add, click Computer account, and then click Next.
8. In the Select Computer dialog box, click Finish to accept the default setting of Local
computer.
Move the installed certificate from the default store location. Because the certificate does not
involve private key binding, you can simply copy and paste the certificate to the new certificate
store.
Move the certificate

1. On CLIENT1, in the newly created MMC, in the console tree pane, double-click
Certificates - Current User, double-click Intermediate Certification Authorities, and
then click Certificates.
2. In the middle pane, right-click the contoso-VPN1-CA certificate, and then click Copy.
3. In the console tree pane, double-click Certificates (Local Computer), double-click
Trusted Root Certification Authorities, and then click Certificates.
4. In the middle pane, right-click, and then click Paste.
5. Refresh the view to verify that the certificate has been added to this store.
Figure 21. New location for downloaded certificate.
36
Configure and test an SSTP-based VPN connection
Now that the root CA certificate of the VPN server's computer certificate is in the Trusted Root
Certification Authorities certificate store on CLIENT1, configure and test an SSTP connection.
Configure and test an SSTP connection

2. Double-click VPN Connection, and then click Properties.
3. Click the Networking tab.
4. From the Type of VPN drop-down list, select Secure Socket Tunneling Protocol
(SSTP), and then click OK.
Figure 22. VPN Connection Properties dialog box.
37
5. In the Connect VPN Connection dialog box, click Connect.
CLIENT1 should successfully connect to VPN1 using the SSTP connection. Verify that
you can access the corporate file server from the remote location.
6. Click Start, click All Programs, click Accessories, and then click Run.
7. In Open, type \\192.168.0.1\corpdata, and then click OK.
8. Double-click VPNTest to open it, and then add some text.
9. From the File menu, click Save As, type VPNTest2 for the file name, and then click
Save.
10. Close VPNTest2.
Additional Resources
• Routing and Remote Access Blog (http://go.microsoft.com/fwlink/?LinkId=82954)
38
• New Networking Features in Windows Server 2008 and Windows Vista
39
DNS Server Global Query Block List
Published: November 2007
Author: Jim Groves
Editor: Jim Becker
Abstract
Clients of network protocols that rely on Domain Name System (DNS) name resolution to resolve
well-known host names are vulnerable to malicious users who use dynamic update to register
host computers that pose as legitimate servers. Examples of such protocols are the Web Proxy
Auto-Discovery Protocol (WPAD) and the Intra-site Automatic Tunnel Addressing Protocol
(ISATAP). The DNS server role in the Windows Server® 2008 operating system introduces a
global query block list that can help reduce this vulnerability. This document introduces this block
list, explains how it works, and describes how to take advantage of its features.
1
otherwise noted, the companies, organizations, products, domain names, e-mail addresses,
logos, people, places, and events depicted in examples herein are fictitious. No association with
any real company, organization, product, domain name, e-mail address, logo, person, place, or
event is intended or should be inferred. Complying with all applicable copyright laws is the
Active Directory, Windows, Windows NT, and Windows Server are trademarks of the Microsoft
group of companies.
2
Contents
DNS server global query block list overview ................................................................................... 5
What is WPAD?............................................................................................................................ 5
What is ISATAP?.......................................................................................................................... 6
How the DNS server global query block list works ...................................................................... 6
Installation Scenarios for the DNS server role ................................................................................ 7

Installing the DNS server role when neither WPAD nor ISATAP is deployed ............................. 8
Installing the DNS server role when WPAD or ISATAP is deployed ........................................... 8
Configuring the DNS server when you deploy or remove protocols ............................................... 9
Configuring the DNS server when you deploy WPAD or ISATAP ............................................... 9
Configuring the DNS server when you remove WPAD or ISATAP ............................................ 10
Configuring the DNS server to block other names ........................................................................ 10
DNS server global query block list technical reference ................................................................. 10
Extensions to dnscmd ................................................................................................................ 11
Global query block list registry values ........................................................................................ 11
3
DNS server global query block list overview
Most TCP/IP networks support the dynamic update feature of Domain Name System (DNS)
because dynamic update is convenient for network administrators and users alike. Dynamic
update makes it possible for DNS client computers to register and dynamically update their
resource records with a DNS server whenever a client changes its network address or host
name. This reduces the need for manual administration of zone records, especially for clients that
frequently move or change locations and use Dynamic Host Configuration Protocol (DHCP) to
obtain an IP address. This convenience comes at a cost, however, because an authorized client
can register any unused host name, even a host name that might have special significance for
certain applications. This can allow a malicious user to "hijack" a special name and divert certain
types of network traffic to that user's computer.
Two commonly deployed protocols are particularly vulnerable to hijacking in this fashion: the Web
Proxy Automatic Discovery Protocol (WPAD) and the Intra-site Automatic Tunnel Addressing
Protocol (ISATAP). Even if a network does not deploy these protocols, clients that are configured
to use them are vulnerable to the hijacking that DNS dynamic update enables. To prevent such
hijacking, the DNS server role in the Windows Server® 2008 operating system includes a global
query block list that can help prevent a malicious user from hijacking DNS names that have
special significance.
What is WPAD?
Most Web browsers use WPAD to locate and apply configuration settings that enable them to use
a network proxy server. These configuration settings are contained in a file that is located on a
server. The browser locates this server by querying a DHCP server for the uniform resource
locator (URL) of the network's WPAD server. If this query is unsuccessful, the browser attempts
to locate the WPAD server by using standard DNS name-resolution queries.
For example, if the Web browser is running on a Windows-based computer named
laptop.acctg.corp.contoso.com, the browser attempts to find the WPAD configuration file by
looking for the following URLs:
• http://wpad.acctg.corp.contoso.com/wpad.dat
• http://wpad.corp.contoso.com/wpad.dat
• http://wpad.contoso.com/wpad.dat
When it locates the Wpad.dat file at any of these locations, the browser reads the contents of the
file, and then configures itself according to the settings in the file.
Unfortunately, you cannot secure this automatic discovery process. Any computer that is
registered in a DNS zone with the name wpad can provide a WPAD configuration to clients on the
5
network, even if the file contains settings that cause the clients to use a fake proxy server, for
example, to divert the client's Web browser to counterfeit Web sites. The dynamic update feature
of DNS makes it possible for a malicious user to accomplish this without requiring the intervention
of a DNS system administrator simply by giving a computer the name wpad and then connecting
it to the network. As long as there is no other computer in the zone with the same name, the
computer of the malicious user can register its name with the DNS server that is authoritative for
its zone and thereby direct all WPAD queries to itself.
The block list feature that is provided by the DNS server role in Windows Server 2008 helps
prevent the hijacking of WPAD by ensuring that queries for WPAD servers always fail unless
WPAD is excluded from the block list. For more information about how the block list works, see
How the DNS server block list works.
What is ISATAP?
ISATAP provides a transition between networks that are based on Internet Protocol version 4
(IPv4) and networks that are based solely on the newer IP version 6 (IPv6). ISATAP provides this
transition by using a tunneling approach to carry IPv6 traffic on an IP version 4 (IPv4)
infrastructure. In other words, ISATAP encapsulates IPv6 packets with an IPv4 header, which
allows the IPv6 packets to be transmitted through a single ISATAP router from one ISATAP-
enabled host to another. This transmission occurs wherever the hosts are located on the network,
regardless of whether the hosts are located on an IPv6-enabled subnet or on an IPv4-only
network.
ISATAP does not support automatic router discovery. Instead, ISATAP hosts use a potential
routers list (PRL) to discover available ISATAP routers. Most commonly, however, ISATAP hosts
construct their PRLs by using DNS to locate a host named isatap on the local domain. For
example, if the local domain is corp.contoso.com, an ISATAP-enabled host queries DNS to obtain
the IPv4 address of a host named isatap.corp.contoso.com.
Consequently, a malicious user can spoof an ISATAP router in much the same way as a
malicious user can spoof a WPAD server: A malicious user can use dynamic update to register
the user's own computer as a counterfeit ISATAP router and then divert traffic between ISATAP-
enabled computers on the network. To prevent this, the Windows Server 2008 DNS Server
service blocks name resolution of the isatap host name by default.
How the DNS server global query block list works

In its default configuration, the Windows Server 2008 DNS Server service maintains a list of
names that, in effect, it ignores when it receives a query to resolve the name in any zone for
which the server is authoritative. To accomplish this, the DNS Server service first checks queries
against the list. Then, if the leftmost portion of the name matches an entry in the list, the DNS
Server service replies to the query as though no resource record existed, even if there is a host
6
(A) or host (AAAA) resource record in the zone for the name. In this way, if a host (A) or host
(AAAA) resource record exists in the zone because a host has used dynamic update to register
itself with a blocked name, the DNS Server service does not resolve the name.
The block list automatically applies to all zones for which the server is authoritative. For example,
if the DNS server is authoritative for contoso.com and for europe.contoso.com, it ignores queries
for wpad.contoso.com as well as for wpad.europe.contoso.com. However, the DNS Server
service does not ignore queries for names in zones for which it is not authoritative. Specifically,
the DNS Server service does not ignore queries that it receives through a forwarder or a stub
zone, or as a result of normal recursion or forwarding. If the block list causes the DNS Server
service to ignore a request for a resource record that does exist in a zone, it logs an event that
explains why it did so.
Important
All DNS servers that are authoritative for a zone must be running Windows Server 2008
and must be configured with the same block list to ensure consistent results when clients
query for resolution of names in the block list.
Because the DNS Server service applies the block list for all resource records, not just host (A) or
host (AAAA) resource records, it ignores queries for such resource record types as mail
exchanger (MX) and service locator (SRV) resource records. However, because the DNS Server
service does not apply the block list to zone names themselves, an administrator can create a
zone named wpad.contoso.com, for example, and add host resource records to that zone. In this
case, the DNS Server service continues to resolve host names in the wpad.contoso.com zone.
The initial contents of the block list depend on whether WPAD or ISATAP is already deployed
when you add the DNS server role to an existing Windows Server 2008 deployment or upgrade
an earlier version of Windows Server running the DNS Server service. The next section describes
installation and upgrade scenarios and explains how the contents of the block list are affected.
Installation Scenarios for the DNS server role

The Domain Name System (DNS) server role global query block list helps protect your network's
clients when you have not deployed the Web Proxy Auto-Discovery Protocol (WPAD) or the Intra-
site Automatic Tunnel Addressing Protocol (ISATAP) on your network. If one of these protocols
was deployed when you installed or upgraded the DNS Server service on a server running
Windows Server 2008, the DNS Server service configures itself to exclude the deployed protocol
from the block list. It does this to avoid interfering with the proper functioning of the protocol.
The following sections describe how the DNS Server service configures itself depending on
whether one of the protocols in the default block list was deployed when you installed or
upgraded the DNS Server service.
7
Installing the DNS server role when neither WPAD
nor ISATAP is deployed
If neither WPAD nor ISATAP was deployed on the network when you installed or upgraded the
DNS Server service on a server running Windows Server 2008, the DNS Server service
configures the block list to ignore queries for hosts named wpad and isatap.
The DNS Server service configures the block list the first time that it runs after you install or
upgrade it. Whenever the DNS Server service starts, it checks for the existence of a particular
registry key. If that key does not exist, the DNS Server service has not yet configured the block
list. The DNS Server service then enumerates all locally authoritative zones looking for existing
host (A) or host (AAAA) resource records for the names wpad and isatap. When the DNS Server
service fails to find these records, it stores the default list, which consists of entries for the names
wpad and isatap, in the registry along with a registry key that indicates that the block list is
enabled.
Configuration of the block list takes place only when the DNS Server service starts the first time
after you install or upgrade it. If you subsequently implement WPAD or ISATAP on the network,
you must configure the affected DNS servers to remove the corresponding name from their block
lists. Similarly, if you subsequently remove WPAD or ISATAP from the network after you install
the DNS Server role in Windows Server 2008, you must add the corresponding name to the block
list of the affected DNS servers. For more information about configuring the DNS Server service,
see Configuring the DNS server when you deploy or remove protocols.
Note
When the DNS Server service configures itself, it does not attempt to determine whether
the existing resource record for a host named wpad or isatap identifies a legitimate
deployed server. Before you upgrade a Windows-based DNS server to Windows
Server 2008, ensure that the server's zones do not already contain resource records for
these host names if the WPAD or ISATAP protocols are not deployed on the network.
Installing the DNS server role when WPAD or

ISATAP is deployed
If WPAD or ISATAP is deployed on the network when the DNS Server service starts the first time
after you install it, the DNS Server service configures the block list to avoid interfering with the
deployed protocol. As described earlier in this section, the first time that the DNS Server service
starts after you install or upgrade it, the DNS Server service enumerates the zones for which it is
authoritative. If it finds a host (A or AAAA) resource record for a host named wpad or isatap, it
removes the corresponding name from the block list before it stores the block list in the registry.
This allows WPAD or ISATAP clients to locate the servers that support the respective protocol.
8
If you subsequently remove support for WPAD or ISATAP from your network, you should
reconfigure the affected DNS servers to enable blocking resolution of the corresponding names.
For more information, see Configuring the DNS server when you deploy or remove protocols.
Configuring the DNS server when you deploy

or remove protocols
The Domain Name System (DNS) Server role configures the global query block list only when the
DNS Server service first starts after you install or upgrade it. Configuration prevents the DNS
Server service from improperly removing an item from the block list if you subsequently register a
host named wpad or isatap in one of the server's zones.
If you deploy or remove the Web Proxy Auto-Discovery Protocol (WPAD) or the Intra-site
Automatic Tunnel Addressing Protocol (ISATAP) after you deploy the DNS server role on a
server running Windows Server 2008, you must update the block list. You update the block list on
all DNS servers that host the zones that are affected by the change. The affected zones are
those where you registered the WPAD or ISATAP servers.
For more information about updating the global block list, see DNS server global query block list
technical reference.
Configuring the DNS server when you deploy

WPAD or ISATAP
When you deploy WPAD or ISATAP, you must remove the corresponding name from the block
list of all servers that are authoritative for the zone where you registered the WPAD or ISATAP
server. To accomplish this, you run the dnscmd /config /globalqueryblocklist command to
update the block list, which removes the corresponding name.
For example, if you deploy ISATAP in your network and register a router named isatap in a zone,
you must run the following command on all DNS servers that are authoritative for that zone:
dnscmd /config /globalqueryblocklist wpad
This command replaces the existing block list with a list that consists of only the name wpad. This
removes isatap from the default block list.
Note
Before you replace the block list, you should run the dnscmd /info
/globalqueryblocklist command to verify the current contents of the block list.
9
Configuring the DNS server when you remove
WPAD or ISATAP
When you remove WPAD or ISATAP from your network, you should configure the block list to
prevent the hijacking that is described in DNS server global query block list overview. To do this,
you add the appropriate name to the block list of the DNS servers that are authoritative for the
zones where you previously registered the protocol's host name. To add the DNS server name to
the block list, you run the dnscmd /config /globalqueryblocklist command.
For example, if you remove support for WPAD from your network, you should run the following
command on all DNS servers that host the zone where the wpad name was registered:
dnscmd /config /globalqueryblocklist wpad isatap
This replaces the existing global query block list with a list that includes the name wpad.
Configuring the DNS server to block other

names
The Domain Name System (DNS) Server role in Windows Server 2008 includes a global query
block list. This block list mitigates security vulnerabilities that occur because the Web Proxy Auto-
Discovery Protocol (WPAD) and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
employ both dynamic update and DNS name resolution. Although this is the primary purpose of
the block list, you can add names to it to prevent resolution for host names other than wpad and
isatap. For example, to prevent name resolution for a host named payroll in all the zones that a
DNS server running Windows Server 2008 hosts, you can run the following command to add the
name payroll to the default block list on the server:
dnscmd /config /globalqueryblocklist wpad isatap payroll
DNS server global query block list technical

reference
This following sections provide technical details about how the global query block list is
configured in the Domain Name System (DNS) Server service in Windows Server 2008.
10
Extensions to dnscmd
Windows Server 2008 extends the dnscmd command-line tool to make it possible for you to
configure and control the global query block list. The following table shows the commands that
you can use with dnscmd.
Command Description
dnscmd /info /enableglobalqueryblocklist Displays whether the global query block list is
enabled. If the block list is enabled, this
command returns the value 1. If the block list is
not enabled, this command returns the value 0.
dnscmd /info /globalqueryblocklist Displays the host names in the current block
list, if any.
dnscmd /config /enableglobalqueryblocklist Enables or disables the block list. If you want
[0 | 1] the DNS Server service to ignore queries for
the names in the block list, you set the value of
this command to 1. If you want to disable the
block list, you set the value of this command to
0. With a value of 0, the DNS Server service
does not ignore queries for names in the block
list.
dnscmd /config /globalqueryblocklist Removes all names from the block list.
dnscmd /config /globalqueryblocklist name Replaces the current block list with a list of the
[name]… names that you specify. By default, the global
query block list contains the following names:
• isatap
• wpad
The DNS Server service can remove either or
both of these names when the DNS Server
service starts the first time. For more
information, see Installation Scenarios for the
DNS server role.
Global query block list registry values

The DNS Server service uses the following registry values to store configuration information for
the block list:
11
•
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\En
ableGlobaQueryBlockList
If you set the value of this registry key to 1 (the default), it instructs the DNS Server service to
block name resolution in all zones that the server hosts for the names that are in the block
list. If you set the value of this registry key to 0, it instructs the DNS Server service not to
block name resolution for the names in the block list.
•
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\Gl
obalQueryBlockList
This registry key is a multistring value that contains the names that you want name resolution
to block.
12
Installing, Configuring, and Troubleshooting
the Microsoft Online Responder
Published: April 2007
Avi Ben-Menahem, Lead Program Manager, Microsoft Corporation
Editor: Debbie Swanson
Contributors:
Vishal Agarwal, Development Lead, Microsoft Corporation
Saurav Sinha, Developer, Microsoft Corporation
Oded Shekel, Program Manager, Microsoft Corporation
Jen Field, Program Manager, Microsoft Corporation
Shawn Corey, Software Development in Test, Microsoft Corporation
Rashmi Jha, Software Development in Test, Microsoft Corporation
Kelvin Yiu, Senior Program Manager, Microsoft Corporation
Yogesh Mehta, Program Manager, Microsoft Corporation
Abstract
This white paper describes the concepts behind and steps needed to install, configure, and
troubleshoot the Microsoft Online Responder, a role service that is used to implement online
1
certificate status protocol (OCSP) revocation checking in Active Directory Certificate Services
environments.
2
responsibility of the user. Without limiting the rights under copyright, no part of this document
may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or
by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any
purpose, without the express written permission of Microsoft Corporation.
Active Directory, Microsoft, MS-DOS, Visual Basic, Visual Studio, Windows, Windows NT, and
3
Contents
Installing, Configuring, and Troubleshooting the Microsoft Online Responder ............................... 7
Overview ...................................................................................................................................... 7
Understanding Revocation Checking Concepts .......................................................................... 7
CRLs ......................................................................................................................................... 8
OCSP ........................................................................................................................................ 9
Understanding the Online Responder's Components.................................................................. 9
OCSP Client............................................................................................................................ 10
Online Responder Web Proxy Cache ..................................................................................... 11
Online Responder Service ...................................................................................................... 11
Revocation Configuration ....................................................................................................... 12
Revocation Providers .............................................................................................................. 12
Exploring Online Responder Deployment Models ..................................................................... 13
Achieving Scalability and High Availability ............................................................................. 13
Deployment Models for Extranet Scenarios ........................................................................... 13
Deploying Microsoft Online Responder ..................................................................................... 16
Installing the Online Responder Service ................................................................................ 16
Preparing the Environment ..................................................................................................... 23
Configuring the CAs ............................................................................................................ 24
Configuring the OCSP Response Signing certificate template ........................................... 26
Configuring the OCSP Response Signing certificate template when using a Windows
Server 2008–based CA ................................................................................................ 27
Server 2003–based CA ................................................................................................ 28
Configuring OCSP Response Signing template permissions .......................................... 29
Assigning an OCSP Response Signing template to a CA ............................................... 30
Renewing OCSP Response Signing certificates ............................................................. 31
Enrolling for an OCSP Response Signing certificate against a stand-alone CA ................ 32
Using an HSM to protect OCSP signing keys ..................................................................... 33
Modifying the Online Responder service credentials....................................................... 33
Configuring the OCSP Response Signing template ........................................................ 34
Configuring the Online Responder ......................................................................................... 34
Configuring Online Responder properties ........................................................................... 35
Web proxy settings........................................................................................................... 35
Audit settings.................................................................................................................... 36
Security settings ............................................................................................................... 38
Managing revocation configurations.................................................................................... 38
Creating a revocation configuration ................................................................................. 38
5
Modifying a revocation configuration ............................................................................... 41
Managing Array members ................................................................................................... 44
Adding Array members .................................................................................................... 44
Monitoring and managing Array members ....................................................................... 44
Performing Online Responder Backup and Restore .................................................................. 45
Troubleshooting the Online Responder ..................................................................................... 46
Online Responder Service Problems...................................................................................... 46
Online Responder Snap-In Messages .................................................................................... 56
Array Configuration messages ............................................................................................ 56
Revocation Configuration messages................................................................................... 58
Enabling CryptoAPI 2.0 Diagnostics .......................................................................................... 60
Additional Resources ................................................................................................................. 61
6
Installing, Configuring, and Troubleshooting
the Microsoft Online Responder
Overview
Public key infrastructure (PKI) consists of multiple components, including certificates, certificate
revocation lists (CRLs), and certification authorities (CAs). In most cases, applications that
depend on X.509 certificates, such as Secure/Multipurpose Internet Mail Extensions (S/MIME),
Secure Sockets Layer (SSL), Encrypting File System (EFS), and smart cards, are required to
validate the status of the certificates used when performing authentication, signing, or encryption
operations. The certificate status and revocation checking is the process by which the validity of
certificates is verified based on two main categories: time and revocation status.
• Time. Certificates are issued for a fixed period of time and considered valid as long as the
expiration date of the certificate is not reached, unless revoked before that date.
• Revocation status. Certificates can be revoked before their expiration date because of
multiple reasons such as key compromise or suspension. Before performing any operation,
applications often validate that the certificate was not revoked.
Although validating the revocation status of certificates can be performed in multiple ways, the
common mechanisms are CRLs, delta CRLs, and Online Certificate Status Protocol (OCSP)
responses. Common scenarios for using OCSP include:
• SSL/Transport Layer Security (TLS) certificate revocation checking
• Smart card logon
• Enterprise S/MIME
• Extensible Authentication Protocol (EAP)/TLS–based virtual private network (VPN)
Microsoft natively supports only CRL in operating systems prior to the Windows Vista® operating
system. Windows Vista and the Windows Server® 2008 operating system will natively support
both CRL and OCSP as a method of determining certificate status. The OCSP support includes
both the client component as well as the Online Responder, which is the server component.
Understanding Revocation Checking Concepts

When an application performs a certificate evaluation, the validation is performed on all
certificates in that certificate's chain. This includes every certificate from the end-entity certificate
presented to the application to the root certificate.
When the first certificate in the chain is validated, the following process takes place:
7
1. The certificate chaining engine attempts to build the chain for the certificate inspected by
querying the local certificate store or by downloading from one of the URLs available in the
inspected certificate's authority information access extensions.
2. For all certificate chains that end in a trusted root, all certificates in the chain are validated.
This involves the following steps:
• Verify that each certificate's signature is valid.
• Verify that the current date and time fall within each certificate's validity period.
• Verify that each certificate is not corrupt or malformed.
3. Each certificate in the certificate chain is checked for revocation status. Revocation checking
is performed either by using a CRL or OCSP, based on the certificate configuration.
After the validation check is completed, the certificate chaining engine returns the results of the
validation check to the application that originated the validation request. The results will indicate if
all certificates in the chain are valid, if the chain terminates at a non-trusted root CA, if any
certificates in the chain are not valid, or if the revocation status for any of the certificates in the
chain cannot be determined.
For more information, see Certificate Revocation and Status Checking
(http://go.microsoft.com/fwlink/?LinkID=27081).
CRLs
A CRL is a file, created and signed by a CA, that contains serial numbers of certificates that have
been issued by that CA and are revoked. In addition to the serial number for the revoked
certificates, the CRL also contains the revocation reason for each certificate and the time the
certificate was revoked.
Currently, two types of CRLs exist: base CRLs and delta CRLs. Base CRLs maintain a complete
list of revoked certificates while delta CRLs maintain only those certificates that have been
revoked since the last publication of a base CRL.
The major drawback of CRLs is their potentially large size, which limits the scalability of the CRL
approach. The large size adds significant bandwidth and storage burdens to the CA and relying
party, and therefore limits the ability of the system to distribute the CRL. Bandwidth, storage
space, and CA processing capacity can also be negatively affected if the publishing frequency
gets too high. Numerous attempts have been made to solve the CRL size issue through the
introduction of partitioned CRLs, delta CRLs, and indirect CRLs. All these approaches have
added complexity and cost to the system without providing an ideal solution to the underlying
problem.
Another drawback of CRLs is latency; because the CRL publishing period is predefined,
information in the CRL might be out of date until a new CRL or delta CRL is published.
8
OCSP
OCSP is a Hypertext Transfer Protocol (HTTP) that allows a relying party to submit a certificate
status request to an OCSP responder. This returns a definitive, digitally signed response
indicating the certificate status. The amount of data retrieved per request is constant regardless
of the number of revoked certificates in the CA. Most OCSP responders get their data from
published CRLs and are therefore reliant on the publishing frequency of the CA. Some OCSP
responders can, however, receive data directly from the CA's certificate status database and
consequently provide near real-time status.
Scalability is the major drawback of the OCSP approach. Since it is an online process and is
designed to respond to single certificate status requests, it results in more server hits, requiring
multiple and sometimes geographically dispersed servers to balance the load. The response
signing and signature verification processes also take time, which can adversely affect the overall
response time at the relying party. Finally, since the integrity of the signed response depends on
the integrity of the OCSP responder's signing key, the validity of this key must also be verified
after a response is validated by the client.
Understanding the Online Responder's

Components
The Microsoft OCSP implementation is divided into client and server components (Figure 1). The
client component is built into the CryptoAPI 2.0 library while the server component is introduced
as a new service provided by the Active Directory® Certificate Services (AD CS) server role.
Figure 1: Microsoft Online Responder Components
9
OCSP Client
The OCSP client is fully integrated into the CryptoAPI 2.0 certificate revocation infrastructure. It
implements the recommendation specified in the draft Internet Engineering Task Force (IETF)
Public Key Infrastructure X.509 (PKIX) "Lightweight OCSP Profile for High Volume Environment"
and is optimized for high-volume scenarios.
The major difference between the Lightweight OCSP Profile and RFC 2560, "X.509 Internet
Public Key Infrastructure Online Certificate Status Protocol - OCSP," can be summarized as
follows:
• The Lightweight OCSP Profile supports both the Hypertext Transfer Protocol (HTTP) and
Secure Hypertext Transfer Protocol (HTTPS).
• Lightweight OCSP Profile responses must specify notBefore and notAfter dates, which are
not required in the full profile.
• Signed requests are not supported in the Lightweight OCSP Profile. The client cannot create
a signed request; if a signed request, which can be created by third-party OCSP clients, is
sent to the Online Responder an "Unauthorized" response is returned.
• With the Lightweight OCSP Profile, nonce is not supported in the request and ignored in the
response. However, the Online Responder supports the nonce extension and will return a
response that includes the nonce extension if configured to do so. For more information, see
Managing revocation configurations.
When an application calls CryptoAPI 2.0 to verify a certificate that specifies locations to Online
Responders, the revocation infrastructure performs the following basic steps (for each Online
Responder specified in the authority information access extension):
1. Search the local CryptoAPI 2.0 in-memory and disk caches to find a cached OCSP response
that has a valid time. The disk cache is located at: <drive>:\Users\<User
name>\AppData\LocalLow\Microsoft\CryptnetUrlCache.
Note
By default, response caching is performed by the OCSP client. This behavior can be
changed by modifying the ChainCacheResynchFiletime value located in the
HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType
0\CertDllCreateCertificateChainEngine\Config registry key. The
ChainCacheResynchFiletime value specifies the date and time to clear the in-
memory cache. The following Certutil commands can be used to modify the
ChainCacheResynchFiletime value:
• To set a registry value to the current date and time:
certutil –setreg chain\ChainCacheResyncFiletime @now
• To set a registry value to the current date and time plus 3 days and 1 hour:
certutil –setreg chain\ChainCacheResyncFiletime @now+3:1
• To display a registry value:

10
certutil –getreg chain\ChainCacheResyncFiletime
• To delete a registry value:

certutil –delreg chain\ChainCacheResyncFiletime
2. If no acceptable cached response can be found, a request is sent by using the HTTP GET
method. In situations where the Online Responder does not support the GET method,
CryptoAPI 2.0 will retry the request by using the HTTP POST method. Only one certificate
can be validated per OCSP request. Moreover, it is not possible to configure CryptoAPI 2.0 to
always try the POST method first.
3. The signature on the response, including the delegated OCSP signer certificate, is verified. If
the certificate contains the id-pkix-ocsp-nocheck extension, identified by the object identifier
1.3.6.1.5.5.7.48.1.5, CryptoAPI will not verify the revocation status of the delegated OCSP
signer certificate.
Online Responder Web Proxy Cache

The Online Responder Web proxy cache represents the service interface for the Online
Responder. It is implemented as an Internet Server Application Programming Interface (ISAPI)
extension hosted by Internet Information Services (IIS), and it performs the following operations:
• Request decoding. All requests sent to the Online Responder are Abstract Syntax Notation
One (ASN.1)–encoded according to the request/response schema defined in RFC 2560. For
more information about RFC 2560, see RFC 2560, "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP" (http://go.microsoft.com/fwlink/?LinkID=71068).
After a request is received by the Online Responder Web proxy, the decoder component will
try to decode the request and extract the certificate serial number to be validated.
• Response caching. After a request is received and a certificate serial number is extracted,
the Online Responder Web proxy will check the local cache for a valid response. The cache
is implemented as part of the ISAPI extension and is an in-memory cache. If a client request
generates a cache fault, the Online Responder Web proxy will make a request to the Online
Responder service for a response. The cache item validity period is set by default to the CRL
validity period from which the response was generated.
Note
In addition to the OCSP ISAPI extension caching, the IIS HTTP.SYS library performs
caching for 120 seconds. Multiple requests to the Online Responder in that time period
will be served with the HTTP.SYS-cached response.
Online Responder Service

The Online Responder is a Microsoft Windows NT® service (ocspsvc.exe) that is running with
Network Service privileges. It performs the following operations:
11
• Manages the Online Responder configuration. The Online Responder provides a
responder-wide set of attributes that can be configured. These attributes include public
interfaces, access control settings, audit settings, and Web proxy cache settings. All the
configuration information is stored in the registry under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OCSPSvc\Responder.
• Retrieves and caches revocation information based on configuration. Based on the
revocation configuration, the Online Responder service can retrieve and cache revocation
information such as CRLs and delta CRLs for future use. For more information, see
Revocation Configuration.
• Signs responses. For each successful request, the Online Responder signs the response
with a pre-acquired signing key.
• Audits configuration changes. To conform to the Common Criteria requirements, all
configuration changes of the Online Responder can be audited. For more information about
audit settings, see Configuring the Online Responder.
Revocation Configuration
A revocation configuration is a set of definitions that configure the Online Responder service to
respond to a certificate status request for a specific CA. Every Online Responder can have one or
more revocation configurations. Revocation configurations include:
• CA certificate
• Signing certificate for OCSP responses
• Revocation provider–specific configuration
Revocation Providers
Revocation providers are the components that are responsible for retrieving and caching
revocation information that is used by the Online Responder service. When the Online Responder
service receives an OCSP request, it first locates the revocation configuration, which is
configured to provide revocation information for the CA that issued the certificate in question.
After located, the Online Responder service extracts the certificate serial number and searches a
local CRL. (For more information about the local CRL, see Managing revocation configurations.)
If no relevant information is found, the Online Responder service sends the serial number to the
revocation provider, which is used by that revocation configuration. The provider, in turn, returns
the status of the certificate to the Online Responder service.
Although the revocation providers were designed for extensibility to allow custom providers to be
developed and used by the Online Responder, the Windows Server 2008 Online Responder
provides only a default CRL-based revocation provider and does not allow new providers to be
added.
12
Exploring Online Responder Deployment Models
When deploying the Online Responder, different deployment models should be considered for
scalability, high availability, and security reasons.
Achieving Scalability and High Availability

Figure 2 shows the deployment models that can provide scalability and high availability. The
Online Responder can be deployed on a single computer or on a software cluster that contains
one or more computers. Clustering can be achieved by using any software or hardware TCP/IP
load balancers. The Online Responder Microsoft Management Console (MMC) snap-in provides
the ability to manage multiple responders as if they were a single entity. For more information,
see Configuring the Online Responder.
Figure 2: Scalability and High Availability Deployment Models
Deployment Models for Extranet Scenarios

When deploying extranet-facing Online Responders, one of the design considerations is the level
of protection provided for the Online Responder signing key. Figure 3 shows two options for
protecting the Online Responder.
Figure 3: Extranet Deployment Models
13
In diagram 1 of Figure 3, the Online Responder is located in a protected local area network
(LAN), while all requests are redirected by an authenticated server that is running IIS, which is
located in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).
The advantage of such a deployment model is that the firewall configuration requires only pass-
through for port 80 between IIS and the Online Responder. Similar results can be achieved by
using the reverse-proxy capability of Microsoft Internet Security and Acceleration (ISA) Server as
demonstrated in diagram 2 of Figure 3. To configure ISA Server 2006 Web publishing rules, use
the following steps:
1. Open the Microsoft Internet Security and Acceleration Server 2006 snap-in. Right-click the
Firewall Policy node, point to New, and click Web Site Publishing Rule.
2. Enter a name for the new rule, and click Next.
3. Verify that Allow is selected, and click Next.
4. If you are targeting a single server or a Network Load Balancing (NLB) cluster, click Publish
a single Web site or load balancer. If you are using ISA Server as the load balancer for an
Online Responder Array, click Publish a server farm of load balanced Web servers. Click
Next.
5. Click Use non-secured connections to connect the published Web server or server
farm, and click Next.
Note
SSL should not be used with OCSP.
14
6. Type the name that clients use to connect to the Online Responder. This is either the
computer name of the server running ISA Server or a DNS alias that is set up to point to the
server running ISA Server.
7. To limit the publishing rule to only forward OCSP requests, type ocsp/* in the Path box.
8. If you are using ISA Server as the load balancer, either select an existing server farm or
create a new server farm.
9. To create a new server farm, click New to start the New Server Farm Wizard. Enter a name
for the new server farm, and click Next.
10. Click Add to add servers by name or IP address.
11. Leave the default connectivity monitoring settings, and click Next.
12. Click Finish to close the wizard.
13. In the Public name box, enter the fully qualified domain name (FQDN) or IP address to be
used for the Online Responder.
14. In the Web listener list, click a Web listener. If a Web listener is not already set up, click New
to start the New Web Listener Wizard.
15. Enter a name for the Web listener, and click Next.
16. Click Do not require SSL secured connections with clients.
Note
SSL should not be used with OCSP.
17. Select the All Networks (and Local Host) check box to allow all network computers to
connect to the Online Responder service, and click Next.
18. In the Select how clients will provide credentials to ISA Server list, click No
Authentication, and then click Next.
Note
The Online Responder service is meant for anonymous access.
19. Click Next.
Note
Since no authentication settings are provided, there are no single sign-on settings to
configure.
21. On the Select Web Listener page, click Next.
22. On the Authentication Delegation page, click Next.
23. On the User Sets page, click Next.
25. After the wizard is finished, click Apply to enable the new policy.
15
26. After the rules are applied, click OK to close the dialog box.
Deploying Microsoft Online Responder

Deploying the Online Responder consists of three steps:
• Install the Online Responder service.
• Prepare the environment.
• Configure the Online Responder.
Installing the Online Responder Service

Deploying Online Responders should occur after deploying CAs and before deploying the end-
entity certificates. For more information about Server Manager and CA deployment, see Windows
Server 2008 CA Enhancements (http://go.microsoft.com/fwlink/?LinkID=83212).
1. Click Start, point to Administrative Tools, and then click Server Manager.
Figure 4: Server Manager
16
2. If the Online Responder is being installed on a computer without any other AD CS role
services, click Add roles on the main page.
Note
If the Online Responder is installed on a computer where the CA or one of its
components is already installed, select the Active Directory Certificate Services node
in the left pane, and then click Add role services on the main page.
3. On the Select Server Roles page of the Add Roles Wizard (Figure 5), select the Active
Directory Certificate Services check box, and then click Next.
Figure 5: Select Server Roles
17
4. On the Select Role Services page (Figure 6), select the Online Certificate Status Protocol
check box.
Figure 6: Select Role Services
18
Because the Online Responder requires IIS, you are prompted to install IIS role services
(Figure 7). The following IIS features are required for the Online Responder to operate
properly:
Web Server
Common HTTP Features
• Static Content
• Default Document
• Directory Browsing
• Http Errors
• Http Redirection
Application Development
• .NET Extensibility
• ISAPI Extensions
Health and Diagnostics
• Http Logging
• Logging Tools
• Request Monitor
19
• Tracing
Security
• Request Filtering
Performance
• Static Content Compression
Management Tools
• IIS Management Console
• IIS 6 Management Compatibility
• IIS Metabase Compatibility
5. Click Add Required Role Services to install the required IIS services, and click Next.
Figure 7: Add Required Role Services
6. The next two steps allow selecting the role services for the Web server (IIS). Click Next
twice.
7. On the Confirm Installation Options page (Figure 8), click Install.
Figure 8: Confirm Installation Options
20
Note
The IIS installation process might take a long time to complete.
Figure 9: Installation Progress
21
8. When the installation is complete, the status of the installation process is displayed on the
Installation Results page.
Figure 10: Installation Results
22
9. Click Close.
As part of the setup process, a virtual directory named OCSP is created in IIS, and the ISAPI
extension used as the Web proxy is registered. You can manually register or un-register the Web
proxy by using either of the following commands:
certutil –vocsproot
certutil –vocsproot delete
Preparing the Environment

The environment preparation consists of the following steps:
• Configure the CA.
• Configure the OCSP Response Signing certificate template.
• Enroll for an OCSP Response Signing certificate against a stand-alone CA.
• Use a hardware security module (HSM) to protect OCSP signing keys.
23
Configuring the CAs
You must configure the CAs to include the Online Responder's URL as part of the authority
information access extension of issued certificates. This URL is used by the OCSP client to
validate the certificate status.
To configure the authority information access extension

1. Open the Certification Authority snap-in, right-click the name of the issuing CA,and then
click Properties.
2. Click the Extensions tab.
3. In the Select extension list, click Authority Information Access (AIA) (Figure 11), and
then click Add.
Figure 11: CA Properties
24
4. In the Add Location dialog box (Figure 12), type the full URL of the Online Responder,
which should be in the following form: http://<DNSServerName>/<vDir>
Note
When installing the Online Responder, the default virtual directory used in IIS is
OCSP.
Figure 12: Add Location dialog box
25
5. Click OK.
6. Select the location from the Location list.
7. Select the Include in the AIA extension of issued certificates and Include in the
online certificate status protocol (OCSP) extension check boxes, and then click OK.
Configuring the OCSP Response Signing certificate template

The Online Responder can sign OCSP responses by using the issuing CA key or a delegated
signing key. A delegated signing certificate has the following attributes:
• Has a short validity period. (A validity period of two weeks is recommended.)
• Includes the id-pkix-ocsp-nocheck extension.
• Does not include CRL distribution point and authority information access extensions.
• Includes id-kp-OCSPSigning enhanced key usage (EKU).
• The steps to configure the OCSP Response Signing template in the Microsoft Windows
Server 2003 operating system are different from the steps in Windows Server 2008.
Note
In Windows Server 2008, a version 3 template is introduced. The new template version
allows advanced cryptography support in addition to other enhancements. For more
26
information, see Windows Server 2008 CA Enhancements
Server 2008–based CA
In Windows Server 2008, a new certificate template is added to the available templates in Active
Directory Domain Services (AD DS). The new template, named OCSP Response Signing, is a
version 3 template preconfigured with the required extensions and attributes listed previously. No
modifications are required to the template or to the CA.
Figure 13 illustrates the flow that determines the behavior of the policy module in Windows
Server 2008 when processing a request for the OCSP Response Signing certificate.
Figure 13: OCSP Response Signing Certificate Request Processing
The EDITF_ENABLEOCSPREVNOCHECK flag is a new CA registry flag introduced in the

Windows Server 2008–based CA. The new flag, which is not enabled by default, allows the CA
policy module to issue certificates that include the id-pkix-ocsp-nocheck extension. The new
OCSP Response Signing template includes an additional flag as well, named
CT_FLAG_ADDREVNOCHECK, which instructs the policy module to add the id-pkix-ocsp-
27
nocheck extension. If either the EDITF_ENABLEOCSPREVNOCHECK flag is enabled or the
template includes the CT_FLAG_ADDREVNOCHECK flag, the policy module will search for an
OCSP Signing EKU in the request and in the template. If both conditions are met, the policy
module will add the id-pkix-ocsp-nocheck extension and will remove the authority information
access and CRL distribution point extensions from the certificate. This flow allows the Windows
Server 2008–based CA to issue an OCSP Response Signing certificate from an enterprise CA as
well as from a stand-alone CA.
If an enterprise CA is used, no additional configuration is required except for enabling the CA to
issue certificates based on the OCSP Response Signing template. If a stand-alone CA is used,
the following commands should be used to enable or disable the
EDITF_ENABLEOCSPREVNOCHECK flag on the CA.
To enable the flag, run the following command:
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK
To disable the flag, run the following command:

certutil –v –setreg policy\editflags –EDITF_ENABLEOCSPREVNOCHECK
After enabling or disabling the flag, the CA should be restarted for the changes to take effect.
Server 2003–based CA
One of the drawbacks of certificate templates is the inability to add custom extensions. This
introduces a problem creating and configuring the OCSP Response Signing template in Windows
Server 2003 and the ability to add the id-pkix-ocsp-nocheck extension. The following procedures
enable you to use the OCSP Response Signing template with a Windows Server 2003 CA.
To configure the certificate template for use with a Windows Server 2003 CA
1. Open the Certificate Templates snap-in.
Note
The snap-in must be opened from within Windows Server 2008. This is required
because only the new version of the snap-in supports the new version 3
templates and allows the duplication of version 3 templates.
2. Right-click the OCSP Response Signing template, and then click Duplicate. The
Duplicate Template dialog box (Figure 14) appears.
Figure 14: Duplicate Template dialog box
28
3. Click Windows 2003 Server, Enterprise Edition, and then click OK. This will create a
version 2 template, which can be issued by the Windows Server 2003–based CA and still
include the id-pkix-ocsp-nocheck extension.
Next, it is necessary to configure the CA to allow custom extensions to be included in certificate
requests.
To configure the Windows Server 2003 CA

1. On the CA computer, open a command prompt and type the following command:
certutil -v -setreg policy\EnableRequestExtensionList +1.3.6.1.5.5.7.48.1.5
2. Restart the CA service by typing the following commands:

net stop certsvc
net start certsvc
The CA is now configured to issue OCSP Response Signing certificates.
Configuring OCSP Response Signing template permissions

As with any template, the enrollment permissions for Read, Enroll, AutoEnroll, Write, and Full
Control must be configured.
To configure the template security settings to allow Online Responders to enroll for
signing certificates
2. Double-click the OCSP Response Signing template, and then click the Security tab.
3. Add the Online Responder computers to the Group or user names list.
4. To allow Online Responder computers to enroll for the OCSP Response Signing
29
certificate, select the Allow check box for the Read and Enroll permissions.
Note
The Autoenroll permission is not used by the Online Responder, which has a separate
implementation of autoenrollment that is explained in detail later in this document. The
default autoenrollment implementation limits a template to issuing one certificate per
client. By default, autoenrollment will renew only one of the signing certificates available
on the Online Responder computer and will archive the rest. In some cases,
autoenrollment will not use the original CA that issued the certificate for renewal. This is
not the behavior expected by the Online Responder, which requires renewal by the same
CA.
Assigning an OCSP Response Signing template to a CA

After the templates are properly configured, the CA needs to be configured to issue that template.
To configure the CA to issue certificates based on the newly created OCSP Response
Signing template
1. Open the Certification Authority snap-in.
2. Right-click Certificate Templates, click New, and then click Certificate Template to
Issue.
3. In the available templates list, click the OCSP Response Signing template, and then
click OK.
Enrolling for an OCSP Response Signing certificate

For enhanced security, the Online Responder service is running with Network Service privileges.
This means it does not have access to computer private keys by default, and permissions for
private keys that need to be accessed by the Online Responder have to be modified to allow
access. A new functionality, which is introduced in the version 3 templates, allows the enrollment
client to configure permissions for computer keys as part of the enrollment process to allow
access for services running as Network Service. This functionality is available only in Windows
Vista and Windows Server 2008.
The new version 3 templates include a new feature that allows the enrollment client to
automatically modify the private key permissions to allow Network Service access.
As long as a Windows Server 2008–based CA is used to issue a version 3 template, no additional
configuration is required.
If a Windows Server 2003, Enterprise Edition–based CA is used, the private key needs to be
manually configured on the Online Responder computer to allow the Online Responder service
access to the private key.
In Windows Vista and Windows Server 2008, the ability to modify private key permissions was
added to the Certificates snap-in.
30
The following procedure is required only if a Windows Server 2003–based CA is used.
To configure the private key permissions for a Windows Server 2003–based CA

1. Open the Certificates snap-in for the local computer.
2. In the available certificates list, select the OCSP Response Signing certificate.
Note
The signing certificate should first be manually enrolled.
3. On the Actions menu, point to All Tasks, click Manage Private Keys, and then click
Add.
4. Type network service, and then click OK.
5. Verify that only the Read permission is allowed for the NETWORK SERVICE, and then
click OK.
6. Restart the Online Responder service by typing the following commands at a command
prompt:
net stop ocspsvc
net start ocspsvc
Renewing OCSP Response Signing certificates

After the initial certificate enrollment is complete and the proper key access control list (ACL) is
set, renewing OCSP Response Signing certificates is similar to any other certificate renewal
procedure with one caveat. This caveat is to follow the correct procedure to renew the OCSP
Response Signing certificate during the period between the time the CA certificate was renewed
to the expiration date of the renewed CA certificate. The problem arises because the same CA
key that was used to sign issued certificates must be used to sign the OCSP Response Signing
certificates. Since this key is no longer available on the CA, no signing certificates can be issued.
Figure 15 illustrates the problem. OCSP Response Signing certificates (S1, S2) need to be
signed by the same key (k1) that was used to sign the end-entity certificates (C1, C2) that they
provide status for. After the CA key is renewed (t1), the CA will be using the new key (k2) to sign
new issued certificates. In the period between the time the CA certificate was renewed (t1) to the
expiration date of the renewed CA certificate (t2), the CA cannot issue or renew OCSP Response
Signing certificates, which can be used to sign OCSP responses for existing valid certificates (C1,
C2).
Figure 15: The OCSP Response Signing certificate renewal problem
31
To overcome this limitation, the Windows Server 2008–based CA was updated to allow the
renewal of OCSP Response Signing certificates by using existing keys. This feature is not
enabled by default. Use the following procedure to allow the renewal of OCSP Response Signing
certificates by using existing CA keys.
To allow the renewal of OCSP Response Signing certificates by using existing CA keys
1. On the CA computer, open a command prompt, and type:
certutil -setreg ca\UseDefinedCACertInRequest 1
2. Press ENTER.
3. Restart the CA service.
When using a Windows Server 2003–based CA, it is impossible to renew OCSP Response
Signing certificates after the CA certificate was renewed. To overcome this limitation, issue n
OCSP signing certificates for each Online Responder computer, where n = (the number of weeks
until the expiration date of the CA key)/2.
Note
This procedure must be performed before renewing the CA certificate.
Enrolling for an OCSP Response Signing certificate against a stand-alone

CA
Since stand-alone CAs do not support the version 2 or version 3 certificate template required to
create an OCSP Response Signing certificate, you must manually create and submit an OCSP
Response Signing certificate request. Use the following procedure to enroll for an OCSP
Response Signing certificate against a stand-alone CA.
To enroll for an OCSP Response Signing certificate against a stand-alone CA

1. Click Start, point to All Programs, click Accessories, and then click Notepad.
2. Copy and paste the following request data into Notepad:
[NewRequest]
Subject = "CN=testca,O=Contoso,OU=nt"
32
PrivateKeyArchive = FALSE
Exportable = TRUE
UserProtected = FALSE
MachineKeySet = TRUE
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
UseExistingKeySet = FALSE
RequestType = PKCS10
[EnhancedKeyUsageExtension]
object identifer="1.3.6.1.5.5.7.3.9"
[Extensions]
1.3.6.1.5.5.7.48.1.5 = Empty
3. Save the file as ocsp.inf.

4. Close Notepad.
5. At a command prompt, type:
certreq.exe –New ocsp.inf ocsp.req
certreq.exe –Submit ocsp.req ocsp.cer
certreq.exe –Accept ocsp.cer
After the enrollment process is complete, you must modify the ACL of the private key to allow the
Online Responder service to access the private key. For the required steps to configure private
key permissions, see Configuring the OCSP Response Signing certificate template.
Using an HSM to protect OCSP signing keys

The following configuration steps are required in case an HSM is used to protect the OCSP
signing keys.
Modifying the Online Responder service credentials

The Online Responder service uses Network Service credentials by default. To allow the Online
Responder service to interact with an HSM, it is required to change the service credentials to
Local System. Use the following steps to configure the Online Responder service credentials.
To configure the Online Responder service credentials

1. Open the Services snap-in.
2. Right-click the Online Responder service, and click Properties.
3. Click the Log On tab.
4. Click the Local System account.
33
5. Select the Allow service to interact with desktop check box, and click OK.
Configuring the OCSP Response Signing template

When you use an HSM to protect the OCSP signing keys, you must also configure the OCSP
Response Signing template to use the HSM's CryptoAPI cryptographic service provider (CSP) or
Cryptography Next Generation (CNG) provider. If only a CryptoAPI CSP is available, you must
duplicate the version 3 OCSP Response Signing template and create a new version 2 template
that supports CryptoAPI CSPs. See "Configuring the OCSP Response Signing certificate
template when using the Windows Server 2003–based CA" in the Configuring the OCSP
Response Signing certificate template section for the required steps to create a version 2
template.
Configuring the Online Responder

Whether the Online Responder is deployed on a single computer, clustered array, or multiple
clustered arrays, the Online Responder management tools provide a single point of monitoring
and configuration for Online Responder deployment.
The management tools installed by default on all Windows Server 2008 versions include the
Online Responder snap-in (Figure 16), which provides all the required functionality for managing
an Online Responder.
Figure 16: Online Responder snap-in
The Online Responder console tree includes the following views:
34
• Online Responder. This view provides general information about the Online Responder
configuration status and allows configuring of Online Responder properties.
• Revocation Configuration. This view allows adding, modifying, and deleting revocation
configurations. For more information about revocation configurations, see Managing
revocation configurations.
• Array Configuration. This view allows configuring, monitoring, and troubleshooting Online
Responder Array members. For more information about Array configurations, see Managing
Array members.
Configuring Online Responder properties

The Online Responder provides a set of configurable properties that are Online Responder–wide
and apply to the Online Responder's service operation.
To open the Online Responder dialog box, click Responder Properties on the Action menu or
click Responder Properties in the Action pane.
Web proxy settings

The Online Responder Web proxy cache is implemented as an ISAPI extension hosted by IIS.
The following configurable settings are enabled (Figure 17).
• Web proxy threads. This setting refers to the number of threads that will be allocated by the
Online Responder ISAPI extension for handling requests. Increasing the number of threads
will use more of the server's memory and reducing the number of threads will reduce the
number of clients that can be served concurrently.
• Cache entries allowed. The cache is implemented as part of the Online Responder's ISAPI
extension and is an in-memory cache only. The recommended cache size is between 1,000
and 10,000 entries. The minimum cache entries allowed is five. A small cache size will cause
more cache faults and will result in a higher load on the Online Responder service for lookup
and signing operations; a large cache size will increase the Online Responder's memory
usage. If the CA certificate is used to sign responses, the size of the cache entries in memory
is approximately 200 bytes; if a delegated signer certificate is used to sign responses, the
size of the cache entries in memory is approximately 2 KB (assuming a key size of 1,024
bytes).
Figure 17: Web proxy settings
35
Audit settings
To comply with Common Criteria requirements for secure certificate issuance systems and to
provide a secure platform, certain event and configuration settings are logged to the Windows
security event log. The Online Responder allows the configuration of the following audit events
(Figure 18).
• Start/Stop the Online Responder Service. Every Start/Stop event of the Online Responder
service will be logged.
• Changes to the Online Responder configuration. All Online Responder configuration
changes, including audit settings changes, will be logged.
• Changes to the Online Responder security settings. All changes to the Online Responder
service request and management interfaces ACL will be logged.
• Requests submitted to the Online Responder. All requests processed by the Online
Responder service will be logged. This option can create a high load on the service and
should be evaluated on a case-by-case basis. Note that only requests that require a signing
36
operation by the Online Responder will generate audit events; requests for previously cached
responses will not be logged.
Figure 18: Audit settings
Audit events will be logged to the Windows security log only if the Audit object access policy is
enabled.
To enable the Audit object access policy

1. Open the Local Group Policy Editor.
2. Under Computer Configuration, expand Windows Settings, Security Settings, and
Local Policies, and then click Audit Policy.
3. Double-click the Audit object access policy.
4. Select the Success and Failure check boxes, and click OK.
37
Security settings
The security settings for the Online Responder include two permission entries that can be set for
users and services to allow or deny access to the request and administration interfaces.
• Manage Online Responder. The Online Responder exposes a management interface
(IOCSPAdmin) that provides the ability to perform administrative tasks such as creating and
managing revocation configurations and to modify the Online Responder's global settings.
• Proxy Requests. The Online Responder exposes a request interface (IOCSPRequestD) that
allows the Online Responder Web proxy component to submit requests for certificate status
to the Online Responder service. This interface is not used by applications that submit the
OCSP request.
Managing revocation configurations

Revocation configurations include a set of definitions that enable the Online Responder to provide
a signed OCSP response. These definitions include the CA certificate, the signing certificate, and
the source of the revocation information. Each revocation configuration serves requests for a
specific CA key pair and certificate. The following rules apply:
• A separate revocation configuration should be created for each CA that was configured to
include the Online Responder authority information access in issued certificates.
• A separate revocation configuration should be created for each CA that is renewed with a
new key pair.
The Revocation Configuration view allows adding, modifying, and deleting revocation
configurations.
Creating a revocation configuration

This section explores the process of creating, modifying, and deleting revocation configurations.
To create a revocation configuration

1. On the Action menu or in the Actions pane, click Add Revocation Configuration.
The Add Revocation Configuration wizard appears.
2. Click Next.
3. In the Name box of the Name the Revocation Configuration page, enter a friendly
name for the revocation configuration (which will help identify the revocation configuration
from the available revocation configurations), and then click Next.
4. On the Select CA Certificate Location page, select the location of the CA certificate for
which this revocation configuration provides certificate status responses.
For the Online Responder to check a certificate's status, the revocation configuration
must identify the CA that issued the certificate. The following options are available:
Figure 19: Select CA Certificate Location
38
• Select a certificate for an existing enterprise CA. This option allows selecting the
CA certificate from the available CA certificates published in AD DS or by querying a
specific CA directly for its certificate. If this option is selected in step 4, the wizard will
prompt the user to select the CA certificate by browsing AD DS for published CAs or
for CA computer names (Figure 20). After identifying the CA certificate, you can verify
the certificate details by clicking the View Selected CA certificate link on the wizard
page.
Figure 20: Choose CA Certificate
39
• Select a certificate from the local certificate store. This option allows selecting a
CA certificate by browsing the certificate store on the current computer. If this option
is selected in step 4, the wizard will prompt the user to select the CA certificate by
browsing the local certificate store.
• Import certificate from a file. This option allows selecting a certificate file with a
*.cer extension. If this option is selected in step 4, the wizard will prompt the user to
select the CA certificate by browsing the file system for a certificate file with a *.cer
extension.
5. On the Select Signing Certificate page (Figure 21), the signing certificate must be
specified for each revocation configuration. The following options are available:
• Automatically select a signing certificate. If this option is selected, the Online
Responder will automatically search the Personal certificate store for the computer
hosting the Online Responder for a certificate that meets the following conditions:
• The certificate has an OCSP Signing EKU.
• The certificate was issued by the CA that was selected in step 4.
• The certificate is valid.
• The certificate has a matching private key.
40
The Auto-Enroll for an OCSP signing certificate check box allows configuring the
Online Responder to automatically enroll and renew OCSP Response Signing certificates
for the specified revocation configuration. If the CA that was selected in step 4 is
configured to issue the OCSP Response Signing template, this check box will be
selected and the Certification Authority and Certificate Template boxes will be filled in
automatically. Otherwise, the Auto-Enroll for an OCSP signing certificate check box
will not be selected.
Note
When the Online Responder's autoenrollment functionality is enabled, the enrolled
certificates will be stored in the certificate store for the Online Responder service and
not in the certificate store of the local computer. To view the current configuration
signing certificate, use the following steps:
1. Open the Certificates snap-in.
2. Click Service account, and click Next.
3. Click Local computer, and click Next.
4. Select the Online Responder service from the available services list, and click Finish.
5. The signing certificate for the current configuration can be found at the store named:
OCSPSVC\<configuration name>.
Note
The revocation provider will always look for a valid CRL and a delta CRL on the local
computer before trying to retrieve them from the network. If the Online Responder is
installed on the same computer as the CA, the values configured in the revocation
provider are ignored.
Modifying a revocation configuration

After a revocation configuration is created, it can be modified. This is done by selecting the
revocation configuration to be edited from the Revocation Configurations view, and then clicking
Edit Properties on the Action menu or in the Actions pane.
Local CRL. The Local CRL tab allows locally managing revoked certificates for a revocation
configuration. When this option is used, the Online Responder manages a local list of revoked
certificates in addition to the CA CRL and delta CRL. This feature is useful when the CA is not
responding and cannot publish CRLs or when the Online Responder cannot retrieve the CRL.
The local revocation information supersedes information in a CA-published CRL. For example, if
a certificate is listed as revoked in the local CRL but is not listed in the CA-published CRL, the
Online Responder will still issue a response in which the specified certificate is revoked.
To add a certificate to the Local revoked certificates list, you first need to select the Enable
local CRL check box and then click Add. The Revoked Certificate Details dialog box (Figure
41
23) requires the certificate's serial number, the revocation reason, and the effective date for the
revocation.
Figure 23: Revoked Certificate Details dialog box
Revocation Provider. The Revocation Provider tab allows reconfiguring the revocation
provider for the specified revocation configuration. Clicking the Provider button will display the
same dialog box as in the Creating Revocation Configuration wizard.
Signing. The Signing tab (Figure 24) allows configuring the following response signing options:
• Hash algorithm. The hash algorithm to be used when signing the response.
• Do not prompt for credentials for cryptographic operations. If the signing key is strongly
protected by an additional password, selecting this option means the Online Responder will
not prompt the user for the password and will fail silently. Understanding this option is
important when using HSMs to store the OCSP signing key. If using an HSM and this option
is selected, CryptoAPI is instructed not to show the PIN dialog box for accessing the private
key, and the signing operation will fail. If this option is not selected, the PIN dialog box will be
displayed the first time the configuration is loaded, which can occur when the service starts or
when the revocation configuration is loaded for the first time.
Note
Do not select this option if HSM is used to protect private keys.
• Automatically use renewed signing certificates. This option instructs the Online
Responder to automatically use renewed signing certificates without asking the Online
Responder administrator to manually assign them.
• Allow Nonce requests. This option instructs the Online Responder to inspect and process
an OCSP request nonce extension. If a nonce extension is included in the OCSP request and
this option is selected, the Online Responder will ignore any cached OCSP response and will
create a new response that includes the nonce provided in the request. If this option is
disabled and a request that includes a nonce extension is received, the Online Responder
will reject the request with an "unauthorized" error.
42
Note
The Microsoft OCSP client does not support the nonce extension.
• Use any valid OCSP signing certificate. By default the Online Responder will only use
signing certificates that are issued by the same CA that issued that certificate being validated.
This option allows modifying the default behavior and instructs the Online Responder to use
any valid existing certificate that includes the OCSP Signing EKU extension.
Note
Windows Vista does not support this deployment model and will fail if this option is
selected.
• Online Responder Identifiers. This option is used to select whether to include the key hash
or the subject of the signing certificate in the response. This is required per RFC 2560.
Figure 24: Revocation Configuration dialog box, Signing tab
43
Managing Array members
To manage global settings and revocation configurations on multiple Online Responder
computers, the concept of "Array" is introduced. An Array is defined as one or more computers
that have the Online Responder service installed, logically grouped and managed by the Online
Responder snap-in. All computers that are members of an Array will have the same global
settings and the same revocation configurations. For each Array, one member is defined as the
Array controller; the role of the Array controller is to help resolve synchronization conflicts and to
apply updated revocation configuration information to all Array members.
When you first open the Online Responder snap-in, you will see that one Array member already
exists in the console tree. This member is the Array controller, which is the local computer by
default.
Adding Array members
To add Array members

1. In the console tree, click Array Configuration.
2. On the Action menu or in the Actions pane, click Add Array Member.
3. In the Select Computer dialog box, browse for the Online Responder computer to be
added to the Array or type the computer's distinguished name, and then click OK.
After the new Online Responder is added to the Array, the Online Responder snap-in will
automatically synchronize global settings as well as existing revocation configurations.
Monitoring and managing Array members

Each member of the Array can be monitored and managed independently. Clicking on a specific
Array member node displays the Array member view, which includes revocation configuration
status information for each of the revocation configurations as well as some configuration options.
To better identify the status of Array members, the following status codes will be displayed in the
console tree:
• Array controller–status okay
• Array controller–status critical
• Array controller–status unknown
• Array controller–status warning
• Array member–status okay
• Array member–status critical
• Array member–status unknown
• Array member–status warning
Manually assigning a signing certificate can be accomplished by using the member view.
44
To manually assign a signing certificate
1. Select an Array member node.
2. Select the revocation configuration to assign a signing certificate to.
3. On the Action menu or in the Actions pane, click Assign Signing Certificate.
4. Select a signing certificate from the available signing certificates list, and then click OK.
Note
The Assign Signing Certificate operation should be used only when Manually select a
signing certificate was selected during the creation of a revocation configuration.
Performing Online Responder Backup and

Restore
Backing up the Online Responder revocation configuration and the signing keys is essential for
proper operation of the Online Responder.
• Revocation configuration. Although revocation configurations can be re-created, it is
recommended that the Online Responder is backed up whenever the revocation
configuration changes.
• Signing keys. Since signing keys can be reissued in case of corruption or another disaster,
they should be backed up only if the issuing CA key is not available. Because of the
limitations described in "Renewing OCSP Response Signing certificates," when using a
Windows Server 2003, Enterprise Edition–based CA, OCSP signing keys that are issued to
Online Responders should be backed up.
Since Online Responder administration tools can synchronize revocation configurations from the
Array controller to the Array members, the backup operation needs to be run only on the Online
Responder Array controller, which holds the most up-to-date revocation configuration information.
To back up the Online Responder revocation configuration, you should perform a full system
state backup.
To extract only the revocation configurations

1. Switch to the Array controller computer.
2. Open the Registry Editor (regedit.exe).
3. Navigate to the following registry hive:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OCSPSvc\Respond
er
4. Right-click the hive, and click Export.
5. Save the information to a *.reg file, and store the file for backup.
45
As described in "Renewing OCSP Response Signing certificates," backing up OCSP signing keys
is required only when using the Online Responder with a Windows Server 2003–based CA. Since
OCSP signing keys are unique to each revocation configuration of each Online Responder
computer, all signing keys available need to be backed up for each Online Responder computer.
To back up the Online Responder signing keys, you should perform a full system state backup.
Troubleshooting the Online Responder

Online Responder troubleshooting can be divided into two subcategories.
• Online Responder service–related issues. Problems in this category include
request/response issues and revocation provider configuration.
• Online Responder tools–related issues. Problems in this category include all Online
Responder snap-in and revocation configuration synchronization–related issues.
Online Responder Service Problems

The following events relate to the Online Responder service (ocspsvc.exe) status and are
displayed in the computer's Event Viewer.
Event 0xC25A0014 - The Online Responder Service did not start: %1. (Error Message).
Event ID 20
Event Name MSG_E_GENERIC_STARTUP_FAILURE
Event Source OnlineResponder or OCSPSvc
Description The Online Responder service (ocspsvc.exe) did not start. In most cases, the
reason will be included in the event message instead of the argument %1.
Diagnostics The following reasons might cause the service to fail initializing:
• Corrupted registry information
• No system resources
Resolve
1. If the information in the error description does not provide enough information to resolve the
error, first try to restart the Online Responder service from the Services snap-in
(services.msc). If the Online Responder service fails to start, check the event log for other
errors that may be related to this failure.
2. If the registry information is corrupted, you must uninstall and reinstall the Online Responder
service by using Server Manager.
3. If not enough system resources are available to start the Online Responder Service, try to
restart the computer or free system resources.
Event 0xC25A0015 - %1(FileIdentifier): OCSP Responder Services detected an exception at
address %2. Flags = %3. The exception is %4(ErrorCode).
46
Event ID 21
Event Name MSG_E_EXCEPTION
Description This event indicates an internal problem with the Online Responder service. Call
Microsoft Customer Service and Support to report the issue.
Diagnostics N/A
Resolve N/A
Event 0xC25A0016 - The Online Responder Service did not process a request from %1. The
request was very long, which can be caused by a denial-of-service attack. If the request was
rejected in error, modify the MaxIncomingMessageSize property for the service. Unless verbose
logging is enabled, this error will not be logged again for 20 minutes.
Event ID 22
Event Name MSG_E_POSSIBLE_DENIAL_OF_SERVICE_ATTACK
Description N/A
Diagnostics N/A
Resolve It is recommended that the originator of the request is located as this type of event might
point to a malicious user or application trying to compromise the Online Responder.
The MaxIncomingMessageSize value can be modified by creating a new registry DWORD value
under the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OCSPSvc\Responder
registry hive and setting the value to the maximum number of bytes you would like the Online
Responder to be able to process.
Event 0xC25A0017 - The Online Responder Service could not locate a signing certificate for
configuration %1(CAConfigurationID).(%2) (Error Message).
Event ID 23
Event Name MSG_E_CACONFIG_MISSING_SIGNINGCERT
Description This event occurs when the Online Responder service encounters a problem either
locating or loading a specific configuration's signing certificate.
Diagnostics The following reasons might cause this event:
• The OCSP Response Signing certificate is not present in the Personal certificate store for the
computer.
For AutoEnroll configurations in which the Online Responder service itself enrolls for its
certificate, this means that there may have been a problem with enrolling or installing the
signing certificate. Check the event log for additional errors or warnings that may be related
to this error. Then, check the status of the OCSP Response Signing certificate.
47
Note
If the revocation configuration is set up for automatic enrollment and renewal of the
OCSP Response Signing certificate, the signing certificate is located within the Online
Responder service account's certificate store. To view it, open MMC and add the
Certificates snap-in for "Service account" on the Online Responder computer, selecting
the "Online Responder Service" account. The certificate will be in the certificate store
under the node labeled with the revocation configuration name.
If the revocation configuration is set up for manual enrollment and renewal of the OCSP
Response Signing certificate, locate the signing certificate within the Online Responder
computer's Personal certificate store for the local computer. Open the Certificates snap-in for the
computer and locate the signing certificate in the Personal certificate store.
Resolve
1. If an OCSP Response Signing certificate is not present in the Personal certificate store for
the local computer, and the revocation is configured for manual OCSP Response Signing
certificate enrollment, you should enroll for a certificate manually.
2. For configurations in which the Online Responder service itself enrolls for its certificate,
manual enrollment will not work and you should check the event log for additional errors or
warnings related to a failure to enroll or install the OCSP Response Signing certificate. If no
additional information is available, verify the following:
a. Verify that the computer on which the Online Responder service is running has
connectivity to a CA. Use the Certification Authority snap-in on the CA to verify that the
CA is configured to issue certificates based on the OCSP Response Signing template.
b. Use the Certificate Templates snap-in to verify that the computer running the Online
Responder has Read and Enroll permissions on the OCSP Response Signing template.
3. If a valid OCSP Response Signing certificate exists, ensure that the Online Responder
service has access to the private key. By default, the Online Responder service runs as
Network Service, so the private key must be accessible by this user context. If the OCSP
Response Signing certificate private key is not accessible to Network Service, follow the
steps in "Enrolling for an OCSP Response Signing certificate" in the Configuring the OCSP
Response Signing certificate template section to correct the problem.
4. If the OCSP Response Signing certificate is not valid for signature purposes, ensure that you
enroll for a certificate that includes the id-kp-OCSPSigning EKU, labeled "OCSP Signing
(1.3.6.1.5.5.7.3.9)."
Event 0x825A0019 - The signing certificate for Online Responder configuration %1 will expire
soon.
Event ID 25
Event Name MSG_W_CACONFIG_SIGNINGCERT_EXPIRING
48
Description The signing certificate for the specified configuration is about to expire. Specifically,
if the Online Responder has been configured so that it can automatically enroll for signing
certificates, the certificate has entered the period in which it can be automatically re-enrolled. For
manual configurations, this means that the period when renewal reminders are triggered has
begun.
Diagnostics Review the expiration date of the specified certificate.
Locate the signing certificate as specified in the guidance for Online Responder event 23 above,
and note the Valid to field.
If the revocation configuration is set up for automatic enrollment of the OCSP Response Signing
certificate, further action may not be required. Check the expiration date on the certificate to
ensure you will have adequate time to verify when automatic re-enrollment has occurred.
Resolve For manual configurations, renew the signing certificate. To do this, right-click the
certificate, and click Renew Certificate with New Key to start the Certificate Renewal Wizard.
Note
The reminder duration is a responder-wide property, expressed as a percentage of the
certificate lifetime. The default value is 90 percent, but this value can be modified by
adding a DWORD registry key named ReminderDuration under
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\OcspSvc\Responder\
%Revocation Configuration Name\
Enter a value between 1 and 100 to indicate the desired percentage. You must stop and restart
the Online Responder service in order for the new value to take effect.
Event 0xC25A001A - The signing certificate for Online Responder configuration %1 has expired.
OCSP requests for this configuration will be rejected.
Event ID 26
Event Name MSG_E_CACONFIG_SIGNINGCERT_EXPIRED
Description The signing certificate for the specified configuration has expired.
Diagnostics Review the expiration date of the specified certificate.
• If the revocation configuration is set up for automatic enrollment of the OCSP Response
Signing certificate, there may have been a problem with the automatic re-enrollment. Locate
the signing certificate within the Online Responder service account's certificate store as
specified in the guidance for Online Responder event 23 above. If the certificate has expired,
check the event log for additional errors or warnings related to a failure to enroll or to install
the OCSP Response Signing certificate automatically. If no other information is available,
verify the following:
a. Verify that the computer on which the Online Responder service is running has
connectivity to a CA. Use the Certification Authority snap-in on the CA to verify that the
CA is configured to issue certificates based on the OCSP Response Signing template.
49
b. Use the Certificate Templates snap-in to verify that the computer running the Online
Responder has Read and Enroll permissions on the OCSP Response Signing template.
• If the revocation configuration is set up for manual enrollment of the OCSP Response Signing
certificate, locate the signing certificate within the Online Responder computer's local
computer Personal certificate store, as specified in the guidance for Online Responder event
23 above.
Resolve For manual configurations, renew the signing certificate. To do this, right-click the
certificate, and click Renew Certificate with New Key to start the Certificate Renewal Wizard.
Event 0x825A001B - The signing certificate for Online Responder configuration %1 was not
updated.(%2) (Error Message).
Event ID 27
Event Name MSG_W_CACONFIG_UPDATE_THREAD_FAILED
Description This event can occur if the Online Responder service cannot update the signing
certificate in case of renewal.
Diagnostics This should happen only in the case of the system running out of resources.
Resolve If not enough system resources are available for the Online Responder to operate
normally, first restart the Online Responder service and then restart the computer or free system
resources. If the error persists, call Microsoft Customer Service and Support.
Event 0xC25A001D - Settings for Online Responder configuration %1 cannot be loaded. OCSP
requests for this configuration will be rejected (%2) (Error Message).
Event ID 29
Event Name MSG_E_CACONFIG_FAILTOLOAD
Description This event can occur if a revocation configuration is corrupted and cannot be loaded.
Diagnostics N/A
Resolve Follow these steps to resolve the problem:
1. Try to delete the revocation configuration through the Online Responder snap-in.
2. Re-create the specified revocation configuration.
If the configuration cannot be loaded through the Online Responder snap-in, follow these steps:
1. Navigate to the following registry hive:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OCSPSvc\Responder
2. Locate and delete the corrupted revocation configuration.
Note
If you are encountering this problem on an Array member, you should delete the
corrupted configuration from the Array member and then synchronize the Array to re-
50
create the revocation configuration. If you are encountering this problem on an Array
controller, temporarily set another computer as the Array controller, synchronize the
Array, and then reset the original computer to be the Array controller.
Event 0x825A001F - Performance counters for the Online Responder Service cannot be
initialized.
Event ID 31
Event Name MSG_W_PERF_COUNTER_INIT_ERROR
Description This event indicates an internal problem with the Online Responder service.
Diagnostics The computer hosting the Online Responder may be running low on memory.
Resolve Open a Windows Performance console window (Perfmon.exe) on the Online Responder
computer to evaluate system memory usage. If necessary, resolve resource issues by adding
physical or virtual memory, or adjusting memory allocation and hard disk use.
Use the Services snap-in to stop and restart the Online Responder service.
If the error persists, call Microsoft Customer Service and Support to report the issue.
Event The Online Responder Service failed to create an enrollment request for the signing
certificate template %2 for configuration %1 (%3) (Error Message).
Event ID 33
Event Name MSG_E_CACONFIG_CREATE_ENROLLMENT_REQUEST_FAILED
Description The Online Responder service tried to enroll or re-enroll for a signing certificate and
encountered an error while generating the certificate request. The error occurred before the
request could be submitted to a CA.
Diagnostics Check the event for the names of the certificate template for which the enrollment
request was attempted, as well as the error message. Check for other errors either before or after
this event in the event log that may provide more information.
Resolve Resolution will depend upon the error message and any other errors or warnings
logged.
Event The Online Responder Service encountered an error while submitting the enrollment
request for configuration %1 to certification authority %2. The request ID is %3 (%4) (Error
Message).
Event ID 34
Event Name MSG_E_CACONFIG_SUBMIT_ENROLLMENT_REQUEST_FAILED
Description The Online Responder service tried to enroll or re-enroll for a signing certificate and
encountered an error while submitting the certificate request to the CA.
51
Diagnostics The event description should contain more information about the cause of the error,
including the error message and the failed CA request ID, if one was returned.
Verify that the computer on which the Online Responder service is running has connectivity to a
CA. Use the Certification Authority snap-in on the CA to verify that the CA is configured to issue
certificates based on the OCSP Response Signing template.
Use the Certificate Templates snap-in to verify that the computer running the Online Responder
has Read and Enroll permissions on the OCSP Response Signing template.
In addition, the request ID provided as part of the error message can be used on the CA
computer to further diagnose the cause of the error.
Resolve After any permissions errors or other errors have been resolved, start a new enrollment
by using the Services snap-in to restart the Online Responder service on each Array member, or
alternatively by right-clicking Array Configuration in the Online Responder snap-in and clicking
Refresh Revocation Data.
If the error persists, check the event log on the CA for any other events related to enrollment
failures. Resolve any issues related to processing requests for OCSP Response Signing
certificates, and then restart the Online Responder service to reattempt the request.
Event The Online Responder Service failed to install the enrollment response for configuration
%1 for the signing certificate template %2. The request ID is %3 (%4) (Error Message).
Event ID 35
Event Name MSG_E_CACONFIG_INSTALL_ENROLLMENT_RESPONSE_FAILED
Description The Online Responder service was able to submit an enrollment request for a
signing certificate to a CA, but an error occurred while the response to the request was being
processed.
Diagnostics Check the event description to verify the name of the CA, the certificate template for
which the enrollment request was attempted, the request ID for the CA, and the error message.
In the Online Responder snap-in, right-click the revocation configuration, and then click View CA
Certificate. Verify that the CA certificate for which the revocation configuration is configured to
issue OCSP responses was used to sign the enrollment or renewal request. If the same CA
certificate was not used, update the OCSP configuration to use the correct CA certificate.
In the Online Responder snap-in, right-click the revocation configuration and click Edit
Properties. Click the Signing tab. If the Use any valid OCSP signing certificate check box is
selected, use the Certificates snap-in to ensure the CA certificate is in a root store or intermediate
store.
Resolve If you have updated the OCSP configuration to use the correct CA certificate, the OCSP
Response Signing certificate request and installation should be completed as part of that process.
Event 0xC25A0011 - The Online Responder web proxy failed to Initialize. %1 (Error Message).
Event ID 17
52
Event Name MSG_E_FAILED_TO_INITIALIZE
Event Source OnlineResponderWebProxy or OCSPISAPIExtension
Description The ISAPI extension failed to initialize because of an internal error.
Diagnostics The following reasons might cause the ISAPI extension to fail to initialize:
• The Online Responder service (ocspsvc.exe) is stopped.
• The DCOM security configuration for the IOCSPAdmin interface is incorrect, causing the
ISAPI to fail updating Web proxy information.
• Online Responder–wide configuration properties may be corrupt.
Resolve Follow these steps to resolve the problem.
1. Ensure that the ocspsvc.exe service is running.
2. Using the Dcomcnfg command-line tool, ensure that the Network Service has Activate
permissions for the IOCSPAdmin interface.
3. If you suspect the Online Responder–wide configuration properties are corrupt, uninstall and
re-install the Online Responder service, or follow the guidance for Online Responder event
29 above to delete and refresh the configuration via the registry or synchronization with other
Array members.
Event 0x425A0014 - Online Responder Service detected an invalid configuration for the %1
property. The value was changed from %2(ExistingValue) to %3 (AdjustedValue).
Event ID 20
Event Name MSG_I_ADJUST_PROPERTY_VALUES
Event Source OnlineResponderWebProxy or OCSPISAPIExtension
Description This event indicates that configuration values are not in the permitted range. This
can occur if the registry was manually modified.
Diagnostics N/A
1. For Array members, either synchronize with the Array controller or reinstall the Online
Responder service.
2. For Array controllers, temporarily set another member as the Array controller, synchronize
the configuration, and then reset the original member as the Array controller. Otherwise,
reinstall the Online Responder service.
Event 0xC25D0010 - For configuration %1, Online Responder revocation provider failed to
update the CRL Information: %2. (Error Message).
Event ID 16
Event Name MSG_E_CRL_RETRIEVAL_FAILED
Event Source OnlineResponderRevocationProvider or OCSPRevInfoProvider
53
Description The Online Responder service could not retrieve a CRL required for the specified
revocation configuration.
Diagnostics Follow these steps to diagnose the problem:
1. Use the Online Responder snap-in to verify that the URLs configured for base and delta CRL
distribution points are valid.
a. Open the Online Responder snap-in. In the console tree, select the revocation
configuration node. In the details pane, right-click the revocation configuration specified in
the event description, and then click Edit Properties. Click the Revocation Provider
tab, and then click Provider.
b. Note the URLs configured in the Base CRL URLs and Delta CRL URLs lists. Using
network tools, verify that these URLs are accessible by the computer running the Online
Responder and that they contain CRL files.
2. Use the Certification Authority snap-in to verify the URLs to which the CA will publish base
and delta CRLs.
a. Open the Certification Authority snap-in, right-click the relevant CA, and then click
Properties. Click the Extensions tab, and note the URLs entered for the CRL
Distribution Point (CDP) extension.
b. Note the URLs for which the Publish CRLs to this location or Publish Delta CRLs to
this location check boxes are selected. Verify that these map to the same network
locations configured as base and delta CRLs in the Online Responder snap-in.
3. On the computer to which the base CRL is published, examine the Freshest CRL extension
for the base CRL. Verify that this identifies a location where the delta CRL can be found.
a. Republish the current CRL, if necessary, by typing the following command at a command
prompt:
certutil -crl
b. Then, verify that Online Responder service can access the CRL. From the Online
Responder snap-in, right-click Array Configuration, and click Refresh Revocation
Data.
4. If the error persists, enable CryptoAPI 2.0 Diagnostics for more information.
To learn how to enable CryptoAPI 2.0 Diagnostics and understand the CryptoAPI diagnostics
information, see Enabling CryptoAPI 2.0 Diagnostics.
Resolve Depending on the results from the troubleshooting steps above and enabling CryptoAPI
2.0 Diagnostics, ensure that the CA publishes CRLs correctly and that they are available to the
Online Responder service.
Event 0xC25D0011 - For configuration %1, Online Responder revocation provider either has no
CRL information or has stale CRL information.
Event ID 17
54
Event Name MSG_E_INVALID_CRL
Description The Online Responder service could not retrieve a CRL required for the specified
Diagnostics See diagnostics for event 16 above.
To learn how to enable CryptoAPI 2.0 Diagnostics and understand the CryptoAPI diagnostics
information, see Enabling CryptoAPI 2.0 Diagnostics.
Event 0xC25D0012 - For configuration %1, Online Responder revocation provider found a delta
CRL referring to a newer Base CRL.
Event ID 18
Event Name MSG_E_MISMATCHED_BASE_DELTA_CRL
Description This event indicates that the delta CRL and the base CRLs do not match. The
Online Responder service downloaded a delta CRL containing updates to a base CRL that
cannot be found. A delta CRL cannot be used without a corresponding base CRL; therefore, the
delta CRL is not valid.
Diagnostics The following reasons might cause this event:
• The CA has failed to publish the base CRL but published the delta CRL correctly.
• The Online Responder service could not retrieve the base CRL but could retrieve the delta
CRL.
Use the following steps to diagnose the problem:
1. Use the Online Responder snap-in to check the URLs for the base and delta CRLs. Follow
the steps outlined in event 16 above to make sure the CA and Online Responder URLs are
configured correctly for base and delta CRL publishing and retrieval.
2. Use the Certificates snap-in for the Online Revocation service account on the Online
Responder computer to locate the current delta CRL. Check the BaseCRLNumber specified
in the "delta CRL indicator" extension of the delta CRL. This number should reference the
version number of a published base CRL.
3. If this number does not match the version number of a published base CRL, republish both
the base and delta CRLs by typing the following command at a command prompt:
certutil –crl
4. Retrieve updated CRL data on the Online Responder. Either restart the Online Responder
service on each Array member or right-click Array Configuration in the Online Responder
55
snap-in and click Refresh Revocation Data. Then verify that the base and delta CRLs
match.
Note
If the problem persists, you can enable CryptoAPI 2.0 Diagnostics to diagnose the root of
the problem. For more information, see Enabling CryptoAPI 2.0 Diagnostics.
Online Responder Snap-In Messages
Array Configuration messages

The following events relate to the status of Array members and are displayed in the Array
Configuration view.
Message Offline
Description Offline status of an Array member means that the member could not be contacted to
retrieve the Online Responder properties or revocation configuration information.
Diagnose N/A
1. Ensure that the Array member computer is running.
2. Ensure that the Online Responder service (ocspsvc.exe) is running on the Array member
computer.
3. Check network connectivity to the Array member by using the Ping command-line tool.
4. Using the Dcomcnfg command-line tool, validate that the current user has the proper
permissions to the IOCSPAdmin interface.
Message Responder Properties not present on Array Controller.
Description This error can occur if Online Responder settings were deleted from the Array
controller and the current user does not have the necessary permissions to update the registry.
Diagnose N/A
Resolve A user with permissions to manage the Online Responder should open the Online
Responder snap-in. This will allow the synchronization engine to re-synchronize the properties
and revocation configurations of the Array.
Message Responder Properties are not synchronized.
Description This message is displayed if an Array member was offline while a revocation
configuration or Online Responder properties were changed.
56
Diagnose N/A
and revocation configurations of the Array.
Message Online
Description The Array member is functional.
Diagnose N/A
Resolve N/A
Message Status Unknown
Description Unknown Array member status is displayed if the Array controller is offline and the
Array member's properties or revocation configuration information cannot be evaluated. Note that
it does not necessarily mean that the Array member is not functional.
Diagnose N/A
1. Ensure that the Array controller computer is running.
2. Ensure that the Online Responder service (ocspsvc.exe) is running on the Array controller
computer.
3. Check network connectivity to the Array controller by using the Ping command-line tool.
Message Array Controller Name on Member is Incorrect.
Description This situation can occur if a new Array controller was assigned to the Array and the
security settings to the entire Array were modified while the Array member was offline.
Diagnose Follow this step to diagnose the problem:
• Validate that the current user has permissions to the IOCSPAdmin interface.
and revocation configurations of the Array. Right-click Array Configuration, and click
Synchronize Members with Array Controller to resynchronize the Online Responder's
configuration data to all Array members.
Message Array Member Name(s) on Member is Incorrect.
Description This situation can occur if a new Array member was added to the Array and the
security settings to the entire Array were modified while the Array member was offline.
Diagnose Follow this step to diagnose the problem:
• Validate that the current user has permissions to the IOCSPAdmin interface.
57
Resolve A user with permissions to manage the Online Responder should start the Online
and revocation configurations of the Array. Use the Synchronize members with array
controller action of the Array node to resynchronize the Online Responder's configuration data to
all Array members.
Revocation Configuration messages

The following events relate to the status of the revocation configuration and are displayed in the
Online Responder snap-in under the Revocation Configuration view.
Message Revocation Configuration is not synchronized with Array Controller.

Description This situation can occur if a revocation configuration was changed on the Array
controller while the Array member was offline.
Diagnose N/A
Resolve Synchronize the Array by using the Online Responder snap-in.
Message Revocation Configuration is missing on Array Controller.
Description This situation can occur if the Online Responder snap-in is targeted at an Array
member while the Array controller is offline.
Diagnose N/A
1. Ensure that the Array controller computer is running.
2. Ensure that the Online Responder service (ocspsvc.exe) is running on the Array controller
computer.
3. Check network connectivity to the Array controller by using the Ping command-line tool.
Message Revocation Configuration is missing on array member(s).
Description This situation can occur if the Online Responder snap-in is targeted at the Array
controller while the Array member is offline.
Diagnose Follow these steps to diagnose the problem:
1. Ensure that the Array member computer is running.
2. Ensure that the Online Responder service (ocspsvc.exe) is running on the Array member
computer.
3. Check network connectivity to the Array member by using the Ping command-line tool.
58
Resolve If the Array member is online and available, use the Synchronize members with array
controller action of the Array node to resynchronize the Online Responder's configuration data to
all Array members.
Message Working
Description "Working" status means that the revocation configuration is functioning as expected.
Diagnose N/A
Resolve N/A
Message Bad signing certificate on Array Controller.
Description This message occurs when the Online Responder service encounters a problem
either locating or loading a specific configuration's signing certificate.
Diagnose For diagnostics steps, see event 23 above.
Resolve For resolution steps, see event 23 above.
Message Bad signing certificate on member(s).
Description This message occurs when the Online Responder service encounters a problem
either locating or loading a specific configuration's signing certificate.
Diagnose For diagnostics steps, see event 23 above.
Resolve For resolution steps, see event 23 above.
Message Signing certificate status is not yet available for the Array Controller.
Description This message indicates that a signing certificate is not available for the specified
Diagnose This message can appear after creating or renaming a revocation configuration or after
changing signing properties.
Resolve Refresh the information in the Online Responder snap-in by clicking Refresh in the
Actions pane.
Message Signing certificate status is not yet available for member(s).
Description This message indicates that a signing certificate is not available for the specified
Diagnose This message can appear after creating or renaming a revocation configuration or after
changing signing properties.
Resolve Refresh the start page by clicking Refresh in the Actions pane.
Message Revocation provider is not working on the Array Controller.
Description This message indicates that a revocation provider is incorrectly configured on the
Array controller.
Diagnose N/A
1. Open the revocation provider properties for the specified revocation configuration.
59
2. Validate that all parameters are correct and within the permitted value range.
Message OCSP signing templates could not be retrieved. %(ErrorMessage).
Description This message indicates that the Online Responder service was not able to retrieve a
list of certificate templates able to issue OCSP Response Signing certificates. Because of this,
the Online Responder service is not able to enroll for a signing certificate.
Diagnose Follow these steps to diagnose the problem:
1. Verify that the computer on which the Online Responder service is running has connectivity
to a CA. Use the Certification Authority snap-in on the CA to verify that the CA is configured
to issue certificates based on the OCSP Response Signing template.
2. Use the Certificate Templates snap-in to verify that the computer running the Online
Responder has Read, Enroll, and Autoenroll permissions on the OCSP Response Signing
template.
1. Configure the CA to issue certificates based on the OCSP Response Signing template.
2. Use the Certificate Templates snap-in to grant the computer running the Online Responder
Read, Enroll, and Autoenroll permissions on the OCSP Response Signing template.
Enabling CryptoAPI 2.0 Diagnostics

CryptoAPI 2.0 Diagnostics is a new feature in Windows Vista and Windows Server 2008 that
makes it easier to troubleshoot PKI-related problems. It logs information about certificate chain
building and revocation into the Event Viewer in more detail than previous CryptoAPI
troubleshooting tools.
CryptoAPI 2.0 Diagnostics logs events that generally correspond to the CryptoAPI 2.0 APIs that
are being called. In addition to the parameters and results of these APIs, it also logs details such
as all network retrieval attempts, HTTP errors, and proxy events. If you see problems related to
CryptoAPI 2.0 in your application, use this feature to reproduce the problem.
You can enable this feature from the Event Viewer or by using command-line scripts.
To enable CryptoAPI 2.0 Diagnostics from the Event Viewer

1. To open the Event Viewer, click Start, right-click My Computer, and then click Manage.
Event Viewer is in the Computer Management window under System Tools.
Note
Event Viewer is an MMC snap-in and you need administrative privileges to
access it.
2. In the Event Viewer, navigate to Application Logs, Microsoft, Windows, and then
CryptoAPI 2.0 for the CryptoAPI 2.0 channel.
60
3. Right-click Operational, and then click Log Properties.
4. Select the Enable Logging check box. This enables CryptoAPI 2.0 Diagnostics logging.
5. To save the log to a file, right-click Operational, and then click Save Log File as.
You can save the log file in the .elf format (which can be opened by using the Event
Viewer) or in the standard .xml format.
6. If data is present in the logs before you reproduce the problem, it is recommended that
you clear the logs. This allows only the data relevant to the problem to be collected from
the saved logs. To clear the logs, right-click Operational, and then click Clear Log.
You can also enable logging and save the logs using the wevtutil.exe tool.
To enable CryptoAPI 2.0 Diagnostics by using command-line scripts

1. Right-click the command prompt program icon, and click Run as administrator.
2. At the command prompt, use the following commands:
• To enable logging, type:
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true
• To save the log to a file, type:

wevtutil.exe epl Microsoft-Windows-CAPI2/Operational filename.elf
• To disable logging, type:

wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false
• To clear logs, type:

wevtutil.exe cl Microsoft-Windows-CAPI2/Operational
Additional Resources
• Internet X.509 Public Key Infrastructure – Certificate and Certificate Revocation List (CRL)
Profile (http://go.microsoft.com/fwlink/?LinkID=71066)
• RFC 2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol -
OCSP" (http://go.microsoft.com/fwlink/?LinkID=71068)
• The Internet Engineering Task Force (http://go.microsoft.com/fwlink/?LinkID=121)
• Windows Server 2008 CA Enhancements (http://go.microsoft.com/fwlink/?LinkID=83212)
61
Server Core Installation Option of Windows
Server 2008 Step-By-Step Guide
Published: October 2007
Author: Jaime Ondrusek
Abstract
This step-by-step guide provides the instructions you need to build a server in your test lab based
on the Server Core installation option of the Windows Server® 2008 operating system. This
includes installing and performing the initial configuration of the Server Core installation, installing
server roles or features, and managing a server that is running a Server Core installation.
1
2
Contents
Server Core Installation Option of Windows Server 2008 Step-By-Step Guide .............................. 5
What is a Server Core installation? .............................................................................................. 5
What’s new in the Server Core installation option? .................................................................. 5
Who should use this guide?...................................................................................................... 6
Benefits of a Server Core installation ....................................................................................... 6
In this guide............................................................................................................................... 6
Deploying a Server Core installation: Overview........................................................................... 6
Prerequisites for deploying a Server Core installation.............................................................. 7
Known issues for deploying a Server Core installation ............................................................ 7
Steps for manually installing a Server Core installation ........................................................... 7
Using an unattend file to install a Server Core installation ....................................................... 7
Configuring a Server Core installation: Overview ........................................................................ 8
Administrative credentials ......................................................................................................... 8
Known issues for configuring a Server Core installation .......................................................... 8
Steps for configuring a Server Core installation ....................................................................... 9
Installing a server role on a server running Server Core installation: Overview ........................ 11
Prerequisites for installing a server role on a server running Server Core installation........... 12
Known issues for installing a server role on a Server Core installation.................................. 12
Steps for installing a server role on a Server Core installation ............................................... 13
Available server roles .......................................................................................................... 13
DNS Server role .................................................................................................................. 13
DHCP Server role ................................................................................................................ 14
File Services role ................................................................................................................. 14
Print Services role ............................................................................................................... 15
Active Directory Lightweight Directory Services role........................................................... 16
Active Directory Domain Services role ................................................................................ 16
Streaming Media Services role ........................................................................................... 16
Web Server (IIS) role ........................................................................................................... 17
Installing Windows Features: Overview ..................................................................................... 17
Prerequisites for installing an optional feature on a server running a Server Core installation
............................................................................................................................................. 18
Known issues for installing an optional feature on a server running a Server Core installation
............................................................................................................................................. 18
Steps for installing an optional feature on a server running a Server Core installation.......... 19
Available optional features .................................................................................................. 19
Managing a Server Core installation: Overview ......................................................................... 20
Prerequisites for managing a server running Server Core installation ................................... 20
3
Known issues for managing a server running a Server Core installation ............................... 20
Steps for managing a Server Core installation ....................................................................... 22
Administering a Server Core installation .................................................................................... 25
Prerequisites for administering a Server Core installation ..................................................... 26
Known issues for administering a Server Core installation .................................................... 26
Steps for administering a Server Core installation ................................................................. 26
Configuration and installation .............................................................................................. 26
Networking and firewall ....................................................................................................... 29
Updates, error reporting, and feedback .............................................................................. 30
Services, processes, and performance ............................................................................... 31
Event logs ............................................................................................................................ 32
Disk and file system............................................................................................................. 33
Hardware ............................................................................................................................. 34
Logging bugs and feedback ....................................................................................................... 34
Additional references ................................................................................................................. 35
Appendix A: Sample Server Core installation - Unattend.xml ................................................... 37
4
Server Core Installation Option of Windows
Server 2008 Step-By-Step Guide
This step-by-step guide provides instructions for building a server in your test lab that is based on
the Server Core installation option of the Windows Server® 2008 operating system. It includes
information about installation, initial configuration, and managing a server that is running a Server
Core installation.
What is a Server Core installation?

The Server Core installation option is a new option that you can use for installing Windows
Server 2008. A Server Core installation provides a minimal environment for running specific
server roles, which reduces the maintenance and management requirements and the attack
surface for those server roles. A server running a Server Core installation supports the following
server roles:
• Active Directory Domain Services (AD DS)
• Active Directory Lightweight Directory Services (AD LDS)
• DHCP Server
• DNS Server
• File Services
• Print Services
• Streaming Media Services
• Web Server (IIS)
To accomplish this, the Server Core installation option installs only the subset of the binary files
that are required by the supported server roles. For example, the Explorer shell is not installed as
part of a Server Core installation. Instead, the default user interface for a server running a Server
Core installation is the command prompt.
What’s new in the Server Core installation option?

The Server Core installation option of Windows Server 2008 requires initial configuration at a
command prompt. A Server Core installation does not include the traditional full graphical user
interface. Once you have configured the server, you can manage it locally at a command prompt
or remotely using a Terminal Server connection. You can also manage the server remotely using
the Microsoft Management Console (MMC) or command-line tools that support remote use.
5
Who should use this guide?
The target audience for the Server Core installation option of Windows Server 2008 includes:
• IT planners and analysts who are technically evaluating the product.
• Enterprise IT planners and designers for organizations.
• IT professionals who are managing the AD DS, AD LDS, DHCP Server, DNS Server, File
Services, Print Services, Streaming Media Services, and Web Server (IIS) roles.
Benefits of a Server Core installation

The Server Core installation option of Windows Server 2008 provides the following benefits:
• Reduced maintenance. Because the Server Core installation option installs only what is
required to have a manageable server for the AD DS, AD LDS, DHCP Server, DNS Server,
File Services, Print Services, and Streaming Media Services roles, less maintenance is
required than on a full installation of Windows Server 2008.
• Reduced attack surface. Because Server Core installations are minimal, there are fewer
applications running on the server, which decreases the attack surface.
• Reduced management. Because fewer applications and services are installed on a server
running the Server Core installation, there is less to manage.
• Less disk space required. A Server Core installation requires only about 1 gigabyte (GB) of
disk space to install and approximately 2 GB for operations after the installation.
In this guide
• Deploying a Server Core installation: Overview
• Configuring a Server Core installation: Overview
• Installing a server role on a server running a Server Core installation: Overview
• Installing Windows Features: Overview
• Managing a Server Core installation: Overview
• Administering a Server Core installation
• Logging bugs and feedback
• Additional references
• Appendix A: Sample Server Core installation - Unattend.xml
Deploying a Server Core installation: Overview

In this scenario, you will create a server running a Server Core installation. There are no special
settings or differences between installing Windows Server 2008 and a Server Core installation.
6
Prerequisites for deploying a Server Core installation
To complete this task, you will need the following:
• The Windows Server 2008 installation media
• A valid product key
• A computer on which you can perform a clean Server Core installation
Known issues for deploying a Server Core installation

• There is no way to upgrade from a previous version of the Windows Server operating system
to a Server Core installation. Only a clean installation is supported.
• There is no way to upgrade from a full installation of Windows Server 2008 to a Server Core
installation. Only a clean installation is supported.
• There is no way to upgrade from a Server Core installation to a full installation of Windows
Server 2008. If you need the Windows® user interface or a server role that is not supported
in a Server Core installation, you will need to install a full installation of Windows
Server 2008.
Steps for manually installing a Server Core installation

Follow this procedure to install a Server Core installation of Windows Server 2008 Beta 3.
To install a Server Core installation

1. Insert the appropriate Windows Server 2008 installation media into your DVD drive.
2. When the auto-run dialog box appears, click Install Now.
3. Follow the instructions on the screen to complete Setup.
Using an unattend file to install a Server Core installation

Using an unattend file for a Server Core installation enables you to perform most of the initial
configuration tasks during Setup. Performing an unattended Server Core installation provides the
following benefits:
• There is no need to perform the initial configuration by using command-line tools.
• You can include the settings in the unattend file to enable remote administration (when Setup
is complete).
• You can configure settings that cannot be easily modified at a command prompt, such as
display resolution.
To install a Server Core installation by using an unattend file

1. Create a .xml file titled Unattend.xml by using a text editor or Windows System Image
7
Manager.
2. Copy the Unattend.xml file to a local drive or shared network resource.
3. Boot your computer to Windows Preinstallation Environment (Windows PE), Windows
Server 2003, or Windows XP.
4. Insert the media disk with the Server Core installation of Windows Server 2008 Beta 3
into your hard disk drive. If the auto-run setup window appears, click Cancel.
5. At a command prompt, change to the drive that contains the installation media.
6. Type the following at a command prompt:
setup /unattend:<path>\unattend.xml
where path is the path to your Unattend.xml file.
7. Allow Setup to complete.
Note
Appendix A of this document contains a sample unattend file with comments that
explain the settings in the sample configuration. This sample can be modified for
use in your environment.
Configuring a Server Core installation: Overview

Because a Server Core installation does not include the Windows user interface, there is no "out-
of-box experience" to help you complete the server configuration. Instead you must manually
complete the configuration using the command-line tools as outlined in the following steps.
Note
You can use an unattended setup to configure these settings during installation. For more
information about unattended settings, see the Windows Automated Installation Kit
(Windows AIK) (http://go.microsoft.com/fwlink/?LinkId=81030).
Administrative credentials
If you are going to join a server running a Server Core installation to an existing Windows domain,
you need a user name and password for an account that has the administrative credentials to join
a computer to the domain.
Known issues for configuring a Server Core installation

• If you close all command prompts, you will have no way to manage the Server Core
installation. To recover, you can press CTRL+ALT+DEL, click Start Task Manager, click
File, click Run, and type cmd.exe. Alternatively, you can log off and log back on again.
8
• Because there is no Web browser, you cannot activate a Server Core installation or access
the Internet through a firewall that requires users to log on.
Steps for configuring a Server Core installation

The following procedures explain how to configure a computer running a Server Core installation.
The steps include:
• Setting the administrative password
• Setting a static IP address
Note
A DHCP address is provided by default. You should perform this procedure only if you
need to set a static IP address.
• Joining a domain
• Activating the server
• Configuring the firewall
To set the administrative password

1. When your computer starts for the first time after the installation completes, press
CTRL+ALT+DEL. Type Administrator for the user name and leave the password blank.
2. The system will inform you that the password has expired and will prompt you to enter a
new password.
3. Type an appropriate password.
To set a static IP address

1. At a command prompt, type the following:
netsh interface ipv4 show interfaces
2. Make a note of the number shown in the Idx column of the output for your network
adapter. If your computer has more than one network adapter, make a note of the
number corresponding to the network adapter for which you wish to set a static IP
address.
3. At the command prompt, type:
netsh interface ipv4 set address name="<ID>" source=static address=<StaticIP>
mask=<SubnetMask> gateway=<DefaultGateway>
Where:
ID is the number from step 2 above
StaticIP is the static IP address that you are setting
SubnetMask is the subnet mask for the IP address
9
DefaultGateway is the default gateway
netsh interface ipv4 add dnsserver name="<ID>" address=<DNSIP>index=1
Where:
ID is the number from step 2 above
DNSIP is the IP address of your DNS server
5. Repeat step 4 for each DNS server that you want to set, incrementing the index=
number each time.
Notes
• If you set the static IP address on the wrong network adapter, you can change back to
using the DHCP address supplied by using the following command:
• netsh interface ipv4 set address name="<ID>" source=dhcp
• where ID is the number of the network adapter from Step 2.
To join a domain
netdom join <ComputerName> /domain:<DomainName> /userd:<UserName>
/passwordd:*
Where:
ComputerName is the name of the server that is running the Server Core installation.
DomainName is the name of the domain to join.
UserName is a domain user account with permission to join the domain.
2. When prompted to enter the password, type the password for the domain user account
specified by UserName.
3. If you need to add a domain user account to the local Administrators group, type the
following command:
net localgroup administrators /add <DomainName>\<UserName>
4. Restart the computer. You can do this by typing the following at a command prompt:
shutdown /r /t 0
To rename the server

1. Determine the current name of the server with the hostname or ipconfig command.
netdom renamecomputer <ComputerName> /NewName:<NewComputerName>
3. Restart the computer.
10
To activate the server
• At a command prompt, type:
slmgr.vbs -ato
If activation is successful, no message will return in the command prompt.
Notes
• You can also activate by phone, using a KMS server, or remotely by typing the following
command at a command prompt of a computer that is running Windows Vista or
Windows Server 2008:
• cscript windows\system32\slmgr.vbs <ServerName> <UserName> <password>:-ato
To configure the firewall

• Use the netsh advfirewall command. For example, to enable remote management from
any MMC snap-in, type the following:
netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
Notes
• You can also use the Windows Firewall snap-in from a Windows Vista or Windows
Server 2008 computer to remotely manage the firewall on a server running a Server Core
installation. To do this, you must first enable remote management of the firewall by
running the following command on the computer running a Server Core installation:
• netsh advfirewall set currentprofile settings remotemanagement enable
Installing a server role on a server running Server

Core installation: Overview
After the Server Core installation is complete and the server is configured, you can install one or
more server roles. The Server Core installation of Windows Server 2008 supports the following
server roles:
• Active Directory Domain Services (AD DS)
• Active Directory Lightweight Directory Services (AD LDS)
• DHCP Server
• DNS Server
• File Services
• Print Services
• Streaming Media Services
11
More information about the command-line tools for configuring the server roles is available in the
Additional references section at the end of this guide.
Note
This section includes a procedure for each server role in the previous list. You need to
complete the procedure(s) for only the server roles that you want to install.
Prerequisites for installing a server role on a server running

Server Core installation
To complete this task, you need the following:
• A computer on which you have installed and configured a Server Core installation of
Windows Server 2008.
• An administrator user account and password for the server running the Server Core
installation.
• If installing and configuring a print server, another computer running Windows Vista or
Windows Server 2008 on which you can run the Print Management Console to remotely
configure the print server.
• If installing and configuring a DHCP server, the information required to configure a DHCP
scope.
• If installing and configuring a DHCP server, you must configure the server running the Server
Core installation to use a static IP Address.
• If installing and configuring a DNS server, the information required to configure a DNS zone.
• If installing and configuring an Active Directory environment, the information required to either
join an existing domain or to create a new domain.
• If you are going to promote the server running the Server Core installation to be a domain
controller in an Active Directory domain, a domain administrator user name and password.
Known issues for installing a server role on a Server Core

installation
• You cannot use the Active Directory Domain Controller Installation Wizard (Dcpromo.exe) on
a server running Server Core installation. You must use an unattend file with Dcpromo.exe to
install or remove the domain controller role.
Alternately, you can run Dcpromo.exe on another Windows Server 2008 computer and use
the wizard to save an unattend file that you can then use on the server running Server Core
installation.
• Dcpromo.exe will restart the computer immediately when the installation is complete or when
Active Directory is removed unless RebootOnCompletion=No is included in the answer file.
12
• The Web Server (IIS) role does not support ASP.NET in Server Core installations. Because
there is no support for managed code, the following IIS features are not available in Server
Core installations:
• IIS-ASPNET
• IIS-NetFxExtensibility
• IIS-ManagementConsole
• IIS-ManagementService
• IIS-LegacySnapIn
• IIS-FTPManagement
• WAS-NetFxEnvironment
• WAS-ConfigurationAPI
Steps for installing a server role on a Server Core installation

To install a server role on a Server Core installation of Windows Server 2008, perform the
procedure for the desired role as follows.
Note
Ocsetup.exe syntax is case sensitive so be sure to follow the examples explicitly.
Available server roles

To discover the available server roles, open a command prompt and type the following:
oclist
This command lists the server roles and optional features that are available for use with
Ocsetup.exe. It also lists the server roles and optional features that are currently installed.
DNS Server role
To install the DNS Server role

start /w ocsetup DNS-Server-Core-Role
Note
Using /w prevents the command prompt from returning until the installation
completes. Without /w, there is no indication that the installation completed.
2. Configure a DNS zone at the command prompt by typing dnscmd or by remotely using
the DNS MMC snap-in.
13
Note
Typing start /w ocsetup DNS-Server-Core-Role /uninstall at the command prompt will
uninstall the DNS Server role.
DHCP Server role
To install the DHCP Server role

start /w ocsetup DHCPServerCore
2. Configure a DHCP scope at the command prompt by using netsh, or by remotely using
the DHCP snap-in from Windows Server 2008.
3. If the DHCP server is installed in an Active Directory domain, you must authorize it in
Active Directory.
The DHCP Server service does not start automatically by default. Use the following procedure to
configure it to start automatically and to start the service for the first time.
To configure and start the DHCP Server service

sc config dhcpserver start= auto
2. Start the service by typing:
net start dhcpserver
Note
Typing start /w ocsetup DHCPServerCore /uninstall at the command prompt will
uninstall the DHCP Server role.
File Services role

The Server service is installed by default to provide administrative share support for management
tools. To install additional file server features use the following commands:
To install File Services role features

• For File Replication service, type the following at a command prompt:
start /w ocsetup FRS-Infrastructure
• For Distributed File System service, type:
start /w ocsetup DFSN-Server
• For Distributed File System Replication, type:
14
start /w ocsetup DFSR-Infrastructure-ServerEdition
• For Services for Network File System (NFS), type:
start /w ocsetup ServerForNFS-Base
start /w ocsetup ClientForNFS-Base
Note
Uninstall any file server role options by using these commands with the /uninstall option.
Print Services role
To install Print Services role features

• For the Print Server feature, type the following at a command prompt:
start /w ocsetup Printing-ServerCore-Role
• For the Line Printer Daemon (LPD) service, type:
start /w ocsetup Printing-LPDPrintService
To add a printer to the print server

1. Determine the IP address or host name of the printer. This may be on the printer's test or
printer configuration page or you might need to refer to the manufacturer's documentation
for instructions.
2. Verify that the print server can communicate with the printer through the network by
pinging the printer from the print server.
3. On another computer running Windows Vista or Windows Server 2008, open the Print
Management console and add the server running the Server Core installation.
4. Expand the entry for the print server running a Server Core installation, right-click
Drivers, and then click Add Driver. The Add Printer Driver Wizard starts.
5. Complete the wizard to install the printer driver for your printer.
6. In the Print Management console, right-click Printers and then click Add Printer. The
Network Printer Installation Wizard starts.
7. Click Add a TCP/IP or Web Services printer by IP address or hostname and then
click Next.
8. Enter the printer's host name or IP address (the port name will be the same by default),
9. Make any necessary changes to the printer name, contact information, or sharing status,
15
Active Directory Lightweight Directory Services role
To install the AD LDS role

start /w ocsetup DirectoryServices-ADAM-ServerCore
Notes
• Uninstall the AD LDS role by typing the following at a command prompt:
• start /w ocsetup DirectoryServices-ADAM-ServerCore /uninstall
Active Directory Domain Services role

This command installs the Active Directory Domain Services role and promotes the server to a
domain controller by using the settings in the unattend file.
For links to information about using an unattend file with Dcpromo.exe, see the Additional
References section at the end of this document.
To install the Active Directory Domain Services role

dcpromo /unattend:<unattendfile>
Where unattendfile is the name of a Dcpromo.exe unattend file.
Note
Dcpromo.exe can also be used to demote a domain controller to a server.
Streaming Media Services role
To install the Streaming Media Services role

1. On another computer, download the Streaming Media Services role installer file from
article 934518 in the Microsoft Knowledge Base
2. Copy the appropriate Microsoft Update Standalone package (.msu file) to your Server
Core installation.
3. Run the .msu file.
start /w ocsetup MediaServer
5. On a different computer, use the Streaming Media Services MMC snap-in to remotely
configure Streaming Media Services.
16
Web Server (IIS) role
To install the Web Server role

1. For the default installation, type the following at a command prompt and press ENTER:
start /w pkgmgr /iu:IIS-WebServerRole;WAS-WindowsActivationService;WAS-
ProcessModel
2. For an installation that includes all of the options, type the following at a command
prompt and press ENTER:
start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-
StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-
HttpRedirect;IIS-ApplicationDevelopment;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-
ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-
LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-
ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-
DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-
IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-
IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-
HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-
ManagementScriptingTools;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-
WMICompatibility;IIS-LegacyScripts;IIS-FTPPublishingService;IIS-FTPServer;WAS-
WindowsActivationService;WAS-ProcessModel
Notes
• To uninstall the Web Server (IIS) role, use the following command:
• start /w pkgmgr /uu:IIS-WebServerRole;WAS-WindowsActivationService;WAS-
ProcessModel
Installing Windows Features: Overview

After the Server Core installation is complete and the server is configured, you can install one or
more optional features. The Server Core installation of Windows Server 2008 supports the
following optional features:
• Failover Clustering
• Network Load Balancing
• Subsystem for UNIX-based applications
• Backup
• Multipath IO
• Removable Storage
• Bitlocker Drive Encryption
17
• Simple Network Management Protocol (SNMP)
• Windows Internet Name Service (WINS)
• Telnet client
The following procedure describes how to install these features on a server running a Server
Core installation.
Note
Failover Clustering is not available in Windows Server 2008 Standard Edition.
Prerequisites for installing an optional feature on a server

running a Server Core installation
The following optional features require appropriate hardware:
• Failover Clustering
• Network Load Balancing
• Multipath IO
• Removable Storage
• Bitlocker Drive Encryption
Note
For more information about the hardware that is required for optional features, see the
Additional References section at the end of this document.
There are no prerequisites for the following optional features:
• Subsystem for UNIX-based applications
• Backup
• Simple Network Management Protocol (SNMP)
• Windows Internet Name Service (WINS)
• Telnet client
Known issues for installing an optional feature on a server

There are no known issues for installing an optional feature on a Server Core installation of
18
Steps for installing an optional feature on a server running a
Server Core installation
To install an optional feature on a Server Core installation of Windows Server 2008, perform the
following procedure.
Note
The Ocsetup.exe syntax is case sensitive so be sure to follow the examples explicitly.
Available optional features

To discover the available optional features, open a command prompt and type the following:
Oclist
This command lists the server roles and optional features that are available for use with
Ocsetup.exe. It also lists the server roles and optional features that are currently installed.
To install an optional feature

start /w ocsetup <featurename>
Where featurename is the name of a feature from the following list:
• Failover Clustering: FailoverCluster-Core
• Network Load Balancing: NetworkLoadBalancingHeadlessServer
• Subsystem for UNIX-based applications: SUACore
• Multipath IO: MultipathIo
• Removable Storage: Microsoft-Windows-RemovableStorageManagementCore
• Bitlocker Drive Encryption: BitLocker
Notes
To install the remote administration tool for BitLocker, type the following at a command
prompt:
start /w ocsetup BitLocker-RemoteAdminTool
• Backup: WindowsServerBackup
• Simple Network Management Protocol (SNMP): SNMP-SC
• Windows Internet Name Service (WINS): WINS-SC
• Telnet client: TelnetClient
19
Note
To remove an optional feature, use start /w ocsetup with the appropriate role name and
the /uninstall switch.
Managing a Server Core installation: Overview

You can manage a server running Server Core installation in the following ways:
• Locally and remotely using a command prompt. By using the Windows command-line
tools at a command prompt, you can manage servers running a Server Core installation.
• Remotely using Terminal Server. By using another computer running Windows, you can
use the Terminal Server client to connect to a server running a Server Core installation, and
manage it remotely. The shell in the Terminal Server session will be the command prompt.
• Remotely using Windows Remote Shell. By using another computer running
Windows Vista or Windows Server 2008, you can use Windows Remote Shell to run
command-line tools and scripts on a server running a Server Core installation.
• Remotely using an MMC snap-in. By using an MMC snap-in from a computer running
Windows Vista or Windows Server 2008, you can connect to a server running Server Core
installation in the same way that you would connect to any computer running Windows.
Prerequisites for managing a server running Server Core

installation
To manage a server running Server Core installation, you need:
• A computer that has a Server Core installation of Windows Server 2008 installed and
configured.
• An administrator user account and password for a server running a Server Core installation.
Known issues for managing a server running a Server Core

installation
• Not all tasks can be performed at a command prompt or remotely through an MMC snap-in.
There is a script included with the Server Core installation of Windows Server 2008 that you
can use to configure the following settings:
• Enable automatic updates
• Enable Remote Desktop for Administration
• Enable Terminal Server clients on previous versions of Windows to connect to a server
• Configure DNS SRV record weight and priority
• Manage IPSec Monitor remotely
20
The script is located in the \Windows\System32 folder of a server running a Server Core
installation. At a command prompt, open the folder, and then use the following command to
display the usage instructions for the previous options:
cscript scregedit.wsf /?
Note
You can use this command with the /cli option to display a list of common command-line
tools and their usage.
• If you close all Command Prompt windows, to open a new Command Prompt window, you
can press CTRL+ALT+DEL, click Start Task Manager, click File, click Run, and then type
cmd.exe. Alternatively, you can log off and log back on.
• Any command or tool that attempts to launch Windows Explorer will not work. For example,
start . used from a command prompt will not work.
• TheRunonce feature is not supported in Server Core installations.
• There is no support for HTML rendering or HTML help in Server Core installations.
• Server Core installations do not support running managed code. Any management tools and
utilities that run locally on a server running a Server Core installation must be written in native
Win32 code.
• Server Core installations do not generate any notifications for activation, new updates, or
password expiration because these notifications require the Windows Explorer shell, which is
not part of the Server Core installation.
• If you need to write a script for managing a server running a Server Core installation, which
requires the secure inclusion of an administrative password, see the scripting column on
Microsoft TechNet (http://go.microsoft.com/fwlink/?LinkID=56421).
• Server Core installations support Windows Installer in quiet mode so that you can install tools
and utilities from Windows Installer files.
• Windows Firewall can be configured at a command prompt by using netsh advfirewall.
• When installing Windows Installer packages on a server running a Server Core installation,
use the /qb option to display the basic user interface.
• To change the time zone on a computer running a Server Core installation of Windows
Server 2008, run control timedate.cpl.
• To change international settings on a computer running a Server Core installation of
Windows Server 2008, run control intl.cpl.
• To use the Disk Management MMC snap-in remotely, start the Virtual Disk Service on a
server running a Server Core installation. To do this, type the following at a command
prompt:
net start VDS
• Control.exe will not run on its own. You must run it with either Timedate.cpl or Intl.cpl.
21
• Winver.exe is not available in Server Core installations. To obtain version information use
Systeminfo.exe.
Steps for managing a Server Core installation

The following procedures explain methods for managing a server running a Server Core
installation, including:
• Managing a server running a Server Core installation locally at a command prompt
• Managing a server running a Server Core installation remotely at a command prompt
• Managing a server running a Server Core installation by using Windows Remote Shell
• Managing a server running a Server Core installation by using Microsoft Management
Console (MMC)
• Adding hardware to a server running a Server Core installation
• Obtaining a list of drivers installed on a server running a Server Core installation
• Installing the DNS server role
To manage a server running a Server Core installation locally at a command prompt

1. Start a server running a Server Core installation.
2. Log on using an administrator account.
3. At the command prompt, use the appropriate command-line tool for the task you want to
complete.
Notes
• For more information about command-line tools, see "Steps for administering a Server
Core installation" later in this document.
• You can find further information at the Command-Line Reference A-Z ().
To manage a server running a Server Core installation by using a terminal server

1. On the server running a Server Core installation, type the following command at a
command prompt:
cscript C:\Windows\System32\ Scregedit.wsf /ar 0
This enables the Remote Desktop for Administration mode to accept connections.
2. On another computer, click Start, click Run, type mstsc, and then click OK.
3. In Computer, enter the name of the server running a Server Core installation, and click
Connect.
4. Log on using an administrator account.
5. When the command prompt appears, you can manage the computer using the Windows
22
command-line tools.
6. When you have finished remotely managing the computer, type logoff in the command
prompt to end your Terminal Server session.
Notes
• If you are running the Terminal Services client on a previous version of Windows, you
must turn off the higher security level that is set by default in Windows Server 2008. To
do this, after step 1, type the following command at the command prompt:
• cscript C:\Windows\System32\Scregedit.wsf /cs 0
Notes
• For more information about command-line tools, see "Steps for administering a Server
Core installation" later in this document.
• You can find further information at the Command-Line Reference A-Z ().
Often it is useful to run Cmd.exe in a Command Prompt window on your local computer, rather
than in the Terminal Services client. To do this, you need a standard Windows Server 2008
installation and the latest Terminal Services client.
To use TS RemoteApp to publish cmd.exe to your local computer

1. Add the Terminal Services role to the standard Windows Server 2008 computer using
Server Manager.
2. Start MMC on the standard Windows Server 2008 computer, add the TS RemoteApp
snap-in, and then connect the snap-n to a server running a Server Core installation.
3. In the Action pane of the snap-in, click Add Remote Programs, and then navigate to
\\<ServerName>\c$\windows\system32\cmd.exe (where ServerName is the name of the
server running a Server Core installation).
4. In the Allow list, select Remote cmd.exe, and then select Create RDP package.
5. Connect to the server running a Server Core installation by using the Remote Desktop
Protocol package.
To manage a server running a Server Core installation by using the Windows Remote
Shell
1. To enable Windows Remote Shell on a server running a Server Core installation, type the
following command at a command prompt:
WinRM quickconfig
2. On another computer, at a command prompt, use WinRS.exe to run commands on a
server running a Server Core installation. For example, to perform a directory listing of
23
the Windows folder, type:
winrs -r:<ServerName> dir c:\windows
Where:
ServerName is the name of the server running a Server Core installation.
Note
The WinRM quickconfig setting enables a server running a Server Core installation to
accept Windows Remote Shell connections. This setting can also be set in an unattend
file. See the example in Appendix A at the end of this document.
Important
• For more information about using different security credentials to run commands, see the
command-line help for WinRS.exe by typing winrs -? at a command prompt.
To manage a server running a Server Core installation by using an MMC snap-in

1. If the server running a Server Core installation is not a member of a domain, establish
alternate credentials to use to connect to the Server Core installation by typing the
following command at a command prompt on your client computer:
cmdkey /add:<servername> /user:<username> /pass:<password>
Where:
ServerName is the name of the server running a Server Core installation.
UserName is the name of an administrator account.
To be prompted for a password, omit the /pass option.
2. When prompted, enter the password for the user name that is specified in the previous
step.
3. Start an MMC snap-in, such as Computer Management.
4. In the left pane, right-click the top of the tree and click Connect to another computer.
(In the Computer Management example, you would right click Computer Management
(Local).)
5. In Another computer, type the computer name of the server running a Server Core
installation and click OK.
6. You can now use the MMC snap-in to manage the server running a Server Core
installation as you would any other computer running a Windows Server operating
system.
To add hardware to a server running a Server Core installation

1. Follow the instructions provided by the hardware vendor for installing new hardware:
• If the driver for the hardware is included in Windows Server 2008 Beta 3, Plug and
24
Play will start and install the driver.
• If the driver for the hardware is not included, proceed with the steps 2 and 3.
2. Copy the driver files to a temporary folder on the server running a Server Core
installation.
3. At a command prompt, open the folder where the driver files are located, and then run
the following command:
pnputil -i -a <driverinf>
Where:
driverinf is the file name of the .inf file for the driver.
4. If prompted, restart the computer.
To obtain a list of drivers that are installed on the server running a Server Core
installation
sc query type= driver
Note
You must include the space after the equal sign for the command to complete
successfully.
To disable a device driver on a server running a Server Core installation

sc delete <service_name>
Where:
service_name is the name of the service that you obtain by running sc query type=
driver.
Administering a Server Core installation

This section focuses on common administrative tasks that are performed locally or remotely from
a command prompt. The commands are grouped into the following sections:
• Configuration and installation
• Networking and firewall
• Updates and error reporting
• Services, processes and performance
• Event logs
• Disk and file system
25
• Hardware
• Remote administration
Prerequisites for administering a Server Core installation

To complete this task, you need:
• A computer on which you have installed and configured a Server Core installation of
Windows Server 2008
• An administrator user account and password for the server running a Server Core installation
Known issues for administering a Server Core installation

• Server Core installation supports Windows Installer in quiet mode so that you can install tools
and utilities from Windows Installer files.
• To use the Disk Management MMC snap-in remotely, start the Virtual Disk Service on a
server running a Server Core installation. To do this, type the following at a command
prompt:
net start VDS
• If you need to write a script for managing a server running a Server Core installation, which
requires the secure inclusion of an administrative password, see the scripting column on
Microsoft TechNet (http://go.microsoft.com/fwlink/?LinkID=56421).
Steps for administering a Server Core installation

The following procedures summarize common administrator tasks for a server running a Server
Core installation.
Configuration and installation
Task Steps
Set the local administrative password At a command prompt, type:

net user administrator *
Join a computer to a domain 1. At a command prompt, type on one line:

netdom join %computername%
/domain:<domain>
/userd:<domain>\username> /password:*
Confirm that the domain has changed At a command prompt, type:
26
Task Steps
set
Remove a computer from a domain At a command prompt, type:

netdom remove
Add a user to the local Administrators At a command prompt, type:

group. net localgroup Administrators /add
<domain>\<username>
Remove a user from the local At a command prompt, type:

Administrators group net localgroup Administrators /delete
<domain\username>
Add a user to the local computer At a command prompt, type:

net user <domain\user name> /add *
Add a group to the local computer At a command prompt, type:

net localgroup <group name> /add
Change the name of a domain-joined At a command prompt, type:

computer netdom renamecomputer %computername%
/NewName:<new computer name>
/userd:<domain\username> /password:*
Confirm the new computer name At a command prompt, type:

set
Change the name of a computer in a work 1. At a command prompt, type:

group netdom renamecomputer
<currentcomputername>
/NewName:<newcomputername>
Disable paging file management At a command prompt, type:

wmic computersystem where
name="<computername>" set
AutomaticManagedPagefile=False
Configure the paging file At a command prompt, type:

wmic pagefileset where name=”<path/filename>”
set
InitialSize=<initialsize>,MaximumSize=<maxsize>
27
Task Steps
Where:
path/filename is the path to and name of the paging
file
initialsize is the starting size of the paging file in
bytes.
maxsize is the maximum size of the page file in
bytes.
Change to a static IP address. 1. At a command prompt, type:

ipconfig /all
2. Record the relevant information or redirect it to a
text file (ipconfig /all >ipconfig.txt).
netsh interface ipv4 show interfaces
4. Verify that there is an interface list.
netsh interface ipv4 set address name <ID
from interface list> source=static
address=<preferred IP address>
gateway=<gateway address>
6. Verify by typing ipconfig /all at a command
prompt and checking that DHCP enabled is set
to No.
Set a static DNS address. 1. At a command prompt, type:

netsh interface ipv4 add dnsserver
name=<name of primary DNS server>
address=<IP address of the primary DNS
server> index=1
netsh interface ipv4 add dnsserver
name=<name of secondary DNS server>
address=<IP address of the secondary DNS
server> index=2
3. Repeat as appropriate to add additional servers.
4. Verify by typing ipconfig /all and checking that
all the addresses are correct.
28
Task Steps
Change to a DHCP-provided IP address 1. At a command prompt, type:

from a static IP address. netsh interface ipv4 set address name=<IP
address of local system> source=DHCP
2. Verify by typing Ipconfig /all and checking that
DCHP enabled is set to Yes.
Activate the server locally. At a command prompt, type:

slmgr.vbs -ato
Activate the server remotely. 1. At a command prompt, type:

cscript slmgr.vbs -ato <servername>
<username> <password>
2. Retrieve the GUID of the computer by typing
cscript slmgr.vbs -did
3. Type cscript slmgr.vbs -dli <GUID>
4. Verify that License status is set to Licensed
(activated).
Networking and firewall
Task Steps
Configure your server to use a proxy server. At a command prompt, type:

netsh Winhttp set proxy
<servername>:<port number>
Configure your server to bypass the proxy for At a command prompt, type:
internet addresses. netsh winttp set proxy <servername>:<port
number>bypass-list="<local>"
Display or modify IPSEC configuration. At a command prompt, type:

netsh ipsec
Display or modify NAP configuration. At a command prompt, type:

netsh nap
Display or modify IP to physical address At a command prompt, type:

translation. arp
29
Task Steps
Display or configure the local routing table. At a command prompt, type:

route
View or configure DNS server settings. At a command prompt, type:

nslookup
Display protocol statistics and current TCP/IP At a command prompt, type:

network connections. netstat
Display protocol statistics and current TCP/IP At a command prompt, type:

connections using NetBIOS over TCP/IP nbtstat
(NBT).
Display hops for network connections. At a command prompt, type:

pathping
Trace hops for network connections. At a command prompt, type:

tracert
Display the configuration of the multicast router. At a command prompt, type:

mrinfo
Enable remote administration of the firewall. At a command prompt, type:

netsh advfirewall firewall set rule
group=”Windows Firewall Remote
Management” new enable=yes
Updates, error reporting, and feedback
Task Steps
Install an update. At a command prompt, type:

wusa <update>.msu /quiet
Remove an update. 1. Type at a command prompt:

expand /f:* <update>.msu c:\test
2. Navigate to c:\test\ and open <update>.xml
in a text editor.
3. In <update>.xml, replace Install with
Remove and save the file.
30
Task Steps
pkgmgr /n:<update>.xml
Configure automatic updates. At a command prompt:

• To verify the current setting, type:
cscript scregedit.wsf /AU /v
• To enable automatic updates, type:
cscript scregedit.wsf /AU /4
• To disable automatic updates, type:
cscript scregedit.wsf /AU /1
Enable error reporting. At a command prompt:

• To verify the current setting, type:
serverWerOptin /query
• To automatically send detailed reports,
type:
serverWerOptin /detailed
• To automatically send summary reports,
type:
serverWerOptin /summary
• To disable error reporting, type:
serverWerOptin /disable
Participate in the Customer Experience At a command prompt:

Improvement Program (CEIP). • To verify the current setting, type:
serverCEIPOptin /query
• To enable CEIP, type:
serverCEIPOptin /enable
• To disable CEIP, type:
serverCEIPOptin /disable
Services, processes, and performance
Task Steps
List the running services. At a command prompt, type either of the
31
Task Steps
following:
• sc query
• net start
Start a service. At a command prompt, type either of the

following:
• sc start <service name>
• net start <service name>
Stop a service. At a command prompt, type either of the

following:
• sc stop <service name>
• net stop <service name>
Retrieve a list of running applications and At a command prompt, type:

associated processes. tasklist
Stop a process forcibly. 1. Use the tasklist command to retrieve the

process ID (PID).
taskkill /PID <process ID>
Start Task Manager. At a command prompt, type:

taskmgr
Manage the performance counters and logging See

with commands such as typeperf, logman, http://go.microsoft.com/fwlink/?LinkId=84872
relog, tracerprt.
Event logs
Task Steps
List event logs. At a command prompt, type:

wevtutil el
Query events in a specified log. At a command prompt, type:

wevtutil qe /f:text <log name>
Export an event log. At a command prompt, type:
32
Task Steps
wevtutil epl <log name>
Clear an event log. At a command prompt, type:

wevtutil cl <log name>
Disk and file system
Task Steps
Manage disk partitions. For a complete list of commands, at a

command prompt, type:
diskpart /?
Manage software RAID. For a complete list of commands, at a

diskraid /?
Manage volume mount points. For a complete list of commands, at a

mountvol /?
Defragment a volume. For a complete list of commands, at a

defrag /?
Convert a volume to the NTFS file system. At a command prompt, type:

convert <volume letter> /FS:NTFS
Compact a file. For a complete list of commands, at a

compact /?
Administer open files. For a complete list of commands, at a

openfiles /?
Administer VSS folders. For a complete list of commands, at a

vssadmin /?
Administer the file system. For a complete list of commands, at a
33
Task Steps
fsutil /?
Verify a file signature. At a command prompt, type:

sigverif /?
Take ownership of a file or folder. For a complete list of commands, at a

icacls /?
Hardware
Task Steps
Add a driver for a new hardware device. 1. Copy the driver to a folder at
%homedrive%\<driver folder>.
pnputil -i -a %homedrive%\<driver
folder>\<driver>.inf
Remove a driver for a hardware device. 1. For a list of loaded drivers, at a command
prompt, type:
sc query type= driver
sc delete <service_name>
Logging bugs and feedback

Your feedback is important to help us improve the Server Core installation option of Windows
Server 2008 in future releases of Windows Server 2008. Please provide feedback regarding:
• Your experience using the Server Core installation of Windows Server 2008, including issues
that you encounter and whether this document was helpful.
• Feature requests and general feedback about the Server Core installation of Windows
Server 2008.
• Feedback about this step-by-step guide. To provide feedback about this guide, follow the
instructions on the Microsoft Web site (http://go.microsoft.com/fwlink/?linkid=55105). Note
34
that in the comment area on the Web site, you need to provide the name of this step-by-step
guide.
Additional references
The following resources provide additional information about the Server Core installation of
• If you need product support, see the Microsoft Connect Web site
• To access newsgroups for Server Core installation, follow the instructions that are provided
on the Microsoft Connect Web site (http://go.microsoft.com/fwlink/?LinkId=50067).
• If you are a beta tester and part of the special Technology Adoption Program (TAP) beta
program, you can contact your appointed Microsoft development team member for
assistance.
The following resources provide additional information about some of the commands that are
used to install and configure Server Core installations and server roles:
Active Directory
Windows Server 2003 Active Directory
(http://go.microsoft.com/fwlink/?LinkID=19802)
Backup
Backing Up and Recovering Data
BitLocker Drive Encryption

BitLocker Drive Encryption Overview
Failover Clustering
Clustering Services
Dcpromo unattend files

Performing an Unattended Installation of Active Directory
DHCP
Dynamic Host Configuration Protocol (http://go.microsoft.com/fwlink/?LinkID=56423)
35
Dfscmd
Dfscmd Overview
Distributed File System

Distributed File System (DFS)
Distributed File System Replication

Distributed File System Replication
DNS
Windows Server 2003 Domain Name System (DNS)
Dnscmd
Dnscmd Overview
Dnscmd Syntax
Dnscmd Examples
File Replication service

What is FRS?
File Server
File and Storage Services
Multipath I/O
Microsoft Storage Technologies: Multipath I/O
Netsh
Netsh Overview
36
Network File System
Performance Tuning Guidelines for Microsoft Services for Network File System
Removable Storage
Removable Storage
Subsystem for UNIX-based Applications

Welcome to Subsystem for UNIX-based Applications
Appendix A: Sample Server Core installation -

Unattend.xml
Copy this sample code into a text editor and save it as Unattend.xml.
Note
See the unattend file documentation for more information about unattend file settings.
Windows System Image Manager, which is provided as part of the Windows Automated
Installation Kit, provides an excellent environment for authoring unattend files.
<unattend xmlns="urn:schemas-microsoft-com:unattend" xmlns:ms="urn:schemas-microsoft-
com:asm.v3" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">

<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35"

language="neutral" versionScope="nonSxS" processorArchitecture="x86">
<UserData>
<AcceptEula>true</AcceptEula>

<FullName>MyFullName</FullName>
<Organization>MyOrganizationName</Organization>
<ProductKey>
<WillShowUI>OnError</WillShowUI>
37
<Key>Sensitive*Data*Deleted</Key>
</ProductKey>
</UserData>
<ImageInstall>
<OSImage>
<WillShowUI>Never</WillShowUI>
<InstallTo>
<DiskID>0</DiskID>
<PartitionID>1</PartitionID>
</InstallTo>
<InstallFrom>
<MetaData>
<Key>/IMAGE/Name</Key>
<!—Specify that server core is to be installed. To install server, the value is Windows
Longhorn Server%SKU%core. This example is for the Standard edition -->
<Value>Windows Longhorn SERVERSTANDARDCORE</Value>
</MetaData>
</InstallFrom>
</OSImage>
</ImageInstall>
</component>
</settings>
<settings pass="specialize">
<component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35"


<ComputerName>MyCompName</ComputerName>
</component>
<component name="Microsoft-Windows-TerminalServices-RDP-WinStationExtensions"
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
processorArchitecture="x86">

<UserAuthentication>0</UserAuthentication>
</component>
38
<component name="Microsoft-Windows-TerminalServices-LocalSessionManager"

<fDenyTSConnections>false</fDenyTSConnections>
</component>
<component name="Microsoft-Windows-Web-Services-for-Management-Core"

<ConfigureWindowsRemoteManagement>true</ConfigureWindowsRemoteManagement>
</component>
<component name="Microsoft-Windows-UnattendedJoin" publicKeyToken="31bf3856ad364e35"

<Identification>
<Credentials>
<Domain>UserDomain</Domain>
<Username>UserName</Username>
<Password>UserPassword</Password>
</Credentials>
<JoinDomain>DomainToBeJoined</JoinDomain>

</Identification>
</component>
</settings>
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35"

<Display>
<HorizontalResolution>1024</HorizontalResolution>
<VerticalResolution>768</VerticalResolution>
<ColorDepth>16</ColorDepth>
</Display>
39
<UserAccounts>
<DomainAccounts>
<DomainAccountList>
<Domain>DOMAIN</Domain>
<DomainAccount>
<Name>TestAccount1</Name>
<Group>Administrators</Group>
</DomainAccount>
</DomainAccountList>
</DomainAccounts>
</UserAccounts>
</component>
</settings>
</unattend>
Note
For <computername>, if you use * the name will be randomly generated.
40
Server Manager Scenarios Step-by-Step
Guide
Abstract
Server Manager is a new tool that is included in Windows Server® 2008 to guide information
technology administrators through the process of installing, configuring, and managing server
roles and features that are part of Windows Server 2008. This document describes Server
Manager and includes a set of scenarios to demonstrate how Server Manager helps
administrators deploy and manage server roles.
1
2
Contents
Server Manager Scenarios Step-by-Step Guide ............................................................................. 5
In this guide .................................................................................................................................. 5
Who should use this step-by-step guide ...................................................................................... 5
Server Manager overview ............................................................................................................ 6
Requirements for Server Manager ............................................................................................... 6
Scenario Overview ....................................................................................................................... 6
Scenario 1: Completing the configuration of a new installation of Windows Server 2008 by
using Initial Configuration Tasks ........................................................................................... 7
Scenario 2: Performing initial configuration tasks in the Server Manager console .................. 7
Participating in CEIP by using Server Manager .................................................................... 8
Changing automatic updating settings by using Server Manager ......................................... 8
Participating in Windows Error Reporting by using Server Manager .................................... 8
Scenario 3: Adding Terminal Services and viewing its status .................................................. 9
Adding Terminal Services and TS Web Access .................................................................... 9
Managing Terminal Services by using Server Manager ..................................................... 10
Removing Terminal Services by using Server Manager ..................................................... 10
Scenario 4: Using Remote Server Administration Tools to manage Print Services remotely 11
Adding Remote Server Administration Tools for Print Services .......................................... 11
Managing Print Services remotely by using the Print Management snap-in ...................... 12
Removing Remote Server Administration Tools for Print Services..................................... 12
Scenario 5: Adding and removing the Print Services role by using the Server Manager
command line ...................................................................................................................... 13
Adding Print Services by using the Server Manager command line ................................... 13
Removing Print Services role services by using the command line .................................... 14
Removing Print Services by using the command line ......................................................... 15
Scenario 6: Adding File Services and Windows Server Backup by using an answer file ...... 15
Adding File Services and Windows Server Backup by using an answer file ...................... 15
Managing File Services and Windows Server Backup........................................................ 16
Removing all roles and features by using an answer file .................................................... 17
Scenario 7: Adding Windows Server virtualization ................................................................. 18
Installing Windows Server virtualization .............................................................................. 18
Managing Windows Server virtualization by using Server Manager ................................... 19
Removing Windows Server virtualization by using Server Manager .................................. 19
Additional resources ................................................................................................................... 20
3
Server Manager Scenarios Step-by-Step
Guide
Server Manager is a new tool available with Windows Server® 2008 that guides information
technology administrators through the process of installing, configuring, and managing server
roles and features that are part of Windows Server 2008.
This step-by-step guide provides an overview of Server Manager and walkthroughs of several
common scenarios for using Server Manager in your enterprise, focusing on new and enhanced
features of Server Manager. This guide helps you learn about how Server Manager functions as a
server role deployment, decommissioning, and management tool. The guide also describes how
Server Manager helps improve productivity, so IT pros can spend less time deploying, managing,
and maintaining their infrastructures, and spend more time using Windows Server 2008 software
packages to add business value.
The scenarios described in this step-by-step guide include initial server configuration tasks as
well as deployment, management, and removal of server roles and features.
In this guide
• Who should use this step-by-step guide
• Server Manager overview
• Requirements for Server Manager
• Scenario overview
Who should use this step-by-step guide

This step-by-step guide benefits:
• An IT administrator, planner, or analyst evaluating Windows Server 2008.
• An enterprise IT planner or designer.
• An early adopter of Windows Server 2008.
• An IT architect responsible for computer management and security throughout your
organization.
• An IT operations engineer who is responsible for the day-to-day management and
troubleshooting of networks, servers, operating systems, or applications.
• An IT operations manager who is accountable for network and server management, IT
hardware and software budgets, and technical decisions.
5
Server Manager overview
Server Manager makes server administration more efficient by allowing administrators to use a
single tool to do the following:
• View and make changes to server roles and features installed on the server.
• Perform management tasks associated with the operational lifecycle of the server, such as
starting or stopping services, and managing local user accounts.
• Perform management tasks associated with the operational lifecycle of roles, role services,
and features installed on the server.
• Determine server status, identify critical events, and analyze and troubleshoot configuration
issues or failures.
Requirements for Server Manager

Before using Server Manager, it is recommended that you familiarize yourself with the functions,
terminology, requirements, and day-to-day management tasks of any roles you plan to install on
your server. For more detailed information about server roles, see the Windows Server
TechCenter (http://go.microsoft.com/fwlink/?LinkId=48541).
Server Manager is installed by default as part of the Windows Server 2008 setup process. To use
Server Manager, you must be logged on to the computer as a member of the Administrators
group on the local computer.
Scenario Overview
The following scenarios guide you through several common uses for Server Manager and its
related technologies Initial Configuration Tasks and Remote Server Administration Tools.
• Scenario 1: Completing the configuration of a new installation of Windows Server 2008 by
using Initial Configuration Tasks
• Scenario 2: Performing initial configuration tasks in the Server Manager console
• Scenario 3: Adding Terminal Services and viewing its status
• Scenario 4: Using Remote Server Administration Tools to manage Print Services remotely
• Scenario 5: Adding and removing the Print Services role by using the Server Manager
command line
• Scenario 6: Adding File Services and Windows Server Backup by using an answer file
• Scenario 7: Adding Windows Server virtualization
6
Scenario 1: Completing the configuration of a new installation of
Windows Server 2008 by using Initial Configuration Tasks
After Windows Server 2008 Setup is finished, an administrator logs on to the server for the first
time, and the Initial Configuration Tasks window automatically opens. The administrator
completes configuration of the new server by using commands in the Initial Configuration Tasks
window.
Note
If you accidentally close Initial Configuration Tasks, click Start, and then click Run. Type
oobe in the Open text box, and then click OK or press ENTER.
To complete the configuration of a server

1. In the Initial Configuration Tasks window, in the Provide Computer Information area,
click Provide computer name and domain.
2. On the Computer Name tab of the System Properties dialog box, click Change to
change the computer name.
3. In the Computer Name/Domain Changes dialog box, type a name for this computer,
and provide the name of a domain or workgroup to which you want to join the computer.
Click OK.
4. For the computer name and domain changes to take effect, restart the computer. You
can wait to do this until after you have completed your work in Initial Configuration Tasks.
5. Configure network settings for this server, such as how the server obtains an IP address.
For example, you can configure settings that determine how the IP address is assigned.
In the Initial Configuration Tasks window, in the Provide Computer Information area,
click Configure networking.
6. In the Network Connections window, click File, and then click New Incoming
Connection to create a new network connection for this computer.
7. Configure Enable automatic updating and feedback according to your organization’s
policies.
8. Configure the server’s use of Remote Desktop according to your organization’s policies.
9. If you do not want to open Initial Configuration Tasks every time an administrator logs on
to the computer, select Do not show this window at logon, and then close the Initial
Configuration Tasks window.
Scenario 2: Performing initial configuration tasks in the Server

Manager console
Although initial configuration tasks have been completed and the Initial Configuration Tasks
window is now closed, an administrator has decided to enable automatic updating and feedback
7
on the computer running Windows Server 2008. The administrator uses Server Manager to
modify settings, instead of running Initial Configuration Tasks once again. The administrator
enrolls the server in the Customer Experience Improvement Program (CEIP), and turns on
automatic updating and Windows Error Reporting.
Participating in CEIP by using Server Manager
To participate in CEIP by using Server Manager

1. Click Start. Point to Administrative Tools, and then click Server Manager.
2. Expand the Resources and Support area, if it is not already open.
3. Click Configure CEIP to open the Customer Experience Improvement Program
Configuration dialog box.
4. Select Yes, I want to participate in the CEIP. Click OK.
Changing automatic updating settings by using Server Manager
To change automatic updating settings by using Server Manager

1. If Server Manager is not already open, open Server Manager by clicking Start, pointing to
Administrative Tools, and then clicking Server Manager.
2. Expand the Server Summary area, if it is not already open.
3. Expand the Security Information area, if it is not already open. Click Configure
Updates.
4. In the Windows Update dialog box, select one of the following:
• Click Have Windows install updates automatically to download and install updates
as they become available. This is recommended.
• Click Let me choose to open the Change Settings window, which allows you to turn
off updates, or to select how updates are downloaded and installed on the server, if
you want automatic updates turned on.
5. If you opened the Change Settings window by clicking Let me choose, when you are
done making changes, click OK.
Participating in Windows Error Reporting by using Server Manager
To participate in Windows Error Reporting by using Server Manager

1. Open Server Manager by clicking Start, pointing to Administrative Tools, and then
clicking Server Manager.
8
2. Expand the Resources and Support area, if it is not already open.
3. Click Turn on Windows Error Reporting.
4. In the Windows Error Reporting Configuration dialog box, select one of the following
options:
• Yes, automatically send detailed reports.
• Yes, automatically send summary reports.
The other settings—Ask me about sending reports every time an error occurs, and I
don't want to participate, and don't ask me again—disable Windows Error Reporting.
Ask me about sending reports every time an error occurs prompts you to report
errors only as they occur.
5. Click OK.
Scenario 3: Adding Terminal Services and viewing its status

A company has just purchased a new server. The new computer must run Terminal Services to
provide centralized access to individual applications without the necessity of providing Remote
Desktop access to each employee.
The administrator performs the following steps to add and configure Terminal Services.
Adding Terminal Services and TS Web Access

The system administrator installs the Terminal Services role on the new computer.
To add Terminal Services and TS Web Access

2. Add Terminal Services by using the Add Roles Wizard in Server Manager. Select the role
services Terminal Server and TS Web Access on the Select Role Services page of the
Add Roles Wizard.
Note
The TS Web Access role service depends on Web Server (IIS) and Windows
System Resource Manager (WSRM). Server Manager prompts you to install IIS
and WSRM if they are not already installed on the computer.
3. The Terminal Services installation process requires an administrator to specify several
configuration options. Complete the configuration pages of the Add Roles Wizard based
on what is most appropriate for your organization. For more information about configuring
Terminal Services, and detailed step-by-step guides, see the Terminal Services page on
the Windows Server TechCenter (http://go.microsoft.com/fwlink/?LinkId=48555).
9
Managing Terminal Services by using Server Manager
The administrator opens the Terminal Services snap-ins and performs Terminal Services
management tasks in the Server Manager window.
To manage Terminal Services by using Server Manager

2. In the hierarchy pane, expand Roles, and then expand Terminal Services.
3. If Terminal Services is installed, but Terminal Services snap-ins and management tools
do not appear in the hierarchy pane, close and then reopen Server Manager.
4. Open the Terminal Services Configuration and then the Terminal Services Manager
snap-ins by selecting their objects in the hierarchy pane.
5. On the role home page for Terminal Services, open the Summary area and the System
Services area, if they are not already open.
6. In the System Services area, click Stop and then Restart to stop and then restart the
Terminal Services service.
7. In the Server Manager hierarchy pane, expand Diagnostics.
8. Expand Event Viewer, expand Custom Views, and then expand Server Roles.
9. If Terminal Services does not appear as a child object of Server Roles, press F5 to
refresh the Server Manager console. If Terminal Services still fails to appear, close and
then reopen Server Manager.
10. To check for new event messages, press F5 or right-click the Event Viewer node, and
then click Refresh. Check for critical, warning, or informational events for Terminal
Services, view event properties, and change filter preferences for events.
Removing Terminal Services by using Server Manager

After several months, the system administrator wants to install Terminal Services on a more
powerful computer, and remove Terminal Services completely from the server on which it
currently is running.
To remove Terminal Services by using Server Manager

2. Open the Roles Summary area, if it is not already open.
3. Click Remove roles.
4. On the Remove Server Roles page of the Remove Roles Wizard, clear the check box
for Terminal Services. Click Next.
10
5. After confirming that you want to remove Terminal Services, on the Confirm Removal
Selections page, click Remove.
Scenario 4: Using Remote Server Administration Tools to

manage Print Services remotely
An administrator is running the Server Core installation option of Windows Server 2008. The
administrator installs the Print Services role on this server. After that, the administrator wants to
manage the server remotely from another computer that is running a full installation of Windows
Server 2008.
Adding Remote Server Administration Tools for Print Services

To manage the Print Services role remotely from the computer running the full installation of
Windows Server 2008, the administrator installs Remote Server Administration Tools.
To add Remote Server Administration Tools for Print Services

clicking Server Manager. In the Features section of the Server Manager home page,
click Add features.
2. On the Select Features page of the Add Features Wizard, expand Remote Server
Administration Tools.
3. Expand Role Administration Tools, and then select Print Services Tools.
Note
Installing Remote Server Administration Tools does not install any roles, role
services, or features on a computer. For each role, role service, or feature you
select within Remote Server Administration Tools, you are installing only
management tools and snap-ins that allow you to perform administration tasks
for specified roles, role services, or features installed on other computers.
4. Click Next, and then click Install.
5. When installation is complete, close the wizard.
To manage the remote print server and make sure it is discoverable on the network, the
administrator restarts the print spooler service on the computer running the Server Core
installation of Windows Server 2008. To restart the spooler services on the computer running the
Print Services role, type the commands net stop spooler, followed by net start spooler, at the
command prompt.
11
Managing Print Services remotely by using the Print Management snap-in
After restarting the spooler service, the administrator is ready to manage Print Services remotely
from the computer running the full installation of Windows Server 2008.
To manage Print Services remotely by using the Print Management snap-in

1. Open the Print Management snap-in by clicking Start, pointing to Administrative
Tools, and then clicking Print Management.
2. Right-click the Print Management node at the top of the hierarchy pane, and then click
Add/Remove Servers.
3. Add or browse for the name of the server that is running the Print Services role.
4. Click OK.
Removing Remote Server Administration Tools for Print Services

Later, the administrator decides that Print Services should not be managed from this computer.
The administrator removes the remote administration tools for Print Services from the computer
running the full installation of Windows Server 2008.
To remove Remote Server Administration Tools for Print Services

clicking Server Manager. In the Features section of the Server Manager home page,
click Remove features.
2. On the Select Features page of the Remove Features Wizard, expand Remote Server
Administration Tools, and then expand Role Administration Tools.
3. Clear the check box for Print Services Tools. Click Next.
4. On the Confirm Removal Options page, click Remove.
Note
Removing Remote Server Administration Tools does not remove any roles, role
services, or features from a computer. For each role, role service, or feature you
select within Remote Server Administration Tools, you are removing only
management tools and snap-ins that allow you to perform administration tasks
for specified roles, role services, or features installed on other computers.
5. When removal is complete, close the wizard.
12
Scenario 5: Adding and removing the Print Services role by
using the Server Manager command line
A company has purchased a new server. The new computer must run Print Services for the
engineering department. After installing Windows Server 2008 on the computer and completing
initial configuration tasks, a system administrator adds the Print Services role to the server by
using the Server Manager command line.
Adding Print Services by using the Server Manager command line

The administrator can start the Server Manager command line and add Print Services from any
directory on the local computer. At first, the administrator adds only the Print Server role service,
but then decides to add the role services LPD Service and Internet Printing Service.
Note
The Server Manager command is not case sensitive.
To add Print Services by using the Server Manager command line

1. Open a Command Prompt window with elevated privileges by right-clicking the
Command Prompt executable or the Command Prompt object on the Start menu, and
then clicking Run as administrator.
2. At the prompt, type the following, and then press ENTER:
ServerManagerCmd.exe -install Print-Server
Note
ServerManagerCmd.exe also automatically installs all required roles, role
services, or features. In this scenario, Server Manager automatically installs Web
Server (IIS) and Windows Process Activation Services.
3. When installation is complete, the Command Prompt window displays the following
message:
Success: Installation succeeded.
4. Verify that the Print Server role service of Print Services was installed by typing the
following at the prompt:
ServerManagerCmd.exe -query
Ensure that the Print Services line item in the -query command results is checked and
highlighted, and that the Print Server child object is checked and highlighted. Also ensure
that other role services of Print Services are not checked.
5. At the command prompt, type the following, and then press ENTER:
ServerManagerCmd.exe -install Print-Internet Print-LPD-Service
Note
13
You can install each additional role service one at a time, or use the
–allSubFeatures option to install all the child elements of a role or feature.
Server Manager automatically skips those elements already installed on the
computer, in this case the Print Server role service.
message:
7. Verify that the LPD Service and Internet Printing Service role services were installed by
typing the following at the command prompt:
Ensure that the Print Services line item in the -query command results is checked and
highlighted, and that all role services of Print Services are now checked and highlighted.
Removing Print Services role services by using the command line

After several days, the administrator decides to use a different computer for serving the print
needs of UNIX-based computers, and removes LPD Service from the current computer.
However, the administrator wants to continue using the current computer as a basic print server,
with the Print Server role service remaining. The administrator uses the Server Manager
command line to remove only LPD Service.
To remove Print Services role services by using the command line

1. If a Command Prompt window is not already open, open a Command Prompt window
with elevated privileges by right-clicking the Command Prompt executable, or the
Command Prompt object on the Start menu, and then clicking Run as administrator.
ServerManagerCmd.exe -remove Print-LPD-Service -restart
Adding -restart to the command line restarts the computer automatically when removal is
complete, if restarting is required by the software that you are removing. In this instance,
a restart of the server is required to remove LPD Service completely.
3. Verify that LPD Service has been removed from the computer by typing the following at
the command prompt:
Ensure that, although the Print Services object in the query results is checked and
highlighted, the LPD Service is not.
14
Removing Print Services by using the command line
After several months, the administrator moves core printing services to a different server, so that
this server can be repurposed. The administrator removes the Print Services role completely from
this computer by using the command line.
To remove Print Services by using the command line

with elevated privileges by right-clicking the Command Prompt executable or the
ServerManagerCmd.exe -remove Print-Services -restart
Adding -restart to the command line restarts the computer automatically when removal is
complete, if restarting is required by the software that you are removing. In this instance,
a restart of the server is not required to remove Print Services.
3. Verify that Print Services has been removed from the computer by typing the following at
the command prompt:
Ensure that the Print Services object in the query results is neither checked nor
highlighted.
Note
roles, role services, or features that are installed due to dependencies, such as Web
Server (IIS) and Windows Process Activation Service, are not removed with the removal
of Print Services.
Scenario 6: Adding File Services and Windows Server Backup

by using an answer file
An administrator wants to create a DFS namespace to facilitate file sharing among company
employees. Because important data is hosted on the server running File Services, it is important
to back up the server by using Windows Server Backup.
Note
For the complete Server Manager command-line schema, see the Microsoft Web site
Adding File Services and Windows Server Backup by using an answer file
The administrator creates an XML answer file to use with the Server Manager command line to
add the File Services role and the Windows Server Backup subfeature on the server.
15
To install File Services and Windows Server Backup by using an answer file
1. Create the following answer file for the Server Manager command line, and save it to a
convenient location as an XML document:
<?xml version="1.0" encoding="utf-8" ?>
<ServerManagerConfiguration Action="Install"
xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<RoleService Id="FS-DFS-Namespace" />
<Feature Id="Backup" />
Note
Although the only role service of File Services installed by this answer file is DFS
Namespace, the File Services role is installed.
ServerManagerCmd.exe -inputPath <answerfile.xml> -whatIf -restart
The placeholder answerfile represents the path and name of the XML answer file created
in Step 1. The -whatIf parameter displays a list of all software installed as a result of the
command, including dependent roles, role services, and features.
Adding -restart to the command line restarts the computer automatically when
installation is complete, if restarting is required by the software that you are removing. In
this instance, a restart of the server is required to install Windows Server Backup.
message:
5. Open the Server Manager console by clicking Start, pointing to Administrative Tools,
and then clicking Server Manager.
6. Verify that the File Services role is installed with the DFS Namespace role service, and
that the Windows Server Backup subfeature of Windows Server Backup Features is also
installed.
Managing File Services and Windows Server Backup

After DFS Namespace and Windows Server Backup are installed, the administrator uses File
Services and Windows Server Backup tools in Server Manager to manage the server.
16
To manage File Services and Windows Server Backup
1. Back up the server. For more information about backing up your server, see the Help
provided with Windows Server Backup Features.
3. In the Server Manager hierarchy pane, expand Roles, and then select File Services to
view the role management home page for File Services.
4. View the status of event messages and services related to File Services. Expand the File
Services node in the hierarchy pane.
5. Select the DFS Management node to open the DFS Management snap-in. Add, remove,
or modify namespaces. Add a new replication group, following the steps in the wizard.
Removing all roles and features by using an answer file

Six months later, the administrator wants to use this computer to run a different server role. The
administrator modifies the answer file to remove all roles, role services, and features installed on
this computer, by replacing the –install parameter with the –remove parameter. The
administrator adds the -whatIf parameter to the end of the command line to generate a full list of
roles, role services, and features that are removed by the command.
To remove all roles and features by using an answer file

1. Create the following answer file for the Server Manager command line, and save it to a
convenient location as an XML document:
<?xml version="1.0" encoding="utf-8" ?>
<ServerManagerConfiguration Action="Remove"
xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<RoleService Id="FS-DFS-Namespace" />
<Feature Id="Backup-Features" />
ServerManagerCmd.exe -inputPath <answerfile.xml> -whatIf -restart
The placeholder answerfile represents the path and name of the XML answer file created
in Step 1. The -whatIf parameter displays a list of all software removed as a result of the
command, including dependent roles, role services, and features.
17
Adding -restart to the command line restarts the computer automatically when
installation is complete, if restarting is required by the software that you are removing.
4. When removal is complete, the Command Prompt window displays the following
message:
Success: Removal succeeded.
5. Open the Server Manager console by clicking Start, pointing to Administrative Tools,
and then clicking Server Manager.
6. Verify that the File Services role and Windows Server Backup are no longer installed on
the computer.
Scenario 7: Adding Windows Server virtualization

An enterprise wants to use Windows Server® virtualization to run virtual machines. The system
administrator installs Windows Server virtualization on the computer, and then manages it by
using snap-ins in Server Manager.
Important
The Windows Server virtualization scenario is only for computers running The 64-bit
edition of Windows Server 2008, and that have support at the processor level for
virtualization. More specific hardware requirements for Windows Server virtualization are
described in the Windows Server virtualization Step-by-Step Guide on the Windows
Server TechCenter (http://go.microsoft.com/fwlink/?LinkId=98822). It is strongly
recommended that you review these hardware requirements before completing any of the
tasks in this scenario.
Installing Windows Server virtualization

The administrator's first task is to run Setup for the two Windows Server virtualization update
packages. After the updates are complete, Windows Server virtualization is available for
installation by using Server Manager.
To install Windows Server virtualization

1. Double-click the following two update packages stored in %windir%\WSV to make
Windows Server virtualization available for installation by using Server Manager:
• Windows6.0-KB939854-x64.msu
• Windows6.0-KB939853-x64.msu
3. In the Roles Summary area, click Add Roles.
4. On the Select Server Roles page of the Add Roles Wizard, select Windows Server
18
virtualization.
5. Complete the Add Roles Wizard. For more information about specific configuration pages
and settings for Windows Server virtualization, see the Windows Server virtualization
Step-by-Step Guide on the Windows Server TechCenter
Managing Windows Server virtualization by using Server Manager

After installing Windows Server virtualization, the administrator uses snap-ins available in Server
Manager to manage the role.
To manage Windows Server virtualization by using Server Manager

2. In the hierarchy pane, expand Roles, and then expand Windows Server Virtualization.
3. With the Server Manager window active, press F5 to refresh the console if Windows
Server virtualization is installed, but Windows Server virtualization snap-ins and
management tools do not show in the hierarchy pane.
Removing Windows Server virtualization by using Server Manager

After several months, the company no longer requires this server to be used as a virtual machine
running multiple operating systems, and the system administrator removes the Windows Server
virtualization role.
To remove Windows Server virtualization by using Server Manager

2. Open the Roles Summary area if it is not already open. Click Remove roles.
3. On the Remove Server Roles page of the Remove Roles Wizard, clear the check box
for Windows Server virtualization. Click Next.
4. After confirming that you want to remove Windows Server virtualization, on the Confirm
Removal Selections page, click Remove.
5. Verify that Windows Server virtualization has been removed from the server by refreshing
Server Manager and viewing the Roles Summary area.
19
Additional resources
• Server Manager on Windows Server TechCenter
• Server ManagerTechnical Overview (http://go.microsoft.com/fwlink/?LinkId=85101)
• Server ManagerCommand-Line Schema (http://go.microsoft.com/fwlink/?LinkId=81203)
20
Step-by-Step Guide for Configuring a Two-
Node File Server Failover Cluster in Windows
Server 2008
Author: Jan Keller
Editor: Ronald Loi
Abstract
A failover cluster is a group of independent computers that work together to increase the
availability of applications and services. The clustered servers (called nodes) are connected by
physical cables and by software. If one of the cluster nodes fails, another node begins to provide
service (a process known as failover). This guide describes the steps for installing and
configuring a file server failover cluster that has two nodes. By creating the configuration in this
guide, you can learn about failover clusters and familiarize yourself with the Failover Cluster
Management snap-in.
1
This is a preliminary document and may be changed substantially prior to final commercial
release of the software described herein. The information contained in this document represents
the current view of Microsoft Corporation on the issues discussed as of the date of publication.
Because Microsoft must respond to changing market conditions, it should not be interpreted to be
a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any
information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in or introduced into a
retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written permission
of Microsoft Corporation.
Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, and Active Directory are either
registered trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries.
2
Contents
Step-by-Step Guide for Configuring a Two-Node File Server Failover Cluster in Windows Server
2008 ............................................................................................................................................. 5
In this guide............................................................................................................................... 5
Overview for a two-node file server cluster .................................................................................. 5
Shared folders in a failover cluster ........................................................................................... 7
Requirements for a two-node failover cluster .............................................................................. 8
Hardware requirements for a two-node failover cluster ............................................................ 8
Software requirements for a two-node failover cluster ........................................................... 10
Network infrastructure and domain account requirements for a two-node failover cluster .... 11
Steps for installing a two-node file server cluster....................................................................... 12
Step 1: Connect the cluster servers to the networks and storage .......................................... 12
Step 2: Install the failover cluster feature ............................................................................... 13
Step 3: Validate the cluster configuration ............................................................................... 15
Step 4: Create the cluster ....................................................................................................... 17
Steps for configuring a two-node file server cluster ................................................................... 19
3
Node File Server Failover Cluster in Windows
Server 2008
service (a process known as failover). Users experience a minimum of disruptions in service.
This guide describes the steps for installing and configuring a file server failover cluster that has
two nodes. By creating the configuration in this guide, you can learn about failover clusters and
familiarize yourself with the Failover Cluster Management snap-in interface in
Windows Server® 2008 Enterprise or Windows Server® 2008 Datacenter.
Note
The failover cluster feature is not available in Windows Web Server 2008 or Windows
Server 2008 Standard.
In Windows Server 2008, the improvements to failover clusters (formerly known as server
clusters) are aimed at simplifying clusters, making them more secure, and enhancing cluster
stability. Cluster setup and management are easier. Security and networking in clusters have
been improved, as has the way a failover cluster communicates with storage. For more
information about improvements to failover clusters, see
In this guide
Overview for a two-node file server cluster
Shared folders in a failover cluster
Requirements for a two-node failover cluster
Steps for installing a two-node file server cluster
Steps for configuring a two-node file server cluster
Overview for a two-node file server cluster

Servers in a failover cluster can function in a variety of roles, including the roles of file server,
print server, mail server, or database server, and they can provide high availability for a variety of
5
other services and applications. This guide describes how to configure a two-node file server
cluster.
A failover cluster usually includes a storage unit that is physically connected to all the servers in
the cluster, although any given volume in the storage is only accessed by one server at a time.
The following diagram shows a two-node failover cluster connected to a storage unit.
Failover cluster with two nodes connected to a storage unit
Storage volumes or logical unit numbers (LUNs) exposed to the nodes in a cluster must not be
exposed to other servers, including servers in another cluster. The following diagram illustrates
this.
Two failover clusters, each with its own LUNs
6
Note that for the maximum availability of any server, it is important to follow best practices for
server management—for example, carefully managing the physical environment of the servers,
testing software changes before fully implementing them, and carefully keeping track of software
updates and configuration changes on all clustered servers.
The following scenario describes how a file server failover cluster can be configured. The files
being shared are on the cluster storage, and either clustered server can act as the file server that
shares them.
Shared folders in a failover cluster

In Windows Server 2008, the interfaces for viewing or configuring shared folders in a failover
cluster have been extended and streamlined. Configuration is more straightforward and
misconfiguration is less likely. The following list describes functionality that is integrated into
failover clustering:
• Display is scoped to clustered shared folders only (no mixing with nonclustered
shared folders): When you or a user views shared folders by specifying the path of a
clustered file server, the display will include only the shared folders that are part of the
cluster. It will exclude nonclustered shared folders that happen to be on a node of the cluster.
• Access-based enumeration: You can use access-based enumeration to hide a specified
folder from users' view. Instead of allowing users to see the folder but not access anything on
it, you can choose to prevent them from seeing the folder at all. You can configure access-
based enumeration for a clustered shared folder in the same way as for a nonclustered
shared folder.
• Offline access: You can configure offline access (caching) for a clustered shared folder in
the same way as for a nonclustered shared folder.
• Clustered disks are always recognized as part of the cluster: Whether you use the
failover cluster interface, Windows Explorer, or the Share and Storage Management snap-in,
Windows Server 2008 recognizes whether a disk has been designated as being in the cluster
storage. If such a disk has already been configured in Failover Cluster Management as part
of a clustered file server, you can then use any of the previously-mentioned interfaces to
create a share on the disk. If such a disk has not been configured as part of a clustered file
server, you cannot mistakenly create a share on it. Instead, an error indicates that the disk
must first be configured as part of a clustered file server before it can be shared.
• Integration of Services for Network File System: The File Server role in Windows
Server 2008 includes the optional role service called Services for Network File System (NFS).
By installing the role service and configuring shared folders with Services for NFS, you can
create a clustered file server that supports UNIX-based clients.
7
To create a failover cluster with two nodes (regardless of the service or application that the nodes
provide), you need the hardware, software, accounts, and network infrastructure described in the
sections that follow.
We recommend that you first use the information provided in this guide in a test lab environment.
A Step-by-Step guide is not necessarily meant to be used to deploy Windows Server features
without the accompanying documentation (as listed in the Additional references section), and it
should be used with discretion as a stand-alone document.
Hardware requirements for a two-node failover cluster

You will need the following hardware for a two-node failover cluster:
• Servers: We recommend that you use a set of matching computers that contain the same or
similar components.
Important
You should use only hardware components that are compatible with Windows
Server 2008.
• Network adapters and cable (for network communication): The network hardware, like
other components in the failover cluster solution, must be compatible with Windows
Server 2008. If you use iSCSI, your network adapters must be dedicated to either network
communication or iSCSI, not both.
In the network infrastructure that connects your cluster nodes, avoid having single points of
failure. There are multiple ways of accomplishing this. You can connect your cluster nodes by
multiple, distinct networks. Alternatively, you can connect your cluster nodes with one
network that is constructed with teamed network adapters, redundant switches, redundant
routers, or similar hardware that removes single points of failure.
Note
If you connect cluster nodes with a single network, the network will pass the
redundancy requirement in the Validate a Configuration Wizard. However, the report
from the wizard will include a warning that the network should not have single points
of failure.
For more details about the network configuration required for a failover cluster, see Network
infrastructure and domain account requirements for a two-node failover cluster, later in this
topic.
Device controllers or appropriate adapters for the storage:
• For Serial Attached SCSI or Fibre Channel: If you are using Serial Attached SCSI or
Fibre Channel, in all clustered servers, the mass-storage device controllers that are
8
dedicated to the cluster storage should be identical. They should also use the same
firmware version.
Note
With Windows Server 2008, you cannot use parallel SCSI to connect the storage
to the clustered servers.
• For iSCSI: If you are using iSCSI, each clustered server must have one or more network
adapters or host bus adapters that are dedicated to the cluster storage. The network you
use for iSCSI cannot be used for network communication. In all clustered servers, the
network adapters you use to connect to the iSCSI storage target should be identical, and
we recommend that you use Gigabit Ethernet or higher.
For iSCSI, you cannot use teamed network adapters, because they are not supported
with iSCSI.
For more information about iSCSI, see the iSCSI FAQ on the Microsoft Web site
• Storage: You must use shared storage that is compatible with Windows Server 2008.
For a two-node failover cluster, the storage should contain at least two separate volumes
(LUNs), configured at the hardware level. One volume will function as the witness disk
(described in the next paragraph). One volume will contain the files that are being shared to
users. Storage requirements include the following:
• To use the native disk support included in failover clustering, use basic disks, not
dynamic disks.
• We recommend that you format the partitions with NTFS (for the witness disk, the
partition must be NTFS).
• For the partition style of the disk, you can use either master boot record (MBR) or GUID
partition table (GPT).
The witness disk is a disk in the cluster storage that is designated to hold a copy of the
cluster configuration database. (A witness disk is part of some, not all, quorum
configurations.) For this two-node cluster, the quorum configuration will be Node and Disk
Majority, the default for a cluster with an even number of nodes. Node and Disk Majority
means that the nodes and the witness disk each contain copies of the cluster configuration,
and the cluster has quorum as long as a majority (two out of three) of these copies are
available.
Deploying storage area networks with failover clusters

When deploying a storage area network (SAN) with a failover cluster, follow these guidelines:
9
• Confirm compatibility of the storage: Confirm with manufacturers and vendors that the
storage, including drivers, firmware, and software used for the storage, are compatible with
failover clusters in Windows Server 2008.
Important
Storage that was compatible with server clusters in Windows Server 2003 might not
be compatible with failover clusters in Windows Server 2008. Contact your vendor to
ensure that your storage is compatible with failover clusters in Windows Server 2008.
Failover clusters include the following new requirements for storage:
• Because improvements in failover clusters require that the storage respond correctly to
specific SCSI commands, the storage must follow the standard called SCSI Primary
Commands-3 (SPC-3). In particular, the storage must support Persistent Reservations as
specified in the SPC-3 standard.
• The miniport driver used for the storage must work with the Microsoft Storport storage
driver.
• Isolate storage devices, one cluster per device: Servers from different clusters must not
be able to access the same storage devices. In most cases, a LUN that is used for one set of
cluster servers should be isolated from all other servers through LUN masking or zoning.
• Consider using multipath I/O software: In a highly available storage fabric, you can deploy
failover clusters with multiple host bus adapters by using multipath I/O software. This
provides the highest level of redundancy and availability. For Windows Server 2008, your
multipath solution must be based on Microsoft Multipath I/O (MPIO). Your hardware vendor
will usually supply an MPIO device-specific module (DSM) for your hardware, although
Windows Server 2008 includes one or more DSMs as part of the operating system.
Important
Host bus adapters and multipath I/O software can be very version sensitive. If you
are implementing a multipath solution for your cluster, you should work closely with
your hardware vendor to choose the correct adapters, firmware, and software for
Software requirements for a two-node failover cluster

The servers for a two-node failover cluster must run the same version of Windows Server 2008,
including the same hardware version (32-bit, x64-based, or Itanium architecture-based). They
should also have the same software updates (patches) and service packs.
10
Network infrastructure and domain account requirements for a
two-node failover cluster
You will need the following network infrastructure for a two-node failover cluster and an
administrative account with the following domain permissions:
• Network settings and IP addresses: When you use identical network adapters for a
network, also use identical communication settings on those adapters (for example, Speed,
Duplex Mode, Flow Control, and Media Type). Also, compare the settings between the
network adapter and the switch it connects to and make sure that no settings are in conflict.
If you have private networks that are not routed to the rest of your network infrastructure,
ensure that each of these private networks uses a unique subnet. This is necessary even if
you give each network adapter a unique IP address. For example, if you have a cluster node
in a central office that uses one physical network, and another node in a branch office that
uses a separate physical network, do not specify 10.0.0.0/24 for both networks, even if you
give each adapter a unique IP address.
For more information about the network adapters, see Hardware requirements for a two-node
failover cluster, earlier in this guide.
• DNS: The servers in the cluster must be using Domain Name System (DNS) for name
resolution. The DNS dynamic update protocol can be used.
• Domain role: All servers in the cluster must be in the same Active Directory domain. As a
best practice, all clustered servers should have the same domain role (either member server
or domain controller). The recommended role is member server.
• Domain controller: We recommend that your clustered servers be member servers. If they
are, you need an additional server that acts as the domain controller in the domain that
contains your failover cluster.
• Clients: As needed for testing, you can connect one or more networked clients to the failover
cluster that you create, and observe the effect on a client when you move or fail over the
clustered file server from one cluster node to the other.
• Account for administering the cluster: When you first create a cluster or add servers to it,
you must be logged on to the domain with an account that has administrator rights and
permissions on all servers in that cluster. The account does not need to be a Domain Admins
account, but can be a Domain Users account that is in the Administrators group on each
clustered server. In addition, if the account is not a Domain Admins account, the account (or
the group that the account is a member of) must be given the Create Computer Objects
permission in the domain.
Note
There is a change in the way the Cluster service runs in Windows Server 2008, as
compared to Windows Server 2003. In Windows Server 2008, there is no Cluster
service account. Instead, the Cluster service automatically runs in a special context
11
that provides the specific permissions and privileges that are necessary for the
service (similar to the local system context, but with reduced privileges).
Steps for installing a two-node file server cluster

You must complete the following steps to install a two-node file server failover cluster.
Step 1: Connect the cluster servers to the networks and storage
Step 2: Install the failover cluster feature
Step 3: Validate the cluster configuration
Step 4: Create the cluster
If you have already installed the cluster nodes and want to configure a file server failover cluster,
see Steps for configuring a two-node file server cluster, later in this guide.

Use the following instructions to connect your selected cluster servers to networks and storage.
Note
Review Hardware Requirements for a Two-Node Failover Cluster earlier in this guide, for
details about the kinds of network adapters and device controllers that you can use with
For a failover cluster network, avoid having single points of failure. There are multiple ways of
accomplishing this. You can connect your cluster nodes by multiple, distinct networks.
Alternatively, you can connect your cluster nodes with one network that is constructed with
teamed network adapters, redundant switches, redundant routers, or similar hardware that
removes single points of failure (If you use a network for iSCSI, you must create this network in
addition to the other networks).
For a two-node file server cluster, when you connect the servers to the cluster storage, you must
expose at least two volumes (LUNs). You can expose additional volumes as needed for thorough
testing of your configuration. Do not expose the clustered volumes to servers that are not in the
cluster.
To connect the cluster servers to the networks and storage

1. Review the details about networks in Hardware Requirements for a Two-Node Failover
Cluster and Network infrastructure and domain account requirements for a two-node
2. Connect and configure the networks that the servers in the cluster will use.
3. If your test configuration includes clients or a non-clustered domain controller, make sure
that these computers can connect to the clustered servers through at least one network.
12
4. Follow the manufacturer's instructions for physically connecting the servers to the
storage.
5. Ensure that the disks (LUNs) that you want to use in the cluster are exposed to the
servers that you will cluster (and only those servers). You can use any of the following
interfaces to expose disks or LUNs:
• The interface provided by the manufacturer of the storage.
• If you are using iSCSI, an appropriate iSCSI interface.
• Microsoft Storage Manager for SANs (part of the operating system in Windows
Server 2008). To use this interface, you need to contact the manufacturer of your
storage for a Virtual Disk Service (VDS) provider package that is designed for your
storage.
6. If you have purchased software that controls the format or function of the disk, follow
instructions from the vendor about how to use that software with Windows Server 2008.
7. On one of the servers that you want to cluster, click Start, click Administrative Tools,
click Computer Management, and then click Disk Management. (If the User Account
Control dialog box appears, confirm that the action it displays is what you want, and then
click Continue.) In Disk Management, confirm that the cluster disks are visible.
8. If you want to have a storage volume larger than 2 terabytes, and you are using the
Windows interface to control the format of the disk, convert that disk to the partition style
called GUID partition table (GPT). To do this, back up any data on the disk, delete all
volumes on the disk and then, in Disk Management, right-click the disk (not a partition)
and click Convert to GPT Disk.
For volumes smaller than 2 terabytes, instead of using GPT, you can use the partition
style called master boot record (MBR).
Important
You can use either MBR or GPT for a disk that is used by a failover cluster, but you cannot
use a disk that you converted to dynamic by using Disk Management.
If you purchased software that controls the format or function of the disk, contact the vendor
for instructions about how to use that software with Windows Server 2008.
9. Check the format of any exposed volume or LUN. We recommend NTFS for the format
(for the witness disk, you must use NTFS).

In this step, you install the failover cluster feature. The servers must be running Windows
Server 2008.
13
To install the failover cluster feature on the servers
1. If you recently installed Windows Server 2008, the Initial Configuration Tasks interface
is displayed, as shown in the following illustration.
Initial Configuration Tasks
If this interface is displayed, under Customize This Server, click Add features. Then
skip to step 3.
2. If the Initial Configuration Tasks interface is not displayed and Server Manager is not
running, click Start, click Administrative Tools, and then click Server Manager. (If the
User Account Control dialog box appears, confirm that the action it displays is what you
want, and then click Continue.)
Server Manager
14
In Server Manager, under Features Summary, click Add Features.
3. In the Add Features Wizard, click Failover Clustering, and then click Install.
4. Follow the instructions in the wizard to complete the installation of the feature. When the
wizard finishes, close it.
5. Repeat the process for each server that you want to include in the cluster.

Before creating a cluster, we strongly recommend that you validate your configuration. Validation
helps you confirm that the configuration of your servers, network, and storage meets a set of
specific requirements for failover clusters.
To validate the failover cluster configuration

1. To open the failover cluster snap-in, click Start, click Administrative Tools, and then
click Failover Cluster Management. (If the User Account Control dialog box appears,
confirm that the action it displays is what you want, and then click Continue.)
Failover Cluster Management snap-in
15
2. Confirm that Failover Cluster Management is selected and then, in the center pane
under Management, click Validate a Configuration.
Validate a Configuration Wizard
16
3. Follow the instructions in the wizard to specify the two servers and the tests, and then run
the tests. To fully validate your configuration, run all tests before creating a cluster.
4. The Summary page appears after the tests run. To view Help topics that will help you
interpret the results, click More about cluster validation tests.
5. While still on the Summary page, click View Report and read the test results.
To view the results of the tests after you close the wizard, see
SystemRoot\Cluster\Reports\Validation Report date and time.html
where SystemRoot is the folder in which the operating system is installed (for example,
C:\Windows).
6. As necessary, make changes in the configuration and rerun the tests.
7. To view Help topics about cluster validation after you close the wizard, in Failover Cluster
Management, click Help, click Help Topics, click the Contents tab, expand the contents
for the failover cluster Help, and click Validating a Failover Cluster Configuration.

To create a cluster, you run the Create Cluster wizard.
17
To run the Create Cluster wizard
under Management, click Create a cluster.
Create Cluster Wizard
Follow the instructions in the wizard to specify:

• The servers to include in the cluster.
• The name of the cluster.
• Any IP address information that is not automatically supplied by your DHCP settings.
3. After the wizard runs and the Summary page appears, to view a report of the tasks the
wizard performed, click View Report.
18
Steps for configuring a two-node file server
cluster
To configure a two-node file server failover cluster, follow these steps:
To configure a two-node file server failover cluster

2. In the console tree, if the cluster that you created is not displayed, right-click Failover
Cluster Management, click Manage a Cluster, and then select the cluster you want to
configure.
3. In the console tree, click the plus sign next to the cluster that you created to expand the
items underneath it.
4. If the clustered servers are connected to a network that is not to be used for network
communication in the cluster (for example, a network intended only for iSCSI), then under
Networks, right-click that network, click Properties, and then click Do not allow the
cluster to use this network. Click OK.
5. Click Services and Applications. Under Actions (on the right), click Configure a
Service or Application.
High Availability Wizard
19
6. Review the text on the first page of the wizard, and then click Next.
List of Services and Applications in the High Availability Wizard
20
7. Click File Server, and then click Next.
8. Follow the instructions in the wizard to specify the following details:
• A name for the clustered file server
• Any IP address information that is not automatically supplied by your DHCP
settings—for example, a static IPv4 address for this clustered file server
• The storage volume or volumes that the clustered file server should use
10. To close the wizard, click Finish.
11. In the console tree, make sure Services and Applications is expanded, and then select
the clustered file server that you just created.
12. Under Actions, click Add a shared folder.
The Provision a Shared Folder Wizard appears. This is the same wizard that you would
use to provision a share on a nonclustered file server.
13. Follow the instructions in the wizard to specify the following settings for the shared folder:
• Path and name.
• NTFS permissions (optional).
21
• Advanced settings for the SMB protocol (optional). SMB is used by Windows-based
clients. The settings include:
- User limits.
- Offline settings (caching).
- Access-based enumeration, described in Shared folders in a failover cluster, earlier
in this guide.
• Whether the NFS protocol will be used, for support of UNIX-based clients (optional).
14. After completing the wizard, confirm that the clustered file server comes online. If it does
not, review the state of the networks and storage and correct any issues. Then right-click
the new clustered file server and click Bring this service or application online.
15. To perform a basic test of failover, right-click the clustered file server, click Move this
service or application to another node, and click the available choice of node. When
prompted, confirm your choice.
You can observe the status changes in the center pane of the snap-in as the clustered
file server instance is moved.
The following resources provide additional information about failover clusters:
• For more information about iSCSI, see the iSCSI FAQ on the Microsoft Web site
• For information about the improvements in failover clusters as compared to server clusters in
Windows Server 2003, see "What's New in Failover Clusters" on the Microsoft Web site
22
Node Print Server Failover Cluster in
Windows Server 2008
Author: Jan Keller
Editor: Ronald Loi
Abstract
service (a process known as failover). This guide describes the steps for installing and
configuring a print server failover cluster that has two nodes. By creating the configuration in this
guide, you can learn about failover clusters and familiarize yourself with the Failover Cluster
Management snap-in.
1
countries.
2
Contents
Step-by-Step Guide for Configuring a Two-Node Print Server Failover Cluster in Windows Server
2008 ............................................................................................................................................. 5
In this guide............................................................................................................................... 5
Overview for a two-node print server cluster ............................................................................... 5
Requirements for a two-node failover cluster .............................................................................. 7
Hardware requirements for a two-node failover cluster ............................................................ 7
Deploying storage area networks with failover clusters ........................................................ 9
Software requirements for a two-node failover cluster ............................................................. 9
Network infrastructure and domain account requirements for a two-node failover cluster .... 10
Steps for installing a two-node print server cluster .................................................................... 11
Step 1: Connect the cluster servers to the networks and storage .......................................... 11
Step 2: Install the failover cluster feature ............................................................................... 12
Step 3: Validate the cluster configuration ............................................................................... 14
Step 4: Create the cluster ....................................................................................................... 16
Steps for configuring a two-node print server cluster................................................................. 17
3
Node Print Server Failover Cluster in
Windows Server 2008
This guide describes the steps for installing and configuring a print server failover cluster that has
two nodes. By creating the configuration in this guide, you can learn about failover clusters and
familiarize yourself with the Failover Cluster Management snap-in interface in
Windows Server® 2008 Enterprise or Windows Server® 2008 Datacenter.
Note
The failover cluster feature is not available in Windows Web Server 2008 or Windows
In Windows Server 2008, the improvements to failover clusters (formerly known as server
been improved, as has the way a failover cluster communicates with storage. For more
information about improvements to failover clusters, see
In this guide
Overview for a two-node print server cluster
Steps for installing a two-node print server cluster
Steps for configuring a two-node print server cluster
Overview for a two-node print server cluster

Servers in a failover cluster can function in a variety of roles, including the roles of file server,
print server, mail server, or database server, and they can provide high availability for a variety of
other services and applications. This guide describes how to configure a two-node print server
cluster.
5
A failover cluster usually includes a storage unit that is physically connected to all the servers in
the cluster, although any given volume in the storage is only accessed by one server at a time.
The following diagram shows a two-node failover cluster connected to a storage unit.
Failover cluster with two nodes connected to a storage unit
Storage volumes or logical unit numbers (LUNs) exposed to the nodes in a cluster must not be
exposed to other servers, including servers in another cluster. The following diagram illustrates
this.
Two failover clusters, each with its own LUNs
Note that for the maximum availability of any server, it is important to follow best practices for
server management—for example, carefully managing the physical environment of the servers,
6
testing software changes before fully implementing them, and carefully keeping track of software
updates and configuration changes on all clustered servers.
The following scenario describes how a print server failover cluster can be configured.

To create a failover cluster with two nodes (regardless of the service or application that the nodes
provide), you need the hardware, software, accounts, and network infrastructure described in the
sections that follow.
We recommend that you first use the information provided in this guide in a test lab environment.
A Step-by-Step guide is not necessarily meant to be used to deploy Windows Server features
without the accompanying documentation (as listed in the Additional references section), and it
should be used with discretion as a stand-alone document.
Hardware requirements for a two-node failover cluster

You will need the following hardware for a two-node failover cluster:
• Servers: We recommend that you use a set of matching computers that contain the same or
similar components.
Important
You should use only hardware components that are compatible with Windows
Server 2008.
• Network adapters and cable (for network communication): The network hardware, like
other components in the failover cluster solution, must be compatible with Windows
Server 2008. If you use iSCSI, your network adapters must be dedicated to either network
communication or iSCSI, not both.
In the network infrastructure that connects your cluster nodes, avoid having single points of
failure. There are multiple ways of accomplishing this. You can connect your cluster nodes by
multiple, distinct networks. Alternatively, you can connect your cluster nodes with one
network that is constructed with teamed network adapters, redundant switches, redundant
routers, or similar hardware that removes single points of failure.
Note
If you connect cluster nodes with a single network, the network will pass the
redundancy requirement in the Validate a Configuration Wizard. However, the report
from the wizard will include a warning that the network should not have single points
of failure.
7
For more details about the network configuration required for a failover cluster, see Network
infrastructure and domain account requirements for a two-node failover cluster, later in this
topic.
• Device controllers or appropriate adapters for the storage:
• For Serial Attached SCSI or Fibre Channel: If you are using Serial Attached SCSI or
Fibre Channel, in all clustered servers, the mass-storage device controllers that are
dedicated to the cluster storage should be identical. They should also use the same
firmware version.
Note
With Windows Server 2008, you cannot use parallel SCSI to connect the storage
to the clustered servers.
• For iSCSI: If you are using iSCSI, each clustered server must have one or more network
adapters or host bus adapters that are dedicated to the cluster storage. The network you
use for iSCSI cannot be used for network communication. In all clustered servers, the
network adapters you use to connect to the iSCSI storage target should be identical, and
we recommend that you use Gigabit Ethernet or higher.
For iSCSI, you cannot use teamed network adapters, because they are not supported
with iSCSI.
For more information about iSCSI, see the iSCSI FAQ on the Microsoft Web site
• Storage: You must use shared storage that is compatible with Windows Server 2008.
For a two-node failover cluster, the storage should contain at least two separate volumes
(LUNs), configured at the hardware level. One volume will function as the witness disk
(described in the next paragraph). One volume will contain the print drivers, print spooler
directory, and print monitors. Storage requirements include the following:
• To use the native disk support included in failover clustering, use basic disks, not
dynamic disks.
• We recommend that you format the partitions with NTFS (for the witness disk, the
partition must be NTFS).
• For the partition style of the disk, you can use either master boot record (MBR) or GUID
partition table (GPT).
The witness disk is a disk in the cluster storage that is designated to hold a copy of the
cluster configuration database. (A witness disk is part of some, not all, quorum
configurations.) For this two-node cluster, the quorum configuration will be Node and Disk
Majority, the default for a cluster with an even number of nodes. Node and Disk Majority
means that the nodes and the witness disk each contain copies of the cluster configuration,
and the cluster has quorum as long as a majority (two out of three) of these copies are
available.
8
Deploying storage area networks with failover clusters
When deploying a storage area network (SAN) with a failover cluster, follow these guidelines:
• Confirm compatibility of the storage: Confirm with manufacturers and vendors that the
storage, including drivers, firmware, and software used for the storage, are compatible with
failover clusters in Windows Server 2008.
Important
Storage that was compatible with server clusters in Windows Server 2003 might not
be compatible with failover clusters in Windows Server 2008. Contact your vendor to
ensure that your storage is compatible with failover clusters in Windows Server 2008.
Failover clusters include the following new requirements for storage:
• Because improvements in failover clusters require that the storage respond correctly to
specific SCSI commands, the storage must follow the standard called SCSI Primary
Commands-3 (SPC-3). In particular, the storage must support Persistent Reservations as
specified in the SPC-3 standard.
• The miniport driver used for the storage must work with the Microsoft Storport storage
driver.
• Isolate storage devices, one cluster per device: Servers from different clusters must not
be able to access the same storage devices. In most cases, a LUN that is used for one set of
cluster servers should be isolated from all other servers through LUN masking or zoning.
• Consider using multipath I/O software: In a highly available storage fabric, you can deploy
failover clusters with multiple host bus adapters by using multipath I/O software. This
provides the highest level of redundancy and availability. For Windows Server 2008, your
multipath solution must be based on Microsoft Multipath I/O (MPIO). Your hardware vendor
will usually supply an MPIO device-specific module (DSM) for your hardware, although
Windows Server 2008 includes one or more DSMs as part of the operating system.
Important
Host bus adapters and multipath I/O software can be very version sensitive. If you
are implementing a multipath solution for your cluster, you should work closely with
your hardware vendor to choose the correct adapters, firmware, and software for
Software requirements for a two-node failover cluster

The servers for a two-node failover cluster must run the same version of Windows Server 2008,
including the same hardware version (32-bit, x64-based, or Itanium architecture-based). They
should also have the same software updates (patches) and service packs.
9
Network infrastructure and domain account requirements for a
two-node failover cluster
You will need the following network infrastructure for a two-node failover cluster and an
administrative account with the following domain permissions:
• Network settings and IP addresses: When you use identical network adapters for a
network, also use identical communication settings on those adapters (for example, Speed,
Duplex Mode, Flow Control, and Media Type). Also, compare the settings between the
network adapter and the switch it connects to and make sure that no settings are in conflict.
If you have private networks that are not routed to the rest of your network infrastructure,
ensure that each of these private networks uses a unique subnet. This is necessary even if
you give each network adapter a unique IP address. For example, if you have a cluster node
in a central office that uses one physical network, and another node in a branch office that
uses a separate physical network, do not specify 10.0.0.0/24 for both networks, even if you
give each adapter a unique IP address.
For more information about the network adapters, see Hardware requirements for a two-node
• DNS: The servers in the cluster must be using Domain Name System (DNS) for name
resolution. The DNS dynamic update protocol can be used.
• Domain role: All servers in the cluster must be in the same Active Directory domain. As a
best practice, all clustered servers should have the same domain role (either member server
or domain controller). The recommended role is member server.
• Domain controller: We recommend that your clustered servers be member servers. If they
are, you need an additional server that acts as the domain controller in the domain that
contains your failover cluster.
• Clients: As needed for testing, you can connect one or more networked clients to the failover
cluster that you create, and observe the effect on a client when you move or fail over the
clustered print server from one cluster node to the other.
• Account for administering the cluster: When you first create a cluster or add servers to it,
you must be logged on to the domain with an account that has administrator rights and
permissions on all servers in that cluster. The account does not need to be a Domain Admins
account, but can be a Domain Users account that is in the Administrators group on each
clustered server. In addition, if the account is not a Domain Admins account, the account (or
the group that the account is a member of) must be given the Create Computer Objects
permission in the domain.
Note
There is a change in the way the Cluster service runs in Windows Server 2008, as
compared to Windows Server 2003. In Windows Server 2008, there is no Cluster
service account. Instead, the Cluster service automatically runs in a special context
10
that provides the specific permissions and privileges that are necessary for the
service (similar to the local system context, but with reduced privileges).
Steps for installing a two-node print server cluster

You must complete the following steps to install a two-node print server failover cluster.
If you have already installed the cluster nodes and want to configure a file server failover cluster,
see Steps for configuring a two-node file server cluster, later in this guide.

Use the following instructions to connect your selected cluster servers to networks and storage.
Note
Review Hardware Requirements for a Two-Node Failover Cluster earlier in this guide, for
details about the kinds of network adapters and device controllers that you can use with
For a failover cluster network, avoid having single points of failure. There are multiple ways of
accomplishing this. You can connect your cluster nodes by multiple, distinct networks.
Alternatively, you can connect your cluster nodes with one network that is constructed with
teamed network adapters, redundant switches, redundant routers, or similar hardware that
removes single points of failure (If you use a network for iSCSI, you must create this network in
addition to the other networks).
For a two-node print server cluster, when you connect the servers to the cluster storage, you
must expose at least two volumes (LUNs). You can expose additional volumes as needed for
thorough testing of your configuration. Do not expose the clustered volumes to servers that are
not in the cluster.
To connect the cluster servers to the networks and storage

1. Review the details about networks in Hardware Requirements for a Two-Node Failover
Cluster and Network infrastructure and domain account requirements for a two-node
2. Connect and configure the networks that the servers in the cluster will use.
3. If your test configuration includes clients or a non-clustered domain controller, make sure
that these computers can connect to the clustered servers through at least one network.
11
4. Follow the manufacturer's instructions for physically connecting the servers to the
storage.
5. Ensure that the disks (LUNs) that you want to use in the cluster are exposed to the
servers that you will cluster (and only those servers). You can use any of the following
interfaces to expose disks or LUNs:
• The interface provided by the manufacturer of the storage.
• If you are using iSCSI, an appropriate iSCSI interface.
• Microsoft Storage Manager for SANs (part of the operating system in Windows
Server 2008). To use this interface, you need to contact the manufacturer of your
storage for a Virtual Disk Service (VDS) provider package that is designed for your
storage.
6. If you have purchased software that controls the format or function of the disk, follow
instructions from the vendor about how to use that software with Windows Server 2008.
7. On one of the servers that you want to cluster, click Start, click Administrative Tools,
click Computer Management, and then click Disk Management. (If the User Account
Control dialog box appears, confirm that the action it displays is what you want, and then
click Continue.) In Disk Management, confirm that the cluster disks are visible.
8. If you want to have a storage volume larger than 2 terabytes, and you are using the
Windows interface to control the format of the disk, convert that disk to the partition style
called GUID partition table (GPT). To do this, back up any data on the disk, delete all
volumes on the disk and then, in Disk Management, right-click the disk (not a partition)
and click Convert to GPT Disk.
For volumes smaller than 2 terabytes, instead of using GPT, you can use the partition
style called master boot record (MBR).
Important
You can use either MBR or GPT for a disk that is used by a failover cluster, but you cannot
use a disk that you converted to dynamic by using Disk Management.
If you purchased software that controls the format or function of the disk, contact the vendor
for instructions about how to use that software with Windows Server 2008.
9. Check the format of any exposed volume or LUN. We recommend NTFS for the format
(for the witness disk, you must use NTFS).

In this step, you install the failover cluster feature. The servers must be running Windows
Server 2008.
12
To install the failover cluster feature on the servers
1. If you recently installed Windows Server 2008, the Initial Configuration Tasks interface
is displayed, as shown in the following illustration.
Initial Configuration Tasks
If this interface is displayed, under Customize This Server, click Add features. Then
skip to step 3.
2. If the Initial Configuration Tasks interface is not displayed and Server Manager is not
running, click Start, click Administrative Tools, and then click Server Manager. (If the
User Account Control dialog box appears, confirm that the action it displays is what you
want, and then click Continue.)
Server Manager
13
In Server Manager, under Features Summary, click Add Features.
3. In the Add Features Wizard, click Failover Clustering, and then click Install.
4. Follow the instructions in the wizard to complete the installation of the feature. When the
wizard finishes, close it.
5. Repeat the process for each server that you want to include in the cluster.

Before creating a cluster, we strongly recommend that you validate your configuration. Validation
helps you confirm that the configuration of your servers, network, and storage meets a set of
specific requirements for failover clusters.
To validate the failover cluster configuration

Failover Cluster Management snap-in
14
under Management, click Validate a Configuration.
Validate a Configuration Wizard
15
3. Follow the instructions in the wizard to specify the two servers and the tests, and then run
the tests. To fully validate your configuration, run all tests before creating a cluster.
4. The Summary page appears after the tests run. To view Help topics that will help you
interpret the results, click More about cluster validation tests.
5. While still on the Summary page, click View Report and read the test results.
To view the results of the tests after you close the wizard, see
SystemRoot\Cluster\Reports\Validation Report date and time.html
where SystemRoot is the folder in which the operating system is installed (for example,
C:\Windows).
6. As necessary, make changes in the configuration and rerun the tests.
7. To view Help topics about cluster validation after you close the wizard, in Failover Cluster
Management, click Help, click Help Topics, click the Contents tab, expand the contents
for the failover cluster Help, and click Validating a Failover Cluster Configuration.

To create a cluster, you run the Create Cluster wizard.
16
To run the Create Cluster wizard
under Management, click Create a cluster.
Create Cluster Wizard
Follow the instructions in the wizard to specify:

• The servers to include in the cluster.
• The name of the cluster.
• Any IP address information that is not automatically supplied by your DHCP settings.
Steps for configuring a two-node print server

cluster
To configure a two-node print server failover cluster, follow these steps:
17
To configure a two-node print server failover cluster
2. In the console tree, if the cluster that you created is not displayed, right-click Failover
Cluster Management, click Manage a Cluster, and then select the cluster you want to
configure.
3. In the console tree, click the plus sign next to the cluster that you created to expand the
items underneath it.
4. If the clustered servers are connected to a network that is not to be used for network
communication in the cluster (for example, a network intended only for iSCSI), then under
Networks, right-click that network, click Properties, and then click Do not allow the
cluster to use this network. Click OK.
5. Click Services and Applications. Under Actions (on the right), click Configure a
Service or Application.
High Availability Wizard
6. Review the text on the first page of the wizard, and then click Next.
18
List of Services and Applications in the High Availability Wizard
7. Click Print Server, and then click Next.

8. Follow the instructions in the wizard to specify the following details:
• A name for the clustered print server
• Any IP address information that is not automatically supplied by your DHCP
settings—for example, a static IPv4 address for this clustered print server
• The storage volume or volumes that the clustered print server should use
10. To close the wizard, click Finish.
11. In the console tree, make sure Services and Applications is expanded, and then select
the clustered print server that you just created.
12. Under Actions, click Manage Printers.
An instance of the Failover Cluster Management interface appears with Print
Management in the console tree.
13. Under Print Management, click Print Servers and locate the clustered print server that
19
you want to configure.
Always perform management tasks on the clustered print server. Do not manage the
individual cluster nodes as print servers.
14. Right-click the clustered print server, and then click Add Printer. Follow the instructions
in the wizard to add a printer.
This is the same wizard you would use to add a printer on a nonclustered server.
15. When you have finished configuring settings for the clustered print server, to close the
instance of the Failover Cluster Management interface with Print Management in the
console tree, click File and then click Exit.
16. To perform a basic test of failover, right-click the clustered print server instance, click
Move this service or application to another node, and click the available choice of
node. When prompted, confirm your choice.
You can observe the status changes in the center pane of the snap-in as the clustered
print server instance is moved.
The following resources provide additional information about failover clusters:
• For more information about iSCSI, see the iSCSI FAQ on the Microsoft Web site
• For information about the improvements in failover clusters as compared to server clusters in
Windows Server 2003, see "What's New in Failover Clusters" on the Microsoft Web site
20
Step-by-Step Guide for Windows Deployment
Services in Windows Server 2008
Author: Trina Gorman
Editor: Dia Reeves
Abstract
This guide provides an introduction to Windows Deployment Services in Windows Server® 2008.
It includes an overview of features, tasks you can use to test Windows Deployment Services, and
details about the technology.
1
Active Directory, Microsoft, MS-DOS, Visual Basic, Visual Studio, Windows, Windows NT, Active
Directory, and Windows Server are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
This product contains graphics filter software; this software is based, in part, on the work of the
Independent JPEG Group.
2
Contents
Windows Deployment Services Role Step-by-Step Guide .............................................................. 5
In this guide .................................................................................................................................. 5
What is Windows Deployment Services? .................................................................................... 5
What’s new in Windows Deployment Services? ....................................................................... 6
Who should use this guide?...................................................................................................... 7
Benefits of Windows Deployment Services .............................................................................. 7
Installing Windows Deployment Services .................................................................................... 8
Prerequisites for installing Windows Deployment Services ...................................................... 8
Steps for installing Windows Deployment Services.................................................................. 9
Upgrading from a server running Windows Server 2003 with SP1 or SP2 ................................. 9
Configuring Windows Deployment Services .............................................................................. 10
Known issues with configuring Windows Deployment Services............................................. 11
Steps for configuring Windows Deployment Services ............................................................ 11
Using the Windows interface ............................................................................................... 12
Using WDSUTIL at a command prompt .............................................................................. 13
Configuring the boot menu ......................................................................................................... 13
Prerequisites for configuring the boot menu ........................................................................... 13
Known issues with configuring the boot menu ....................................................................... 14
Steps for configuring the boot menu ....................................................................................... 14
Creating and modifying images.................................................................................................. 15
Prerequisites for creating and modifying images.................................................................... 16
Known issues with creating images ........................................................................................ 16
Steps for creating images ....................................................................................................... 16
Boot images......................................................................................................................... 16
Install images....................................................................................................................... 19
Installing an operating system.................................................................................................... 21
Prerequisites for installing an operating system ..................................................................... 21
Steps for installing an operating system ................................................................................. 21
Using unattend files .................................................................................................................... 21
Prerequisites for using unattend files...................................................................................... 22
Known issues with using unattend files .................................................................................. 22
Steps for using unattend files ................................................................................................. 22
Configuring unattended installation for the Windows Deployment Services client ............. 22
Configuring unattend installation for Windows Setup.......................................................... 23
Creating a multicast transmission .............................................................................................. 24
Prerequisites for creating a multicast transmission ................................................................ 24
Known issues in creating a multicast transmission ................................................................ 24
3
Steps for creating a multicast transmission ............................................................................ 25
Using the Windows interface ............................................................................................... 25
Using WDSUTIL .................................................................................................................. 26
Transport Server ........................................................................................................................ 28
Configuring Transport Server ................................................................................................. 28
Known issues with configuring Transport Server ................................................................ 28
Steps for configuring Transport Server ............................................................................... 28
Creating a namespace with Transport Server ........................................................................ 29
Prerequisites for creating a namespace with Transport Server .......................................... 29
Steps for creating a namespace with Transport Server ...................................................... 29
Steps for client computers to join a namespace ................................................................. 32
Appendix A: Sample client unattend file .................................................................................... 33
4
Windows Deployment Services Role Step-by-
Step Guide
This guide contains step-by-step guidance for how to use the Windows Deployment Services role
in Windows Server® 2008. This guide does not pertain to the Windows Deployment Services
Update for Windows Server 2003 (which is included in Windows Automated Installation Kit
(Windows AIK) and in Windows Server 2003 SP2). For more information about the update, see
To download a .doc version of this guide, see http://go.microsoft.com/fwlink/?LinkId=89381.
To provide feedback about this topic, e-mail wdsdoc@microsoft.com.
Note
This guide focuses primarily on the functionality of the complete installation of Windows
Deployment Services (Deployment Server). For information about how to configure and
use Transport Server, see the Transport Server section.
In this guide
• What is Windows Deployment Services?
• Installing Windows Deployment Services
• Upgrading from a server running Windows Server 2003 with SP1 or SP2
• Configuring Windows Deployment Services
• Configuring the boot menu
• Creating and modifying images
• Installing an operating system
• Using unattend files
• Creating a multicast transmission
• Transport Server
• Appendix A: Sample client unattend file
What is Windows Deployment Services?

The Windows Deployment Services role in Windows Server 2008 is the updated and redesigned
version of Remote Installation Services (RIS). Windows Deployment Services enables you to
deploy Windows operating systems, particularly Windows Vista® and Windows Server 2008. You
5
can use it to set up new computers by using a network-based installation. This means that you do
not have to be physically present at each computer and you do not have to install each operating
system directly from a CD or DVD. The components of Windows Deployment Services are
organized into the following three categories:
• Server components. These components include a Pre-Boot Execution Environment (PXE)
server and Trivial File Transfer Protocol (TFTP) server for network booting a client to load
and install an operating system. Also included is a shared folder and image repository that
contains boot images, install images, and files that you need specifically for network boot.
There is also a networking layer, a multicast component, and a diagnostics component.
• Client components. These components include a graphical user interface that runs within
the Windows Pre-Installation Environment (Windows PE). When a user selects an operating
system image, the client components communicate with the server components to install the
image.
• Management components. These components are a set of tools that you use to manage
the server, operating system images, and client computer accounts.
What’s new in Windows Deployment Services?

Windows Deployment Services for Windows Server 2008 includes several modifications to RIS
features. There are also modifications from Windows Deployment Services that you can install
onto computers running Windows Server 2003.
Changes from RIS Changes from Windows Deployment Services on

Windows Server 2003
• Ability to deploy Windows Vista and • Ability to transmit data and images using
Windows Server 2008. multicast functionality.
• Support for Windows PE as a boot • Ability to transmit data and images using
operating system. multicast functionality on a standalone
• Support for the Windows image (.wim) server (when you install Transport Server).
format. • Does not support RISETUP images or
• Ability to transmit data and images using OSChooser screens.
multicast functionality. • Enhanced TFTP server.
• Ability to transmit data and images using • Supports network boots of x64-based
multicast functionality on a standalone computers with Extensible Firmware
server (when you install Transport Server). Interface (EFI).
• An extensible and higher-performing PXE • Metric reporting for installations.
server component.
• A new boot menu format for selecting boot
operating systems.
6
Changes from RIS Changes from Windows Deployment Services on
Windows Server 2003
• A new graphical user interface that you can
use to select and deploy images and to
manage Windows Deployment Services
servers and clients.
Who should use this guide?

Windows Deployment Services is intended for deployment specialists who are responsible for the
deployment of Windows operating systems in an organization. This guide assumes that you have
a working knowledge of common desktop deployment technologies, networking components
including Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and
Active Directory® Domain Services. The target audiences are:
• IT planners or analysts evaluating Windows Vista or Windows Server 2008
• Enterprise IT planners or designers
• Deployment specialists interested in deploying images to computers without operating
systems
Benefits of Windows Deployment Services

Windows Deployment Services provides the following benefits:
• Reduces the complexity of deployments and the cost associated with inefficient manual
installation processes.
• Allows network-based installation of Windows operating systems including Windows Vista
and Windows Server 2008.
• Deploys Windows images to computers without operating systems.
• Supports mixed environments that include Windows Vista, Windows Server 2008, Microsoft
Windows XP and Microsoft Windows Server 2003.
• Provides an end-to-end solution for the deployment of Windows operating systems to client
computers and servers.
• Built on standard Windows Server 2008 setup technologies including Windows PE, .wim files,
and image-based setup.
7
Installing Windows Deployment Services
Prerequisites for installing Windows Deployment Services
The following are requirements for installing this role, depending on if you choose Deployment
Server or Transport Server during the installation.
Deployment Server Transport Server
• Active Directory Domain Services. A There are no requirements for installing

Windows Deployment Services server must Transport Server. However, see Prerequisites
be either a member of an Active Directory for creating a namespace with transport server
Domain Services domain or a domain for a list of requirements that you need to use
controller for an Active Directory Domain the functionality of Transport Server.
Services domain. The Active Directory
Important
Domain Services domain and forest
versions are irrelevant; all domain and This guide focuses primarily on the
forest configurations support Windows functionality of Deployment Server. For
Deployment Services. information about how to configure and
use Transport Server, see Transport
• DHCP. You must have a working Dynamic
Server.
Host Configuration Protocol (DHCP) server
with an active scope on the network
because Windows Deployment Services
uses Pre-Boot Execution Environment
(PXE), which relies on DHCP for IP
addressing.
• DNS. You must have a working Dynamic
Name Services (DNS) server on the
network to run Windows Deployment
Services.
• NTFS volume. The server running
Windows Deployment Services requires an
NTFS file system volume for the image
store.
• Credentials. To install the role, you must
be a member of the Local Administrators
group on the Windows Deployment
Services server. To start the Windows
Deployment Services client, you must be a
member of the Domain Users group.
8
Steps for installing Windows Deployment Services
You can install Windows Deployment Services using the Initial Configuration Wizard or Server
Manager.
• To start the installation using the Initial Configuration Wizard, click Add roles on the Initial
Configuration Tasks startup screen. Click Next and then select Windows Deployment
Services.
• To start the installation using Server Manager, click Add roles which is located within the
Roles Summary pane. Click Next and then select Windows Deployment Services.
During the installation, you have two installation options to choose from:
• Transport Server. This option provides a subset of the functionality of Windows Deployment
Services. It contains only the core networking parts. You can use Transport Server to create
multicast namespaces that transmit data (including operating system images) from a
standalone server. You should use this option if you want to transmit data using multicasting,
but do not want to incorporate all of Windows Deployment Services.
• Deployment Server. This option provides the full functionality of Windows Deployment
Services, which you can use to configure and remotely install Windows operating systems.
With Windows Deployment Services, you can create and customize images and then use
them to re-image computers. Deployment Server is dependent on the core parts of Transport
Server.
Important
This guide focuses primarily on the functionality of Deployment Server. For
information about how to configure and use Transport Server, see Transport Server.
Upgrading from a server running Windows Server

2003 with SP1 or SP2
There are three modes of operation for Windows Deployment Services in Windows Server 2003:
Legacy, Mixed, and Native. Only servers in Native mode can upgrade to Windows Server 2008.
Your upgrade will be blocked if RIS is configured, or if the Windows Deployment Services is in
Legacy or Mixed mode. To check the operating mode that you are in, run WDSUTIL /get-server
/show:config.
Consider the following scenarios:
• If RIS is currently running on the server but you do not have Windows Deployment Services
installed, then you must install it before upgrading. Windows Deployment Services is included
in the Windows Automated Installation Kit (Windows AIK) and Windows Server 2003 Service
Pack 2. For more information about how to install and configure, see the Windows
Deployment Services Update Step-by-Step Guide for Windows Server 2003
9
(http://go.microsoft.com/fwlink/?LinkId=94643). Then use the instructions below to change
from Legacy mode (default) to Native mode.
• If RIS was installed on the server when you installed Windows Deployment Services, it will be
in Legacy or Mixed mode—you will need to change it to Native mode before upgrading.
• If RIS was not installed on the server when you installed Windows Deployment Services, the
server will be in Native mode and therefore ready to be upgraded to Windows Server 2008.
Use the following procedures to change the server mode to Native.
To change the server mode from Legacy to Mixed

1. Initialize the server by doing one of the following:
• Using the MMC snap-in. On the Start menu, click Administrative Tools, and then
click Windows Deployment Services. Right-click the server and select Initialize
Server.
• Using WDSUTIL. Run WDSUTIL /Initialize-Server /RemInst:C:\RemoteInstall
(assuming C:\RemoteInstall is the location of your REMINST shared folder).
2. When the process completes, use the following procedure to change the server mode to
Native.
To change a server mode from Mixed to Native

1. Decide whether to retire your RISETUP and RIPREP images or convert them to .wim
format. To retire them, simply delete the images. If you wish to convert them, you have
two options:
• Offline conversion (RIPREP images only)
• Deploy and recapture (RIPREP or RISETUP images)
For more information about these options, download the guide located at
(http://go.microsoft.com/fwlink/?LinkId=81031) and see "Chapter 7: Working With
Images".
2. Run WDSUTIL /Set-Server /ForceNative.
3. When the process completes, the server is ready to be upgraded to Windows
Server 2008.
Configuring Windows Deployment Services

You can configure Windows Deployment Services by using the Windows Deployment Services
MMC snap-in or by using WDSUTIL at the command prompt. Configuring Windows Deployment
Services involves the following actions:
10
• Creating a shared folder that contains the files necessary for PXE boot, the files for booting
Windows PE into RAMDISK, Windows PE boot images, and install images for Windows Vista
or Windows Server 2008.
• Configuring the answer settings of the PXE listener to control whether and how the server
services incoming client boot requests.
• If Microsoft DHCP is installed on the same physical computer as Windows Deployment
Services, the configuration wizard does the following (if you configure Windows Deployment
Services by using WDSUTIL, you have to manually make these changes):
• Adds DHCP option tag 60, with the PXE client setting selected, to all DHCP scopes (as a
DHCP global option). This is necessary so that a booting PXE client can be notified that
there is a listening PXE server on the network.
• Selects the Do not Listen on port 67 option. This is necessary so that booting clients
can find the DHCP server on the network.
Known issues with configuring Windows Deployment Services

You should note the following issues when configuring your server:
• IPv6 is not supported for this version of Windows Deployment Services. Even though the
management utilities show that you can specify the IPv6 address range, these options do
nothing in this version of Windows Deployment Services.
• You should use only the boot.wim file from the Windows Server 2008 DVD. If you use the
boot.wim file from the Windows Vista DVD, you will not be able to use the full functionality of
Windows Deployment Services (for example, multicasting).
• If you are running Windows Deployment Services and a non-Microsoft DHCP server on the
same computer, in addition to configuring the server to not listen on port 67, you will need to
use your DHCP tools to add Option 60 to their DHCP scopes.
• If DHCP is installed on a server that is located in a different subnet, then you will need to do
one of the following:
• (recommended) Configure your IP Helper tables. All DHCP broadcasts on UDP port 67
by client computers should be forwarded directly to both the DHCP server and the
Windows Deployment Services PXE server. Also, all traffic to UDP port 4011 from the
client computers to the Windows Deployment Services PXE server should be routed
appropriately (these requests direct traffic to the server, not broadcasts).
• Add DHCP options 66 and 67.
Steps for configuring Windows Deployment Services

You can configure Windows Deployment Services by using either of the following:
• The Windows interface.
11
• WDSUTIL at a command prompt.
Using the Windows interface
To configure Windows Deployment Services

1. Click Start, click Administrative Tools, and then click Windows Deployment Services.
2. In the left-hand pane of the Windows Deployment Services MMC snap-in, click to expand
the server list.
3. Right-click the server and click Configure Server.
4. Follow the instructions in the wizard.
5. When the configuration is complete, click to clear the Add images to Windows
Deployment Services now check box and then click Finish.
To add the default boot image included in the product installation DVD
1. Click the server to which you want to add the boot image.
2. Right-click the Boot Images node, and then click Add Boot Image.
3. Browse to choose the default boot image (boot.wim) located on the Windows
Server 2008 DVD, in the \Sources directory.
4. Click Open, and then click Next.
5. Follow the instructions in the wizard to add the image.
To add the default install image(s) included in the product installation DVD
1. Click the server to which you want to add the install image.
2. Right-click the Install Images node, and then click Add Install Image.
3. Specify a name for the image group, and then click Next.
4. Browse to select the default install image (install.wim) located on the Windows Vista or
Windows Server 2008 DVD, in the \Sources directory, and then click Open.
5. To add a subset of the images included in the install.wim, then clear the check boxes for
the images that you do not want to add to the server. You should only add the images for
which you have licenses.
6. Follow the instructions in the wizard to add the images.
To add additional custom images

• Follow the instructions in Creating and modifying images if you would like to do the
following:
• Create a capture image based on the boot image that you added in the previous
12
procedure.
• Create a custom install image.
Using WDSUTIL at a command prompt
To configure from a command prompt

1. Click Start, right-click Command Prompt, and then click Run as administrator.
2. Type the following command where <driveletter> is the name of the NTFS formatted drive
and <foldername> is the name of the directory where you want to create the shared
folder:
WDSUTIL /initialize-server /reminst:"<driveletter>\<foldername>"
3. To set the answer policy to answer all clients, run:
WDSUTIL /Set-Server /AnswerClients:all
4. If you are installing Windows Deployment Services on a computer with Microsoft DHCP
installed, run WDSUTIL /Set-Server /UseDHCPPorts:no /DHCPoption60:yes
5. To add a boot image, run the following command where <bootimage> is the full path to
the boot image:
WDSUTIL /Add-Image /ImageFile:<bootimage> /ImageType:boot
6. To add an install image, run the following where <installimage> is the full path to the
install image and <name> is the name of the image group to create. (You can append
/SingleImage:<imagename> to add only one of the images included in the install.wim.):
WDSUTIL /add-image /ImageFile:<installimage> /ImageType:install
/ImageGroup:<name>
Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt.
Configuring the boot menu

When you PXE boot a computer, the Windows Deployment Services client presents a boot menu.
The boot menu allows Windows Deployment Services to support separate boot architectures and
a choice of boot images for each architecture type. This mechanism uses the same Boot
Configuration Data (BCD) menu structure that is used in Windows Vista and Windows
Server 2008.
Prerequisites for configuring the boot menu

To complete this task, ensure that you are a member of the Local Administrators Group on the
Windows Deployment Services server.
13
Known issues with configuring the boot menu
Note the following issues and limitations with the boot menu:
• The boot menu can contain no more than 13 boot images. This is because of a limitation
in the number of characters displayed from within the operating system loader boot menu.
• The name of the .wim file that contains the boot image cannot contain any spaces. This
file can contain only letters or numbers.
• Double-byte character sets used as image names might not display properly in the
boot menu. This issue pertains to localized strings. Limitations within the BIOS character
sets do not allow the characters to display properly.
Steps for configuring the boot menu

The Windows Deployment Services boot menu will appear when you PXE boot a computer, and
more than one supported boot image exists on the Windows Deployment Services server. You
can accomplish many tasks by using Windows PE boot images—for example, you could have
boot images that:
• Launch Setup to install Windows.
• Reformat the hard disks to support BitLocker Drive Encryption (using unattend) and then
install Windows.
• Contain the Windows Recovery Environment (Windows RE) that you want to use when a
computer fails to start.
• Contain the Windows Deployment Services Image Capture Wizard, which creates an install
image from the client computer's operating system.
• Includes a Windows PE image for administrators who want perform other operations from
within Windows PE.
In addition, x64-based computers can run x86-based or x64-based Windows PE boot images.
Therefore, for each of these tasks, you could have two boot images—one for x86 and one for
x64. In this case, the boot menu on x86-based computers will only display the x86 boot images
(because x86-based computers cannot run x64 boot images).
Note
The default behavior is for x64-based computers to display both x86-based and x64-
based boot images when both are available. To change this default, run WDSUTIL /Set-
Server /Defaultx86x64ImageType:{x86|x64|both}.
The following procedures outline how to add more boot images to the boot menu. To view help
for WDSUTIL, type WDSUTIL /? at a command prompt.
To add an additional boot image by using the Windows interface

1. In the left-hand pane of the Windows Deployment Services MMC snap-in, click to expand
14
the server list, and then choose the server to which you want to add the boot image.
2. Right-click the Boot Images node, and then click Add Boot Image.
3. Click Browse to locate the boot image that you want to add. The boot image must be
located on the server and it can be the same or different architecture.
4. Follow the instructions in the wizard to add an additional boot image.
5. When you have completed this procedure and you PXE boot a client computer, a boot
menu will appear that shows both boot images.
To add an additional boot image at a command prompt

2. Run the following command to add an additional boot image, where <bootimage> is the
full path to the boot image on the server. The image can be the same or a different
architecture.
WDSUTIL /Add-Image /ImageFile:<bootimage> /ImageType:boot
3. When you have completed this procedure and you PXE boot a client computer, a boot
menu will appear that shows both boot images.
Note
To make any additional changes to the boot menu, use Bcdedit.exe to edit the default.bcd file
located at %REMINST%\boot\<architecture>. You can run bcdedit /? at a command prompt to
see the command line options.
For more information about Bcdedit, see Boot Configuration Data Editor Frequently Asked
Questions (http://go.microsoft.com/fwlink/?LinkID=65818).
Creating and modifying images

With Windows Deployment Services you can create and modify boot images and install images.
• Boot images. Boot images are the images that you boot a client computer into to perform an
operating system installation.
• Install images. Install images are the operating system images that you deploy to the client
computer.
You can modify images to add files or drivers without having to create a new image using the
tools in the Windows AIK. The processes are similar for a boot or install image, however the tool
sets and syntax vary between image types. Detailed information about modifying .wim files is
available in the Windows AIK User's Guide for Windows Vista
15
Prerequisites for creating and modifying images
To create and modify boot or install images, adhere to the following prerequisites:
• Ensure that there is enough disk space to create and store the new images.
• Be a member of the Local Administrators Group on the Windows Deployment Services
server.
• Match the version of Sysprep.exe with the version of the operating system that you want to
capture.
• Install the Windows AIK if you are creating bootable ISO images
• Have a writeable CD or DVD and a disk-burning utility (if you are burning an image to
media—for example a discover image),
Known issues with creating images

You cannot add split .wim (.swm) files to your Windows Deployment Services server. Instead, you
must combine the split images into a single .wim file.
Steps for creating images

The information in this section explains how you can create and modify boot images and install
images.
Boot images
Boot images are the images that you boot a client computer into before installing the operating
system image. The boot image presents a boot menu that contains the images that users can
install onto their computers. These images contain Windows PE 2.0 and the Windows
Deployment Services client. You can use the default boot image (boot.wim) that is included in the
Windows Server 2008 installation media in the \Sources directory. Except in advanced scenarios
(for example, if you need to add drivers to the image), you will not need to modify this file.
Important
You should use only the boot.wim file from the Windows Server 2008 DVD. If you use the
boot.wim file from the Windows Vista DVD, you will not be able to use the full functionality
of Windows Deployment Services (for example, multicasting).
You can create the following types of boot images using Windows Deployment Services:
• Capture images. The images that you boot a client computer into in order to capture the
operating system into a .wim file.
• Discover images. The images used to install an operating system onto a computer that is
not PXE enabled.
16
Create a capture image to capture a custom operating system into a .wim file
Capture images are boot images that launch the Windows Deployment Services Capture Utility
instead of Setup. When you boot a reference computer (that has been prepared with Sysprep)
into a capture image, a wizard creates an install image of the reference computer and saves it as
a .wim file.
You can also create media (CD, DVD, USB drive, and so on) that contains a capture image, and
then boot a computer from the media. After you create the install image, you can add the image
to the server for PXE boot deployment. These images provide an alternative to the command-line
utility, ImageX.exe.
To create a capture image using the Windows interface

1. In the Windows Deployment Services MMC snap-in, expand the Boot Images node.
2. Right-click the image to use it as a capture image.
3. Click Create Capture Boot Image.
4. Type a name, description, and the location to save a local copy of the file. You must
specify a location in case there is a problem with the network when you deploy the
capture image.
5. Continue to follow the instructions in the wizard, and when it is complete, click Finish.
6. Right-click the boot image folder.
7. Click Add Boot Image.
8. Browse and select the new capture image, and then click Next.
9. Follow the instructions in the Windows Deployment Services Capture Utility.
10. Once you have created the capture image, follow the instructions in the Install Image
section to boot a client computer into the capture image and capture the operating
system.
To create a capture image at a command prompt

2. Type the following where <bootimage> is the name of the boot image you want to use to
create the capture image, and <captureimage> is the file path and file name of the new
capture image:
WDSUTIL /New-CaptureImage /Image:<bootimage> /Architecture:x86
/Filepath:<captureimage>
3. Type the following where <captureimage> is the file path and file name of the capture
image you want to add to the image store:
17
WDSUTIL /Add-Image /Imagefile:<captureimage> /ImageType:boot
Note
4. Once you have created the capture image, follow the instructions in the Install Image
section to boot a client computer into the capture image and capture the operating
system.
Create a discover image to install an image onto a computer that is not PXE enabled
Discover images are boot images that force Setup.exe to launch in Windows Deployment
Services mode and then discover a Windows Deployment Services server. These images are
typically used to deploy images to computers that are not PXE enabled or that are on networks
that do not allow PXE. When you create a discover image and save it to media (CD, DVD, USB
drive, and so on), you can then boot a computer to the media. The discover image on the media
locates a Windows Deployment Services server, and the server deploys the install image to the
computer.
Note
You can configure discover images to target a specific Windows Deployment Services
server. This means that if you have multiple servers in your environment, you can create
a discover image for each, and then name them based on the name of the server.
To create a discover image by using the Windows interface

1. In the Windows Deployment Services MMC snap-in, expand the Boot images node.
2. Right-click the image you want to use as a discover image.
3. Click Create Discover Boot Image.
4. Follow the instructions in the wizard, and when it is complete, click Finish.
5. Right-click the boot image folder.
6. Click Add Boot Image.
7. Browse and select the new discover image, and then click Next.
8. Follow the instructions in the wizard.
To create a discover image at a command prompt

1. Click Start, click All Programs, click Accessories, right-click Command Prompt, and
then click Run as administrator.
2. Type the following where <bootimage> is the name of the boot image that you want to
use to create the discover image, and <discoverimage> is the file path and file name of
the new discover image:
WDSUTIL /New-DiscoverImage /Image:<bootimage> /Architecture:x86
18
/Filepath:<discoverimage>
3. If you want to add the discover image back to the image store, type the following where
<discoverimage> is the file path and file name of the discover image you want to add to
the image store:
WDSUTIL /Add-Image /ImageFile:<discoverimage> /ImageType:boot
Note
To create media that contains the discover image

1. Download and install the Windows AIK (http://go.microsoft.com/fwlink/?LinkId=81030).
2. Open a command prompt and change to the PETools folder:
Cd C:\Program Files\Windows AIK\Tools\PETools
3. To create a Windows PE build environment, type:
CopyPE <architecture> C:\Winpe
4. To copy the discover image that you created in the previous procedure, type:
Copy /y c:\boot.wim c:\Winpe\ISO\Sources
5. To change back to the PETools folder, type:
Cd C:\Program Files\Windows AIK\Tools\PETools
6. To create the bootable ISO image, type:
Oscdimg -n -bc:\winpe\ISO\boot\etfsboot.com c:\winpe\ISO c:\winpe.iso
7. Use a utility that can create a CD or DVD to transfer the ISO image to the appropriate
media.
Note
Using the Windows copy command to copy the image to media will not create a
bootable disk.
Install images
You can build custom install images from reference computers and deploy them to client
computers. A reference computer can be a computer with a standard Windows installation or a
Windows installation that has been configured for a specific environment. First, you boot a
computer (which has been prepared with Sysprep) into a capture image, then the capture image
creates an install image of the computer.
To create an custom install image of a reference computer

1. Create a capture image and add it to the Windows Deployment Services server (See
19
Create a capture image to capture a custom operating system in .wim format for more
information).
2. Create a reference computer (install the operating system, applications, and make any
other changes that you want).
3. At a command prompt on the reference computer, change folders to
\Windows\System32\Sysprep or the folder that contains Sysprep.exe and Setupcl.exe.
4. Type one of the following:
• On computers running Windows Vista, run sysprep /oobe /generalize /reboot
Note
If you prefer, you can also use the Sysprep graphical user interface by
double-clicking Sysprep.exe.
• On computers running Windows XP, run sysprep -mini -reseal
5. When the computer restarts, press F12.
6. In Windows Boot Manager, select the capture image, and then click Next.
7. Choose the appropriate drive, and then provide a name and description for the image.
Click Next to continue.
Important
You will only see drives that contain operating systems prepared with Sysprep. If
you do not run the command in step 4, you will not see any drives to capture.
8. Click Browse and browse to a local location where you want to store the captured install
image.
Important
You must enter a local location to save the new image or you will not be able to
capture the image. This requirement is enforced to avoid image corruption in the
event of a network malfunction.
9. Type a name for the image (use the .wim file name extension), and then click Save.
10. Click Upload image to WDS server.
11. Type the name of the Windows Deployment Services server, and then click Connect.
12. If prompted for credentials, provide a user name and password for an account with
sufficient permissions to connect to the Windows Deployment Services server.
13. On the Image Group list, choose the image group in which to store the image.
14. Click Finish.
20
Installing an operating system
Windows Deployment Services relies on Pre-Boot Execution Environment (PXE) technology to
allow a client computer to network boot and remotely connect over a TCP/IP network connection
to a Windows Deployment Services server.
Prerequisites for installing an operating system

The following are the requirements to remotely connect to a Windows Deployment Services
server:
• The client computer must be capable of PXE boot.
• An appropriately configured Windows Deployment Services server must be available in the
domain.
• Your user account must be a member of the Domain Users group.
• The client computer must have 512 MB of RAM, which is required to use Windows PE).
Steps for installing an operating system

To PXE boot a computer to install an image, complete the steps in this section.
To install an operating system

1. Configure the BIOS of the computer to enable PXE boot, and set the boot order so that it
is booting from the network is first.
2. Restart the computer and when prompted, press F12 to initiate the PXE boot process.
3. Select the appropriate boot image from the boot menu. (This boot image selection menu
will only be available if you have two or more boot images on the Windows Deployment
Services server. For more information, see Configuring the boot menu)
4. Select the locale that you want Setup to run in.
5. When prompted, provide a user name and password with sufficient credentials to install
images from the Windows Deployment Services server.
6. Continue to follow the instructions in the Windows Deployment Services client.
7. When installation is complete, the computer will reboot and Setup will continue.
Using unattend files

Windows Deployment Services allows you to automate the Windows Deployment Services client
and the latter stages of Windows Setup. This two-stage approach is accomplished by using two
different unattend files.
21
• Windows Deployment Services client unattend file. This file uses the Unattend.xml format
and is stored on the Windows Deployment Services server in the \WDSClientUnattend folder.
It is used to automate the Windows Deployment Services client user interface screens (such
as entering credentials, choosing an install image, and configuring the disk).
• Image unattend file. This file uses the Unattend.xml or Sysprep.inf format, depending upon
the version of the operating system in the image. It is stored in a subfolder (either $OEM$
structure or \Unattend) in the per-image folder. It is used to automate the remaining phases of
setup (for example, offline servicing, Sysprep specialize, and mini-setup).
Prerequisites for using unattend files

• Ensure that you are a member of the Local Administrators Group on the Windows
Deployment Services server.
• Ensure that you have sufficient credentials to add a computer to a domain.
Known issues with using unattend files

Windows Deployment Services management tools only assign install image unattend files for
Windows Vista and Windows Server 2008 images. For down-level images, you must use your
existing Sysprep.inf files and manually create a $OEM$ directory structure.
Steps for using unattend files

To automate the installation, create the appropriate unattend file depending on whether you are
configuring the Windows Deployment Services client or Windows Setup. We recommend that you
use Windows System Image Manager, (included as part of the Windows AIK) to author the
unattend files. Then copy the unattend file to the appropriate location, and assign it for use. You
can assign it at the server level or the client level. The server level assignment can further be
broken down by architecture, allowing you to have differing settings for x86-based and x64-based
clients. Assignment at the client level overrides the server-level settings.
Configuring unattended installation for the Windows Deployment Services

client
To associate a client unattend file by architecture using the Windows interface

1. Create an Unattend.xml file with settings applicable to the Windows Deployment Services
client.
See Appendix A for a sample client unattend file.
2. Copy the client unattend file to RemoteInstall\WDSClientUnattend.
3. Open the Windows Deployment Services MMC snap-in, and right-click the server that
contains the Windows Vista or Windows Server 2008 image that you want to associate
22
the unattend file to, and then click Properties.
4. On the Client tab, select Enable unattended installation, browse to the appropriate
unattend file, and then click Open.
5. Click OK to close the Properties page.
To associate a client unattend file by architecture using a command line

2. Type the following where <filepath> is the path name and file name of the client unattend
file, and architecture is the architecture of the client to automate (x86 or x64):
WDSUTIL /Set-Server /WDSUnattend /Policy:enabled /File:<filepath>
/Architecture:<arch>
Note
To associate a client unattend file per computer at a command prompt

2. Type the following where <relative path>is the path from the REMINST share to the
folder that contains client unattend file:
WDSUTIL /Set-Device /Device:<computername> /ID:<GUID or MAC address>
/WDSClientUnattend:<relative path>
Configuring unattend installation for Windows Setup
To associate a image unattend file to an image by using the Windows interface

1. From the Windows Deployment Services MMC snap-in, click to expand the image group
that contains the Windows Vista or Windows Server 2008 image.
2. Right-click the image that you want to associate the unattend file to, and click Properties.
3. On the General tab, click Allow image to install in unattend mode.
4. Click Select File, browse to select the unattend file and then click OK.
5. Click OK.
To associate a image unattend file to an image at a command prompt

2. Type the following, where:
• <imagename> is the name of the image with which to associate the unattend file.
23
• <imagegroupname> is the name of the image group containing the image file.
• <unattendfile> is the path and file name of the unattend file to associate with the
image.
WDSUTIL /Set-Image /Image:<imagename> /ImageType:install
/ImageGroup:<imagegroupname> /UnattendFile:<unattendfile>
Creating a multicast transmission

Multicast transmissions allow you to deploy an image to a large number of client computers
without overburdening the network. When you create a multicast transmission, the image is sent
over the network only once, which can drastically reduce the network bandwidth that is used.
Note
For information about using multicast functionality with Transport Server, see the
Transport Server section.
Prerequisites for creating a multicast transmission

To implement this feature in your organization, you must have:
• Routers that support multicasting.
• At least one install image (that you want to transmit) on the server.
• The boot.wim file from the Windows Server 2008 media (located in the \Sources folder).
Known issues in creating a multicast transmission

You may encounter the following issues when implementing multicasting:
• The boot.wim from the Windows Vista DVD will not work with multicast transmission. You
must use the boot.wim from the Windows Server 2008 media. If you use the Windows Vista
file, you will be able to create the transmission, but people who boot into it will not be able to
join a transmission.
• Multicasting in this version of Windows Deployment Services does not work with Multicast
Address Dynamic Client Allocation Protocol (MADCAP).
• If multiple servers are using multicast functionality on a network (Transport Server,
Deployment Server, or another solution), it is important that each server is configured so that
the multicast IP addresses do not collide. Otherwise, you may encounter excessive traffic
when you enable multicasting. Note that each Windows Deployment Services server will
have the same default range. To workaround this issue, specify static ranges that do not
overlap to ensure that each server is using a unique IP address.
• After you configure Windows Deployment Services server, if you modify the Multicast IP
Address, the UDP Port Range, or the RPC port number (by running wdsutil /set-server
24
/rpcport:<portnum>), you must restart the service before the changes will take effect. If you
do not restart the service, the server will use the old values and may not answer clients. To
restart the service, you can either 1) right-click Windows Deployment Services in the MMC
snap-in and click Restart or 2) run net stop wdsserver and then run net start wdsserver
from the command line.
Steps for creating a multicast transmission

You can create transmissions through either of the following options.
• Using the Windows interface
• Using WDSUTIL
Using the Windows interface

To enable multicasting for an image, you must create a multicast transmission for it. In Windows,
you have two options for creating a multicast transmission:
• Right-click the Multicast Transmission node, and then click Create Multicast
Transmission.
• Right-click an image, and then click Create Multicast Transmission.
Selecting multicast type

There are two types of multicast transmissions:
• Auto-Cast. This option indicates that as soon as an applicable client requests an install
image, a multicast transmission of the selected image begins. Then, as other clients request
the same image, they too are joined to the transmission that is already started.
• Scheduled-Cast. This option sets the start criteria for the transmission based on the number
of clients that are requesting an image and/or a specific day and time. If you do not select
either of these check boxes, then the transmission will not start until you manually start the
transmission. Note that in addition to these criteria, you can start a transmission manually at
any time by right-clicking the transmission and clicking Start.
Note
Content is transferred over the network only if clients request data. If no clients are
connected (that is, the transmission is idle), then data will not be sent over the
network.
Configuring transmissions
After a transmission is created, you can do the following:
• Start the transmission. If the transmission is on a Scheduled-Cast, there is at least one
client, and the transmission has not started yet, you can right-click the transmission, and click
Start.
25
• Delete the transmission. If you right-click the transmission and click Delete, the multicast
transmission stops and each client installation will fall back to using unicast. That is, the client
installations will not be deleted or stopped, but they will not use the multicast transmission to
complete the installation.
• Deactivate the transmission. If you right-click and click Deactivate, each client that is
currently installing will continue, but no new clients will be joined to the transmission. After
each current client installation is complete, the transmission will be deleted. If there are no
clients when you click this option, then it will be deleted instantly.
• View properties. To view the properties, right-click the transmission, and click Properties.
Note that you cannot edit the properties of a transmission after it is created. To make a
change after you have created a transmission, you need to delete and recreate it.
• Refresh the transmissions and data. To do this, right-click a transmission and click
Refresh. You can also refresh the data by pressing F5.
Configuring clients in a transmission

After you have created the transmission, client computers join the transmission by selecting the
image in the Windows Deployment Services client. Client computers can also join a transmission
using Wdsmcast.exe—a command line tool included in the Windows AIK. When there are clients
in a transmission, you can:
• Viewclients and see progress. To view any connected clients, expand the Multicast
Transmissions node, and click the image. The connected clients (including the current
installation time and the percent complete) are shown in the right pane.
• Stop a client installation. To stop the installation completely, right-click a client and click
Disconnect. You should use this option with caution because the installation will fail and the
computer could be left in an unusable state.
• Disconnect a client from a multicast transmission. To discontinue the transmission for a
particular client but continue to transfer the image through unicasting, right-click the client,
and then click Bypass multicast.
Using WDSUTIL
Creating a multicast transmission for an install image
You have two options for transmission type: Auto-Cast and Scheduled-Cast.
• To create an Auto-Cast transmission, run:
WDSUTIL /New-MulticastTransmission /Image:<image name> /FriendlyName:<friendly
name> /ImageType:Install /ImageGroup:<Image group name> /TransmissionType:AutoCast
• To create a Scheduled-Cast transmission, run:
26
WDSUTIL /New-MulticastTransmission /Image:<image name> /FriendlyName:<friendly
name> /ImageType:Install /ImageGroup:<Image group name>
/TransmissionType:ScheduledCast [/Time:<yyyy/mm/dd:hh:mm>][/Clients:<no of clients>]
Configuring transmissions
After a transmission is created, you can start it, delete it, deactivate it, and view its properties.
• To start the transmission, run:
WDSUTIL /Start-MulticastTransmission /Image:<image name> /ImageType:Install
/ImageGroup:<image group name>
Note
You can only start the transmission if it is on a Scheduled-Cast, there is at least one
client, and the transmission is not started.
• To delete the transmission, run:
WDSUTIL /Remove-MulticastTransmission /Image:<image name> /ImageType:Install
/ImageGroup:<image group name> /Force
• To deactivate the transmission, run:
WDSUTIL /Remove-MulticastTransmission /Image:<image name> /ImageType:Install
• To view properties, run:
WDSUTIL /Get-MulticastTransmission /Image:<image name> /ImageType:Install
Configuring clients in a transmission

After you have created the transmission, client computers join the transmission by selecting the
image in the Windows Deployment Services client. Client computers can also join a transmission
through Wdsmcast.exe—a command line tool that is included in the Windows AIK. When there
are clients in a transmission, you can do the following actions:
• To view clients and see progress, run:
/ImageGroup:<image group name> /show:clients
• To stop a client installation completely, run:
WDSUTIL /Disconnect-Client /ClientID:<id> /Force.
Note
You should use this option with caution because the installation will fail and the
• To disconnect a client from a multicast transmission but continue to transfer the
image by using unicasting, run:
27
WDSUTIL /Disconnect-Client /ClientID:<id>
• To view client <id> for each transmission, run:
/ImageGroup:<image group name> /show:clients
Transport Server
During installation, you can choose to install only Transport Server. This option provides a subset
of the functionality of Windows Deployment Services. It contains only the core networking parts.
You can use Transport Server to create multicast namespaces that transmit data (including
operating system images) from a standalone server. The standalone server does not need Active
Directory, DHCP or DNS. You can use Transport Server in advanced scenarios as a part of a
custom deployment solution.
Configuring Transport Server
Known issues with configuring Transport Server

Note the following issues with configuring Transport Server:
• If multiple servers are using multicast functionality on a network (Transport Server,
Deployment Server, or another solution), it is important that each server is configured so that
the multicast IP addresses do not collide. Otherwise, you may encounter excessive traffic
when you enable multicasting. Note that each Windows Deployment Services server will
have the same default range. To workaround this issue, specify static ranges that do not
overlap to ensure that each server is using a unique IP address.
• Multicasting in this version of Windows Deployment Services does not work with Multicast
Address Dynamic Client Allocation Protocol (MADCAP).
Steps for configuring Transport Server

Transport Server does not require any configuration. However, you can perform the following
optional configurations:
Important
After configuring any of these settings, you must restart the WDSServer service to apply
the changes. To restart the service, run net stop wdsserver and then run net start
wdsserver at a command prompt.
• To configure multicast IP addressing, run:
WDSUTIL /Set-TransportServer /ObtainIPv4From:Range /Start:<start Ipv4 Address>
/End:<end Ipv4 Address>
• To set the UDP port range, run
28
WDSUTIL /Set-TransportServer [/Server:<name>] /StartPort:x /EndPort:y
• To set the network profile, run
WDSUTIL /Set-TransportServer [/Server:<name>] /Profile:{10Mbps|100Mbps|1Gbps|Custom}
Creating a namespace with Transport Server

You can use Transport Server to create namespaces. A namespaces is a transmission that does
not have any settings already set for you. For example, with namespaces, you have to manually
set the names for the data and data groups, the content provider, and the path to the folder that
contains the data.
Prerequisites for creating a namespace with Transport Server

To create a namespace with Transport Server, you need the following:
• A content provider. You can use the Windows Deployment Services content provider
(named WDS) that is included when you install Transport Server. Or you can create your own
using the tools in the Windows SDK.
• Data to transmit. You can transmit any data that your content provider knows how to find
(for example operating system images, data files, or an MP3 archive), The Windows
Deployment Services content provider knows how to find any file within a directory.
• Familiarity with WDSUTIL. The only way to manage Transport Server is through the
WDSUSTIL command line tool.
• A way to boot clients because Transport Server does not include a PXE listener.
• Routers. The routers in your environment must support multicasting.
Steps for creating a namespace with Transport Server

You can create Scheduled-Cast and Auto-Cast namespaces. See Options explanation for more
information about each parameter.
• To create a Scheduled-Cast namespace, run:
WDSUTIL /New-Namespace [/Server:<server name>] /Namespace:<namespace name>
/FriendlyName:<friendly name> [/Description:<description>] /ContentProvider:<name>
/ConfigString:<config string> /NamespaceType:ScheduledCast
[/Time:<YYYY/MM/DD:hh:mm>] [/Clients:<number of clients>]
For example:
WDSUTIL /New-Namespace /Server:MyWDSServer /FriendlyName:"Custom Scheduled
Namespace" /Namespace:"Custom Scheduled 1" /ContentProvider:WDS
/ConfigString:D:\Images /NamespaceType:ScheduledCast
/Time:"2006/11/20:17:00" /Clients:20
• To create an AutoCast namespace, run:
29
WDSUTIL /New-Namespace [/Server:<server>] /Namespace:<namespace name>
/FriendlyName:<friendly name> [/Description:<description>] /ContentProvider:<name>
/ConfigString:<config string> /NamespaceType:AutoCast
For example:
WDSUTIL /New-Namespace /FriendlyName:"Custom AutoCast Namespace"
/Namespace:"Custom Auto 1" /ContentProvider:WDS /ConfigString:D:\Images
/NamespaceType:AutoCast
Common commands
The following are the most commonly used commands with Transport Server. See Options
explanation for more information about each parameter.
• To start the transmission, run:
WDSUTIL /Start-Namespace /Namespace:<name>
Note
To start a transmission, the transmission must be a Scheduled-Cast and there must
be at least one client who has requested the transmission of data.
• To display information about a namespace and the clients connected to it (for
example, computer name, MAC address, IP address, speed, and percent complete),
run:
WDSUTIL /Get-Namespace /Namespace:<name> /Show:Clients
• To remove a namespace, run:
WDSUTIL /Remove-Namespace [/Server:<server name>] /Namespace:<namespace name>
[/Force]
For example:
• To remove the namespace after current client downloads are complete, run: WDSUTIL
/Remove-Namespace /Namespace:"Custom Auto 1"
• To remove the namespace immediately and stop any current client downloads, run:
WDSUTIL /Remove-Namespace /Server:MyWDSServer /Namespace:"Custom Auto 1"
/Force
• To stop a client installation completely, run:
WDSUTIL /Disconnect-Client /ClientID:<id> /Force
Important
You should use this option with caution because the installation will fail and the
• To discontinue the download for a client but continue to transfer the image through
another method (such as SMB copy), run:
WDSUTIL /Disconnect-Client /ClientID:<id>
30
• To view the client <id> for each namespace, run:
WDSUTIL /Get-Namespace /Namespace:<name> /show:clients
Options explanation
Option Description
/Server:<server name> Specifies the name of the Windows Deployment Services

server. This can be either the NetBIOS name or the
FQDN. If not specified, the local server will be used.
/Namespace:<Namespace name> Specifies the name of the namespace. This is not the
friendly name and it must be unique.
• Deployment Server: The syntax for namespace name
is
/Namspace:WDS:<ImageGroup>/<ImageName>/<Ind
ex>. For example: WDS:ImageGroup1/install.wim/1
• Transport Server: This value should match the name
given when creating the namespace on the server.
/FriendlyName:<friendly name> Specifies the friendly name of the namespace. This name
does not need to be unique.
/Description:<description> Specifies a description of the namespace.
/ContentProvider:<name> Specifies the name of the content provider that supplies

data to the multicast server. If you are using the Windows
Deployment Services content provider, specify WDS.
/ConfigString:<config string> Specifies the configuration string for the content provider.
If you are using the Windows Deployment Services
content provider (WDS), specify the path to the directory
where content is stored (for example
D:\Photos\Landscapes). This path can be anywhere on
the server.
/NamespaceType: Specifies the type of namespace to create.

{AutoCast|ScheduledCast}
/Time:<YYYY/MM/DD:hh:mm> Specifies the time on server when the namespace will

start (allowed only for Scheduled-Cast).
/Clients:<Num of Clients> Specifies the number of clients to wait for before
31
Option Description
namespace will start (allowed only for Scheduled-Cast).
/Force Deletes the transmission—even if there are current client

installations. If you do not specify /Force, the
transmission will be in the Delete Pending state. (After
clients downloads are complete, the transmission will be
removed.)
Steps for client computers to join a namespace

In Transport Server, client computers join a transmission using Wdsmcast.exe (a command-line
tool included in the Windows AIK). Wdsmcast.exe runs on Windows Server 2003, Windows Vista,
Windows Server 2008, or Windows PE 2.0.
To join a namespace
1. Install Wdsmcast.exe onto the client computer.
• If the client has an operating system (Windows Vista or Windows Server 2003), you
can install the Windows AIK. Wdsmcast.exe is in the Tools directory.
• If the client does not have an operating system, then you need to add Wdsmcast.exe
to a Windows PE image and boot the client into the image. Instructions for doing this
are included in the Windows AIK (http://go.microsoft.com/fwlink/?LinkId=81030).
2. Run the following from the client computer:
WDSMCAST /Transfer-File /Server:<server name> /Namespace:<namespace name>
/Username:<domain and user name> [/Password:<password>] /SourceFile:<file path>
/DestinationFile:<file path>
Option Explanation
/Server:<server name> Specifies the name of the Windows Deployment Services

server. This can be either the NetBIOS name or the
FQDN.
/Namespace:<Namespace name> Specifies the name of the namespace. This is not the
friendly name and it must be unique.
• Deployment Server: The syntax for namespace name
is
/Namspace:WDS:<ImageGroup>/<ImageName>/<Ind
ex>. For example: WDS:ImageGroup1/install.wim/1
• Transport Server: This value should match the name
32
Option Explanation
given when creating the namespace on the server.
/Username:<domain and user name> Domain and user name to connect to the server with. Can
be in the format Domain\User or User@Domain.
[/Password:<password>] Password for the user. If this is not specified, you will be
prompted to enter it.
/SourceFile:<file path> Path to the file to be transferred, relative to the root

directory of the content provider (for example, if you are
using the Windows Deployment Services content provider
(named WDS), the path is relative to the ConfigString
directory).
/DestinationFile:<file path> Complete file path and name for the destination file.
• For a newsgroup about Windows Deployment Services, see Setup and Deployment
• Windows AIK (http://go.microsoft.com/fwlink/?LinkId=81030)
• Windows AIK User's Guide for Windows Vista (http://go.microsoft.com/fwlink/?LinkID=53552)
• Sysprep (http://go.microsoft.com/fwlink/?LinkId=87732)
• For more information about the Windows Deployment Services Update for Windows
Server 2003, see the following:
• Windows Deployment Services Update Step-by-Step Guide for Windows Server 2003
• Deploying and Managing the Windows Deployment Services Update on Windows
Server 2003 (http://go.microsoft.com/fwlink/?LinkId=81031)
Appendix A: Sample client unattend file

The following is a sample Windows Deployment Services client unattend file:
<?xml version="1.0" ?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35"
33
<WindowsDeploymentServices>
<Login>
<Credentials>
<Username>username</Username>
<Domain>wds-dom</Domain>
<Password>my_password</Password>
</Credentials>
</Login>
<ImageSelection>
<InstallImage>
<ImageName>Windows Vista with Office</ImageName>
<ImageGroup>ImageGroup1</ImageGroup>
<Filename>Install.wim</Filename>
</InstallImage>
<InstallTo>
<DiskID>0</DiskID>
</InstallTo>
</ImageSelection>
</WindowsDeploymentServices>
<DiskConfiguration>
<Disk>
<DiskID>0</DiskID>
<WillWipeDisk>false</WillWipeDisk>
<ModifyPartitions>
<ModifyPartition>
<Order>1</Order>
<Letter>C</Letter>
34
<Label>TestOS</Label>
<Format>NTFS</Format>
<Active>true</Active>
<Extend>false</Extend>
</ModifyPartition>
</ModifyPartitions>
</Disk>
</DiskConfiguration>
</component>
<component name="Microsoft-Windows-International-Core-WinPE"
publicKeyToken="31bf3856ad364e35"
<SetupUILanguage>
<UILanguage>en-US</UILanguage>
</SetupUILanguage>
<UILanguage>en-US</UILanguage>
</component>
</settings>
</unattend>
35
Step-by-Step Guide to Deploying Policies for
Windows Firewall with Advanced Security
Published: October 2007
Author: Dave Bishop
Editor: Scott Somohano
Technical Reviewers: Sarah Wahlert, Tom Baxter, Siddharth Patil, L. Joan Devraun
MVP Reviewers: Michael Gotch, Rodrigo Immaginario, Robert Stuczynski
Abstract
This guide shows you how to centrally configure and distribute commonly used settings and rules
for Windows Firewall with Advanced Security by describing typical tasks in a common scenario.
you get hands-on experience in a lab environment using Group Policy management tools to
create and edit GPOs to implement typical firewall settings. You also configure GPOs to
implement common server and domain isolation scenarios and see the effects of those settings.
1
The information contained in this document represents the current view of Microsoft Corporation
on the issues discussed as of the date of publication. Because Microsoft must respond to
changing market conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the
date of publication.
This Step-by-Step Guide is for informational purposes only. MICROSOFT MAKES NO

WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS
DOCUMENT.
Unless otherwise noted, the companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted in examples herein are fictitious. No
association with any real company, organization, product, domain name, e-mail address, logo,
person, place, or event is intended or should be inferred.
Microsoft Windows Server, Windows Vista, and Windows XP are trademarks of the Microsoft
group of companies.
2
Contents
Step-by-Step Guide to Deploying Policies for Windows Firewall with Advanced Security ............. 5
Scenario Overview ....................................................................................................................... 5
Technology Review for Deploying Windows Firewall with Advanced Security ............................ 8
Network Location Awareness ................................................................................................... 8
Host Firewall ........................................................................................................................... 10
Connection Security and IPsec............................................................................................... 11
Group Policy ........................................................................................................................... 12
Requirements for Performing the Scenarios .............................................................................. 13
Examining Default Settings on Clients and Servers .................................................................. 17
Step 1: Starting Windows Firewall in Control Panel ............................................................... 18
Step 2: Examining the Basic Options Available by Using the Control Panel Interface .......... 19
Step 3: Examining the Basic Options by Using the Netsh Command-Line Tool .................... 21
Step 4: Examining the Basic Options Available When Using the Windows Firewall with
Advanced Security MMC snap-in ........................................................................................ 22
Deploying Basic Settings by Using Group Policy....................................................................... 23
Step 1: Creating OUs and Placing Computer Accounts in Them ........................................... 24
Step 2: Creating the GPOs to Store Settings ......................................................................... 25
Step 3: Adding the GPO Setting to Enable the Firewall on Member Client Computers ......... 26
Step 4: Deploying the Initial GPO with Test Firewall Settings ................................................ 27
Step 5: Adding the Setting that Prevents Local Administrators from Applying Conflicting Rules
............................................................................................................................................. 28
Step 6: Configuring the Rest of Your Client Computer Firewall Settings ............................... 31
Step 7: Creating WMI and Group Filters ................................................................................ 33
Step 8: Enabling Firewall Logging .......................................................................................... 37
Creating Rules that Allow Required Inbound Network Traffic .................................................... 38
Step 1: Configuring Predefined Rules by Using Group Policy ............................................... 38
Step 2: Allowing Unsolicited Inbound Network Traffic for a Specific Program ....................... 40
Step 3: Allowing Inbound Traffic to a Specific TCP or UDP Port ........................................... 43
Step 4: Allowing Inbound Network Traffic that Uses Dynamic RPC ....................................... 44
Step 5: Viewing the Firewall Log ............................................................................................ 48
Creating Rules that Block Unwanted Outbound Network Traffic ............................................... 50
Step 1: Blocking Network Traffic for a Program by Using an Outbound Rule ........................ 50
Step 2: Deploying and Testing Your Outbound Rule.............................................................. 51
Deploying a Basic Domain Isolation Policy ................................................................................ 52
Step 1: Creating a Connection Security Rule that Requests Authentication .......................... 53
Step 2: Deploying and Testing Your Connection Security Rules ........................................... 54
Step 3: Changing the Isolation Rule to Require Authentication ............................................. 57
3
Step 4: Testing Isolation with a Computer That Does Not Have the Domain Isolation Rule.. 57
Step 5: Creating Exemption Rules for Computers that are Not Domain Members ................ 58
Isolating a Server by Requiring Encryption and Group Membership ......................................... 59
Step 1: Creating the Security Group ....................................................................................... 60
Step 2: Modifying a Firewall Rule to Require Group Membership and Encryption ................ 60
Step 3: Creating a Firewall Rule on the Client to Support Encryption .................................... 61
Step 4: Testing the Rule When CLIENT1 Is Not a Member of the Group .............................. 63
Step 5: Adding CLIENT1 to the Group and Testing Again ..................................................... 63
Creating Rules that Allow Specific Computers or Users to Bypass Firewall Block Rules ......... 64
Step 1: Adding and Testing a Firewall Rule that Blocks All Telnet Traffic.............................. 65
Step 2: Modifying Your Telnet Allow Rule to Override Block Rules ....................................... 66
Summary .................................................................................................................................... 67
Additional References ................................................................................................................ 67
4
Step-by-Step Guide to Deploying Policies for
This step-by-step guide illustrates how to deploy Active Directory® Group Policy objects (GPOs)
to configure Windows Firewall with Advanced Security in Windows Vista® and
Windows Server® 2008. Although you can configure a single server locally by using Group Policy
Management tools directly on the server, that method is not consistent or efficient when you have
many computers to configure. When you have multiple computers to manage, create and edit
GPOs, and then apply those GPOs to the computers in your organization.
The goal of a Windows Firewall with Advanced Security configuration in your organization is to
improve the security of each computer by blocking unwanted network traffic from entering the
computer. Network traffic that does not match the rule set of Windows Firewall with Advanced
Security is dropped. You can also require that the network traffic which is allowed must be
protected by using authentication or encryption. The ability to manage Windows Firewall with
Advanced Security by using Group Policy allows an administrator to apply consistent settings
across the organization in a way that is not easily circumvented by the user.
In this guide, you get hands-on experience in a lab environment using Group Policy management
tools to create and edit GPOs to implement typical firewall settings. You also configure GPOs to
implement common server and domain isolation scenarios and see the effects of those settings.
Scenario Overview
In this guide, you learn about how to create and deploy settings for Windows Firewall with
Advanced Security by stepping through procedures that illustrate the common tasks you have to
perform in a typical scenario.
Specifically, you configure settings in GPOs to control the following Windows Firewall with
Advanced Security options:
• Enable or disable the Windows Firewall, and configure its basic behavior.
• Determine which programs and network ports are allowed to receive inbound network traffic.
• Determine which outbound network traffic is allowed or blocked.
• Support network traffic that uses multiple or dynamic ports, such as those that use Remote
Procedure Call (RPC), or the File Transfer Protocol (FTP).
• Require that all network traffic entering specific servers be protected by Internet Protocol
security (IPsec) authentication and optionally encrypted.
5
You work with several computers that perform common roles found in a typical network
environment. These include a domain controller, a member server, and a client computer, as
shown in the following illustration.
The scenario described in this guide includes viewing and configuring firewall settings, and
configuring a domain isolation environment. It also includes server isolation, which requires group
membership to access a server and can optionally require that all traffic to the server is
encrypted. Finally, it includes a mechanism to allow trusted network devices to bypass firewall
rules for troubleshooting.
Each of the scenario steps are described in the following sections.
Examining default settings on clients and servers

In this section, you use Windows Firewall settings in Control Panel, the netsh command-line tool,
and the Windows Firewall with Advanced Security Microsoft Management Console (MMC) snap-
in to examine the default Windows Firewall with Advanced Security settings on the both the
CLIENT1 and MBRSVR1 computers. Using the tools directly on a local computer is useful to see
the current configuration and the firewall and connection security rules that are active on the
computer.
Deploying basic settings by using Group Policy

In this section, you create a Group Policy object (GPO) that contains basic firewall settings, and
then assign that GPO to the organizational unit (OU) that contains the client computer. To ensure
that only the correct computers can apply the GPO settings, you use Windows Management
6
Instrumentation (WMI) and security group filtering to restrict applying the GPO to computers that
are running the correct version of Windows.
The GPO that you configure includes some of the basic Windows Firewall with Advanced
Security settings that are part of a typical enterprise's GPO settings, such as:
• Any local firewall setting created by a user, even a local administrator, is ignored.
• Ensure that the firewall is enabled with your specified handling of network traffic, and cannot
be disabled.
• The computer does not display the notification when Windows Firewall with Advanced
Security blocks a program from listening on a network port.
Creating rules that allow required inbound network traffic

In this section, you create inbound firewall rules that:
• Use predefined rule groups to support common network services.
• Allow a program to listen for any network traffic it needs to operate.
• Allow a program to listen for network traffic only on a specified TCP or UDP port.
• Allow a network service to listen for network traffic.
• Limit network traffic from only specified IP addresses, and to specific types of networks.
• Apply different firewall behavior based on the network location type to which the computer is
connected.
• Support programs that use the dynamic port assigning capabilities of RPC.
Creating rules that block unwanted outbound network traffic

In this section, you configure outbound firewall rules to block unapproved programs from sending
outbound traffic from a computer.
Deploying domain isolation settings

In this section, you enable GPO settings on your domain member computers that force them to
accept network connection requests only from other domain member computers.
Isolating a server by requiring encryption and group

membership
In this section, you create connection security and firewall rules that require that a server or group
of servers allow network traffic only from computers that are members of an authorized group.
The rules also specify that the traffic to and from these servers must be encrypted.
7
Creating rules that allow specific computers or users to bypass
firewall block rules
In this section, you configure firewall and connection security rules to allow specific authorized
users or computers, such as the network port scanners used by network troubleshooting and
security teams, to bypass the firewall.
Technology Review for Deploying Windows

Firewall with Advanced Security
Windows Firewall with Advanced Security combines a host-based firewall and an Internet
Engineering Task Force (IETF)-compliant implementation of Internet Protocol security (IPsec).
As a host-based firewall, Windows Firewall with Advanced Security runs on each computer that is
running Windows Server® 2008 or Windows Vista® to provide local protection from network
attacks that might pass through your perimeter network firewall or originate from inside your
organization.
Windows Firewall with Advanced Security also provides IPsec-based computer-to-computer
connection security which allows you to protect your network data by setting rules that require
authentication, integrity checking, or encryption when your computers exchange data.
Windows Firewall with Advanced Security works with both Internet Protocol version 4 (IPv4) and
IPv6 traffic.
This section of the guide provides a brief review of these features to support your understanding
of the scenarios that you examine in later sections of this guide.
• Network Location Awareness
• Host Firewall
• Connection Security and IPsec
• Group Policy
Network Location Awareness

Windows Vista® and Windows Server® 2008 support network location awareness, which allows
network-aware programs to alter their behavior based on how the computer is connected to the
network. In the case of Windows Firewall with Advanced Security, you can create rules that apply
only when the profile associated with a specific network location type is active on your computer.
How Network Location Awareness works

The following diagram shows the network location types that can be detected by Windows.
8
Windows detects the following network location types:
• Public. By default, the public network location type is assigned to all networks when they are
first connected. A public network is considered to be shared with the public, with no
protection between the local computer and any other computer.
• Private. The private network location type can be manually selected by a local administrator
for a connection to a network that is not directly accessible by the public. This connection can
be to a home or office network that is isolated from publicly accessible networks by using a
firewall device or a device that performs network address translation (NAT). Wireless
networks should be protected by using an encryption protocol such as Wi-Fi Protected
Access (WPA) or WPAv2. A network is never automatically assigned the private network
location type; it must be assigned by the administrator. Windows remembers the network,
and the next time that you connect to it, Windows automatically assigns the network the
private network location type again.
• Domain. The domain network location type is detected when the local computer is a member
of an Active Directory domain, and the local computer can authenticate to a domain controller
for that domain through one of its network connections. If those conditions are met then the
domain network location type is automatically assigned. An administrator cannot manually
assign this network location type.
Windows Firewall with Advanced Security stores its setting and rules in profiles, and supports one
profile for each network location type. The profile associated with the currently detected network
location type is the one that is applied to the computer. If the network location type changes then
the rules the profile associated with the new network location type automatically apply.
When you have multiple network adapters attached to your computer, you can be attached to
networks of different types. Windows Vista and Windows Server 2008 only support one active
network location type at a time. Windows automatically selects the network location type for the
least secure network. For example, if a computer has two active connections, one to a public
network and one to a private network, Windows selects the public network type to enable the
more rigorous security rules in its profile to protect the computer.
Windows XP and Windows Server 2003 support a domain profile that is identical in concept to the
one described above. However, instead of supporting both a private and public profile, the earlier
9
versions of Windows support only a 'standard' profile. So if you create rules by using the
Windows Firewall node in the Administrative Templates section of the Group Policy editor then
you can only specify that they apply to the domain and standard profiles. If you specify the
standard profile and then apply these rules to a computer that is running Windows Vista or
Windows Server 2008 then the rules apply when the computer’s network location profile is set to
either private or public. The rules in the domain profile still apply only when the computer’s
network location profile is set to domain.
For more information about network location awareness and its use in Windows Firewall with
Advanced Security, see the section "Network location-aware host firewall" in Getting Started with
Windows Firewall with Advanced Security at http://go.microsoft.com/fwlink/?linkid=64343.
Host Firewall
Windows Firewall with Advanced Security includes a host-based firewall component that is a
protective boundary for the local computer, which monitors and restricts information that travels
between your computer and its attached networks or the Internet. It provides an important line of
defense against someone who might try to access your computer without your permission.
In Windows Vista and Windows Server 2008, the host firewall in Windows Firewall with Advanced
Security is turned on by default, with unsolicited inbound network traffic blocked, and all outbound
traffic allowed.
How the host firewall works

Network traffic flowing in and out of your computer can be categorized as shown in the following
diagram.
Network traffic consists of a packet or a stream of packets that are sent from a source port on one
computer to a destination port on another computer. A port is just an integer value in the network
packet that identifies the program on the sending or receiving end of the connection. Generally,
only one program listens on a port at a time. To listen on a port, the program registers itself and
the port numbers to which it must listen with the operating system. When a packet arrives at the
10
local computer, the operating system examines the destination port number, and then provides
the contents of the packet to the program registered to use that port. When using the TCP/IP
protocol, a computer can receive network traffic addressed by using a specific transport protocol
such as TCP or UDP, and on any one of the ports numbered from 1 to 65,535. Many of the lower
numbered ports are reserved for well-known services, such as a Web server that uses Hyper
Text Transport Protocol (HTTP) on TCP port 80, Telnet remote terminal services on TCP port 23,
or Simple Mail Transfer Protocol (SMTP) on port 25.
Windows Firewall with Advanced Security works by examining the source and destination
addresses, source and destination ports, and protocol numbers of a packet, and then comparing
them to the rules that are defined by the administrator. When a rule matches a network packet
then the action specified in the rule (to allow or block the packet) is taken. In Windows Vista and
Windows Server 2008, functionality in Windows Firewall with Advanced Security is expanded to
include allowing or blocking network packets based on whether they are protected by IPsec
authentication or encryption.
For more information about the host firewall functionality and the new features added to Windows
Firewall with Advanced Security in Windows Vista and Windows Server 2008, see Getting Started
with Windows Firewall with Advanced Security at http://go.microsoft.com/fwlink/?linkid=64343,
and Windows Firewall on TechNet at http://go.microsoft.com/fwlink/?linkid=95393.
Connection Security and IPsec

Internet Protocol Security (IPsec) is a framework of open standards for protecting
communications over TCP/IP networks by using cryptographic security services. IPsec supports
network-level peer authentication, data origin authentication, data integrity, data confidentiality
(encryption), and replay protection. The Microsoft implementation of IPsec is based on standards
developed by the Internet Engineering Task Force (IETF) IPsec working group.
The implementation of IPsec included with Windows Vista and Windows Server 2008 is fully
integrated into the Network layer (layer 3) of the Open Systems Interconnection (OSI) network
reference model. This lets it provide protection to any IP-based protocol in a manner that is
transparent to the programs that are running on the computer.
IPsec is an important layer in a defense-in-depth strategy to protect your organization's network-
accessible resources.
How IPsec works

IPsec provides a variety of connection security services to network traffic. You can configure each
service to apply to specific network traffic by creating a connection security rule in Windows
Firewall with Advanced Security that identifies the characteristics of the network traffic to protect,
and the nature of the protection to be applied.
11
• Source authentication. Source authentication ensures that each computer that is
participating in a connection receives proof that the other computer (and optionally the user
on the other computer) is truly the entity that it claims to be.
Authentication involves each computer providing some form of credentials to the other
computer that can be proved to be from the claimed source. Kerberos tokens, which can be
checked with a domain controller, or a computer or user certificate which can be
cryptographically checked against its trusted root certificate, are among the authentication
methods generally used.
• Data integrity. Data integrity ensures that the packet that is received is identical to the
packet that was transmitted, and that it was not damaged or modified in transit.
A network packet that is part of the network connection includes a cryptographic hash of the
packet. The hash is calculated by the sending computer, encrypted, and included in the
packet. The receiving computer calculates its own hash on the received packet, and after
decrypting the included hash, compares the two hash values. If they match, the packet is
accepted and processed. If they do not match, then the packet was damaged or possibly
modified in transit, and is dropped.
• Data confidentiality. Data confidentiality ensures that the information included in the
network connection cannot be accessed or read by non-authorized computers or users.
When specified, every network packet that is part of the network connection has its data
payload encrypted. Various strength encryption protocols are available for use.
For more information about IPsec, see:
• Getting Started with Windows Firewall with Advanced Security at
http://go.microsoft.com/fwlink/?linkid=64343
• Introduction to Server and Domain Isolation at http://go.microsoft.com/fwlink/?linkid=94631
For more information about the IPsec functionality in Windows Firewall with Advanced Security
and its use in supporting serer and domain isolation, see:
• The IPsec page on TechNet at http://go.microsoft.com/fwlink/?linkid=95394
• The Server and Domain Isolation page on TechNet at
Group Policy
Group Policy enables you to perform your administrator tasks more efficiently because it enables
centralized computer and user management. Centrally managing the configuration settings of
computers and users on the network can decrease the total cost of ownership for the IT
infrastructure.
12
How Group Policy works
Group Policy is a technology available as part of an Active Directory domain services
implementation. When member computers connect to an Active Directory domain, they
automatically retrieve and apply Group Policy objects (GPOs) from the domain controller.
A GPO is a collection of settings that can be created by a domain administrator, and then applied
to groups of computers or users in the organization.
Windows Vista allows you to use Group Policy to centrally manage a greater number of features,
components, and security settings than you were able to do in earlier versions of Windows. For
example, the number of Group Policy settings has increased from approximately 1,800 in
Windows Server 2003 with Service Pack 1 to approximately 2,500 in Windows Vista and
Windows Server 2008. These new policy settings help you manage desktops, servers, security
settings, and many other aspects of running your network.
Configuration settings and rules that you want to apply to the computers in your organization are
stored in Group Policy objects (GPOs) that are maintained on the domain controllers of an Active
Directory domain. The GPOs are automatically downloaded to all assigned computers when they
connect to the domain. They are then merged with the local GPO stored on the computer, and
then applied to the computer's active configuration. Group Policy provides easy centralized
management, and detailed control of which computers receive which GPOs.
Because the capabilities of both firewall rules and the implementation of IPsec are significantly
enhanced in Windows Vista and Windows Server 2008, we recommend that administrators leave
existing GPO settings in place for earlier versions of Windows and create new GPOs for
computers that are running Windows Vista and Windows Server 2008. By applying the new
GPOs to the same set of containers as the old GPO settings, and by using WMI filters with each
GPO, you can ensure that you apply the most appropriate settings to each computer in your
organization.
For more information about Group Policy, see Windows Server Group Policy at
http://go.microsoft.com/fwlink/?linkid=93542.
Requirements for Performing the Scenarios

This section describes how to configure computers to try the scenarios for Windows Firewall with
Advanced Security in a test lab environment. Step-by-Step guides are not necessarily meant to
be used to deploy Windows Server features without accompanying documentation (as listed in
the Additional References section). Use this guide as a stand-alone document with discretion.
Caution
If you accidentally apply Windows Firewall with Advanced Security settings to a GPO that
applies to production computers, you can affect their ability to communicate with other
computers.
The computers needed for a test lab for this guide include the following:
13
1. DC1 is a computer that is running Windows Server 2008, Standard or Enterprise Edition, that
is configured to provide the following functions:
• The primary domain controller for the Contoso.com Active Directory domain
• A Domain Name System (DNS) server that can resolve names for the Contoso.com DNS
zone
2. MBRSVR1 is a computer that is running Windows Server 2008, Standard or Enterprise
Edition, configured to provide the following functions:
• A domain member in the Contoso.com domain
• A manager and editor of the Group Policy objects in the Contoso.com domain
• A Telnet server
3. CLIENT1 is a computer that is running Windows Vista, Business, Enterprise, or Ultimate
Edition, that is configured as follows:
• A domain member in the Contoso.com domain
Hardware requirements
You must meet the following hardware requirements in order to set up the test lab:
• Three computers that can run the operating systems required for the roles used in this guide
(see the "Software Requirements" section later in this guide).
• The computers must be connected to each other by using a network, but we recommend that
you use a stand-alone, isolated network that contains nothing but the computers that are
used in this guide. The computers can be physical computers attached to a physical network,
or virtual machines running in a Microsoft® Virtual Server or Virtual PC environment and
connected to an isolated virtual network.
Caution
If you connect your test network to your production environment or to the Internet then we
strongly recommend that you ensure that all computers are updated with the latest
security updates and are running appropriate antivirus protection software.
Note
The steps in this guide assume that your computers are on an isolated test lab network,
and that the names, IP addresses, and so on, do not interfere with the operation of other
computers on your production environment..
Software requirements
• For DC1: Windows Server 2008, Standard or Enterprise Edition.
• For MBRSVR1: Windows Server 2008, Standard or Enterprise Edition.
• For CLIENT1: Windows Vista, Business, Enterprise, or Ultimate Edition.
14
Required common procedures
The procedures that are shown here frequently occur in this guide, and the steps for them are not
included in-line. See the steps listed here any time that you must refer to them.
• The User Account Control dialog box appears whenever you try to perform an
administrative task. If your account is a member of the local Administrators group then you
can click Continue when you are prompted. If your user account is not an administrator then
you must provide the credentials (user name and password) of an account that has the
required permissions.
Use the following procedure when you are instructed to open an administrator command
prompt.
To open an administrator command prompt

1. Click Start, click All Programs, and then click Accessories.
2. Right-click Command Prompt, and then click Run as administrator.
Alternatively, you can do the same thing with any shortcut to the command prompt that you
put in the Start menu, the Quick Launch bar, or the desktop.
• Use the following procedure when you are instructed to open the Windows Firewall with
Advanced Security MMC snap-in.
To open the Windows Firewall with Advanced Security MMC snap-in

• Click Start, then in the Start Search box, type wf.msc, and then press ENTER.
Alternatively:
• On Windows Server 2008 you can click Start, click Administrative Tools, and then click
Windows Firewall with Advanced Security.
• On Windows Vista you can click Start, click All Programs, click Administrative Tools,
and then click Windows Firewall with Advanced Security.
Setting up the lab computers

First, set up the domain controller and create the domain that has the required user accounts.
To install and configure the domain controller DC1

1. Install Windows Server 2008 by using the following settings:
2. Set the local Administrator account password to Pass@word1.
3. Configure the network to use the following settings:
• IP address: 192.168.0.1
• Subnet mask: 255.255.255.0
15
• Default Gateway: Leave blank
• DNS Server address: 192.168.0.1
4. Name the computer DC1. Restart the computer when you are prompted.
5. Install Active Directory by using the following settings:
• Include DNS as part of the installation.
• Create a new domain in a new forest, and name the domain contoso.com.
• Use the password Pass@word1 for all user accounts.
6. After installing Active Directory, restart the computer when you are prompted.
7. Create a new user account in Contoso named Admin1, with a password of
Pass@word1.
8. Add Admin1 to the group Domain Administrators.
Now install the member server, and then configure the required services.
To install and configure the member server MBRSVR1

1. Install Windows Server 2008 by using the following settings:
2. Set the local Administrator account password to Pass@word1.
• IP address: 192.168.0.100
• Subnet mask: 255.255.255.0
4. Name the computer MBRSVR1. Restart the computer when you are prompted.
5. Join the computer to the contoso.com domain, and then restart the computer when you
are prompted.
6. Using Server Manager, install the features Group Policy Management and Telnet
Server onto the computer.
7. Configure the Telnet Server service to start automatically whenever the computer starts.
Finally, install the workstation client, and configure it.
To install and configure the client computer CLIENT1

1. Install Windows Vista by using the following settings:
2. When prompted to name the local administrator during setup, name it localadmin, and
then set its password to Pass@word1.
3. Name the computer CLIENT1.
16
4. Identify the network location type as Work.
• IP address: 192.168.0.101
• Subnet mask: 255.255.255.0
6. Name the computer CLIENT1. Restart the computer when you are prompted.
7. Using the Turn Windows features on and off option in the Program and Features
control panel program, install the Telnet Client onto the computer.
8. Join the computer to the contoso.com domain, and then restart the computer when you
are prompted.
Examining Default Settings on Clients and

Servers
The functionality provided by Windows Firewall with Advanced Security in Windows Vista and
Windows Server 2008 can be accessed by using three different user interfaces:
• Windows Firewall icon in Control Panel. This interface provides access to only basic host
firewall settings and is intended for a consumer in a non-managed environment. The
Windows Firewall icon in Control Panel has limited functionality and is designed for consumer
control of a single computer, instead of enterprise administrator control over lots of
computers.
• Netsh Advfirewall command-line tool. The netsh command provides the ability to modify
many aspects of a computer's network configuration. This includes the ability to configure the
Windows Firewall with Advanced Security settings and rules for a single computer or a GPO
that can be applied to lots of computers in an enterprise environment.
• Windows Firewall with Advanced Security Microsoft Management Console (MMC)
snap-in. This interface provides access to both firewall and IPsec functionality, and is the
primary means for an administrator to manage both an individual computer and a GPO.
Steps for examining default settings on clients and servers

In this section of the guide, you learn how to start see commenttool to see what functionality is
available through it. By using each of these tools you see the default and current configuration in
Windows Firewall with Advanced Security for computers that are running Windows Vista and
Step 1: Starting Windows Firewall in Control Panel
17
Step 2: Examining the Basic Options Available by Using the Control Panel Interface
Step 3: Examining the Basic Options by Using the Netsh Command-Line Tool
Step 4: Examining the Basic Options Available When Using the Windows Firewall with Advanced
Security MMC snap-in
Step 1: Starting Windows Firewall in Control Panel

In this step, you open the Windows Firewall icon in Control Panel on each of your domain
member computers.
To open the Windows Firewall icon in Control Panel on CLIENT1

1. On CLIENT1, log on as contoso\admin1 with the password Pass@word1.
2. Click Start, and then click Control Panel.
In Windows Vista, the default Control Panel view is Control Panel Home.
3. Click Security, and then click Windows Firewall.
4. On the Windows Firewall page, note the following default settings that are part of a
typical Windows Vista installation, as shown in the following figure:
• Windows Firewall is enabled.
• Unsolicited inbound connections that do not have an exception are blocked.
• When a program tries to listen for incoming connections and is prevented from doing
this by the firewall, a notification is displayed to the user.
• The current settings are those assigned to the Domain network location profile
because the computer is joined and authenticated to an Active Directory domain.
5. Keep Windows Firewall in Control Panel open.
Now examine the same interface on Windows Server 2008.
To open the Windows Firewall icon in Control Panel on MBRSVR1

1. On MBRSVR1, log on as contoso\admin1 with the password Pass@word1.
18
2. Click Start, and then click Control Panel.
In Windows Server 2008, the default Control Panel view is Classic View.
3. Click Windows Firewall.
4. On the Windows Firewall page, note the following default settings that are part of a
typical Windows Server 2008 installation:
• Windows Firewall is enabled.
Note
If the computer that is running Windows Server was upgraded from an earlier
version of Windows Server that included Windows Firewall then the On/Off
state is preserved in the upgrade.
• Unsolicited inbound connections that do not have an exception are blocked.
• When a program tries to listen for incoming connections and is prevented from doing
this by the firewall, a notification is not displayed to the user.
Note
This differs from the default setting on Windows Vista.
• The current settings are those assigned to the Domain network location profile
because the computer is joined to a domain and authenticated.
5. Keep Windows Firewall in Control Panel open.
Step 2: Examining the Basic Options Available by Using the

Control Panel Interface
In this step, you examine the options that you can configure by using the Windows Firewall icon
in Control Panel, and compare the differences between Windows Vista and Windows
Server 2008.
19
To examine the options available in the Windows Firewall icon in Control Panel
1. On both CLIENT1 and MBRSVR1, click Change settings on the Windows Firewall
page.
2. Examine the tabs for the few settings that you can configure by using this interface. Any
changes you make here apply only to the currently configured network location profile
(Domain network). Compare the differences between the default settings on MBRSVR1
and CLIENT1.
• General tab. On this tab, you can enable or disable the firewall. In addition, you can
choose to block all incoming connections, even when an exception exists that
ordinarily allows that connection.
Caution
Do not disable the firewall by stopping the Windows Firewall (MpsSvc)
service. The Windows Firewall service also implements Windows Service
Hardening, which provides additional protections for other Windows services.
Microsoft does not support disabling the Windows Firewall service. Instead,
use the interface shown here in the Windows Firewall icon in Control Panel
or use the Windows Firewall with Advanced Security MMC snap-in. For more
information about Windows Service Hardening, see Windows Vista Security
and Data Protection Improvements at
Note
Disabling the firewall by using the Off setting on the Windows Firewall
Settings page does not stop the Windows Firewall (MpsSvc) service. It does
stop Windows Firewall from filtering any inbound or outbound network traffic
according to the configured rules.
On MBRSVR1, you see no differences on the General tab compared to a computer
that is running Windows Vista, unless the operating system was upgraded from an
earlier version of Windows Server that had Windows Firewall installed but disabled.
When a computer that is running Windows Server is upgraded to a later version of
Windows Server, the On/Off state of the Windows Firewall is maintained.
• Exceptions tab. On this tab you can see the exceptions that have been defined to
allow specific network connections. The selected exceptions are enabled. Most of the
entries displayed here represent predefined rule sets that are included with Windows.
If you click the name of an exception and then click Properties, a description of the
exception appears. You can also create your own custom program-based and port-
based exceptions on this page. You can specify a scope to an exception: any
computer, the local subnet only, or a custom list of addresses and subnets.
A computer that is running Windows Server 2008 and configured to have a network
20
server role, such as a domain controller, typically has many more exceptions enabled
to allow access to its services than other computers. For example, the MBRSVR1
computer has the Telnet exception rule enabled because you installed that service
as part of the setup for this guide. The rule was created and enabled automatically
during the installation of the Telnet service.
By default on computers that are running Windows Server 2008, the Notify me when
Windows Firewall blocks a new program option is not selected.
• Advanced tab. On this tab you can specify which network connections, as defined in
Network and Sharing Center, are protected by the Windows Firewall. By default, all
network connections are protected. You can also use the Restore Defaults button to
remove the complete custom configuration that you have applied to the firewall.
3. On bothCLIENT1 and MBRSVR1, click OK on the Windows Firewall Settings page,
close Windows Firewall, and then close Control Panel.
Step 3: Examining the Basic Options by Using the Netsh

Command-Line Tool
In this step, you try an alternative method for seeing the basic firewall configuration options by
using the Netsh command-line tool.
To examine the basic firewall options by using Netsh

1. On MBRSVR1, open an administrator command prompt.
2. At the command prompt, run netsh advfirewall show currentprofile.
Important
You must use the advfirewall context instead of the older firewall or ipsec
contexts. Advfirewall is new to the netsh command in this version of Windows.
The firewall and ipsec contexts still exist, but are provided only for compatibility
with Group Policy settings that are created by using an earlier version of
Windows.
3. Examine the output and compare to what you saw earlier in the Windows Firewall icon in
Control Panel. Your output resembles the following figure.
21
The values State, Firewall Policy, and InboundUserNotification correspond to the
basic settings that you examined in the Windows Firewall icon in Control Panel in the
previous steps. The other settings shown in the netsh output are not configurable by
using the Windows Firewall icon in Control Panel. They are configurable by using the
netsh command-line tool, and the Windows Firewall with Advanced Security MMC snap-
in.
4. Close the command prompt.
Step 4: Examining the Basic Options Available When Using the

Windows Firewall with Advanced Security MMC snap-in
In this step, you use the Windows Firewall with Advanced Security MMC snap-in to see the basic
options available.
To examine the basic options by using the Windows Firewall with Advanced Security
MMC snap-in
1. On MBRSVR1, open Windows Firewall with Advanced Security.
2. Examine the three panes of the Windows Firewall with Advanced Security snap-in.
• The navigation pane enables you to select from the main functional areas.
• The details pane displays information about currently selected functional area.
• The actions pane displays shortcuts to available tasks that are relevant to the
currently selected functional area.
3. In the navigation pane, select the node labeled Windows Firewall with Advanced
Security.
22
The details pane displays the basic state information for each network location profile.
Because MBRSVR1 is connected to the domain, the entry for that network location profile
in the Overview section reads Domain Profile is Active.
4. In the navigation pane, right-click Windows Firewall with Advanced Security, and then
click Properties.
5. Note that there are four tabs, one for each network location profile and one for IPsec
settings. The changes you make on each profile tab only apply to the computer when the
specified network location profile is active. The IPsec Settings tab enables you to
configure the default IPsec protocol parameters that are used when a connection security
rule does not specify otherwise.
6. Click the Private Profile tab as an example. Note that for each profile, you can enable or
disable the firewall, configure the default firewall behavior for handling unsolicited
inbound connections and outbound connections, and specify logging options.
7. Click Customize in the Settings section. Note that for each profile, you can configure
notifications and how your computer responds to incoming multicast or broadcast
network traffic.
The Rule merging section is configurable only when you are managing the settings of a
Group Policy object (GPO). The settings here indicate whether the Group Policy
administrator allows a local Administrator to apply their own locally created firewall and
connection security rules. If set to No then only GPO-supplied rules are applied to the
computer and any locally defined rules are ignored.
8. Click Cancel to return to the main Properties page.
9. Click Customize in the Logging section to examine the options available for creating a
log file to capture details about the firewall's operation. Even though a log file name is
specified, nothing is written to the file until you select Yes in one of the two lists.
10. Set the value of both lists to No to disable logging. You will use this in a later section of
the guide.
11. Click Cancel two times to return to the Windows Firewall with Advanced Security snap-in.
12. You can click the other functional areas to see the currently configured Inbound Rules,
Outbound Rules, and Connection Security Rules, but do not change any of them at
this point.
Deploying Basic Settings by Using Group Policy

Use Group Policy to define and deploy specific configurations for groups of users and computers.
These configurations are created by using the Group Policy Object Editor and are contained in
one or more Group Policy objects (GPOs) stored in Active Directory. To deploy the settings, the
23
GPO is linked to one or more Active Directory containers, such as a site, a domain, or an
organizational unit (OU). The settings in the GPO are then applied automatically to the users and
computers whose objects are stored in those Active Directory containers. You can configure the
work environment for your users once, and then rely on Group Policy to enforce your settings.
For an overview of Group Policy, see the Group Policy technology review in this guide. For more
information about Group Policy, see Windows Server Group Policy at
Steps for deploying basic settings by using Group Policy

In this section, you create a set of OUs to contain your computer accounts. You then create
GPOs that contain settings that are intended for a specific set of computers. You use the Group
Policy Management Editor to configure a GPO that contains basic firewall settings, and then
assign that GPO to the OU that contains your test computer. Finally, you create and apply a
Windows Management Instrumentation (WMI) filter to restrict the application of the GPO to
computers that are running a specified operating system. This enables you to have multiple
groups of computers in a single Active Directory container (OU, site, or domain) that require
different settings, and ensure that each receives the correct GPO.
The GPOs that you configure include some of the basic Windows Firewall with Advanced
Security settings that are part of typical enterprise firewall settings.
Step 1: Creating OUs and Placing Computer Accounts in Them
Step 2: Creating the GPOs to Store Settings
Step 3: Adding the GPO Setting to Enable the Firewall on Member Client Computers
Step 4: Deploying the Initial GPO with Test Firewall Settings
Step 5: Adding the Setting that Prevents Local Administrators from Applying Conflicting Rules
Step 6: Configuring the Rest of Your Client Computer Firewall Settings
Step 7: Creating WMI and Group Filters
Step 8: Enabling Firewall Logging
Step 1: Creating OUs and Placing Computer Accounts in Them

In this step, you use the Active Directory Users and Computers MMC snap-in to create two OUs
in your domain hierarchy: one for member servers, and one for member client computers. You
then move each computer account to the relevant new OU.
To create your OUs and put your computer accounts in them

1. On DC1, click Start, click Administrative Tools, and then click Active Directory Users
and Computers.
2. In the navigation pane, right-click contoso.com, click New, and then click
24
Organizational Unit.
3. In the Name box, type MyMemberServers, and then click OK.
4. Right-click contoso.com again, and then click New, and then click Organizational Unit.
5. In the Name box, type MyClientComputers, and then click OK.
6. In the navigation pane, click Computers.
7. In the details pane, right-click CLIENT1, and then click Move.
8. In the Move dialog box, click MyClientComputers, and then click OK.
9. In the details pane, right-click MBRSVR1, and then click Move.
10. In the Move dialog box, click MyMemberServers, and then click OK.
When you have finished, your display resembles the following figure.
11. Close the Active Directory Users and Computers snap-in.
Step 2: Creating the GPOs to Store Settings

In this step, you create a new GPO. Because it is not yet linked to any OU, the settings that you
configure do not yet apply to any computers.
To create the GPOs

1. On MBRSVR1, click Start, click Administrative Tools, and then click Group Policy
Management.
2. In the navigation pane, expand Forest: contoso.com, expand Domains, and then
expand contoso.com.
25
3. In the navigation pane, right-click Group Policy Objects, and then click New.
4. In the Name box, type Firewall Settings for WS2008 Servers, and then click OK.
5. In the navigation pane, right-click Group Policy Objects, and then click New.
6. In the Name box, type Firewall Settings for Vista Clients, and then click OK.
7. Select the Group Policy Objects node, and your display resembles the following figure.
Step 3: Adding the GPO Setting to Enable the Firewall on

Member Client Computers
In this step, you configure your client GPO to include a setting that enables Windows Firewall on
all clients running Windows Vista to which the GPO applies.
To add the GPO setting to enable the firewall on member client computers
1. On MBRSVR1, in Group Policy Management, click Group Policy Objects, right-click
Firewall Settings for Vista Clients, and then click Edit.
2. In Group Policy Management Editor, right-click the top node Firewall Settings for
Vista Clients [DC1.contoso.com] Policy, and then click Properties.
3. Select the Disable User Configuration settings check box, and then click OK.
Note
You can remove either the user or computer section whenever it is not needed.
This improves performance on the client computer when it is applying a GPO.
4. In the Confirm Disable dialog box, click Yes, and then click OK.
5. Under Computer Configuration, expand Windows Settings, expand Security
Settings, and then expand Windows Firewall with Advanced Security.
6. Click the node Windows Firewall with Advanced Security -
LDAP://cn={GUID},cn=policies,cn=system,DC=contoso,DC=com, where GUID is a
26
unique number assigned to your domain.
7. In the details pane, under Overview, notice that for each network location profile
Windows Firewall state is not configured, and then click Windows Firewall
Properties.
8. On the Domain Profile tab, click the drop-down list next to Firewall state, and then click
On (recommended).
Note
This might appear to be an unnecessary step, because the firewall is turned on
by default on the client computers. However, a local administrator can disable the
firewall if you leave this setting as Not configured. Setting it in the GPO as
shown in this step turns it on and prevents the local administrators from disabling
it.
9. Click OK to save your changes. Note in the details pane that Domain Profile now shows
Windows Firewall is on.
10. Close Group Policy Management Editor.
Step 4: Deploying the Initial GPO with Test Firewall Settings

In this step, you link your GPO to an OU to apply it to your member client computer.
To deploy your firewall settings

1. On MBRSVR1, in Group Policy Management, in the navigation pane, right-click
MyClientComputers, and then click Link an Existing GPO.
27
2. In the Group Policy objects list, click Firewall Settings for Vista Clients, and then click
OK.
In the next procedure, you confirm that the client computer receives and applies the new GPO
settings.
To test your new GPO

1. On CLIENT1, open an administrator command prompt.
2. In the command prompt window, type gpupdate /force, and then press ENTER. Wait
until the command finishes before moving to the next step.
3. To validate that the GPO was correctly applied, run gpresult /r /scope computer. In the
output, look for the section Applied Group Policy Objects. Confirm that it contains
entries for both Firewall Settings for Vista Clients and the Default Domain Policy.
4. Open the Windows Firewall with Advanced Security snap-in.
5. Right-click the top node Windows Firewall with Advanced Security on Local
Computer, and then click Properties.
6. Note that the Firewall State setting is On, and that the list control is disabled. It is now
controlled by Group Policy and cannot be changed locally, even by an administrator.
7. Close the Properties dialog box, and the Windows Firewall with Advanced Security
snap-in.
Step 5: Adding the Setting that Prevents Local Administrators

from Applying Conflicting Rules
In this step, you configure and test a setting that prevents firewall rules created by local
administrators from being applied to the computer and possibly conflicting with the GPO-deployed
rules.
By default members of the local Administrators group on the computer can use Windows Firewall
with Advanced Security to create and enable firewall and connection security rules. These local
rules are then merged with the rules received from Group Policy and applied to the computer's
active configuration. The setting described in this section prevents the locally defined rules from
merging with the rules that are contained in the deployed GPOs.
Important
Although this setting prevents a local administrator from applying a rule, it also prevents
Windows Firewall with Advanced Security from prompting the user about a new program
and creating an inbound rule when the user approves. If you enable this setting then you
must ensure that every program that requires firewall rules has the correct rules defined
in your GPOs.
28
To confirm that a local administrator can create a conflicting rule
1. On CLIENT1, at the administrator command prompt, run ping dc1.
The ping command works, which indicates that it can communicate with DC1.
2. Start the Windows Firewall with Advanced Security snap-in.
3. Under Windows Firewall with Advanced Security, right-click Outbound Rules, and
then click New Rule.
4. On the Rule Type page of the New Outbound Rule Wizard, click Custom, and then
click Next.
5. On the Program page, select All programs, and then click Next.
6. On the Protocol and Ports page, use the default settings, and then click Next.
7. On the Scope page, use the default settings, and then click Next.
8. On the Action page, use the default settings, and then click Next.
9. On the Profile page, clear the check boxes for Private and Public, but leave Domain
selected, and then click Next.
10. On the Name page, enter the name A Test Rule (use an 'A' as the first character to
ensure the rule appears at the top of the list), and then click Finish.
This creates a firewall rule that blocks all network traffic, effectively breaking
communications for the computer.
11. Return to the command prompt window, and run ping dc1 again.
The ping command fails, as shown in the following figure, because the local firewall rule
blocks outgoing communications.
29
12. In the Windows Firewall with Advanced Security snap-in, click Outbound Rules in the
navigation pane, right-click A Test Rule, and then click Disable Rule. You must disable
the rule to re-enable communication for the next steps.
13. Leave the Administrator: Command Prompt window and Windows Firewall with
Advanced Security snap-in open.
In the next procedure, you modify the GPO assigned to the client computer to prevent locally
defined rules from being merged and applied to the active firewall configuration. Also, you disable
the notification that asks the user whether to allow a program for which there are no rules.
To prevent the computer from using rules and settings defined by local administrators
2. In Group Policy Management Editor, expand Computer Configuration, expand
Windows Settings, expand Security Settings, and then expand Windows Firewall
3. Right-click Windows Firewall with Advanced Security -
LDAP://cn={GUID},cn=policies,cn=system,DC=contoso,DC=com, and then click
Properties.
4. On the Domain Profile tab, in the Settings section, click Customize.
5. Change the Display a notification setting to No. This prevents Windows from displaying
a notification to the user whenever a program is blocked.
6. In the Rule merging section, change the Apply local firewall rules list to No.
7. In the Rule merging section, change the Apply local connection security rules list to
No.
8. Click OK two times to return to Group Policy Management Editor.
In the next step, you refresh Group Policy on CLIENT1, and then confirm that locally defined rules
cannot block network communications.
To test your new restrictions on local administrators

1. On CLIENT1, in Administrator: Command Prompt, run gpupdate /force. Wait until the
command finishes.
2. In the Windows Firewall with Advanced Security snap-in, in the list of Outbound
Rules, right-click A Test Rule, and then click Enable Rule.
3. In Administrator: Command Prompt, run ping dc1.
The ping command works even though A Test Rule appears to be enabled. The rule is
listed as enabled on the local computer, but when you set the Apply local firewall rules
to No on the GPO in the previous procedure, you blocked the merging of local rules with
30
the rules delivered in the GPO.
4. In the navigation pane of the Windows Firewall with Advanced Security snap-in,
expand Monitoring, and then click Firewall to see the list of rules active on the local
computer.
No rules are listed. You have not created any rules in the GPO, and no local rules are
active because of the settings that you included in the GPO.
5. Before proceeding, delete your rule. In the navigation pane, click Outbound Rules. In
the details pane, right-click A Test Rule, click Delete, and then click Yes on the
confirmation dialog box.
6. Leave both Administrator: Command Prompt and the Windows Firewall with
Advanced Security snap-in open.
Step 6: Configuring the Rest of Your Client Computer Firewall

Settings
At this point, you have the firewall enabled, and a local administrator cannot disable it. In this
step, you complete the configuration of the client computer GPO by adding other frequently used
settings to further control the behavior of the firewall on a computer that is running
Windows Vista.
Any settings in the GPO that you leave on the default value of "Not configured" can be configured
by a local administrator. Therefore, you might not want to depend on the default settings. Instead,
you should explicitly set those values that you want configured a certain way. The procedures in
this section illustrate how to configure other common settings that you typically do not want a
local administrator to be able to change.
To see that a local administrator can modify settings that are not enforced by a GPO
1. On CLIENT1, in the Windows Firewall with Advanced Security snap-in, in the
navigation pane, right-click the top node Windows Firewall with Advanced Security,
and then click Properties.
2. On the Domain Profile tab, change Outbound connections to Block, and then click
OK.
3. In Administrator: Command Prompt, type ping dc1, and then press ENTER.
Notice that the command fails, because all outgoing network traffic is blocked by
Windows Firewall with Advanced Security.
4. In the Windows Firewall with Advanced Security snap-in, right-click the top Windows
Firewall with Advanced Security node, and then click Properties.
5. Change Outbound connections back to Allow (default) to restore regular operation,
31
and then click OK.
In the next procedure, you configure the settings in Group Policy so that a local administrator
cannot change or disable them.
To configure other common firewall settings in Group Policy

1. On MBRSVR1, in the Group Policy Management Editor, right-click Windows Firewall
with Advanced Security -
Properties.
2. On the Domain Profile tab, in the State section, set Inbound connections to Block
(default), and set Outbound connections to Allow (default). This is, of course, the
same behavior to which the client is already set, but setting it in the GPO prevents local
administrators from changing the settings.
3. Click OK to save your settings and return to the Group Policy Management Editor.
In the next procedure, you refresh Group Policy on the client, and confirm that locally defined
rules and settings cannot block network communications.
To test your new restrictions on local administrators

1. On CLIENT1, in Administrator: Command Prompt, type gpupdate /force, and then
press ENTER. Wait until the command finishes.
2. In the navigation pane of the Windows Firewall with Advanced Security snap-in, right-
click the top Windows Firewall with Advanced Security node, and then click
Properties.
3. On the Domain Profile tab, notice that the restrictions now prevent a local user, even an
administrator, from modifying the settings.
Note
The Inbound connection setting enables you to Block all connections. This is
a security feature to support a quick mitigation of a malware threat, and cannot
be blocked by Group Policy.
4. In the Settings section, click Customize, and then notice that the settings that you
configured in Group Policy cannot be locally changed.
5. Click Cancel two times to return to the Windows Firewall with Advanced Security
snap-in.
6. Close the Windows Firewall with Advanced Security snap-in.
32
Step 7: Creating WMI and Group Filters
When the network includes client computers that run a variety of Windows operating systems,
two computers in the same OU might require different settings to achieve the same configuration.
For example, a computer that is running Windows XP might require a different setting than a
computer that is running Windows Vista. Two GPOs would be required in that case, one to apply
to computers that are running Windows XP, and one to apply to computers that are running
Windows Vista. There are two frequently used techniques used to ensure that GPOs only apply
to the correct computers:
• Add a Windows Management Instrumentation (WMI) filter to the GPO. A WMI filter enables
you to specify criteria that must be matched before the linked GPO is applied to a computer.
By letting you filter the computers to which the settings apply, this reduces the need to further
subdivide your OUs in Active Directory.
• Grant or deny the Apply Policy security permission in the access control list (ACL) for the
GPO. If you put your computers in security groups, you can then deny the Apply Policy
permission to the groups that should not use the GPO.
Important
Windows XP and Windows Server 2003 use different tools and produce different firewall
and IPsec settings than the Windows Firewall with Advanced Security tool included with
Windows Vista and Windows Server 2008. Mixing the settings together on the same
computer can cause unexpected connectivity problems that are very difficult to
troubleshoot. We recommend that you use the Windows Firewall with Advanced Security
snap-in for settings to create the GPOs for computers that are running Windows Vista or
Windows Server 2008, and use the tools provided in Windows XP or
Windows Server 2003 to create the GPOs intended for those operating systems.
In this step, you apply and test a WMI filter that restricts a GPO to applying only to computers that
are running Windows Vista.
To create a WMI filter that does not apply to the client

1. On MBRSVR1, switch to Group Policy Management.
2. In the navigation pane, right-click WMI Filters, and then click New.
3. In the Name box, type Apply only to Windows XP.
4. Click Add.
5. In the Query box type:
select * from Win32_OperatingSystem where Version like "5.1%"
6. Click OK, and then click Save.
7. Under Group Policy Objects, click Firewall Settings for Vista Clients.
8. Click the Scope tab, and under WMI Filtering, select your filter Apply Only to
33
Windows XP from the list.
9. In the confirmation dialog box, click Yes.
The policy now only applies to computers that are running a Windows operating system
reporting a version number that starts with the characters"5.1". Because Windows Vista
is version 6.0, the policy does not apply to that operating system.
10. Leave the Group Policy Management MMC snap-in running.
In the next procedure, you deploy the GPO to see that it no longer applies to the client computer
that is running Windows Vista.
To deploy and test your 'bad' WMI filter

1. On CLIENT1, in Administrator: Command Prompt, run gpupdate /force. Wait for the
command to finish.
2. If it is still open close and then restart the Windows Firewall with Advanced Security
snap-in.
3. In the navigation pane, right-click Windows Firewall with Advanced Security on Local
4. Note that all the controls in the user interface are now enabled, and no longer locked by
policy because the GPO no longer applies to this computer.
5. Click OK.
6. Close the Windows Firewall with Advanced Security snap-in. Leave Administrator:
Command Prompt running.
In the next procedure, you fix the WMI filter so that it correctly applies the GPO to Windows Vista.
To fix the GPO

1. On MBRSVR1, in Group Policy Management, in the navigation pane, expand WMI
Filters.
2. Right-click Apply Only to Windows XP, and then click Rename.
3. Change the XP to Vista, and then press ENTER.
4. Right-click Apply Only to Windows Vista, and then click Edit.
5. Select your query, and then click Edit to display the WMI Query dialog box.
6. Change the version number so that the query reads:
select * from Win32_OperatingSystem where Version like "6.0%"
7. Click OK, and then Save.
The setting now only applies to computers that are running a Windows operating system
reporting a version number that starts with 6.0, such as Windows Vista or Windows
Server 2008.
34
8. Leave the Group Policy Management snap-in running.
In the next procedure, you deploy the policy to see that it now does apply to the client computer
that is running Windows Vista.
To deploy and test your fixed WMI filter

1. On CLIENT1, in Administrator: Command Prompt, run gpupdate /force. Wait for the
command to finish.
Notice that many of the controls in the user interface are now disabled because the GPO
is re-applied to this computer.
4. Click OK.
5. Leave Administrator: Command Prompt and the Windows Firewall with Advanced
Security snap-in open.
In the next several procedures, you test group filtering with security ACLs.
To create the computer group

1. On DC1, if the Active Directory Users and Computers snap-in is not open, open it.
Click click Start, click Administrative Tools, and then click Active Directory Users and
Computers.
2. In the navigation pane, right-click Computers, click New, and then click Group.
3. In Group name, type Windows Vista Computers, and then click OK.
In the next procedure, you set the permissions on the GPO to grant the apply policy permission
only to members of your new computer group.
To set ACL permissions on the GPO

1. On MBRSVR1, in Group Policy Management, expand Group Policy Objects, and then
click Firewall Settings for Vista Clients.
2. On the Scope tab, in the Security Filtering section, click Authenticated Users, and
then click Remove.
3. Click Add, type Windows Vista Computers, and then click OK.
Your computer is not yet a member of this new group. Verify that the GPO does not apply.
To verify that the GPO no longer applies to CLIENT1

1. On CLIENT1, open an Administrator: Command Prompt, and then run gpupdate
35
/force. Wait for the command to finish.
2. Type gpresult /r /scope computer. Examine the Applied Group Policy Objects
section and verify that the only GPO listed is Default Domain Policy.
3. Look down several more lines under The following GPOs were not applied because
they were filtered out for an entry for Firewall Settings for Vista Clients.
4. If it is still open, close the Windows Firewall with Advanced Security snap-in, and then
restart it.
6. Confirm that all the controls are enabled again because the GPO no longer applies.
7. Click Cancel to close the Properties page.
In the next procedure, you add the computer to the new group.
To add CLIENT1 to the group

1. On DC1, in the Active Directory Users and Computers snap-in, select the Computers
container, and then double-click Windows Vista Computers in the details pane.
2. Select the Members tab, and then click Add.
3. Click Object Types.
4. Clear all check boxes except Computers, and then click OK.
5. In the text box, type CLIENT1, and then click OK two times to save your changes.
Finally, you can apply the GPO to your computer to see the results.
To apply the GPO applied to the computer

1. On CLIENT1, restart the computer. The changes to the group membership must be
refreshed in the local computer's security tokens. This occurs when the computer starts.
2. Log on as contoso/admin1.
3. Open an Administrator: Command Prompt, and run gpresult /r /scope computer.
4. Examine the output to confirm that the GPO is applied to your computer again.
7. Confirm that some of the controls are disabled again because they are now controlled by
Group Policy.
8. Click Cancel to close the Properties page.
For more information about how to use WMI filters and Group Policy, see:
36
• HOWTO: Leverage Group Policies with WMI Filters at
• Windows Server Group Policy at http://go.microsoft.com/fwlink/?linkid=93542
Step 8: Enabling Firewall Logging

When you create or modify firewall rules, you can sometimes end up with a rule set that allows
traffic that you do not want, or that blocks traffic that you require. To help troubleshoot these
types of problems, Windows Firewall with Advanced Security can create a log file that contains
entries for network connections that are permitted and network connections that are blocked.
In this step, you configure your server GPO to create a log file and to log both allowed packets
and dropped packets. In the next section, after you create and test some firewall rules, you
examine this log file to see the kinds of entries created there.
To configure a firewall log file in your server GPO

1. On MBRSVR1, in Group Policy Management, in the navigation pane, right-click
Firewall Settings for WS2008 Servers, and then click Edit.
2. In the Group Policy Management Editor, right-click the top node in the navigation pane,
and then click Properties.
3. Select the Disable User Configuration settings check box.
4. In the confirmation dialog box, click Yes, and then click OK.
5. In the navigation pane, expand Computer Configuration, expand Windows Settings,
expand Security Settings, and then expand Windows Firewall with Advanced
Security.
6. Right-click Windows Firewall with Advanced Security -
Properties.
7. On the Domain Profile tab, in the Logging section, click Customize.
8. Clear both Not configured check boxes. You can use the default values for path and
maximum size.
9. Change Log dropped packets to Yes.
10. Change Log successful connections to Yes.
11. Click OK two times to save your GPO.
12. Close the Group Policy Management Editor.
After this GPO is applied to MBRSVR1, the firewall starts logging both dropped packets and
successful connections. You view the log in a later section.
37
Creating Rules that Allow Required Inbound
Network Traffic
By default, Windows Firewall with Advanced Security blocks all unsolicited inbound network
traffic. To enable programs that depend on such traffic to run correctly, you must create rules with
specified criteria.
Steps for creating rules that allow required inbound network

traffic
In this section of the guide, you create firewall rules that allow specific types of unsolicited
inbound network traffic through the firewall.
Step 1: Configuring Predefined Rules by Using Group Policy
Step 2: Allowing Unsolicited Inbound Network Traffic for a Specific Program
Step 3: Allowing Inbound Traffic to a Specific TCP or UDP Port
Step 4: Allowing Inbound Network Traffic that Uses Dynamic RPC
Step 5: Viewing the Firewall Log
Step 1: Configuring Predefined Rules by Using Group Policy

In many scenarios, you might want to configure rules that allow generally required network
activity. Many common network traffic types are already specified in Windows Firewall with
Advanced Security by predefined sets of rules. This makes it easy to select them for configuration
and deployment.
In this step, you use the Group Policy Management MMC snap-in to configure a group of firewall
rules. You set the rules that are part of the group Core Networking to be always enabled.
To configure a group of firewall rules

1. On MBRSVR1, in the Group Policy Management snap-in, right-click Firewall Settings
for Vista Clients, and then click Edit.
2. In the navigation pane of the Group Policy Management Editor, expand Computer
Configuration, expand Windows Settings, expand Security Settings, expand
Windows Firewall with Advanced Security, and then expand Windows Firewall with
Advanced Security - LDAP://{GUID},cn=policies,cn=system,DC=contoso,DC=com.
3. Click Inbound Rules.
There are no inbound firewall rules in the GPO by default.
4. Right-click Inbound Rules, and then click New rule.
5. On the Rule Type page of the wizard, click Predefined, select Core Networking from
38
the list, and then click Next.
6. On the Predefined Rules page, examine the list of rules, leave them all selected, and
then click Next.
Note
In a production environment, carefully consider which profiles you apply the rules
to. You may want to consider rules for other profiles to control how the firewall
works on computers that are away from the network, such as portable computers
which are taken home. You might want to consider applying your rules to all the
profiles to ensure that your organization's computers continue to be protected
when they are away from the organization's network. Some rule modifications
may be required to allow expected program behavior on a home or public
network that is different from the organization's network.
7. On the Action page, because we want to create an exception for traffic that would by
default be blocked, select Allow the connection, and then click Finish.
The list of enabled rules now appears in the details pane for Inbound Rules.
With the list of rules now in the GPO, deploy the GPO to the client computer.
39
To test the rules on the client computer
1. On CLIENT1, in Administrator: Command Prompt, run gpupdate /force. Wait until the
command finishes.
2. In the navigation pane of the Windows Firewall with Advanced Security snap-in,
expand Monitoring, and then click Firewall.
Note the list of rules that is now active on the local computer.
3. Click View, and then click Add/Remove columns.
4. If the Rule Source column is not displayed, click Rule Source in the Available columns
list, and then click Add.
5. Click Move Up to position Rule Source directly after Name, and then click OK.
Note
Adding the Rule Source column is useful in troubleshooting scenarios, but it can
make the listing of the rules slower. We recommend that you remove the column
from the view when you do not need it.
6. Note that all the rules identify the GPO Firewall Settings for Vista Clients as the source
of the rule. Even if you disable the locally defined Core Networking rules under Inbound
Rules, these rules from the GPO still apply to the computer.
7. Close the Group Policy Management Editor for the client GPO.
Step 2: Allowing Unsolicited Inbound Network Traffic for a

Specific Program
When you use a program that must be able to receive unsolicited inbound network traffic, you
must create a rule to permit that traffic to pass through the firewall.
By default on Windows Vista, when you start such a program and it registers with Windows to
listen on a specific TCP or UDP port number, Windows blocks the request and displays a dialog
box asking for your instructions. If you choose to allow the program, then Windows automatically
creates a firewall rule to allow all network traffic for that program. You can also create a similar
rule manually. If you create such a rule and distribute it by using Group Policy, then users do not
have to see the dialog box and decide what to do.
By default on computers running Windows Server 2008, the notification dialog box does not
appear, and the program is silently blocked. So on computers running Windows Server 2008 you
must create rules for each program that requires unsolicited inbound network traffic. Another
advantage to creating the rule manually is that you can restrict the rule to only the specific traffic
required by the program.
40
In this section, as a first example, you create a firewall rule that allows inbound traffic for the
Telnet service through the firewall, and then you deploy that rule to MBRSVR1 by using Group
Policy.
To create a firewall rule that allows inbound traffic for a program

1. On MBRSVR1, in the Group Policy Management window, right-click Firewall Settings
for WS2008 Servers, and then click Edit.
expand Security Settings, expand Windows Firewall with Advanced Security, and
then expand Windows Firewall with Advanced Security -
LDAP://cn={GUID},cn=policies,cn=system,DC=contoso,dc=com.
3. Right-click Inbound Rules, and then click New rule.
4. On the Rule Type page, click Custom, and then click Next.
Note
We recommend that you create rules that are as specific as possible. That
means you may want to specify both the program, to ensure the rule only allows
traffic when that program is running, and the port, to ensure that the program can
only receive on the desired port number. To see all the options in the wizard, use
the Custom rule type.
5. In the text box for This program path, type %systemroot%\system32\tlntsvr.exe.
6. Because programs can host multiple services, we recommend that you also limit the rule
to the specific service you want. Next to Services, click Customize.
7. Click Apply to this service, select Telnet, click OK, and then click Next.
Note
The list of services includes only the services currently installed on the computer
on which you are editing the GPO. If the service you want to specify is not
installed on this computer, you can use the option Apply to service with this
service short name, and then type the service name in the text box. To discover
the service short name, use the Services MMC snap-in on a computer on which
the service is installed.
8. On the Protocols and Ports page, click Next. You restrict the rule to a specific port in
the next section.
9. On the Scope page, click Next.
10. On the Action page, click Allow the Connection, and then click Next.
11. On the Profile page, clear the Private and Public check boxes. Confirm that Domain is
selected, and then click Next.
12. On the Name page, type Allow Inbound Telnet, and then click Finish.
41
Before you deploy the GPO, configure some other settings to ensure that local rules cannot
interfere with your domain provided rule.
To finish configuring the firewall rule for the member server

1. In the navigation pane of the Group Policy Management Editor, right-click Windows
Firewall with Advanced Security -
LDAP://cn={GUID},cn=policies,cn=system,DC=contoso,dc=com, and then click
Properties.
2. Set Firewall state to On (recommended).
3. Set Inbound connections to Block (default).
4. Set Outbound connections to Allow (default).
5. In the Settings section, click Customize.
6. Set Display a notification to No.
7. Set Apply local firewall rules to No.
8. Set Apply local connection security rules to No.
9. Click OK two times to save your GPO.
In this procedure, you deploy your GPO to your member server.
To deploy the GPO to the member server

1. Switch to the Group Policy Management snap-in, right-click MyMemberServers, and
then click Link an existing GPO.
2. In the Select GPO dialog box, click Firewall Settings for WS2008 Servers, and then
click OK.
The GPO is now assigned.
3. Open Administrator: Command Prompt, and then run gpupdate /force. Wait for the
command to finish.
5. In the navigation pane, expand Monitoring, and then click Firewall. Note that the only
currently active rule is the Allow Inbound Telnet rule that you created in the GPO.
In this procedure, you test the deployed firewall rule.
To test the Telnet firewall rule

1. On CLIENT1, at Administrator: Command Prompt, type telnet mbrsvr1, and then
press ENTER.
After several seconds the following screen appears and indicates that your Telnet firewall
rule is working.
42
2. Close the Telnet session by typing exit, and then pressing ENTER.
In this procedure, you confirm that it is not the local Telnet rule that was created when the Telnet
Server service was installed on MBRSVR1. You disable that rule and confirm that Telnet still
works because your GPO applied rule is active.
To confirm that it is your GPO rule that allows Telnet to work

1. On MBRSVR1, in the Windows Firewall with Advanced Security snap-in, in the
navigation pane, click Inbound Rules. Note your GPO-based Telnet firewall rule is listed
at the top.
2. Scroll down to the rule named Telnet Server, right-click it, and then click Disable rule.
3. On CLIENT1, at the command prompt, run telnet mbrsvr1 again, and then confirm that it
is still working.
Finally, you demonstrate that the Telnet service can listen for network traffic on any port the way
the rule is currently configured.
To show that the firewall rule allows Telnet network traffic on a specified port
1. On MBRSVR1, at an Administrator: Command Prompt, type tlntadmn config
port=25, and then press ENTER. This configures your Telnet server to listen on port 25
instead of the default port 23.
2. On CLIENT1, at a command prompt, type telnet mbrsvr1 25. This instructs the client to
use port 25 for its connection instead of the default port 23.
The connection succeeds.
In the next section, you configure the rule to allow traffic only on a port number you specify.
Step 3: Allowing Inbound Traffic to a Specific TCP or UDP Port

In the previous step, you created a rule that allows unsolicited inbound network traffic only to the
Telnet Server service. However, it is considered a best practice to also limit the traffic to the TCP
and/or UDP ports that the service really needs. In the case of Telnet, only TCP port 23 is
required.
43
In this procedure, you refine the Telnet exception rule to limit the allowed inbound network traffic
only to TCP port 23.
To configure the rule to limit traffic to a specific port

1. On MBRSVR1, in Group Policy Management Editor for your server GPO, click
Inbound Rules.
2. In the details pane, right-click Allow Inbound Telnet, and then click Properties.
3. Click the Protocols and Ports tab.
4. In Protocol type, click TCP. Note the Protocol number automatically changes to 6.
5. In the Local port list, click Specific Ports.
6. In the text box directly under Local Port, type 23.
7. Click OK to save your changes.
In this procedure, you test the modified rule.
To test your modified rule

1. On MBRSVR1, at Administrator: Command Prompt, run gpupdate /force. Wait until
the command finishes.
The Telnet service on MBRSVR1 is still configured to listen on port 25.
2. On CLIENT1, at a command prompt, run telnet mbrsvr1 25.
The command times out and fails because the firewall on MBRSVR1 now blocks all
inbound traffic to the Telnet service except port 23.
3. On MBRSVR1, at the Administrator: Command Prompt, run tlntadmn config port=23
to restore the service to the default port number.
4. On CLIENT1, at the command prompt, run telnet mbrsvr1.
The command succeeds because the firewall allows inbound network traffic to port 23 to
the Telnet service.
Step 4: Allowing Inbound Network Traffic that Uses Dynamic

RPC
Many programs use the RPC protocol to request communications with a host service on a
dynamically assigned port number. To do this, the remote client connects to the server on TCP
port 135 (the "well-known" port number for RPC), and identifies the service to which it wants to
connect. The RPC Endpoint Mapper service which is listening on that port, replies with the port
number that the client should use to connect to the desired service.
44
In earlier versions of Windows, dynamically assigned ports have been a challenge for firewall
administrators. Either they had to create rules to open large ranges of port numbers in the
dynamically assigned range (all ports greater than 1024), or they had to limit the program to using
a much smaller number of ports than it was designed to use. Creating rules to open many ports
that are not currently being actively used increases the surface area of a computer's vulnerability
to attack. Limiting programs to using fewer ports might compromise the programs' performance.
Neither situation is a good solution.
Note
To determine whether your program must use ports that are dynamically assigned by
RPC, see the documentation provided by your program's vendor. Alternatively, you can
examine the traffic going to and from your program by using a network protocol analyzer
such as Microsoft Network Monitor. You can download Network Monitor at
http://go.microsoft.com/fwlink/?LinkID=94770.
In Windows Vista and Windows Server 2008, this problem is solved by the introduction of rules
that can directly support RPC port requirements for programs. To configure this support for a
program you must create the following rules:
• An inbound rule that allows inbound network traffic for RPC Endpoint Mapper service. This
rule allows the computer to receive traffic sent to the port 135. The rule must also be
configured to use the allow action, and the program path of the RPC Endpoint Mapper
service.
• An inbound rule that specifies Dynamic RPC for the port number. When an incoming request
from a remote computer is received by the RPC Endpoint Mapper service on port 135 (see
the previous rule), the service assigns a dynamic port number to the request and replies to
the remote computer by using that number. The IP address of the remote computer and the
dynamic port number are stored in an internal table. When the remote computer then sends a
packet to the new port number, this rule allows Windows to match the port number and IP
address to the entries stored in the table. If a match is found, it allows the inbound traffic.
The advantage is that any port in the RPC ephemeral range can be used without having to
explicitly define a rule to open that port. The port is only usable by a program that was assigned
the use of the port by the endpoint mapper. No unused ports are left open, reducing the
vulnerability of the server.
In this section, you create rules for the Remote Event Log service that use Dynamic RPC.
Although Windows Vista and Windows Server 2008 have predefined rules that provide this
capability, you create the rules manually to see the steps involved.
To begin, confirm that the Remote Event Log service is not currently working remotely from the
client because the firewall on MBRSVR1 is blocking the traffic.
To confirm that the Remote Event Log service is not working remotely
1. On CLIENT1, click Start, type event viewer in the Start Search box, and then press
45
ENTER.
2. Click Action, and then click Connect to another computer.
3. In the Another computer text box, type MBRSVR1, and then click OK.
4. After several seconds, the connection attempt fails as shown in the following figure,
because Windows Firewall with Advanced Security on MBRSVR1 is blocking the required
network traffic. Click OK.
To allow this service to work, begin by creating a rule that supports inbound traffic to the RPC
Endpoint Mapper service.
To create a rule that allows inbound network traffic to the RPC Endpoint Mapper service
1. On MBRSVR1, in Group Policy Management Editor for your server GPO, in the
navigation pane, right-click Inbound Rules, and then click New rule.
3. In the This program path text box, type %systemroot%\system32\svchost.exe.
4. Next to Services, click Customize.
5. Click Apply to this service, select Remote Procedure Call (RPC) with a short name of
RpcSs, click OK, and then click Next.
6. On the warning about conflicting with Windows service-hardening rules, click Yes.
7. On the Protocol and Ports page, for Protocol type, select TCP.
8. For Local Port, select RPC Endpoint Mapper, and then click Next.
10. On the Action page, click Next.
11. On the Profile page, clear the Private and Public check boxes, and then click Next.
12. On the Name page, type Allow RPC Endpoint Mapper, and then click Finish.
Next, create a rule that allows the incoming traffic from the remote Event Log client. Since the
incoming port number is assigned dynamically by the RPC Endpoint Mapper service, you specify
Dynamic RPC instead of a specific port number.
46
Note
The Event Log we are using as an example service is hosted in
%systemroot%\system32\svchost.exe. Be sure to use the path of the executable file
hosting the service that you want to create rules for when in a production environment.
To create a rule that allows inbound network traffic to your RPC-enabled service
1. On MBRSVR1, in Group Policy Management Editor, in the navigation pane, right-click
Inbound Rules, and then click New rule.
3. In the This program path text box, type %systemroot%\system32\svchost.exe. The
Remote Event Log service is another service hosted by that file.
4. Next to Services, click Customize.
5. Click Apply to this service, select Windows Event Log with a short name of Eventlog,
click OK, and then click Next.
6. On the warning about conflicting with Windows service-hardening rules, click Yes.
7. On the Protocol and Ports page, for Protocol type, select TCP.
8. For Local Port, select Dynamic RPC, and then click Next.
10. On the Action page, click Next.
12. On the Name page, type Allow Remote Event Log Service, and then click Finish.
Now you can apply the GPO to MBRSVR1.
13. At an Administrator: Command Prompt, run gpupdate /force. Wait for the command
to finish.
14. If it is not already open, open the Windows Firewall with Advanced Security snap-in.
15. Expand Monitoring, click Firewall, and then confirm that your new rules are now active
on the computer.
Now you can try to connect to the Remote Event Log service from the client again.
47
To confirm that the Remote Event Log service is working
1. On CLIENT1, in Event Viewer, click Action, and then click Connect to another
computer.
2. In the Another computer text box, type MBRSVR1, and then click OK.
3. The attempt succeeds, and the top node in the navigation page shows that the viewer is
connected to MBRSVR1.contoso.com.
4. Close Event Viewer.
Step 5: Viewing the Firewall Log

You have created several connections to your server after turning on firewall logging, and you
also had several connections blocked by the firewall rules you put in place. In this step you
examine the log that accumulated to this point and then you turn the logging back off.
To examine the firewall log

1. On MBRSVR1, if it is not already open, open the Windows Firewall with Advanced
Security snap-in.
2. In the navigation pane, click Monitoring. In the Logging Settings section, click the file
path next to File name. The log opens in Notepad.
3. In Notepad, examine the entries. There are many more entries than those related directly
to your activity for this guide. There are Domain Name System (DNS) queries, network
basic input/output (NetBIOS) protocol connections, and so on.
4. Search for lines that resemble the following examples. You can press CTRL-F to open a
search dialog box, and enter a [space] 23 [space]. Be sure to include the spaces, so
that you do not find the number 23 embedded in other numbers.
The values in italic in the samples that follow might vary from those in your log. The final
column is not shown here, but is often of interest, because it shows whether the packet
48
was an inbound (RECEIVE) or outbound (SEND) packet.
• The following entries represent the allowed Telnet connections on ports 23 and 25:
2007-07-18 10:10:48 ALLOW TCP 192.168.0.101 192.168.0.100 52174 23
2007-07-18 10:15:54 ALLOW TCP 192.168.0.101 192.168.0.100 52175 25
• The following entry represents a blocked Telnet connection attempt on port 25:
2007-07-18 10:28:28DROP TCP 192.168.0.101 192.168.0.100 52180 25
• The following entries shows the allowed Remote Event Log connection:
2007-07-18 10:49:59 ALLOW TCP 192.168.0.101 192.168.0.100 52191 135
2007-07-18 10:50:00 ALLOW TCP 192.168.0.101 192.168.0.100 52192 49153
5. Close Notepad.
Note
In production troubleshooting scenarios, you can import your log file into Microsoft Excel
to more easily search, sort, and filter the entries. Use the space character as the
separator when you import the log file.
You should only turn on logging when you need it, such as when you are troubleshooting.
Because we are finished, turn the logging off.
To turn Firewall logging off

1. Switch to the Group Policy Management Editor window that is configuring your Server
GPO.
2. In the navigation pane, right-click Windows Firewall with Advanced Security -
Properties.
3. On the Domain Profile tab, under Logging, click Customize.
4. Change Log dropped packets to No (default).
5. Change Log successful connections to No (default).
6. Click OK two times to save your changes.
7. At the Administrator: Command Prompt, run gpupdate /force. Wait until the command
is finished..
49
Creating Rules that Block Unwanted Outbound
Network Traffic
By default, Windows Firewall with Advanced Security allows all outbound network traffic. If your
organization prohibits specific network programs on organization computers, you can help
enforce that prohibition by blocking the network traffic that the programs require to operate
correctly.
By default, inbound network traffic to a computer that does not match a rule is blocked, but
nothing prevents outbound traffic from leaving a computer. To block the network traffic for
prohibited programs, you must create an outbound rule that blocks traffic with specific criteria
from passing through Windows Firewall with Advanced Security.
Steps for creating rules that block prohibited outbound network

traffic
In this section of the guide, you create firewall rules that block specific types of outbound network
traffic at Windows Firewall with Advanced Security. You use Telnet as the sample program to be
blocked.
Step 1: Blocking Network Traffic for a Program by Using an Outbound Rule
Step 2: Deploying and Testing Your Outbound Rule
Step 1: Blocking Network Traffic for a Program by Using an

Outbound Rule
In this step, you create a rule for CLIENT1 to block all outbound traffic on TCP port 23. You can
create a rule for a specific program path and name, but because it is easy to rename an
executable and bypass that restriction, it is typically more effective to block the ports for the
network traffic that the program requires to work.
Caution
Blocking the ports needed by a program prevents any program that uses those ports from
communicating on the network. Make sure that no program that the users require use the
same ports.
To create an outbound block rule

1. On MBRSVR1, if Group Policy Management Editor is still open, close it.
2. In Group Policy Management, right-click Firewall Settings for Vista Clients, and then
click Edit.
3. Expand Computer Configuration, expand Windows Settings, expand Security
Settings, expand Windows Firewall with Advanced Security, and then expand
50
Windows Firewall with Advanced Security -
LDAP://{GUID},cn=policies,cn=system,DC=contoso,DC=com.
4. Click Outbound Rules, and then notice that no rules are currently defined.
5. Right-click Outbound Rules, and then click New Rule.
Note
If you select the Port rule type, you can only specify the local port number to
block. We want to block remote port 23. Therefore, specify the Custom rule type.
7. On the Program page, click All programs, and then click Next.
8. On the Protocol and Ports page, change the Protocol type to TCP.
9. In the Remote ports list, click Specific Ports, type 23 in the text box, and then click
Next.
Note
Be sure to specify the Remote port, not Local. This differs from the inbound
rules you set earlier, because this rule applies to the client instead of the server.
11. On the Action page, click Block the connection, and then click Next.
13. On the Name page, type Block Outbound Telnet, and then click Finish.
Step 2: Deploying and Testing Your Outbound Rule

Now that you have the rule created, deploy it to CLIENT1 and test it.
To deploy and test your outbound block rule

1. On CLIENT1, at an Administrator: Command Prompt, run gpupdate /force. Wait until
the command has finished.
2. Run telnet mbrsvr1.
3. The connection fails as shown in the following message:
Connecting to mbrsvr1…Could not open connection to the host, on port 23:
Connect failed
4. For the next section, you must use Telnet again, so disable the rule. On MBRSVR1, in
Group Policy Management Editor, right-click the rule Block Outbound Telnet, and
then click Disable Rule.
5. On CLIENT1, repeat steps 1 and 2 to confirm that Telnet is working again.
51
6. Type exit and the press ENTER to end the Telnet session.
Deploying a Basic Domain Isolation Policy

By using Windows Firewall with Advanced Security in Windows Vista and Windows Server 2008,
you can create connection security rules that specify that traffic must be secured by one or more
of the features of IPsec. In domain isolation you use authentication to require each computer
involved in a connection to positively establish the identity of the other computer.
By creating rules that require authentication by a domain member, you effectively isolate those
domain-member computers from computers that are not part of the domain.
Most networks contain computers that cannot participate in domain isolation because they cannot
use IPsec. This can be due to the network services they host, the operating systems they run, or
other reasons. If you implement domain isolation, you must create inbound exemption rules for
these computers that cannot use IPsec, if you want them to communicate with the computers that
require IPsec.
For outbound connections, most of the domain isolation scenarios use the option to request but
not require IPsec protection. This enables the computers to protect traffic when communicating
with computers than can also use IPsec, but fall back to plaintext after three seconds of trying
IPsec when communicating with computers that cannot use IPsec. However, some services have
response time-outs that are less than three seconds, which causes them to fail. In earlier versions
of Windows this meant that you had to create (sometimes a very large number of) outbound
exemption rules to support those servers or services that cannot authenticate. To address this
problem, Microsoft released the Simple Policy Update for Windows Server 2003 and
Windows XP. This update reduces the delay for attempts between IPsec-protected clients and
non-IPsec-protected clients to one-half second. For more information about the Simple Policy
Update for Windows Server 2003 and Windows XP, see Simplifying IPsec Policy with the Simple
Policy Update at http://go.microsoft.com/fwlink/?LinkID=94767.
When you use request mode in Windows Vista and Windows Server 2008, Windows sends both
connection attempts at the same time. If the remote host responds with IPsec, the non-IPsec
attempt is abandoned. If the IPsec request generates no response, the non-IPsec attempt can
continue.
This reduced delay solves the time-out failure problem for most programs. However, there might
still be times when you want to ensure that your computers do not use IPsec to try to talk to
certain hosts on the network. In those circumstances, create exemption rules for the clients and
they no longer use IPsec to communicate with computers on the exemption list.
For more information about domain isolation, see "Introduction to Server and Domain Isolation at
http://go.microsoft.com/fwlink/?LinkID=94631 and Domain Isolation with Microsoft Windows
Explained at http://go.microsoft.com/fwlink/?LinkID=94632.
52
Steps for creating connection security rules to enforce domain
isolation
In this section, you create connection security rules that specify that the computers in your
domain require authentication for inbound network traffic and request authentication for outbound
traffic.
Step 1: Creating a Connection Security Rule that Requests Authentication
Step 2: Deploying and Testing Your Connection Security Rules
Step 3: Changing the Isolation Rule to Require Authentication
Step 4: Testing Isolation with a Computer That Does Not Have the Domain Isolation Rule
Step 5: Creating Exemption Rules for Computers that are Not Domain Members
Step 1: Creating a Connection Security Rule that Requests

Authentication
In this step, you create connection security rules for the contoso.com domain that cause all
member computers to require authentication for inbound network traffic, and request it for
outbound traffic. You start by using a GPO that only requests inbound authentication, and after
you confirm that it is working you revise it to require inbound authentication.
To create a new GPO for domain isolation

1. On MBRSV1, in Group Policy Management, right-click Group Policy Objects, and
then click New.
2. In Name, type Domain Isolation, and then click OK.
3. In the navigation pane, right-click your new GPO, and then click Edit.
4. In Group Policy Management Editor, in the navigation pane, right-click the top node for
your Domain Isolation GPO, and then click Properties.
5. Select the Disable User Configuration settings check box, because this is a computer-
only GPO.
6. In the Confirm Disable dialog box, click Yes, and then click OK.
expand Security Settings, expand Windows Firewall with Advanced Security, and
then expand Windows Firewall with Advanced Security -
LDAP://cn={GUID},cn=policies,cn=system,DC=contoso,DC=com.
8. Right-click Connection Security Rules, and then click New rule.
9. On the Rule Type page, click Isolation, and then click Next.
10. On the Requirements page, confirm that Request authentication for inbound and
outbound connections selected, and then click Next.
53
Caution
In a production environment, we recommend that you set request mode first and
allow the GPO to fully propagate to the network. Confirm that all your computers
are communicating successfully by using IPsec before changing the rules to
require mode. Setting the rule to require mode first can result in computers that
cannot communicate until all the computers receive and apply the GPO. In a later
step, you modify the rule to change it to require inbound authentication.
11. On the Authentication Method page, click Computer (Kerberos V5), and then click
Next.
13. On the Name page, type Request Inbound Request Outbound, and then click Finish.
Step 2: Deploying and Testing Your Connection Security Rules

In this step, you deploy and test your domain isolation rule. You link the GPO that contains the
rule to the OUs that contain the computer accounts, and then you test connectivity and view the
IPsec security associations (SAs) that are created to support the connection.
Start by linking your GPO to the OUs that contains the computers to receive the rule.
To link your GPO to the appropriate OUs

1. On MBRSVR1, open the Group Policy Management snap-in.
2. Right-click MyClientComputers, and then click Link an Existing GPO.
3. In the Group Policy objects list, select Domain Isolation, and then click OK.
4. Right-click MyMemberServers, and then click Link an Existing GPO.
5. In the Group Policy objects list, select Domain Isolation, and then click OK.
If you browse your OUs, you see a list that resembles the following diagram:
54
Now, ensure that both computers receive and apply the new GPO.
To test the new GPO on your computers

1. On both MBRSVR1 and CLIENT1, at an Administrator: Command Prompt, run
gpupdate /force. Wait until the commands finish.
The connection succeeds. Do not end the Telnet session yet.
4. Expand Monitoring, expand Security Associations, and then click Main Mode.
5. In the Main Mode pane, double-click the security association (SA) that is displayed.
6. Examine the settings, as shown in the following figure, that the local computer (CLIENT1)
authenticated with the remote computer (MBRSVR1).
55
7. Click OK.
8. In the navigation pane, click Quick Mode, and then double-click the SA that is displayed.
9. Examine the settings, which show that any traffic between the two computers using any
protocol is protected using the Encapsulating Security Payload (ESP) integrity algorithm
Secure Hash Algorithm (SHA1). ESP integrity uses a cryptographically protected
checksum to ensure that the packets that are received have not been modified after they
are sent. Any packets that fail the integrity tests are silently dropped.
Note
SAs have a limited lifetime. Therefore, if you let the connection sit idle long
enough, the SA can expire and be removed from the list. By sending more
network traffic, the SA is renegotiated and reappears in the list.
10. Type exit at the Telnet prompt to end the Telnet session.
56
Step 3: Changing the Isolation Rule to Require Authentication
In this step, modify the rule that you created so that authentication is required instead of
requested. Clients that cannot authenticate, or that do not have a connection security rule to
authenticate the traffic, cannot communicate with computers that are domain members.
To change the policy from requesting to requiring authentication

1. On MBRSVR1, switch to the Group Policy Management Editor.
2. In the details pane, right-click Request Inbound Request Outbound, and then click
Properties.
3. In the Name text box, change the name to Require Inbound Request Outbound to
accurately reflect its new behavior.
4. Click the Authentication tab.
5. Under Requirements, change Authentication mode to Require inbound and request
outbound, and then click OK.
Note
Although using Require inbound and outbound would work for this guide, in a
production environment it is usually not practical to require outbound
authentication. Domain-member computers often must initiate communications
with computers that are not in the domain, such as remote Web sites.
Confirm that the computers can still communicate even though authentication is required.
To test the modified GPO requiring authentication

1. On both MBRSVR1 and CLIENT1, at an Administrator: Command Prompt, run
gpupdate /force.
The connection succeeds.
3. Type exit to end the Telnet session.
Step 4: Testing Isolation with a Computer That Does Not Have

the Domain Isolation Rule
To simulate a computer that is not part of the domain, remove the GPO from CLIENT1, and try to
connect again.
57
To remove the GPO from CLIENT1
2. Under MyClientComputers, right-click Domain Isolation, and then click Link Enabled
to disable the link.
In the next procedure, you refresh the GPO on CLIENT1 and try to communicate with MBRSVR1.
To test the modified GPO on CLIENT1

2. At the command prompt, run telnet mbrsvr1. The connection fails because it never
receives a reply to its request. Because MBRSVR requires authentication, and CLIENT1
cannot supply it, all incoming packets are dropped.
3. Type exit and press ENTER to end the Telnet session.
In the next procedure, you restore the GPO to the client so that the correct rule is in place for later
steps.
To reapply the GPO to CLIENT1

1. On MBRSVR1, under MyClientComputers, right-click Domain Isolation, and then click
Link Enabled.
2. If you want, you can repeat the previous procedure "To test the modified GPO on
CLIENT1" to confirm that you can connect again. This time the connection succeeds.
Step 5: Creating Exemption Rules for Computers that are Not

Domain Members
In this step, you add a rule to your domain isolation GPO to exempt all DNS servers on the
network from the domain isolation authentication requirements.
Note
If the computers on the network are all running Windows Vista, Windows Server 2008, or
if they can run the Simple Policy Update for Windows Server 2003 and Windows XP
(http://go.microsoft.com/fwlink/?LinkID=94767), then you probably do not need to add
exemption rules as illustrated here. Fewer exemption rules means less complexity for
your connection security and firewall rule GPOs.
To modify your domain isolation GPO to exempt DNS servers

1. On MBRSVR1, switch to the Group Policy Management Editor that has the Domain
58
Isolation GPO open.
2. In the navigation pane, right-click Connection Security Rules, and then click New rule.
3. On the Rule Type page, click Authentication exemption, and then click Next.
4. On the Exempt Computers page, click Add.
5. In the IP Address dialog box, click Predefined set of computers.
6. Click the list to expand it, select DNS servers, and then click OK.
7. On the Exempt Computers page, click Next.
9. On the Name page, type Exempt DNS servers from domain isolation, and then click
Finish.
The new rule appears in your GPO.
Note
You can use a network traffic analyzer such as Microsoft Network Monitor to see
the network packets before and after you apply this rule to confirm that IPsec
attempts are not made to the DNS server after the exemption rule is applied. To
download Network Monitor, see Microsoft Network Monitor at
http://go.microsoft.com/fwlink/?LinkID=94770.
Isolating a Server by Requiring Encryption and

Group Membership
Domain isolation restricts domain-member computers to communicating only with other domain-
member computers. Some servers contain sensitive data, such as personal data, medical
records, or credit card data that must be guarded even more carefully. An extra layer of security,
known as server isolation, restricts access to this sensitive data to only those users who have a
specific business need. Often such data must also be encrypted during transmission to prevent
eavesdropping.
By using Windows Firewall with Advanced Security in Windows Vista and Windows Server 2008,
you can specify that specific network connections can be accessed only by specific users, based
on their group membership. You can also specify that access is permitted only by specific
computers based on computer account membership in a group. Both types of restriction are
based on the authentication methods demonstrated in the previous section. Finally, you can also
specify that these network connections are encrypted by using one of several encryption
algorithms.
For more information about server isolation, see:
• Introduction to Server and Domain Isolation at http://go.microsoft.com/fwlink/?LinkID=94631
59
• Server Isolation with Microsoft Windows Explained at
http://go.microsoft.com/fwlink/?LinkID=94793
Steps for creating connection security rules to enforce server

isolation
In this section, you create inbound firewall rules that specify that only computers that are
members of a specific group can access MBRSVR1. You also configure the rules to require
encryption for all connections to the specified server.
Step 1: Creating the Security Group
Step 2: Modifying a Firewall Rule to Require Group Membership and Encryption
Step 3: Creating a Firewall Rule on the Client to Support Encryption
Step 4: Testing the Rule When CLIENT1 Is Not a Member of the Group
Step 5: Adding CLIENT1 to the Group and Testing Again
Step 1: Creating the Security Group

In this step, you create a security group in Active Directory. This group will be referenced by your
firewall rule in a later step to control which computers can access the server.
To create a security group

1. On DC1, click Start, and then click Server Manager.
2. In the navigation pane, expand Roles, expand Active Directory Domain Services,
expand Active Directory Users and Computers, expand contoso.com, right-click
Computers, click New, and then click Group.
3. In the New Object - Group dialog box, type Access to MBRSVR1, and then click OK.
4. Leave Server Manager running with the Computers container shown in the details
pane.
Do not add any computers to the group yet.
Step 2: Modifying a Firewall Rule to Require Group Membership

and Encryption
In this step, you modify your Telnet firewall rule to allow Telnet traffic only from computers that
are members of the security group you created in the last step.
To modify the Telnet firewall rule on MBRSVR1

2. In the navigation pane, under Group Policy Objects, right-click Firewall Settings for
60
WS2008 Servers, and then click Edit.
3. In the Group Policy Management Editor, expand Windows Settings, expand Security
Settings, expand Windows Firewall with Advanced Security, expand Windows
Inbound Rules.
4. In the details pane, right-click Allow Inbound Telnet, and then click Properties.
5. Change the name by typing Allow Encrypted Inbound Telnet to Group Members
Only.
6. Click Allow only secure connections, and then click Require encryption.
7. Click the Users and Computers tab.
8. Under Authorized computers, click Only allow connections from these computers,
and then click Add.
9. In the Select Computers or Groups dialog box, type Access to MBRSVR1, click
Check Names to ensure that it resolves, and then click OK.
Important
Even though this guide only demonstrates how to use a computer group,
remember that you can also specify user group membership as a requirement,
as long as the authentication method that is used includes user authentication as
well as computer authentication. This enables you to specify that only users who
are members of group X can access the protected server, and only when they
are using a computer that is a member of group Y. An authorized user that uses
a non-authorized computer cannot access the protected server, nor can an
authorized computer be used by a non-authorized user to access the protected
server.
10. Click OK to close the Allow Inbound Telnet Properties page.
11. Close the Group Policy Management Editor.
Step 3: Creating a Firewall Rule on the Client to Support

Encryption
In this step, you create a new firewall rule that applies to the client computer so that it can
successfully encrypt the connection as required by the server.
To modify the Telnet firewall rule for the client

1. On MBRSVR1, in Group Policy Management, under Group Policy Objects, right-click
61
2. In the Group Policy Management Editor, expand Windows Settings, expand Security
Settings, expand Windows Firewall with Advanced Security, expand Windows
LDAP://cn={GUID},cn=policies,cn=system,DC=contoso,DC=com, right-click
Outbound Rules, and then click New Rule.
4. On the Program page, click All Programs, and then click Next.
Note
By restricting the rule to the Telnet port number (in the next step), instead of the
program name, any correctly configured Telnet client can be used. If you specify
a program by path and file name then only that specific program works, and other
Telnet client programs fail. This configuration is recommended only for outbound
rules. For inbound rules, we recommend that you use both a port restriction and
a program restriction. That way the port is only open when the program is
running. If you do not specify a program then the port remains open all the time.
5. On the Protocol and Ports page, change the Protocol type to TCP.
6. Change the Remote port list to Specific Ports, type 23 in the text box, and then click
Next.
7. On the Scope page, under Which remote IP addresses does this rule match, select
the These IP addresses check box. Make sure to select the remote option.
8. To the right of the Remote address section, click Add.
9. In the IP Address dialog box, type 192.168.0.100 (the IP address of MBRSVR1) in the
top text box, click OK, and then click Next.
10. On the Action page, click Allow the connection if it is secure, click Require the
connections to be encrypted, and then click Next.
11. On the Computers page, click Next.
13. Name the rule Allow only encrypted Telnet to MBRSVR1, and then click Finish.
14. At an Administrator: Command Prompt, run gpupdate /force. Wait until the command
finishes.
62
Step 4: Testing the Rule When CLIENT1 Is Not a Member of the
Group
CLIENT1 has a firewall rule and a connection security rule that meet all the requirements to
communicate with MBRSVR1, but CLIENT1 has not yet been added to the computer group that is
referenced in the inbound Telnet firewall rule for MBRSVR1. In this step, you try to connect to
both the Remote Event Viewer service and the Telnet service on MBRSVR1.
To try to connect to the Remote Event Viewer service on MBRSVR1

2. Click Start, type event viewer in the Start Search box, and then press ENTER.
3. In the navigation pane of Event Viewer, right-click the top node Event Viewer (Local),
and then click Connect to another computer.
4. In the Select Computer dialog box, type MBRSVR1, and then click OK.
The attempt is successful, because the rules you created do not require group
membership or encryption for the Event Viewer.
Now, to see the effect of your new rules, try to connect to MBRSVR1 using Telnet.
To try to connect to MBRSVR1 by using Telnet

• On CLIENT1, at an Administrator: Command Prompt, run telnet mbrsvr1.
The command fails because the computer is not yet a member of the Access to
MBRSVR1 group, and only members of that group are permitted to send port 23 traffic
through Windows Firewall with Advanced Security to that server.
Step 5: Adding CLIENT1 to the Group and Testing Again

In this step, you add CLIENT1 to the security group Access to MBRSVR1, and then verify that it
enables the client to access the Telnet service again.
To add the computer to the group

1. On DC1, in the Computers container, double-click the group Access to MBRSVR1, and
then click the Members tab.
2. Click Add.
3. In the Select Users, Contacts, Computers, or Groups dialog box, click Object Types.
4. Click Computers, and then click OK.
5. In the text box, type client1, and then click OK.
63
6. Click OK to close the group Properties page.
To test Telnet access from CLIENT1 to MBRSVR1

1. Because its group membership must be refreshed, restart CLIENT1.
2. After the computer restarts, log on as contoso\admin1.
3. Open an Administrator: Command Prompt, and then run telnet mbrsvr1.
The command works because all requirements of the rules are now satisfied. Only
computers that are both a member of the domain and that authenticate as a member of
the specified group can access the Telnet service on MBRSVR1.
5. Expand Monitoring, expand Security Associations, and then click Quick Mode.
6. Double-click the SA to display its properties. There is now a protocol listed next to ESP
confidentiality. That is the encryption algorithm being used by this connection.
7. Click OK, and then close Windows Firewall with Advanced Security.
8. In the Telnet window, type exit, and then press ENTER to end the Telnet session.
Creating Rules that Allow Specific Computers or

Users to Bypass Firewall Block Rules
In a typical network, you want all network traffic blocked except for traffic that is truly required.
By default, rules that block traffic have a higher precedence than rules that allow traffic. So if
traffic coming into (or going out of) the firewall matches both an allow rule and a block rule, it will
be dropped.
There are times however, when you might want to allow network traffic into a computer that is
ordinarily blocked. For example, the network troubleshooting team might need to use network
protocol analyzers or other network troubleshooting equipment in ways that the firewall rules
would ordinarily prevent. In such circumstances, you can create a computer-specific and
optionally a user-specific exception to some or all the firewall rules.
Because the IPsec authentication protocols require the exchange of computer or user credentials,
the credentials can be checked against a list of computers or users in the rule to further restrict
the network traffic. If you enable the Override block rules setting on the firewall rule then
correctly authenticated traffic that matches this rule is permitted, even if another rule would block
it. The result is a set of rules that say "this traffic is blocked unless it is coming from an
authenticated computer or user who is approved."
64
Steps for creating rules that allow specific computers or users to
bypass the firewall
In this section of the guide, you create a firewall rule that blocks all Telnet network traffic, and
then test it with your existing Telnet allow rule you created in a previous section. Then you modify
your existing Telnet allow rule to include the Override Block Rules setting, and confirm that you
can connect from your approved computer.
Step 1: Adding and Testing a Firewall Rule that Blocks All Telnet Traffic
Step 2: Modifying Your Telnet Allow Rule to Override Block Rules
Step 1: Adding and Testing a Firewall Rule that Blocks All Telnet
Traffic
Create a rule that blocks all Telnet traffic, and then test it by using the existing Telnet allow rule to
see that the cumulative effect is to block Telnet traffic.
To create a Telnet block rule

Firewall Settings for WS2008 Servers, and then click Edit.
2. In the Group Policy Object Editor, in the navigation pane, expand Computer
Configuration, expand Windows Settings, expand Security Settings, expand
Windows Firewall with Advanced Security, and then expand Windows Firewall with
Advanced Security -
LDAP://cn={GUID},cn=policies,cn=system,DC=contoso,DC=com.
3. Right-click Inbound Rules, and then click New Rule.
5. On the Program page, click This program path, and then in the text box, type
%systemroot%\system32\tlntsvr.exe.
6. Click Customize, click Apply to this service, click the row for Telnet with a short name
of TlntSvr, click OK, and then click Next.
7. On the Protocol and Ports page, change the Protocol type to TCP, change Local port
to Specific Ports, type 23 in the text box, and then click Next.
9. On the Action page, click Block the connection, and then click Next.
11. On the Name page, type Block All Telnet, and then click Finish.
Now you have two conflicting rules. One specifies that Telnet traffic is permitted as long as it is
encrypted and sent by a computer that is a member of the group Access to MBRSVR1. The
65
other rule says to block all Telnet traffic. In the next procedure you see what Telnet connectivity is
available when these two rules are both in place.
To test Telnet connectivity when two conflicting rules are in place

1. On MBRSVR1, switch to the Administrator: Command Prompt, run gpupdate /force.
Wait until the command is finished.
2. On CLIENT1, at a command prompt, type the command telnet mbrsvr1.
The command fails because, by default, the block rule has a higher precedence than the
allow rule.
Step 2: Modifying Your Telnet Allow Rule to Override Block

Rules
In this step, you modify your existing Telnet allow rule to include the Override Block Rule
setting, and then test the behavior of Telnet with the modified rule.
To add the Override Block Rule setting to your rule

1. On MBRSVR1, in Group Policy Management Editor, click Inbound Rules.
2. Right-click Allow Encrypted Inbound Telnet to Group Members Only, and then click
Properties.
3. On the General tab, in the Action section, select the Override block rules check box,
and then click OK.
Now test the two conflicting rules.
To test the Telnet connectivity with your current rule configuration

1. On MBRSVR1, at an Administrator: Command Prompt, run gpupdate /force. Wait
until the command is finished.
2. On CLIENT1, at a command prompt, run telnet mbrsvr1.
The command succeeds because the existing Telnet allow rule now overrides the block
rule. The only traffic that can bypass the Telnet block rule is that traffic that matches the
existing Telnet allow rule with the Override block rule option enabled. That rule specifies
that the traffic must be authenticated, and in this case, encrypted.
3. Type exit and the press ENTER to end the Telnet session.
66
Summary
Windows Firewall with Advanced Security is an important element in a defense-in-depth security
strategy to help secure the computers in your organization, and help mitigate against threats that
either bypass your perimeter firewall or originate from within the network.
In this guide, you were introduced to the features of the new Windows Firewall with Advanced
Security included with Windows Vista and Windows Server 2008:
• You used Windows Firewall with Advanced Security to set up basic inbound and outbound
firewall rules.
• You created Group Policy objects that configure firewall settings on all the computers in a
domain, and ensured that users cannot override those settings.
• You created a set of basic domain isolation rules that restrict domain-member computers
from accepting network traffic from computers that are not members of the domain.
• You created connection security rules that isolate servers which store sensitive information,
by restricting access to only computers that are members of approved groups.
• Finally, you created rules that enabled specific trusted computers to bypass firewall
requirements.
Additional References
For more information about the technologies discussed in this guide, see the following locations.

• Windows Firewall (http://go.microsoft.com/fwlink/?linkid=95393)
This page contains links to the documentation currently available for Windows Firewall, for
both the version available on Windows XP with Service Pack 2 (SP2) and Windows
Server 2003 with SP2, and the version available on Windows Vista and Windows
Server 2008.
• Windows Firewall with Advanced Security - Diagnostics and Troubleshooting
(http://go.microsoft.com/fwlink/?linkid=95372)
This article describes how Windows Firewall with Advanced Security works, what the
common troubleshooting situations are, and which tools you can use for troubleshooting.
IPsec
• IPsec (http://go.microsoft.com/fwlink/?linkid=95394)
This page contains links to the documentation currently available for Internet Protocol
security (IPsec), for both the version available on Windows XP with Service Pack 2 (SP2) and
67
Windows Server 2003 with SP2, and the version available as connection security rules in
Windows Firewall with Advanced Security on Windows Vista and Windows Server 2008.
• Simplifying IPsec Policy with the Simple Policy Update
This article describes a downloadable update available for Windows XP with SP2 and
Windows Server 2003 with Service Pack 1 (SP1). (The update is built into Windows
Server 2003 Service Pack 2). The update changes the behavior of IPsec negotiation so that
the IPsec policy rules can be simplified, in some cases significantly reducing the number of
required IP filters and their ongoing maintenance.
Server and Domain Isolation

• Server and Domain Isolation (http://go.microsoft.com/fwlink/?linkid=95395)
This page contains links to documentation that support the most common uses for IPsec:
server and domain isolation. Documentation is available for both the IPsec version available
on Windows XP with SP2 and Windows Server 2003 with SP2.
Group Policy
• Group Policy (http://go.microsoft.com/fwlink/?linkid=93542)
This page contains links to the documentation currently available for Group Policy, for both
the version available on Windows XP with SP2 and Windows Server 2003 with SP2, and the
version available on Windows Vista and Windows Server 2008.
• HOWTO: Leverage Group Policies with WMI Filters
This article describes how to create a WMI filter to set the scope of a GPO based on
computer attributes, such as operating system version number.
68
Using Identity Federation with Active
Directory Rights Management Services Step-
by-Step Guide
Author: Brian Lich
Abstract
This step-by-step guide provides instructions for setting up a test environment to deploy and
evaluate Active Directory Rights Management Services (AD RMS) with federated identity support
in Windows Server® 2008. It includes the necessary information for installing and configuring
AD RMS and AD FS and verifying AD RMS features after configuration is complete.
1
Microsoft, Active Directory, MS-DOS, Windows, Windows NT, and Windows Server are either
countries.
2
Contents
Using Identity Federation with Active Directory Rights Management Services Step-by-Step Guide
...................................................................................................................................................... 5
About This Guide.......................................................................................................................... 5
Deploying AD RMS with Identity Federation Support in a Test Environment .............................. 6
Step 1: Setting up the CP&L Enterprises Domain ........................................................................... 8

Install Windows Server 2008 Enterprise on the AD FS resource partner (ADFS-RESOURCE)
............................................................................................................................................... 9
Create the ADFSADMIN user account ................................................................................... 10
Add the ADFSADMIN user account to the local Administrators group on ADFS-RESOURCE
............................................................................................................................................. 11
Step 2: Setting up the Trey Research Domain .............................................................................. 11

Configure the domain controller (TREY-DC) .......................................................................... 12
Install Windows Server 2003 with SP2 on TREY-DC ......................................................... 12
Install Active Directory ......................................................................................................... 13
Raise the domain functional level to Windows Server 2003 ............................................... 14
Configure a DNS forwarder ................................................................................................. 14
Create user accounts .......................................................................................................... 15
Configure the computer for the federation account partner (ADFS-ACCOUNT) ....................... 16
Configure the AD RMS-enabled client computer (ADRMS-CLNT2) .......................................... 18
Step 3: Installing and Configuring AD FS ...................................................................................... 20

Install the Federation Service on ADFS-RESOURCE and ADFS-ACCOUNT ....................... 20
Configure ADFS-ACCOUNT to work with AD RMS ............................................................... 21
Configure ADFS-RESOURCE to Work with AD RMS ............................................................ 23
Step 4: Configuring ADRMS-SRV to Work with AD FS................................................................. 27

Grant security audit privileges to the AD RMS service account .......................................... 27
Add the AD RMS extranet cluster URLs ............................................................................. 28
Add the AD RMS Identity Federation Support role service ................................................. 28
Enable Identity Federation Support in the Active Directory Rights Management Services
console ............................................................................................................................. 29
Step 5: Verifying AD RMS Functionality ........................................................................................ 30
3
Using Identity Federation with Active
Directory Rights Management Services Step-
by-Step Guide
About This Guide

This step-by-step guide will assist you in using Active Directory Rights Management Services
(AD RMS) with Active Directory® Federation Services (AD FS) in a test environment. Specifically,
this guide will look at how to implement AD RMS if you have also deployed AD FS in your
organization and have established a trust relationship with another organization that has not
deployed AD RMS. Using the information in this guide, you can extend the basic AD RMS
deployment to use AD FS credentials to establish trusted user accounts. This will enable you to
share access to rights-protected content with another organization without having to establish a
separate trust.
In this guide, you will create a test deployment that includes the following components:
• An AD FS resource partner server
• An AD FS account partner server
• Two AD RMS clients
• Two Active Directory domain controllers
This guide assumes that you previously completed Windows Server Active Directory Rights
Management Services Step-by-Step Guide, and that you have already deployed the following
components:
• One AD RMS-enabled client
• One Active Directory domain controller

5
• Guidance for setting up and configuring AD RMS in a production environment.
• Complete technical reference for AD RMS or AD FS.
• Guidance for setting up AD FS with Microsoft Office SharePoint Server 2007 and AD RMS.
For more information about using identity federation with Office SharePoint Server 2007 and
AD RMS, see Appendix A of the Deploying Active Directory Rights Management Services
with Microsoft Office SharePoint Server 2007 Step-By-Step Guide
Deploying AD RMS with Identity Federation

Support in a Test Environment
We recommend that you first use the steps provided in this guide in a test lab environment. Step-
by-step guides are not necessarily meant to be used to deploy Windows Server features without
additional deployment documentation and should be used with discretion as a stand-alone
document.
Upon completion of this guide, you will have a working AD RMS and AD FS infrastructure. You
can then test and verify AD RMS and AD FS functionality as follows:
• Restrict permissions on a Microsoft Word 2007 document in the CPANDL.COM domain.
• Have an authorized user in the TREYRESEARCH.NET domain open and work with the
document.
• Have an unauthorized user in the CPANDL.COM domain attempt to open and work with the
document.
The test environment described in this guide includes eight computers connected to a private

Services (IIS) 7.0, World
Wide Web Publishing
Service, and Message
Queuing
CPANDL-DC Windows Server 2003 with Active Directory, Domain

TREY-DC Service Pack 2 (SP2) Name System (DNS)
Note
Domain controllers
running Windows 2000
Server with Service
6
Pack 4 can be used.
However, in this step-by-
step guide it is assumed
that you will be using
domain controllers running
Windows Server 2003 with
SP2.
Standard Edition with Service
Pack 2 (SP2)

ADRMS-CLNT2 Enterprise Edition
ADFS-RESOURCE Windows Server® 2008 Enterprise AD FS, IIS

ADFS-ACCOUNT
Note
Before installing and configuring the components in this guide, you should verify that your
hardware meets the minimum requirements for AD RMS
The computers form two private intranets and are connected through a common hub or Layer 2
switch. This configuration can be emulated in a virtual server environment, if desired. This step-
network ID 10.0.0.0/24 is used for the intranet. The domain controller for the domain named
cpandl.com is CPANDL-DC and the domain controller for the domain name treyresearch.net is
TREY-DC. The following figure shows the configuration of the test environment:
7
Step 1: Setting up the CP&L Enterprises
Domain
Before you install AD FS and the AD RMS Identity Federation Support role service, you need to
make changes to the infrastructure of the CPANDL domain. In this step, you will perform the
following tasks to install the required Active Directory Federation Services resource partner and
add it to the CP&L Enterprises infrastructure.
This section includes the following procedures:
8
• Install Windows Server 2008 Enterprise on the AD FS resource partner (ADFS-RESOURCE)
• Create the ADFSADMIN user account
• Add the ADFSADMIN user account to the local Administrators group on ADFS-RESOURCE
This step assumes that you have completed the Windows Server Active Directory Rights
Management Services Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=72134).
Use the following table as a reference when setting up the appropriate computer names,
operating systems, and network settings that are required to complete the steps in this guide.
Important
Computer name Operating system IP settings DNS settings

requirement
ADFS-RESOURCE Windows Server® 2008 IP address: Preferred:

Enterprise 10.0.0.7 10.0.0.1
Subnet mask:
255.255.255.0
Install Windows Server 2008 Enterprise on the AD FS resource

partner (ADFS-RESOURCE)
First, install Windows Server 2008 Enterprise as a stand-alone server on ADFS-RESOURCE.
Important
Windows Server 2008 Enterprise is required for the federation servers.
To install Windows Server 2008 Enterprise

3. When prompted for a computer name, type ADFS-RESOURCE.
In this step, configure TCP/IP properties so that the ADFS-RESOURCE computer has a static IP
address of 10.0.0.7.
9
To configure TCP/IP properties on the ADFS-RESOURCE computer
1. Log on to ADFS-RESOURCE with the ADFS-RESOURCE\Administrator account or
another user account in the local Administrators group.
2. Click Start, click Control Panel, click Network and Internet, double-click Network and
Sharing Center, click Manage Network Connections, right-click Local Area
Connection, and then click Properties.
Properties.
4. Select the Use the following IP address option. In IP address, type 10.0.0.7, in Subnet
mask, type 255.255.255.0.
5. Select the Use the following DNS server addresses option. In Preferred DNS server,
type 10.0.0.1.
6. Click OK, and then click Close to close the Local Area Connection Properties dialog
box.
Next, join the ADFS-RESOURCE computer to the CPANDL domain:
To join ADFS-RESOURCE to the cpandl.com domain

1. Click Start, right-click Computer, and then click Properties.
2. Click Change settings (at the right side under Computer name, domain, and
workgroup settings), and then click Change.
3. In the Computer Name/Domain Changes dialog box, select the Domain option, and
6. When a Computer Name/Domain Changes dialog box appears prompting you for
administrative credentials, provide the credentials of CPANDL\Administrator, and click
OK.
7. When a Computer Name/Domain Changes dialog box appears welcoming you to the
8. When a Computer Name/Domain Changes dialog box appears telling you that the
Create the ADFSADMIN user account

In this step, create the ADFSADMIN user account in Active Directory.
10
To add ADFSADMIN to the CPANDL Domain
1. Log on to CPANDL-DC with the CPANDL\Administrator account or another account in
2. Click Start, point to Administrative Tools, and then click Active Directory Users and
Computers. This opens the Active Directory Users and Computers console.
3. In the console tree, expand cpandl.com, right-click Users, point to New, and then click
User.
4. In the New Object – User dialog box, type ADFSADMIN in Full name and User logon
name boxes, and then click Next.
5. In the New Object – User dialog box, type a password of your choice in the Password
and Confirm password boxes. Clear the User must change password at next logon
check box, click Next, and then click Finish.
Add the ADFSADMIN user account to the local Administrators

group on ADFS-RESOURCE
Installing AD FS requires that the logged on user have administrative privileges on the local
server.
To add ADFSADMIN to the Administrators group

1. Log on to ADFS-RESOURCE as cpandl\administrator.
3. Expand Configuration, expand Local Users and Groups, and then click Groups.
4. Right-click Administrators, and then click Add to Group.
5. Click Add.
6. In the Select Users, Computers, or Groups window, type cpandl\adfsadmin, and then
click OK.
7. Click OK to close the Administrators properties sheet.
Step 2: Setting up the Trey Research Domain

Before you install AD FS and the AD RMS Federation Identity Support role service, you should
install and configure the Trey Research infrastructure. In this step, you will install the required
computers that make up the Trey Research domain:
• Configure the domain controller (TREY-DC)
11
• Configure the computer for the federation account partner (ADFS-ACCOUNT)
• Configure the AD RMS-enabled client computer (ADRMS-CLNT2)
Use the following table as reference when setting up the appropriate computer names, operating
systems, and network settings that are required to complete the steps in this guide.
Important
Before you configure your computers with static Internet Protocol (IP) addresses, it is
recommended that you first complete Windows product activation while each of your
computers still has Internet connectivity.
Computer name Operating system requirement IP settings DNS settings
TREY-DC Windows Server 2003 with IP address: Configured by DNS

SP2 10.0.0.30 server role.
Subnet mask:
255.255.255.0
ADFS-ACCOUNT Windows Server® 2008 IP address: Preferred:

Enterprise 10.0.0.31 10.0.0.30
Subnet mask:
255.255.255.0
ADRMS-CLNT2 Windows Vista IP address Preferred:

10.0.0.32 10.0.0.30
Subnet mask:
255.255.255.0
Configure the domain controller (TREY-DC)

To configure the domain controller TREY-DC, you must install Windows Server 2003, configure
TCP/IP properties, install Active Directory, raise the Active Directory domain functional level to
Windows Server 2003, and create user accounts. For each of the user accounts that are
configured for use with AD RMS, you also need to add an e-mail address and assign users to
these groups.
Install Windows Server 2003 with SP2 on TREY-DC

First, install Windows Server 2003 with SP2 on the TREY-DC computer.
12
To install Windows Server 2003 Standard Edition
1. Start your computer using the Windows Server 2003 product CD. (You can use any
edition of Windows Server 2003 except the Web Edition to establish the domain)
2. Follow the instructions that appear on your computer screen, and when prompted for a
computer name, type TREY-DC.
In this step configure TCP/IP properties so that TREY-DC has a static IP address of 10.0.0.30.
To configure TCP/IP properties on TREY-DC

1. Log on to TREY-DC with the TREY-DC\Administrator account or another user account in
2. Click Start, point to Control Panel, point to Network Connections, click Local Area
4. Click the Use the following IP address option. In the IP address box, type 10.0.0.30. In
the Subnet mask box, type 255.255.255.0.
box.
Install Active Directory

In this step, you are going to create a domain controller for Trey Research. It is important that you
first configure the IP addresses as specified in the previous table before you attempt to install
Active Directory. This helps ensure that DNS records are configured appropriately.
Note
If you need to use fewer computers to test this scenario, you can use the Dcpromo tool to
create two new Active Directory forests on both of the federation servers rather than
configuring separate domain controllers. As a security best practice, domain controllers
should not run as both federation servers and domain controllers in a production
environment.
To configure TREY-DC as a domain controller

1. Click Start, and click Run. In the Open box, type dcpromo, and then click OK.
2. On the Welcome page of the Active Directory Installation Wizard, click Next.
3. Click Next, select the Domain controller for a new domain option, and then click Next.
4. Select the Domain in a new forest option, and click Next.
5. In Full DNS name for new domain, type treyresearch.net and then click Next.
6. In Domain NetBIOS name, type treyresearch, and then click Next three times.
13
7. Select the Install and configure the DNS server on this computer and set this
computer to use this DNS server as its preferred DNS server option, and then click
Next.
8. Select the Permissions compatible only with Windows 2000 or Windows
Server 2003 operating systems option, and then click Next.
9. In the Restore Mode Password and Confirm Password boxes, type a strong password,
10. Click Next.
11. When the Active Directory Installation Wizard is done, click Finish.
Raise the domain functional level to Windows Server 2003

In this step, we will raise the Active Directory domain functional level to Windows Server 2003.
This functional level allows the use of Active Directory universal groups.
To raise the domain functional level to Windows Server 2003

1. Log on to TREY-DC with the TREYRESEARCH\Administrator account or another user
account in the local Administrators group.
Computers.
3. Right-click treyresearch.net, and then click Raise Domain Functional Level.
4. In the list under Select an available domain functional level, click Windows
Server 2003, and then click Raise.
Note
You cannot change the domain functional level once you have raised it.
Configure a DNS forwarder

DNS forwarders are used in this guide to forward DNS requests that cannot be resolved from the
treyresearch.net domain to the cpandl.com domain, and vice versa. To configure the DNS
forwarder:
To configure the DNS forwarder on TREY-DC

14
3. Right-click TREY-DC, and then click Properties.
4. Click the Forwarders tab.
5. In the Selected domain's forward IP address list section, type 10.0.0.1, and then click
Add.
6. Click OK.
Next, configure the DNS forwarder on the CPANDL-DC computer:
To configure the DNS forwarder on CPANDL-DC

1. Log on to CPANDL-DC with the CPANDL\Administrator account or another user account
in the local Administrators group.
3. Right-click CPANDL-DC, and then click Properties.
4. Click the Forwarders tab.
5. In the Selected domain's forward IP address list section, type 10.0.0.30, and then click
Add.
6. Click OK.
Create user accounts

In this step, add the user accounts shown in the following table to Active Directory. Use the
procedure following the table to create the user accounts.
Account Name User Logon Name E-mail address
ADFSADMIN ADFSADMIN
Terrence Philip tphilip tphilip@treyresearch.net
To add new user accounts to the TREYRESEARCH domain

Computers. This opens the Active Directory Users and Computers console.
3. In the console tree, expand treyresearch.net.
4. Right-click Users, point to New, and then click User.
5. In the New Object – User dialog box, type ADFSADMIN in the Full name and User
logon name boxes, and then click Next.
15
7. Perform steps 3-6 for Terrence Philip (tphilip).
Next, add e-mail addresses to user accounts from the table above.
To add e-mail addresses to user accounts

1. In the Active Directory Users and Computers console, right-click Terrence Philip,
click Properties, type tphilip@treyresearch.net in the E-mail box, and then click OK.
2. Close the Active Directory Users and Computers console.
Configure the computer for the federation account

partner (ADFS-ACCOUNT)
In this section, we will configure the computer that will be used at the federation server in the
TREYRESEARCH domain.
First, install Windows Server 2008 Enterprise as a stand-alone server on ADFS-ACCOUNT.
Important
Windows Server 2008 Enterprise is required for the federation servers.
To install Windows Server 2008 Enterprise

3. When prompted for a computer name, type ADFS-ACCOUNT.
In this step configure TCP/IP properties so that the ADFS-ACCOUNT computer has a static IP
address of 10.0.0.31.
To configure TCP/IP properties on the ADFS-ACCOUNT computer

1. Log on to ADFS-ACCOUNT with the ADFS-ACCOUNT\Administrator account or another
user account in the local Administrators group.
2. Click Start, click Network, click Network and Sharing Center, click Manage Network
Connections, right-click Local Area Connection, and then click Properties.
Properties.
4. Select the Use the following IP address option. In IP address, type 10.0.0.31, in
16
Subnet mask, type 255.255.255.0.
type 10.0.0.30.
box.
Next, join the ADFS-ACCOUNT computer to the TREYRESEARCH domain:
To join ADFS-ACCOUNT to the treyresearch.net domain

3. Click Change settings (at the right side), and then click Change.
then type treyresearch.net.
5. Click More, and type treyresearch.net in Primary DNS suffix of this computer box.
administrative credentials, provide the credentials for TREYRESEARCH\Administrator,
and click OK.
treyresearch.net domain, click OK.
Finally, add the ADFSADMIN user account to the local Administrators group on ADFS-
ACCOUNT:
To add ADFSADMIN to the local Administrators group on ADFS-ACCOUNT

1. Log on to ADFS-ACCOUNT with the TREYRESEARCH\Administrator account or another
2. To open Server Manager, click Start, point to Administrative Tools, and then click
Server Manager.
3. Expand Configuration, expand Local Users and Groups, and then click Groups.
4. Double-click Administrators, click Add, type TREYRESEARCH\ADFSADMIN, click OK,
and then click OK again.
17
Configure the AD RMS-enabled client computer
(ADRMS-CLNT2)
To configure the ADRMS-CLNT2 client computer in the TREYRESEARCH domain, you must
install Windows Vista, configure TCP/IP properties, and then join the computer to the
TREYRESEARCH domain. You must also install an AD RMS-enabled application. In this
example, Microsoft Office Word 2007 Enterprise Edition is installed on the client.

1. Start your computer by using the Windows Vista product CD.
2. Follow the instructions that appear on your screen, and when prompted for a computer
name, type ADRMS-CLNT2.
Next, configure TCP/IP properties so that ADRMS-CLNT2 has a static IP address of 10.0.0.32. In
addition, configure the DNS server of TREY-DC (10.0.0.30).

1. Log on to ADRMS-CLNT2 with the ADRMS-CLNT2\Administrator account or another
2. Click Start, click Network, and then click Network and Sharing Center.
3. Click Manage Network Connections, right-click Local Area Connection, and then click
Properties.
Properties.
5. Select the Use the following IP address option. In IP address, type 10.0.0.32, in
Subnet mask, type 255.255.255.0.
type 10.0.0.30.
box.
Next, join the ADRMS-CLNT2 to the TREYRESEARCH domain.
To join ADRMS-CLNT2 to the TREYRESEARCH domain

2. Under Computer name, domain, and workgroup settings, click Change settings.
3. On the Computer Name tab, click Change.
then type treyresearch.net.
18
5. Click More, and in the Primary DNS suffix of this computer box, type
treyresearch.net.
6. Click OK, and click OK again.
administrative credentials, provide the credentials for treyresearch\administrator, and
then click OK.
treyresearch.net domain, click OK.
10. In the System Settings Change dialog box, click Yes to restart the computer.
Next, we need to configure ADRMS-CLNT2 for federation support with AD RMS. This registry
entry assigns the AD FS home realm for AD RMS.
To configure ADRMS-CLNT2 for federation support

1. Log on to ADRMS-CLNT2 with the TREYRESEARCH\Administrator account or another
2. Click Start, type regedit.exe, and then press Enter.
3. Expand HKEY_LOCAL_MACHINE, expand Software, and then expand Microsoft.
4. Right-click Microsoft, point to New, click Key, type MSDRM and then press Enter.
5. Right-click MSDRM, point to New, click Key, type Federation and then press Enter.
6. Right-click Federation, point to New, click String Value, type FederationHomeRealm,
and then press ENTER.
7. Double-click FederationHomeRealm, type urn:federation:treyresearch.net, and then
click OK.
Finally, install Microsoft Office Word 2007 Enterprise Edition on ADRMS-CLNT2.

1. Double-click setup.exe from the Microsoft Office 2007 Enterprise product CD.
2. Click Customize as the installation type, set the installation type to Not Available for all
applications except Microsoft Office Word 2007 Enterprise, and then click Install Now.
This might take several minutes to complete.
Important
Only the Ultimate, Professional Plus, and Enterprise editions of Microsoft Office 2007
allow you to create rights-protected content. All editions will allow you to consume rights-
protected content.
19
Step 3: Installing and Configuring AD FS
Now that you have configured the computers that will be used as federation servers, you are
ready to install Active Directory Federation Services (AD FS) components on each of the
computers. This section includes the following procedures:
• Install the Federation Service on ADFS-RESOURCE and ADFS-ACCOUNT
• Configuring ADFS-ACCOUNT to work with AD RMS
• Configuring ADFS-RESOURCE to work with AD RMS
Install the Federation Service on ADFS-RESOURCE and ADFS-

ACCOUNT
Use the following procedure to install the Federation Service component of AD FS on the ADFS-
RESOURCE computer and the ADFS-ACCOUNT computer. After the Federation Service is
installed on a computer, that computer becomes a federation server.
To add the Federation Service role service

1. Log on to ADFS-RESOURCE with the CPANDL\ADFSADMIN account or another
4. Click Add Roles.
5. On the Before You Begin page, click Next.
6. On the Select Server Roles page, click Active Directory Federation Services.
7. Click Next.
8. On the Introduction to AD FS page, click Next.
9. On the Select Role Services page, select the Federation Service check box. If you are
prompted to install additional role services, click Add Required Role Services, and then
click Next.
10. Select the Choose an existing certificate for SSL encryption option, click the
appropriate certificate, and then click Next.
Note
If you choose to use self-signed certificates in your test environment, select the
Create a self-signed certificate for SSL encryption option, and then click
Next.
11. On the Choose a Token-Signing Certificate page, select the Choose an existing
20
token-signing certificate option, click the appropriate certificate, and then click Next.
Note
If you choose to use self-signed certificates in your test environment, select the
Create a self-signed token-signing certificate option, and then click Next.
12. Select the Create a new trust policy option, and then click Next.
13. Read the Introduction to Web Server (IIS) page, and then click Next.
14. Keep the Web server default check box selections, and then click Next
15. Click Install.
16. When the installation has completed, click Close.
17. Log on to ADFS-ACCOUNT as TREYRESEARCH\ADFSADMIN.
18. Repeat steps 2–13 for the ADFS-ACCOUNT computer using the
TREYRESEARCH\ADFSADMIN user account.
Configure ADFS-ACCOUNT to work with AD RMS

The ADFS-ACCOUNT computer is a member of the TREYRESEARCH domain and forwards
AD RMS requests to the CPANDL domain. In this section, you configure the AD FS trust policy,
create a custom claim for the ProxyAddresses Active Directory attribute, add an Active Directory
Account Store, and add and configure a resource partner.
First, configure the ADFS-ACCOUNT computer trust policy for the federation service in the
TREYRESEARCH domain.
To configure the trust policy on the AD FS account partner (ADFS-ACCOUNT)

1. Log on to ADFS-ACCOUNT with the TREYRESEARCH\adfsadmin account or another
Services.
4. Expand Federation Service, right-click Trust Policy, and then click Properties.
5. In the Federation Service URI box, type urn:federation:treyresearch.net.
Note
The Federation Service URI value is case sensitive.
6. In the Federation Service endpoint URL box, confirm that https://ADFS-
ACCOUNT.treyresearch.net/adfs/ls/ is shown.
7. On the Display Name tab, in Display name for this trust policy, type Trey Research,
21
and then click OK.
Next, create a custom claim that will be used with AD RMS.
To create a custom claim

1. In the Active Directory Federation Services console, expand Federation Service, expand
Trust Policy, and then expand My Organization.
2. Right-click Organization Claims, point to New, and then click Organization Claim.
3. In the Claim name box, type ProxyAddresses.
Note
The claim name value is case-sensitive.
4. Select the Custom claim option, and then click OK.
Important
Great care should be taken when allowing proxy addresses through a federated trust. If
proxy addresses through federation are allowed, it is possible for a malicious user to
spoof an authorized user's credentials and access the user's rights-protected content. If
proxy addresses through federation is a requirement of your organization, you should
implement a claims transformation module that will examine a proxy address from a
federated user and make sure that it matches the forest in which the request originated.
The option to allow a proxy address from a federated user is turned off by default in the
Active Directory Rights Management Services console.
Next, add an Active Directory account store to the Federation Service for the TREYRESEARCH
domain.
To add an Active Directory account store to ADFS-ACCOUNT

2. Right-click Account Stores, point to New, and then click Account Store.
3. On the Welcome to the Add Account Store Wizard page, click Next.
4. On the Account Store Type page, select the Active Directory Domain Services
5. On the Enable this Account Store page, select the Enable this account store check
box, and then click Next.
6. On the Completing the Add Account Store Wizard page, click Finish.
7. Double-click the E-mail organization claim, select the Enabled check box, type mail in
the LDAP attribute box, and then click OK.
8. Right-click the Active Directory account store, point to New, and then click Custom claim
22
extraction.
9. In the Attribute box, type ProxyAddresses, and then click OK.
Finally, add a resource partner to the Federation Service in the TREYRESEARCH domain.
To add a resource partner to the TREYRESEARCH domain

Trust Policy, and then expand Partner Organizations.
2. Right-click Resource Partners, point to New, and then click Resource Partner.
3. On the Welcome to the Add Resource Partner Wizard page, click Next.
4. Select the No option on the Import Policy File page, and then click Next.
5. On the Resource Partner Details page, in the Display name box, type CP&L
Enterprises.
6. In the Federation Service URI box, type urn:federation:cpandl.com.
Note
The Federation Service URL value is case sensitive.
7. In the Federation Service endpoint URL box, type https://adfs-
resource.cpandl.com/adfs/ls/, and then click Next.
8. On the Federation Scenario page, select the Federated Web SSO option, and then
click Next.
9. Select the UPN Claim and E-mail Claim check boxes, and then click Next.
10. Select the Pass all UPN suffixes through unchanged option, and then click Next.
11. Select the Pass all E-mail suffixes through unchanged option, and then click Next.
12. Ensure that the Enable this resource partner check box is checked, and then click
Next.
13. Click Finish.
14. Right-click the new CP&L Enterprises resource partner, point to New, and then click
Outgoing Custom Claim Mapping.
15. In the Outgoing custom claim name box, type ProxyAddresses, and then click OK.
16. Close the Active Directory Federation Services console.
Configure ADFS-RESOURCE to Work with AD RMS

The ADFS-RESOURCE computer is a member of the CPANDL domain and receives AD RMS
requests from the TREYRESEARCH domain. In this section, you configure the AD FS trust
policy, create a custom claim for the ProxyAddresses Active Directory attribute, add an Active
23
Directory Account Store, add AD RMS as a Claims-aware application, and configure a resource
partner.
First, configure the ADFS-RESOURCE computer trust policy for the federation service in the
CPANDL domain.
To configure the trust policy on the AD FS resource partner (ADFS-RESOURCE)

1. Log on to ADFS-RESOURCE with the CPANDL\ADFSADMIN account or another user
Services.
4. Expand Federation Service, right-click Trust Policy, and then click Properties.
5. In the Federation Service URI box, type urn:federation:cpandl.com.
Note
The Federation Service URI value is case sensitive.
6. In the Federation Service endpoint URL box, confirm that https://ADFS-
RESOURCE.cpandl.com/adfs/ls/ is shown.
7. On the Display Name tab, in Display name for this trust policy, type CP&L
Enterprises, and then click OK.
Next, create a custom claim that will be used with AD RMS.
To create a custom claim

2. Right-click Organization Claims, point to New, and then click Organization Claim.
3. In the Claim name box, type ProxyAddresses.
Note
The claim name value is case-sensitive.
4. Select the Custom claim option, and then click OK.
Next, add an Active Directory account store to the Federation Service for the CPANDL domain.
To add an Active Directory account store to ADFS-RESOURCE

24
2. Right-click Account Stores, point to New, and then click Account Store.
3. On the Welcome to the Add Account Store Wizard page, click Next.
4. On the Account Store Type page, select the Active Directory Domain Services
5. On the Enable this Account Store page, select the Enable this account store check
box, and then click Next.
6. On the Completing the Add Account Store Wizard page, click Finish.
7. Double-click the E-mail organization claim, select the Enabled check box, type mail in
the LDAP attribute box, and then click OK.
8. Right-click the Active Directory account store, point to New, and then click Custom claim
extraction.
9. In the Attribute box, type ProxyAddresses, and then click OK.
Next, add the AD RMS certification pipeline as a claims-aware application.
To add the AD RMS certification pipeline as a claims-aware application

3. On the Welcome to the Add Application Wizard page, click Next.
4. On the Application Type page, select the Claims-aware application option, and then
click Next.
5. In the Application display name box, type AD RMS Certification.
6. In the Application URL box, type https://adrms-
srv.cpandl.com/_wmcs/certificationexternal/, and then click Next.
Note
The application URL is case sensitive and the name of the AD RMS extranet
cluster should match the return URL value of the ADRMS-SRV computer exactly.
If the values do not match, AD FS functionality will not work.
7. On the Accepted Identity Claims page, select the User principal name (UPN) and E-
mail check boxes, and then click Next.
8. On the Enable this Application page, select the Enable this application check box,
9. On the Completing the Add Application Wizard page, click Finish.
10. In the task pane, double-click ProxyAddresses, select the Enabled check box, and then
click OK.
25
Use the following procedure to add the AD RMS licensing pipeline as a claims-aware application.
To add AD RMS licensing as a claims-aware application

3. On the Welcome to the Add Application Wizard page, click Next.
4. On the Application Type page, select the Claims-aware application option, and then
click Next.
5. In the Application display name box, type AD RMS Licensing.
6. In the Application URL box, type https://adrms-
srv.cpandl.com/_wmcs/licensingexternal/, and then click Next.
Note
The application URL is case sensitive and the computer name in the URL should
match the return URL value of the ADRMS-SRV computer exactly. If the values
do not match, AD FS functionality will not work.
7. On the Accepted Identity Claims page, select the User principal name (UPN) and E-
mail check boxes, and then click Next.
8. On the Enable this Application page, click the Enable this application check box, and
then click Next.
9. On the Completing the Add Application Wizard page, click Finish.
10. In the task pane, double-click ProxyAddresses, click the Enabled check box, and then
click OK.
Next, add an account partner to ADFS-RESOURCE. This account partner receives requests from
the ADFS-ACCOUNT computer in the TREYRESEARCH domain.
To add an account partner to ADFS-RESOURCE

Trust Policy, and then expand Partner Organizations.
2. Right-click Account Partners, point to New, and then click Account Partner.
3. On the Welcome to the Add Account Partner Wizard page, click Next.
4. On the Import Policy File page, select the No option, and then click Next.
5. On the Resource Partner Details page , in the Display name box, type Trey Research.
6. In the Federation Service URI box, type urn:federation:treyresearch.net.
7. In the Federation Service endpoint URL box, type https://adfs-
account.treyresearch.net/adfs/ls/, and then click Next.
26
8. On the Account Partner Verification page, type the path where the token signing
certificate is stored, and then click Next.
9. Select the Federated Web SSO option, and then click Next.
10. Select the UPN Claim and E-mail Claim check boxes, and then click Next.
11. On the Accepted UPN Suffixes page, type treyresearch.net, click Add, and then click
Next.
12. On the Accept E-mail Suffixes page, type treyresearch.net, click Add, and then click
Next.
13. Verify that the Enable this account partner check box is checked, and then click Next.
14. Click Finish.
15. Right-click the Trey Research account partner, point to New, and then click Incoming
Custom Claim Mapping.
16. In the Incoming custom claim name box, type ProxyAddresses, and then click OK.
Step 4: Configuring ADRMS-SRV to Work

with AD FS
Windows Server 2008 includes the option to install identity federation support for AD RMS as a
role service through Server Manager. This step of the guide will cover the following tasks:
• Grant security audit privileges to the AD RMS service account
• Add the AD RMS extranet cluster URLs
• Add the AD RMS Identity Federation Support role service
• Enable Identity Federation Support in the Active Directory Rights Management Services
console
Grant security audit privileges to the AD RMS service account

The AD RMS service account must be able to generate security audit events when using AD FS.
To grant security audit privileges to the AD RMS service account

1. Click Start, point to Administrative Tools, and then click Local Security Policy.
27
3. Expand Local Policies, and then click User Rights Assignment.
4. Double-click Generate security audits.
5. Click Add User or Group.
6. Type cpandl\adrmssrvc, and then click OK.
7. Click OK to close the Generate security audits properties sheet.
Add the AD RMS extranet cluster URLs

AD RMS-enabled clients consuming rights-protected content through a federated trust use the
AD RMS extranet cluster URLs to create a rights account certificate.
Caution
The AD RMS cluster URLs must be added before the Identity Federation Support role
service is added by using Server Manager. If the cluster URLs are not added, you must
edit the web.config files in the certificationexternal and licensingexternal directories
manually.
To add the AD RMS extranet cluster URLs

1. Log on to ADRMS-SRV with the CPANDL\ADRMSADMIN account.
2. Open the Active Directory Rights Management Services console. Click Start, point to
Administrative Tools, and then click Active Directory Rights Management Services.
4. Right-click adrms-srv.cpandl.com, and then click Properties.
5. Click the Cluster URLs tab, and then select the Extranet URLs check box.
6. For Licensing, click https://, and then type adrms-srv.cpandl.com.
7. For Certification, click https://, and then type adrms-srv.cpandl.com.
8. Click OK.
Add the AD RMS Identity Federation Support role service

Next, add the Identity Federation Support role service through Server Manager.
To add the Identity Federation Support Role Service

28
4. In the Roles Summary box, click Active Directory Rights Management Services, and
then click Add Role Services.
5. Select the Identity Federation Support check box. Ensure that the Claims-aware
Agent role service is listed as a required role service, and then click Add Required
Role Services.
6. Click Next.
7. On the Configure Identity Federation Support page, type adfs-resource.cpandl.com,
click Validate, and then click Next.
8. On the Introduction to AD FS page, click Next.
9. On the AD FS Role Service page, confirm that Claims-aware Agent is checked, and
then click Next.
10. Click Install to add the Identity Federation Support role service to the ADRMS-SRV
computer.
11. Click Finish.
Enable Identity Federation Support in the Active Directory Rights

Management Services console
Once enabled, Identity Federation Support allows user accounts to use credentials established by
a federated trust relationship through Active Directory Federation Services (AD FS) as a basis for
obtaining a rights account certificate from an AD RMS cluster.
To enable AD RMS identity federation support in the Active Directory Rights

Management Services console
2. Open the Active Directory Rights Management Services console and expand the
AD RMS cluster.
4. In the console tree, expand Trust Policies,and then click Federated Identity Support.
5. In the Actions pane, click Enable Federated Identity Support.
6. In the Actions pane, click Properties.
7. On the Active Directory Federation Service Policies tab, in Federated Identity
Certificate validity period, type 7. This is the number of days that federated rights
account certificates are to be valid.
8. Click OK.
29
The AD RMS client is included in the default installation of Windows Vista and Windows
Server 2008. Previous versions of the client are available for download for some earlier versions
of the Windows operating systems. For more information, see the Windows Server 2003 Rights
Management Services page in the Microsoft Windows Server TechCenter
Before you can publish or consume rights-protected content on Windows Vista, you must add the
AD RMS cluster URL, the ADFS-RESOURCE URL, and the ADFS-ACCOUNT URL to the
Internet Explorer Local Intranet security zone of the ADRMS-CLNT2 computer. This is required to
ensure that your credentials are automatically passed from Microsoft Office Word to the AD RMS
Web services.
To add AD RMS cluster URL to the Internet Explorer Local Intranet security zone
1. Log on to ADRMS-CLNT2 as Terence Philip (TREYRESEARCH\tphilip).
2. Click Start, click Control Panel, click Network and Internet, and then click Internet
Options.
3. Click the Security tab, and then click Local Intranet.
4. Click Sites, and then click Advanced.
5. In the Add this website to the zone box, do the following:
a. Type https://adrms-srv.cpandl.com, and then click Add.
b. Type https://adfs-resource.cpandl.com, and then click Add.
c. Type https://adfs-account.treyresearch.net, and then click Add.
To verify the functionality of the AD RMS deployment, you log on as Nicole Holliday, create a
Microsoft Word 2007 document, and then restrict permissions on it so that Terrence Philip is able
to read the document but is unable to change, print, or copy it. You then log on as Terence Philip,
verifying that Terence Philip can read the document but do nothing else with it.

1. Log on to ADRMS-CLNT as Nicole Holliday (CPANDL\nhollida).
Office Word 2007.
3. Type Only Terence Philip can read this document, but cannot change, print, or
copy it. Click Microsoft Office Button, point to Prepare, point to Restrict Permission,
and then click Restricted Access.
4. Click the Restrict permission to this document check box.
5. In the Read text box, type TPHILIP@TREYRESEARCH.NET, and then click OK to close
30
the Permission dialog box.
6. Click the Microsoft Office Button, click Save As, and then save the file as \\adrms-
db\public\ADRMS-TST.docx
Finally, log on as Terence Philip on ADRMS-CLNT2 in the TREYRESEARCH.NET domain and
attempt to open the document, ADRMS-TST.docx.

1. Log on to ADRMS-CLNT2 as Terence Philip (TREYRESEARCH\tphilip).
Office Word 2007.
3. Click the Microsoft Office Button, click Open, and then type \\ADRMS-DB\PUBLIC
\ADRMS-TST.docx. If you are prompted for credentials, use CPANDL\Administrator.
The following message appears: "Permission to this document is currently restricted.
Microsoft Office must connect to https://adrms-srv.cpandl.com/_wmcs/licensing to
verify your credentials and download your permissions."
4. Click OK.
The following message appears: "Verifying your credentials for opening content with
restricted permissions".
5. When the document opens, click Microsoft Office Button. Notice that the Print option is
not available.
6. Click View Permission in the message bar. You should see that Terence Philip has
been restricted to being able only to read the document.
7. Click OK to close the My Permissions dialog box, and then close Microsoft Word.
You have successfully deployed and demonstrated the functionality of using identity federation
with AD RMS, using the simple scenario of applying restricted permissions to a Microsoft
Word 2007 document. You can also use this deployment to explore some of the additional
capabilities of AD RMS through additional configuration and testing.
31
What's New in Failover Clusters
Author: Jan Keller
Editor: Ronald Loi
Abstract
In Windows Server® 2008, the improvements to failover clusters (formerly known as server
been improved, as has the way a failover cluster communicates with storage. This document
describes the improvements in failover clusters.
1
countries.
2
Contents
What's New in Failover Clusters in Windows Server 2008 ............................................................. 5
What does a failover cluster do? .................................................................................................. 5
Who will be interested in failover clustering? ............................................................................... 5
Are there any special considerations? ......................................................................................... 5
What new functionality does failover clustering provide? ............................................................ 5
New validation wizard ............................................................................................................... 6
Support for GPT disks in cluster storage .................................................................................. 6
What existing functionality is changing? ...................................................................................... 6
Improvements to setup ............................................................................................................. 7
Improvements to management interfaces ................................................................................ 7
Improvements to stability and security to help maximize availability........................................ 8
Improvements to the way a cluster works with storage ............................................................ 8
Improvements to interfaces for working with shared folders .................................................... 8
Improvements to networking and security ................................................................................ 9
Do I need to change any existing code to work with Windows Server 2008? ........................... 10
How should I prepare to deploy this feature? ............................................................................ 10
Is this feature available in all editions of Windows Server 2008? .............................................. 10
3
What's New in Failover Clusters in Windows

Server 2008
In Windows Server® 2008 Enterprise and Windows Server® 2008 Datacenter, the improvements
to failover clusters (formerly known as server clusters) are aimed at simplifying clusters, making
them more secure, and enhancing cluster stability. Cluster setup and management are easier.
Security and networking in clusters have been improved, as has the way a failover cluster
communicates with storage.
Note
The failover cluster feature is not available in Windows® Web Server 2008 or
Windows Server® 2008 Standard.
What does a failover cluster do?

Who will be interested in failover clustering?

Failover clusters are used by IT professionals who need to provide high availability for services or
applications.
Are there any special considerations?

Microsoft supports a failover cluster solution only if all the hardware components are marked as
"Certified for Windows Server 2008." In addition, the complete configuration (servers, network,
and storage) must pass all tests in the Validate a Configuration wizard, which is included in the
Failover Cluster Management snap-in.
What new functionality does failover clustering

provide?
• New validation feature. With this feature, you can check that your system, storage, and
network configuration is suitable for a cluster.
5
• Support for GUID partition table (GPT) disks in cluster storage. GPT disks can have
partitions larger than two terabytes and have built-in redundancy in the way partition
information is stored, unlike master boot record (MBR) disks.
New validation wizard

By using the new validation wizard in failover clusters, you can perform tests to determine
whether your system, storage, and network configuration is suitable for a cluster. These tests
include specific simulations of cluster actions, and fall into the following categories:
• System Configuration tests. These tests analyze whether the selected servers meet
specific requirements, for example, the requirement that the servers must run the same
operating system version and software updates.
• Network tests. These tests analyze whether the planned cluster networks meet specific
requirements, for example, requirements for network redundancy.
• Storage tests. These tests analyze whether the storage meets specific requirements, for
example, whether the storage correctly supports the necessary SCSI commands and handles
simulated cluster actions correctly.
Support for GPT disks in cluster storage

GUID partition table (GPT) disks are supported in failover cluster storage. GPT disks provide
increased disk size and robustness. Specifically, GPT disks can have partitions larger than two
terabytes and have built-in redundancy in the way partition information is stored, unlike master
boot record (MBR) disks. With failover clusters, you can use either type of disk.
What existing functionality is changing?

The following list briefly summarizes the improvements in failover clusters:
• Improved cluster setup. These improvements make it simpler to get started with a new
cluster.
• Simplified management interfaces. With the improvements to interfaces, you can focus on
managing your applications, not your cluster.
• Improvements to stability and security, which can result in increased availability.
Failover clusters include improvements to the way the cluster communicates with storage,
improving the performance of a storage area network (SAN) or direct attached storage
(DAS). They also offer configuration options that mean the quorum no longer needs to be a
single point of failure. In addition, improvements to the underlying software infrastructure and
to networking and security increase the reliability and availability of failover clusters.
6
• Improvements to the way a cluster works with storage. With these improvements, you
can achieve better performance with your storage than was possible with server clusters in
previous releases.
• Improvements to interfaces for working with shared folders. With these improvements,
configuration of shared folders is more straightforward and misconfiguration is less likely.
• Improvements to networking and security. These improvements make it simpler to
configure and maintain the networks that the cluster uses.
Improvements to setup
The Create Cluster wizard has been simplified to make it much easier to set up a cluster. Cluster
setup is also fully scriptable so that you can automate your deployment.
The failover clustering software also includes a wizard that can help you capture certain resource
group settings from a cluster running Windows Server 2003 and apply them to a cluster running
Windows Server 2008. This can help you accomplish a migration more quickly.
Improvements to management interfaces

With failover clusters in Windows Server 2008, you can carry out the following management and
operations tasks more easily than with server clusters in previous releases:
• Quickly configure clustered services and applications. The interface for administering a
cluster is simpler and more intuitive, making it easier to perform such tasks as making a
shared folder highly available. You can focus on managing your applications, not your cluster.
• Use the command line or Windows Management Instrumentation (WMI) to work with a
cluster. You can use the command line or Windows Management Instrumentation (WMI) for
more tasks than in previous versions.
• Troubleshoot a cluster. In addition to working with the cluster log, you can use Event
Tracing for Windows to easily gather, manage, and report information about the sequence of
events that occurred on the cluster.
• Use the Volume Shadow Copy Service to capture backups. Full integration with the
Volume Shadow Copy Service makes it easier to back up and restore your cluster
configuration.
• Control the way you view shared folders that have been clustered. You can control or
"scope" your view of shared folders so that it is easy to understand which shared folders are
clustered and on which cluster a shared folder is available.
7
Improvements to stability and security to help maximize

availability
With failover clusters in Windows Server 2008, improvements to the cluster infrastructure help
you maximize availability of services and applications. You can:
• Configure your cluster so that the quorum is not a single point of failure. With
improvements in failover clusters, you can use the two cluster models that previously
existed—the quorum resource model and the majority node set model—or a "hybrid" of the
two. For example, in a two-node cluster, you can specify that if the quorum disk (now called a
"witness disk") becomes unavailable, the cluster continues running as long as the copies of
the cluster configuration database on the two nodes remain available.
• Achieve greater reliability and availability because of improvements to the cluster
infrastructure itself. The cluster infrastructure has been improved to help you achieve
greater reliability and availability with failover clusters. For example, the software
infrastructure that handles clustered resources will isolate dynamic-link libraries (DLLs) that
perform actions incorrectly, minimizing impact to the cluster. As another example, the cluster
will use enhanced methods to ensure consistency among copies of the cluster configuration
database.
Improvements to the way a cluster works with storage

With failover clusters in Windows Server 2008, you can achieve better performance with your
storage than was possible with server clusters in previous releases. You can:
• Make additional disks available to the cluster while applications are online. You can
modify resource dependencies while resources are online, which means you can make an
additional disk available without interrupting access to the application that will use it.
• Obtain better performance and stability with your storage. When a failover cluster
communicates with your SAN or DAS, it uses the least disruptive commands (avoiding SCSI
bus resets). Disks are never left in an unprotected state, meaning that the risk of volume
corruption is lowered. Failover clusters also support improved methods for disk discovery and
recovery.
The types of storage connections that failover clusters support are Serial Attached SCSI
(SAS), iSCSI, and Fibre Channel.
• Perform disk maintenance tasks more easily. "Maintenance mode" has been improved so
that you can run tools to check, fix, back up, or restore disks more easily and with less
disruption to the cluster.
Improvements to interfaces for working with shared folders

In Windows Server 2008, the interfaces for viewing or configuring shared folders in a failover
cluster have been extended and streamlined. Configuration is more straightforward and
8
misconfiguration is less likely. The improvements include the ability to configure the following for
shared folders:
• Access-based enumeration: You can use access-based enumeration to hide a specified
folder from users' view. Instead of allowing users to see the folder but not access anything on
it, you can choose to prevent them from seeing the folder at all. You can configure access-
based enumeration for a clustered shared folder in the same way as for a nonclustered
shared folder.
• Offline access: You can configure offline access (caching) for a clustered shared folder in
the same way as for a nonclustered shared folder.
• Clustered disks always recognized as part of the cluster: Whether you use the failover
cluster interface, Windows Explorer, or the Share and Storage Management snap-in,
Windows Server 2008 recognizes whether a disk has been designated as being in the cluster
storage. If such a disk has already been configured in Failover Cluster Management as part
of a clustered file server, you can then use any of the previously-mentioned interfaces to
create a share on the disk. If such a disk has not been configured as part of a clustered file
server, you cannot mistakenly create a share on it. Instead, an error indicates that the disk
must first be configured as part of a clustered file server before it can be shared.
• Integration of Services for Network File System: The File Server role in Windows
Server 2008 includes the optional role service called Services for Network File System (NFS).
By installing the role service and configuring shared folders with Services for NFS, you can
create a clustered file server that supports UNIX-based clients.
Improvements to networking and security

With failover clusters in Windows Server 2008, network performance and security are improved,
compared to previous releases. You can:
• Use IPv6, which is fully integrated into failover clusters. Failover clusters fully support
IPv6 for both node-to-node and node-to-client communication.
• Use Domain Name System (DNS) without legacy NetBIOS dependencies. This simplifies
the transport of server message block (SMB) traffic and means you do not have Windows
Internet Name Service (WINS) and NetBIOS name-resolution broadcasts.
• Achieve better reliability through other improvements to networking. Because of
improvements to networking, you can fine-tune the dependencies between a network name
and associated IP addresses so that the network name will be available if either (not both) of
the IP addresses is available. In addition, when nodes transmit and receive "heartbeats" to
confirm that each node is still available, they use Transmission Control Protocol (TCP) rather
than the less reliable User Datagram Protocol (UDP).
• Achieve enhanced security through security improvements and auditing of cluster
access. Security improvements in failover clusters enhance authentication and encryption. In
9
addition, you can use auditing to capture information about who accessed your cluster and
when.
• Place clustered servers on different subnets: You can now place clustered servers on
different IP subnets, which reduces the requirements for geographically dispersed clusters.
• Create additional security for intra-cluster communications: You now have the option
either to digitally sign or encrypt all intra-cluster communication. By default, intra-cluster
communication is digitally signed. Intra-cluster communication typically includes information
about changes to the cluster configuration or to the state of clustered resources.
Do I need to change any existing code to work

with Windows Server 2008?
If you have an application that ran in a server cluster running Windows Server 2003, and the
application depends on the Cluster service account that was required for server clusters, you
might need to change the application so that it no longer depends on the account. Failover
clusters running Windows Server 2008 do not use a separate Cluster service account.
How should I prepare to deploy this feature?

Carefully review the hardware on which you plan to deploy a failover cluster to ensure that it is
compatible with Windows Server 2008. This is especially necessary if you are currently using that
hardware for a server cluster running Windows Server 2003. Hardware that supports a server
cluster running Windows Server 2003 will not necessarily support a failover cluster running
Note
You cannot perform a rolling upgrade from a server cluster running Windows Server 2003
to a failover cluster running Windows Server 2008. However, after you create a failover
cluster running Windows Server 2008, you can use a wizard to migrate certain resource
settings to it from a server cluster running Windows Server 2003.
Is this feature available in all editions of Windows

Server 2008?
The failover cluster feature is available in Windows Server 2008 Enterprise and Windows
Server 2008 Datacenter. The feature is not available in Windows Web Server 2008 or Windows
10
What's New in Terminal Services for
Windows Server 2008
Authors: Daniel H. Brown, Tessa Wooley, and Connie Rock
Editor: Linda Caputo
Abstract
The Terminal Services component of Microsoft® Windows Server® 2008 provides technologies
that enable users to access Windows-based programs that are installed on a terminal server, or
to access the Windows desktop itself, from almost any computing device. Users can connect to a
terminal server to run programs and to use network resources on that server.
For Microsoft Windows Server 2008, Terminal Services includes new core functionality that
enhances the end-user experience.
1
Microsoft, MS-DOS, Windows, Windows NT, and Windows Server are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
2
Contents
What's New in Terminal Services for Windows Server 2008 .......................................................... 7
Terminal Services Core Functionality .............................................................................................. 7

Who will be interested in these features? .................................................................................... 8
Are there any special considerations about these features? ....................................................... 8
Remote Desktop Connection 6.1 .......................................................................................... 9
Additional references ................................................................................................................... 9
Remote Desktop Connection Display .............................................................................................. 9

Custom display resolutions .......................................................................................................... 9
Monitor spanning ........................................................................................................................ 10
Desktop Experience ................................................................................................................... 10
Font smoothing........................................................................................................................... 11
Display data prioritization ........................................................................................................... 12
Plug and Play Device Redirection for Media Players and Digital Cameras .................................. 13
Microsoft Point of Service for .NET Device Redirection ................................................................ 15

Configuring a terminal server .............................................................................................. 15
Configuring a Remote Desktop Protocol file ....................................................................... 16
Using redirected Microsoft POS for .NET devices .............................................................. 17
Single Sign-On for Terminal Services ........................................................................................... 17

What is single sign-on for Terminal Services? ........................................................................... 17
Key scenarios for single sign-on ................................................................................................ 18
Prerequisites for deploying single sign-on ................................................................................. 18
Recommended configuration of a terminal server when using single sign-on .......................... 18
Terminal Server Installation ........................................................................................................... 19

Installing the Terminal Server role service ................................................................................. 19
Installing programs ..................................................................................................................... 22
Configuring remote connection settings ..................................................................................... 22
Terminal Services Printing ............................................................................................................. 24

Are there any special considerations? ....................................................................................... 24
3
What new functionality does this feature provide?..................................................................... 25
What existing functionality is changing? .................................................................................... 25
How should I prepare for this change? ............................................................................... 25
What settings have been added or changed in Windows Server 2008? ................................... 26
Group Policy settings........................................................................................................... 26
Terminal Services RemoteApp (TS RemoteApp).......................................................................... 27

What does TS RemoteApp do? ................................................................................................. 27
Who will be interested in this feature? ....................................................................................... 28
Ability to run programs remotely ............................................................................................. 29
Why is this functionality important? ..................................................................................... 29
What works differently? ....................................................................................................... 29
Do I need to change any existing code? .................................................................................... 29
Terminal Services Web Access (TS Web Access)........................................................................ 30

What does TS Web Access do? ................................................................................................ 30
What new functionality does this feature provided?................................................................... 31
Lets you easily deploy RemoteApp programs over the Web ................................................. 31
List of RemoteApp programs is dynamically updated ............................................................ 32
Includes the TS Web Access Web Part .................................................................................. 33
Includes Remote Desktop Web Connection ........................................................................... 34
Terminal Services Licensing (TS Licensing) ................................................................................. 34
4
What does TS Licensing do? ..................................................................................................... 35
Who will be interested in TS Licensing? .................................................................................... 35
What new functionality is provided by TS Licensing? ................................................................ 36
How should I prepare to use TS Licensing? .............................................................................. 36
Are there any special considerations about TS Licensing? ....................................................... 36
Terminal Services Gateway (TS Gateway) ................................................................................... 37

What does TS Gateway do? ...................................................................................................... 37
How should I prepare for TS Gateway? ..................................................................................... 41
TS CAPs ................................................................................................................................. 41
Why are TS CAPs important? ............................................................................................. 42
TS RAPs ................................................................................................................................. 42
Security groups and TS Gateway-managed computer groups associated with TS RAPs ..... 43
Monitoring capabilities ............................................................................................................ 44
Group Policy settings for TS Gateway .................................................................................... 44
Do I need to change any existing code? .................................................................................... 45
Terminal Services Session Broker (TS Session Broker) ............................................................... 46

What settings have been added or changed? ........................................................................... 48
Group Policy settings........................................................................................................... 48
Terminal Services and Windows System Resource Manager ...................................................... 49

Prerequisites for Using WSRM with Terminal Services ............................................................. 49
Installing Terminal Server ....................................................................................................... 49
Installing WSRM ..................................................................................................................... 49
Configuring WSRM for Terminal Services ................................................................................. 50
Windows System Resource Manager Snap-In ....................................................................... 50
Resource-Allocation Policies .................................................................................................. 50
Monitoring Performance ......................................................................................................... 51
5
What's New in Terminal Services for
Windows Server 2008
The Terminal Services component of Windows Server® 2008 provides technologies that enable
users to access Windows-based programs that are installed on a terminal server, or to access the
Windows desktop itself, from almost any computing device. Users can connect to a terminal
server to run programs and to use network resources on that server.
The following topics describe changes in Terminal Services functionality that are available in this
release:
• Terminal Services Core Functionality
• Remote Desktop Connection Display
• Plug and Play Device Redirection for Media Players and Digital Cameras
• Microsoft Point of Service for .NET Device Redirection
• Single Sign-On for Terminal Services
• Terminal Server Installation
• Terminal Services Printing
• Terminal Services RemoteApp (TS RemoteApp)
• Terminal Services Web Access (TS Web Access)
• Terminal Services Licensing (TS Licensing)
• Terminal Services Gateway (TS Gateway)
• Terminal Services Session Broker (TS Session Broker)
• Terminal Services and Windows System Resource Manager
Terminal Services Core Functionality

For Windows Server 2008, Terminal Services includes new core functionality that enhances the
end-user experience when connecting remotely to a Windows Server 2008 terminal server. This
new core functionality includes:
• Remote Desktop Connection 6.1
• Remote Desktop Connection Display improvements, including:
• Custom display resolutions
• Monitor spanning
• Desktop Experience
7
• Font smoothing
• Display data prioritization
• Plug and Play Device Redirection for Media Players and Digital Cameras
• Microsoft Point of Service for .NET Device Redirection
• Single Sign-On for Terminal Services
Who will be interested in these features?

The new core functionality in Terminal Services will be of interest to organizations that currently
use or are interested in using Terminal Services. Terminal Services provides technologies that
enable access, from almost any computing device, to a server running Windows-based programs
or the full Windows desktop. Users can connect to a terminal server to run programs and use
network resources on that server.
For Windows Server 2008, you might be interested in the new core functionality in Terminal
Services if you use any of the following hardware:
• Monitors that support higher resolutions, such as 1680 x 1050 or 1920 x 1200
• Multiple monitors
• Windows Portable Devices
• Microsoft Point of Service for .NET devices
You also might be interested in the new core functionality in Terminal Services if you want to
support any of the following scenarios:
• Have users connect to a terminal server and have the remote computer look and feel more
like the user's local Windows Vista® desktop experience.
• Ensure that display, keyboard, and mouse data passed over a remote connection is not
adversely affected by bandwidth intensive actions, such as large print jobs.
• Allow users with a domain account to log on once, using a password or smart card, and then
gain access to a terminal server without being asked for their credentials again.
Are there any special considerations about these

features?
In order to take advantage of the new Terminal Services core functionality, you will need to use
the following:
• Remote Desktop Connection (RDC) 6.0 or RDC 6.1
• Windows Server 2008 configured as a terminal server
In some cases, you will also need to use Windows Vista.
8
Remote Desktop Connection 6.1
Remote Desktop Connection (RDC) 6.1 is available with Windows Server 2008. RDC 6.1
supports Remote Desktop Protocol 6.1.
Remote Desktop Connection (RDC) 6.0 is available with Windows Vista.
The RDC 6.0 software is also available for use on Windows Server® 2003 with Service Pack 1
(SP1), Windows Server 2003 with Service Pack 2 (SP2), and Windows® XP with SP2. To use
any new Terminal Services features on any of these platforms, download the installer package
from article 925876 in the Microsoft Knowledge Base
For information about other new features in Terminal Services, see What's New in Terminal
Services for Windows Server 2008.
Remote Desktop Connection Display

Remote Desktop Connection (RDC) 6.0 and RDC 6.1 add support for using higher-resolution
desktops and spanning multiple monitors horizontally to form a single large desktop. Also, the
Desktop Experience feature and the display data prioritization settings are designed to enhance
the end-user experience when connecting remotely to a Windows Server 2008 terminal server.
Custom display resolutions

Custom display resolution provides support for additional display resolution ratios, such as 16:9
or 16:10. For example, newer monitors with resolutions of 1680 x 1050 or 1920 x 1200 are now
supported. The maximum resolution supported is 4096 x 2048.
Note
Previously, only 4:3 display resolution ratios were supported, and the maximum
resolution supported was 1600 x 1200.
You can set a custom display resolution in an .rdp file or from a command prompt.
To set a custom display resolution in an .rdp file

• Open the .rdp file in a text editor. Add or change the following settings:
desktopwidth:i:<value>
desktopheight:i:<value>
where <value> is the resolution, such as 1680 or 1050.
9
For more information about .rdp file settings, see article 885187 in the Microsoft Knowledge
Base (http://go.microsoft.com/fwlink/?linkid=66168).
To set a custom display resolution from a command prompt

• At a command prompt, use the mstsc.exe command with the following syntax, and then
press ENTER.
mstsc.exe /w:<width> /h:<height>
Monitor spanning
Monitor spanning allows you to display your remote desktop session across multiple monitors.
The monitors used for monitor spanning must meet the following requirements:
• All monitors must use the same resolution. For example, two monitors using 1024 x 768
resolution can be spanned. But one monitor at 1024 x 768 and one monitor at 800 x 600
cannot be spanned.
• All monitors must be aligned horizontally (that is, side by side). There is currently no support
for spanning multiple monitors vertically on the client system.
• The total resolution across all monitors cannot exceed 4096 x 2048.
You can enable monitor spanning in an .rdp file or from a command prompt.
To enable monitor spanning in an .rdp file

• Open the .rdp file in a text editor. Add or change the following setting:
Span:i:<value>
• If <value> = 0, monitor spanning is disabled.
• If <value> = 1, monitor spanning is enabled.
To enable monitor spanning from a command prompt

• At a command prompt, type the following command, and then press ENTER.
mstsc.exe /span
Desktop Experience
Remote Desktop Connection (RDC) 6.0 and RDC 6.1 reproduce the desktop that exists on the
remote computer on the user’s client computer. To make the remote computer look and feel more
like the user's local Windows Vista desktop experience, you can install the Desktop Experience
10
feature on your Windows Server 2008 terminal server. Desktop Experience installs features of
Windows Vista, such as Windows Media® Player 11, desktop themes, and photo management.
To install Desktop Experience on your terminal server

1. Open Server Manager. Click Start, point to Administrative Tools, and then click Server
Manager.
2. Under Features Summary, click Add features.
3. On the Select Features page, select the Desktop Experience check box, and then click
Next.
4. On the Confirm Installation Selections page, verify that the Desktop Experience
feature will be installed, and then click Install.
5. On the Installation Results page, you are prompted to restart the server to finish the
installation process. Click Close, and then click Yes to restart the server.
6. After the server restarts, confirm that Desktop Experience is installed.
a. Start Server Manager.
b. Under Features Summary, confirm that Desktop Experience is listed as installed.
Font smoothing
Windows Server 2008 supports ClearType®, which is a technology for displaying computer fonts
so that they appear clear and smooth, especially when you are using an LCD monitor.
A Windows Server 2008 terminal server can be configured to provide ClearType functionality
when a client computer connects to the Windows Server 2008 terminal server by using Remote
Desktop Connection. This functionality is referred to as font smoothing. Font smoothing is
available if the client computer is running any of the following:
• Windows Vista
• Windows Server 2003 with SP1 or SP2 and the Remote Desktop Connection 6.0 software
• Windows XP with SP2 and the Remote Desktop Connection 6.0 software
By default, ClearType is enabled on Windows Server 2008. To ensure that ClearType is enabled
on the Windows Server 2008 terminal server, follow this procedure.
To ensure that ClearType is enabled

1. Click Start, click Control Panel, and then click Appearance and Personalization.
2. Click Personalization, and then click Window Color and Appearance.
3. On the Appearance tab, click Effects. Select the Use the following method to smooth
edges of screen fonts check box, select ClearType, and then click OK.
11
To make font smoothing available for a remote desktop connection, follow this procedure on the
client computer.
To make font smoothing available

1. Open Remote Desktop Connection. To open Remote Desktop Connection on
Windows Vista, click Start, point to All Programs, click Accessories, and then click
Remote Desktop Connection.
2. In the Remote Desktop Connection dialog box, click Options.
3. On the Experience tab, select the Font smoothing check box.
4. Configure any remaining connection settings, and then click Connect.
When you allow font smoothing, you are specifying that the local settings on the client computer
will help determine the user experience in the remote desktop connection. Note that by allowing
font smoothing, you are not changing the settings on the Windows Server 2008 terminal server.
Using font smoothing in a remote desktop connection will increase the amount of bandwidth used
between the client computer and the Windows Server 2008 terminal server.
Display data prioritization

Display data prioritization automatically controls virtual channel traffic so that display, keyboard,
and mouse data is given a higher priority over other virtual channel traffic, such as printing or file
transfers. This prioritization is designed to ensure that your screen performance is not adversely
affected by bandwidth intensive actions, such as large print jobs.
The default bandwidth ratio is 70:30. Display and input data will be allocated 70 percent of the
bandwidth, and all other traffic, such as clipboard, file transfers, or print jobs, will be allocated 30
percent of the bandwidth.
You can adjust the display data prioritization settings by making changes to the registry of the
terminal server. You can change the value of the following entries under the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermDD subkey:
• FlowControlDisable
• FlowControlDisplayBandwidth
• FlowControlChannelBandwidth
• FlowControlChargePostCompression
If these entries do not appear, you can add them. To do this, right-click TermDD, point to New,
and then click DWORD (32-bit) Value.
You can disable display data prioritization by setting the value of FlowControlDisable to 1. If
display data prioritization is disabled, all requests are handled on a first-in-first-out basis. The
default value for FlowControlDisable is 0.
12
You can set the relative bandwidth priority for display (and input data) by setting the
FlowControlDisplayBandwidth value. The default value is 70; the maximum value allowed is 255.
You can set the relative bandwidth priority for other virtual channels (such as clipboard, file
transfers, or print jobs) by setting the FlowControlChannelBandwidth value. The default value is
30; the maximum value allowed is 255.
The bandwidth ratio for display data prioritization is based on the values of
FlowControlDisplayBandwidth and FlowControlChannelBandwidth. For example, if
FlowControlDisplayBandwidth is set to 150 and FlowControlChannelBandwidth is set to 50, the
ratio is 150:50, so display and input data will be allocated 75 percent of the bandwidth.
The FlowControlChargePostCompression value determines if flow control will calculate the
bandwidth allocation based on pre-compression or post-compression bytes. The default value is
0, which means that the calculation will be made on pre-compression bytes.
If you make any changes to the registry values, you need to restart the terminal server for the
changes to take effect.
Plug and Play Device Redirection for Media

Players and Digital Cameras
In Windows Server 2008 redirection has been enhanced and expanded. Now you can redirect
Windows Portable Devices, specifically media players based on the Media Transfer Protocol
(MTP) and digital cameras based on the Picture Transfer Protocol (PTP).
To redirect Plug and Play devices

1. Open Remote Desktop Connection. To open Remote Desktop Connection on
Windows Vista, click Start, point to All Programs, click Accessories, and then click
Remote Desktop Connection.
2. In the Remote Desktop Connection dialog box, click Options.
3. On the Local Resources tab, click More.
4. Under Local devices and resources, expand Supported Plug and Play devices.
Plug and Play devices that are currently plugged in and that are supported for redirection
will show up in this list. If the device that you have plugged in does not show up in the list,
the device is currently not supported for redirection. Check the device manual to see if
13
the device supports MTP or PTP.
5. Choose the device that you want to redirect by selecting the check box next to the
device's name.
6. You can also redirect devices that have not been plugged in yet but will be plugged in
later when a session to a remote computer is active. To make Plug and Play devices that
you will plug in later available for redirection, select the Devices that I plug in later
check box.
Note
You can also redirect drives that will be connected after a session to a remote
computer is active. To make a drive that you will connect to later available for
redirection, expand Drives, and then select the Drives that I connect to later
check box.
7. Click OK and proceed to connect to the remote computer.
Note
The Remote Desktop Protocol (.rdp) file created by the RemoteApp Wizard automatically
enables Plug and Play device redirection. For more information about RemoteApps, see
the TS RemoteApp Step-by-Step Guide on the TS RemoteApp & TS Web Access page
on the Windows Server 2008 TechCenter (http://go.microsoft.com/fwlink/?LinkId=79609).
When the session to the remote computer is launched, you should see the Plug and Play device
that is redirected get automatically installed on the remote computer. Plug and Play notifications
will appear in the taskbar on the remote computer.
If you have selected the Devices that I plug in later check box in Remote Desktop Connection,
you should see the Plug and Play device get installed on the remote computer when you plug the
Plug and Play device into your local computer while the session to the remote computer is active.
After the redirected Plug and Play device is installed on the remote computer, the Plug and Play
device is available for use in your session with the remote computer. For example, if you are
redirecting a Windows Portable Device such as a digital camera, the device can be accessed
directly from an application such as the Scanner and Camera Wizard on the remote computer.
Note
Plug and Play device redirection is not supported over cascaded terminal server
connections. For example, if you have a Plug and Play device attached to your local
client computer, you can redirect and use that Plug and Play device when you connect to
a terminal server (Server1, for example). If from within your remote session on Server1,
you then connect to another terminal server (Server2, for example), you will not be able
to redirect and use the Plug and Play device in your remote session with Server2.
You can control Plug and Play device redirection by using either of the following Group Policy
settings:
14
• Do not allow supported Plug and Play device redirection located in Computer
Configuration\Administrative Templates\Windows Components\Terminal
Services\Terminal Server\Device and Resource Redirection
• The policy settings located in Computer Configuration\Administrative
Templates\System\Device Installation\Device Installation Restrictions
You can also control Plug and Play device redirection on the Client Settings tab in the Terminal
Services Configuration tool (tsconfig.msc) by using the Supported Plug and Play Devices
check box.
Microsoft Point of Service for .NET Device

Redirection
In Windows Server 2008 you can also redirect devices that use Microsoft Point of Service (POS)
for .NET 1.11.
Important
Microsoft POS for .NET device redirection is only supported if the terminal server is
running an x86-based version of Windows Server 2008.
You can download Microsoft POS for .NET 1.11 from the Microsoft Download Center
(http://go.microsoft.com/fwlink/?linkid=66169).
Configuring a terminal server
To implement Microsoft POS for .NET 1.11 on your terminal server

1. Install Microsoft POS for .NET 1.11.
2. Install the .NET service objects or configuration XML files for the Microsoft POS for .NET
device. The device service objects or configuration XML files are usually provided by the
device vendor and are written to work with POS for .NET by using the Microsoft POS for
.NET 1.11 Software Development Kit (SDK). You can install the device service objects or
configuration XML files through the standard installation software that accompanies the
device. For installation instructions for the specific Microsoft POS for .NET device that
you are using, consult the device’s manual.
3. After you install the device service objects or configuration XML files for all the Microsoft
15
POS for .NET devices that you are supporting on the terminal server, you need to stop
and start the Terminal Services UserMode Port Redirector service. To restart the
Terminal Services UserMode Port Redirector service, follow these steps:
a. Open the Services snap-in. To open the Services snap-in, click Start, point to
Administrative Tools, and then click Services.
b. In the Services dialog box, in the Name column, right-click Terminal Services
UserMode Port Redirector, and then click Restart.
Note
Restart the Terminal Services UserMode Port Redirector service only after you have
installed the device server objects or configuration XML files for all the Microsoft POS
for .NET devices that you are supporting on the terminal server. If you later install a
new device server object or configuration XML file on your terminal server for a
Microsoft POS for .NET device, you will need to restart the Terminal Services
UserMode Port Redirector service.
Configuring a Remote Desktop Protocol file

Microsoft POS for .NET devices, by default, are not listed under Local devices and resources
on the Local Resources tab in Remote Desktop Connection. Therefore, to enable Microsoft POS
for .NET devices for redirection, you need to edit the Remote Desktop Protocol (.rdp) file that you
use to connect to the terminal server.
To enable Microsoft POS for .NET device redirection in an .rdp file

• Open the .rdp file in a text editor. Add or change the following setting:
redirectposdevices:i:<value>
• If <value> = 0, Microsoft POS for .NET device redirection is disabled.
• If <value> = 1, Microsoft POS for .NET device redirection is enabled.
Note
The .rdp file created created by the RemoteApp Wizard automatically enables Plug and
Play device redirection. For more information about RemoteApps, see the
TS RemoteApp Step-by-Step Guide on the TS RemoteApp & TS Web Access page on
the Windows Server 2008 TechCenter (http://go.microsoft.com/fwlink/?LinkId=79609).
16
Using redirected Microsoft POS for .NET devices
After you have implemented Microsoft POS for .NET 1.11 on your terminal server and have
enabled Microsoft POS for .NET device redirection in your .rdp file, plug in your Microsoft POS for
.NET device and then connect to the remote computer by using the modified .rdp file. After you
connect to the remote computer, you should see the Microsoft POS for .NET device that is
redirected get automatically installed on the remote computer. Plug and Play notifications will
appear in the taskbar on the remote computer.
After the redirected Microsoft POS for .NET device is installed on the remote computer, any
Microsoft POS for .NET application residing on the terminal server can access the Microsoft POS
for .NET device as if the device were available locally. There is a sample application in the POS
for .NET 1.11 SDK that you can use to test access to and the functionality of the redirected
Microsoft POS for .NET device. The sample application is called ccltestapp.exe and can be
found in the \SDK\Samples\Sample Application folder in the folder where you installed POS for
.NET.
You can control Microsoft POS for .NET device redirection by using either of the following Group
Policy settings:
• Do not allow supported Plug and Play device redirection located in Computer
Configuration\Administrative Templates\Windows Components\Terminal
Services\Terminal Server\Device and Resource Redirection
• The policy settings located in Computer Configuration\Administrative
Templates\System\Device Installation\Device Installation Restrictions
You can also control Microsoft POS for .NET device redirection on the Client Settings tab in the
Terminal Services Configuration tool (tsconfig.msc) by using the Supported Plug and Play
Devices check box.
Single Sign-On for Terminal Services
What is single sign-on for Terminal Services?

Single sign-on is an authentication method that allows a user with a domain account to log on
once, using a password or smart card, and then gain access to remote servers without being
asked for their credentials again.
17
Key scenarios for single sign-on
The key scenarios for single sign-on are:
• Line-of-business (LOB) applications deployment
• Centralized application deployment
Due to lower maintenance costs, many companies prefer to install their LOB applications on a
terminal server and make these applications available through RemoteApps or Remote Desktop.
Single sign-on makes it possible to give users a better experience by eliminating the need for
users to enter credentials every time they initiate a remote session.
Prerequisites for deploying single sign-on

To implement single sign-on functionality in Terminal Services, ensure that you meet the following
requirements:
• You can only use single sign-on for remote connections from a Windows Vista®-based
computer to a Windows Server® 2008-based terminal server. You can also use single sign-
on for remote connections from a Windows Server 2008-based server to a Windows
Server 2008-based server.
• Make sure that the user accounts that are used for logging on have appropriate rights to log
on to both the terminal server and the Windows Vista client.
• Your client computer and terminal server must be joined to a domain.
Recommended configuration of a terminal server

when using single sign-on
To configure the recommended settings for your terminal server, complete the following steps:
• Configure authentication on the terminal server.
• Configure the Windows Vista-based computer to allow default credentials to be used for
logging on to the specified terminal servers.
To configure authentication on the server

1. Open Terminal Services Configuration. To open Terminal Services Configuration, click
Start, click Run, type tsconfig.msc and then click OK.
2. Under Connections, right-click RDP-Tcp, and then click Properties.
3. In the Properties dialog box, on the General tab, verify that the Security Layer value is
either Negotiate or SSL (TLS 1.0), and then click OK.
18
To allow default credential usage for single sign-on
1. On the Windows Vista-based computer, open the Local Group Policy Editor. To open
Local Group Policy Editor, click Start, and in the Start Search box, type gpedit.msc and
then press ENTER.
2. In the left pane, expand the following: Computer Configuration, Administrative
Templates, System, and then click Credentials Delegation.
3. Double-click Allow Delegating Default Credentials.
4. In the Properties dialog box, on the Setting tab, click Enabled, and then click Show.
5. In the Show Contents dialog box, click Add to add servers to the list.
6. In the Add Item dialog box, in the Enter the item to be added box, type the prefix
termsrv/ followed by the name of the terminal server; for example, termsrv/Server1, and
then click OK.
Terminal Server Installation

The Terminal Server role service, known as the Terminal Server component in Windows
Server® 2003, enables a Windows Server® 2008-based server to host Windows®-based
programs or the full Windows desktop. From their own computing devices, users can connect to a
terminal server to run programs and to use network resources on that server.
In Windows Server 2008, you must do the following to install the Terminal Server role service,
and to configure the terminal server to host programs:
1. Use Server Manager to install the Terminal Server role service.
2. Install programs on the server.
3. Configure remote connection settings. This includes adding users and groups that need to
connect to the terminal server.
Installing the Terminal Server role service

You can use the following procedure to use Server Manager to install the Terminal Server role
service on the computer. This procedure assumes that no other Terminal Services role services
(for example, TS Gateway, TS Licensing) have been installed on the computer. If Terminal
19
Services is already installed on the server, use the "To install the Terminal Server role server
when Terminal Services is already installed" procedure.
Membership in the local Administrators group, or equivalent, on the terminal server that you
plan to configure, is the minimum required to complete this procedure.
To install the Terminal Server role service

1. Open Server Manager. To open Server Manager, click Start, point to Administrative
Tools, and then click Server Manager.
2. Under Roles Summary, click Add roles.
3. In the Add Roles Wizard, on the Before You Begin page, click Next.
4. On the Select Server Roles page, under Roles, select the Terminal Services check
box.
Note
If Terminal Services is already installed on the server, the Terminal Services
check box will be selected and dimmed.
5. Click Next.
6. On the Terminal Services page, click Next.
7. On the Select Role Services page, select the Terminal Server check box, and then
click Next.
If you are installing the Terminal Server role service on a domain controller, you will
receive a warning dialog box. Installing the Terminal Server role service on a domain
controller is not recommended.
8. On the Uninstall and Reinstall Applications for Compatibility page, click Next.
9. On the Specify Authentication Method for Terminal Server page, select the
appropriate authentication method for the terminal server, and then click Next.
10. On the Specify Licensing Mode page, select the appropriate licensing mode for the
terminal server, and then click Next.
11. On the Select User Groups Allowed Access To This Terminal Server page, add the
users or user groups that you want to be able to remotely connect to this terminal server,
12. On the Confirm Installation Selections page, verify that the Terminal Server role
service will be installed, and then click Install.
14. If you are prompted that other programs are still running, do either of the following:
• To close the programs manually and restart the server later, click Cancel.
20
• To automatically close the programs and restart the server, click Restart now.
15. After the server restarts and you log on to the computer, the Installation Results page
will appear. Confirm that the installation of Terminal Server succeeded.
You can also confirm that Terminal Server is installed by following these steps:
b. Under Roles Summary, click Terminal Services.
c. Under System Services, confirm that Terminal Services has a status of Running.
d. Under Role Services, confirm that Terminal Server has a status of Installed.
You can use the following procedure to install the Terminal Server role service when Terminal
Services is already installed on the computer.
Membership in the local Administrators group, or equivalent, on the terminal server that you
plan to configure, is the minimum required to complete this procedure
To install the Terminal Server role service when Terminal Services is already installed
2. In the left pane, expand Roles.
3. Right-click Terminal Services and then click Add Role Services.
click Next.
If you are installing the Terminal Server role service on a domain controller, you will
receive a warning dialog box. Installing the Terminal Server role service on a domain
controller is not recommended.
5. On the Uninstall and Reinstall Applications for Compatibility page, click Next.
6. On the Specify Authentication Method for Terminal Server page, select the
appropriate authentication method for the terminal server, and then click Next.
7. On the Specify Licensing Mode page, select the appropriate licensing mode for the
terminal server, and then click Next.
8. On the Select User Groups Allowed Access To This Terminal Server page, add the
users or user groups that you want to be able to remotely connect to this terminal server,
11. If you are prompted that other programs are still running, do either of the following:
21
• To close the programs manually and restart the server later, click Cancel.
• To automatically close the programs and restart the server, click Restart now.
12. After the server restarts and you log on to the computer, the Installation Results page
will appear. Confirm that the installation of Terminal Server succeeded.
You can also confirm that Terminal Server is installed by following these steps:
b. Under Roles Summary, click Terminal Services.
c. Under SystemServices, confirm that Terminal Services has a status of Running.
d. Under Role Services, confirm that Terminal Server has a status of Installed.
Installing programs
Install programs on the terminal server after you have installed the Terminal Server role service. If
you install the Terminal Server role service on a computer that already has programs installed,
some of the existing programs may not work correctly in a multiple user environment.
Some programs may require minor setup modifications to run correctly on a terminal server.
Before you install a program on the terminal server, type change user /install at the command
prompt to place the system in install mode. After the program is installed, type change user
/execute at the command prompt to return the system to execute mode.
Note
If you install a program from an .msi package, you do not have to run these commands to
switch the system in and out of install mode. Instead, you can run the .msi package or
associated Setup file directly.
If you have programs that are related to each other or have dependencies on each other, we
recommend that you install the programs on the same terminal server. For example, we
recommend that you install Microsoft Office as a suite instead of installing individual Office
programs on separate terminal servers.
You should consider putting individual programs on separate terminal servers in the following
circumstances:
• The program has compatibility issues that may affect other programs.
• A single program and the number of associated users may fill server capacity.
Configuring remote connection settings

By default, remote connections are enabled after you install the Terminal Server role service. You
can use the following procedure to add users and groups that need to connect to the terminal
server, and to verify or to change remote connection settings.
22
Note
To perform this procedure, you must be a member of the Administrators group on the
terminal server.
To configure remote connection settings

1. Start the System tool. To start the System tool, use either of the following methods:
• Click Start, and then click Control Panel. In Control Panel, double-click System.
• Click Start, click Run, type control system and then click OK.
2. Under Tasks, click Remote Settings.
3. In the System Properties dialog box, on the Remote tab, click either of the following,
depending on your environment:
• Allow connections from computers running any version of Remote
Desktop By default, this option is enabled. Use this option if users will access the
terminal server from any client computers that are running a version of the RDC client
that does not support Network Level Authentication.
• Allow connections only from computers running Remote Desktop with Network
Level Authentication Use this option if all client computers that will access the
terminal server are running a version of the RDC client that supports Network Level
Authentication. If a client that does not support Network Level Authentication tries to
connect, they will receive an authentication error message.
For more information about the two options, click the Help me choose link on the
Remote tab.
4. Click Select Users to add the users and groups that need to connect to the terminal
server by using Remote Desktop. The users and groups that you add are added to the
Remote Desktop Users group.
Members of the local Administrators group can connect even if they are not listed.
If you select Don't allow connections to this computer on the Remote tab, no users
will be able to connect remotely to this computer, even if they are members of the
Remote Desktop Users group.
To determine whether a computer is running a version of the RDC client that supports Network
Level Authentication, start the RDC client, click the icon in the upper-left corner of the Remote
Desktop Connection dialog box, and then click About. Look for the phrase "Network Level
Authentication supported" in the About Remote Desktop Connection dialog box.
23
Terminal Services Printing
Terminal Services printing has been enhanced in Windows Server® 2008 by the addition of the
Terminal Services Easy Print printer driver and a Group Policy setting that enables you to redirect
only the default client printer.
The Terminal Services Easy Print driver is a feature in Windows Server 2008 that enables users
to reliably print from a Terminal Services RemoteApp™ program or from a terminal server
desktop session to the correct printer on their client computer. It also enables users to have a
much more consistent printing experience between local and remote sessions.
The Redirect only the default client printer policy setting allows you to specify whether the
default client printer is the only printer that is redirected in Terminal Services sessions. This helps
to limit the number of printers that the spooler must enumerate, therefore improving terminal
server scalability.

To use the Terminal Services Easy Print driver, clients must be running both of the following:
• Remote Desktop Connection (RDC) 6.1
Note
The RDC 6.1 client supports Remote Desktop Protocol 6.1.
• Microsoft .NET Framework 3.0 Service Pack 1 (SP1)
At the time of the Windows Server 2008 RC0 release, client support is limited to Windows
Server 2008 and Windows Vista with Service Pack 1 (SP1) Beta. Windows Server 2008 and
Windows Vista with SP1 Beta include both of the required components.
To test the Terminal Services Easy Print driver on a Windows Server 2008-based server (that is
acting as the client), you must first add .NET Framework 3.0 SP1. To do this, you can use either
of the following methods:
To add .NET Framework 3.0 SP1 by using the Server Manager user interface
1. Start Server Manager. To open Server Manager, click Start, point to Administrative
2. In the left pane of Server Manager, right-click Features, and then click Add Features.
3. On the Select Features page, expand .NET Framework 3.0.
4. Select the .NET Framework 3.0 Features and the XPS Viewer check boxes, and then
click Next.
5. Click Install.
24
To add .NET Framework 3.0 SP1 by using the command line
1. Start the command prompt with elevated privileges. To do this, click Start, right-click
Command Prompt, and then click Run as administrator.
pkgmgr.exe /iu:NetFx3
The installation occurs silently, and may take several minutes.
What new functionality does this feature provide?

The Terminal Services Easy Print driver offers the following functionality:
• Increased reliability of Terminal Services printing for both RemoteApp and remote desktop
sessions.
• Support for legacy and new printer drivers without the necessity of installing these drivers on
the terminal server.
• Scalability improvements over Windows Server 2003 in terms of printer enumeration
performance. During the Winlogon process, the spooler only enumerates printers that are
available for a user in a particular session instead of enumerating all redirected printers.
Therefore, printers are enumerated on a per-session basis, instead of on a per-user basis.
• Enhanced available printer capabilities. The Terminal Services Easy Print driver provides rich
and complete printer capabilities in remote sessions. All of the physical printer driver's
capabilities are available for use when a user views the printing preferences.
The Redirect only the default client printer Group Policy setting allows you to control whether
the default client printer is the only printer redirected in a Terminal Services session, or whether
all printers are redirected in a session.
What existing functionality is changing?

The terminal server fallback printer driver is not included with Windows Server 2008. Although the
Specify terminal server fallback printer driver behavior Group Policy setting still exists, it can
only be used for Windows Server 2003 with SP1-based computers.
How should I prepare for this change?

By default, the Terminal Services Easy Print driver is enabled in Windows Server 2008. To use
the Terminal Services Easy Print driver, client computers must meet the requirements that are
outlined in the "Are there any special considerations about these features" section.
If there are client computers that do not support the Terminal Services Easy Print driver, and the
printer driver is not already available on the terminal server, you must do either of the following to
support client printing:
25
• Ensure that client printer drivers for both local and network printers are installed on the
terminal server. If you are installing a third-party driver, make sure that the driver is a
Windows Hardware Quality Labs (WHQL) signed driver.
• Add the client printer drivers for both local and network printers to a custom printer mapping
file on the terminal server. For more information about how to create a custom printer
mapping file, see the "Resolution" section of article 239088 in the Microsoft Knowledge Base
What settings have been added or changed in

Windows Server 2008?
Group Policy settings
The following Group Policy settings have been added for Terminal Services printing:
• Use Terminal Services Easy Print printer driver first
This policy setting is located in the following node of the Local Group Policy Editor:
Computer Configuration\Administrative Templates\Windows Components\Terminal
Services\Terminal Server\Printer Redirection
The possible values are:
• Enabled or Not configured: If this policy setting is enabled or not configured, the
terminal server will first try to use the Terminal Services Easy Print driver to install all
client printers. If for any reason the Terminal Services Easy Print driver cannot be used, a
printer driver on the terminal server that matches the client printer will be used. If the
terminal server does not have a printer driver that matches the client printer, the client
printer will not be available for the Terminal Services session. By default, this policy
setting is not configured.
• Disabled: If you disable this policy setting, the terminal server will try to find a suitable
printer driver to install the client printer. If the terminal server does not have a printer
driver that matches the client printer, the server will try to use the Terminal Services
Easy Print driver to install the client printer. If for any reason the Terminal Services
Easy Print driver cannot be used, the client printer will not be available for the Terminal
Services session.
• Redirect only the default client printer
This policy setting is located in the following node of the Local Group Policy Editor:
Services\Terminal Server\Printer Redirection
26
• Enabled: If you enable this policy setting, only the default client printer is redirected in
Terminal Services sessions.
• Disabled or Not configured: If you disable or do not configure this policy setting, all
client printers are redirected in Terminal Services sessions. By default, this policy setting
is not configured.
Terminal Services RemoteApp (TS

RemoteApp)
Terminal Services RemoteApp™ (TS RemoteApp) enables organizations to provide access to
standard Windows®-based programs from virtually any location to users of any Windows Vista®–
based or Windows Server® 2008–based computer, or to users of Windows XP with Service
Pack 2 (SP2)–based or Windows Server 2003 with Service Pack 1 (SP1)–based computers that
have the new Remote Desktop Connection (RDC) client installed.
TS RemoteApp is installed as part of the Terminal Server role service in Windows Server 2008.
What does TS RemoteApp do?

RemoteApp programs are programs that are accessed remotely through Terminal Services and
appear as if they are running on the end user's local computer. Users can run RemoteApp
programs side by side with their local programs. A user can minimize, maximize, and resize the
program window, and can easily start multiple programs at the same time. If a user is running
more than one RemoteApp program on the same terminal server, the RemoteApp programs will
share the same Terminal Services session.
Users can run RemoteApp programs in a number of ways. They can:
1. Double-click a Remote Desktop Protocol (.rdp) file that has been created and distributed by
their administrator.
2. Double-click a program icon on their desktop or Start menu that has been created and
distributed by their administrator with a Windows Installer (.msi) package.
3. Double-click a file whose extension is associated with a RemoteApp program. (This can be
configured by their administrator with a Windows Installer package.)
27
4. Access a link to the RemoteApp program on a Web site by using Terminal Services Web
Access (TS Web Access).
The .rdp files and Windows Installer packages contain the settings needed to run RemoteApp
programs. After opening the RemoteApp program on a local computer, the user can interact with
the program that is running on the terminal server as if it were running locally.
Who will be interested in this feature?

TS RemoteApp can reduce complexity and reduce administrative overhead in many situations,
including:
• Branch offices, where there may be limited local IT support and limited network bandwidth.
• Situations where users need to access applications remotely.
• Deployment of line-of-business (LOB) applications, especially custom LOB applications.
• Environments, such as "hot desk" or "hoteling" workspaces, where users do not have
assigned computers.
• Deployment of multiple versions of an application, particularly if installing multiple versions
locally would cause conflicts.
You should review this topic, and the additional supporting documentation on TS RemoteApp, if
you are in any of the following groups:
• IT planners and analysts who are technically evaluating the product.
• Enterprise architects.
• IT professionals who deploy or administer terminal servers, LOB applications, or applications
that can be more efficiently deployed with TS RemoteApp.

To access RemoteApp programs that are deployed as .rdp files or as Windows Installer
packages, the client computer must be running Remote Desktop Connection (RDC) 6.0 or
RDC 6.1. (RDC 6.1 supports Remote Desktop Protocol 6.1.) A supported version of the RDC
client is included with Windows Vista and Windows Server 2008.
Note
The RDC version 6.0 software is available for use on Windows XP with SP2 and
Windows Server 2003 with SP1. You can download the installer package from article
925876 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=79373).
To access RemoteApp programs through TS Web Access, the client computer must be running
RDC 6.1. RDC 6.1 is included with Windows Server 2008 and Windows Vista Service Pack 1
(SP1) Beta.
28
Ability to run programs remotely
Users can run programs from a terminal server and have the same experience as if the programs
were running on the end user's local computer, including resizable windows, drag-and-drop
support between multiple monitors, and notification icons in the notification area.
Why is this functionality important?

TS RemoteApp improves the user's experience, opens new avenues for program deployment,
and reduces the amount of administrative effort required to support these programs.
What works differently?

Instead of being presented to the user in the desktop of the remote terminal server, the
RemoteApp program is integrated with the client's desktop, running in its own resizable window
with its own entry in the taskbar. If the program uses a notification area icon, this icon appears in
the client's notification area. Popup windows are redirected to the local desktop. Local drives and
printers can be redirected to appear in the RemoteApp program. Many users might not be aware
that the RemoteApp program is any different than a local program.

You should evaluate your programs to see which ones might be suited to being run as a
RemoteApp program, and then test the programs. To test your programs, follow the procedures
described in the TS RemoteApp Step-by-Step Guide to configure your terminal server to support
RemoteApp programs and to use the TS RemoteApp Manager snap-in to make RemoteApp
programs available to users.
Do I need to change any existing code?

For a program to run as a RemoteApp program, the terminal server that hosts the program must
be running Windows Server 2008. Any program that can run in a Terminal Services session or in
a Remote Desktop session should be able to run as a RemoteApp program.
Some of the fundamental changes in the Windows Server 2008 operating system might impact
earlier versions of programs that run correctly under earlier versions of the Windows operating
system. If you experience difficulty running a program as a RemoteApp program, verify that it
runs correctly on the local console of a server that is running Windows Server 2008.
Review other sections of this guide for additional information about compatibility issues.
29
For more information about TS RemoteApp, see the TS RemoteApp Step-by-Step Guide
Terminal Services Web Access (TS Web

Access)
Terminal Services Web Access (TS Web Access) is a role service in the Terminal Services role
that lets you make Terminal Services RemoteApp™ (TS RemoteApp) programs, and a link to the
terminal server desktop, available to users from a Web browser. Additionally, TS Web Access
enables users to connect from a Web browser to the remote desktop of any server or client
computer where they have the appropriate access.
With TS Web Access, users can visit a Web site (either from the Internet or from an intranet) to
access a list of available RemoteApp programs. When they start a RemoteApp program, a
Terminal Services session is started on the Windows Server® 2008-based terminal server that
hosts the RemoteApp program.
What does TS Web Access do?

After you install TS Web Access on a Windows Server 2008-based Web server, users can
connect to the TS Web Access server to access RemoteApp programs that are available on a
Windows Server 2008-based terminal server. TS Web Access has many benefits. These include
the following:
• Users can access RemoteApp programs from a Web site over the Internet or from an
intranet. To start a RemoteApp program, they just click the program icon.
• If a user starts more than one RemoteApp program through TS Web Access, and the
programs are running on the same terminal server, the RemoteApp programs run within the
same Terminal Services session.
• By using TS Web Access, there is much less administrative overhead. You can easily deploy
programs from a central location. Additionally, programs are running on a terminal server and
not on the client computer so they are easier to maintain.
• TS Web Access includes Remote Desktop Web Connection, which enables users to connect
remotely to the desktop of any computer where they have Remote Desktop access.
30
• TS Web Access provides a solution that works with minimal configuration. The TS Web
Access Web page includes a customizable Web Part, which can be incorporated into a
customized Web page or a Windows® SharePoint® Services site.

The information in this topic applies to the following types of IT professionals:
• IT professionals who already run or who are interested in deploying programs to users by
using Terminal Services.
• IT professionals who want better control over the user’s experience.
• Web administrators and developers.
• Windows SharePoint Services administrators.

Before you install TS Web Access, review the following installation guidelines:
• You must install TS Web Access on a computer that is running Windows Server 2008.
• You must install TS Web Access together with Microsoft Internet Information Services (IIS)
7.0.
• The TS Web Access server does not have to be a terminal server.
• To use TS Web Access in Windows Server 2008 RC0, client computers must be running one
of the following operating systems:
• Windows Server 2008
• Windows Vista® with Service Pack 1 (SP1) Beta
Note
To use TS Web Access, client computers must be running RDC 6.1. (RDC 6.1
supports Remote Desktop Protocol 6.1.) RDC 6.1 is included with Windows
Server 2008 and Windows Vista with SP1 Beta.
What new functionality does this feature

provided?
Lets you easily deploy RemoteApp programs over the Web
With TS Web Access, a user can visit a Web site, view a list of RemoteApp programs, and then
just click a program icon to start the program. The RemoteApp programs are seamless, meaning
that they appear like a local program. Users can minimize, maximize, and resize the program
31
window, and can easily start multiple programs at the same time. For an administrator, TS Web
Access is easy to configure and to deploy.

This functionality translates to ease and flexibility of use and deployment. With TS Web Access,
you can provide users with access to RemoteApp programs from any location and from any
computer that has intranet or Internet access.

TS Web Access provides a much improved Web experience over earlier versions of Terminal
Services.
• With TS Web Access, a user does not have to start the Remote Desktop Connection (RDC)
client to start a RemoteApp program. Instead, they access the Web page, and then click a
program icon.
• The RemoteApp programs look like they are running on the local desktop.
• If the user starts multiple RemoteApp programs and the RemoteApp programs are all running
on the same terminal server, the programs run in the same session.
• Users do not have to download a separate ActiveX control to access TS Web Access.
Instead, RDC 6.1 includes the required ActiveX control. (The RDC 6.1 client supports
Remote Desktop Protocol 6.1.)

If you want to deploy TS Web Access, you can prepare by reviewing the Terminal Services
RemoteApp™ (TS RemoteApp) topic in this document for information about the new
TS RemoteApp feature. More detailed deployment information is available in the TS RemoteApp
Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=84895). You may also want to review
information about IIS 7.0.
If you want to use TS Web Access to make RemoteApp programs available to computers over
the Internet, you should review the "Terminal Services Gateway (TS Gateway)" topic in this
document. TS Gateway helps you secure remote connections to terminal servers on your
corporate network.
List of RemoteApp programs is dynamically updated

When you deploy TS Web Access, the list of RemoteApp programs that appears in the TS Web
Access Web Part is dynamically updated. The list is populated from the RemoteApp Programs
list of a single terminal server.
32
An administrator can specify the data source that will be used to populate the list of RemoteApp
programs. The Web Part is populated with all RemoteApp programs that are configured for Web
access on that server's RemoteApp Programs list.

The dynamically updated program list and the ability to specify the RemoteApp data source
simplifies the deployment of RemoteApp programs over the Web.

Earlier versions of Terminal Services did not provide a mechanism to dynamically update a Web
site with a list of RemoteApp programs.
Includes the TS Web Access Web Part

TS Web Access provides a customizable TS Web Access Web Part, where the list of RemoteApp
programs is displayed. You can deploy the Web Part by using any one of the following methods:
• Deploy the Web Part as part of the TS Web Access Web page. (This is the default out-of-the-
box solution.)
• Deploy the Web Part as part of a customized Web page.
• Add the Web Part to a Windows SharePoint Services site.

TS Web Access provides a flexible out-of-the-box solution. The provided TS Web Access Web
page and Web Part let you implement the TS Web Access site quickly and easily, and let you
deploy TS Web Access by using a Web page or by using Windows SharePoint Services.

With TS Web Access, you do not have to manually add a list of available programs to a Web
page to provide centralized Web access to RemoteApp programs. The customizable Web Part
gives you flexibility with regard to site appearance and deployment method.

If you want to customize the default Web page or Web Part, you should plan the design changes
that you want to make. You should also decide whether you want to provide access to TS Web
Access by using the provided TS Web Access Web page, a customized Web page or by using
Windows SharePoint Services.
33
Includes Remote Desktop Web Connection
In Windows Server 2008, Remote Desktop Web Connection is available through the TS Web
Access Web page.

Remote Desktop Web Connection enables users to connect remotely to the desktop of any
computer where they have Remote Desktop access. For example, a user could connect remotely
to their desktop at work if the remote computer is configured to accept Remote Desktop
connections, and the user is a member of the Remote Desktop Users group on the remote
computer.

In Windows Server 2008, the Remote Desktop Web Connection feature is available through the
Remote Desktop tab on the TS Web Access Web page. Remote Desktop Web Connection is
installed as part of the TS Web Access role service, instead of as an optional component of IIS.
As an administrator, you can configure whether the Remote Desktop tab is available to users.
Additionally, you can configure settings such as the TS Gateway server to use, the TS Gateway
authentication method, and the default device and resource redirection options.

To prepare for this change, determine whether you want to make the Remote Desktop Web
Connection feature available to users. If you do plan to use the feature, determine device and
resource redirection requirements, and whether you want Remote Desktop Web connections to
authenticate through a TS Gateway server. For information about how to configure Remote
Desktop Web Connection behavior, review the TS RemoteApp Step-by-Step Guide
Terminal Services Licensing (TS Licensing)

Windows Server® 2008 provides a license management system for Terminal Services known as
Terminal Services Licensing (TS Licensing). This system allows terminal servers to obtain and
manage Terminal Services client access licenses (TS CALs) for devices and users that are
connecting to a terminal server. TS Licensing supports terminal servers that run Windows
34
Server 2008 as well as terminal servers running Windows Server 2003 or Windows® 2000
Server.
Note
Remote Desktop supports two concurrent connections to remotely administer a
computer. You do not need a license server for these connections.
What does TS Licensing do?

A terminal server is a computer on which the Terminal Server role service is installed. It provides
clients access to Windows–based applications running entirely on the server and supports
multiple client sessions on the server. As clients connect to a terminal server, the terminal server
determines if the client needs a TS CAL, requests a TS CAL from a license server, and then
delivers that TS CAL to the client.
A Terminal Services license server is a computer on which the TS Licensing role service is
installed. A license server stores all TS CALs that have been installed for a group of terminal
servers and tracks the TS CALs that have been issued. One license server can serve many
terminal servers simultaneously. To issue permanent TS CALs to client devices, a terminal server
must be able to connect to an activated license server. A license server that has been installed
but not activated will only issue temporary TS CALs.
TS Licensing is a separate entity from the terminal server. In most large deployments, the license
server is deployed on a separate server, even though it can be a co-resident on the terminal
server in some smaller deployments.
TS Licensing is a low-impact service. It requires very little CPU or memory for regular operations,
and its hard disk requirements are small, even for a significant number of clients. Idle activities
are negligible. Memory usage is less than 10 megabytes (MB). The license database grows in
increments of 5 MB for every 6,000 TS CALs issued. The license server is only active when a
terminal server is requesting a TS CAL, and its impact on server performance is very low, even in
high-load scenarios.
TS Licensing includes the following features and benefits:
• Centralized administration for TS CALs
• License tracking and reporting for TS Per User CALs
• Simple support for various communication channels and purchase programs
• Minimal impact on network and servers
Who will be interested in TS Licensing?

The effective management of TS CALs by using TS Licensing will be of interest to organizations
that currently use or are interested in using Terminal Services. Terminal Services provides
35
technologies that enable access, from almost any computing device, to a server running
Windows-based programs or the full Windows desktop. Users can connect to a terminal server to
run programs and use network resources on that server.
What new functionality is provided by

TS Licensing?
TS Licensing for Windows Server 2008 now includes the ability to track the issuance of TS Per
User CALs by using TS Licensing Manager.
If the terminal server is in Per User licensing mode, the user connecting to it must have a TS Per
User CAL. If the user does not have the required TS Per User CAL, the terminal server will
contact the license server to get the TS CAL for the user.
After the license server issues a TS Per User CAL to the user, the administrator can track the
issuance of the TS CAL by using TS Licensing Manager.
How should I prepare to use TS Licensing?

To use TS Licensing to manage TS CALs, you will need to do the following on a server running
1. Install the TS Licensing role service.
2. Open TS Licensing Manager and connect to the Terminal Services license server.
3. Activate the license server.
4. Install required TS CALs on the license server.
For more information about installing and configuring TS Licensing on Windows Server 2008, see
the Windows Server 2008 TS Licensing Step-by-Step Setup Guide on the TS Licensing page on
the Windows Server 2008 TechCenter (http://go.microsoft.com/fwlink/?LinkID=79607).
Are there any special considerations about

TS Licensing?
In order to take advantage of TS Licensing, you must meet these prerequisites:
• You must install the TS Licensing role service on a server running Windows Server 2008.
• TS Per User CAL tracking and reporting is supported only in domain-joined scenarios (the
terminal server and the license server are members of a domain) and is not supported in
workgroup mode. Active Directory® Domain Services is used for license tracking in Per User
mode. Active Directory Domain Services can be Windows Server 2008-based or Windows
Server 2003-based.
36
Note
No updates to the Active Directory Domain Services schema are needed to
implement TS Per User CAL tracking and reporting.
• A terminal server running Windows Server 2008 cannot communicate with a license server
running Windows Server 2003. However, it is possible for a terminal server running Windows
Server 2003 to communicate with a license server running Windows Server 2008.
Terminal Services Gateway (TS Gateway)

Terminal Services Gateway (TS Gateway) is a role service in the Terminal Services server role of
Windows Server® 2008 that allows authorized remote users to connect to resources on an
internal corporate or private network, from any Internet-connected device. The network resources
can be terminal servers, terminal servers running RemoteApp programs, or computers with
Remote Desktop enabled.
TS Gateway uses Remote Desktop Protocol (RDP) over HTTPS to establish a secure, encrypted
connection between remote users on the Internet and the internal network resources on which
their productivity applications run.
What does TS Gateway do?

TS Gateway provides many benefits, including:
• TS Gateway enables remote users to connect to internal network resources over the Internet,
by using an encrypted connection, without needing to configure virtual private network (VPN)
connections.
• TS Gateway provides a comprehensive security configuration model that enables you to
control access to specific internal network resources.
• TS Gateway provides a point-to-point RDP connection, rather than allowing remote users
access to all internal network resources.
• TS Gateway enables most remote users to connect to internal network resources that are
hosted behind firewalls in private networks and across network address translators (NATs).
With TS Gateway, you do not need to perform additional configuration for the TS Gateway
server or clients for this scenario.
37
Prior to this release of Windows Server, security measures prevented remote users from
connecting to internal network resources across firewalls and NATs. This is because port
3389, the port used for RDP connections, is typically blocked for network security purposes at
the firewalls. TS Gateway transmits RDP traffic to port 443 instead, by using an HTTP Secure
Sockets Layer/Transport Layer Security (SSL/TLS) tunnel. Because most corporations open
port 443 to enable Internet connectivity, TS Gateway takes advantage of this network design
to provide remote access connectivity across multiple firewalls.
• The TS Gateway Manager snap-in console enables you to configure authorization policies to
define conditions that must be met for remote users to connect to internal network resources.
For example, you can specify:
• Who can connect to network resources (in other words, the user groups who can
connect).
• What network resources (computer groups) users can connect to.
• Whether client computers must be members of Active Directory security groups.
• Whether device and disk redirection is allowed.
• Whether clients need to use smart card authentication or password authentication, or
whether they can use either method.
• You can configure TS Gateway servers and Terminal Services clients to use Network Access
Protection (NAP) to further enhance security. NAP is a health policy creation, enforcement,
and remediation technology that is included in Windows® XP Service Pack 2,
Windows Vista®, and Windows Server 2008. With NAP, system administrators can enforce
health requirements, which can include software requirements, security update requirements,
required computer configurations, and other settings.
Note
Computers running Windows Server 2008 cannot be used as NAP clients when
TS Gateway enforces NAP. Only computers running Windows XP SP2 and
Windows Vista can be used as NAP clients when TS Gateway enforces NAP.
For information about how to configure TS Gateway to use NAP for health policy enforcement
for Terminal Services clients that connect to TS Gateway servers, see the TS Gateway
Server Step-by-Step Setup Guide on the TS Gateway page on the Windows Server 2008
TechCenter (http://go.microsoft.com/fwlink/?linkid=79605).
• You can use TS Gateway server with Microsoft Internet Security and Acceleration (ISA)
Server to enhance security. In this scenario, you can host TS Gateway servers in a private
network rather than a perimeter network (also known as a DMZ, demilitarized zone, and
screened subnet), and host ISA Server in the perimeter network. The SSL connection
between the Terminal Services client and ISA Server can be terminated at the ISA Server,
which is Internet-facing.
38
For information about how to configure ISA Server as an SSL termination device for
TS Gateway server scenarios, see the TS Gateway Server Step-by-Step Setup Guide on the
TS Gateway page on the Windows Server 2008 TechCenter
• The TS Gateway Manager snap-in console provides tools to help you monitor TS Gateway
connection status, health, and events. By using TS Gateway Manager, you can specify
events (such as unsuccessful connection attempts to the TS Gateway server) that you want
to monitor for auditing purposes.

If your organization makes Terminal Services–based applications and computers that run Remote
Desktop available to users from outside your network perimeter, TS Gateway can simplify
network administration and reduce your exposure to security risks.
TS Gateway can also make it easier for users because they do not have to configure VPN
connections and can access TS Gateway servers from sites that can otherwise block outbound
RDP or VPN connections.
You should review this section and the additional supporting documentation about TS Gateway if
you are in any of the following groups:
• IT administrators, planners, and analysts who are evaluating remote access and mobile
solution products
• Enterprise IT architects and designers for organizations
• Early adopters
• Security architects who are responsible for implementing trustworthy computing
• IT professionals who are responsible for terminal servers or remote access to desktops

For TS Gateway to function correctly, you must meet these prerequisites:
• You must have a server with Windows Server 2008 installed.
• You must be a member of the Administrators group on the computer that you want to
configure as a TS Gateway server.
• You must obtain an externally trusted SSL certificate for the TS Gateway server if you do not
have one already. By default, on the TS Gateway server, the RPC/HTTP Load Balancing
service and the IIS service use Transport Layer Security (TLS) 1.0 to encrypt
communications between clients and TS Gateway servers over the Internet. For TLS to
function correctly, you must install an SSL certificate on the TS Gateway server.
39
Note
You do not need a certification authority (CA) infrastructure within your organization if
you can use another method to obtain an externally trusted certificate that meets the
requirements for TS Gateway. If your company does not maintain a stand-alone CA
or an enterprise CA and you do not have a compatible certificate from a trusted
public CA, you can create and import a self-signed certificate for your TS Gateway
server for technical evaluation and testing purposes.
The certificate must meet these requirements:
• The name in the Subject line of the server certificate (certificate name, or CN) must
match the DNS name that the client uses to connect to the TS Gateway server, unless
you are using wildcard certificates or the SAN attributes of certificates. If your
organization issues certificates from an enterprise CA, a certificate template must be
configured so that the appropriate name is supplied in the certificate request. If your
organization issues certificates from a stand-alone CA, you do not need to do this.
• The certificate is a computer certificate.
• The intended purpose of the certificate is server authentication. The Extended Key Usage
(EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
• The certificate has a corresponding private key.
• The certificate has not expired. We recommend that the certificate be valid one year from
the date of installation.
• A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if
the certificate that you plan to use contains an object identifier of 2.5.29.15, you can only
use the certificate if at least one of the following key usage values is also set:
CERT_KEY_ENCIPHERMENT_KEY_USAGE,
CERT_KEY_AGREEMENT_KEY_USAGE, and
CERT_DATA_ENCIPHERMENT_KEY_USAGE.
For more information about these values, see Advanced Certificate Enrollment and
Management (http://go.microsoft.com/fwlink/?LinkID=74577).
• The certificate must be trusted on clients. That is, the public certificate of the CA that
signed the TS Gateway server certificate must be located in the Trusted Root
Certification Authorities store on the client computer.
For more information about certificate requirements for TS Gateway and how to obtain and install
a certificate if you do not have one already, see the TS Gateway Step-by-Step Setup Guide on
the TS Gateway page on the Windows Server 2008 TechCenter
Additionally, keep in mind the following considerations:
40
• TS Gateway transmits all RDP traffic (that typically would have been sent over port 3389) to
port 443 by using an HTTPS tunnel. This also means that all traffic between the client and
TS Gateway is encrypted while in transit over the Internet.
• To function correctly, TS Gateway requires several role services and features to be installed
and running. When you use Server Manager to install the TS Gateway role service, the
following additional role services and features are automatically installed and started, if they
are not already installed:
• Remote procedure call (RPC) over HTTP Proxy
• Web Server (IIS) [Internet Information Services 7.0].
IIS 7.0 must be installed and running for the RPC over HTTP Proxy service to function.
• Network Policy and Access Services.
You can also configure TS Gateway to use Terminal Services connection authorization
policies that are stored on another server that runs the Network Policy Server (NPS)
service. By doing this, you are using the NPS server—formerly known as a Remote
Authentication Dial-In User Service (RADIUS) server—to centralize the storage,
management, and validation of TS CAPs. If you have already deployed an NPS server
for remote access scenarios such as VPN and dial-up networking, using the existing NPS
server for TS Gateway scenarios as well can enhance your deployment.
How should I prepare for TS Gateway?

• You should review this topic and the additional supporting documentation on TS Gateway,
including the TS Gateway Server Step-by-Step Setup Guide on the TS Gateway page on the
Windows Server 2008 TechCenter (http://go.microsoft.com/fwlink/?linkid=79605).
• You should also prepare to acquire an SSL certificate, or to issue one from your own
certification authority (CA).
• You should become familiar with the TLS and SSL protocols if you are not already.

TS Gateway provides the following new features to simplify administration and enhance security.
TS CAPs
Terminal Services connection authorization policies (TS CAPs) allow you to specify user groups,
and optionally client computer groups, that can access a TS Gateway server. You can create a
TS CAP by using TS Gateway Manager.
41
Why are TS CAPs important?
TS CAPs simplify administration and enhance security by providing a greater level of control over
access to computers on your internal network.
TS CAPs allow you to specify who can connect to a TS Gateway server. You can specify a user
group that exists on the local TS Gateway server or in Active Directory Domain Services. You can
also specify other conditions that users must meet to access a TS Gateway server. You can list
specific conditions in each TS CAP. For example, you might require a user to use a smart card to
connect through TS Gateway.
Users are granted access to a TS Gateway server if they meet the conditions specified in the
TS CAP.
Important
Users are granted access to a TS Gateway server if they meet the conditions specified in
the TS CAP. You must also create a Terminal Services resource authorization policy
(TS RAP). A TS RAP allows you to specify the internal network resources that users can
connect to through TS Gateway. Until you create both a TS CAP and a TS RAP, users
cannot connect to internal network resources through this TS Gateway server.
TS RAPs
TS RAPs allow you to specify the internal corporate network resources that remote users can
connect to through a TS Gateway server. When you create a TS RAP, you can create a computer
group (a list of computers on the internal network to which you want the remote users to connect)
and associate it with the TS RAP.
Remote users connecting to an internal network through a TS Gateway server are granted
access to computers on the network if they meet the conditions specified in at least one TS CAP
and one TS RAP.
Note
When you associate a TS Gateway-managed computer group with a TS RAP, you can
support both fully qualified domain names (FQDNs) and NetBIOS names by adding both
names to the TS Gateway-managed computer group separately. When you associate an
Active Directory security group with a TS RAP, both FQDNs and NetBIOS names are
supported automatically if the internal network computer that the client is connecting to
belongs to the same domain as the TS Gateway server. If the internal network computer
belongs to a different domain than the TS Gateway server, users must specify the FQDN
of the internal network computer.
Together, TS CAPs and TS RAPs provide two different levels of authorization to provide you with
the ability to configure a more specific level of access control to computers on an internal
network.
42
Security groups and TS Gateway-managed computer groups
associated with TS RAPs
Remote users can connect through TS Gateway to internal network resources in a security group
or a TS Gateway-managed computer group. The group can be any one of the following:
• Members of an existing security group. The security group can exist in Local Users and
Groups on the TS Gateway server, or it can exist in Active Directory Domain Services.
• Members of an existing TS Gateway-managed computer group or a new TS Gateway-
managed computer group. You can configure a TS Gateway–managed computer group by
using TS Gateway Manager after installation.
A TS Gateway-managed computer group will not appear in Local Users and Groups on the
TS Gateway server, nor can it be configured by using Local Users and Groups.
When you add an internal network computer to the list of TS Gateway-managed computers,
keep in mind that if you want to allow remote users to connect to the computer by specifying
either its computer name or its IP address, you must add the computer to the computer group
twice (by specifying the computer name of the computer and adding it to the computer group
and then specifying the IP address of the computer and adding it to the computer group
again). If you specify only an IP address for a computer when you add it to a computer group,
users must also specify the IP address of that computer when they connect to that computer
through TS Gateway.
Important
To ensure that remote users connect to the internal corporate network computers
that you intend, we recommend that you do not specify IP addresses for the
computers, if the computers are not configured to use static IP addresses. For
example, you should not specify IP addresses if your organization uses DHCP to
dynamically reconfigure IP addresses for the computers. To ensure that remote users
connect to the internal corporate network computers that you intend, we recommend
that you do not specify IP addresses for the computers, if the computers are not
configured to use static IP addresses. For example, you should not specify IP
addresses if your organization uses DHCP to dynamically reconfigure IP addresses
for the computers.
• Any network resource. In this case, users can connect to any computer on the internal
network that they could connect to when they use Remote Desktop Connection.
To ensure that the appropriate users have access to the appropriate network resources, plan and
create security groups and TS Gateway-managed computer groups carefully. Evaluate the users
who should have access to each group, and then associate the groups with TS RAPs to grant
users access as needed.
43
Monitoring capabilities
You can use TS Gateway Manager to view information about active connections from Terminal
Services clients to internal corporate network resources through TS Gateway. This information
includes:
• The connection ID. The connection ID is displayed in the format <a:b>, where "a" is the
tunnel ID that uniquely identifies a specific connection to the TS Gateway server and "b" is
the channel ID. The tunnel ID represents the number of connections that the TS Gateway
server has received since the Terminal Services Gateway service has been running. Each
time the TS Gateway server receives a new connection, the tunnel ID is incremented by 1.
• The domain and user ID of the user logged on to the client.
• The full name of the user logged on to the client.
• The date and time when the connection was initiated.
• The length of time the connection was active.
• The length of time that the connection is idle, if applicable.
• The name of the internal network computer to which the client is connected
• The IP address of the client
Note
If your network configuration includes proxy servers, the IP address that appears in
the Client IP Address column (in the Monitoring details pane) might reflect the IP
address of the proxy server, rather than the IP address of the Terminal Services
client.
• The port on the internal network computer to which the client is connected
You can also specify the types of events that you want to monitor, such as unsuccessful or
successful connection attempts to internal network computers through a TS Gateway server.
When these events occur, you can monitor the corresponding events by using Windows Event
Viewer. TS Gateway events are stored in Event Viewer under Application and Services
Logs\Microsoft\Windows\Terminal Services-Gateway\.
Group Policy settings for TS Gateway

You can use Group Policy and Active Directory Domain Services to centralize and simplify the
administration of TS Gateway policy settings. You use the Local Group Policy Editor to configure
local policy settings, which are contained within Group Policy Objects (GPOs). You use the Group
Policy Management Console (GPMC) to link GPOs to sites, domains, or organizational units
(OUs) in Active Directory Domain Services.
Group Policy settings for Terminal Services client connections through TS Gateway can be
applied in one of two ways. These policy settings can either be suggested (that is, they can be
enabled, but not enforced) or they can be enabled and enforced. Suggesting a policy setting
44
allows users on the client to enter alternate TS Gateway connection settings. Enforcing a policy
setting prevents a user from changing the TS Gateway connection setting, even if they select the
Use these TS Gateway server settings option on the client.
The following three Group Policy settings are available for TS Gateway server:
• Set the TS Gateway Server Authentication Method: Enables you to specify the
authentication method that Terminal Services clients must use when connecting to internal
network resources through a TS Gateway server.
• Enable Connections Through TS Gateway: Enables you to specify that, when Terminal
Services clients cannot connect directly to an internal network resource, the clients will
attempt to connect to the internal network resource through the TS Gateway server that is
specified in the Set the TS Gateway server address policy setting.
• Set the TS Gateway Server Address: Enables you to specify the TS Gateway server that
Terminal Services clients use when they cannot connect directly to an internal network
resource.
Important
If you disable or do not configure this policy setting, but enable the Enable connections
through TS Gateway policy setting, client connection attempts to any internal network
resource will fail if the client cannot connect directly to the network resource.
Do I need to change any existing code?

You do not need to change any existing code to work with TS Gateway. TS Gateway only
manages the way in which the connection to the internal corporate network computer is created.
Note
TS Gateway can route connections to any Terminal Services–based session, including
those on Windows Server 2008, Windows Server 2003, Windows Vista, and
Windows XP–based computers.
If the internal corporate network computer is using new Terminal Services features, you will need
to use the Remote Desktop Connection version 6.0 or later software, which is included with
Windows Server 2008 and Windows Vista.
Note
The Remote Desktop Connection version 6.0 or later software is available for use on
Windows XP with Service Pack 2 and Windows Server 2003 with Service Pack 1 or later.
To use any new Terminal Services features on either of these platforms, download the
installer package for RDC. For information about how to download the installer package
for RDC 6.0 or later, see article 925876 in the Microsoft Knowledge Base
45
Terminal Services Session Broker (TS

Session Broker)
Terminal Services Session Broker (TS Session Broker) is a role service in
Windows Server® 2008 that allows a user to reconnect to an existing session in a load-balanced
terminal server farm. TS Session Broker stores session state information that includes session
IDs and their associated user names, and the name of the server where each session resides.
Windows Server 2008 introduces the new TS Session Broker Load Balancing feature. This
feature enables you to distribute the session load between servers in a load-balanced terminal
server farm. When used with Domain Name System (DNS) round robin, this solution is easier to
deploy than Windows Network Load Balancing (NLB).
Note
In Windows Server 2008, the name of the Terminal Services Session Directory (TS
Session Directory) feature was changed to Terminal Services Session Broker
(TS Session Broker).

To participate in TS Session Broker Load Balancing, the TS Session Broker server and the
terminal servers in the farm must be running Windows Server 2008. Windows Server 2003-based
terminal servers cannot use the TS Session Broker Load Balancing feature.
For clients to use TS Session Broker Load Balancing, they must be running Remote Desktop
Connection (RDC) version 5.2 or later.

The new TS Session Broker Load Balancing feature enables you to evenly distribute the session
load between servers in a load-balanced terminal server farm. With TS Session Broker Load
Balancing, new user sessions are redirected to the terminal server with the fewest sessions.
TS Session Broker is a two phased load-balancing mechanism. In the first phase, initial
connections are distributed by a preliminary load-balancing mechanism, such as DNS round
robin. After a user authenticates, the terminal server that accepted the initial connection queries
the TS Session Broker server to determine where to redirect the user.
46
In the second phase, the terminal server where the initial connection was made redirects the user
to the terminal server that was specified by TS Session Broker. The redirection behavior is as
follows:
• A user with an existing session will connect to the server where their session exists.
• A user without an existing session will connect to the terminal server that has the fewest
sessions.
TS Session Broker Load Balancing sets a limit of 16 for the maximum number of pending logon
requests to a particular terminal server. This helps to prevent the scenario where a single server
is overwhelmed by new logon requests; for example, if you add a new server to the farm, or if you
enable user logons on a server where they were previously denied.
The TS Session Broker Load Balancing feature also enables you to assign a relative weight value
to each server. By assigning a server weight value, you can help to distribute the load between
more powerful and less powerful servers in the farm.
Note
To configure a server to participate in TS Session Broker Load Balancing, and to assign
a server weight value, you can use the Terminal Services Configuration tool.
Additionally, a user logon mode setting is provided that enables you to prevent new users from
logging on to a terminal server that is scheduled to be taken down for maintenance. This
mechanism provides for the ability to take a server offline without disrupting the user experience.
If new logons are denied on a terminal server in the farm, TS Session Broker will allow users with
existing sessions to reconnect, but will redirect new users to terminal servers that are configured
to allow new logons.
Note
The User logon mode setting is located under General in the Edit settings area of the
Terminal Services Configuration tool.
While any load-balancing mechanism can be used to distribute the initial connections, DNS round
robin is the easiest mechanism to deploy. Deploying TS Session Broker Load Balancing with a
network level load-balancing solution such as NLB or a hardware load balancer avoids the
limitations of DNS, while still taking advantage of TS Session Broker session-based load
balancing, the per server limit on the number of pending logon requests, and the user logon mode
setting. The limitations of DNS round robin include the caching of DNS requests on the client,
which can result in clients using the same IP address for each initial connection request, and the
potential for a 30-second timeout delay if a user is redirected to a terminal server that is offline,
but still listed in DNS.

If you want to use the TS Session Broker Load Balancing feature, both the TS Session Broker
server and the terminal servers in the same farm must be running Windows Server 2008.
47
If you want to use DNS round-robin as the load balancer for initial connections, you must create a
host resource record for each terminal server in the farm that maps to the terminal server farm
name in DNS. (The farm name is the virtual name that clients will use to connect to the terminal
server farm.) DNS uses round robin to rotate the order of the resource records that are returned
to the client. This functionality helps to distribute initial connections across servers in the farm.
Note
If you prefer, you can use a hardware load balancer to spread the initial connection and
authentication load between multiple terminal servers in the farm.
What settings have been added or changed?

Group Policy settings
The following Group Policy setting has been added for TS Session Broker:
Services\Terminal Server\TS Session Broker\Use TS Session Broker load balancing
• Enabled: If you enable this policy setting, TS Session Broker will redirect users who do not
have an existing session to the terminal server in the farm with the fewest sessions.
Redirection behavior for users with existing sessions will not be affected. If the server is
configured to use TS Session Broker, users who have an existing session will be redirected
to the terminal server where their session exists.
• Disabled: If you disable this policy setting, users who do not have an existing session will log
on to the terminal server that they first connect to.
• Not configured: If you do not configure this policy setting, TS Session Broker Load
Balancing is not specified at the Group Policy level. In this case, you can configure the
terminal server to participate in TS Session Broker Load Balancing by using the Terminal
Services Configuration tool or the Terminal Services WMI provider. By default, this policy
setting is not configured.
For more information, see the TS Session Broker Load Balancing Step-by-Step Guide
48
Terminal Services and Windows System
Resource Manager
Windows® System Resource Manager (WSRM) on Windows Server® 2008 allows you to control
how CPU and memory resources are allocated to applications, services, and processes on the
computer. Managing resources in this way improves system performance and reduces the
chance that applications, services, or processes will take CPU or memory resources away from
one another and slow down the performance of the computer. Managing resources also creates a
more consistent and predictable experience for users of applications and services running on the
computer.
You can use WSRM to manage multiple applications on a single computer or users on a
computer on which Terminal Services is installed.
For more information about WSRM, see the following documentation:
• Windows Server 2008 Windows System Resource Manager Step-by-Step Guide on the
Windows Server 2008 Technical Library Web site
• Windows Server 2003 Help for Windows System Resource Manager on the Microsoft
Download Center (http://go.microsoft.com/fwlink/?LinkId=49774).
Prerequisites for Using WSRM with Terminal

Services
Installing Terminal Server
Install the Terminal Server role service on your computer before installing and configuring
WSRM. To install the Terminal Server role service in Windows Server 2008 see the Terminal
Server Installation procedure.
Installing WSRM
To install WSRM
1. Open Server Manager. Click Start, point to Administrative Tools, and then click Server
Manager.
2. Under Features Summary, click Add features.
3. On the Select Features page, select the Windows System Resource Manager check
box.
4. A dialog box will appear informing you that Windows Internal Database also needs to be
49
installed for WSRM to work properly. Click Add Required Features, and then click Next.
5. On the Confirm Installation Selections page, verify that Windows Internal Database
and Windows Server Resource Manager will be installed, and then click Install.
6. On the Installation Results page, confirm that the installation of Windows Internal
Database and Windows Server Resource Manager succeeded, and then click Close.
After you install WSRM, you need to start the Windows System Resource Manager service.
To start the Windows System Resource Manager service

1. Open the Services snap-in. To open the Services snap-in, click Start, point to
Administrative Tools, and then click Services.
2. In the Services dialog box, in the Name column, right-click Windows System Resource
Manager, and then click Start.
Configuring WSRM for Terminal Services

Windows System Resource Manager Snap-In
To configure WSRM, you use the Windows System Resource Manager snap-in.
To open the Windows System Resource Manager snap-in

1. Click Start, point to Administrative Tools, and then click Windows System Resource
Manager.
2. In the Connect to computer dialog box, click This computer, and then click Connect to
have the Windows System Resource Manager administer the computer that you are
using.
Resource-Allocation Policies
WSRM uses resource-allocation policies to determine how computer resources, such as CPU
and memory, are allocated to processes running on the computer. There are two resource-
allocation policies that are specifically designed for computers running Terminal Services. The
two Terminal Services-specific resource-allocation policies are:
• Equal_Per_User
• Equal_Per_Session
Note
The Equal_Per_Session resource-allocation policy is new for Windows Server 2008.
50
If you implement the Equal_Per_Session resource-allocation policy, each user session (and its
associated processes) gets an equal share of the CPU resources on the computer.
To implement the Equal_Per_Session resource-allocation policy

1. Open the Windows System Resource Manager snap-in.
2. In the console tree, expand the Resource Allocation Policies node.
3. Right-click Equal_Per_Session, and then click Set as Managing Policy.
4. If a dialog box appears informing you that the calendar will be disabled, click OK.
For information about the Equal_Per_User resource-allocation policy and additional WSRM
settings and configuration (such as creating a process-matching criterion by using user or group
matching), see the following documentation:
• Windows Server 2008 Windows System Resource Manager Step-by-Step Guide on the
Windows Server 2008 Technical Library Web site
• Windows Server 2003 Help for Windows System Resource Manager on the Microsoft
Download Center (http://go.microsoft.com/fwlink/?LinkId=49774).
Monitoring Performance
You should collect data about the performance of your terminal server before and after
implementing the Equal_Per_Session resource-allocation policy (or making any other WSRM-
related configuration change). You can use Resource Monitor in the Windows System Resource
Manager snap-in to collect and view data about the usage of hardware resources and the activity
of system services on the computer.
51
Windows Server 2008 Active Directory
Certificate Services Step-By-Step Guide
Author: Roland Winkler
Editor: Debbie Swanson
Abstract
This step-by-step guide describes the steps needed to set up a basic configuration of Active
Directory® Certificate Services (AD CS) in a lab environment.
AD CS in Windows Server® 2008 provides customizable services for creating and managing
public key certificates used in software security systems employing public key technologies.
1
Microsoft, Active Directory, MS-DOS, Visual Basic, Visual Studio, Windows, Windows NT, and
2
Contents
Windows Server Active Directory Certificate Services Step-by-Step Guide ................................... 5
AD CS Technology Review .......................................................................................................... 5
Requirements for Using AD CS ................................................................................................... 6
AD CS Basic Lab Scenario .......................................................................................................... 7
Steps for Setting up a Basic Lab .................................................................................................. 7
Step 1: Setting Up an Enterprise Root CA ............................................................................... 8
Step 2: Installing the Online Responder ................................................................................... 9
Step 3: Configuring the CA to Issue OCSP Response Signing Certificates............................. 9
Step 4: Creating a Revocation Configuration ......................................................................... 11
Step 5: Verifying that the AD CS Lab Setup Functions Properly ............................................ 12
AD CS Advanced Lab Scenario ................................................................................................. 13
Steps for Setting Up an Advanced Lab ...................................................................................... 14
Step 1: Setting Up the Stand-Alone Root CA ......................................................................... 15
Step 2: Setting Up the Enterprise Subordinate Issuing CA .................................................... 15
Step 3: Installing and Configuring the Online Responder ...................................................... 16
Step 4: Configuring the Issuing CA to Issue OCSP Response Signing Certificates .............. 17
Step 5: Configuring the Authority Information Access Extension to Support the Online
Responder ........................................................................................................................... 17
Step 6: Assigning the OCSP Response Signing Template to a CA ....................................... 18
Step 7: Enrolling for an OCSP Response Signing Certificate ................................................ 18
Step 8: Creating a Revocation Configuration ......................................................................... 19
Step 9: Setting Up and Configuring the Network Device Enrollment Service ........................ 20
Step 10: Verifying that the Advanced AD CS Test Setup Functions Properly ....................... 21
3
Windows Server Active Directory Certificate
Services Step-by-Step Guide
This step-by-step guide describes the steps needed to set up a basic configuration of Active
Directory® Certificate Services (AD CS) in a lab environment.
AD CS in Windows Server® 2008 provides customizable services for creating and managing
public key certificates used in software security systems that employ public key technologies.
This document includes:
• A review of AD CS features
• Requirements for using AD CS
• Procedures for a basic lab setup to test AD CS on a minimum number of computers
• Procedures for an advanced lab setup to test AD CS on a larger number of computers to
more realistically simulate real-world configurations
AD CS Technology Review
Using the Active Directory Certificate Services option of the Add Roles Wizard, you can set up
the following components of AD CS:
• Certification authorities (CAs). Root and subordinate CAs are used to issue certificates to
users, computers, and services, and to manage their validity.
• CA Web enrollment. Web enrollment allows users to connect to a CA by means of a Web
browser in order to:
• Request certificates and review certificate requests.
• Retrieve certificate revocation lists (CRLs).
• Perform smart card certificate enrollment.
• Online Responder service. The Online Responder service implements the Online
Certificate Status Protocol (OCSP) by decoding revocation status requests for specific
certificates, evaluating the status of these certificates, and sending back a signed response
containing the requested certificate status information.
Important
Online Responders can be used as an alternative to or an extension of CRLs to
provide certificate revocation data to clients. Microsoft Online Responders are based
on and comply with RFC 2560 for OCSP. For more information about RFC 2560, see
the Internet Engineering Task Force Web site
5
• Network Device Enrollment Service. The Network Device Enrollment Service allows
routers and other network devices to obtain certificates based on the Simple Certificate
Enrollment Protocol (SCEP) from Cisco Systems Inc.
Note
SCEP was developed to support the secure, scalable issuance of certificates to
network devices by using existing CAs. The protocol supports CA and registration
authority public key distribution, certificate enrollment, certificate revocation,
certificate queries, and certificate revocation queries.
Requirements for Using AD CS

CAs can be set up on servers running a variety of operating systems, including Windows® 2000
Server, Windows Server® 2003, and Windows Server 2008. However, not all operating systems
support all features or design requirements, and creating an optimal design requires careful
planning and lab testing before you deploy AD CS in a production environment. Although you can
deploy AD CS with as little hardware as a single server for a single CA, many deployments
involve multiple servers configured as root, policy, and issuing CAs, and other servers configured
as Online Responders.
Note
A limited set of server roles is available for a Server Core installation of Windows
Server 2008 and for Windows Server 2008 for Itanium-based Systems.
The following table lists the AD CS components that can be configured on different editions of
Components Web Standard Enterprise Datacenter
CA No Yes Yes Yes
Network Device No No Yes Yes

Enrollment Service
Online Responder No No Yes Yes

service
The following features are available on servers running Windows Server 2008 that have been
configured as CAs.
AD CS features Web Standard Enterprise Datacenter
Version 2 and No No Yes Yes

version 3 certificate
6
AD CS features Web Standard Enterprise Datacenter
templates
Key archival No No Yes Yes
Role separation No No Yes Yes
Certificate No No Yes Yes

Manager
restrictions
Delegated No No Yes Yes

enrollment agent
restrictions
AD CS Basic Lab Scenario

The following sections describe how you can set up a lab to begin evaluating AD CS.
accompanying documentation and should be used with discretion as a stand-alone document.
Steps for Setting up a Basic Lab

You can begin testing many features of AD CS in a lab environment by using as few as two
servers running Windows Server 2008 and one client computer running Windows Vista®. The
computers for this guide are named as follows:
• LH_DC1: This computer will be the domain controller for your test environment.
• LH_PKI1: This computer will host an enterprise root CA for the test environment. This CA will
issue client certificates for the Online Responder and client computers.
Note
Enterprise CAs and Online Responders can only be installed on servers running
Windows Server 2008 Enterprise or Windows Server 2008 Datacenter.
• LH_CLI1: This client computer running Windows Vista will autoenroll for certificates from
LH_PKI1 and verify certificate status from LH_ PKI1.
To configure the basic lab setup for AD CS, you need to complete the following prerequisite
steps:
• Set up a domain controller on LH_DC1 for contoso.com, including some organizational units
(OUs) to contain one or more users for the client computer, client computers in the domain,
and for the servers hosting CAs and Online Responders.
7
• Install Windows Server 2008 on LH_PKI1, and join LH_PKI1 to the domain.
• Install Windows Vista on LH_CLI1, and join LH_CLI1 to contoso.com.
After you have completed these preliminary setup procedures, you can begin to complete the
following steps:
Step 1: Setting Up an Enterprise Root CA
Step 2: Installing the Online Responder
Step 3: Configuring the CA to Issue OCSP Response Signing Certificates
Step 4: Creating a Revocation Configuration
Step 5: Verifying that the AD CS Lab Setup Functions Properly
Step 1: Setting Up an Enterprise Root CA

An enterprise root CA is the anchor of trust for the basic lab setup. It will be used to issue
certificates to the Online Responder and client computer, and to publish certificate information to
Active Directory Domain Services (AD DS).
Note
To set up an enterprise root CA

1. Log on to LH_PKI1 as a domain administrator.
2. Click Start, point to Administrative Tools,and then click Server Manager.
3. In the Roles Summary section, click Add roles.
4. On the Select Server Roles page, select the Active Directory Certificate Services
check box. Click Nexttwo times.
5. On the Select Role Services page, select the Certification Authority check
box,andthen click Next.
6. On the Specify Setup Type page, click Enterprise,and then click Next.
7. On the Specify CA Type page, click Root CA, and then click Next.
8. On the Set Up Private Key and Configure Cryptography for CA pages, you can
configure optional configuration settings, including cryptographic service providers.
However, for basic testing purposes, accept the default values by clicking Next twice.
9. In the Common name for this CA box, type the common name of the CA, RootCA1,
10. On the Set the Certificate Validity Period page, accept the default validity duration for
the root CA, and then click Next.
11. On the Configure Certificate Database page, accept the default values or specify other
8
storage locations for the certificate database and the certificate database log, and then
click Next.
12. After verifying the information on the Confirm Installation Options page, click Install.
13. Review the information on the confirmation screen to verify that the installation was
successful.
Step 2: Installing the Online Responder

An Online Responder can be installed on any computer running Windows Server 2008 Enterprise
or Windows Server 2008 Datacenter. The certificate revocation data can come from a CA on a
computer running Windows Server 2008, a CA on a computer running Windows Server 2003, or
from a non-Microsoft CA.
Note
IIS must also be installed on this computer before the Online Responder can be installed.
To install the Online Responder

1. Log on to LH_PKI1 as a domain administrator.
2. Click Start, point to Administrative Tools,and then click Server Manager.
3. Click Manage Roles. In the Active Directory Certificate Services section, click Add
role services.
4. On the Select Role Services page, select the Online Responder check box.
You are prompted to install IIS and Windows Activation Service.
5. Click Add Required Role Services, and then click Next three times.
6. On the Confirm Installation Options page, click Install.
7. When the installation is complete, review the status page to verify that the installation
was successful.
Step 3: Configuring the CA to Issue OCSP Response Signing

Certificates
Configuring a CA to support Online Responder services involves configuring certificate templates
and issuance properties for OCSP Response Signing certificates and then completing additional
steps on the CA to support the Online Responder and certificate issuance.
Note
These certificate template and autoenrollment steps can also be used to configure
certificates that you want to issue to a client computer or client computer users.
9
To configure certificate templates for your test environment
1. Log on to LH_PKI1 as a CA administrator.
3. Right-click the OCSP Response Signing template, and then click Duplicate Template.
4. Type a new name for the duplicated template, such as OCSP Response Signing_2.
5. Right-click the OCSP Response Signing_2 certificate template, and then click
Properties.
6. Click the Security tab. Under Group or user name, click Add, and then type the name
or browse to select the computer hosting the Online Responder service.
7. Click the computer name, LH_PKI1, and in the Permissions dialog box, select the Read
and Autoenroll check boxes.
8. While you have the Certificate Templates snap-in open, you can configure certificate
templates for users and computers by substituting the desired templates in step 3, and
repeating steps 4 through 7 to configure permissions for LH_CLI1 and your test user
accounts.
To configure the CA to support Online Responders, you need to use the Certification Authority
snap-in to complete two key steps:
• Add the location of the Online Responder to the authority information access extension of
issued certificates.
• Enable the certificate templates that you configured in the previous procedure for the CA.
To configure a CA to support the Online Responder service

2. In the console tree, click the name of the CA.
3. On the Action menu, click Properties.
4. Click the Extensions tab. In the Select extension list, click Authority Information
Access (AIA).
5. Select the Include in the AIA extension of issue certificates and Include in the
online certificate status protocol (OCSP) extension check boxes.
6. Specify the locations from which users can obtain certificate revocation data; for this
setup, the location is http://LH_PKI1/ocsp.
7. In the console tree of the Certification Authority snap-in, right-click Certificate
Templates, and then click New Certificate Templates to Issue.
8. In Enable Certificate Templates, select the OCSP Response Signing template and
any other certificate templates that you configured previously, and then click OK.
9. Open Certificate Templates, and verify that the modified certificate templates appear in
10
the list.

A revocation configuration includes all of the settings that are needed to respond to status
requests regarding certificates that have been issued by using a specific CA key.
These configuration settings include the CA certificate, the signing certificate for the Online
Responder, and the locations to which clients are directed to send their status requests.
Important
Before you create a revocation configuration, ensure that certificate enrollment has taken
place so that a signing certificate exists on the computer and adjust the permissions on
the signing certificate to allow the Online Responder to use it.
To verify that the signing certificate is properly configured

1. Start or restart LH_PKI1 to enroll for certificates.
2. Log on as a CA administrator.
3. Open the Certificates snap-in for the computer account. Open the Personal certificate
store for the computer, and verify that it contains a certificate titled OCSP Response
Signing.
4. Right-click this certificate, and then click Manage Private Keys.
5. Click the Security tab. In the User Group or user name dialog box, click Add, enter
Network Service to the Group or user name list, and then click OK.
6. Click Network Service, and in the Permissions dialog box, select the Full Control
check box.
7. Click OK twice.
Creating a revocation configuration involves the following tasks:

• Identify the CA certificate for the CA that supports the Online Responder.
• Identify the CRL distribution point for the CA.
• Select a signing certificate that will be used to sign revocation status responses.
• Select a revocation provider, the component responsible for retrieving and caching the
revocation information used by the Online Responder.

1. Open the Online Responder snap-in.
2. In the Actions pane, click Add Revocation Configuration to start the Add Revocation
Configurationwizard, and then click Next.
3. On the Name the Revocation Configuration page, type a name for the revocation
11
configuration, such as LH_RC1, and then click Next.
4. On the Select CA certificate Location page, click Select a certificate from an existing
enterprise CA, and then click Next.
5. On the following page, the name of the CA, LH_PKI1, should appear in the Browse CA
certificates published in Active Directory box.
• If it appears, click the name of the CA that you want to associate with your revocation
configuration, and then click Next.
• If it does not appear, click Browse for CA Computer and type the name of the
computer hosting LH_PKI1 or click Browse to locate this computer. When you have
located the computer, click Next.
Note
You might also be able to link to the CA certificate from the local certificate
store, or by importing it from removable media in step 4.
6. View the certificate and copy the CRL distribution point for the parent root CA, RootCA1.
To do this:
a. Open the Certificate Services snap-in. Select an issued certificate.
b. Double-click the certificate, and then click the Details tab.
c. Scroll down and select the CRL Distribution Points field.
d. Select and copy the URL for the CRL distribution point that you want to use.
e. Click OK.
7. On the Select Signing Certificate page, accept the default option, Automatically select
signing certificate, and then click Next.
8. On the Revocation Provider page, click Provider.
9. On the Revocation Provider Properties page, click Add, enter the URL of the CRL
distribution point, and then click OK.
10. Click Finish.
11. Using the Online Responder snap-in, select the revocation configuration, and then
examine the status information to verify that it is functioning properly. You should also be
able to examine the properties of the signing certificate to verify that the Online
Responder is configured properly.
Step 5: Verifying that the AD CS Lab Setup Functions Properly

You can verify the setup steps described previously as you perform them.
After the installation is complete, you should verify that your basic test setup is functioning
properly by confirming that you can autoenroll certificates, revoke certificates, and make accurate
revocation data available from the Onlline responder.
12
To verify that the AD CS test setup functions properly
1. On the CA, configure several certificate templates to autoenroll certificates for LH_CLI1
and users on this computer.
2. When information about the new certificates has been published to AD DS, open a
command prompt on the client computer and enter the following command to start
certificate autoenrollment:
certutil -pulse
3. On LH_CLI1, use the Certificates snap-in to verify that the certificates have been issued
to the user and to the computer, as appropriate.
4. On the CA, use the Certification Authority snap-in to view and revoke one or more of the
issued certificates by clicking Certification Authority (Computer)/CA name/Issued
Certificates and selecting the certificate you want to revoke. On the Action menu, point
to All Tasks, and then click Revoke Certificate. Select the reason for revoking the
certificate, and click Yes.
5. In the Certification Authority snap-in, publish a new CRL by clicking Certification
Authority (Computer)/CA name/Revoked Certificates in the console tree. Then, on the
Action menu, point to All Tasks, and click Publish.
6. Remove all CRL distribution point extensions from the issuing CA by opening the
Certification Authority snap-in and then selecting the CA. On the Action menu, click
Properties.
7. On the Extensions tab, confirm that Select extension is set to CRL Distribution Point
(CDP).
8. Click any CRL distribution points that are listed, click Remove, and then click OK.
9. Stop and restart AD CS.
10. Repeat steps 1 and 2 above, and then verify that clients can still obtain revocation data.
To do this, use the Certificates snap-in to export the certificate to a file (*.cer). At a
certutil -url <exportedcert.cer>
11. In the Verify and Retrieve dialog box that appears, click From CDP and From OCSP
and compare the results.
AD CS Advanced Lab Scenario

The following sections describe how you can set up a lab to evaluate more features of AD CS
than in the basic lab setup.
13
Steps for Setting Up an Advanced Lab
To test additional features of AD CS in a lab environment, you will need five computers running
Windows Server 2008 and one client computer running Windows Vista. The computers for this
guide are named as follows:
• LH_DC1: This computer will be the domain controller for your test environment.
• LH_CA_ROOT1: This computer will host a stand-alone root CA for the test environment.
• LH_CA_ISSUE1: This enterprise CA will be subordinate to LH_CA_ROOT1 and issue client
certificates for the Online Responder and client computers.
Note
• LH_ORS1. This server will host the Online Responder.
• LH_NDES. This server will host the Network Device Enrollment Servicethat makes it possible
to issue and manage certificates for routers and other network devices.
• LH_CLI1: This client computer running Windows Vista will autoenroll for certificates from
LH_CA_ISSUE1 and verify certificate status from LH_ORS1.
To configure the advanced lab setup for AD CS, you need to complete the following prerequisite
steps:
1. Set up a domain controller on LH_DC1 for contoso.com, including some OUs to contain one
or more users for LH_CLI1, client computers in the domain, and for the servers hosting CAs
and Online Responders.
2. Install Windows Server 2008 on the other servers in the test configuration and join them to
the domain.
3. Install Windows Vista on LH_CLI1, and join LH_CLI1 to contoso.com.
After you have completed these preliminary setup procedures, you can begin to complete the
following steps:
Step 1: Setting Up the Stand-Alone Root CA
Step 2: Setting Up the Enterprise Subordinate Issuing CA
Step 3: Installing and Configuring the Online Responder
Step 4: Configuring the Issuing CA to Issue OCSP Response Signing Certificates
Step 5: Configuring the Authority Information Access Extension to Support the Online Responder
Step 6: Assigning the OCSP Response Signing Template to a CA
Step 7: Enrolling for an OCSP Response Signing Certificate
Step 9: Setting Up and Configuring the Network Device Enrollment Service
14
Step 10: Verifying that the Advanced AD CS Test Setup Functions Properly
Step 1: Setting Up the Stand-Alone Root CA

A stand-alone root CA is the anchor of trust for the basic lab setup. It will be used to issue
certificates to the subordinate issuing CA. Because it is critical to the security of the public key
infrastructure (PKI), this CA is online in many PKIs only when needed to issue certificates to
subordinate CAs.
To set up a stand-alone root CA

1. Log on to LH_CA_ROOT1 as an administrator.
2. Start the Add RolesWizard. On the Select Server Roles page, select the Active
Directory Certificate Services check box, and then click Next two times.
3. On the Select Role Services page, select the Certification Authority check box, and
then click Next.
4. On the Specify Setup Type page, click Standalone, and then click Next.
5. On the Specify CA Type page, click Root CA, and then click Next.
configure optional settings, including cryptographic service providers. However, for basic
testing purposes, accept the default values by clicking Next twice.
7. In the Common name for this CA box, type the common name of the CA, RootCA1,
the root CA, and then click Next.
click Next.
Step 2: Setting Up the Enterprise Subordinate Issuing CA

Most organizations use at least one subordinate CA to protect the root CA from unnecessary
exposure. An enterprise CA also allows you to use certificate templates and to use AD DS for
enrollment and publishing certificates.
To set up an enterprise subordinate issuing CA

1. Log on to LH_CA_ISSUE1 as a domain administrator.
Directory Certificate Services check box, and then click Nexttwo times.
15
3. On the Select Role Services page, select the Certification Authority check box, and
then click Next.
4. On the Specify Setup Type page, click Enterprise, and then click Next.
5. On the Specify CA Type page, click Subordinate CA, and then click Next.
configure optional settings, including cryptographic service providers. However, for basic
testing purposes, accept the default values by clicking Next twice.
7. On the Request Certificate page, browse to locate LH_CA_ROOT1, or if, the root CA is
not connected to the network, save the certificate request to a file so that it can be
processed later. Click Next.
The subordinate CA setup will not be usable until it has been issued a root CA certificate
and this certificate has been used to complete the installation of the subordinate CA.
8. In the Common name for this CA box, type the common name of the CA,
LH_CA_ISSUE1.
the CA, and then click Next.
click Next.
Step 3: Installing and Configuring the Online Responder

An Online Responder can be installed on any computer running Windows Server 2008 Enterprise
or Windows Server 2008 Datacenter. The certificate revocation data can come from a CA on a
computer running Windows Server 2008, a CA on a computer running Windows Server 2003, or
from a non-Microsoft CA. An Online Responder will typically not be installed on the same
computer as a CA.
Note
IIS must also be installed on this computer before the Online Responder can be installed.
As part of the setup process a virtual directory named OCSP is created in IIS and the
Web proxy is registered as an Internet Server Application Programming Interface (ISAPI)
extension.
To install the Online Responder service

1. Log on to LH_ORS1 as an administrator.
2. Start the Add Roles Wizard. On the Select Server Rolespage, select the Active
DirectoryCertificate Services check box, and then click Next two times.
16
3. On the Select Role Services page, clear the Certification Authority check box, select
the Online Responder check box, and then click Next.
was successful.
Step 4: Configuring the Issuing CA to Issue OCSP Response

Signing Certificates
As with any certificate template, the OCSP Response Signing template must be configured with
the enrollment permissions for Read, Enroll, Autoenroll, and Write before any certificates can be
issued based on the template.
To configure certificate templates for your test environment

1. Log on to LH_CA_ISSUE1 as a CA administrator.
3. Right-click the OCSP Response Signing template, and then click Duplicate Template.
4. Type a new name for the duplicated template, such as OCSP Response Signing_2.
5. Right-click the OCSP Response Signing_2 certificate template, and then click
Properties.
6. Click the Security tab. Under Group or user name, click Add and type the name or
browse to select the computer hosting the Online Responder service.
7. Click the computer name, LH_ORS1, and in the Permissions dialog box, select the
Read and Autoenroll check boxes.
8. While you have the Certificate Templates snap-in open, you can configure certificate
templates for users and computers by substituting the desired templates in step 3, and
repeating steps 4 through 7 to configure permissions for LH_CLI1 and your test user
accounts.
Step 5: Configuring the Authority Information Access Extension

to Support the Online Responder
You need to configure the CAs to include the URL for the Online Responder as part of the
authority information access extension of the issued certificate. This URL is used by the Online
Responder client to validate the certificate status.
17
To configure the authority information access extension to support the Online
Responder
1. Log on to LH_CA_ISSUE1 as a CA administrator.
3. In the console tree, click the name of the CA.
4. On the Action menu, click Properties.
5. On the Extensions tab, click Select extension, and then click Authority Information
Access (AIA).
6. Select the Include in the AIA extension of issue certificates and Include in the
online certificate status protocol (OCSP) extension check boxes.
7. Specify the locations from which users can obtain certificate revocation data; for this
setup, the location is http://LH_ORS1/ocsp.
8. In the console tree of the Certification Authority snap-in, right-click Certificate
Templates, and then click New Certificate Templates to Issue.
9. In Enable Certificate Templates, select the OCSP Response Signing template and
any other certificate templates that you configured previously, and then click OK.
10. Open Certificate Templates, and verify that the modified certificate templates appear in
the list.
Step 6: Assigning the OCSP Response Signing Template to a CA

Once the templates are properly configured, the CA needs to be configured to issue that
template.
To configure the CA to issue certificates based on the newly created OCSP Response
Signing template
2. Right-click Certificate Templates, and then click Certificate Template to Issue.
3. Select the OCSP Response Signing_2 template from the list of available templates, and
then click OK.
Step 7: Enrolling for an OCSP Response Signing Certificate

Enrollment might not take place right away. Therefore, before you proceed to the next step,
confirm that certificate enrollment has taken place so that a signing certificate exists on the
computer, and verify that the permissions on the signing certificate allow the Online Responder to
use it.
18
To verify that the signing certificate is properly configured
1. Start or restart LH_ORS1 to enroll for the certificates.
2. Log on as a CA administrator.
3. Open the Certificates snap-in for the computer. Open the Personal certificate store for the
computer, and then verify that it contains a certificate titled OCSP Response Signing_2.
4. Right-click this certificate, and then click Manage Private Keys.
5. Click the Security tab. In the User Group or user name dialog box, click Add to type in
and add Network Service to the Group or user name list, and then click OK.
6. Click Network Service, and in the Permissions dialog box, select the Full Control
check box. Click OK twice.

Creating a revocation configuration involves the following tasks:
• Identify the CA certificate for the CA that supports the Online Responder.
• Identify the CRL distribution point for the CA.
• Select a signing certificate that will be used to sign revocation status responses.
• Select a revocation provider, the component responsible for retrieving and caching the
revocation information used by the Online Responder.

1. Log on to LH_ORS1 as a domain administrator.
2. Open the Online Responder snap-in.
3. In the Actions pane, click Add Revocation Configuration to start the Add Revocation
Configuration wizard, and then click Next.
4. On the Name the Revocation Configuration page, type a name for the revocation
configuration, such as LH_RC1, and then click Next.
5. On the Select CA Certificate Location page, click Select a certificate for an existing
enterprise CA, and then click Next.
6. On the following page, the name of the CA, LH_CA_ISSUE1, should appear in the
Browse CA certificates published in Active Directory box.
• If it appears, click the name of the CA that you want to associate with your revocation
configuration, and then click Next.
• If it does not appear, click Browse for CA Computer and type the name of the
computer hosting LH_CA_ISSUE1 or click Browse to locate this computer. When
you have located the computer, click Next.
Note
19
You might also be able to link to the CA certificate from the local certificate
store, or by importing it from removable media in step 5.
7. View the certificate and copy the CRL distribution point for the parent root CA, RootCA1.
To do this:
a. Open the Certificate Services snap-in, and then select an issued certificate.
b. Double-click the certificate, and then click the Details tab.
c. Scroll down and select the CRL Distribution Points field.
d. Select and copy the URL for the CRL distribution point that you want to use.
e. Click OK.
8. On the Select Signing Certificate page, accept the default, Automatically select
signing certificate, and then click Next.
9. On the Revocation Provider page, click Provider.
10. On the Revocation Provider Properties page, click Add, enter the URL of the CRL
distribution point, and then click OK.
11. Click Finish.
12. Using the Online Responder snap-in, select the revocation configuration, and then
examine the status information to verify that it is functioning properly. You should also be
able to examine the properties of the signing certificate to verify that the Online
Responder is configured properly.
Step 9: Setting Up and Configuring the Network Device

Enrollment Service
The Network Device Enrollment Service allows software on routers and other network devices
running without domain credentials to obtain certificates.
The Network Device Enrollment Service operates as an ISAPI filter on IIS that performs the
following functions:
• Generates and provides one-time enrollment passwords to administrators
• Processes SCEP enrollment requests
• Retrieves pending requests from the CA
SCEP was developed as an extension to existing HTTP, PKCS #10, PKCS #7, RFC 2459, and
other standards to enable network device and application certificate enrollment with CAs. SCEP
is identified and documented on the Internet Engineering Task Force Web site
Before you begin this procedure, create a user ndes_user1 and add this user to the IIS user
group. Then, use the Certificate Templates snap-in to configure Read and Enroll permissions for
this user on the IPSEC (Offline Request) certificate template.
20
To set up and configure the Network Device Enrollment Service
1. Log on to LH_NDES as an enterprise administrator.
Directory Certificate Services check box, and then click Next two times.
3. On the Select Role Services page, clear the Certification Authority check box, and
then select Network Device Enrollment Service.
was successful.
7. Because this is a new installation and there are no pending SCEP certificate requests,
click Replace existing Registration Authority (RA) certificates, and then click Next.
When the Network Device Enrollment Service is installed on a computer where a
registration authority already exists, the existing registration authority and any pending
certificate requests are deleted.
8. On the Specify User Account page, click Select User, and type the user name
ndes_user1 and password for this account, which the Network Device Enrollment
Service will use to authorize certificate requests. Click OK, and then click Next.
9. On the Specify CA page, select either the CA name or Computer name check box,
click Browse to locate the CA that will issue the Network Device Enrollment Service
certificates, LH_CA_ISSUE1, and then click Next.
10. On the Specify Registry Authority Information page, type ndes_1 in the RA name
box. Under Country/region,select the check box for the country/region you are in, and
then click Next.
11. On the Configure Cryptography page, accept the default values for the signature and
encryption keys, and then click Next.
12. Review the summary of configuration options, and then click Install.
Step 10: Verifying that the Advanced AD CS Test Setup

Functions Properly
You can verify the setup steps described previously as you perform them.
After the installation is complete, you should verify that your advanced test setup is functioning
properly.
21
To verify that the advanced AD CS test setup functions properly
1. On the CA, configure several certificate templates to autoenroll certificates for LH_CLI1
and users on this computer.
2. When information about the new certificates has been published to AD DS, open a
command prompt on the client computer and enter the following command to start
certificate autoenrollment:
certutil -pulse
3. On the client computer, use the Certificates snap-in to verify that the certificates have
been issued to the user and to the computer, as appropriate.
4. On the CA, use the Certification Authority snap-in to view and revoke one or more of the
issued certificates by clicking Certification Authority (Computer)/CA name/Issued
Certificates and selecting the certificate you want to revoke. On the Action menu, point
to All Tasks, and then click Revoke Certificate. Select the reason for revoking the
certificate, and click Yes.
5. In the Certification Authority snap-in, publish a new CRL by clicking Certification
Authority (Computer)/CA name/Revoked Certificates in the console tree. Then, on the
Action menu, point to All Tasks, and click Publish.
6. Remove all CRL distribution point extensions from the issuing CA by opening the
Certification Authority snap-in and then selecting the CA. On the Action menu, click
Properties.
7. On the Extensions tab, confirm that Select extension is set to CRL Distribution Point
(CDP).
8. Click any CRL distribution points that are listed, click Remove, and click OK.
9. Stop and restart AD CS.
10. Repeat steps 1 and 2 above, and then verify that clients can still obtain revocation data.
To do this, use the Certificates snap-in to export the certificate to a file (*.cer). At a
certutil -url <exportedcert.cer>
11. In the Verify and Retrieve dialog box that appears, click From CDP and From OCSP
and compare the results.
22
Windows Server 2008 RC0 Terminal Services
RemoteApp Step-by-Step Guide
Writer: Tessa Wooley
Abstract
Terminal Services RemoteApp™ (TS RemoteApp) is a feature that enables users to access
programs remotely through Terminal Services. The remote programs appear as if they are
running on the user's local computer. Users can run RemoteApp programs side-by-side with their
local programs. If a user is running more than one RemoteApp program on the same terminal
server, the RemoteApp programs will share the same Terminal Services session. You can use
Terminal Services Web Access (TS Web Access) to make RemoteApp programs available
through a Web site.
1
Active Directory, Microsoft, MS-DOS, RemoteApp, Visual Basic, Visual Studio, Windows,
Windows NT, and Windows Server are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
2
Contents
Windows Server 2008 RC0 Terminal Services RemoteApp Step-by-Step Guide .......................... 5
What are RemoteApp programs? ................................................................................................ 5
Who should use TS RemoteApp? ................................................................................................ 6
Key scenarios for TS RemoteApp ............................................................................................ 6
How should I deploy RemoteApp programs? .............................................................................. 7
About deploying RemoteApp programs through TS Web Access............................................ 8
About deploying RemoteApp programs through a file share or other distribution mechanism 9
Configure the server that will host RemoteApp programs ......................................................... 10
Install the Terminal Server role service .................................................................................. 11
Install programs on the terminal server .................................................................................. 11
Verify remote connection settings........................................................................................... 12
Add RemoteApp programs and configure global deployment settings ...................................... 13
Add programs to the RemoteApp Programs list ..................................................................... 13
Configure global deployment settings..................................................................................... 14
Configure terminal server settings....................................................................................... 15
Configure TS Gateway settings........................................................................................... 16
Configure common RDP settings (optional) ........................................................................ 17
Configure custom RDP settings (optional) .......................................................................... 18
Configure digital signature settings (optional) ..................................................................... 19
Manage RemoteApp programs and settings .......................................................................... 21
Change or delete a RemoteApp program ........................................................................... 21
Export or import RemoteApp programs and settings .......................................................... 22
Deploy RemoteApp programs to users ...................................................................................... 23
Deploy RemoteApp programs through TS Web Access ........................................................ 23
Install the TS Web Access role service ............................................................................... 23
Populate the TS Web Access Computers security group ................................................... 24
Configure the data source for TS Web Access ................................................................... 25
Connect to TS Web Access ................................................................................................ 26
Deploy RemoteApp programs through file sharing or other distribution methods.................. 27
Create an .rdp file from a RemoteApp program .................................................................. 27
Create a Windows Installer package from a RemoteApp program ..................................... 28
Make RemoteApp programs available from the Internet ........................................................... 30
Configure the TS Web Access server to allow access from the Internet ............................... 31
Additional information ................................................................................................................. 32
Upgrading from Windows Server 2008 Beta 3 to Windows Server 2008 RC0 ...................... 32
Configure Server Manager and Initial Tasks not to run in administrator's RemoteApp session
............................................................................................................................................. 33
3
Configure Remote Desktop Web Connection behavior .......................................................... 33
4
Windows Server 2008 RC0 Terminal Services
RemoteApp Step-by-Step Guide
With Terminal Services, organizations can provide access to Windows®-based programs from
almost any location to almost any computing device. Terminal Services in
Windows Server® 2008 includes Terminal Services RemoteApp™ (TS RemoteApp). You can use
several different methods to deploy RemoteApp programs, such as Terminal Services Web
Access (TS Web Access). With TS Web Access, you can provide access to RemoteApp
programs through a Web page over the Internet or over an intranet. TS Web Access is also
included in Windows Server 2008.
What are RemoteApp programs?

RemoteApp programs are programs that are accessed remotely through Terminal Services and
appear as if they are running on the end user's local computer. Instead of being presented to the
user in the desktop of the remote terminal server, the RemoteApp program is integrated with the
client's desktop, running in its own resizable window with its own entry in the taskbar. Users can
run RemoteApp programs side-by-side with their local programs. If a user is running more than
one RemoteApp program on the same terminal server, the RemoteApp programs will share the
same Terminal Services session.
In Windows Server 2008, users can access RemoteApp programs in several ways, depending on
the deployment method that you choose. They can:
• Access a link to the program on a Web site by using TS Web Access.
• Double-click a Remote Desktop Protocol (.rdp) file that has been created and distributed by
their administrator.
• Double-click a program icon on their desktop or Start menu that has been created and
distributed by their administrator with a Windows Installer (.msi) package.
• Double-click a file where the file name extension is associated with a RemoteApp program.
This can be configured by their administrator with a Windows Installer package.
The .rdp files and Windows Installer packages contain the settings that are needed to run
RemoteApp programs. After opening a RemoteApp program on their local computer, the user can
interact with the program that is running on the terminal server as if it were running locally.
Important
To access RemoteApp programs that are deployed as .rdp files or as Windows Installer
packages, the client computer must be running Remote Desktop Connection (RDC) 6.0
or RDC 6.1. (RDC 6.1 supports Remote Desktop Protocol 6.1.) To access RemoteApp
programs through TS Web Access, the client computer must be running RDC 6.1.
5
RDC 6.1 is included with Windows Server 2008 and Windows Vista Service Pack 1 (SP1)
Beta. To download RDC 6.0 for Windows Server 2003 with Service Pack 1 (SP1) or
Windows XP with Service Pack 2 (SP2), see article 925876 in the Microsoft® Knowledge
Base (http://go.microsoft.com/fwlink/?LinkId=79373).
Who should use TS RemoteApp?

This guide is intended for the following audiences:
• IT planners and analysts who are evaluating the product
• Enterprise architects
• IT professionals who deploy or administer terminal servers, line-of-business (LOB)
applications, or applications that can be more efficiently deployed with TS RemoteApp
Key scenarios for TS RemoteApp

TS RemoteApp is especially useful in scenarios such as the following:
• Remote users. Users often need to access programs from remote locations, such as while
working from home or while traveling. If you want users to access RemoteApp programs over
an Internet connection, you can allow access through a Virtual Private Network (VPN), or you
can deploy TS RemoteApp together with Terminal Services Gateway (TS Gateway) to help
secure remote access to the programs.
• Branch offices. In a branch office environment, there may be limited local IT support and
limited network bandwidth. By using TS RemoteApp, you can centralize the management of
your applications and improve remote program performance in limited bandwidth scenarios.
• Line-of-business (LOB) applications deployment. Companies often need to run consistent
LOB applications on computers that are running different Windows versions and
configurations. Instead of deploying the LOB applications to all the computers in the
company, which can be expensive in terms of time and cost, you can install the LOB
applications on a terminal server and make them available through TS RemoteApp.
• Application deployment. With TS RemoteApp you do not have to deploy and maintain
different versions of the same program for individual computers. If employees need to use
multiple versions of a program, you can install those versions on one or more terminal
servers, and users can access them through TS RemoteApp.
• Roaming users. In a company with a flexible desk policy, users can work from different
computers. In some cases, the computer where a user is working may not have the
necessary programs installed locally. By using TS RemoteApp, you can install the programs
on a terminal server and make them available to users as if those programs were installed
locally.
6
How should I deploy RemoteApp programs?
Before you configure TS RemoteApp, you should decide how you want to distribute RemoteApp
programs to users. You can use either of the following deployment methods:
• You can make RemoteApp programs available on a Web site by distributing the RemoteApp
programs through TS Web Access.
• You can distribute RemoteApp programs as .rdp files or Windows Installer packages through
a file share, or through other distribution mechanisms such as Microsoft Systems
Management Server or Active Directory software distribution.
7
RemoteApp deployment components
About deploying RemoteApp programs through TS Web Access

If you use TS Web Access, you can deploy RemoteApp programs from a single terminal server or
farm, or a link to the full terminal server desktop, directly through TS Web Access. All RemoteApp
programs on the terminal server or farm that are configured for TS Web Access will appear on the
TS Web Access Web site.
8
Note
Additionally, TS Web Access includes the Remote Desktop Web Connection feature,
which allows users to connect from a Web browser to the remote desktop of any server
or client computer where they have Remote Desktop access. You can determine whether
you want this feature to be available to users. For more information, see Configure
Remote Desktop Web Connection Behavior.
To deploy RemoteApp programs by using TS Web Access, you must complete the following
tasks.
Task Reference
1. Configure the server that will host Configure the server that will host RemoteApp
RemoteApp programs. This includes installing programs
Terminal Server, installing programs, and
verifying remote connection settings.
2. Use TS RemoteApp Manager to add Add RemoteApp programs and configure global
RemoteApp programs that are enabled for deployment settings
TS Web Access, and to configure global
deployment settings.
3. Install TS Web Access on the server that you Install the TS Web Access role service
want users to connect to over the Web to
access RemoteApp programs.
4. Add the computer account of the TS Web Populate the TS Web Access Computers
Access server to the TS Web Access security group
Computers group on the terminal server.
5. Configure the TS Web Access server to Configure the data source for TS Web Access
populate its list of RemoteApp programs from a
single terminal server or single farm.
About deploying RemoteApp programs through a file share or

other distribution mechanism
You can also deploy RemoteApp programs through .rdp files or Windows Installer packages that
are made available through file sharing, or through other distribution mechanisms such as
Microsoft Systems Management Server or Active Directory software distribution. These methods
enable you to distribute RemoteApp programs to users without using TS Web Access.
9
Note
If you distribute RemoteApp programs through Windows Installer packages, you can also
configure whether the terminal server will take over client file name extensions for the
RemoteApp programs. If this is the case, a user can double-click a file where the file
name extension is associated with a RemoteApp program.
You must complete the following tasks to prepare RemoteApp programs for distribution through a
file share or some other distribution mechanism.
Task Reference
1. Configure the server that will host Configure the server that will host RemoteApp
RemoteApp programs. This includes installing programs
Terminal Server, installing programs, and
verifying remote connection settings.
2. Use TS RemoteApp Manager to add Add RemoteApp programs and configure global
RemoteApp programs and to configure global deployment settings
deployment settings.
3. Use TS RemoteApp Manager to create .rdp • Create an .rdp file from a RemoteApp
files or Windows Installer packages from program
RemoteApp programs. • Create a Windows Installer package from a
RemoteApp program
After you create .rdp files or Windows Installer packages, you can distribute them to users.
Configure the server that will host RemoteApp

programs
Before you can deploy RemoteApp programs to users, you must configure the server to host
RemoteApp programs. The following procedures are covered:
• Install the Terminal Server role service
• Install programs on the terminal server
• Verify remote connection settings
Note
These procedures apply to an environment where you are using a single terminal server
to host RemoteApp programs.
To perform these procedures, you must be a member of the Administrators group on the
terminal server.
10
Install the Terminal Server role service
To install the Terminal Server role service
2. Under Roles Summary, click Add Roles.
3. On the Before You Begin page of the Add Roles Wizard, click Next.
4. On the Select Server Roles page, select the Terminal Services check box, and then
click Next.
click Next.
7. On the Uninstall and Reinstall Applications for Compatibility page, review the
information, and then click Next.
8. On the Specify Authentication Method for Terminal Server page, select the desired
authentication method, and then click Next.
Note
If you select Require Network Level Authentication, at the time of the
Windows Server 2008 RC0 release, only clients that are running Windows
Server 2008 or Windows Vista with RDC 6.0 or a later version of the RDC client
can connect to the terminal server.
9. On the Specify Licensing Mode page, select the licensing mode that applies to your
Terminal Services environment, and then click Next.
10. On the Select User Groups Allowed Access To This Terminal Server page, add any
users or groups that you want to add to the Remote Desktop Users group, and then click
Next.
13. After the server restarts, the Resume Configuration Wizard completes the installation.
When you see an Installation succeeded status message on the Installation Results
page, click Close.
Install programs on the terminal server

We recommend that you install programs on the terminal server after you have installed the
Terminal Server role service. If you install a program from a Windows Installer package, the
11
program will automatically install in Terminal Server Install mode. If you are installing from
another kind of Setup package, use either of the following methods to put the server into Install
mode:
• Use the Install Application on Terminal Server option in Control Panel to install the
program.
• Before you install a program, run the change user /install command from the command line.
After the program is installed, run the change user /execute command to exit from Install
mode.
If you have programs that are related to each other or have dependencies on each other, we
recommend that you install the programs on the same terminal server. For example, we
recommend that you install Microsoft Office as a suite instead of installing individual Office
programs on separate terminal servers.
You should consider putting individual programs on separate terminal servers in the following
circumstances:
• The program has compatibility issues that may affect other programs.
• A single program and the number of associated users may fill server capacity.
Verify remote connection settings

By default, remote connections are enabled after you install the Terminal Server role service. You
can use the following procedure to add users and groups that need to connect to the terminal
server, and to verify or to change remote connection settings.
To verify remote connection settings

1. Start the System tool. To do this, click Start, click Run, type control system in the Open
box, and then click OK.
2. Under Tasks, click Remote settings.
3. In the System Properties dialog box, on the Remote tab, ensure that the Remote
Desktop connection setting is configured correctly, depending on your environment. You
can select either of the following options:
• Allow connections from computers running any version of Remote Desktop
(less secure)
• Allow connections only from computers running Remote Desktop with Network
Level Authentication (more secure)
For more information about the two options, on the Remote tab, click the Help me
choose link.
4. To add the users and groups that need to connect to the terminal server by using Remote
Desktop, click Select Users, and then click Add.
12
The users and groups that you add are added to the Remote Desktop Users group.
Note
Members of the local Administrators group can connect even if they are not
listed.
5. When you are finished, click OK to close the System Properties dialog box.
Add RemoteApp programs and configure global

deployment settings
After you have prepared the terminal server to host RemoteApp programs, you can use
TS RemoteApp Manager to do the following:
• Add programs to the RemoteApp Programs list
• Configure global deployment settings
In TS RemoteApp Manager, you can also delete, modify, import RemoteApp programs and
settings from another terminal server, or export RemoteApp programs and settings to another
terminal server. For more information, see Manage RemoteApp programs and settings.
Add programs to the RemoteApp Programs list

To make a RemoteApp program available to users through any distribution mechanism, you must
add the program to the RemoteApp Programs list. By default, programs that you add to the list
are configured to be available through TS Web Access.
To add a program to the RemoteApp Programs list

1. Start TS RemoteApp Manager. To do this, click Start, point to Administrative Tools,
point to Terminal Services, and then click TS RemoteApp Manager.
2. In the Actions pane, click Add RemoteApp Programs.
3. On the Welcome to the RemoteApp Wizard page, click Next.
4. On the Choose programs to add to the RemoteApp Programs list page, select the
check box next to each program that you want to add to the RemoteApp Programs list.
You can select multiple programs.
Note
The programs that are shown on the Choose programs to add to the
RemoteApp Programs list page are the programs that are found on the All
Users Start menu on the terminal server. If the program that you want to add to
the RemoteApp Programs list is not in the list, click Browse, and then specify
the location of the program's .exe file.
13
5. To configure the properties for a RemoteApp program, click the program name, and then
click Properties. You can configure the following:
• The program name that will appear to users. To change the name, type a new name
in the RemoteApp program name box.
• The path of the program executable file. To change the path, type the new path in the
Location box, or click Browse to locate the .exe file.
Note
You can use system environment variables in the path name. For example,
you can substitute %windir% for the explicit path of the Windows folder (such
as C:\Windows). You cannot use per user environment variables.
• The alias for the RemoteApp program. The alias is a unique identifier for the program
that defaults to the program's file name (without the extension). We recommend that
you do not change this name.
• Whether the RemoteApp program is available through TS Web Access. By default,
the RemoteApp program is available through TS Web Access setting is enabled.
To change the setting, select or clear the check box.
• Whether command-line arguments are allowed, not allowed, or whether to always
use the same command-line arguments.
• The program icon that will be used. To change the icon, click Change Icon.
6. When you are finished configuring program properties, click OK, and then click Next.
7. On the Review Settings page, review the settings, and then click Finish.
The programs that you selected should appear in the RemoteApp Programs list.
Configure global deployment settings

You can configure global deployment settings that apply to all RemoteApp programs in the
RemoteApp Programs list. These settings will apply to any RemoteApp program that you make
available through TS Web Access. Additionally, these settings will be used as the default settings
if you create .rdp files or Windows Installer packages from any of the listed RemoteApp
programs.
Note
Any changes to deployment settings that you make when you use TS RemoteApp
Manager to create .rdp files or Windows Installer packages will override the global
settings.
These global deployment settings include:
• Terminal server settings
• TS Gateway settings
14
• Common Remote Desktop Protocol (RDP) settings
• Custom RDP settings
• Digital signature settings
Configure terminal server settings

To define how users will connect to the terminal server (or terminal server farm) to access
RemoteApp programs, you can configure terminal server deployment settings.
To configure terminal server settings

1. In the Actions pane of TS RemoteApp Manager, click Terminal Server Settings. (Or, in
the Overview pane, next to Terminal Server Settings, click Change.)
2. On the Terminal Server tab, under Connection settings, accept or modify the server or
farm name, the RDP port number, and server authentication settings.
Important
If the Require server authentication check box is selected, consider the
following:
• If any client computers are running Windows Server 2003 with SP1 or Windows XP
with SP2, you must configure the terminal server to use a Secure Sockets Layer
(SSL) certificate. (You cannot use a self-signed certificate.)
• If the RemoteApp program is for intranet use, and all client computers are running
either Windows Server 2008 or Windows Vista, you do not have to configure the
terminal server to use an SSL certificate. In this case, Network Level Authentication
is used.
3. To provide a link to the full terminal server desktop through TS Web Access, under
Remote desktop access, select the Show a remote desktop connection to this
terminal server in TS Web Access check box.
4. Under Access to unlisted programs, choose either of the following:
• Do not allow users to start unlisted program on initial connection
(Recommended)
To help protect against malicious users, or a user unintentionally starting a program
from an .rdp file on initial connection, we recommended that you select this setting.
Important
This setting does not prevent users from starting unlisted programs remotely
after they connect to the terminal server by using the RemoteApp program.
For example, if Microsoft Word is in the RemoteApp Programs list and
Microsoft Internet Explorer is not, if a user starts a remote Word session, and
then clicks a hyperlink in a Word document, they can start Internet Explorer.
15
• Allow users to start both listed and unlisted programs on initial connection
Caution
If you choose this option, users can start any program remotely from an .rdp
file on initial connection, not just those programs in the RemoteApp
Programs list. To help protect against malicious users, or a user
unintentionally starting a program from an .rdp file, we recommend that you
do not select this setting.
5. When you are finished, click OK.
Configure TS Gateway settings

To define whether users will connect to the terminal server across a firewall through TS Gateway,
you can configure TS Gateway deployment settings. For more information about TS Gateway,
see the TS Gateway Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=85872).
To configure TS Gateway settings

1. In the Actions pane of TS RemoteApp Manager, click TS Gateway Settings. (Or, in the
Overview pane, next to TS Gateway Settings, click Change.)
2. On the TS Gateway tab, configure the desired TS Gateway behavior. You can configure
whether to automatically detect TS Gateway server settings, to use TS Gateway server
settings that you specify, or to not use a TS Gateway server.
If you select Automatically detect TS Gateway server settings, the client tries to use
Group Policy settings to determine the behavior of client connections to TS Gateway.
Note
For more information about client Group Policy settings, see the Help topic
"Using Group Policy to Manage Client Connections Through TS Gateway." (To
open TS Gateway Help on a Windows Server 2008-based server, click Start,
click Run, type hh ts_gateway.chm, and then click OK.)
If you select Use these TS Gateway server settings, do the following:
a. Configure the TS Gateway server name and the logon method.
Important
The server name must match what is specified in the SSL certificate for the
TS Gateway server.
b. If you want the connection to try to use the same user credentials to access both the
TS Gateway server and the terminal server, select the Use the same user
credentials for TS Gateway and terminal server check box. However, users may
still receive two prompts for credentials if conflicting credentials exist from any source
such as Group Policy settings, and those credentials do not work. They may also
16
receive two prompts for credentials if default credentials are used for the connection
and those credentials do not work.
c. If you want the client computer to automatically detect when TS Gateway is required,
select the Bypass TS Gateway server for local addresses check box. (Selecting
this option optimizes client performance.)
To always use a TS Gateway server for client connections, clear the Bypass TS
Gateway server for local addresses check box.
Configure common RDP settings (optional)

You can specify common Remote Desktop Protocol (RDP) settings for RemoteApp connections,
such as device and resource redirection, and some user display settings. These settings will
apply when a user connects to a RemoteApp program through TS Web Access, or when you
create an .rdp file or a Windows Installer package from an existing RemoteApp program.
To configure common RDP settings

1. In the Overview pane of TS RemoteApp Manager, next to RDP Settings, click Change.
2. Under Devices and resources, configure which devices and resources on the client
computer you want to make available in the remote session.
3. Under User experience, choose whether to enable font smoothing and the desired color
depth.
4. When you are finished, click Apply.
Note
To configure additional RDP settings, such as audio redirection, click the
Custom RDP Settings tab. For more information, see Configure Custom RDP
Settings.
5. To close the RemoteApp Deployment Settings dialog box, click OK.
Note
If you do not sign .rdp files with a digital signature, or if you sign .rdp files with a digital
signature that clients do not recognize (such as a certificate from a private certification
authority), some redirection settings that you specify in TS RemoteApp Manager may be
overridden by the client. For example, if you enable all redirection settings on the
Common RDP Settings tab, and a user connects to an .rdp file that is not signed, disk
drives, and supported Plug and Play devices will not be redirected automatically. These
devices and resources will only be redirected if the user enables these redirection
settings in the RemoteApp warning dialog box that appears when they try to connect.
This default behavior helps to reduce potential security vulnerabilities. (Note that the
17
same behavior occurs if you enable serial port redirection on the Custom RDP Settings
tab.)
Configure custom RDP settings (optional)

You can specify custom RDP settings for RemoteApp connections, such as audio redirection.
These settings will apply when a user connects to a RemoteApp program through TS Web
Access, or when you create a Windows Installer package or .rdp file from an existing RemoteApp
program.
Note
You can use custom RDP settings to configure the working directory for RemoteApp
programs. By default, the working directory for a RemoteApp program is the same
location as the program executable file. If you configure the working directory as a
custom RDP setting, the setting will apply to all RemoteApp programs that are available
through TS Web Access, and to any .rdp files or Windows Installer packages that you
create from a RemoteApp program. If you want to customize the working directory for
RemoteApp programs that you plan to distribute as .rdp files or Windows Installer
packages, you can add the working directory as a custom RDP setting, create the files
from the RemoteApp programs, and then clear the working directory custom RDP setting.
To specify custom RDP settings

1. In the Overview pane of TS RemoteApp Manager, next to RDP Settings, click Change.
2. On the Custom RDP Settings tab, type or copy the custom RDP settings that you want
to use into the Custom RDP settings box.
To copy settings from an existing .rdp file, open the file in a text editor such as Notepad,
and then copy the desired settings.
Important
You cannot override settings that are available in the global deployment settings
in TS RemoteApp Manager. If you do so, you will be prompted to remove those
settings when you click Apply.
To create an .rdp file to copy the settings from, follow these steps:
a. Open the RDC client, and then click Options.
b. Configure the settings that you want, such as audio redirection.
c. When you are finished, on the General tab, click Save As, and then save the .rdp
file.
d. Open the .rdp file in Notepad, and then copy the desired settings into the Custom
RDP settings box on the Custom RDP Settings tab.
3. When you have finished adding the settings that you want, click Apply.
18
4. If the Error with Custom RDP Settings dialog box appears, do the following:
a. Click Remove to automatically remove the settings that are either not valid or cannot
be overridden, or click OK to remove the settings manually.
b. After the settings are removed, click Apply again.
5. To close the RemoteApp Deployment Settings dialog box, click OK.
Configure digital signature settings (optional)

You can use a digital signature to sign .rdp files that are used for RemoteApp connections to the
terminal server. This includes the .rdp files that are used for connections through TS Web Access
to RemoteApp programs on the terminal server and to the terminal server desktop.
Important
To connect to a RemoteApp program by using a digitally signed .rdp file, the client must
be running RDC 6.1. (The RDC 6.1 client supports Remote Desktop Protocol 6.1.)
If you use a digital certificate, the cryptographic signature on the connection file provides
verifiable information about your identity as its publisher. This enables clients to recognize your
organization as the source of the RemoteApp program or the remote desktop connection, and
allows them to make more informed trust decisions about whether to start the connection. This
helps protect against the use of .rdp files that were altered by a malicious user.
You can sign .rdp files that are used for RemoteApp connections by using a Server
Authentication certificate (SSL certificate) or a Code Signing certificate. You can obtain SSL and
Code Signing certificates from public certification authorities (CAs), or from an enterprise CA in
your public key infrastructure hierarchy.
If you are already using an SSL certificate for terminal server or TS Gateway connections, you
can use the same certificate to sign .rdp files. However, if users will connect to RemoteApp
programs from public or home computers, you must use either of the following:
• A certificate from a public certification authority (CA) that participates in the Microsoft Root
Certificate Program Members program (http://go.microsoft.com/fwlink/?LinkID=59547).
• If you are using an enterprise CA, your enterprise CA-issued certificate must be co-signed by
a public CA that participates in the Microsoft Root Certification Program Members program.
To configure the digital certificate to use

1. In the Actions pane of TS RemoteApp Manager, click Digital Signature Settings. (Or,
in the Overview pane, next to Digital Signature Settings, click Change.)
2. Select the Sign with a digital certificate check box.
3. In the Digital certificate details box, click Change.
4. In the Select Certificate dialog box, select the certificate that you want to use, and then
click OK.
19
Note
The Select Certificate dialog box is populated by certificates that are located in
the local computer's certificates store or in your personal certificate store. The
certificate that you want to use must be located in one of these stores.
Group Policy settings to control client behavior when opening a digitally signed .rdp file
You can use Group Policy to configure clients to always recognize RemoteApp programs from a
particular publisher as trusted. You can also configure whether clients will block RemoteApp
programs and remote desktop connections from external or unknown sources. By using these
policy settings, you can reduce the number and complexity of security decisions that users face.
This reduces the chances of inadvertent user actions that may lead to security vulnerabilities.
The relevant Group Policy settings are located in the Local Group Policy Editor at the following
location, in both the Computer Configuration and in the User Configuration node:
Administrative Templates\Windows Components\Terminal Services\Remote Desktop
Connection Client
The available policy settings are:
• Specify SHA1 thumbprints of certificates representing trusted .rdp publishers
This policy setting allows you to specify a list of Secure Hash Algorithm 1 (SHA1) certificate
thumbprints that represent trusted .rdp file publishers. If you enable this policy setting, any
certificate with an SHA1 thumbprint that matches a thumbprint on the list will be considered
trusted.
• Allow .rdp files from valid publishers and user’s default .rdp settings
This policy setting allows you to specify whether users can run .rdp files from a publisher that
signed the file with a valid certificate. This policy setting also controls whether the user can
start an RDP session by using default .rdp settings, such as when a user directly opens the
RDC client without specifying an .rdp file.
• Allow .rdp files from unknown publishers
This policy setting allows you to specify whether users can run unsigned .rdp files and .rdp
files from unknown publishers on the client computer.
Important
To use these Group Policy settings, the client computer must be running RDC 6.1.
For more information about these policy settings, view the Group Policy Explain text in the Local
Group Policy Editor.
20
Manage RemoteApp programs and settings
In TS RemoteApp Manager, you can make changes to an existing RemoteApp program, or you
can remove the program from the list. Additionally, you can export or import the RemoteApp
Programs list and the global deployment settings to or from another terminal server.
• Change or delete a RemoteApp program
• Export or import RemoteApp programs and settings
Change or delete a RemoteApp program

After you have added a program to the RemoteApp Programs list, you can change the
deployment settings for all RemoteApp programs, change the properties of a single RemoteApp
program, or delete the RemoteApp program from the list.
• To change deployment settings for all RemoteApp programs, in the Actions pane of
TS RemoteApp Manager, click Terminal Server Settings, TS Gateway Settings, or Digital
Signature Settings. (Or, click one of the Change options in the Overview pane. You can
also change custom RDP settings in the Overview pane.)
Important
If you make any changes, the changes will not affect .rdp files or Windows Installer
packages that you already created by using TS RemoteApp Manager.
• To change the properties of a single RemoteApp program, click the program in the
RemoteApp Programs list, and then in the Actions pane for the program, click Properties.
Note
You cannot change the properties of an existing .rdp file or Windows Installer
package by using TS RemoteApp Manager. Instead, you must click Create .rdp File
or Create Windows Installer Package in the Actions pane to create a new .rdp file
or Windows Installer package that has the desired properties.
• To change whether the RemoteApp program will be available from TS Web Access, click the
program, and then click Show in TS Web Access or Hide in TS Web Access in the
Actions pane.
• To delete a program in the RemoteApp Programs list, click the RemoteApp program, and
then in the Actions pane for the program, click Remove. Click Yes to confirm the deletion.
Note
When you delete a program in the RemoteApp Programs list, any .rdp files or
Windows Installer packages that you created from the RemoteApp program are not
deleted.
21
Export or import RemoteApp programs and settings
You can copy the RemoteApp Programs list and deployment settings from one terminal server
to another terminal server. You might want to do this if you want to configure multiple terminal
servers identically to host RemoteApp programs, such as in a terminal server farm.
To export the RemoteApp Programs list and deployment settings

1. Start TS RemoteApp Manager.
2. In the Actions pane, click Export RemoteApp Settings.
3. Select either of the following options:
• Export the RemoteApp Programs list and settings to another terminal server
If you select this option, in the Terminal server name box, enter the name of the
terminal server that you want to export the settings to, and then click OK. (For the
export operation to succeed, the source terminal server must have Windows
Management Instrumentation (WMI) access to the target terminal server.)
Important
When you click OK, the RemoteApp Programs list and deployment settings
will be automatically overwritten on the target terminal server.
• Export the RemoteApp Programs list and settings to a file
If you select this option, click OK. In the Save As dialog box, specify a location to
save the .tspub file, and then click Save.
To import the RemoteApp Programs list and deployment settings

1. Start TS RemoteApp Manager.
2. In the Actions pane, click Import RemoteApp Settings.
3. Select either of the following options:
• Import the RemoteApp Programs list and settings from another terminal server
If you select this option, in the Terminal server name box, enter the name of the
terminal server that you want to import the settings from, and then click OK. The
settings are imported directly into TS RemoteApp Manager. (For the import operation
to succeed, the source terminal server must have WMI access to the target terminal
server.)
• Import the RemoteApp Programs list and settings from a file
If you select this option, click OK. In the Open dialog box, locate and then click the
.tspub file that you want to import, and then click Open.
If you import a configuration, and the target terminal server does not have a program in the
RemoteApp Programs list installed or the program is installed in a different folder, the program
22
will appear in the RemoteApp Programs list. However, the name will be displayed with
strikethrough text.
Note
Only the RemoteApp Programs list and deployment settings are exported or imported.
Any .rdp files or Windows Installer packages that were created from the programs will not
be exported or imported. You must create new .rdp files or Windows Installer packages
on each terminal server unless the server is a member of a terminal server farm. If you
specified a farm name when you created the .rdp files or Windows Installer packages,
and the server where you want to copy the files to is a member of the same terminal
server farm, you can manually copy the files.
Deploy RemoteApp programs to users

The following section includes instructions about how to deploy RemoteApp programs to users
through TS Web Access or through a file share or other distribution mechanism.
Deploy RemoteApp programs through TS Web Access

With TS Web Access, users can access RemoteApp programs from a Web site over the Internet
or from an intranet. To start a RemoteApp program, they just click the program icon. TS Web
Access provides a solution that works with minimal configuration. The default TS Web Access
Web page includes a customizable Web Part, which can be incorporated into a customized Web
page.
Note
For information about client requirements, see Client requirements and configuration.
To use TS Web Access to deploy RemoteApp programs, you must do the following:
1. Install the TS Web Access role service.
2. Populate the TS Web Access Computers security group.
3. Specify the terminal server from which to populate the list of RemoteApp programs that will
appear in the TS Web Access Web Part.
Install the TS Web Access role service

You must install the TS Web Access role service on the server that you want users to connect to
over the Web to access RemoteApp programs. When you install the TS Web Access role service,
Microsoft Internet Information Services (IIS) 7.0 is also installed.
The server where you install TS Web Access acts as the Web server. The server does not have
to be a terminal server.
23
Membership in the local Administrators group is the minimum required to complete this
procedure.
To install TS Web Access

2. If the Terminal Services role is already installed:
a. Under Roles Summary, click Terminal Services.
b. Under Role Services, click Add Role Services.
c. On the Select Role Services page, select the TS Web Access check box.
If the Terminal Services role is not already installed:
a. Under Roles Summary, click Add Roles.
b. On the Before You Begin page, click Next.
c. On the Select Server Roles page, select the Terminal Services check box, and
then click Next.
d. Review the Terminal Services page, and then click Next.
e. On the Select Role Services page, select the TS Web Access check box.
3. Review the information about the required role services, and then click Add Required
Role Services.
4. Click Next.
5. Review the Web Server (IIS) page, and then click Next.
6. On the Select Role Services page, where you are prompted to select the role services
that you want to install for IIS, click Next.
7. On the Confirm Installation Selections page, click Install.
8. On the Installation Results page, confirm that the installation succeeded, and then click
Close.
Populate the TS Web Access Computers security group

If the TS Web Access server and the terminal server that hosts the RemoteApp programs are
separate servers, you must add the computer account of the TS Web Access server to the
TS Web Access Computers security group on the terminal server.
To add the computer account of the TS Web Access server to the security group
1. On the terminal server, click Start, point to Administrative Tools, and then click
Computer Management.
2. In the left pane, expand Local Users and Groups, and then click Groups.
24
3. In the right pane, double-click TS Web Access Computers.
4. In the TS Web Access Computers Properties dialog box, click Add.
5. In the Select Users, Computers, or Groups dialog box, click Object Types.
6. In the Object Types dialog box, select the Computers check box, and then click OK.
7. In the Enter the object names to select box, specify the computer account of the
TS Web Access server, and then click OK.
8. Click OK to close the TS Web Access Computers Properties dialog box.
Configure the data source for TS Web Access

You can configure TS Web Access to populate the list of RemoteApp programs that appear in the
Web Part from a specific terminal server or terminal server farm.
Specify the data source for TS Web Access

By default, TS Web Access populates its list of RemoteApp programs from a single terminal
server, and points to the local host. The Web Part is populated by all RemoteApp programs that
are enabled for TS Web Access on that terminal server's RemoteApp Programs list.
To complete this procedure, you must log on to the TS Web Access server by using the local
Administrator account or an account that is a member of the TS Web Access Administrators
group on the TS Web Access server.
To specify which terminal server to use as the data source

1. Connect to the TS Web Access Web site. To do this, use either of the following methods:
• On the TS Web Access server, click Start, point to Administrative Tools, point to
Terminal Services, and then click TS Web Access Administration.
• Use Internet Explorer to connect to the TS Web Access Web site. By default, the
Web site is located at the following address, where server_name is the name of the
TS Web Access server:
http://server_name/ts
2. Log on to the site by using either the local Administrator account, or an account that is a
member of the local TS Web Access Administrators group. (If you are already logged on
to the computer as one of these accounts, you are not prompted for credentials.)
3. On the title bar, click the Configuration tab.
Note
If you access the TS Web Access Web site by using the TS Web Access
Administration option, the page automatically opens to the Configuration tab.
4. In the Editor Zone area, in the Terminal server name box, enter the name of the
terminal server that you want to use as the data source.
25
5. Click Apply to apply the changes.
To test TS Web Access, see Connect to TS Web Access.
Connect to TS Web Access

By default, you can access the TS Web Access Web site at the following location, where
server_name is the NetBIOS name or the fully qualified domain name of the Web server where
you installed TS Web Access:
http://server_name/ts
If you connect to TS Web Access from a public computer, such as a computer in an "Internet
café," you should clear the I am using a private computer that complies with my
organization's security policy check box that appears in the lower-right corner of the Web Part.
In public mode, you are not provided with the option to save your credentials, and the caching of
bitmaps is not enabled.
Client requirements and configuration

To connect to TS Web Access, the client computer must be running one of the following
operating systems:
• Windows Vista with SP1 Beta
Additionally, the client computer must be configured as follows:
• The client computer must be running RDC 6.1. (The RDC 6.1 client supports RDP 6.1.)
RDC 6.1 is included with Windows Server 2008 and Windows Vista SP1 Beta.
• The Terminal Services ActiveX Client control must be enabled. (The ActiveX control is
included with RDC 6.1.)
If you are running Windows Server 2008 or Windows Vista with SP1 Beta, and you receive a
warning message on the Internet Explorer Information bar, point to Add-on Disabled, and
then click Run ActiveX Control. When you do this, you may see a security warning. Make
sure that the publisher for the ActiveX control is "Microsoft Corporation" before you click Run.
Note
If the Internet Explorer Information bar does not appear, and you cannot connect to
TS Web Access, you can enable the Terminal Services ActiveX control by using the
Manage Add-ons tool on the Tools menu of Internet Explorer.
• The TS Web Access server must be added to the Local intranet zone or the Trusted sites
zone in Internet Explorer. To do this, use the following procedure.
To add site to Local intranet or Trusted sites zone by using Internet Options
1. Start Internet Explorer.
26
2. On the Tools menu, click Internet Options.
3. Click the Security tab.
4. If the TS Web Access server is on your intranet, click Local intranet. Otherwise, click
Trusted sites.
5. Click Sites.
6. Use one of the following procedures, depending on the zone that you selected:
• If you are adding the site to the Local intranet zone, click Advanced. In the Add
this website to the zone box, type the URL of the Web server (for example,
type http://server_name), and then click Add. If the site does not require server
verification, clear the Require server verification (https:) for all sites in this
zone box. Click Close to apply the settings.
• If you are adding the site to the Trusted sites zone, in the Add this website to
the zone box, type the URL of the Web server (for example, type
http://server_name.domain_name.com), and then click Add. If the site does not
require server verification, clear the Require server verification (https:) for all
sites in this zone box. Click Close to apply the settings.
Deploy RemoteApp programs through file sharing or other

distribution methods
You can deploy RemoteApp programs to users by making .rdp files or Windows Installer
packages available from a file share or through other distribution mechanisms. You can use
TS RemoteApp Manager to create the .rdp files or Windows Installer packages from RemoteApp
programs that are in the RemoteApp Programs list.
Create an .rdp file from a RemoteApp program

You can use the RemoteApp Wizard to create an .rdp file from any program in the RemoteApp
Programs list.
To create an .rdp file

2. In the RemoteApp Programs list, click the program that you want to create an .rdp file
for. To select multiple programs, press and hold the CTRL key when you click each
program name.
3. In the Actions pane for the program or selected programs, click Create .rdp file.
Note
If you selected multiple programs, the settings described in the rest of this
27
procedure apply to all of the selected programs. A separate .rdp file is created for
each program.
4. On the Welcome to the Remote App Wizard page, click Next.
5. On the Specify Package Settings page, do the following:
a. In the Enter the location to save the packages box, accept the default location or
click Browse to specify a new location to save the .rdp file.
b. In the Terminal server settings area, click Change to modify the terminal server or
farm name, the RDP port number, and the Require server authentication setting.
(For more information about these settings, see Configure terminal server settings.)
When you are finished, click OK.
c. In the TS Gateway settings area, click Change to modify or to configure whether
clients will use a TS Gateway server to connect to the target terminal server across a
firewall. (For more information about these settings, see Configure TS Gateway
settings.) When you are finished, click OK.
Note
For more information about TS Gateway, see the TS Gateway Step-by-Step
Guide (http://go.microsoft.com/fwlink/?LinkId=85872).
d. To digitally sign the .rdp file, in the Certificate Settings section, click Change to
select or to change the certificate to use. Select the certificate that you want to use,
and then click OK. (For more information about these settings, see Configure digital
signature settings (optional).)
6. When you are finished, click Next.
7. On the Review Settings page, click Finish.
When the wizard is finished, the folder where the .rdp file was saved opens in a new
window. You can confirm that the .rdp file was created.
Create a Windows Installer package from a RemoteApp program

You can use the RemoteApp Wizard to create a Windows Installer (.msi) package from any
program in the RemoteApp Programs list.
To create a Windows Installer package

2. In the RemoteApp Programs list, click the program that you want to create a Windows
Installer package for. To select multiple programs, press and hold the CTRL key when
you click each program name.
3. In the Actions pane for the program or selected programs, click Create Windows
28
Installer package.
Note
If you selected multiple programs, the settings described in the rest of this
procedure apply to all of the selected programs. A separate Windows Installer
package is created for each program.
4. On the Welcome to the RemoteApp Wizard page, click Next.
5. On the Specify Package Settings page, do the following:
a. In the Enter the location to save the packages box, accept the default location or
click Browse to specify a new location to save the Windows Installer package.
b. In the Terminal server settings area, click Change to modify the terminal server or
farm name, the RDP port number, and the Require server authentication setting.
(For more information about these settings, see Configure terminal server settings.)
When you are finished, click OK.
c. In the TS Gateway settings area, click Change to modify or to configure whether
clients will use a TS Gateway server to connect to the target terminal server across a
firewall. (For more information about these settings, see Configure TS Gateway
settings.) When you are finished, click OK.
Note
For more information about TS Gateway, see the TS Gateway Step-by-Step
Guide (http://go.microsoft.com/fwlink/?LinkId=85872).
d. To digitally sign the file, in the Certificate Settings section, click Change to select or
to change the certificate to use. Select the certificate that you want to use, and then
click OK. (For more information about these settings, see Configure digital signature
settings (optional).)
6. When you are finished, click Next.
7. On the Configure Distribution Package page, do the following:
a. In the Shortcut icons area, specify where the shortcut icon for the program will
appear on client computers.
b. In the Take over client extensions area, configure whether to take over client file
name extensions for the program.
If you associate the file name extensions on the client computer with the RemoteApp
program, all file name extensions that are handled by the program on the terminal
server will also be associated on the client computer with the RemoteApp program.
For example, if you add Microsoft Word as a RemoteApp program, and you configure
the option to take over client file name extensions, any file name extensions on the
client computer that Word takes over will be associated with Remote Word. This
means that any existing program on the client computer will no longer handle file
29
name extensions such as .doc and .dot. Note that users are not prompted whether
the terminal server should take over file extensions for the program.
To view what file name extensions are associated with a program on the terminal
server, click Start, click Control Panel, and then double-click Default Programs.
Click Associate a file type or protocol with a program to view the file name
extensions and their default associated program.
Caution
Do not install Windows Installer packages that were created with this setting
enabled on the terminal server itself. If you do, clients that use the Windows
Installer package may not be able to start the associated RemoteApp
program.
8. After you have configured the properties of the distribution package, click Next.
9. On the Review Settings page, click Finish.
When the wizard is finished, the folder where the Windows Installer package was saved
opens in a new window. You can confirm that the Windows Installer package was
created.
Make RemoteApp programs available from the

Internet
By using TS RemoteApp together with TS Gateway, you can enable users to connect from the
Internet to individual programs on a terminal server without having to first establish a virtual
private network (VPN) connection. (Alternatively, if you do not want to deploy TS Gateway, you
can make RemoteApp programs available through a VPN solution.) Depending on the
deployment method that you choose, remote users can connect to a program by opening an .rdp
file, by clicking a shortcut to a Windows Installer package on their desktop or Start menu, or by
accessing a RemoteApp program on a Web page through TS Web Access.
To make RemoteApp programs available from the Internet through TS Gateway, follow these
steps:
1. Ensure that you meet the following prerequisites:
• You must have already deployed RemoteApp programs on the terminal server.
• If you want to make RemoteApp programs available from the Internet through TS Web
Access, you must have successfully deployed TS Web Access in an intranet
environment.
2. Review the TS Gateway Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=85872).
3. Following the procedures in the TS Gateway Step-by-Step Guide, deploy and configure
TS Gateway. When you do so, make sure that you do the following:
30
a. Create a Terminal Services connection authorization policy (TS CAP) to define the list of
user groups that can connect to the terminal servers that host the RemoteApp programs.
For more information, see the "Create a TS CAP for the TS Gateway server" section of
the TS Gateway Step-by-Step guide.
b. Create a Terminal Services resource authorization policy (TS RAP) that provides access
to the terminal servers that host the RemoteApp programs.
When you create the TS RAP, add the user groups that you defined in the TS CAP. Also,
create a new TS Gateway-managed computer group that contains both the NetBIOS
names and the fully qualified domain names (FQDNs) of the terminal servers that host
the RemoteApp programs.
Note
If you are using a terminal server farm, specify the name of the farm, and not the
individual farm members.
For more information, see the "Create a TS RAP and specify computers that users can
connect to through the TS Gateway server" section of the TS Gateway Step-by-Step
Guide.
4. Configure TS Gateway settings in TS RemoteApp Manager (either in the global deployment
settings or when you create an .rdp file or Windows Installer package). When you do so,
make sure that you specify the FQDN of the TS Gateway server.
When you configure global deployment settings, the changes will be reflected immediately on
the TS Web Access Web site.
Note
If you have previously created .rdp files and Windows Installer packages, the new
settings will not be reflected in those packages. You must create new packages with
the correct settings, and then distribute them to users.
5. To allow Internet access to RemoteApp programs through TS Web Access, configure firewall
and authentication settings. For more information, see Configure the TS Web Access server
to allow access from the Internet in the following section.
Configure the TS Web Access server to allow access from the

Internet
To allow users to access the TS Web Access server from the Internet through TS Gateway, the
recommended configuration is to place both the TS Gateway server and the TS Web Access
server in the perimeter network, with the terminal servers that host RemoteApp programs behind
the internal firewall.
Alternatively, you can deploy TS Web Access on the internal network, and then make the Web
site available through Microsoft Internet Security and Acceleration (ISA) Server. For more
31
information about Web publishing through ISA Server 2006, visit the "Publishing Concepts in ISA
Server 2006" Web site (http://go.microsoft.com/fwlink/?LinkId=86359).
If you deploy TS Web Access in the perimeter network, you must configure your firewall to allow
Windows Management Instrumentation (WMI) traffic from the TS Web Access server to the
terminal server.
Additionally, the TS Web Access Web site must be configured to use Windows authentication. By
default, Windows authentication is enabled for the TS Web Access Web site.
To verify that Windows authentication is enabled

1. On the TS Web Access server, click Start, point to Administrative Tools, and then click
Internet Information Services (IIS) Manager.
2. In the left pane of Internet Information Services (IIS) Manager, expand the server name,
expand Sites, expand Default Web Site, and then click TS.
3. In the middle pane, under IIS, double-click Authentication.
4. Ensure that Windows Authentication is set to Enabled. If it is not, right-click Windows
Authentication, and then click Enable.
Note
If you placed TS Web Access in a custom Web site, you must ensure that the
authentication method that is used for the Web site can map to the user's Windows
account. You can do this by using integrated Windows authentication on the custom Web
site.
Additional information
Upgrading from Windows Server 2008 Beta 3 to Windows
Server 2008 RC0
If you are using TS RemoteApp and have made RemoteApp programs available by using the
Beta 3 release of Windows Server 2008, the list of RemoteApp programs and settings in
TS RemoteApp Manager is not preserved when you upgrade to the RC0 release.
To preserve the settings, use the Export RemoteApp Settings option in TS RemoteApp
Manager to export the RemoteApp programs and settings to a file. After you upgrade the server
to RC0, use the Import RemoteApp Settings option to import the file and to restore the settings.
(For more information, see Export or import RemoteApp programs and settings.)
If you upgraded the server before exporting the settings to a file, you will have to add the list of
RemoteApp programs and configure the deployment settings manually in TS RemoteApp
Manager.
32
Configure Server Manager and Initial Tasks not to run in
administrator's RemoteApp session
If a user has administrative access to the terminal server where the RemoteApp programs are
installed, when the user starts a RemoteApp program, the Server Manager tool and Initial
Configuration Tasks also start in the RemoteApp session.
You can control this behavior by using the following Group Policy settings in the Computer
Configuration\Administrative Templates\System\Server Manager node of the Local Group
Policy Editor on the terminal server:
• Do not display Initial Configuration Tasks window automatically at logon
You must enable this policy setting to prevent the Initial Configuration Tasks window from
opening when a user with administrative access starts a RemoteApp session.
• Do not display Server Manager automatically at logon
You must enable this policy setting to prevent Server Manager from opening when a user
with administrative access starts a RemoteApp session.
Configure Remote Desktop Web Connection behavior

Terminal Services Remote Desktop Web Connection enables a user to connect to the desktop of
a remote computer from the TS Web Access Web site. To connect to a remote computer, the
following conditions must be true:
• The remote computer must be configured to accept Remote Desktop connections.
• The user must be a member of the Remote Desktop Users group on the remote computer.
A user can access Remote Desktop Web Connection by clicking the Remote Desktop tab on the
TS Web Access page. As an administrator, you can configure whether the Remote Desktop tab
is available to users. Additionally, you can configure settings such as which TS Gateway server to
use, and the default device and resource redirection options.
Membership in the local Administrators group, or equivalent, is the minimum required to
complete this procedure.
To configure Remote Desktop Web Connection behavior

1. On the TS Web Access server, start Internet Information Services (IIS) Manager. To do
this, click Start, point to Administrative Tools, and then click Internet Information
Services (IIS) Manager.
2. In the left pane, expand the server name, expand Sites, expand Default Web Site, and
then click TS.
3. In the middle pane, under ASP.NET, double-click Application Settings.
4. To change Remote Desktop Web Connection settings, modify the values in the
Application Settings pane.
33
• To configure a default TS Gateway server, double-click DefaultTSGateway, enter
the fully qualified domain name of the server in the Value box (for example,
server1.contoso.com), and then click OK.
• To specify the TS Gateway authentication method, double-click
GatewayCredentialsSource, type the number that corresponds to the desired
authentication method in the Value box, and then click OK. The possible values
include:
0 = Ask for password (NTLM)
1 = Smart card
4 = Allow user to select later
• To configure whether the Remote Desktop tab appears on the TS Web Access
page, double-click ShowDesktops. In the Value box, type true to show the Remote
Desktop tab, or type false to hide the Remote Desktop tab. When you are finished,
click OK.
• To configure default device and resource redirection settings, double-click the setting
that you want to modify (xClipboard, xDriveRedirection, xPnPRedirection,
xPortRedirection, or xPrinterRedirection). In the Value box, type true to enable
the redirection setting by default, or type false to disable the redirection setting by
default, and then click OK.
5. When you are finished, close IIS Manager.
Your changes should take effect immediately on the TS Web Access Web site. If the
Web page is open, refresh the page to view the changes.
Note
You can also configure these settings by modifying the %windir%\Web\ts\Web.config file
directly by using a text editor such as Notepad.
34
Windows Server 2008 RC0 TS Session
Broker Load Balancing Step-By-Step Guide
Author: Tessa Wooley
Abstract
Windows Server® 2008 that enables you to load balance sessions in a terminal server farm, and
allows a user to reconnect to an existing session in a load-balanced terminal server farm. The
new TS Session Broker Load Balancing feature enables you to easily distribute the session load
between servers in a load-balanced terminal server farm.
1
2
Contents
Windows Server 2008 RC0 TS Session Broker Load Balancing Step-by-Step Guide ................... 5
What new functionality does this feature provide?....................................................................... 5
About using DNS round robin ...................................................................................................... 6
TS Session Broker Load Balancing system requirements ........................................................... 7
Checklist: Deploying TS Session Broker Load Balancing ........................................................... 7
Install the TS Session Broker role service ................................................................................... 8
Installation prerequisites ........................................................................................................... 8
Installation procedure ............................................................................................................... 8
Add each terminal server in the farm to the Session Directory Computers local group .............. 9
Configure TS Session Broker settings for terminal servers in the farm ..................................... 10
Configure TS Session Broker settings by using Group Policy ............................................... 10
Configure TS Session Broker settings by using Terminal Services Configuration ................. 12
Configure DNS for TS Session Broker Load Balancing ............................................................. 14
Additional information ................................................................................................................. 15
Configure dedicated redirectors (optional) ............................................................................. 15
Deny logons to a terminal server in a load-balanced farm ..................................................... 15
Additional references ........................................................................................................... 16
3
Windows Server 2008 RC0 TS Session
Broker Load Balancing Step-by-Step Guide
Windows Server® 2008 that enables you to load balance sessions between terminal servers in a
farm, and allows a user to reconnect to an existing session in a load-balanced terminal server
farm. TS Session Broker stores session state information that includes session IDs, their
associated user names, and the name of the server where each session resides.
This step-by-step guide describes how to configure the new TS Session Broker Load Balancing
feature.
Note
In Windows Server 2008, the name of the Terminal Services Session Directory feature
was changed to TS Session Broker.

The new TS Session Broker Load Balancing feature enables you to evenly distribute the session
load between servers in a load-balanced terminal server farm. With TS Session Broker Load
Balancing, new user sessions are redirected to the terminal server with the fewest sessions.
TS Session Broker is a two phased load-balancing mechanism. In the first phase, initial
connections are distributed by a preliminary load-balancing mechanism, such as Domain Name
System (DNS) round robin. After a user authenticates, the terminal server that accepted the initial
connection queries the TS Session Broker server to determine where to redirect the user.
In the second phase, the terminal server where the initial connection was made redirects the user
to the terminal server that was specified by TS Session Broker. The redirection behavior is as
follows:
• A user with an existing session will connect to the server where their session exists.
• A user without an existing session will connect to the terminal server that has the fewest
sessions.
TS Session Broker Load Balancing sets a limit of 16 for the maximum number of pending logon
requests to a particular terminal server. This helps to prevent the scenario where a single server
is overwhelmed by new logon requests; for example, if you add a new server to the farm, or if you
enable user logons on a server where they were previously denied.
The TS Session Broker Load Balancing feature also enables you to assign a relative weight value
to each server. By assigning a relative weight value, you can help to distribute the load between
5
more powerful and less powerful servers in the farm. For more information, see Configure TS
Session Broker settings by using Terminal Services Configuration.
Additionally, a new "server draining" mechanism is provided that enables you to prevent new
users from logging on to a terminal server that is scheduled to be taken down for maintenance.
This mechanism provides for the ability to take a server offline without disrupting the user
experience. If new logons are denied on a terminal server in the farm, TS Session Broker will
allow users with existing sessions to reconnect, but will redirect new users to terminal servers that
are configured to allow new logons. For more information, see Deny logons to a terminal server in
a load-balanced farm.
You can enable TS Session Broker Load Balancing through Terminal Services Configuration,
Group Policy, or Windows Management Instrumentation (WMI). If you are using DNS round robin
to distribute initial connections, you must also configure DNS entries for each terminal server in
the farm.
Note
While any load-balancing mechanism can be used to distribute the initial connections,
DNS round robin is the easiest mechanism to deploy. Deploying TS Session Broker Load
Balancing with a network level load-balancing solution such as Network Load Balancing
(NLB) or a hardware load balancer avoids the limitations of DNS, while still taking
advantage of TS Session Broker session-based load balancing, the per server limit on
the number of pending logon requests, and the new "server draining" feature. The
limitations of DNS round robin include the caching of DNS requests on the client, which
can result in clients using the same IP address for each initial connection request, and
the potential for a 30-second timeout delay if a user is redirected to a terminal server that
is offline, but still listed in DNS.
About using DNS round robin

To configure DNS round robin, you must create a host resource record for each terminal server in
the farm that maps to the terminal server farm name in DNS. (The farm name is the virtual name
that clients will use to connect to the terminal server farm.) DNS uses round robin to rotate the
order of the resource records that are returned to the client. This functionality helps to distribute
initial connections across servers in the farm. The initial connection behavior is as follows:
1. An incoming Terminal Services client queries DNS and receives a list of IP addresses for the
farm.
2. The client tries to connect to the first IP address in the list that was returned by DNS.
If the connection fails, the client will automatically try to connect to the next IP address (after
a 30-second timeout delay). This provides a degree of fault tolerance if one of the terminal
servers is unavailable.
6
Note
For information about how to configure dedicated redirectors that redirect user sessions
but do not accept user logons, see Configure dedicated redirectors (optional).
TS Session Broker Load Balancing system

requirements
To participate in TS Session Broker Load Balancing, the following system requirements apply:
• The TS Session Broker server and the terminal servers in the farm must be running Windows
Server 2008.
Note
Windows Server 2003-based terminal servers cannot use the TS Session Broker
Load Balancing feature.
• You must configure all terminal servers in the load-balanced farm identically, with the same
available programs.
• For clients to use TS Session Broker Load Balancing, they must be running Remote Desktop
Connection (RDC) version 5.2 or later.
Checklist: Deploying TS Session Broker Load

Balancing
To deploy TS Session Broker Load Balancing, you must complete the following tasks.
Note
This step-by-step guide describes how to configure TS Session Broker Load Balancing
by using DNS round robin to distribute the initial connections. If you prefer, you can use
NLB or a hardware load balancer to spread the initial connection and authentication load
between multiple terminal servers in the farm.
Task Reference
Install the TS Session Broker role service on Install the TS Session Broker role service
the server that you want to use to track user
sessions for a farm.
Add the terminal servers in the farm to the Add each terminal server in the farm to the
Session Directory Computers local group on Session Directory Computers local group
the TS Session Broker server.
Configure the terminal servers in the farm to Configure TS Session Broker settings for
7
Task Reference
join a farm in TS Session Broker, and to terminal servers in the farm
participate in TS Session Broker Load
Balancing.
Configure DNS round robin entries for terminal Configure DNS for TS Session Broker Load
servers in the farm. Balancing
Install the TS Session Broker role service

You must install the TS Session Broker role service on the server that you want to use to track
user session information for a load-balanced terminal server farm. You can use a single
TS Session Broker server to track user sessions across multiple farms, as there is minimal
performance overhead.
The Windows Server 2008-based server where you install the TS Session Broker role service
does not have to be a terminal server or have Remote Desktop enabled. It is considered a best
practice to install the TS Session Broker role service on a back-end infrastructure server, such as
a file server. If you install the role service on a server that is not a terminal server, the Terminal
Services Session Broker service will not be affected when you need to perform maintenance on
terminal servers in the farm.
When you install the TS Session Broker role service, the following changes occur on the local
computer:
• The Terminal Services Session Broker service is installed. By default, the service is set to
Started and to Automatic.
• The Session Directory Computers local group is created.
Installation prerequisites
The server where you install TS Session Broker must be a member of a domain.
Note
If you install the TS Session Broker role service on a domain controller, the Session
Directory Computers group will be a domain local group and will be available on all
domain controllers.
Installation procedure
procedure.
8
To install TS Session Broker
2. If the Terminal Services role is already installed:
a. Under Roles Summary, click Terminal Services.
b. Under Role Services, click Add Role Services.
c. On the Select Role Services page, select the TS Session Broker check box, and
then click Next.
If the Terminal Services role is not already installed:
a. Under Roles Summary, click Add Roles.
b. On the Before You Begin page of the Add Roles Wizard, click Next.
c. On the Select Server Roles page, select the Terminal Services check box, and
then click Next.
d. Review the Terminal Services page, and then click Next.
e. On the Select Role Services page, select the TS Session Broker check box, and
then click Next.
3. On the Confirm Installation Selections page, click Install.
4. On the Installation Results page, confirm that the installation succeeded, and then click
Close.
Add each terminal server in the farm to the

Session Directory Computers local group
For terminal servers to use TS Session Broker, you must add the computer account for each
terminal server in the farm to the Session Directory Computers local group on the TS Session
Broker server.
procedure.
Important
You must perform this procedure on the server where you installed the TS Session
Broker role service.
To add terminal servers to the Session Directory Computers local group

1. On the TS Session Broker server, click Start, point to Administrative Tools, and then
click Computer Management.
9
2. In the left pane, expand Local Users and Groups, and then click Groups.
3. In the right pane, right-click the Session Directory Computers group, and then click
Properties.
4. Click Add.
5. In the Select Users, Computers or Groups dialog box, click Object Types.
6. Select the Computers check box, and then click OK.
7. Locate and then add the computer account for each terminal server that you want to add.
Configure TS Session Broker settings for terminal

servers in the farm
You can configure a terminal server to join a farm in TS Session Broker and to participate in
TS Session Broker Load Balancing by using Group Policy or the Terminal Services Configuration
tool. However, you must use Terminal Services Configuration to configure the following settings:
• The IP addresses to be used for reconnection.
• The relative weight of the server when using TS Session Broker Load Balancing.
For information about how to configure the settings by using Group Policy, see Configure TS
Session Broker settings by using Group Policy. Configuring the settings by using Group Policy is
a recommended best practice.
For information about how to configure the settings by using Terminal Services Configuration, see
Configure TS Session Broker settings by using Terminal Services Configuration.
Important
Group Policy settings take precedence over configuration settings in the Terminal
Services Configuration snap-in and those that are made by using the Terminal Services
WMI provider.
Configure TS Session Broker settings by using Group Policy

To assign TS Session Broker settings through Group Policy, it is a best practice to group the
terminal servers that are in the same terminal server farm into a single organizational unit (OU) in
Active Directory Domain Services (AD DS). Then, configure the TS Session Broker settings in a
Group Policy object (GPO) that applies to the OU.
Note
For the TS Session Broker settings to be effective on a server, the server must have the
Terminal Server role service installed.
10
The following procedure describes how to configure TS Session Broker Group Policy settings by
using the Group Policy Management Console (GPMC) on a Windows Server 2008-based domain
controller.
To change Group Policy settings for a domain or an OU, you must be logged on as a member of
the Domain Admins, Enterprise Admins, or the Group Policy Creator Owners group, or have
been delegated the appropriate control over Group Policy to complete this procedure.
To apply TS Session Broker settings to an Active Directory OU

1. To start the GPMC, click Start, point to Administrative Tools, and then click Group
Policy Management.
2. In the left pane, locate the OU that contains the terminal servers.
3. To modify an existing GPO for the OU, expand the OU, and then click the GPO.
To create a new GPO, follow these steps:
a. Right-click the OU, and then click Create a GPO in this domain, and link it here.
b. In the Name box, type a name for the GPO, and then click OK.
c. In the left pane, click the new GPO.
4. In the right pane, click the Settings tab.
5. Right-click Computer Configuration, and then click Edit.
6. In the left pane, under Computer Configuration, expand Administrative Templates,
Windows Components, Terminal Services, Terminal Server, and then click
TS Session Broker.
7. In the right pane, double-click the Join TS Session Broker policy setting, click Enabled,
and then click OK.
8. Double-click the Configure TS Session Broker farm name policy setting, and then do
the following:
a. Click Enabled.
b. In the TS Session Broker farm name box, type the name of the farm in TS Session
Broker that you want to join, and then click OK.
Important
TS Session Broker uses a farm name to determine which servers are in the
same terminal server farm. You must use the same farm name for all servers
that are in the same load-balanced terminal server farm. Although the farm
name in TS Session Broker does not have to be registered in AD DS, it is
recommended that you use the same name that you will use in DNS for the
terminal server farm. (The terminal server farm name in DNS represents the
virtual name that clients will use to connect to the terminal server farm.) If
you type a new farm name, a new farm is created in TS Session Broker and
11
the server is joined to the farm. If you type an existing farm name, the server
joins the existing farm in TS Session Broker.
9. Double-click the Configure TS Session Broker server name policy setting, and then do
the following:
a. Click Enabled.
b. In the TS Session Broker server name box, type the name of the server where you
installed the TS Session Broker role service, and then click OK.
10. Double-click the Use TS Session Broker load balancing policy setting, click Enabled,
and then click OK.
11. Optionally, if you are using a hardware load balancer that supports token redirection,
double-click Use IP Address Redirection and configure the setting. See the Group
Policy Explain text for more information.
Note
To configure TS Session Broker settings by using local Group Policy, use the Local
Group Policy Editor. To start the Local Group Policy Editor, click Start, click Run, type
gpedit.msc, and then click OK. To configure local Group Policy settings, you must be a
member of the Administrators group on the local computer or you must have been
delegated the appropriate authority.
Configure TS Session Broker settings by using Terminal

Services Configuration
You can configure a terminal server to join a farm in TS Session Broker and to participate in
TS Session Broker Load Balancing by using Terminal Services Configuration.
Note
The following steps are only applicable if the Terminal Server role service is installed.
procedure.
To configure TS Session Broker settings by using Terminal Services Configuration

1. Start Terminal Services Configuration. To do this, click Start, point to Administrative
Tools, point to Terminal Services, and then click Terminal Services Configuration.
2. In the Edit settings area, under TS Session Broker, double-click Member of farm in
TS Session Broker.
3. On the TS Session Broker tab, click to select the Join a farm in TS Session Broker
check box.
4. In the TS Session Broker server name or IP address box, type the name or the IP
12
address of the TS Session Broker server.
Note
The TS Session Broker server is the server where you installed the TS Session
Broker role service.
5. In the Farm name in TS Session Broker box, type the name of the farm that you want
to join in TS Session Broker.
Important
TS Session Broker uses a farm name to determine which servers are in the
same terminal server farm. You must use the same farm name for all servers that
are in the same load-balanced terminal server farm. Although the farm name in
TS Session Broker does not have to be registered in AD DS, it is recommended
that you use the same name that you will use in DNS for the terminal server
farm. (The terminal server farm name in DNS represents the virtual name that
clients will use to connect to the terminal server farm.) If you type a new farm
name, a new farm is created in TS Session Broker and the server is joined to the
farm. If you type an existing farm name, the server joins the existing farm in
TS Session Broker.
6. To participate in TS Session Broker Load Balancing, select the Participate in Session
Broker Load-Balancing check box.
7. Optionally, in the Relative weight of this server in the farm box, modify the server
weight. By default, the value is 100. The server weight is relative. Therefore, if you assign
one server a value of 100, and one a value of 200, the server with a relative weight of
200 will receive twice the number of sessions.
8. Verify that you want to use IP address redirection. By default, the Use IP address
redirection (recommended) setting is enabled. If you clear the check box, the server
switches to token redirection mode.
9. In the Select IP addresses to be used for reconnection box, click to select the check
box next to each IP address that you want to use. When you select the IP addresses to
use, consider the following:
• Only the first selected IPv4 address will be used by clients that are running RDC 5.2
and earlier.
• Using IPv6 addresses is not recommended if the terminal server farm contains
servers that are running Windows Server 2003.
13
Configure DNS for TS Session Broker Load
Balancing
To configure DNS round robin for TS Session Broker Load Balancing, you must map the IP
address of each terminal server in the farm to the terminal server farm name in DNS.
The following procedure provides the steps to configure DNS on a Windows Server 2008-based
domain controller.
You must be a member of the Domain Admins, Enterprise Admins, or the DnsAdmins group
to complete this procedure.
To add DNS entries for each terminal server in the farm

2. Expand the server name, expand Forward Lookup Zones, expand the domain name,
and then click the appropriate zone.
3. Right-click the zone, and then click New Host (A or AAAA).
4. In the Name (uses parent domain name if blank) box, type the terminal server farm
name.
The farm name is the virtual name that clients will use to connect to the terminal server
farm. For management purposes, it is recommended that you use the same farm name
that you specified when you configured the terminal servers to join a farm in TS Session
Broker.
Important
Do not use the name of an existing server for the farm name.
5. In the IP address box, type the IP address of a terminal server in the farm.
6. Click Add Host, and then click OK when you receive the message that the host record
was successfully created.
7. Repeat steps four through six for each terminal server in the farm. For each DNS entry,
ensure that you specify the same farm name in the Name (uses parent domain name if
blank) box. For example, if you have three terminal servers in a farm named FARM1,
with IP addresses of 192.168.1.20, 192.168.1.21, and 192.168.1.22, the entries would
look similar to the following:
Farm1 Host(A) 192.168.1.20
Farm1 Host(A) 192.168.1.21
Farm1 Host(A) 192.168.1.22
8. When you are finished, click Done.
14
Additional information
Configure dedicated redirectors (optional)
When you register the IP address of each terminal server in the farm to a single terminal server
farm name in DNS, incoming Terminal Services clients will try to connect to the first IP address
for the farm name that is returned by DNS. The terminal server that receives this initial connection
request acts as the redirector.
To increase session redirection performance in a large terminal server farm, you can configure
terminal servers to be dedicated redirectors. These servers will process incoming requests, but
will not accept user sessions. To configure dedicated redirectors, you must do the following:
1. Create DNS round robin entries for the terminal servers that you want to use as dedicated
redirectors. When you do so, you must map the IP address of each terminal server that you
are using as a dedicated redirector to the terminal server farm name in DNS. (The farm name
is the virtual name that clients will use to connect to the terminal server farm.) The farm name
must not match an existing server name in AD DS.
2. Configure the servers to deny new user logons. For more information about how to deny new
user logons, see Deny logons to a terminal server in a load-balanced farm.
Because these dedicated redirectors have no user sessions, they do not require roaming profiles
or any installed programs. This enables a faster logon experience, and makes the server easier
to manage and more reliable.
Deny logons to a terminal server in a load-balanced farm

In Windows Server 2008, you can configure a terminal server to deny logon requests from new
users. With the ability to deny logons from new users to specific servers in a farm, you can
maintain your terminal server environment without disrupting end-user service. If you configure a
terminal server to deny new logons, the following behavior occurs:
• Users with existing sessions can still reconnect to the server. Only new logons to that server
are denied. However, an administrator can still log on to the server locally to perform
maintenance on the server.
Note
An administrator can also connect remotely by starting the RDC client from the
command line with the /admin option (mstsc /admin).
• If you are using TS Session Broker Load Balancing, TS Session Broker will redirect new
users to other servers in the farm, where new user logons are enabled.
Before you take a server down for maintenance, you can notify users with existing sessions to log
off from the server by using Terminal Services Manager to send a message.
15
To deny new user logons
1. Click Start, point to Administrative Tools, point to Terminal Services, and then click
Terminal Services Configuration.
2. In the Edit settings area, double-click User logon mode under General.
3. On the General tab, click either of the following:
• Allow reconnections, but prevent new logons
• Allow reconnections, but prevent new logons until the server is restarted
4. Click OK.
When you are finished doing maintenance, ensure that Allow all connections is
selected.
• For information about how to configure a load-balanced terminal server farm by using
TS Session Broker and NLB, see the Step-by-Step Guide for Configuring Network Load
Balancing with Terminal Services: Windows Server 2008
• For information about Terminal Services Session Directory in Windows Server 2003, see
Session Directory and Load Balancing Using Terminal Server
16
Windows Server Active Directory Rights
Management Services Step-by-Step Guide
Author: Brian Lich
Abstract
This step-by-step guide provides instructions for setting up a test environment to deploy and
evaluate Active Directory Rights Management Services (AD RMS) in Windows Server® 2008. It
includes the necessary information for preparing the AD RMS infrastructure, installing and
configuring AD RMS, and verifying AD RMS features after configuration is complete.
1
Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Windows Vista, and Active
Directory are either registered trademarks or trademarks of Microsoft Corporation in the
2
Contents
Windows Server Active Directory Rights Management Services Step-by-Step Guide ................... 5
About This Guide.......................................................................................................................... 5
Deploying AD RMS in a Test Environment .................................................................................. 6
Step 1: Setting up the Infrastructure ................................................................................................ 7

Configure the domain controller (CPANDL-DC) ....................................................................... 8
Configure the computer for the AD RMS databases (ADRMS-DB) ....................................... 12
Configure the computer for the AD RMS root cluster (ADRMS-SRV) .................................... 15
Configure AD RMS client computer (ADRMS-CLNT)............................................................. 16
Step 2: Installing and Configuring AD RMS on ADRMS-SRV ....................................................... 18
Step 3: Verifying AD RMS Functionality on ADRMS-CLNT .......................................................... 21
3
Windows Server Active Directory Rights
Management Services Step-by-Step Guide
About This Guide

This step-by-step walks you through the process of setting up a working Active Directory Rights
Management Services (AD RMS) infrastructure in a test environment. During this process you
create an Active Directory® domain, install a database server, install the AD RMS server role,
configure the AD RMS cluster, and configure the AD RMS-enabled client computer.
Once complete, you can use the test lab environment to learn about AD RMS technology on
Windows Server® 2008 and assess how it might be deployed in your organization.
• Prepare the AD RMS infrastructure.
• Install and configure AD RMS.
The goal of an AD RMS deployment is to be able to protect information, no matter where it goes.
Once AD RMS protection is added to a digital file, the protection stays with the file. By default,
only the content owner is able to remove the protection from the file. The owner grants rights to
other users to perform actions on the content, such as the ability to view, copy, or print the file.
For more information about the business reasons behind an AD RMS deployment, see the white
paper "Windows Rights Management Services: Helping Organizations Safeguard Digital
Information from Unauthorized Use" (http://go.microsoft.com/fwlink/?LinkId=64636).
Note
This guide is considered the basic AD RMS step-by-step guide. All other step-by-step
guides developed for AD RMS will assume that this guide has been completed first.

• Guidance for setting up and configuring AD RMS in a production environment
• Complete technical reference for AD RMS
5
additional deployment documentation and should be used with discretion as a stand-alone
document.
Upon completion of this step-by-step guide, you will have a working AD RMS infrastructure. You
can then test and verify AD RMS functionality as follows:
• Restrict permissions on a Microsoft Office Word 2007 document
• Have an authorized user open and work with the document.
• Have an unauthorized user attempt to open and work with the document.
The test environment described in this guide includes four computers connected to a private
ADRMS-SRV Windows Server 2008 AD RMS, Internet Information

Services (IIS) 7.0, World Wide
Web Publishing Service, and
Message Queuing
CPANDL-DC Windows Server 2003 with Active Directory, Domain Name

Service Pack 2 (SP2) System (DNS)
Note
Service Pack 2 for
Windows Server 2003 is
not required but will be
used for the purposes of
this guide.
Standard Edition with Service
Note
Pack 2 (SP2)
Service Pack 2 for
Windows Server 2003 is Note
not required but will be Service Pack 2 for SQL
used for the purposes of Server 2005 Standard
this guide. Edition is not required
but will be used for the
purposes of this guide.
6

Enterprise Edition
Note
For more information about the system requirements for installing AD RMS, see
The computers form a private intranet and are connected through a common hub or Layer 2
switch. This configuration can be emulated in a virtual server environment if desired. This step-
network ID 10.0.0.0/24 is used for the intranet. The domain controller is named CPANDL-DC for
the domain named cpandl.com. The following figure shows the configuration of the test
environment:
Step 1: Setting up the Infrastructure

To prepare your AD RMS test environment in the CPANDL domain, you must complete the
following tasks:
• Configure the domain controller (CPANDL-DC)
• Configure the computer for the AD RMS databases (ADRMS-DB)
• Configure the computer for the AD RMS root cluster (ADRMS-SRV)
• Configure the AD RMS client computer (ADRMS-CLNT)
Use the following table as a reference when setting up the appropriate computer names,
operating systems, and network settings that are required to complete the steps in this guide.
7
Important
Computer name Operating system IP settings DNS settings

requirement
CPANDL-DC Windows Server 2003 IP address: Configured by DNS

with Service Pack 2 10.0.0.1 server role.
(SP2)
Subnet mask:
255.255.255.0
ADRMS-SRV Windows Server 2008 IP address: Preferred:

10.0.0.2 10.0.0.1
Subnet mask:
255.255.255.0
ADRMS-DB Windows Server 2003 IP address: Preferred:

with SP2 10.0.0.3 10.0.0.1
Subnet mask:
255.255.255.0
ADRMS-CLNT Windows Vista IP address Preferred:

10.0.0.4 10.0.0.1
Subnet mask:
255.255.255.0
Configure the domain controller (CPANDL-DC)

To configure the domain controller CPANDL-DC, you must:
• Install Windows Server 2003 with SP2.
• Configure TCP/IP properties.
• Install Active Directory.
• Raise the Active Directory domain functional level to Windows Server 2003.
• Create user accounts.
• Create groups for the user accounts.
8
For each user account and group that you configure with AD RMS, you need to add an e-mail
address and then assign the users to groups.
First, install Windows Server 2003 with SP2 on a stand-alone server.

1. Start your computer by using the Windows Server 2003 product CD. (You can use any
edition of Windows Server 2003 except the Web Edition to establish the domain.)
computer name, type CPANDL-DC.
Next, configure TCP/IP properties so that CPANDL-DC has a static IP address of 10.0.0.1. In
addition, configure 10.0.0.1 as the IP address for the DNS server.
To configure TCP/IP properties on CPANDL-DC

1. Log on to CPANDL-DC as a member of the local Administrators group.
box.
Next, configure the computer as a domain controller.
To configure CPANDL-DC as a domain controller

1. Click Start, and then click Run. In the Open box, type dcpromo, and then click OK.
2. On the Welcome page of the Active Directory Installation Wizard, click Next.
3. Select the Domain controller for a new domain option, and then click Next.
4. Select the Domain in a new forest option, and then click Next.
5. Select the No, just install and configure DNS on this computer option, and then click
Next.
6. In the Full DNS name for new domain box, type cpandl.com, and then click Next.
7. In the Domain NetBIOS name box, type CPANDL, and then click Next three times.
8. Select the Permissions compatible only with Windows 2000 or Windows
Server 2003 operating systems option, and then click Next.
9. In the Restore Mode Password and Confirm password boxes, type a strong password.
Click Next.
9
10. Click Next again.
11. When the Active Directory Installation Wizard is done, click Finish.
Note
You must restart the computer after you complete this procedure.
Next, you must raise the domain functional level to Windows Server 2003 so that Active Directory
Universal groups can be used.
To raise the domain functional level to Windows Server 2003

1. Log on to CPANDL-DC with the CPANDL\Administrator account or another user account
in the Domain Admins group.
Computers.
3. Right-click cpandl.com, and then click Raise domain functional level.
4. In the list under Select an available domain functional level, click Windows
Server 2003, and then click Raise.
5. Click OK to confirm the selection.
Note
You cannot change the domain functional level once you have raised it.
Next, add the user accounts shown in the following table to Active Directory. Use the procedure
following the table to create the user accounts.
Account Name User Logon Name E-mail address Group
ADRMSSRVC ADRMSSRVC
ADRMSADMIN ADRMSADMIN Enterprise Admins
Nicole Holliday NHOLLIDA nhollida@cpandl.com Employees,

Finance
Limor Henig LHENIG lhenig@cpandl.com Employees,

Marketing
Stuart Railson SRAILSON srailson@cpandl.com Employees,

Engineering
10
To add new user accounts
Computers.
2. In the console tree, expand cpandl.com.
3. Right-click Users, point to New, and then click User.
4. In the New Object – User dialog box, type ADRMSSRVC in the Full name and User
logon name boxes, and then click Next.
6. Perform steps 3-6 for each of the following users: ADRMSADMIN, Nicole Holliday, Limor
Henig, and Stuart Railson.
Next, add e-mail addresses to all user accounts.
To add e-mail addresses to user accounts

1. In the Active Directory Users and Computers console, right-click Nicole Holliday, click
Properties, type nhollida@cpandl.com in the E-mail box, and then click OK.
2. Repeat step 1 for Limor Henig and Stuart Railson, using the e-mail addresses for each
account from the table.
Once the user accounts have been created, Active Directory Universal groups should be created
and these users added to them. The following table lists the Universal groups that should be
added to Active Directory. Use the procedure following the table to create the Universal groups.
Group Name E-mail address
Finance finance@cpandl.com
Marketing marketing@cpandl.com
Engineering engineering@cpandl.com
Employees employees@cpandl.com
To add new group objects to Active Directory

1. In the Active Directory Users and Computers console, right-click Users, point to New,
and then click Group.
2. In the New Object – Group dialog box, type Finance in Group name, select the
11
Universal option for the Group Scope, and then click OK.
3. Perform the above steps 1-2 for each of the remaining groups: Marketing, Engineering,
and Employees.
Next, add e-mail addresses to group objects:
To add e-mail addresses to group objects

1. In the Active Directory Users and Computers console, double-click Users, right-click
Finance, and then click Properties.
2. Type finance@cpandl.com in the E-mail box, and then click OK.
3. Perform the above steps 1-2 for each of the remaining groups: Marketing, Engineering,
and Employees.
Finally, add the user accounts to their appropriate groups. In this guide, we will add Nicole
Holliday, Limor Henig, and Stuart Railson to the Employees group. Then, we will add Nicole
Holliday to the Finance group, Limor Henig to the Marketing group, and finally add Stuart Railson
to the Engineering group. To add the user accounts to their respective groups, you should follow
these steps:
To add user accounts to groups

1. In the Active Directory Users and Computers console, double-click Users, and then
double-click Employees.
2. Click Members, and then click Add.
3. Type nhollida@cpandl.com;lhenig@cpandl.com;srailson@cpandl.com, and then
click OK.
4. Perform the above steps 2-4 to add one member to each of the remaining groups as
follows:
• Nicole Holliday—Finance
• Limor Henig—Marketing
• Stuart Railson—Engineering
Configure the computer for the AD RMS databases (ADRMS-DB)

First, install Windows Server 2003 on the computer that will be hosting the AD RMS databases.

1. Start your computer using the Windows Server 2003 product CD. (You can use any
edition of Windows Server 2003 except the Web Edition to establish the domain.)
12
computer name, type ADRMS-DB.
In this step, configure TCP/IP properties so that ADRMS-DB has a static IP address of 10.0.0.3.
To configure TCP/IP properties on ADRMS-DB

1. Log on to ADRMS-DB with the ADRMS-DB\Administrator account or another user
box.
Next, join the AD RMS database server (ADRMS-DB) computer to the CPANDL domain:
To join ADRMS-DB to the CPANDL domain

1. Click Start, right-click My Computer, and then click Properties.
2. Click Computer Name tab, click Change.
3. In the Computer Name Changes dialog box, select the Domain option, and then type
cpandl.com.
4. Click More, and then type cpandl.com in the Primary DNS suffix of this computer
box.
5. Click OK twice.
6. When a Computer Name Changes dialog box appears prompting you for administrative
credentials, provide the credentials for CPANDL\Administrator, and then click OK.
8. When a Computer Name Changes dialog box appears telling you that the computer
must be restarted, click OK, and click Close.
9. Click Yes to restart the computer.
Next, install Microsoft SQL Server 2005 Standard Edition:
To install Microsoft SQL Server 2005

1. Log on to ADRMS-DB with the CPANDL\Administrator account or another user account
13
2. Insert the Microsoft SQL Server 2005 product CD. The installation will start automatically.
3. Click the I accept the licensing terms and conditions check box, and then click Next.
4. On the Installing Prerequisites page, click Install.
5. Click Next.
6. On the Welcome to the Microsoft SQL Server Installation Wizard page, click Next, and
then click Next again.
7. In the Name box, type your name. In the Company box, type the name of your
organization, and then type in the appropriate product key. Click Next.
8. Select the SQL Server Database Services, Workstation components, and Books
Online and development tools check boxes, and then click Next.
9. Select the Default instance option, and then click Next.
10. Select the Use the built-in System account option, and then click Next.
11. Click the Windows Authentication Mode option, and then click Next.
12. Click Next, accepting the default Collation Settings, and then click Next again.
13. Click Install. When the status of all the selected components is finished, click Next.
14. Click Finish.
Next, add ADRMSADMIN to the local Administrators group on ADRMS-DB. The AD RMS
installing user account needs this membership in order to create the AD RMS databases. After
AD RMS installed, ADRMSADMIN can be removed from this group.
To add ADRMSADMIN to local Administrators group

1. Click Start, click Administrative Tools, and then click Computer Management.
2. Expand System Tools, expand Local User and Groups, and then click Groups.
3. Right-click Administrators, click Add to Group, click Add, type ADRMSADMIN in Enter
the object names to select (examples) box, and then click OK.
4. Click OK, and then close Computer Management.
Finally, create a shared folder on ADRMS-DB so that other users can find documents saved to
the network.
To create a shared network folder that can be modified by CP&L employees

1. Click Start, click MyComputer, and then double-click Local Disk (C:).
2. Click File, point to New, and then click Folder.
3. Type Public for the new folder, and then press ENTER.
4. Right-click Public, and then click Sharing and Security.
5. Select the Share this folder option, and ensure that Public is in the Share name box.
14
6. Click Permissions.
7. Select the Full Control check box in the Allow column of the Permissions for
Everyone box.
8. Click OK two times.
Configure the computer for the AD RMS root cluster (ADRMS-

SRV)
To configure the member server, ADRMS-SRV, you must install Windows Server 2008, configure
TCP/IP properties, and then join ADRMS-SRV to the domain cpandl.com. You must also add the
account ADRMSADMIN as a member to the local administrators group. This is needed for
ADRMSADMIN to install AD RMS on ADRMS-SRV.
Installing the AD RMS server role will also install Internet Information Services (IIS) 7.0, Message
Queuing, and Windows Internal Database.
First, install Windows Server 2008 as a stand-alone server.
To install Windows Server 2008

3. When prompted for a computer name, type ADRMS-SRV.
Next, configure TCP/IP properties so that ADRMS-SRV has a static IP address of 10.0.0.2. In
addition, configure the DNS server by using the IP address of CPANDL-DC (10.0.0.1).
To configure TCP/IP Properties

1. Log on to ADRMS-SRV with the ADRMS-SRV\Administrator account or another user
2. Click Start, click Control Panel, double-click Network and Sharing Center, click
Manage Network Connections, right-click Local Area Connection, and then click
Properties.
Properties.
mask, type 255.255.255.0.
type 10.0.0.1.
15
box.
Next, join ADRMS-SRV to the cpandl.com domain.
To join ADRMS-SRV to the cpandl.com domain

2. Click Change settings (at the right side under Computer name, domain, and
workgroup settings), and then click Change.
administrative credentials, provide the credentials for CPANDL\Administrator, and then
click OK.
After the computer has restarted, add ADRMSADMIN to the local administrators group on
ADRMS-SRV.
To add ADRMSADMIN to the local administrators group

1. Log on to ADRMS-SRV with the CPANDL\Administrator account or another user account
2. Click Start, click Administrative Tools, and then click Computer Management.
3. Expand System Tools, expand Local User and Groups, and then click Groups.
4. Right-click Administrators, click Add to Group, click Add, type ADRMSADMIN in Enter
the object names to select (examples) box, and then click OK.
5. Click OK, and then close Computer Management.
Configure AD RMS client computer (ADRMS-CLNT)

To configure ADRMS-CLNT, you must install Windows Vista, configure TCP/IP properties, and
then join ADRMS-CLNT to the domain cpandl.com. You must also install an AD RMS-enabled
application. In this example, Microsoft Office Word 2007 Enterprise Edition is installed on
ADRMS-CLNT.
16
1. Start your computer by using the Windows Vista product CD.
2. Follow the instructions that appear on your screen, and when prompted for a computer
name, type ADRMS-CLNT.
Next, configure TCP/IP properties so that ADRMS-CLNT has a static IP address of 10.0.0.4. In
addition, configure the DNS server of CPANDL-DC (10.0.0.1).

1. Log on to ADRMS-CLNT with the ADRMS-CLNT\Administrator account or another user
2. Click Start, click Control Panel, click Network and Internet, and then click Network
and Sharing Center.
3. Click Manage Network Connections, right-click Local Area Connection, and then click
Properties.
Properties.
mask, type 255.255.255.0.
type 10.0.0.1.
box.
Next, join ADRMS-CLNT to the cpandl.com domain.
To join ADRMS-CLNT to the cpandl.com domain

2. Under Computer name, domain, and workgroup settings, click Change settings.
4. On the Computer Name tab, click Change.
6. Click More, and in the Primary DNS suffix of this computer box, type cpandl.com.
17
administrative credentials, provide the credentials, and then click OK.
11. In the System Settings Change dialog box, click Yes to restart the computer.
Finally, install Microsoft Office Word 2007 Enterprise.

1. Log on to ADRMS-CLNT with the CPANDL\Administrator account or another user
2. Double-click setup.exe from the Microsoft Office 2007 Enterprise product disc.
3. Click Customize as the installation type, set the installation type to Not Available for all
applications except Microsoft Office Word 2007 Enterprise, and then click Install Now.
This might take several minutes to complete.
Important
Only the Ultimate, Professional Plus, and Enterprise editions of Microsoft Office 2007
allow you to create rights-protected content. All editions will allow you to consume rights-
protected content.
Step 2: Installing and Configuring AD RMS

on ADRMS-SRV
To install and configure AD RMS, you must add the AD RMS server role.
Windows Server 2008 includes the option to install AD RMS as a server role through Server
Manager. Both installation and configuration of AD RMS are handled through Server Manager.
The first server in an AD RMS environment is the root cluster. An AD RMS root cluster is
composed of one or more AD RMS servers configured in a load-balancing environment. This
step-by-step guide will install and configure a single-server AD RMS root cluster.
Registering the AD RMS service connection point (SCP) requires that the installing user account
be a member of the Active Directory Enterprise Admins group.
18
Important
Access to the Enterprise Admins group should be granted only while AD RMS is being
installed. After installation is complete, the installing user account should be removed
from this group.
To add ADRMSADMIN to the Enterprise Admins group

1. Log on to CPANDL-DC with the cpandl\Administrator account or another user account in
the Domain Admins group.
Computers.
3. In the console tree, expand cpandl.com, double-click Users, and then double-click
Enterprise Admins.
4. Click the Members tab, and then click Add.
5. Type adrmsadmin@cpandl.com, and then click OK.
Install and configure AD RMS as a root cluster.
To add the AD RMS Server Role

1. Log on to ADRMS-SRV as cpandl\ADRMSADMIN.
4. In the Roles Summary box, click Add Roles. The Add Roles Wizard opens.
5. Read the Before You Begin section, and then click Next.
6. On the Select Server Roles page, select the Active Directory Rights Management
Services check box.
7. The Role Services page appears informing you of the AD RMS dependent role services
and features. Make sure that Web Server (IIS), Windows Process Activation Service
(WPAS), and Message Queuing are listed, and then click Add Required Role Services.
Click Next.
8. Read the AD RMS introduction page, and then click Next.
9. On the Select Role Services page, verify that the Active Directory Rights
Management Server check box is selected, and then click Next.
10. Select the Create a new AD RMS cluster option, and then click Next.
11. Select the Use a different database server option.
12. Click Select, type ADRMS-DB in the Select Computer dialog box, and then click OK.
13. In Database instance, click Default, and then click Validate.
19
14. Click Next.
15. Click Specify, type CPANDL\ADRMSSRVC, type the password for the account, click
OK, and then click Next.
16. Ensure that the Use AD RMS centrally managed key storage option is selected, and
then click Next.
17. Type a strong password in the Password box and in the Confirm password box, and
then click Next.
18. Choose the Web site where AD RMS will be installed, and then click Next. In an
installation that uses default settings, the name of the only available Web site should be
Default Web Site.
19. Select the Use an SSL-encrypted connection (https://) option.
20. In the Fully-Qualified Domain Name box, type adrms-srv.cpandl.com, and then click
Validate. If validation succeeds, the Next button becomes available. Click Next.
21. Select the Choose an existing certificate for SSL encryption option, click the
certificate that has been imported for this AD RMS cluster, and then click Next.
22. Type a name that will help you identify the AD RMS cluster in the Friendly name box,
23. Ensure that the Register the AD RMS service connection point now option is
selected, and then click Next to register the AD RMS service connection point (SCP) in
Active Directory during installation.
24. Read the Introduction to Web Server (IIS) page, and then click Next.
25. Keep the Web server default check box selections, and then click Next.
26. Click Install to provision AD RMS on the computer. It can take up to 60 minutes to
complete the installation.
27. Click Finish.
28. Log off the server, and then log on again to update the security token of the logged-on
user account. The user account that is logged on when the AD RMS server role is
installed is automatically made a member of the AD RMS Enterprise Administrators local
group. A user must be a member of that group to administer AD RMS.
Note
At this point in the guide, you can remove cpandl\ADRMSADMIN from the local
Administrators group on ADRMS-DB.
Your AD RMS root cluster is now installed and configured.
Further management of AD RMS is done by using the Active Directory Rights Management
Services console.
20
To open the Active Directory Rights Management Services console
1. Click Start, point to Administrative Tools, and then click Active Directory Rights
Management Services.
From the console, you can configure trust policies, configure exclusion policies, and create rights
policy templates.
Step 3: Verifying AD RMS Functionality on

ADRMS-CLNT
The AD RMS client is included in the default installation of Windows Vista and Windows
Server 2008. Previous versions of the client are available for download for some earlier versions
of the Windows operating system. For more information, see the Windows Server 2003 Rights
Management Services page on the Microsoft Windows Server TechCenter
Before you can consume rights-protected content, you must add the AD RMS cluster URL to the
Local Intranet security zone.
Add the AD RMS cluster URL to the Local Intranet security zone for all users who will be
consuming rights-protected content.
To add AD RMS cluster to Local Intranet security zone

1. Log on to ADRMS-CLNT as Nicole Holliday (cpandl\NHOLLIDA).
5. Click Advanced.
6. In the Add this website to the zone, type https://adrms-srv.cpandl.com, and then
click Add.
7. Click Close.
8. Repeat steps 1–7 for Stuart Railson and Limor Henig.
To verify the functionality of the AD RMS deployment, you will log on as Nicole Holliday and then
restrict permissions on a Microsoft Word 2007 document so that members of the CP&L
Engineering group are able to read the document but unable to change, print, or copy. You will
then log on as Stuart Railson, verifying that the proper permission to read the document has been
21
granted, and nothing else. Then, you will log on as Limor Henig. Since Limor is not a member of
the Engineering group, he should not be able to consume the rights-protected file.

1. Log on to ADRMS-CLNT as Nicole Holliday (cpandl\NHOLLIDA).
Office Word 2007.
3. Type CP&L engineering employees can read this document, but they cannot
change, print, or copy it on the blank document page.
4. Click the Microsoft Office Button, click Prepare, click Restrict Permission, and then
click Restricted Access.
5. Click the Restrict permission to this document check box.
6. In the Read box, type engineering@cpandl.com, and then click OK to close the
Permission dialog box.
7. Click the Microsoft Office Button, click Save As, and then save the file as \\ADRMS-
DB\Public\ADRMS-TST.docx.
Next, log on as Stuart Railson and open the document, ADRMS-TST.docx.
To view a rights-protected document

1. Log on to ADRMS-CLNT as Stuart Railson (cpandl\SRAILSON).
Office Word 2007.
3. Click the Microsoft Office Button, and then click Open.
4. In the File name box, type \\ADRMS-DB\Public\ADRMS-TST.docx, and then click
Open.
Microsoft Office must connect to https://adrms-
srv.cpandl.com:443/_wmcs/licensing to verify your credentials and download your
permission."
5. Click OK.
The following message appears: "Verifying your credentials for opening content with
restricted permissions…".
6. When the document opens, click the Microsoft Office Button. Notice that the Print
option is not available.
7. Close Microsoft Word.
22
8. Log off as Stuart Railson.
Finally, log on as Limor Henig and verify that he is not able to consume the rights-protected file.
To attempt to view a rights-protected document

1. Log on to ADRMS-CLNT as Limor Henig (cpandl\LHENIG).
Office Word 2007.
3. Click the Microsoft Office Button, click Open, and then double-click \\ADRMS-
DB\Public\ADRMS-TST.docx.
Microsoft Office must connect to https://adrms-
srv.cpandl.com:443/_wmcs/licensing to verify your credentials and download your
permission."
4. Click OK.
5. The following message appears: "You do not have credentials that allow you to open
this document. You can request updated permission from nhollida@cpandl.com.
Do you want to request updated permission?"
6. Click No, and then close Microsoft Word.
You have successfully deployed and demonstrated the functionality of AD RMS, using the simple
scenario of applying restricted permissions to a Microsoft Word 2007 document. You can also
use this deployment to explore some of the additional capabilities of AD RMS through additional
23
Windows Server “Longhorn” Beta 3
Release TS Gateway Server Step-By-Step
Setup Guide

Modified: April 2007
Abstract
Terminal Services Gateway (TS Gateway) is a new role service available to users of the
Microsoft Windows Server® Code Name "Longhorn" operating system. TS Gateway
enables authorized remote users to connect to resources on an internal corporate or
private network, from any Internet-connected device. The network resources can be
either terminal servers running RemoteApp™ programs [hosting line-of-business (LOB)
applications] or computers with Remote Desktop enabled. TS Gateway encapsulates
Remote Desktop Protocol (RDP) within HTTPS to help form a secure, encrypted remote
connection between users on the Internet and the internal network resources on which
their productivity applications run.

Active Directory, Terminal Services, Microsoft, MS-DOS, Visual Basic, Visual Studio,
Windows, Windows NT, and Windows Server are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.

Contents
Windows Server “Longhorn” Beta 3 Release TS Gateway Server Step-by-Step Setup
Guide ............................................................................................................................... 7
What is TS Gateway? ...................................................................................................... 7
Who should use TS Gateway? ..................................................................................... 7
Benefits of TS Gateway................................................................................................ 8
In this guide .................................................................................................................. 9
Prerequisites for configuring a TS Gateway server ....................................................... 10
Role, role service, and feature dependencies ............................................................ 10
Administrative credentials .......................................................................................... 11
Client considerations .................................................................................................. 11
Special considerations for TS Gateway......................................................................... 11
Name resolution issues .............................................................................................. 11
Status of TS Gateway server farm members not displayed correctly ........................ 12
Details about active connections through TS Gateway not displayed correctly in TS
Gateway Manager................................................................................................... 12
TS RAPs not associated with computer groups when TS Gateway and Terminal
Server role services are installed on the same computer....................................... 13
AllowAnonymous registry key not created or updated when you enable or disable
HTTPS-HTTP bridging in TS Gateway Manager .................................................... 14
TS Gateway role service does not run if you install TS Gateway on a computer that
already has other server roles installed .................................................................. 15
Key scenarios for TS Gateway ...................................................................................... 15
Overview of the TS Gateway core scenario: Enabling remote access to internal
corporate network resources over the Internet .......................................................... 16
System requirements for the TS Gateway core scenario .......................................... 16
Setting up the TS Gateway core scenario.................................................................. 17
Connection sequence for the TS Gateway core scenario.......................................... 19
Steps for configuring the TS Gateway server ................................................................ 20
1. Install the TS Gateway role service........................................................................ 20
Verify successful role service installation and TS Gateway service status ............ 23
2. Obtain a certificate for the TS Gateway server ...................................................... 23
Certificate installation and configuration process overview .................................... 24
Certificate requirements for TS Gateway................................................................ 26
Create a self-signed certificate for TS Gateway ..................................................... 27
3. Configure a certificate for the TS Gateway server ................................................. 28
Install a certificate on the TS Gateway server ........................................................ 28
Map the TS Gateway server certificate................................................................... 29
Understand authorization policies for TS Gateway .................................................... 30
TS CAPs ................................................................................................................. 30
TS RAPs ................................................................................................................. 31
Computer groups associated with TS RAPs........................................................... 32
4. Create a TS CAP for the TS Gateway server ........................................................ 32
5. Create a TS RAP and specify computers that users can connect to through the TS
Gateway server ....................................................................................................... 34
6. Limit the maximum number of simultaneous connections through TS Gateway
(optional) ................................................................................................................. 36
Configure the Terminal Services client for TS Gateway ......................................... 37
7. Monitor a TS Gateway server ................................................................................ 37
Specify TS Gateway events to log .......................................................................... 38
View details about active connections through a TS Gateway server .................... 41
Overview of the TS Gateway NAP scenario: Enabling NAP health policy checking for
remote access to internal corporate network resources ............................................ 42
System requirements for the TS Gateway NAP scenario .......................................... 43
Setting up the TS Gateway NAP scenario ................................................................. 44
Steps for configuring TS Gateway for the NAP scenario .............................................. 45
1. Enable NAP health policy checking on the TS Gateway server ............................ 46
2. Delete existing TS CAPs and create three new TS CAPs on the TS Gateway
server ...................................................................................................................... 47
3. Configure a Windows Security Health Validator on the TS Gateway server ......... 47
4. Create two health policies on the TS Gateway server ........................................... 48
5. Create three network policies on the TS Gateway server...................................... 49
Configure the Terminal Services client as a NAP enforcement client ....................... 52
Overview of the TS Gateway ISA Server scenario: Enabling SSL bridging for remote
access to internal corporate network resources ........................................................ 52
System requirements for the TS Gateway ISA Server scenario ................................ 53
Configuring connections between ISA Server and TS Gateway server .................... 54
Setting up the TS Gateway ISA Server scenario ....................................................... 55
Steps for configuring TS Gateway for the ISA Server scenario .................................... 56
1. Create a firewall policy on the ISA Server to allow RDP (optional) ....................... 57
2. Export the SSL certificate for the TS Gateway server and copy it to the ISA Server
................................................................................................................................ 57
3. Install the SSL certificate for the TS Gateway server on the ISA Server ............... 58
4. Copy and install the TS Gateway server root certificate on the ISA Server .......... 59
5. Create a new Web publishing rule on the ISA Server............................................ 61
6. Enable or Disable HTTPS-HTTP bridging on the TS Gateway server .................. 63
7. Create access rules on the ISA Server .................................................................. 63
8. Verify client configuration and test end-to-end connectivity ................................... 63
Appendix A: Example script for verifying that the TS Gateway server configuration is
correct......................................................................................................................... 64
Running the Rpcpingtest example script.................................................................... 64
Example of successful output .................................................................................... 65
Rpcping example script .............................................................................................. 65
Disclaimer ................................................................................................................... 66
Additional references ..................................................................................................... 67
Terminal Services Client Step-by-Step Setup Guide for TS Gateway .............................. 67

Known issues ................................................................................................................. 68
Automatic reconnection to TS Gateway server might fail after Terminal Services
client comes out of hibernation ............................................................................... 68
TS Gateway server connection requests from a client running Windows XP with SP2
might fail if a smart card is used for authentication ................................................ 68
Prerequisites for setting up the Terminal Services client for the TS Gateway core
scenario ...................................................................................................................... 68
Steps for configuring a Terminal Services client for the TS Gateway core scenario .... 69
Install the TS Gateway server root certificate on the Terminal Services client
(optional) ................................................................................................................. 70
Configure Remote Desktop Connection settings ....................................................... 71
Verify that end-to-end connectivity through TS Gateway is functioning correctly ...... 73
Prerequisites for setting up the Terminal Services client for the TS Gateway NAP
scenario ...................................................................................................................... 74
Steps for configuring a Terminal Services client as a NAP enforcement client ............ 74
Download and run the Terminal Services NAP client configuration command.......... 75
Test to confirm that the TS Gateway NAP health policy is successfully applied to the
Terminal Services client .......................................................................................... 76
Test for successful blocked connection for NAP-capable client ............................. 77
Verify that the NAP health policy blocked the connection ...................................... 78
Test for successful allowed connection for NAP-capable client ............................. 79
Verify that the NAP health policy allowed the connection ...................................... 80
Test for successful blocked connection for non-NAP capable client ...................... 80
7
Windows Server “Longhorn” Beta 3

Release TS Gateway Server Step-by-Step
Setup Guide
What is TS Gateway?
Windows Server® Code Name "Longhorn" Terminal Services Gateway (TS Gateway) is
a role service that enables authorized remote users to connect to resources on an
internal corporate or private network, from any Internet-connected device. The network
resources can be either terminal servers running RemoteApp™ programs [hosting line-
of-business (LOB) applications] or computers with Remote Desktop enabled.
TS Gateway uses Remote Desktop Protocol (RDP) over HTTPS to help form a secure,
encrypted connection between remote users on the Internet and the internal network
resources on which their productivity applications run.
This guide describes functionality for the Windows Server "Longhorn" Beta 3 release of
TS Gateway.
The procedures in this guide will help you set up a TS Gateway server, enabling remote
users to access terminal servers or computers with Remote Desktop enabled on your
internal corporate or private network.
Note
After you use the procedures in this guide to set up a TS Gateway server, you
must also set up clients to use a TS Gateway server and verify that the end-to-
end connections can be successfully established through TS Gateway. For client
setup and end-to-end connectivity testing instructions, see the Terminal Services
Client Step-by-Step Setup Guide for TS Gateway.
Who should use TS Gateway?

This guide is targeted at these audiences:
• IT administrators, planners, and analysts who are evaluating remote access and
mobile solution products
• Enterprise IT architects and designers
8
• Early adopters
• Security architects who are responsible for implementing trustworthy computing
• IT professionals who are responsible for terminal servers or remote access to
desktops
Benefits of TS Gateway
TS Gateway provides these benefits:
• TS Gateway enables remote users to connect to internal network resources over the
Internet by using an encrypted connection, without needing to configure virtual
private network (VPN) connections.
• TS Gateway provides a comprehensive security configuration model that enables you

to control access to specific internal network resources. TS Gateway provides a
point-to-point RDP connection, rather than allowing remote users access to all
internal network resources.
• TS Gateway enables remote users to connect to internal network resources that are
hosted behind firewalls in private networks and across network address translators
(NATs). With TS Gateway, you do not need to perform additional configuration for the
TS Gateway server or clients for this scenario.
Prior to the release of Windows Server "Longhorn", security measures prevented remote
users from connecting to internal network resources across firewalls and NATs. This is
because port 3389, the port used for RDP connections, is typically blocked for network
security purposes at the firewalls. TS Gateway transmits RDP traffic to port 443 instead,
by using an HTTP Secure Sockets Layer/Transport Layer Security (SSL/TLS) tunnel.
Because most corporations open port 443 to enable Internet connectivity, TS Gateway
takes advantage of this network design to provide remote access connectivity across
multiple firewalls.
• The TS Gateway Manager snap-in console enables you to configure authorization
policies to define conditions that must be met for remote users to connect to internal
network resources. For example, you can specify:
• Who can connect to network resources (in other words, the user groups who can
connect).
• What network resources (computer groups) users can connect to.

• Whether client computers must be members of specific Active Directory®
security groups.
9
• Whether clients need to use smart card authentication or password

authentication, or whether they can use either method.
• You can configure TS Gateway servers and Terminal Services clients to use Network
Access Protection (NAP) to further enhance security. NAP is a health policy creation,
enforcement, and remediation technology that is included in Microsoft®
Windows® XP Service Pack 2, Windows Vista™, and Windows Server "Longhorn".
With NAP, system administrators can enforce health requirements, which can include
software requirements, security update requirements, required computer
configurations, and other settings.
• Whether device and disk redirection is allowed.

• You can use TS Gateway server in conjunction with Microsoft Internet Security and
Acceleration (ISA) Server to enhance security. In this scenario, you can host TS
Gateway servers in a private network rather than a perimeter network (also known as
DMZ, demilitarized zone, and screened subnet), and host ISA Server in the perimeter
network. The SSL connection between the Terminal Services client and ISA Server
can be terminated at the ISA Server, which is Internet-facing.
• TS Gateway Manager provides tools to help you monitor TS Gateway connection
status, health, and events. By using TS Gateway Manager, you can specify events
(such as unsuccessful connection attempts to the TS Gateway server) that you want
to monitor for auditing purposes.
In this guide
• Prerequisites for configuring a TS Gateway server
• Special considerations for TS Gateway
• Key scenarios for TS Gateway
• Overview of the TS Gateway core scenario: Enabling remote access to internal

corporate network resources over the Internet
• Steps for configuring the TS Gateway server
• Overview of the TS Gateway NAP scenario: Enabling NAP health policy checking
for remote access to internal corporate network resources
• Steps for configuring TS Gateway for the NAP scenario
• Overview of the TS Gateway ISA Server scenario: Enabling SSL bridging for
remote access to internal corporate network resources
• Steps for configuring TS Gateway for the ISA Server scenario
10
• Appendix A: Example script for verifying that the TS Gateway server configuration is
correct
Prerequisites for configuring a TS Gateway

server
For TS Gateway to function correctly, you must meet these prerequisites:
• You must have a server with Windows Server "Longhorn" installed.
• You must obtain an SSL certificate for the TS Gateway server if you do not have one
already. By default, on the TS Gateway server, the RPC/HTTP Load Balancing
service and the IIS service use Transport Layer Security (TLS) 1.0 to encrypt
communications between clients and TS Gateway servers over the Internet. For TLS
to function correctly, you must install an SSL certificate on the TS Gateway server.
For information about certificate requirements for TS Gateway and how to obtain and
install a certificate, see Obtain a certificate for the TS Gateway server later in this
guide.
Note
You do not need a certification authority (CA) infrastructure within your
organization if you can use another method to obtain an externally trusted
certificate that meets the requirements for TS Gateway.
• Active Directory Domain Services is only required if you configure a TS Gateway
authorization policy that requires that clients be members of an Active Directory
security group to connect to the TS Gateway server.
Role, role service, and feature dependencies

To function correctly, TS Gateway requires several role services and features to be
installed and running. When you use Server Manager to install the TS Gateway role
service, the following additional roles, role services, and features are automatically
installed and started, if they are not already installed:
• Remote Procedure Call (RPC) over HTTP Proxy

• Web Server (IIS) [Internet Information Services 7.0]
IIS 7.0 must be installed and running for the RPC over HTTP Proxy feature to
function.
11
• Network Policy and Access Services

You can also configure TS Gateway to use another NPS server—formerly known as
a Remote Authentication Dial-In User Service (RADIUS) server—to centralize the
storage, management, and validation of Terminal Services connection authorization
policies (TS CAPs). If you have already deployed an NPS server for remote access
scenarios such as VPN and dial-up networking, using the existing NPS server for TS
Gateway scenarios as well can enhance your deployment.
Administrative credentials
• You must be a member of the Administrators group on the computer that you want to
configure as a TS Gateway server.
Client considerations
For information about client prerequisites and configuration steps, see the Terminal
Services Client Step-by-Step Setup Guide for TS Gateway.
Special considerations for TS Gateway

The following is a special consideration for TS Gateway in the Windows Server
"Longhorn" Beta 3 release.
Name resolution issues

When remote users attempt to access a computer on the internal corporate network
through a TS Gateway server, they can specify either a NetBIOS name or a fully qualified
domain name (FQDN) for the computer that they are attempting to connect to. When
users specify the FQDN name of the target computer, and the associated TS RAP that is
configured on the TS Gateway server uses a NetBIOS name for the target computer, the
client connection will succeed.
However, if the user attempts to connect to the target computer by using its NetBIOS
name when the TS RAP configured on the TS Gateway server uses an FQDN name for
the target computer, name resolution will fail and the user will not be able to connect to
the target computer.
To avoid name resolution failure, and to support either NetBIOS names or FQDNs,
include each possible computer name in the computer group that you create when you
configure a TS RAP. For example, the computer names MySAPReportingServer and
12
MySAPReportingServer.seattle.corp.microsoft.com would each need to be included in

the computer group that you create, although both names represent the same computer.
Status of TS Gateway server farm members not displayed

correctly
When you add TS Gateway servers to the list of servers on the Server Farm tab of the
TS Gateway server Properties dialog box, for each server that you add to the farm, the
status of the server will be displayed under TS Gateway server farm status. In this
release of TS Gateway server, the server status is not displayed correctly in the Status,
Connections, and Details columns. Only the information in the Server name column is
displayed correctly. There is no workaround for this issue.
For information about how to add TS Gateway servers to the list of servers on the Server
Farm tab, see the “Create a TS Gateway server farm” topic in the Windows Server
"Longhorn" TS Gateway Help.
Details about active connections through TS Gateway not

displayed correctly in TS Gateway Manager
In TS Gateway Manager, you can view details about active connections through TS
Gateway by selecting the node that represents your TS Gateway server, clicking
Monitoring, and viewing information in the results pane columns. However, the names of
several columns do not correctly reflect the data that they contain. The following table
summarizes the data that is displayed in each column and whether the data is displayed
correctly in each column (that is, whether the heading in each column correctly reflects
the type of data displayed in the column).
Column name Actual data displayed Is data displayed correctly or

incorrectly?
Connection ID Connection ID Correct
User ID User ID Correct
User Name User name Correct
Connected On Target computer Incorrect
Connection Duration Target port Incorrect
Idle Time Client IP address Incorrect

13
Column name Actual data displayed Is data displayed correctly or

incorrectly?
Target Computer Idle time Incorrect
Client IP Address Connected on Incorrect
Target Port Connection duration Incorrect
Because the User ID and User Name columns display the correct data, you can
successfully disconnect all connections for a user or disconnect a selected connection.
TS RAPs not associated with computer groups when TS

Gateway and Terminal Server role services are installed on
the same computer
If you use Server Manager to install the TS Gateway and Terminal Server role services
simultaneously on the same computer, and if you create a TS RAP during role service
installation, the TS RAP will not be associated with the computer group that you specify.
If you select Allow access to all computers when you create the TS RAP, the TS RAP
properties will not reflect this selection.
For example. if you create a TS RAP and select Allow access to all computers when
you create the policy during role service installation in Server Manager, when the
installation is completed, the Installation Results page will indicate that the installation
completed successfully. However, when you open TS Gateway Manager and then open
the Properties dialog box for the TS RAP that you created during the Server Manager
installation process, this selection will not be displayed on the Computer Group tab. If
you specified a computer group, the computer group would not be displayed on the
Computer Group tab.
To avoid this issue, when you install the TS Gateway role service in Server Manager, do
not install any other role service at the same time. If you plan to install other role services,
install them separately.
If you have already installed the TS Gateway role service with other role services at the
same time and you have encountered this issue, you can resolve this issue by
configuring the computer group for the TS RAP manually, in TS Gateway Manager. For
more information, see Create a TS RAP and specify computers that users can connect to
through the TS Gateway server.
14
AllowAnonymous registry key not created or updated when

you enable or disable HTTPS-HTTP bridging in TS Gateway
Manager
To enable HTTPS-HTTP bridging for TS Gateway scenarios with ISA Server, you must
configure the TS Gateway server appropriately. By design, if you select the Use HTTPS-
HTTP bridging check box on the TS Gateway server (this setting is located on the SSL
Bridging tab of the TS Gateway server Properties dialog box), this enables HTTPS-
HTTP bridging. Clearing this check box enables HTTPS-HTTPS bridging. By design,
selecting or clearing this check box should create or update the AllowAnonymous
registry key value.
However, in the Beta 3 release of TS Gateway, selecting or clearing the Use HTTPS-
HTTP bridging check box does not create or update the AllowAnonymous registry key
value.
To resolve this issue, you must create or update the value of this registry key manually.
Warning
Incorrectly editing the registry can severely damage your system. Before making
changes to the registry, you should back up any valued data on the computer.
To create or update the AllowAnonymous registry key value manually

1. On the TS Gateway server, open Registry Editor. To open Registry Editor, click Start, click
Run, type regedit, and then click OK.
2. Do one of the following:
• If you are enabling HTTPS-HTTP bridging for the first time, after you verify that the Use
HTTPS-HTTP bridging check box is selected in TS Gateway Manager, you must create
the AllowAnonymous registry key.
To do this, in Registry Editor, right-click
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RPC\RpcProxy, and then click
DWORD (32-bit) Value. Type AllowAnonymousas the name for the new value. With
the new registry value selected, on the Edit menu, click Modify Data. In the Edit
DWORD (32-bit) Value dialog box, in Value Data, type 1, and then click OK.
• If you are disabling HTTPS-HTTP bridging, after you verify that the Use HTTPS-HTTP
bridging check box is cleared in TS Gateway Manager, you must update the value of
the AllowAnonymous registry key.
To do this, in Registry Editor, right-click
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RPC\RpcProxy\AllowAnonymous,
15
and then click Modify. In the Edit DWORD (32-bit) Value dialog box, in Value Data,
type 0, and then click OK.
3. Recycle the default application pool in IIS manually by doing the following:
• Open Internet Information Services (IIS) Manager. To open Internet Information

Services (IIS) Manager, click Administrative Tools, and then click Internet
Information Services (IIS) Manager.
• In the Connections pane, expand the server node, and then click Application Pools.
• In the Application Pools pane, click DefaultAppPool.
• In the Actions pane, under Application Pool Tasks, click Recycle.
TS Gateway role service does not run if you install TS

Gateway on a computer that already has other server roles
installed
If you install the TS Gateway role service on a computer that already has other roles
installed, TS Gateway might not function correctly. When this occurs, when a client
attempts to connect to an internal network resource through TS Gateway, the following
error message appears on the client: "This computer can't connect to the remote
computer because the Terminal Services Gateway server is temporarily unavailable. Try
reconnecting later or contact your network administrator for assistance.”
To resolve this issue, restart the TS Gateway role service.
Key scenarios for TS Gateway

This setup guide provides information to help you configure the following three key
scenarios for TS Gateway:
• TS Gateway core scenario: Enabling remote access to internal corporate network

resources over the Internet
• TS Gateway NAP scenario: Enabling NAP health policy checking for remote access
to internal corporate network resources
• TS Gateway ISA Server scenario: Enabling SSL bridging for remote access to
internal corporate network resources
16
Overview of the TS Gateway core scenario:

Enabling remote access to internal corporate
network resources over the Internet
The following steps are required for the successful setup and demonstration of the TS
Gateway core scenario described as an example in this guide. This scenario enables you
to configure TS Gateway server so that a remote user can access an internal corporate
network resource over the Internet, through the TS Gateway server. In this scenario, the
internal corporate network resource can be either a terminal server running RemoteApp
programs [hosting line-of-business (LOB) applications] or a computer with Remote
Desktop enabled.
1. We recommend that you set up three computers to evaluate this scenario. These
computers are:
• The TS Gateway server (known as "TSGSERVER" in this example)
• The Terminal Services client (known as "TSCLIENT" in this example)
• An internal corporate network resource (known as "CORPORATERESOURCE"
in this example)
2. Configure the TS Gateway server by following the instructions in Steps for
configuring the TS Gateway server later in this guide.
3. Configure the Terminal Services client by following the instructions in "Steps for
configuring a Terminal Services client for the TS Gateway core scenario" in the
Terminal Services Client Step-by-Step Setup Guide for TS Gateway.
4. Configure the internal corporate network resource.

5. Demonstrate that the Terminal Services client can connect to the internal corporate
network resource through the TS Gateway server.
System requirements for the TS Gateway core scenario

The three computers used in the TS Gateway core scenario must meet the following
system requirements.
Computer Required configuration
TS Gateway server (TSGSERVER) • Windows Server "Longhorn" Beta 3. The

installation must be a clean installation, not
an upgrade.
17
Terminal Services client (TSCLIENT) • Windows Vista RTM. The installation can
be an upgrade from Windows XP with
Service Pack 2 (SP2).
• Windows XP with SP2 and Remote
Desktop Connection (RDC) 6.0 or later. To
download the installer package for RDC, go
to Microsoft Help and Support
(http://go.microsoft.com/fwlink/?LinkID=793
73).
• Windows Server "Longhorn" Beta 3. The
an upgrade.
• Microsoft Windows Server® 2003 with
Service Pack 1 (SP1) or later and RDC 6.0
or later.
Internal corporate network resource For computers running Remote Desktop:

(CORPORATERESOURCE)
• Windows Vista RTM. The installation can
be an upgrade from Windows XP with SP2.
• Windows XP with SP2.
• Windows Server 2003 with SP1 or later.
For terminal servers hosting LOB applications:

an upgrade.
Setting up the TS Gateway core scenario

Diagram 1 illustrates the core scenario for TS Gateway.
18
Note
The steps in this setup guide describe how to set up the core TS Gateway
scenario for remote access from a Terminal Services client through a TS
Gateway server to an internal corporate network resource. The guide does not
describe how to set up the firewalls illustrated in the diagram, terminal servers
running RemoteApp programs (hosting LOB applications), or the Active Directory
infrastructure. The diagram is provided to suggest one of many ways in which the
TS Gateway core remote access scenario might be implemented in a production
environment.
For information about how to set up a terminal server, see the Help topic "Terminal
Server" (http://go.microsoft.com/fwlink/?LinkId=72052).
For information about setting up RemoteApp programs, see the Windows Server
"Longhorn" Terminal Services RemoteApp Step-by-Step Guide
(http://go.microsoft.com/fwlink/?linkId=84895).
For information about how to enable Remote Desktop, see the topic "Using Remote
Desktop" in the Windows Server "Longhorn" Help.
19
Connection sequence for the TS Gateway core scenario

Following is a simplified description of the sequence that TSCLIENT follows when
connecting through TSGSERVER to CORPORATERESOURCE:
1. The user on the Terminal Services client, TSCLIENT, might initiate the connection by
doing one of the following:
• Clicking an RDP file that the administrator has configured, to access his or her
full desktop.
• Clicking a RemoteApp program icon. RemoteApp programs are represented in
an RDP file that the administrator has configured.
• Visiting a Web site (either from the Internet or from an intranet) to access a list of
RemoteApp programs that the administrator has made available by using
Terminal Services Web Access (TS Web Access), and then clicking a
RemoteApp program icon.
2. An SSL tunnel is established between TSCLIENT and TSGSERVER by using the TS
Gateway server's SSL certificate. Before a connection between TSCLIENT and
TSGSERVER is established, TSGSERVER must authenticate and authorize the user
according to TS CAPs that the administrator has configured on TSGSERVER.
3. After authentication and authorization succeed, TSGSERVER signals TSCLIENT to
continue with the connection sequence.
4. TSCLIENT requests a connection from TSGSERVER to CORPORATERESOURCE.
Before authorizing the request, TSGSERVER verifies that both of the following
conditions are met simultaneously, for at least one Terminal Services resource
authorization policy (TS RAP) that is configured on TSGSERVER:
• CORPORATERESOURCE is a member of a computer group that is specified in
the TS RAP; and
• The user is a member of a user group that is specified in the TS RAP.
If both requirements are met, TSGSERVER authorizes the request.
5. An SSL connection is established between TSCLIENT and TSGSERVER, and an

RDP connection is established between TSGSERVER and
CORPORATERESOURCE.
From this point, any packets that TSCLIENT sends to TSGSERVER are forwarded to
CORPORATERESOURCE, and any packets that CORPORATERESOURCE sends
to TSGSERVER are forwarded to TSCLIENT.
20
6. TSCLIENT will attempt to create a user session on CORPORATERESOURCE.

CORPORATERESOURCE performs Windows authentication to validate the identity
of the user requesting the connection and the privileges that the user has on
CORPORATERESOURCE. (These are the same steps that would be followed if
TSCLIENT were to request a remote connection to CORPORATERESOURCE
without using TSGSERVER.)
7. TSCLIENT exchanges encrypted RDP packets encapsulated within SSL with

TSGSERVER over port 443. TSGSERVER forwards the RDP packets to
CORPORATERESOURCE over port 3389.
Steps for configuring the TS Gateway server

To configure the TS Gateway server, complete these tasks.
Task Reference/Step-by-step instructions
1. Install the TS Gateway role service. Install the TS Gateway role service
2. Obtain a certificate for the TS Gateway Obtain a certificate for the TS Gateway
server. server
3. Configure a certificate for the TS Configure a certificate for the TS Gateway

Gateway server. server
4. Create a Terminal Services connection Create a TS CAP

authorization policy (TS CAP).
5. Create a Terminal Services resource Create a TS RAP

authorization policy (TS RAP).
6. Limit the maximum number of Limit the maximum number of simultaneous

simultaneous connections though TS connections through TS Gateway
Gateway (optional).
7. Monitor the TS Gateway server for Monitor the TS Gateway server for
connection status and reporting. connection status and reporting
1. Install the TS Gateway role service

Follow these steps to install the TS Gateway role service. Optionally, during the role
service installation process, you can select an existing certificate (or create a new self-
signed certificate), and you can create a TS CAP and a TS RAP.
21
To install the TS Gateway role service

1. Open Server Manager. To open Server Manager, click Start, point to
Administrative Tools, and then click Server Manager.
2. In Server Manager, under Roles Summary, click Add roles.

4. On the Select Server Roles page, under Roles, select the Terminal Services
check box, and then click Next.
6. On the Select Role Services page, in the Role services list, select the TS
Gateway check box.
7. If prompted to specify whether you want to install the additional role services
required for TS Gateway, click Add Required Role Services.
8. On the Select Role Services page, click Next.

9. On the Choose a Server Authentication Certificate for SSL Encryption page,
specify whether to choose an existing certificate for SSL encryption
(recommended), create a self-signed certificate for SSL encryption, or choose a
certificate for SSL encryption later.
10. On the Create Authorization Policies for TS Gateway page, specify whether
you want to create a TS CAP and a TS RAP during the TS Gateway role service
installation process or later. If you select Later, follow the procedures in Create a
TS CAP to create this policy. If you select Now, do the following:
• On the Select User Groups That Can Connect Through TS Gateway

page, click Add to specify additional user groups. In the Select Groups
dialog box, specify the user group location and name, and then click OK as
needed to check the name and to close the Select Groups dialog box.
To specify more than one user group, do either of the following: Type the
name of each user group, separating the name of each group with a semi-
colon; or add additional groups from different domains by repeating the first
part of this step for each group.
• After you finish specifying additional user groups, on the Create
Authorization Policies for TS Gateway page, click Next.
• On the Create a TS CAP for TS Gateway page, accept the default name for
the TS CAP (TS_CAP_01) or specify a new name, select one or more
supported Windows authentication methods, and then click Next.
22
• On the Create a TS RAP for TS Gateway page, accept the default name for
the TS RAP (TS_RAP_01) or specify a new name, and then do one of the
following: Specify whether to allow users to connect only to computers in one
or more computer groups, and then specify the computer groups; or specify
that users can connect to any computer on the network. Click Next. If you do
not want to create a TS RAP during the role service installation process,
follow the procedure in Create a TS RAP.
11. On the Network Policy and Access Services page (which appears if this role
service is not already installed), review the summary information, and then click
Next.
12. On Select Role Services, verify that Network Policy Server is selected, and
then click Next.
13. On the Web Server (IIS) page (which appears if this role service is not already
installed), review the summary information, and then click Next.
14. On the Select Role Services page, accept the default selections for Web Server
(IIS), and then click Next.
15. On the Confirm Installation Options page, verify that the following roles, role
services, and features will be installed:
• Terminal Services\TS Gateway
• Network Policy and Access Services
• RPC over HTTP Proxy

• Windows Process Activation Service
16. Click Install.
17. On the Installation Progress page, installation progress will be noted.
If any of these roles, role services, or features has already been installed,
installation progress will be noted only for the new roles, role services, or
features that are being installed.
18. On the Installation Results page, confirm that installation for these roles, role
services, and features was successful, and then click Close.
23
Verify successful role service installation and TS Gateway service

status
Use the following procedure to verify that the TS Gateway role service and dependent
roles, role services, and features are installed correctly and running.
To verify that installation was successful

2. In the console tree, expand Roles, and then double-click Terminal Services.
3. On the Terminal Services summary page, in the System Services area, verify
that the status of Terminal Services Gateway is Running and that the startup
type is set to Auto.
4. Close Server Manager.
5. Open Internet Information Services (IIS) Manager. To open IIS Manager, click
Start, point to Administrative Tools, and then click Internet Information
Services (IIS) Manager.
6. In the console tree, expand <TS Gateway_Server_Name>\Sites\Default Web
Site, and then click Default Web Site.
7. Right-click Default Web Site, point to Manage Web Site, and then click
Advanced Settings.
8. In the Advanced Settings dialog box, under (General), verify that Start
Automatically is set to True. If it is not set to True, click the drop-down arrow to
display the list, and then click True.
9. Click OK.
10. Close IIS Manager.
2. Obtain a certificate for the TS Gateway server

This section assumes an understanding of certificate trust chaining, certificate signing,
and general certificate configuration principles. For information about certificates, see the
Windows Server "Longhorn" TechCenter (http://go.microsoft.com/fwlink/?LinkId=86041).
As mentioned earlier in this guide, by default TLS 1.0 is used to encrypt communications
between Terminal Services clients and TS Gateway servers over the Internet. TLS is a
standard protocol that is used to provide secure Web communications on the Internet or
intranets. TLS is the latest and most secure version of the SSL protocol. For more
24
information about TLS, see SSL/TLS in Windows Server 2003

(http://go.microsoft.com/fwlink/?LinkID=19646) and RFC 2246: The TLS Protocol Version
1.0 (http://go.microsoft.com/fwlink/?LinkID=40979).
For TLS to function correctly, you must install an SSL-compatible X.509 certificate on the
TS Gateway server.
If you already have a certificate, you can reuse it for the TS Gateway server if the
certificate:
• Is issued by one of the trusted public certification authorities (CAs) that participate in
the Microsoft Root Certificate Program Members program [as listed in article 931125
in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=59547)];
and
• Meets the certificate requirements for TS Gateway server.
If the certificate is not trusted by the Microsoft Root Certificate Program Members
program (for example, if you create and install a self-signed certificate on the TS
Gateway server and you do not manually configure the certificate to trust the Terminal
Services client computer), a warning stating that you do not have a trusted certificate
appears when the client attempts to connect through the TS Gateway server, and the
connection will not succeed. To prevent this error from occurring, install the certificate
onto the computer certificate store on the client computer before the client attempts to
connect through the TS Gateway server.
Certificate installation and configuration process overview

The process of obtaining, installing, and configuring a certificate for TS Gateway server
involves the following steps:
1. Obtain a certificate for the TS Gateway server by doing one of the following:
• If your company maintains an enterprise certification authority (CA) that is

configured to issue SSL-compatible X.509 certificates that meet TS Gateway
requirements, you can generate and submit a certificate request by using the
Certreq command-line tool. Certreq enables you to submit, retrieve, create, and
accept certificate requests that are sent to a Windows Server 2003 or
Windows Server "Longhorn" CA. For information about how to use Certreq in
Windows Server 2003, see Certreq
25
Note
The Certificate Request Wizard is not supported for obtaining certificates
for TS Gateway.
Your enterprise CA-issued certificate must be co-signed by a trusted public CA that
participates in the Microsoft Root Certification Program Members program. Otherwise,
users connecting from home computers or kiosks might not be able to connect to TS
Gateway servers. These connections might fail because the enterprise CA-issued root
might not be trusted by computers that are not members of domains, such as home
computers or kiosks.
• If your company does not maintain an enterprise CA that is configured to issue
SSL-compatible X.509 certificates, you can purchase a certificate from a trusted
public CA that participates in the Microsoft Root Certificate Program Members
program (http://go.microsoft.com/fwlink/?LinkID=59547). Some of these vendors
might offer certificates at no cost on a trial basis.
• Alternatively, if your company does not maintain an enterprise CA and you do not
have a compatible certificate from a trusted public CA, you can create and import
a self-signed certificate for your TS Gateway server for technical evaluation and
testing purposes. For step-by-step instructions, see Create a self-signed
certificate for TS Gateway.
In the example configurations described in this guide, a self-signed certificate is

used.
Important
If you use either of the first two methods to obtain a certificate (that is, if
you obtain a certificate from a PKI or a public vendor), you must also
install the certificate on the TS Gateway server and map the certificate.
However, if you create a self-signed certificate by using the Add Roles
Wizard during installation of the TS Gateway role service or by using TS
Gateway Manager after installation (as described in Create a self-signed
certificate for TS Gateway), you do not need to install or map the
certificate to the TS Gateway server. In this case, the certificate is
automatically created, installed in the correct location on the TS Gateway
server, and mapped to the TS Gateway server.
Note that Terminal Services clients must have the certificate of the certification
authority (CA) that issued the server certificate in their Trusted Root Certification
Authorities store. Therefore, if you create a self-signed certificate by following the
procedure in this guide, you must install the root certificate in the client computer
certificate store. For step-by-step instructions, see "Install the TS Gateway server
26
root certificate on the client" in the Terminal Services Client Step-by-Step Setup
Guide for TS Gateway.
If you used one of the first two methods to obtain a certificate and the Terminal
Services client computer trusts the certificate, you do not need to install the certificate
of the CA that issued the server certificate in the client computer certificate store. For
example, you do not need to install the certificate of the issuing CA in the client
computer certificate store if a VeriSign or other public, trusted PKI certificate is
installed on the TS Gateway server and the Terminal Services client computer trusts
the TS Gateway server certificate.
2. Install a certificate on the TS Gateway server. Use this procedure, described later in
this guide, to install the certificate on your TS Gateway server.
3. Map the TS Gateway certificate. This procedure, described later in this guide, allows
you to map the existing certificate to the TS Gateway server.
For information about PKI configuration in Windows Server 2003, see Public Key
Infrastructure (http://go.microsoft.com/fwlink/?LinkId=66539) and Deploying a Public Key
Infrastructure (http://go.microsoft.com/fwlink/?LinkId=66541). For information about
requesting certificates in Windows Server 2003, see Requesting Certificates
Certificate requirements for TS Gateway

Certificates for TS Gateway must meet these requirements:
• The name in the Subject line of the server certificate (certificate name, or CN) must
match the DNS name that the client uses to connect to the TS Gateway server.
• The certificate is a computer certificate.
• The intended purpose of the certificate is server authentication. The Extended Key
Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
• The certificate has a corresponding private key.
• The certificate has not expired. We recommend that the certificate be valid one year
from the date of installation.
• A certificate object identifier (also known as OID) of 2.5.29.15 is not required.
However, if the certificate that you plan to use contains an object identifier of
2.5.29.15, you can only use the certificate if at least one of the following key usage
values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE,
CERT_KEY_AGREEMENT_KEY_USAGE, and
CERT_DATA_ENCIPHERMENT_KEY_USAGE.
27
For more information about these values, see Advanced Certificate Enrollment and
Management (http://go.microsoft.com/fwlink/?LinkID=74577).
• The certificate must be trusted on clients. That is, the public certificate of the CA that
signed the TS Gateway server certificate must be located in the client's Trusted Root
Certification Authorities store.
Create a self-signed certificate for TS Gateway

This procedure describes how to use TS Gateway Manager to create a self-signed
certificate for technical evaluation and testing purposes, if you did not already create one
by using the Add Roles Wizard when you installed the TS Gateway role service.
Note
As mentioned, if you create a self-signed certificate by using the Add Roles
Wizard during installation of the TS Gateway role service, or by using TS
Gateway Manager after installation (as described in this procedure), you do not
need to install or map the certificate to the TS Gateway server. In this case, the
certificate is automatically created, installed in the correct location on the TS
Gateway server, and mapped to the TS Gateway server.
To create a self-signed certificate for the TS Gateway server

1. Open TS Gateway Manager. To open TS Gateway Manager, click Start, point to
Administrative Tools, point to Terminal Services, and then click Terminal
Services Gateway.
2. In the console tree, click to select the node that represents your TS Gateway
server, which is named for the computer on which the TS Gateway server is
running.
3. In the results pane, under Configuration Status, click the View or modify
certificate properties hyperlink.
4. On the SSL Certificate tab, click Create a self-signed certificate for SSL
encryption, and then click Create Certificate.
5. In the Create Self-Signed Certificate dialog box, to store the certificate in a
specified location so that you can manually distribute the certificate to clients,
select the Store the root certificate check box, specify where to store the
certificate, and then click OK.
6. If you selected the Store the root certificate check box and specified a location
for the certificate, a message will appear stating that TS Gateway has
28
successfully created the self-signed certificate, and confirming the location of the
stored certificate. Click OK to close the message.
7. Click OK again to close the TS Gateway server Properties dialog box.
3. Configure a certificate for the TS Gateway server

The process of configuring a certificate for a TS Gateway server involves these steps:
Install a certificate on the TS Gateway server
Map the TS Gateway server certificate
Install a certificate on the TS Gateway server

After you obtain a certificate, use this procedure to install the certificate in the correct
location on the TS Gateway server, if the certificate is not already installed. After you
complete this procedure, you must map the certificate.
Note
This procedure is not required if you created a self-signed certificate by using the
Add Remove Roles Wizard during installation of the TS Gateway role service, or
by using TS Gateway Manager after installation, as described in Create a self-
signed certificate for TS Gateway. In either case, a certificate is automatically
created, installed in the correct location on the TS Gateway server, and mapped
to the TS Gateway server.
To install a certificate on the TS Gateway server

1. Open the Certificates snap-in console. If you have not already added the
Certificates snap-in console, you can do so by doing the following:
• Click Start, click Run, type mmc, and then click OK.
• On the File menu, click Add/Remove Snap-in.

• In the Add or Remove Snap-ins dialog box, in the Available snap-ins list,
click Certificates, and then click Add.
• In the Certificates snap-in dialog box, click Computer account, and then
click Next.
• In the Select Computer dialog box, click Local computer: (the computer
this console is running on), and then click Finish.
• In the Add or Remove snap-ins dialog box, click OK.
29
2. In the Certificates snap-in console, in the console tree, expand Certificates

(Local Computer), and then click Personal.
3. Right-click the Personal folder, point to All Tasks, and then click Import.

5. On the File to Import page, in the File name box, specify the name of the
certificate that you want to import, and then click Next.
6. On the Password page, if you specified a password for the private key
associated with the certificate earlier, type the password.
7. On the Certificate Store page, accept the default option, and then click Next.
8. On the Completing the Certificate Import Wizard page, confirm that the correct
certificate has been selected.
9. Click Finish.
10. After the certificate import has successfully completed, a message appears
confirming that the import was successful. Click OK.
11. With Certificates selected in the console tree, in the details pane, verify that the
correct certificate appears in the list of certificates on the TS Gateway server.
The certificate must be under the Personal store of the local computer.
Map the TS Gateway server certificate

Note that you must use TS Gateway Manager to map the TS Gateway server certificate.
If you map a TS Gateway server certificate by using any other method, TS Gateway will
not function correctly.
Note
This procedure is not required if you created a self-signed certificate by using the
Add Remove Roles Wizard during installation of the TS Gateway role service, or
by using TS Gateway Manager after installation, as described in Create a self-
signed certificate for TS Gateway. In either case, a certificate is automatically
created, installed in the correct location on the TS Gateway server, and mapped
to the TS Gateway server.
To map a certificate to the local TS Gateway server

Services Gateway.
30
2. In the TS Gateway Manager console tree, right-click the local TS Gateway

server, and then click Properties.
3. On the SSL Certificate tab, click Select an existing certificate for SSL
encryption (recommended), and then click Browse Certificates.
4. In the Install Certificate dialog box, click the certificate that you want to use, and
then click Install.
5. Click OK to close the Properties dialog box for the TS Gateway server.
6. If this is the first time that you have mapped the TS Gateway certificate, after the
certificate mapping is completed, you can verify that the mapping was successful
by viewing the TS Gateway Server Status area in TS Gateway Manager. Under
Configuration Status and Configuration Tasks, the warning stating that a
server certificate is not yet installed or selected and the View or modify
certificate properties hyperlink are no longer displayed.
Understand authorization policies for TS Gateway

After you complete the initial installation and configuration steps for the TS Gateway
server described earlier in this guide, you must create Terminal Services connection
authorization policies (TS CAPs), computer groups, and Terminal Services resource
authorization policies (TS RAPs). These policies are required to ensure that TS Gateway
functions correctly.
TS CAPs
TS CAPs allow you to specify who can connect to a TS Gateway server. You can specify
a user group that exists on the local TS Gateway server or in Active Directory Domain
Services. You can also specify other conditions that users must meet to access a TS
Gateway server. For example, you can specify that all users who connect to a specific
terminal server that is hosting a human resources (HR) database through a TS Gateway
server must be members of the "HR Users" security group. You can also specify that the
client computer that is initiating the connection must be a member of an Active Directory
security group in the corporate network to connect to the TS Gateway server. By
requiring that the computer be a member of a specific Active Directory security group in
the corporate network, you can exclude users who are attempting to connect to the
corporate network from kiosks, airport computers, or home computers that are not
trusted.
For enhanced security when clients are connecting to the internal corporate network
through TS Gateway, you can also specify whether to disable client device redirection for
31
all devices supported by the Terminal Services client, or just for a specific type of device
such as a disk drive or Plug and Play devices. If you disable client device redirection for
all devices supported by the client, all Clipboard and file device redirection are disabled,
except for audio and smart card redirection.
Additionally, you can specify whether clients must use smart card authentication or
password authentication to access computers remotely on your corporate network
through a TS Gateway server. When both of these options are selected, clients that use
either authentication method are allowed to connect.
Finally, if your organization has deployed Network Access Protection (NAP), you can
specify that the client must send a statement of health (SoH). For information about how
to configure TS Gateway for NAP, see Overview of the TS Gateway NAP scenario:
Enabling NAP health policy checking for remote access to internal corporate network
resources.
Important
Users are granted access to a TS Gateway server if they meet the conditions
specified in the TS CAP. You must also create a TS RAP. A TS RAP allows you
to specify the network resources that users can connect to through TS Gateway.
Until you create both a TS CAP and a TS RAP, users cannot connect to network
resources through this TS Gateway server.
TS RAPs
TS RAPs allow you to specify the internal corporate network resources that remote users
can connect to through a TS Gateway server. When you create a TS RAP, you can
create a computer group and associate it with the TS RAP. For example, you can specify
that users who are members of the “HR Users” user group be allowed to connect only to
computers that are members of the “HR Computers” computer group, and that users who
are members of the “Finance Users” user group be allowed to connect only to computers
that are members of the "Finance Computers" computer group.
Remote users connecting to an internal corporate network through a TS Gateway server
are granted access to computers on the network if they meet the conditions specified in
at least one TS CAP and one TS RAP.
Note
Client users can specify a NetBIOS name or a fully qualified domain name
(FQDN) for the internal corporate network computer that they want to access
through the TS Gateway server. To support either NetBIOS or FQDN names,
create a TS RAP for each possible computer name.
32
Together, TS CAPs and TS RAPs provide two different levels of authorization to provide
you with the ability to configure a more specific level of access control to computers on
the internal corporate network.
Computer groups associated with TS RAPs

Remote users can connect through TS Gateway to internal corporate network resources
in a computer group. The computer group members can be any one of the following:
• Members of an existing Windows group. The Windows group can exist in Local Users
and Groups on the TS Gateway server, or it can exist in Active Directory Domain
Services.
• Members of an existing TS Gateway-managed computer group or a new

TS Gateway-managed computer group. You can add the computers to which you
want to provide user access to the TS Gateway-managed computer group by using
TS Gateway Manager.
A TS Gateway-managed group will not appear in Local Users and Groups on the
TS Gateway server, nor can it be configured by using Local Users and Groups.
• Any network resource. In this case, users can connect to any computer on the
internal corporate network that they could connect to when they use Remote
Desktop.
4. Create a TS CAP for the TS Gateway server

This procedure describes how to use TS Gateway Manager to create a custom TS CAP.
Alternatively, you can use the Authorization Policies Wizard to quickly create a TS CAP
and a TS RAP for TS Gateway.
Important
If you configure more than one TS CAP, keep in mind that TS Gateway uses the
following policy lookup behavior: policies are applied in the numerical order
shown in the TS Gateway Manager results pane, and access to the TS Gateway
server is granted by the first matching policy. That is, if a client does not meet the
requirements of the first TS CAP in the list, TS Gateway will evaluate the second
policy in the list, and so forth, until it locates a TS CAP whose requirements are
met. If a client does not meet the requirements of any TS CAP in the list,
TS Gateway denies access to the client.
33
To create a TS CAP for the TS Gateway server

1. Open TS Gateway Manager.
2. In the console tree, click to select the node that represents the TS Gateway
running.
3. In the console tree, expand Policies, and then click Connection Authorization
Policies.
4. Right-click the Connection Authorization Policies folder, click Create New
Policy, and then click Custom.
5. On the General tab, type a name for the policy, and then verify that the Enable
this policy check box is selected.
6. On the Requirements tab, under Supported Windows authentication
methods, select one or both of the following check boxes:
• Password
• Smart card
When both of these options are selected, clients that use either authentication
method are allowed to connect.
7. Under User group membership (required), click Add Group to select the user
groups to which you want this TS CAP to apply.
8. In the Select Groups dialog box, specify the user group location and name, and
then click OK. To specify more than one user group, do either of the following:
• Type the name of each user group, separating the name of each group with
a semi-colon.
• Add additional groups from different domains by repeating Step 8 for each
group.
9. To specify computer domain membership criteria that client computers should
meet (optional), on the Requirements tab, under Client computer group
membership (optional), click Add Group, and then specify the computer
groups. In the example configurations, no computer group is specified.
To specify computer groups, you can use the same steps that you used to
specify user groups.
10. On the Device Redirection tab, select one of the following options to enable or
disable redirection for remote client devices:
34
• To permit all client devices to be redirected when connecting through the TS

Gateway server, click Enable device redirection for all client devices.
• To disable device redirection for all client devices except for audio and smart
cards, select Disable device redirection for all remote client devices
except for smart cards.
If you disable device redirection for all client devices, the client will not
redirect the Clipboard, storage drives, printers, serial ports, or Plug-and-Play
devices. Audio and smart card redirection behavior are not affected by this
setting. Instead, audio and smart card redirection behavior will be determined
by settings on the client.
• To disable device redirection for only certain device types, click Disable
device redirection for the following client device types, and then select
the check boxes that correspond to the client device types for which device
redirection should be disabled.
11. Click OK.
12. The new TS CAP that you created appears in the TS Gateway Manager results
pane. Click the name of the TS CAP to view the policy details in the lower pane.
5. Create a TS RAP and specify computers that users can

connect to through the TS Gateway server
This procedure describes how to use TS Gateway Manager to create a custom TS RAP,
and to specify computers that users can connect to through the TS Gateway server.
Alternatively, you can use the Authorization Policies Wizard to complete these tasks.
Important
If users are connecting to members of a terminal server farm, you must select the
Select an existing TS Gateway-managed computer group or create a new
one option on the Computer Group tab. In the computer group, you must
specify the name of the farm rather than the name of each member must be
specified in the computer group.
To create a TS RAP and specify computers that users can connect to through
the TS Gateway server
35
running.
3. In the console tree, expand Policies, and then click Resource Authorization
Policies.
4. Right-click the Resource Authorization Policies folder, click Create New

Policy, and then click Custom.
5. On the General tab, in the Policy name box, enter a name that is no longer than
64 characters.
6. In the Description box, enter a description for the new TS RAP.
7. On the User Groups tab, click Add to select the user groups to which you want
this TS RAP to apply.
8. In the Select Groups dialog box, specify the user group location and name, and
then click OK. To specify more than one user group, do either of the following:
• Type the name of each user group, separating the name of each group with
a semi-colon.
• Add additional groups from different domains by repeating Step 7 for each
group.
9. On the Computer Group tab, specify the computer group that users can connect
to through TS Gateway. Then, do one of the following:
• To specify an existing computer group, click Select an existing Windows

group, and then click Browse. In the Select Group dialog box, specify the
user group location and name, and then click OK.
• To specify a TS Gateway-managed computer group, click Select an existing

TS Gateway-managed computer group or create a new one, and then
click Browse. In the Select a TS Gateway-managed Computer Group
dialog box, do one of the following:
Select an existing TS Gateway-managed computer group by clicking the
name of the computer group that you want to use, and then click OK to close
the dialog box.
Create a new TS Gateway-managed computer group by clicking Create New
Group. On the General tab, type a name and description for the new group.
On the Network Resources tab, type the name or IP address of the
computer or Terminal Services farm that you want to add, and then click
Add. Repeat this step as needed to specify additional computers, and then
click OK to close the New TS Gateway-Managed Computer Group dialog
box. In the Select a TS Gateway-managed Computer Group dialog box,
36
click the name of the new computer group, and then click OK to close the
dialog box.
Important
When you add an internal corporate network computer to the list of
TS Gateway-managed computers, keep in mind that if you want to
allow remote users to connect to the computer by specifying either
its computer name or its IP address, you must add the computer to
the computer group twice (by specifying the computer name of the
computer and adding it to the computer group and then specifying
the IP address of the computer and adding it to the computer group
again). If you specify only an IP address for a computer when you
add it to a computer group, users must also specify the IP address of
that computer when they connect to that computer through TS
Gateway. To ensure that remote users connect to the internal
corporate network computers that you intend, we recommend that
you do not specify IP addresses for the computers, if the computers
are not configured to use static IP addresses. For example, you
should not specify IP addresses if your organization uses DHCP to
dynamically reconfigure IP addresses for the computers.
• To specify any network resource, click Allow users to connect to any

network resource, and then click OK.
10. After you specify a computer group, the new TS RAP that you created appears in
the TS Gateway Manager results pane. When you click the name of the TS RAP,
the policy details appear in the lower pane.
6. Limit the maximum number of simultaneous connections

through TS Gateway (optional)
By default, no limit is set for the number of connections that clients can make to
resources on the network through a TS Gateway server. To optimize TS Gateway server
performance or to ensure compliance with the connection/security policies of your
organization, you can set a limit for the number of simultaneous connections that clients
can make to network resources through a TS Gateway server.
To limit the maximum number of allowable connections for TS Gateway

37
running.
3. In the console tree, expand Monitoring.
4. With the Monitoring folder selected, right-click the Monitoring folder, and then
click Edit Connection Limit.
5. On the General tab, under Maximum Connections, do one of the following:
• To set a limit for the maximum number of simultaneous connections that
Terminal Services clients can make to network resources through TS
Gateway, click Limit maximum allowed simultaneous connections to,
and then specify the number of allowable connections.
• To set no limit on the number of allowable connections between clients and
network resources through TS Gateway, click Allow the maximum
supported simultaneous connections. This is the default option.
• To prevent new connections from being made between clients and network
resources through TS Gateway, click Disable new connections. If you
select this option, only new connection attempts will be rejected. Current
connections will not be ended.
6. Click OK.
Configure the Terminal Services client for TS Gateway

For information about configuring the Terminal Services client for TS Gateway, see the
Terminal Services Client Step-by-Step Setup Guide for TS Gateway.
Note
New Remote Desktop Connection (RDC) software is available for use on
Windows Server 2003 with Service Pack 1 or later and Windows XP with Service
Pack 2. To use any new Terminal Services features (including TS Gateway) on
either of these platforms, download the installer package for RDC 6.0 or later. To
download this package, go to Microsoft Help and Support
(http://go.microsoft.com/fwlink/?LinkID=79373). Clients must have RDC 6.0 or
later installed to connect to TS Gateway servers.
7. Monitor a TS Gateway server

After you have configured Terminal Services clients to connect to remote computers on
the network through TS Gateway, you can monitor active connections. This section
38
provides the following information about monitoring active connections through a TS

Gateway server:
• Specify TS Gateway events to log
• View details about active connections through a TS Gateway server
Specify TS Gateway events to log

By using TS Gateway Manager, you can specify the types of events that you want to
monitor, such as unsuccessful or successful connection attempts to internal corporate
network computers through a TS Gateway server.
When these events occur, you can monitor the corresponding events by using Windows
Event Viewer. TS Gateway server events are stored in Event Viewer under Application
and Services Logs\Microsoft\Windows\Terminal Services-Gateway\.
To specify TS Gateway events to log

running.
3. With the name of the TS Gateway server highlighted in the console tree, right-
click the name of the server, and then click Properties.
4. On the Auditing tab, select or clear the appropriate check boxes to specify the
events that you want to monitor for TS Gateway.
The following table lists and describes the TS Gateway event types that you can monitor.
39
Table 1: TS Gateway Event Types
Event name Description Event ID
Successful User By monitoring the 303: When the client

Disconnection from the timestamp for this event disconnects from the
Resource and the related Successful resource
User Connection to the
202: When an administrator
Resource event, you can
disconnects the client
verify the user session time
and the amount of data (in
kilobytes) that was sent and
received by the client
through the TS Gateway
server.
Failed User Connection to The client met the 304

the Resource conditions specified in the
Terminal Services
connection authorization
policy (TS CAP) and the
Terminal Services resource
authorization policy
(TS RAP), but could not
connect to the remote
computer through the
TS Gateway server
because the remote
computer was unavailable.
By auditing this event, you

can determine which
connectivity issues are
caused by problems with
Terminal Services and
Remote Desktop rather
than the TS Gateway
server, when clients cannot
connect to remote
computers through the
TS Gateway server.
40
Failed Connection The client could not 201

Authorization connect to a TS Gateway
server because the client
did not meet the conditions
specified in the TS CAP.
Failed Resource The client could not 301

Authorization connect through a
TS Gateway server to the
specified resource because
no TS RAPs are configured
to allow the user access to
the specified resource.
For example, as mentioned
earlier, this issue might
occur if the user attempts to
connect to the remote
computer by using its
NetBIOS name when the
TS RAP configured on the
TS Gateway server uses an
FQDN name for the remote
computer.
Successful User The user successfully 302

Connection to the connected to a remote
Resource computer through the
TS Gateway server.
Successful Connection The client successfully 200

Authorization connected to the
TS Gateway server
because the client met the
conditions specified in the
TS CAP.
41
Successful Resource The client successfully 300

Authorization connected through the
TS Gateway server to the
specified resource because
the client met the
conditions specified in the
TS RAP.
View details about active connections through a TS Gateway server

Information about active connections from Terminal Services clients to internal corporate
network resources through TS Gateway includes:
• The domain and user ID of the user logged onto the client
• The IP address of the client
Note
If your network configuration includes proxy servers, the IP address that appears
in the Client IP Address column (in the Monitoring details pane) will reflect the
IP address of the proxy server, rather than the IP address of the Terminal
Services client.
• The name of the target computer to which the client is connected

• The target port through which the client is connected
• The date and time when the connection was initiated
• The length of time that the connection is idle, if applicable

• The connection duration
• The amount of data (in kilobytes) that was sent and received by the client through the
TS Gateway server
To view details about active connections through a TS Gateway server

running.
42
3. In the console tree, click Monitoring.

The TS Gateway Manager results pane displays a summary of the number of
connections from users to specific remote computers. Specific connections, if
any, are listed below the summary.
When you click a connection, the connection details appear in the lower pane. If
necessary, you can disconnect one or all TS Gateway connections for a user.
4. To refresh the display of connection status, in the Actions pane, click Refresh.
Overview of the TS Gateway NAP scenario:

Enabling NAP health policy checking for
remote access to internal corporate network
resources
To enhance security, you can configure TS Gateway servers and clients to use Network
Access Protection (NAP). NAP is a health policy creation, enforcement, and remediation
technology that is included in Windows Vista and Windows Server "Longhorn". By using
NAP, you can enforce health requirements on clients that connect to the TS Gateway
server, which can include firewalls being enabled, security update requirements, and
other required computer configurations.
Note
TS Gateway currently does not support remediation.
This section describes how to configure NAP with the TS Gateway server. By using NAP,
you can help ensure that clients meet the health policy requirements of your organization
before they are allowed to connect to internal corporate network resources through TS
Gateway servers.
The following steps are required for the successful setup and demonstration of the TS
Gateway NAP scenario described as an example in this guide.
1. We recommend that you set up three computers to evaluate this scenario. These
computers are:
• The TS Gateway server/Network Policy Server (NPS server) (known as
"TSGSERVER" in this example)
• The Terminal Services client (known as "TSCLIENT" in this example)

43
• An internal corporate network resource (known as "CORPORATERESOURCE"

in this example)
2. Complete the core TS Gateway server configuration by following the instructions in
Steps for configuring the TS Gateway server earlier in this guide. Then, configure the
TS Gateway server/NPS server for NAP health policy checking by following the
instructions in Steps for configuring TS Gateway for the NAP scenario also in this
guide.
3. Complete the core Terminal Services client configuration for TS Gateway by following
the instructions in "Steps for configuring a Terminal Services client for the TS
Gateway core scenario" in the Terminal Services Client Step-by-Step Setup Guide
for TS Gateway. Then, configure the client as a NAP enforcement client by following
the instructions in "Steps for configuring a Terminal Services client as a NAP
enforcement client" in the same guide.
4. Configure the internal corporate network resource. As mentioned, this resource can
be any terminal server that runs RemoteApp programs (hosts LOB applications) or
any computer with Remote Desktop enabled.
5. Verify that the NAP health policies created on the TS Gateway server are
successfully applied to the Terminal Services client by completing the following two
tasks:
• Testing for a successful blocked connection. If the health policies are correctly
applied to the Terminal Services client, the client connection attempt will be
blocked by the NPS server when automatic updating is disabled on the Terminal
Services client computer.
• Testing for a successful allowed connection. If the health policies are correctly
applied to the Terminal Services client, the client connection attempt will be
allowed by the NPS server when automatic updating is enabled on the Terminal
Services client computer.
To complete these tasks, follow the instructions in "Verify that the NAP health policies are
successfully applied to the Terminal Services client" in the Terminal Services Client Step-
by-Step Setup Guide for TS Gateway.
System requirements for the TS Gateway NAP scenario

The three computers used in the TS Gateway NAP scenario must meet the following
44
TS Gateway server (TSGSERVER) • In this scenario, TSGSERVER is used as

the TS Gateway server and as an NPS
server, and it must run Windows Server
"Longhorn" Beta 3. The installation must be
a clean installation, not an upgrade.
Terminal Services client (TSCLIENT) In this scenario, TSCLIENT is used as a

Terminal Services client and as a NAP client,
and it can run any of the following:
• Windows Vista RTM. The installation can

be an upgrade from Windows XP with SP2.
• Windows XP with SP2, with the latest
Terminal Services client and the NAP client
for Windows XP with SP2 installed. To
download the installer package for RDC 6.0
or later and the NAP client for Windows XP
with SP2, go to Microsoft Help and Support
73).
Windows Server "Longhorn" Beta 3. The
installation must be a clean installation.
Internal corporate network resource • Windows Vista RTM. The installation can
(CORPORATERESOURCE) be an upgrade from Windows XP with SP2.

• Windows Server "Longhorn" Beta 3
release. The installation must be a clean
installation.
Setting up the TS Gateway NAP scenario

Diagram 2 illustrates how TS Gateway can be used with NAP.
45
Note
The steps in this setup guide describe how to set up remote access from a
Terminal Services client through a TS Gateway server to an internal corporate
network resource, with health policy checking for Terminal Services (the NPS
server is used to perform the health policy checking). The guide does not
describe how to set up the firewalls illustrated in the diagram, the terminal
servers running RemoteApp programs, or the perimeter network or Active
Directory infrastructure. The diagram is provided to suggest one way in which
this scenario might be implemented in a production environment.
Steps for configuring TS Gateway for the NAP

scenario
To configure the TS Gateway server NAP scenario, complete these tasks.
46
1. Enable NAP health policy checking on Enable NAP health policy checking on the
the TS Gateway server. TS Gateway server
2. Delete existing TS CAPs and create Delete existing TS CAPs and create three
three new TS CAPs on the TS Gateway new TS CAPs on the TS Gateway server
server.
3. Configure a Windows Security Health Configure a Windows Security Health

Validator on the TS Gateway server. Validator on the TS Gateway server
4. Create two health policies on the TS Create two health policies on the TS
Gateway server. Gateway server
5. Create three network policies on the TS Create three network policies on the TS
Gateway server. Gateway server
1. Enable NAP health policy checking on the TS Gateway

server
To enable NAP health policy checking on the TS Gateway server, you enable a setting
on the server that requests that the Terminal Services client send an SoH.
ToTo enable health checking on the TS Gateway server

Services Gateway.
2. In the TS Gateway Manager console tree, right-click the local TS Gateway

server, and then click Properties.
3. On the TS CAP Store tab, select the Request clients to send a statement of
health check box.
4. A message will appear, stating that you must also configure TS CAPs for NAP to
ensure that health policies are enforced. Click OK to close the message.
5. Click OK again to close the TS Gateway server Properties dialog box.

47
2. Delete existing TS CAPs and create three new TS CAPs

on the TS Gateway server
If you have already created one or more TS CAPs on the TS Gateway server by using TS
Gateway Manager and following the procedures in for the TS Gateway core scenario
described earlier in this guide, we strongly recommend that you delete those TS CAPs by
following the steps in this procedure.
Warning
Failure to delete existing TS CAPs might result in security vulnerabilities for your
internal corporate network because these TS CAPs might bypass the NAP
authorization policies that you will create for the TS Gateway NAP scenario. If the
NAP authorization policies are bypassed, Terminal Services clients that don't
meet NAP authorization policy requirements will be allowed access to the TS
Gateway server.
To delete existing TS CAPs on the TS Gateway server/NPS server

2. In the console tree, click to select the node that represents the TS Gateway
running.
3. In the console tree, expand Policies, and then click Connection Authorization
Policies.
4. In the details pane, right-click any existing TS CAPs, and then click Delete.
After you delete any previously created TS CAPs from TS Gateway Manager, create
three new identical TS CAPs (TSCAP1, TSCAP2, and TSCAP3) by following the
procedures in Create a TS CAP for the TS Gateway server.
If you have not already done so, also create a TS RAP in TS Gateway Manager. If you
have already created a TS RAP that meets your security requirements, you do not need
to delete the existing TS RAP and create a new TS RAP. For step-by-step instructions
about how to create a TS RAP, see earlier in this guide.
3. Configure a Windows Security Health Validator on the TS

Gateway server
When you configure a Windows Security Health Validator (WSHV), you are creating a
client health policy that establishes the requirements for client computers that are allowed
to connect to your network. When client computers attempt to connect to your network
48
and their configuration does not match the WSHV, their network connection is blocked
until the clients meet the conditions of the WSHV.
In this example, the WSHV only requires that automatic updating be enabled.
To configure a Windows Security Health Validator on the TS Gateway server

1. Open the Network Policy Server snap-in console. To open Network Policy
Server, click Start, point to Administrative Tools, and then click Network
Policy Server.
2. In the console tree, expand Network Access Protection, and then click System
Health Validators.
3. In the details pane, right-click Windows Security Health Validator, and then
click Properties.
4. In the Windows Security Health Validator Properties dialog box, on the
Settings tab, click Configure.
5. On the Windows Vista and/or the Windows XP SP2 tab (depending on the
operating system that the Terminal Services client is running), clear every check
box except for Automatic updating is enabled and Windows Update.
6. Click OK to close the Windows Security Health Validator Properties dialog
box (with the Windows Vista and Windows XP tabs, and then click OK again to
close the Windows Security Health Validator Properties dialog box with the
Settings tab.
4. Create two health policies on the TS Gateway server

Health policies allow you to specify health requirements in terms of installed system
health validators (SHVs) and whether NAP clients must pass or fail any or all of the
selected SHVs.
To create two health policies on the TS Gateway server

Policy Server.
2. In the console tree, expand Policies, and then click Health Policies.
3. Right-click the Health Policies folder, and then click New.
4. In the Create New Health Policy dialog box, on the Settings tab, under Policy
49
name, type FAIL.

5. Under Client SHV check, select Client fails one or more SHV checks.
6. Under SHVs used in this health policy, select the Windows Security Health
Validator check box.
7. Click OK.
8. Repeat Steps 3 through 7 to create a second health policy, specifying these
settings in the Create New Health Policy dialog box:
Name: PASS
Client SHV check: Client passes all SHV checks
SHVs used in this health policy: Windows Security Health Validator

9. Click OK.
5. Create three network policies on the TS Gateway server

A network policy contains an ordered set of rules that define how connection attempts are
either authorized or rejected. For each rule, there is a policy type that either grants or
denies access, one or more conditions, and policy settings. If a connection is authorized,
the network policy settings can specify a set of connection restrictions. For NAP, network
policies specify the conditions to check for health requirements and, for noncompliant
NAP-capable clients or clients that are not NAP-capable, the enforcement behavior. To
be NAP-capable, a client must be able to produce a statement of health (SoH), which
contains the client's compliance status.
To configure network policies in the Network Policy Server console, use the following
procedure.
ToTo create three network policies on the TS Gateway server

Policy Server.
2. In the console tree, expand Policies, and then click Network Policies.
Important
When you select the Network Policies folder in the console tree, a default
policy, TSG Marker Policy <GUID>, appears in the console tree. Do not
delete or modify this policy. Additionally, any TS CAPs that you have
50
created by using TS Gateway Manager will also appear in Network

Policy Server, if you have already created such a TS CAP (for example,
if you have followed the steps for configuring the TS Gateway core
scenario, as described in Steps for configuring the TS Gateway server,
at least one additional TS CAP will appear). Do not use the Network
Policy Server snap-in console to delete or modify these TS CAPS.
3. With Network Policies selected in the console tree, right-click TSCAP1, and
4. In the TSCAP1 Properties dialog box, on the Overview tab, change the name of
the TS CAP to TSCAP FAIL, and accept the default values, where:
• The Policy enabled check box is selected
• Access Permission: Grant access
• The Ignore user account dial-in properties check box is selected

• The Type of network access server option is selected, with Terminal
Server Gateway selected in the list.
5. On the Conditions tab, click Add.
6. In the Select condition dialog box, click Health Policies, and then click Add.
7. In the Health Policies dialog box, under Health policies, click FAIL, and then
click OK to close this dialog box.
8. On the Conditions tab, verify that the value of the Health Policy condition is
FAIL.
9. On the Constraints tab, verify that only the Allow clients to connect without
negotiating an authentication method check box is selected.
10. On the Settings tab, browse to Network Access Protection\NAP
Enforcement. With NAP Enforcement selected in the navigational tree, select
Allow limited access.
11. Verify that the following check boxes are not selected:
• Allow full network access for a limited time

• Enable auto-remediation of client computers
Functionality for these two options is not available for TS Gateway server in
the Beta 3 Release. Therefore, the conditions of the health policy are
enforced immediately and clients who do not meet the conditions of the
health policy will not be able to connect to the TS Gateway server.
51
Additionally, non-compliant computers cannot be updated. Instead, non-

compliant computers will not be allowed to connect to the TS Gateway
server.
12. Click OK to close the TSCAP1 Properties dialog box.

13. With Network Policies selected in the console tree, open the properties for
TSCAP2, and on the Overview tab, change the name to TSCAPPASS, and
accept the default settings.
15. In the Select condition dialog box, click Health Policies, and then click Add.
16. In the Health Policies dialog box, under Health policies, click PASS, and then
click OK.
17. On the Conditions tab, verify that the value of the Health Policy condition is
PASS.
negotiating an authentication method is selected.

Enforcement. With NAP Enforcement selected in the navigational tree, verify
that Allow full network access is selected.
20. Click OK to close the TSCAP2 Properties dialog box.

21. With Network Policies selected in the console tree, right-click TSCAP3, and
22. On the Overview tab, change the name to NONNAPCAP, and accept the default
settings.
24. In the Select condition dialog box, click NAP-Capable Computers, and then
click Add.
25. In the NAP-Capable Computers dialog box, click Only computers that are not
NAP-Capable, and then click OK.
26. On the Conditions tab, verify that the value of the NAP-Capable condition is
Computer is not NAP-Capable.
negotiating an authentication method check box is selected.
52
Enforcement. With NAP Enforcement selected in the navigational tree, select

Allow limited access.
For each NAP policy that you create, you must create three corresponding TS CAPs (one
PASS, one FAIL, and one NONNAPCAP). Additionally, one TS Gateway marker policy
must exist for all TS CAPs. If the correct policies are not configured for NAP enforcement,
clients who do not meet NAP health requirements will not receive the correct NAP error
message. Instead, clients in this scenario will receive a general TS CAP error message.
Configure the Terminal Services client as a NAP

enforcement client
After you configure the TS Gateway server/NPS server for NAP health policy checking,
you must configure the Terminal Services client as a NAP enforcement client. For step-
by-step instructions, see "Steps for configuring a Terminal Services client as a NAP
enforcement client" in the Terminal Services Client Step-by-Step Setup Guide for TS
Gateway.
Overview of the TS Gateway ISA Server

scenario: Enabling SSL bridging for remote
access to internal corporate network
resources
You can use Internet Security and Acceleration (ISA) Server 2004 with TS Gateway to
enhance security for TS Gateway server by configuring ISA Server to function as an SSL
bridging device. When SSL bridging is used, ISA Server can terminate SSL sessions,
inspect packets, and re-establish SSL sessions. ISA Server helps enhance security by
decrypting incoming SSL traffic, statefully inspecting the traffic for malicious code, and
then blocking connections that contain suspicious packets or packets that reflect known
exploits. ISA Server also performs stateful HTTP filtering, which provides deep inspection
of HTTP application content.
Following are three scenarios in which ISA Server and TS Gateway server can be used
together to enhance security for remote connections to internal corporate network
resources:
• ISA Server as an SSL bridging device. In this scenario, ISA Server is hosted in a
perimeter network with SSL bridging. The TS Gateway server is hosted in the
corporate/private network.
53
This scenario is illustrated in Diagram 3, in the next section.

• ISA Server as a firewall and SSL bridging device. In this scenario, ISA Server
functions as a firewall that performs port filtering, packet filtering (checking for RPC
verbs), and SSL bridging. The TS Gateway server is hosted in the corporate/private
network.
• ISA Server as a firewall that performs port filtering. In this scenario, ISA Server
functions as an external firewall and permits traffic only over port 443.The TS
Gateway server is hosted in a perimeter network.
Note
The steps in this setup guide provide detailed configuration information only for
the first scenario (ISA Server as an SSL bridging device). The other two
scenarios are mentioned as alternate ways in which ISA Server can be used with
TS Gateway to enhance security for remote connections to internal corporate
network resources.
System requirements for the TS Gateway ISA Server

scenario
The four computers used in the TS Gateway ISA Server scenario must meet the following
TS Gateway server (TSGSERVER) • Windows Server "Longhorn" Beta 3. The

an upgrade.
ISA Server (ISASERVER) • Windows Server 2003 with ISA

Server 2004 with Service Pack 1 Standard
Edition. Two network adapters are required
because ISA Server serves as the bridge
between the Internet and the internal
corporate network.
54
Terminal Services client (TSCLIENT) • Windows Vista RTM. The installation can
be an upgrade from Windows XP with
Service Pack 2.
• Windows XP with SP2 and the Terminal
Services client, Remote Desktop
Connection (RDC) 6.0 or later. To
download the installer package for RDC, go
to Microsoft Help and Support
73).

an upgrade.
• Windows Server 2003 with SP1 or later

and RDC 6.0 or later.
Internal corporate network resource • Windows Vista RTM. The installation can
(CORPORATERESOURCE) be an upgrade from Windows XP with SP2.

an upgrade.
Configuring connections between ISA Server and TS

Gateway server
You can configure ISA Server communication with the TS Gateway server in either of the
following two ways:
• HTTPS-HTTPS bridging: In this configuration, the TS Gateway client initiates an SSL
(HTTPS) request to the SSL bridging device. The SSL bridging device initiates a new
HTTPS request to the TS Gateway server, for maximum security.
55
• HTTPS-HTTP bridging: In this configuration, the TS Gateway client initiates an SSL

(HTTPS) request to the SSL bridging device. The SSL bridging device initiates a new
HTTP request to the TS Gateway server.
Setting up the TS Gateway ISA Server scenario

Diagram 3 illustrates the ISA Server scenario for TS Gateway, in which ISA Server is
used as an SSL bridging device.
Note
The steps in this setup guide describe how to set up remote access from a
Terminal Services client through a TS Gateway server, where SSL traffic from
the client is first sent to the ISA Server, which is used for SSL bridging. The guide
does not describe how to install ISA Server 2004, nor does it describe how to
configure the firewalls illustrated in the diagram, the terminal servers running
RemoteApp programs (hosting LOB applications), or the perimeter network or
Active Directory infrastructure. The diagram is provided to suggest one way in
which this scenario might be implemented in a production environment.
56
Steps for configuring TS Gateway for the ISA

Server scenario
To configure the TS Gateway server and ISA Server bridging scenario, complete these
tasks.
1. Create a firewall policy on the ISA "Firewall Policy" topic in the ISA Server 2004
Server to allow the RDP protocol Enterprise and Standard Edition Help
access from anywhere to anywhere (http://go.microsoft.com/fwlink/?LinkID=89125)
(optional).
Note
This firewall policy is needed only if you
plan to administer the ISA Server
remotely.
2. Export the SSL certificate for the TS Export the certificate for the TS Gateway server
Gateway server and copy it to the ISA and copy it to the ISA Server
Server.
3. Install the SSL certificate for the TS Install the SSL certificate for the TS Gateway
Gateway server on the ISA Server. server on the ISA Server
4. Copy and install the TS Gateway Copy and install the TS Gateway server root
server root certificate on the ISA certificate on the ISA Server
Server.
Note
This step is required only if you are
using a self-signed certificate or
another SSL certificate type that is not
trusted.
5. Create a new Web publishing rule on Create a new Web publishing rule on the ISA
the ISA Server. Server
6. Enable or disable HTTPS-HTTP Enable or disable the HTTPS-HTTP bridging

bridging on the TS Gateway server. setting on the TS Gateway server
7. Create access policies on the ISA Create access policies on the ISA Server
Server.
57
8. Verify client configuration and test Verify client configuration and test end-to-end
end-to-end connectivity. connectivity
1. Create a firewall policy on the ISA Server to allow RDP

(optional)
As mentioned, this firewall policy is only needed on the ISA Server if you plan to
administer the ISA Server remotely. For information about ISA Server firewall policies,
see the "Firewall Policy" topic in the ISA Server 2004 Enterprise and Standard Edition
Help (http://go.microsoft.com/fwlink/?LinkID=89125).
2. Export the SSL certificate for the TS Gateway server and

copy it to the ISA Server
To export the SSL certificate for the TS Gateway server and copy it to the ISA
Server
1. On the TS Gateway server, open Internet Information Services (IIS) Manager. To
open IIS Manager, click Start, point to Administrative Tools, and then click
Internet Information Services (IIS) Manager.
2. In the console tree, browse to <Local TS Gateway Server>.
3. In the details pane, under IIS, double-click Server Certificates.
4. Right-click the SSL certificate for the TS Gateway server (the SSL certificate that
is mapped to the TS Gateway server), and then click Export.
If the Export command does not appear on the shortcut menu, this means that
the certificate that you selected was not marked as exportable when it was
originally created. If this is the case, you can create a new self-signed certificate
by using TS Gateway Manager, as described in Create a self-signed certificate
for TS Gateway.
5. In the Export Certificate dialog box, under Export to, click the browse button to
browse to the location where you want to export the certificate file (for example,
your Desktop).
6. In the Specify file to save as dialog box, in the File name box, specify a name
for the certificate file that you want to export (for example, TSGSERVER), and
58
then click Open.

7. In the Password box, type a password to help secure the file.
8. In the Confirm password box, confirm the password.
9. Click OK.
10. Close IIS Manager.
11. Navigate to the location where you exported the SSL certificate for the TS
Gateway server, and then copy the certificate to the ISA Server. If the ISA Server
is configured to block file transactions, before you do this, ensure that you have
configured the appropriate firewall exception on the ISA Server.
3. Install the SSL certificate for the TS Gateway server on

the ISA Server
To install the SSL certificate for the TS Gateway server on the ISA Server
1. On the ISA Server, open the Certificates snap-in console. If you have not already
added the Certificates snap-in console, you can do so by doing the following:

click Next.
(Local Computer), and then click Personal.
3. Right-click the Personal folder, point to All Tasks, and then click Import.
5. On the File to Import page, in the File name box, click Browse, and then
browse to the location where you copied the SSL certificate for the TS Gateway
server. Select the certificate (Certificate_Name.pfx), click Open, and then click
59
Next.
6. On the Password page, if earlier you specified a password for the private key
associated with the certificate, type the password.
7. On the Certificate Store page, accept the default option, and then click Next.
8. On the Completing the Certificate Import Wizard page, confirm that the correct
certificate has been selected.
9. On the Completing the Certificate Import Wizard page, confirm that the
following certificate settings appear:
• Certificate Store Selected by User: Trusted Root Certification Authorities
• Content: PFX
• File Name: FilePath\<Certificate_Name.pfx>, where <Certificate_Name> is
the name of the TS Gateway server SSL certificate.
10. Click Finish.

correct certificate appears in the list of certificates on the ISA Server. The
certificate must be under the Personal store of the local computer.
4. Copy and install the TS Gateway server root certificate

on the ISA Server
As mentioned, this step is required only if you are using a self-signed certificate or
another SSL certificate type that is not trusted. This step is not required, for example, if
you are using a certificate that is issued from a trusted public CA.
To copy and install the TS Gateway server root certificate on the ISA Server
1. On the ISA Server, open the Certificates snap-in console. If you have not already
added the Certificates snap-in console, you can do so by doing the following:

60
click Next.

(Local Computer), expand Trusted Root Certification Authorities, right-click
Certificates, point to All Tasks, and then click Import.
4. On the File to Import page, in the File name box, click Browse, and then
browse to the location of the TS Gateway server root certificate. Select the root
certificate (<Root_Certificate_Name.cer, or, if the private key was also exported,
<Root_Certificate_Name.pfx>), click Open, and then click Next.
Note
If you created a self-signed certificate by using the Add Remove Roles
Wizard during installation of the TS Gateway role service, or by using TS
Gateway Manager after installation, as described in Create a self-signed
certificate for TS Gateway, note that the self-signed certificate is also the
root certificate.
6. On the Certificate Store page, accept the default option (Place all certificates
in the following store - Trusted Root Certification Authorities), and then click
Next.

• Content: Certificate (or PFX)
• File Name: FilePath\<Root_Certificate_Name.cer> (or
<Root_Certificate_Name.pfx>), where <Root_Certificate_Name> is the name
of the TS Gateway server root certificate.
8. Click Finish.

61
root certificate of the TS Gateway server appears in the list of certificates on the
ISA Server. Ensure that the certificate appears under the Trusted Root
Certification Authorities store on the local computer.
5. Create a new Web publishing rule on the ISA Server

To configure the TS Gateway server and ISA Server for HTTPS-HTTP bridging or for
HTTPS-HTTPS bridging, you must create the appropriate Web publishing rule on the ISA
Server.
To create a new Web publishing rule on the ISA Server

1. On the ISA Server, open ISA Server Management. To open ISA Server
Management, click Start, point to All Programs, point to Microsoft ISA Server,
and then click ISA Server Management.
2. In the console tree, browse to <Local ISA Server>.

3. Right-click Firewall Policy, point to New, and then click Secure Web Server
Publishing Rule.
4. On the Welcome To The SSL Publishing Rule Wizard page, in the SSL Web
Publishing Rule Name box, type a name for the new server publishing rule, and
then click Next.
5. On the Publishing Mode page, click SSL Bridging, and then click Next.
6. On the Select Rule Action page, click Allow, and then click Next.
7. On the Bridging Mode page, do one of the following:
• To enable HTTPS-HTTP bridging, click Secure connections to clients, and
then click Next.
• To enable HTTPS-HTTPS bridging, click Secure connection to clients and
Web server, and then click Next.
8. On the Define Website to Publish page, do the following:
• In the Computer name or IP address box, type the name of the TS
Gateway server. The specified name must match the name of the TS
Gateway server through which users will connect in this scenario.
• Select the Forward the original host header instead of the actual one
(specified above) check box.
62
• In the Path box, type /*

9. On the Public Name Details page, do the following:
• In Accept requests for, ensure that This domain name is selected.
• In the Public name box, type the name of the TS Gateway server. The
specified name must match the name of the TS Gateway server through
which users will connect in this scenario.
• In the Path box, accept the default (/*).

• Click Next.
10. Create a new SSL Web listener by doing the following:
• On the Welcome to the New Web Listener page, in Web Listener Name,
type a name for the Web listener, and then click Next. If Web listeners have
already been configured for the ISA Server, on the Select Web Listener
page, click New to open the Welcome to the New Web Listener page and
begin specifying a new Web listener.
• On the IP Addresses page, under Listen for requests from these
networks, select the External check box, and then click Next.
• On the Port Specification page, do the following:
Under SSL, select the Enable SSL check box, and then clear the Enable
HTTP box.
Click Select, and in the Select Certificate dialog box, click the certificate
that you want to use.
Click OK to close the Select Certificate dialog box, and then click Next.
• On the Completing the New Web Listener Wizard page, click Finish.
• On the Select Web Listener page, confirm that the correct Web listener
properties appear, and then click Next.
11. On the User Sets page, click All Users, and then click Next.
12. On the Completing the New SSL Web Publishing Rule Wizard page, click
Finish.
13. To save the changes and update the ISA Server firewall policy, in the details
pane of the ISA Server Management console, click Apply.
14. In the Apply New Configuration dialog box, click OK after the changes are
applied (a progress bar appears while the changes are being applied).
63
6. Enable or Disable HTTPS-HTTP bridging on the TS

Gateway server
You must configure the TS Gateway server appropriately to enable or disable HTTPS-
HTTP bridging. By design, selecting the Use HTTPS-HTTP bridging check box on the
SSL Bridging tab of the TS Gateway server enables HTTPS-HTTP bridging, and
clearing this setting disables HTTPS-HTTPS bridging (if this setting is not cleared and
you attempt to use HTTPS-HTTPS bridging, the TS Gateway server will not function). By
design, selecting or clearing this check box should create or update the
AllowAnonymous registry key value.
Important
As mentioned earlier in this guide, in the Beta 3 release of TS Gateway, selecting
or clearing the Use HTTPS-HTTP bridging check box does not create or update
the AllowAnonymous registry key value. Therefore, you must create or update
this registry key value manually. For more information and step by step
instructions, see Special considerations for TS Gateway earlier in this guide.
Important
If you enable HTTPS-HTTP bridging, the TS Gateway server will depend on ISA
Server 2004 to perform user authentication. If you no longer want to use ISA
Server for SSL bridging in this scenario, we strongly recommend that you roll
back the configuration changes described in this procedure by disabling HTTPS-
HTTP bridging on the TS Gateway server. If you do not roll back the
configuration changes in this scenario, TS Gateway will allow access to
everyone.
7. Create access rules on the ISA Server

• On the ISA Server, create additional access rules to allow inbound and outbound
traffic as needed in your environment.
For information about how to configure ISA Server access rules, see the "Configure
Access Rules" topic in the ISA Server 2004 Enterprise and Standard Edition Help
8. Verify client configuration and test end-to-end

connectivity
Terminal Services clients that connect through the ISA Server to the TS Gateway server
are located in the external network range of the ISA Server. In a typical deployment, the
64
TS Gateway server address and the IP address of the ISA Server will be published in
DNS. As a result, clients will resolve the TS Gateway server address to the ISA Server.
The secure Web publishing rule that you create for the ISA Server ensures that all
incoming requests to the TS Gateway server from the external network will be forwarded
to the TS Gateway server, which is located in the internal network.
If you cannot publish entries to DNS, for testing purposes, you can add an entry to the
hosts file of the client that maps the TS Gateway server address to the IP address of the
ISA Server. The hosts file on the client is located at:
%windir%\system32\drivers\etc\hosts.
Next, ensure that the client is correctly configured as a TS Gateway client as described in
"Steps for configuring a Terminal Services client for the TS Gateway core scenario." To
ensure that connectivity is successful in this scenario, follow the steps in "Verify that end-
to-end connectivity through TS Gateway is functioning correctly" in the Terminal Services
Client Step-by-Step Setup Guide for TS Gateway.
Appendix A: Example script for verifying that

the TS Gateway server configuration is
correct
After you have completed certificate configuration for the TS Gateway server and TS
Gateway clients, you can use the Rpcping.exe resource kit tool to confirm that the
certificate configuration is correct. The following script provides an example of how you
can use Rpcping.exe for this purpose. Rpcping.exe is available for download from
Windows Server 2003 Resource Kit Tools (http://go.microsoft.com/fwlink/?LinkId=16544).
This appendix describes how to save the example script as a text file and run the script
by using Rpcping.exe, and provides an example of successful output and the example
script syntax.
Running the Rpcpingtest example script

To run this example script, use the following procedure. Note that you must run the script
as a member of the local Administrators group on the TS Gateway server.
To run the example script

1. Copy and paste the example script into a text file.
2. Save the text file as Rpcpingtest.cmd.

65
3. Open the command prompt, switch to the directory where Rpcping.exe is

located, and then type Rpcpingtest.cmd.
4. For example, if you saved Rpcping.exe to the C:\Tools directory, you would do
the following:
At the command prompt, type the following (replace
TSGATEWAYSERVERNAME with the name of your TS Gateway server):
C:\Tools\Rpcpingtest TSGATEWAYSERVERNAME <user name> <domain

name>
5. Press ENTER.
6. Type the password for RPC/http proxy (the password for the TS Gateway
server).
Example of successful output

If the script is successful and the certificate configuration is correct, output similar to the
following will appear:
Results: RPC/HTTP server preferred auth scheme is: 2
Results: Pinging successfully completed in 78 sec.
------------------------------------------------------------
Prompting for second rpc ping command in the scripting file
Enter the password for server: <password for TS Gateway>
Enter the password for RCP/http Proxy: <password for TS Gateway>
Results: Completed 1 calls in 141 ms

Results: 7 T/S or 141.000 ms/T.
Rpcping example script

@echo off
setlocal
set _TARGETGATEWAY=%1
set _USERNAME=%2
set _DOMAINNAME=%3
if "%_TARGETGATEWAY%" == "" goto DO_USAGE

if "%_USERNAME%" == "" goto DO_USAGE
if "%_DOMAINNAME%" == "" goto DO_USAGE
Echo *******************************************************************
Echo * The first RPCPing will authenticate to the RPC over HTTP
Echo * Proxy service. If this ping fails, then the certificate
66
Echo * on the client computer is not correctly configured,

Echo * or you might have entered the wrong password.
Echo *******************************************************************
Rpcping -v 2 -e 3388 -t ncacn_http -s localhost -o RpcProxy=%_TARGETGATEWAY% -P

"%_USERNAME%,%_DOMAINNAME%,*" -H NTLM -u NTLM -a connect -F ssl -B
msstd:%_TARGETGATEWAY% -E
-R None
Echo *******************************************************************
Echo * The second RPCPing will attempt to authenticate to the TS
Echo * Gateway service. If this ping fails, then the TS Gateway
Echo * service is probably not running.
Echo *******************************************************************
Rpcping -v 2 -e 3388 -t ncacn_http -s localhost -o RpcProxy=%_TARGETGATEWAY% -P

"%_USERNAME%,%_DOMAINNAME%,*" -I "%_USERNAME%,%_DOMAINNAME%,*" -H NTLM -u NTLM -a
connect -F
ssl -B msstd:%_TARGETGATEWAY%
goto endall
:DO_USAGE
Echo ******************************************************************
Usage: *
Echo * testclient.cmd [gateway] [user] [domain/machine] *
Echo * *
Echo ******************************************************************
goto endall
:ENDALL
Endlocal
Disclaimer
The sample script is not supported under any Microsoft standard support program or
service. The sample script is provided AS IS without warranty of any kind. Microsoft
further disclaims all implied warranties including, without limitation, any implied warranties
of merchantability or of fitness for a particular purpose. The entire risk arising out of the
use or performance of the sample script and documentation remains with you. In no
event shall Microsoft, its authors, or anyone else involved in the creation, production, or
delivery of the script be liable for any damages whatsoever (including, without limitation,
damages for loss of business profits, business interruption, loss of business information,
or other pecuniary loss) arising out of the use of or inability to use the sample scripts or
documentation, even if Microsoft has been advised of the possibility of such damages.
67
The following references provide additional information about TS Gateway:
• For product support, see the Terminal Services page on the Windows Server
"Longhorn" TechCenter (http://go.mi).
• To access newsgroups for Terminal Services, see the Terminal Services Community
page on the Microsoft TechNet Web site (http://go.mi).
• If you are a beta tester and part of the special Technology Adoption Program (TAP)
beta program, you can also contact your appointed Microsoft development team
member for assistance.
Terminal Services Client Step-by-Step

Setup Guide for TS Gateway
Windows Server® Code Name "Longhorn" Terminal Services Gateway (TS Gateway) is
a role service that enables authorized remote users to connect to resources on an
internal corporate or private network, from any Internet-connected device. TS Gateway
uses Remote Desktop Protocol (RDP) over HTTPS to help form a secure, encrypted
connection between remote users on the Internet and the internal network resources on
which their productivity applications run.
The procedures in this guide will help you:
• Set up a Terminal Services client to access internal network resources (terminal

servers running RemoteApp™ programs [hosting line-of-business (LOB) applications]
or computers with Remote Desktop enabled) over the Internet, through a TS
Gateway server.
• Set up a Terminal Services client as a Network Access Protection (NAP)
enforcement client. NAP client components are responsible for compiling health
status statements on client computers, maintaining a client computer's health state,
and communicating a client computer's health state to the NAP server components.
Important
Before you follow the steps in this guide to set up a Terminal Services client,
verify that you have correctly configured the TS Gateway server, as
described in the Windows Server “Longhorn” Beta 3 Release TS Gateway
Server Step-by-Step Setup Guide.
68
Known issues
The following are known issues for Terminal Services clients connecting through a TS
Gateway server in the Windows Server "Longhorn" Beta 3 release.
Automatic reconnection to TS Gateway server might fail

after Terminal Services client comes out of hibernation
After you establish a remote connection through a TS Gateway server to another
computer, if the Terminal Services client that initiated the connection hibernates and then
comes out of hibernation, the client might not automatically reconnect to the remote
computer through the TS Gateway server. To resolve this problem, open Task Manager,
end the mstsc (Remote Desktop Connection) process, and then attempt the remote
connection again. Closing mstsc will not resolve this problem.
TS Gateway server connection requests from a client

running Windows XP with SP2 might fail if a smart card is
used for authentication
If you are using a client running Microsoft® Windows® XP with SP2 to connect to a
remote computer through a TS Gateway server, you will receive an error message stating
that the remote computer is misconfigured if you do the following:
1. Connect to a remote computer and leave your smart card in the smart card reader
during the session.
2. End the session, leaving the smart card in the smart card reader.
3. Start another connection while leaving the smart card in the smart card reader.
To resolve this problem, remove the smart card, reinsert it, and then try to connect to the
remote computer again.
Prerequisites for setting up the Terminal

Services client for the TS Gateway core
scenario
For a diagram of this scenario and for system requirements, see Diagram 1 and "System
requirements for the TS Gateway core scenario" in the Windows Server “Longhorn” Beta
3 Release TS Gateway Server Step-by-Step Setup Guide.
69
Steps for configuring a Terminal Services

client for the TS Gateway core scenario
To configure the Terminal Services client for the TS Gateway core scenario, complete
these tasks.
1. Verify that system requirements are met "System requirements for the TS Gateway
for the Terminal Services client. core scenario" in the Windows Server
“Longhorn” Beta 3 Release TS Gateway
Server Step-by-Step Setup Guide
2. Install the TS Gateway server root Install the TS Gateway server root
certificate on the Terminal Services client certificate on the Terminal Services client
(optional).
Note
This procedure is not required if a
certificate that is issued by one of
the trusted public CAs that
participate in the Microsoft Root
Certificate Program Members
program is installed on the TS
Gateway server, and the Terminal
Services client computer trusts the
certificate.
3. Configure Remote Desktop Connection Configure Remote Desktop Connection

settings. settings
4. Verify that end-to-end connectivity Verify that end-to-end connectivity through

through the TS Gateway server is the TS Gateway server is functioning
functioning correctly. correctly
As mentioned, you can also configure the Terminal Services client as a NAP enforcement
client. For more information, see Steps for configuring a Terminal Services client as a
NAP enforcement client later in this guide.
70
Install the TS Gateway server root certificate on the

Terminal Services client (optional)
The client computer must verify and trust the identity of the TS Gateway server before
you can send your password and logon credentials securely and complete the
authentication process. To establish this trust, the clients must trust the root of the
server’s certificate. That is, clients must have the certificate of the certification authority
(CA) that issued the server certificate in their Trusted Root Certification Authorities store.
You can view this store by using the Certificates snap-in.
As mentioned, this procedure is not required if:
• A certificate that is issued by one of the trusted public CAs that participate in the
Microsoft Root Certificate Program Members program [as listed in article 931125 in
the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=59547)] is
installed on the TS Gateway server; and
• The Terminal Services client computer trusts the certificate.
For more information, see "Obtain a certificate for the TS Gateway server" in the
Windows Server “Longhorn” Beta 3 Release TS Gateway Server Step-by-Step Setup
Guide.
If the TS Gateway server is using a non-Microsoft, trusted PKI certificate that is
recognized and trusted by your client computer, proceed to the Configure remote desktop
connection settings section.
Important
Do not install certificates from any untrusted sources or individuals.
To install the TS Gateway server root certificate, do the following on the Terminal
Services client.
To install the TS Gateway server root certificate on the Terminal Services client
1. Open the Certificates snap-in console. If you have not already added the
Certificates snap-in console, you can do so by doing the following:

click Next.
71

(Local Computer), expand Trusted Root Certification Authorities, right-click
Certificates, point to All Tasks, and then click Import.

4. On the File to Import page, in the File name box, browse to the TS Gateway
server root certificate, click Open, and then click Next.
6. On the Certificate Store page, accept the default option (Place all certificates
in the following store - Trusted Root Certification Authorities), and then click
Next.
• Content: Certificate
• File Name: FilePath\<Root_Certificate_Name.cer>, where
<Root_Certificate_Name> is the name of the TS Gateway server root
certificate.
8. Click Finish.
root certificate of the TS Gateway server appears in the list of certificates on the
client. Ensure that the certificate appears under the Personal store.
Configure Remote Desktop Connection settings
To configure Remote Desktop Connection settings

1. Open the Remote Desktop Connection client. To open the Remote Desktop
Connection client, click Start, point to All Programs, point to Accessories, and
72
then click Remote Desktop Connection.

2. In the Remote Desktop Connection dialog box, click Options to expand the
dialog box and view settings.
3. On the Advanced tab, in the Connect from anywhere area, click Settings.
4. In the Gateway Server Settings dialog box, select the appropriate options:
• Automatically detect TS Gateway server settings (default). If you select
this option, the Terminal Services client attempts to use Group Policy
settings that determine the behavior of client connections to TS Gateway
servers, if these settings have been configured and enabled. Group Policy
settings for Terminal Services client connections can be applied in one of two
ways. These settings can either be suggested (that is, they can be enabled,
but not enforced) or they can be enabled and enforced. When Group Policy
settings are suggested, if you click Use these TS Gateway server settings,
you can modify settings and specify the name of the TS Gateway server or
TS Gateway server farm that you want to connect to and the logon method to
use for the connection. When Group Policy settings are enabled and
enforced, when you click Use these TS Gateway server settings, you
cannot modify the settings.
• Use these TS Gateway server settings. If a TS Gateway server name or

TS Gateway server farm name and logon method are not already enabled
and enforced by Group Policy, you can select this option and specify the
name of the TS Gateway server or TS Gateway server farm that you want to
connect to and the logon method to use for the connection. Note that when
you specify a name for the TS Gateway server or TS Gateway server farm,
you must use a fully qualified domain name (FQDN).
• Bypass TS Gateway server for local addresses. This option is selected by
default.
If you want the Terminal Services client to automatically detect when TS
Gateway is required, select this check box. If you use a mobile computer,
selecting this option will optimize client connectivity performance and
minimize latency because TS Gateway will only be used when it is required.
If your computer is always connected to the local area network (LAN) or if it
is hosted inside the corporate firewall, TS Gateway will not be used. If you
are outside the corporate network and connecting to the corporate network
over the Internet, TS Gateway will be used.
If you are in a LAN, but want to test connectivity through a TS Gateway
server or TS Gateway server farm, clear this check box. Otherwise, the client
73
will not connect through the TS Gateway server or TS Gateway server farm
in this case.
• Do not use a TS Gateway server. Select this option if your computer is
always connected to the LAN or if it is hosted inside the corporate firewall.
This option is appropriate if you know that you do not need to use TS
Gateway to traverse a firewall.
5. Do one of the following:

• To save the settings and close the Remote Desktop Connection dialog
box, click Save, and then click Cancel. The settings will be saved as an RDP
file to a default location (by default, the file is saved to
Drive:\<Username>\Documents).
• To save the RDP file to a specified location (you can customize and
distribute the file later to multiple clients as needed), click Save As. In the
Save as dialog box, in the File name box, specify the file name and location,
and then click Save
• To proceed with a connection to an internal network resource, click Save,

click Connect, and then proceed to step 5 in the next procedure ("Verify that
end-to-end connectivity through TS Gateway is functioning correctly").
Verify that end-to-end connectivity through TS Gateway is

functioning correctly
To verify that end-to-end connectivity through TS Gateway is functioning

correctly
3. On the General tab, type the name of the computer (terminal server or computer
running Remote Desktop) to which you want to connect remotely through TS
Gateway.
4. Click Connect.
5. On the Enter your credentials page, select the user account that you want to
use to log on remotely to the computer, and then enter the required credentials.
74
6. Click Submit.
7. Review the security warning, and then click Yes.
8. On the Gateway server credentials page, select the user name that you want to
use to log on to the TS Gateway server, and then enter the required credentials.
9. Click Submit.
10. After a few moments, the connection completes and a connection will be
established through the TS Gateway server to the computer.
Prerequisites for setting up the Terminal

Services client for the TS Gateway NAP
scenario
For a diagram of this scenario and for system requirements, see Diagram 2 and "System
requirements for the TS Gateway NAP scenario" in the Windows Server “Longhorn” Beta
3 Release TS Gateway Server Step-by-Step Setup Guide.
Steps for configuring a Terminal Services

client as a NAP enforcement client
To configure a Terminal Services client computer as a Network Access Protection (NAP)
enforcement client, you must complete these tasks.
Verify that system requirements are met for "System requirements for the TS Gateway
the Terminal Services client. NAP scenario" in the Windows Server
“Longhorn” Beta 3 Release TS Gateway
Server Step-by-Step Setup Guide
Download and run the Terminal Services Download and run the Terminal Services
NAP client configuration command. NAP client configuration command
Test to confirm that the NAP health policy Test to confirm that the NAP health policy is
is successfully applied to the Terminal successfully applied to the Terminal
Services client. Services client
75
Download and run the Terminal Services NAP client

configuration command
The Terminal Services NAP client configuration command (Tsgqecclientconfig.cmd)
performs the following tasks to configure the Terminal Services client as a NAP
enforcement client:
• Adds the TS Gateway server name to the Trusted Server list on the client.
• Starts the Network Access Protection Agent service and sets the service startup type
to Automatic.
The NAP agent collects and manages health information. The NAP agent processes
statements of health (SoH) from the various system health agents (SHAs) and
reports client health to the NAP administration server. For NAP to function correctly,
you must start the Network Access Protection Agent service on the client, and then
set the service startup type to Automatic. By default, this service does not start
automatically.
• Enables the TS Gateway Quarantine Enforcement client.
To run this example script, use the following procedure. Note that you must run the
script as a member of the local Administrators group on the TS Gateway server.
To download and run the Terminal Services NAP client configuration command
1. To download the Terminal Services NAP client configuration command, go to the
TS Gateway page on the Windows Server "Longhorn" TechCenter
(http://go.microsoft.com/fwlink/?LinkId=79605). When you open the command
prompt, right-click the command prompt, and then click Run as Administrator.
You must run this command with elevated privileges for the command to
succeed. For information about how to run this command with elevated privileges
in Windows XP, see article 294676 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=87531). For information about how to do
this in Windows Server 2003, see Run a program with administrative credentials
tsgqecclientconfig TS_GATEWAY_SERVER_NAME
where TS_GATEWAY_SERVER_NAME is the fully qualified domain name

(FQDN) of the TS Gateway server that you want to add to the list of trusted TS
Gateway servers on the client.
The name that you specify for the server must match the name in the Issued to
76
field of the TS Gateway server certificate. If you create a self-signed certificate by

using the Add Roles Wizard during installation of the TS Gateway role service or
by using TS Gateway Manager after installation, specify the fully qualified domain
name (FQDN) of the TS Gateway server.
To specify more than one TS Gateway server, separate each server name with a
\0 (for example, SERVER_NAME1\0SERVER_NAME2\0SERVER_NAME3).
3. After the commands are successfully completed, the following appears:

The operation completed successfully.
Enabling the TS Gateway Quarantine Enforcement Client
The operation completed successfully.
Setting the Network Access Protection service startup type to Automatic…
[SC] ChangeServiceConfig SUCCESS
Starting the Network Access Protection service...

The Network Access Protection Agent service is starting.
The Network Access Protection Agent service was started successfully.
4. Restart the client computer to implement the configuration changes.
5. Open Registry Editor. To open Registry Editor, click Start, click Run, type
regedit, and then click OK.
6. Verify that the following registry key appears:

HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server
Client\TrustedGateways
where TrustedGateways lists the FQDN of the TS Gateway servers that you
specified in Step 2, in the Data field.
Test to confirm that the TS Gateway NAP health policy is

successfully applied to the Terminal Services client
Use the following procedures to verify that the health policy that you configured on the TS
Gateway server is being applied to the Terminal Services client.
Recall that the Windows Security Health Validator (WSHV) policy that you created on the
TS Gateway server (by following the steps in the Windows Server “Longhorn” Beta 3
Release TS Gateway Server Step-by-Step Setup Guide) requires that you enable
automatic updating for the connection to succeed.
77
To test whether the health policy is correctly applied to the Terminal Services client,
perform the following tasks:
• Test for successful blocked connection for NAP-capable client. If the health policy is
correctly applied to the Terminal Services NAP-capable client, the client connection
attempt will be blocked by the server when automatic updating is disabled on the
client.
• Test for successful allowed connection for NAP-capable client. If the health policy is
correctly applied to the Terminal Services NAP-capable client, the client connection
attempt will be allowed by the server when automatic updating is enabled on the
client.
• Test for successful blocked connection for non-NAP capable client. If the health
policy is correctly applied to the Terminal Services non-NAP capable client, the client
connection attempt will be blocked by the server, because the client cannot send a
statement of health (SoH).
Test for successful blocked connection for NAP-capable client

Perform the following procedure to test whether at least one NAP health policy is
correctly configured to block the NAP-capable Terminal Services client connection to the
TS Gateway server when automatic updating is disabled on the client.
To attempt an end-to-end connection through the TS Gateway server when

automatic updating is disabled on the client
1. Open Control Panel. To open Control Panel, click Start, and then click Control
Panel.
2. In Control Panel, double-click Security.
3. Under Security Center, click Turn automatic updating on or off.

4. In the Choose how Windows can install updates dialog box, click Never
check for updates (not recommended), and then click OK.
with Remote Desktop enabled) to which you want to connect remotely through
78
TS Gateway.
8. Click Connect.
10. Click Submit.
13. Click Submit.
14. After a few moments, the following error message appears:

This computer can't connect to the remote computer because your computer or
device did not pass the Network Access Policies validation set by your network
administrator. Please contact your network administrator for assistance.
15. Click OK to close the message, and then cancel the connection.
Verify that the NAP health policy blocked the connection

On the TS Gateway server, the following three events will appear in the Event Log to
confirm that client access to the TS Gateway server was denied because the health
policy was successfully applied:
• Event ID 1: This event, which appears in the global System log, indicates that the
Terminal Services connection authorization policy (TS CAP) granted full access to
the client.
client was denied access to the TS Gateway server and quarantined because the
health policy was successfully applied.
• Event ID 204: This event, which appears in the TS Gateway server log, indicates that
the client is not authorized to access the TS Gateway server.
To verify that the NAP health policy blocked the connection

1. On the TS Gateway server, open Event Viewer. To open Event Viewer, click
Start, point to Administrative Tools, and then click Event Viewer.
2. In Event Viewer, expand Windows Logs, and then click System.
3. With System selected in the console tree, search for event IDs 1 and 5.
79
4. In the console tree, expand Applications and Services

Logs\Microsoft\Windows\TerminalServices-Gateway, and then click
Operational.
5. With Operational selected in the console tree, search for Event ID 204.
Test for successful allowed connection for NAP-capable client

correctly configured to allow the Terminal Services client connection to the TS Gateway
server when automatic updating is enabled on the client.
To attempt an end-to-end connection through the TS Gateway server when

automatic updating is enabled on the client
Panel.

4. In the Choose how Windows can install updates dialog box, click Install
updates automatically (recommended), and then click OK.
7. On the General tab, type the name of the computer (terminal server or remote
desktop) to which you want to connect remotely through TS Gateway.
8. Click Connect.
10. Click Submit.
80
13. Click Submit.

14. After a few moments, the connection completes and a connection will be
established through the TS Gateway server to the computer.
Verify that the NAP health policy allowed the connection

On the TS Gateway server, the following three events will appear in the Event Log to
confirm that client access to the TS Gateway server was granted because the health
policy was successfully applied:
• Event ID 1: This event, which appears in the global System log, indicates that the TS
CAP granted full access to the client.
client was granted access to the TS Gateway server because the health policy was
successfully applied.
• Event ID 200: This event, which appears in the TS Gateway server log, indicates that
the client is healthy and therefore can access the TS Gateway server.
To verify that the NAP health policy allowed the connection

1. On the TS Gateway server, open Event Viewer. To open Event Viewer, click
Start, point to Administrative Tools, and then click Event Viewer.
2. In Event Viewer, expand Windows Logs, and then click System.
3. With System selected in the console tree, search for event IDs 1 and 7.
4. In the console tree, expand Applications and Services
Logs\Microsoft\Windows\TerminalServices-Gateway, and then click
Operational.
5. With Operational selected in the console tree, search for Event ID 200.
Test for successful blocked connection for non-NAP capable client

correctly configured to block the Terminal Services client connection to the TS Gateway
server when the client cannot send an SoH to the TS Gateway server.
81
To attempt an end-to-end connection through the TS Gateway server when the

client cannot send an SoH
Panel.

4. In the Choose how Windows can install updates dialog box, verify that Install
updates automatically (recommended) is selected, and then click OK. If this
option is not selected, click it, and then click OK.
5. At the command prompt, type the following to stop the Network Access
Protection Agent service. When you open the command prompt, right-click the
command prompt, click Run as Administrator, and then at the command
prompt, type the following:
net stop napagent
with Remote Desktop enabled) to which you want to connect remotely through
TS Gateway.
9. Click Connect.
11. Click Submit.
14. Click Submit.

15. After a few moments, the following error message appears:
This computer can't connect to the remote computer because your computer or
device did not pass the Network Access Policies validation set by your network
82
administrator. Please contact your network administrator for assistance.

16. Click OK to close the message, and then cancel the connection.
On the TS Gateway server, follow the steps in Verify that the NAP health policy blocked
the connection to confirm that client access to the TS Gateway server was denied
because the health policy was successfully applied.
Network Access Protection (http://go.microsoft.com/fwlink/?LinkID=70047)
Working Remotely with Windows XP (http://go.microsoft.com/fwlink/?LinkId=49761)

Windows Server 2003 Terminal Services Product Evaluation
Terminal Services page on the Windows Server 2003 TechCenter
Terminal Services page on the Windows Server "Longhorn" TechCenter
Windows Server "Longhorn" Beta 3
Release TS Licensing Step-By-Step
Setup Guide

Author: Daniel H. Brown
Contributors: Nitin Cholkar, Aruna Somendra
Abstract
Windows Server® Code Name "Longhorn" provides a license management system for
Terminal Services known as Terminal Services Licensing (TS Licensing). This system
allows terminal servers to obtain and manage Terminal Services client access licenses
(TS CALs) for devices and users that are connecting to a terminal server. TS Licensing
supports terminal servers that run Windows Server "Longhorn" as well as terminal
servers running Microsoft Windows Server® 2003 or Microsoft Windows® 2000 Server.

Active Directory, Terminal Services, Microsoft, MS-DOS, Visual Basic, Visual Studio,
Windows, Windows NT, and Windows Server are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.

Contents
Windows Server "Longhorn" Beta 3 Release TS Licensing Step-by-Step Setup Guide .... 5
Overview of TS Licensing ................................................................................................... 5
Installation Prerequisites for TS Licensing .......................................................................... 7
Terminal Services Client Access Licenses (TS CALs) ....................................................... 8
Terminal Services License Server Discovery ..................................................................... 9
Configuration Checklist for TS Licensing .......................................................................... 10
Installing TS Licensing ...................................................................................................... 10
Connecting to a Terminal Services License Server .......................................................... 12
Installing TS Licensing Manager ....................................................................................... 13
Activating a Terminal Services License Server ................................................................ 14

Activating a Terminal Services License Server Automatically .......................................... 15
Activating a Terminal Services License Server by Using a Web Browser ........................ 16
Activating a Terminal Services License Server by Using the Telephone ......................... 17
Installing Terminal Services Client Access Licenses ........................................................ 18

Obtaining Beta Terminal Services Client Access Licenses .............................................. 19
Installing Terminal Services Client Access Licenses Automatically ................................. 20
Installing Terminal Services Client Access Licenses by Using a Web Browser ............... 21
Installing Terminal Services Client Access Licenses by Using the Telephone................. 23
Configuring License Settings on a Terminal Server ......................................................... 24

Specifying the Terminal Services licensing mode ......................................................... 25
Specifying the license server discovery mode .............................................................. 25
Tracking the Issuance of Terminal Services Client Access Licenses ............................... 26
Troubleshooting TS Licensing Installation ........................................................................ 26

Reviewing the configuration of your license server ....................................................... 27
Diagnosing licensing problems on your terminal server ................................................ 27
Known Issues for TS Licensing Installation ...................................................................... 28

5
Windows Server "Longhorn" Beta 3

Release TS Licensing Step-by-Step Setup
Guide
Windows Server® Code Name "Longhorn" provides a license management system for
Terminal Services known as Terminal Services Licensing (TS Licensing). This system
allows terminal servers to obtain and manage Terminal Services client access licenses
(TS CALs) for devices and users that are connecting to a terminal server. TS Licensing
supports terminal servers that run Windows Server "Longhorn" as well as terminal
servers running Microsoft Windows Server® 2003 or Microsoft Windows® 2000 Server.
For more information about TS Licensing, see the TS Licensing page on the
Windows Server "Longhorn" TechCenter (http://go.microsoft.com/fwlink/?LinkId=79607).
The following topics are covered in this Step-by-Step Guide:

• Overview of TS Licensing
• Installation Prerequisites for TS Licensing
• Configuration Checklist for TS Licensing

• Installing TS Licensing
• Connecting to a Terminal Services License Server
• Activating a Terminal Services License Server

• Installing Terminal Services Client Access Licenses
• Configuring License Settings on a Terminal Server
• Tracking the Issuance of Terminal Services Client Access Licenses

• Troubleshooting TS Licensing Installation
• Known Issues for TS Licensing Installation
Overview of TS Licensing
Terminal Services Licensing (TS Licensing) manages the Terminal Services client access
licenses (TS CALs) that are required for each device or user to connect to a terminal
6
server. You use TS Licensing to install, issue, and monitor the availability of TS CALs
on a Terminal Services license server.
For more information about TS CALs, see Terminal Services Client Access Licenses (TS
CALs).
When a client—either a user or a device—connects to a terminal server, the terminal
server determines if a TS CAL is needed. The terminal server then requests a TS CAL
from the Terminal Services license server, and then the TS CAL is issued to the client by
the license server. Although there is a licensing grace period during which no license
server is required, after the grace period ends, clients must receive a valid TS CAL
issued by a license server before they can log on to a terminal server.
Important
Remote Desktop supports two concurrent connections to remotely administer a
computer. You do not need a license server for these connections.
To use Terminal Services, you must also have at least one license server. For small
deployments, it is acceptable to install both the Terminal Server role service and the
TS Licensing role service on the same computer. For larger deployments, it is
recommended that the TS Licensing role service be installed on a separate computer
from the Terminal Server role service.
You must configure TS Licensing correctly in order for your terminal server to continue to
accept connections from clients. To allow ample time for you to deploy a license server,
Terminal Services provides a licensing grace period during which no license server is
required. During this grace period, a terminal server can accept connections from
unlicensed clients without contacting a license server. The grace period begins the first
time the terminal server accepts a client connection. The grace period ends after you
deploy a license server and that license server issues its first permanent TS CAL, or after
120 days, whichever comes first.
After the TS Licensing grace period ends, you must purchase and install the appropriate
number of TS CALs for each device or user that needs to connect to a terminal server. In
addition, you must verify that the TS Licensing mode that you specify on the terminal
server matches the type of TS CAL available on the license server. TS Licensing modes
determine the type of TS CAL that a license server issues to a client.
7
Installation Prerequisites for TS

Licensing
TS Licensing manages the Terminal Services client access licenses (TS CALs) that are
required for each device or user to connect to a terminal server. You use TS Licensing to
install, issue, and monitor the availability of TS CALs on a Terminal Services license
server.
This checklist provides tasks that an administrator should perform before installing and
configuring TS Licensing.
Task Reference
Determine if a Terminal Services license Remote Desktop supports two concurrent

server is needed. connections to remotely administer a
computer. You do not need a license server
for these connections.
Verify that the license server supports the TS Licensing in Windows Server
operating system of the terminal servers. "Longhorn" supports terminal servers that
run:
• Windows Server "Longhorn"
• Windows Server 2003 R2

• Windows 2000
A terminal server running Windows Server

"Longhorn" can only communicate with a
license server running Windows Server
"Longhorn".
Determine which type of TS CALs to use. Terminal Services Client Access Licenses
(TS CALs)
8
Task Reference
Purchase the appropriate type and number For the Windows Server "Longhorn" Beta 3
of TS CALs. release, you do not have to purchase TS
CALs from Microsoft. Instead, you can use
a test license code from Microsoft so that
you can install Windows Server "Longhorn"
beta TS CALs on a Windows Server
"Longhorn" Beta 3 license server. For more
information, see Obtaining Beta Terminal
Services Client Access Licenses.
Determine the method of the Terminal Terminal Services License Server

Services license server discovery. Discovery
Terminal Services Client Access

Licenses (TS CALs)
There are two types of Terminal Services client access licenses (TS CALs):
• TS Per Device CALs
• TS Per User CALs
When Per Device licensing mode is used, and a client computer or device connects to a
terminal server for the first time, the client computer or device is issued a temporary
license by default. When a client computer or device connects to a terminal server for the
second time, if the license server is activated and enough TS Per Device CALs are
available, the license server issues the client computer or device a permanent, TS Per
Device CAL.
A TS Per User CAL gives one user account the right to access a terminal server from an
unlimited number of client computers or devices. TS Per User CALs are not enforced by
TS Licensing. As a result, client connections can occur regardless of the number of
TS Per User CALs installed on the license server. This does not absolve administrators
from the Microsoft Software License Terms requirements to have a valid TS Per User
CAL for each user. Failure to have a TS Per User CAL for each user, if Per User
licensing mode is being used, is a violation of the license terms.
9
To ensure that you are in compliance with the license terms, make sure that you track
the number of TS Per User CALs being used in your organization and that you have a
sufficient number of TS Per User CALs installed on the license server to provide a TS Per
User CAL for each user that needs to connect to the terminal server.
In Windows Server "Longhorn", you can use the TS Licensing Manager tool to track and
generate reports on the issuance of TS Per User CALs. For more information, see
Tracking the Issuance of Terminal Services Client Access Licenses.
Terminal Services License Server

Discovery
When you install the TS Licensing role service, you need to specify a scope, which
determines how the Terminal Services license server will be automatically discoverable
by terminal servers.
The three scopes are:
• Workgroup
• Domain
• Forest
Workgroup scope is only available when the computer that you are installing the
TS Licensing role service on is not a member of a domain. If you configure workgroup
scope, terminal servers, without any additional configuration, can automatically discover
a license server in the same workgroup.
Domain scope and forest scope are only available when the computer that you are
installing the TS Licensing role service on is a member of a domain.
If you configure domain scope, terminal servers, without any additional configuration, can
automatically discover a license server in the same domain if the license server is
installed on a domain controller. To configure domain scope, you must be logged on as a
domain administrator to the domain in which the license server is a member.
If you configure forest scope, terminal servers, without any additional configuration, can
automatically discover a license server in the same forest. To configure forest scope, you
must be logged on as an enterprise administrator to the forest in which the license server
is a member.
10
Note
In Windows Server 2003, "forest scope" was known as "enterprise scope."
Configuration Checklist for TS Licensing

TS Licensing manages the Terminal Services client access licenses (TS CALs) that are
required for each device or user to connect to a terminal server. You use TS Licensing to
install, issue, and monitor the availability of TS CALs on a Terminal Services license
server.
This checklist provides the tasks that an administrator needs to complete to install and
configure TS Licensing.
Task Reference
Review prerequisites for installing Installation Prerequisites for TS Licensing

TS Licensing.
Install the TS Licensing role service. Installing TS Licensing
Activate the Terminal Services license Activating a Terminal Services License

server. Server
Install Terminal Services client access Installing Terminal Services Client Access
licenses (TS CALs) on the Terminal Licenses
Services license server.
Configure the terminal server to support Configuring License Settings on a Terminal

TS Licensing. Server
Installing TS Licensing
Use the following procedure to install the TS Licensing role service if Terminal Services is
not already installed on the server. If Terminal Services is already installed on the server,
use the "To install the TS Licensing role service when Terminal Services is already
installed" procedure.
Membership in the Administrators group, or equivalent, is the minimum required to

11
To install the TS Licensing role service

2. Under Roles Summary, click Add roles.

4. On the Select Server Roles page, under Roles, select the Terminal Services
check box.
Note
If Terminal Services is already installed on the server, the Terminal
Services check box will be selected and dimmed.
5. Click Next.
7. On the Select Role Services page, select the TS Licensing check box.
8. On the Configure Scope for TS Licensing page, specify the scope for
TS Licensing. For more information about TS Licensing scopes, see Terminal
Services License Server Discovery.
9. On the Configure Scope for TS Licensing page, specify the location where the
TS Licensing database will be stored. If you want to specify a database location
other than the default location provided, click Browse. Note that the database
location must be a local folder on the computer on which TS Licensing is being
installed.
10. Click Next.
11. On the Confirm Installation Selections page, verify that the TS Licensing role
13. On the Installation Results page, confirm that installation for the role service
was successful, and then click Close.
Use the following procedure to install the TS Licensing role service when Terminal
Services is already installed on the server.
To install the TS Licensing role service when Terminal Services is already

installed
12

2. In the left pane, expand Roles.
3. Right-click Terminal Services, and then click Add Role Services.
4. On the Select Role Services page, click to select the TS Licensing check box,
5. On the Configure Scope for TS Licensing page, specify the scope for
TS Licensing. For more information about TS Licensing scopes, see Terminal
Services License Server Discovery.
6. On the Configure Scope for TS Licensing page, specify the location where the
TS Licensing database will be stored. If you want to specify a database location
other than the default location provided, click Browse. Note that the database
location must be a local folder on the computer on which TS Licensing is being
installed.
7. Click Next.
8. On the Confirm Installation Selections page, verify that the TS Licensing role
10. On the Installation Results page, confirm that installation for the role service
was successful, and then click Close.
Connecting to a Terminal Services

License Server
After installing TS Licensing, you can use the TS Licensing Manager tool to connect to
and manage Terminal Services license servers.
If you want to use TS Licensing Manager from another Windows Server "Longhorn"
computer, see Installing TS Licensing Manager.

13
To connect to a Terminal Services license server

1. Click Start, point to Administrative Tools, point to Terminal Services, and then
click TS Licensing Manager.
2. On the Action menu, click Connect.

3. In the Server box, type the name of the license server to which you want to
connect, and then click Connect.
When TS Licensing Manager opens, it automatically tries to find all license servers in the
workgroup or domain.
Installing TS Licensing Manager

The TS Licensing Manager tool in Windows Server "Longhorn" is automatically installed
on any computer on which the TS Licensing role service has been installed. If you want
to manage your license servers from a remote computer running Windows Server
"Longhorn", you can install TS Licensing Manager on that computer by using the
following procedure.
To install TS Licensing Manager

2. In the left pane, right-click Features, and then click Add Features.
3. On the Select Features page, expand Remote Server Administration Tools,
expand Role Administration Tools, and then expand Terminal Services.
4. Select the TS Licensing Manager check box, and then click Next.
5. On the Confirm Installation Selections page, click Next.
6. On the Installation Results page, confirm that installation of TS Licensing
Manager was successful, and then click Close.
7. To run TS Licensing Manager, click Start, point to Administrative Tools, point
to Terminal Services, and then click TS Licensing Manager.
14
Activating a Terminal Services License

Server
A Terminal Services license server must be activated in order to certify the server and
allow the license server to issue Terminal Services client access licenses (TS CALs). You
can activate a license server by using the Activate Server Wizard in the TS Licensing
Manager tool.
There are three methods by which you can activate your license server:
• Internet (Automatic) This method requires Internet connectivity from the computer
running TS Licensing Manager. Internet connectivity is not required from the license
server itself. This method uses TCP/IP (TCP Port 443) to connect directly to the
Microsoft Clearinghouse.
• Web You can use the Web method when the computer running TS Licensing
Manager does not have Internet connectivity, but you have access to the Web by
means of a Web browser from another computer. The URL for the Web method is
displayed in the Activate Server Wizard.
• Telephone The telephone method allows you to talk to a Microsoft customer
service representative to complete the activation process. The appropriate telephone
number is displayed in the Activate Server Wizard and is determined by the
country/region that you choose in the wizard.
When you activate the license server, Microsoft provides the server with a limited-use
digital certificate that validates server ownership and identity. Microsoft uses an X.509
industry standard certificate for this purpose. By using this certificate, a license server
can make subsequent transactions with Microsoft.
You only need to activate a license server once. While waiting to complete the activation
or TS CAL installation processes, your license server can issue temporary TS CALs that
allow clients to use terminal servers for up to 90 days.
• Activating a Terminal Services License Server Automatically
• Activating a Terminal Services License Server by Using a Web Browser
• Activating a Terminal Services License Server by Using the Telephone
15

Server Automatically
The automatic activation method requires Internet connectivity from the computer running
the TS Licensing Manager tool. Internet connectivity is not required from the license
server itself. This method uses TCP/IP (TCP Port 443) to connect directly to the Microsoft
Clearinghouse.
To activate a Terminal Services license server automatically

2. Right-click the license server that you want to activate, and then click Activate
Server. The Activate Server Wizard starts.
3. Click Next.
4. On the Connection method page, in the Connection method list, select

Automatic connection (recommended), and then click Next.
5. On the Company Information page, type your name, company, and
country/region information, and then click Next.
6. Specify any other information that you want such as e-mail and company
address. This information is optional.
7. Click Next. Your license server is activated.

8. On the Completing the Activate Server Wizard page, do one of the following:
• To install Terminal Services client access licenses (TS CALs) onto your
license server, ensure that the Start Install Licenses Wizard now check
box is selected, click Next, and then follow the instructions.
• To install TS CALs later, clear the Start Install Licenses Wizard now check
box, and then click Finish.
16

Server by Using a Web Browser
The Web activation method can be used when the computer running the TS Licensing
Manager tool does not have Internet connectivity, but you have access to the Web by
means of a Web browser from another computer. The URL for the Web method is
displayed in the Activate Server Wizard.
To activate a Terminal Services license server by using a Web browser

3. Click Next.
4. On the Connection method page, in the Connection method list, select Web
Browser, and then click Next.
5. On the License Server Activation page, click the hyperlink to connect to the
Terminal Server Licensing Web site.
6. Under Select Option, click Activate a license server, and then click Next.
7. In the Product ID boxes, type your Product ID. Your Product ID is displayed on
the License Server Activation page of the Activate Server Wizard. Complete
the name, company, and country/region fields, and then click Next.
8. Confirm your entries, and then click Next. Your license server ID is displayed.
Write down the license server ID or print the Web page.
9. On the License Server Activation page of the Activate Server Wizard, type the
license server ID that you received in the previous step, and then click Next.
Your license server is activated.
10. On the Completing the Activate Server Wizard page, do one of the following:
17

Server by Using the Telephone
The telephone activation method allows you to talk to a Microsoft customer service
representative to complete the activation process. The appropriate telephone number is
displayed in the Activate Server Wizard and is determined by the country/region that you
choose in the wizard.
To activate a Terminal Services license server by telephone

3. Click Next.
4. On the Connection method page, in the Connection method list, select

Telephone, and then click Next.
5. On the Country or Region Selection page, click your country/region, and then
click Next to display the appropriate telephone number to call.
6. Call Microsoft by using the telephone number that is displayed on the License
Server Activation page, and then provide the Microsoft customer support
representative with the Product ID that is displayed on your screen. The
representative will also ask you to provide your name and the name of your
organization. The representative processes your request to activate the license
server, and creates a unique ID for your license server.
7. On the License Server Activation page, type the license server ID that the
representative provides, and then click Next. Your license server is activated.
8. On the Completing the Terminal Server License Server Activation Wizard

18
page, do one of the following:

Installing Terminal Services Client

Access Licenses
There are three methods by which you can install Terminal Services client access
licenses (TS CALs) onto your license server by using the Install Licenses Wizard in the
TS Licensing Manager tool:
• Internet (Automatic) This method requires Internet connectivity from the computer
running TS Licensing Manager. Internet connectivity is not required from the license
server itself. This method uses TCP/IP (TCP Port 443) to connect directly to the
Microsoft Clearinghouse.
• Web You can use the Web method when the computer running TS Licensing
Manager does not have Internet connectivity, but you have access to the Web by
means of a Web browser from another computer. The URL for the Web installation
method is displayed in the Install Licenses Wizard.
• Telephone The telephone method allows you to talk to a Microsoft customer

service representative to complete the installation process. The appropriate
telephone number is determined by the country/region that you choose in the Install
Licenses Wizard and is displayed by the wizard.
Before installing TS CALs onto your license server, please note the following:
• You must activate your Terminal Services license server before you can install
TS CALs onto your license server.
• You will need a license code to install TS CALs onto your license server. A license
code is provided when you purchase your TS CALs.
19
Note
For the Windows Server "Longhorn" Beta 3 release, you do not have to
purchase TS CALs from Microsoft. Instead, you can use a test license code
from Microsoft so that you can install Windows Server "Longhorn" beta
TS CALs on a Windows Server "Longhorn" Beta 3 license server. For more
information, see Obtaining Beta Terminal Services Client Access Licenses.
• Installing Terminal Services Client Access Licenses Automatically
• Installing Terminal Services Client Access Licenses by Using a Web Browser
• Installing Terminal Services Client Access Licenses by Using the Telephone
Obtaining Beta Terminal Services Client

Access Licenses
For the Windows Server "Longhorn" Beta 3 release, you do not have to purchase
TS CALs from Microsoft. Instead, you can use a test license code from Microsoft so that
you can install Windows Server "Longhorn" beta TS CALs on a Windows Server
"Longhorn" Beta 3 license server.
Note
The test license code should only be used for beta testing and evaluation
purposes.
To obtain a test license code for installation of beta TS CALs

1. Go to the Terminal Server License Code Request Web site
2. On the Terminal Server License Code Request page, read the welcome
message.
3. Under Customer Information, complete the following required fields; you can
also complete the optional fields (such as Last Name, First Name):
• Country
• Source Select Technical Beta (download site).
20
• License Type Select Windows Server "Longhorn" Per Device or Per User
CALs.
• E-Mail Address Enter the e-mail address to which you want the test license
code delivered.
4. Click Next.
5. On the Confirm License Code Request page, re-enter your e-mail address,
verify that all the other information you entered is correct, and then click Submit.
6. On the License Code Request Successfully Processed page, click Finish.
7. You will receive an e-mail message with the subject line "Terminal Server
License Management" that contains your test license code.
8. Copy the test license code into a safe location and do not delete the e-mail. This
test code is important and will be required when installing Windows Server
"Longhorn" beta TS CALs.

Access Licenses Automatically
The automatic installation method requires Internet connectivity from the computer
running TS Licensing Manager to complete the Terminal Services client access license
(TS CAL) installation process. Internet connectivity is not required from the license server
itself. This method uses TCP/IP (TCP Port 443) to connect directly to the Microsoft
Clearinghouse.
Note
TS CALs from Microsoft. Instead, you can use a test license code from Microsoft
so that you can install Windows Server "Longhorn" beta TS CALs on a
Windows Server "Longhorn" Beta 3 license server. For more information, see
Obtaining Beta Terminal Services Client Access Licenses.

21
To install client access licenses automatically

2. Verify that the installation method for the Terminal Services license server is set
to Automatic connection (recommended) by right-clicking the license server
on which you want to install TS CALs, and then clicking Properties. On the
Connection Method tab, change the connection method if necessary.
3. In the console tree, right-click the Terminal Services license server on which you
want to install the TS CALs, click Install Licenses to open the Install Licenses
Wizard, and then click Next.
4. On the License Program page, select License Pack (Retail Purchase). Other
programs are not supported for the Windows Server "Longhorn" Beta 3 release.
Click Next.
5. On the License Code page, type the test license code that you received in e-
mail into the boxes provided, and then click Add. If you have more than one test
license code, type each additional code and click Add until all the codes are
entered.
6. Click Next. The TS CALs are installed on your Terminal Services license server.
7. On the Completing the Install Licenses Wizard page, click Finish. The
Terminal Services license server can now issue TS CALs to clients that connect
to a terminal server.

Access Licenses by Using a Web
Browser
The Web method can be used to complete the Terminal Services client access license
(TS CAL) installation process when the computer running the TS Licensing Manager tool
does not have Internet connectivity, but you have access to the Web by means of a Web
browser from another computer. The URL for the Web installation method is displayed in
the Install Licenses Wizard.
22
Note
To install client access licenses by using a Web browser

to Web Browser by right-clicking the license server on which you want to install
TS CALs, and then clicking Properties. On the Connection Method tab, change
the connection method if necessary.
4. On the Obtain Client License Key Pack page, click the hyperlink to connect to
the Terminal Server Licensing Web site. You can connect to this site from any
computer that has Internet access.
5. On the Windows Terminal Services Web page, under Select Option, click Install
Client Access License tokens, and then click Next.
6. Provide the following required information:
• License Server ID A 35-digit number, in groups of 5 numerals, which is
displayed in the Install Licenses Wizard.
• License Program Select License Pack (Retail Purchase). Other
programs are not supported for the Windows Server "Longhorn" Beta 3
release.
• Last name or surname
• First name or given name
• Company name
• Country/region
23
You can also provide the optional information requested, such as company
address, e-mail address, and phone number. In the organizational unit field, you
can describe the unit within your organization that this license server will serve.
7. Click Next.
8. In the License Codes boxes, type the test license code that you received in e-
mail, and then click Add. If you have more than one test license code, type each
additional code and click Add until all the codes are entered, and then click Next.
9. Verify that all of the information you have entered is correct. To submit your
request to the Microsoft Clearinghouse, click Next. The Web page then displays
a TS CAL ID generated by the Microsoft Clearinghouse. Write down the TS CAL
ID or print the Web page.
10. In the Install Licenses Wizard, on the Obtain Client License Key Pack page,
enter the TS CAL ID that you received in the previous step, and then click Next.
The TS CALs are installed on your Terminal Services license server.

Access Licenses by Using the Telephone
The telephone installation method allows you to talk to a Microsoft customer service
representative to complete the Terminal Services client access license (TS CAL)
installation process. The appropriate telephone number is displayed in the Install
Licenses Wizard and is determined by the country/region that you have specified.
Note

24
To install client access licenses by using the telephone

to Telephone by right-clicking the license server on which you want to install
TS CALs, and then clicking Properties. On the Connection Method tab, change
the connection method if necessary. On the Required Information tab, change
the country/region if necessary.
4. On the Obtain client license key pack page, use the telephone number that is
displayed to call the Customer Support Center, and give the representative your
Terminal Services license server ID and the test license code that you received
in e-mail. The representative then processes your request to install TS CALs,
and gives you a unique ID for the TS CALs.
5. On the Obtain client license key pack page, type the TS CALs ID provided by
the representative into the boxes, and then click Next. The TS CALs are installed
on your Terminal Services license server.
Configuring License Settings on a

Terminal Server
After you have installed and configured the Terminal Services license server, you need to
configure your terminal server by doing the following:
• Specifying the Terminal Services licensing mode
• Specifying the license server discovery mode
25
Specifying the Terminal Services licensing

mode
configure the Terminal Services licensing mode on your terminal server. The Terminal
Services licensing mode determines the type of Terminal Services client access licenses
(TS CALs) that a license server issues to a client connecting to the terminal server.
Important
The Terminal Services licensing mode must match the type of TS CALs available
on the license server.
The Terminal Services licensing mode can be set in the following ways:
• During the installation of the Terminal Server role service in Server Manager
• By configuring Terminal Server licensing mode in the Terminal Services
Configuration tool
• By applying the Set the Terminal Services licensing mode Group Policy setting
Specifying the license server discovery mode

configure the license server discovery mode on your terminal server. This will help
ensure that the terminal server can contact the license server in order to request
Terminal Services client access licenses (TS CALs).
The license server discovery mode can be set in the following ways:
• By configuring License Server discovery mode in the Terminal Services
Configuration tool
• By applying the Use the specified Terminal Services license servers Group Policy
setting
In the automatic license server discovery process, a terminal server in a Windows
Server-based domain attempts to contact a license server in the following order:
• License servers that are specified in the Terminal Services Configuration tool
• License servers that are published in Active Directory® Domain Services
• License servers that are installed on domain controllers in the same domain as the
terminal server
26
Tracking the Issuance of Terminal

Services Client Access Licenses
In Windows Server "Longhorn", you can use the TS Licensing Manager tool to track and
generate reports on the issuance of Terminal Services Per User client access licenses
(TS Per User CALs).
Important
TS Per User CAL tracking and reporting is supported only in domain-joined
scenarios; that is, the terminal server and the Terminal Services license server
must be members of a domain. TS Per User CAL tracking and reporting is not
supported in workgroup mode. Active Directory Domain Services is used for
license tracking in Per User mode. Active Directory Domain Services can be
Windows Server "Longhorn"-based or Windows Server 2003-based. Also, the
computer account for the license server must be a member of the Terminal
Server License Servers group in the domain.
To track the issuance of TS Per User CALs

2. Right-click the license server about which you want to generate a report, point to
Create Report, and then select Per User CAL Usage.
3. Select the scope of the report, and then click Create Report.
4. The report will appear in the Reports node under the license server.
Troubleshooting TS Licensing
Installation
You can check the configuration of your Terminal Services license server and identify
common licensing problems for a terminal server by using the following:
• Review Configuration in the TS Licensing Manager tool
27
• Licensing Diagnosis in the Terminal Services Configuration tool
Reviewing the configuration of your license

server
After installing the TS Licensing role service on a Windows Server "Longhorn" computer,
you can use TS Licensing Manager to review the configuration of the license server. The
purpose of this configuration review is to identify any possible problems on the license
server—not the terminal server—that would prevent the license server from:
• Being discovered by terminal servers.
• Issuing Terminal Services client access licenses (TS CALs) to users or devices
connecting to a terminal server.
• Tracking and reporting the issuance of TS CALs.

To review the configuration of a license server

1. On the license server, click Start, point to Administrative Tools, point to
Terminal Services, and then click TS Licensing Manager.
2. In the left pane, click All servers. In the right pane, the Configuration column
provides a general configuration status for a license server.
3. To review the configuration details of a license server, right-click the license
server that you want to review, and then click Review Configuration.
4. The dialog box will provide you with information about the configuration of the
license server. If a configuration problem is identified, you can correct the
problem from within the dialog box.
Diagnosing licensing problems on your

terminal server
After you have installed and configured the license server and you have configured the
license settings on your terminal server, you can use Terminal Services Configuration to
diagnose common licensing problems for your terminal server. The purpose of this
diagnosis is to identify configuration problems on the terminal server—not the license
28
server—that would prevent users from connecting to the terminal server because of
licensing issues.
Note
For more information about license settings, see Configuring License Settings on
a Terminal Server.
To diagnosis licensing problems on a terminal server

1. On the terminal server, click Start, point to Administrative Tools, point to
Terminal Services, and then click Terminal Services Configuration.
2. .In the left pane, click Licensing Diagnosis.

3. The center pane provides information about the following:
• Configuration information about the terminal server
• License servers that the terminal server discovered

• Configuration information about the license servers
• Licensing problems identified along with possible resolutions
Known Issues for TS Licensing

Installation
The following are known issues related to the installation of TS Licensing in the Beta 3
release of Windows Server "Longhorn".
29
Issue 1 Installing TS Licensing with insufficient AD DS

privileges
Issue details When you install the TS Licensing role service

by using the Add Roles Wizard in Server
Manager, the Installation Results page may
show errors. These errors usually indicate a
TS Licensing configuration issue, not an
installation problem.
These errors can occur if you do not have the

appropriate privileges when installing
TS Licensing. For example:
• If the computer on which you are installing

TS Licensing is joined to a domain, you
should perform the TS Licensing
installation with an account that has
Domain Admins privileges in Active
Directory Domain Services (AD DS). If you
do not install TS Licensing with an account
that has Domain Admins privileges in
AD DS, the TS Licensing installation may
succeed, but you will see an error message
on the Installation Results page because
TS Licensing could not be properly
configured after being installed.
• If you want to configure the scope for
TS Licensing as "forest" during the
installation process, you should perform the
TS Licensing installation with an account
that has Enterprise Admins privileges in
AD DS. If you do not install TS Licensing
with an account that has Enterprise Admins
privileges in AD DS, the TS Licensing
installation may succeed, but you will see
an error message on the Installation
Results page because TS Licensing could
not be properly configured after being
installed.
30
Issue 1 Installing TS Licensing with insufficient AD DS

privileges
Workaround If you see error messages on the Installation

Results page:
(how you can fix the problem if you
encounter it) • Determine if the Terminal Services
Licensing service is running. If it is running,
the Installation Results page will confirm
that TS Licensing installation succeeded
but some configuration steps failed.
After confirming that some configuration steps
failed, you can do the following to correct the
issues noted:
• Correct these problems, if you have the
required privileges in AD DS, by using
Review Configuration in the TS Licensing
Manager tool. For more information, see
Troubleshooting TS Licensing Installation.
• Contact someone with Domain Admins

privileges in AD DS to manually add the
computer account for the license server to
the Terminal Server License Servers group
in AD DS.
• Contact someone with Enterprise Admins
privileges in AD DS to publish the license
server in AD DS by using the instructions in
article 555034 in the Microsoft Knowledge
Base
(http://go.microsoft.com/fwlink/?LinkId=674
39).
31
Issue 2 Specifying an invalid database path during

TS Licensing installation
Issue details While installing TS Licensing on

Windows Server "Longhorn" by using the
Add Roles Wizard in Server Manager, you
can specify an invalid database path for the
TS Licensing database and you will be
allowed to proceed through installation. You
will not be alerted to the invalid
TS Licensing database path because the
Add Roles Wizard does not validate the
path. At the end of the installation, the
TS Licensing installation may succeed, but
you will see an error message on the
Installation Results page.
Workaround The TS Licensing database path must be a

local folder on the computer on which
TS Licensing is being installed.
If you enter an invalid TS Licensing
database path, the database will
automatically be installed to the default
database path location (system32\lserver).
The database path cannot be changed after

TS Licensing has been installed.
To avoid this issue, on the Configure
Scope for TS Licensing page in the Add
Roles Wizard in Server Manager, use the
Browse button and select the appropriate
folder on the local computer.
32
Issue 3 Unattended installation limits database and

scope options
Issue details If you install TS Licensing by using

unattended installation, the following
limitations exist:
• TS Licensing will be installed with the

default database path. It is not possible to
specify another database path.
• The scope of TS Licensing cannot be

specified. The scope will be either domain
or workgroup, depending on whether the
computer is joined to a domain. Because
the scope cannot be set to forest, the
license server will not be published in
AD DS, which will limit which terminal
servers will be able to automatically
discover the license server.
• The computer account for the license
server will not be automatically added to
the Terminal Server License Servers
group in AD DS if the computer is joined
to a domain. This will prevent the license
server from being able to track and report
on Terminal Services Per User client
access licenses (TS Per User CALs).
33
Issue 3 Unattended installation limits database and

scope options
Workaround To avoid these issues, we highly recommend

that you use the Add Roles Wizard in Server
Manager to install TS Licensing.
If you have done an unattended installation of

TS Licensing, you can do the following to
correct the issues noted:
• The database path cannot be changed

after TS Licensing has been installed.
• If you do not have the required privileges,
contact someone with Enterprise Admins
privileges in AD DS to publish the license
server in AD DS by using the instructions
in article 555034 in the Microsoft
Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=).

contact someone with Domain Admins
the Terminal Server License Servers
group in AD DS.
34
Issue 4 Uninstalling TS Licensing with insufficient

AD DS privileges
Issue details If you uninstall TS Licensing by using the

Remove Roles Wizard in Server Manager by
using an account with insufficient AD DS
privileges, the following issues will occur:
• The license server is not unpublished from
AD DS.
• The computer account for the license

server is not removed from the Terminal
Server License Servers group in AD DS.
• The folder for the TS Licensing database is

not removed.
Workaround To avoid these issues, uninstall TS Licensing

by using an account with sufficient AD DS
privileges.
Otherwise, you can do the following to correct

the issues noted:
contact someone with Enterprise Admins
privileges in AD DS to unpublish the license
server in AD DS by using the instructions in
article 555034 in the Microsoft Knowledge
Base
(http://go.microsoft.com/fwlink/?LinkId=674
39).
contact someone with Domain Admins
the Terminal Server License Servers group
in AD DS.
• Manually delete the folder that contains the
TS Licensing database.
35
Issue 5 Beta license servers will not issue licenses to RTM

terminal servers
Issue details A typical deployment life cycle could include beta

operating systems mixed with release to
manufacturing (RTM) operating systems.
Moreover, it is often not possible to perform a
single enterprise-wide operating system
upgrade, so there will always be the possibility of
having a beta Terminal Services license server
and an RTM terminal server. The beta Terminal
Services license servers will not issue licenses
to RTM terminal servers.
Workaround You need to add an entry to the registry of the

beta license server so that the RTM terminal
servers can request and receive licenses from
the beta license server.
Subkey:
HKLM\Software\Microsoft\TermServLicensing
Entry name: RunAsRTM
Entry type: DWORD
Value: 1

Server 2008

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Server 2008

Hochgeladen von

Copyright:

Verfügbare Formate

Creating and Deploying Active Directory

Rights Management Services Templates

Published: May 2007

Microsoft may have patents, patent applications, trademarks, copyrights, or other

© 2007 Microsoft Corporation. All rights reserved.

All other trademarks are property of their respective owners.

Step 1: Creating a Shared Folder on the AD RMS Cluster................................................. 7

Step 2: Creating an AD RMS Rights Policy Template ........................................................ 9

Step 3: Configuring the AD RMS client ............................................................................. 10

Step 4: Verifying AD RMS Functionality using ADRMS-CLNT ......................................... 12

Creating and Deploying Active Directory

About this Guide

What This Guide Does Not Provide

• Guidance for setting up and configuring AD RMS in either a production or test

Active Directory Rights Management Services Step-by-Step Guide

Deploying AD RMS in a Test Environment

Computer Name Operating System Applications and Services

ADRMS-SRV Windows Server "Longhorn" AD RMS, Internet

CPANDL-DC Windows Server 2003 with Active Directory®, Domain

Computer Name Operating System Applications and Services

ADRMS-DB Windows Server 2003 with Microsoft SQL

ADRMS-CLNT Windows Vista Microsoft Office Word 2007

Step 1: Creating a Shared Folder on the

To create an AD RMS rights policy templates shared folder

8. In the Group or user names box, click ADRMSSRVC

Step 2: Creating an AD RMS Rights

To create a new AD RMS rights policy template

2. In the Active Directory Rights Management Services Administration console, click

9. Type CPANDL.COM CC in the Name box.

11. Click Next.

14. Click Finish.

Step 3: Configuring the AD RMS client

To create a folder for rights-protected content

6. Click the Security tab, and then click Edit.

To make AD RMS templates available to users on ADRMS-CLNT

9. Copy the exported AD RMS rights policy templates from \\ADRMS-

Step 4: Verifying AD RMS Functionality

To restrict permissions on a Microsoft Word 2007 document

To view a protected document

The following message appears: "Permission to this document is currently

srv.cpandl.com/_wmcs/licensing to verify your credentials and download

The following message appears: "Verifying your credentials for opening

Microsoft may have patents, patent applications, trademarks, copyrights, or other

© 2007 Microsoft Corporation. All rights reserved.

All other trademarks are property of their respective owners.

Step 1: Configuring AD RMS to Work in an Extranet ......................................................... 8

Step 2: Installing and Configuring ISA-SRV ..................................................................... 10

Step 3: Configuring AD RMS Extranet Client ................................................................... 15

Step 4: Verifying AD RMS Functionality using ADRMS-CLNT ......................................... 18

Deploying Active Directory Rights

About this Guide

As you complete the steps in this guide, you will:

What This Guide Does Not Provide

Server Active Directory Rights Management Services Step-by-Step Guide

Deploying AD RMS in a Test Environment

Computer Name Operating System Applications and Services

ADRMS-SRV Windows Server 2008 AD RMS, Internet

CPANDL-DC Windows Server 2003 with Active Directory, Domain

Computer Name Operating System Applications and Services

ADRMS-DB Windows Server 2003 with SP1 Microsoft SQL

ADRMS-CLNT Windows Vista™ Microsoft Office Word 2007

ADRMS-EXCLNT Windows Vista Microsoft Office Word 2007

Step 1: Configuring AD RMS to Work in

To configure the AD RMS extranet cluster URLs