Preparation Guide for Exam 70-

643
TS: Windows Server 2008 Applications Infrastructure, Configuring

Contents
Skills Being Measured..................................................................................... ............3
Deploying Servers......................................................................................................6
Windows Deployment Services.............................................................................. ..6
Important Features of Windows Server 2008 Deployment...................................6
How Does Windows Deployment Services Work?.................................................7
Multicast Support in Windows Deployment Services............................................9
Managing Images by Using ImageX.....................................................................9
Process for Installing Windows Deployment Services.........................................10
TechNet Virtual Lab: Deployment Services (WDS) in Windows Server 2008 Beta
3.......................................................................................................... ...............11
KMS Activation..................................................................................................... ..11
Prerequisites for KMS Activation.........................................................................11
Known Issues for KMS Activation .......................................................................12
Steps for Installing, Configuring, and Deploying KMS Activation........................12
KMS Hosts..........................................................................................................13
KMS Publishing to DNS.......................................................................................15
Steps for Configuring KMS Publishing to DNS.....................................................17
KMS Clients........................................................................................................20
Configure Windows Server Hyper-V and virtual machines.....................................23
Virtualization Scenarios in Windows Server 2008..................................................23
What Is Virtualization?................................................................................. .......23
TechNet Webcast: Virtualization and Windows Server 2008 (Level 300)............24
Overview of the Production Server Consolidation Scenario................................24
Overview of the Business Continuity Management Scenario..............................25
Overview of the Dynamic Datacenter Scenario..................................................25
Overview of the Test and Development Scenario...............................................26
 Virtualization Features in Windows Server 2008................................................27
Features of System Center Virtual Machine Manager.........................................28
Configure high availability.....................................................................................29
TechNet Webcast: Achieving High Availability with Windows Server 2008
Clustering (Level 200)........................................................................................29
What Is Failover Clustering?...............................................................................29
Process for Validating the Server Environment for Clustering............................30
Requirements for Installing Failover Clustering..................................................31
How to Install Failover Clustering.......................................................................32
Implementing Network Load Balancing in Windows Server 2008.......................33
Implementing High Availability and Virtualization in Windows Server 2008.......34
TechNet Virtual Lab: Windows Server 2008 Enterprise Failover Clustering Lab. .34
Windows Server 2008 Availability and Scalability Article...................................34
Configuring Terminal Services..................................................................................34
Core Functionality of Terminal Services.................................................................34
Overview of Functionalities of Terminal Services................................................35
What Is Terminal Services Licensing?.................................................................36
Considerations for Implementing Terminal Services Licensing...........................38
Implementing Terminal Services Remote Programs...............................................39
What Are Terminal Services Remote Programs?.................................................39
How to Manage Remote Programs.....................................................................40
Implementing Terminal Services Web Access........................................................40
How to Implement Terminal Services Web Access..............................................40
Implementing Terminal Services Gateway.............................................................41
What Is Terminal Services Gateway?..................................................................42
Considerations for Planning the Terminal Services Gateway Installation............42
Installing the Terminal Services Gateway Role...................................................44
Managing Terminal Services by Using Windows System Resource Manager..........45
What Is Windows System Resource Manager?...................................................45
Summary................................................................................................. ..............47
Core Functionality of Terminal Services..............................................................47
Implementing Terminal Services Remote Programs...........................................47
 TechNet Virtual Lab: Centralized Application Access with Windows Server 2008
Beta 3........................................................................................................... ......48
Implementing Terminal Services Web Access.....................................................48
Implementing Terminal Services Gateway..........................................................48
Managing Terminal Services by Using Windows System Resource Manager......49
TechNet Virtual Lab: Managing Terminal Services Gateway and RemoteApps in
Windows Server 2008...................................................................................... ...49
Configuring a Web Services Infrastructure ..............................................................49
Manage Internet Information Services (IIS)...........................................................49
TechNet Webcast: End-to-End Overview of Internet Information Services 7.0
(Level 200)................................................................................. ........................49
Benefits of the IIS 7.0 Server Role......................................................................49
Features of the Administrative Tools in IIS 7.0....................................................50
Configuration Files in IIS 7.0...............................................................................51
Options for Replicating Settings between Servers..............................................52
Options for Managing Security in IIS 7.0............................................................53
Options for Troubleshooting IIS 7.0.....................................................................54
TechNet Virtual Lab: Using APPCMD Command Line or UI with IIS 7 in Windows
Server 2008.................................................................................................... ....54
Configuring Network Application Services ...............................................................54
Configure Windows Media server..........................................................................54
Configuring Advanced Streaming Solutions in Windows Media Server...............54
Options for Configuring Security in Windows Media Server................................56
Active Directory Rights Management Service........................................................57
Features............................................................................................................57
Requirements................................................................................. ....................57

Skills Being Measured

This exam measures your ability to accomplish the technical tasks listed in the following table. The
percentages indicate the relative weight of each major topic area on the exam.

Skills measured by Exam 70-643

Deploying Servers (23 percent)

Deploy images by using Windows Deployment Services.

May include but is not limited to: Install from media (IFM); configure Windows Deployment Services;
Skills measured by Exam 70-643

capture Windows Deployment Services images; deploy Windows Deployment Services images; server
core

Configure Microsoft Windows activation.

May include but is not limited to: install a KMS server; create a DNS SRV record; replicate volume
license data

Configure Windows Server Hyper-V and virtual machines.

May include but is not limited to: virtual networking; virtualization hardware requirements; Virtual Hard
Disks; migrate from physical to virtual; VM additions; backup; optimization; server core

Configure high availability.

May include but is not limited to: failover clustering; Network Load Balancing; hardware redundancy

Configure storage.
May include but is not limited to: RAID types; Virtual Disk Specification (VDS) API; Network Attached
Storage; iSCSI and fibre channel Storage Area Networks; mount points

Configuring Terminal Services (31 percent)

Configure Windows Server 2008 Terminal Services RemoteApp (TS RemoteApp).

May include but is not limited to: Configuring Terminal Services Web Access; configuring Terminal
Services Remote Desktop Web Connection

Configure Terminal Services Gateway.

May include but is not limited to: certificate configuration; Terminal Services Gateway Manager (TS
Gateway Manager); specifying resources that users can access through TS Gateway by using Terminal
Services resource authorization policy (TS RAP) and Terminal Services connection authorization policy
(TS CAP); Terminal Services group policy

Configure Terminal Services load balancing.

May include but is not limited to: Terminal Services Session Broker redirection modes; DNS
registration; setting through group policy

Configure and monitor Terminal Services resources.

May include but is not limited to: allocate resources by using Windows Server Resource Manager;
configure application logging

Configure Terminal Services licensing.

May include but is not limited to: deploy licensing server; connectivity between terminal servers and
Terminal Services licensing server; recovering Terminal Services licensing server; managing Terminal
Services client access licenses (TS CALs)

Configure Terminal Services client connections.

May include but is not limited to: connecting local devices and resources to a session; Terminal Services
profiles; Terminal Services home folders; Remote Desktop Connection (RDC); single sign-on; Remote
Desktop Snap-In; MSTSC.exe

Configure Terminal Services server options.

May include but is not limited to: logoff; disconnect; reset; remote control; monitor; Remote Desktop
Protocol (RDP) permissions; connection limits; session time limits; managing by using GPOs; viewing
Skills measured by Exam 70-643

processes; session permissions; display data prioritization

Configuring a Web Services Infrastructure (30 percent)

Configure Web applications.

May include but is not limited to: directory-dependent; publishing; URL-specified configuration;
Microsoft .NET components, for example, .NET and aspx; configure application pools

Manage Web sites.

May include but is not limited to: migrate sites and Web applications; publish IIS Web sites; configure
virtual directories

Configure a File Transfer Protocol (FTP) server.

May include but is not limited to: configure for extranet users; configure permissions

Configure Simple Mail Transfer Protocol (SMTP).

May include but is not limited to: setting up smart hosts; configuring size limitations; setting up
security and authentication to the delivering server; creating proper service accounts; authentication;
SMTP relay

Manage Internet Information Services (IIS).

May include but is not limited to: Web site content backup and restore; IIS configuration backup;
monitor IIS; configure logging; delegation of administrative rights

Configure SSL security.

May include but is not limited to: configure certificates; requesting SSL certificate; renewing SSL
certificate; exporting and importing certificates

Configure Web site authentication and permissions.

May include but is not limited to: configure site permissions and authentication; configure application
permissions; client certificate mappings

Configuring Network Application Services (13 percent)

Configure Windows Media server.

May include but is not limited to: on-demand replication; configure time-sensitive content; caching and
proxy

Configure Digital Rights Management (DRM).

May include but is not limited to: encryption; sharing business rules; configuring license delivery;
configuring policy templates

Configure Microsoft Windows SharePoint Services server options.

May include but is not limited to: site permissions; backup; antivirus; configuring Windows SharePoint
Services service accounts

Configure Windows SharePoint Services e-mail integration.

May include but is not limited to: configuring a document library to receive e-mail; configuring incoming
vs. outgoing e-mail
Deploying Servers

Windows Deployment Services

Important Features of Windows Server 2008 Deployment

The installation process of Windows Server 2008 is simplified with the new image-
based installation technology. Many organizations use traditional sector-based
images that are difficult to update. To deal with this problem, a new imaging process
has been introduced in Windows Server 2008. Some of the components involved in
the new imaging process are:

Windows Imaging File (WIM) Format

The WIM is a file-based disk image format. The following are the benefits of
using a file-based image format over the typical sector-based image format:

• A single WIM file deals with different hardware configuration.

• WIM can store multiple images within a single file.
• WIM enables compression and single instancing of files. Single
instancing allows multiple images to share a single copy of a file.
• WIM allows images to be serviced offline. You can add or remove
drivers, files, and patches.
• A WIM image can be installed on partitions of any size, unlike sector-
based image formats.
• WIM allows nondestructive application of images.
• WIM allows you to boot Windows PE from a WIM file.

Windows PE boot operating system

Windows Server 2008 is modularized to ensure that the setup files are
composed of multiple components, rather than a single file. The following are
the benefits of modularizing Windows Server 2008:

• You can add device drivers, service packs, and updates to the image
files offline without installing the image on a computer.
• You can customize certain Windows components, based on your
requirements.
• You can update a component without re-creating the image when an
update is introduced.
• You can deploy multiple language versions of the operating system in a
single image file because the core Windows components are not
language-specific.
 Windows PE 2.0

Windows PE 2.0 is a compact, special purpose Windows operations system.

Windows PE 2.0 is a bootable tool that provides operating system features.
Windows PE has been designed to replace MS-DOS as the pre-installation
environment. Windows PE loads into RAM to help you in modifying Windows
Server 2008 operating system files. You can use Windows PE for three specific
tasks:

• Installing Windows Server 2008. Windows PE runs every time you

install Windows Server 2008.
• Troubleshooting. Windows PE can be used for both automatic and
manual troubleshooting.
• Recovering and Rebuilding. Original Equipment Manufacturers (OEMs)
and Independent Software Vendors (ISVs) use Windows PE to build
customized, automated solutions to recover and rebuild computers
that run Windows Vista.

Windows System Image Manager

By using Windows System Image Manager (SIM), you can create and manage
unattended Windows Setup answer files in a GUI. You can use answer files,
which are XML-based files, to configure and customize the default Windows
installation.

You can use Windows SIM to:

• Create or update existing unattended answer files.

• Validate the settings of an existing answer file against a WIM file.
• View all the configurable component settings in a WIM file.
• Create a configuration set.
• Add third-party drivers, applications, or other packages to an answer
file.

Script-based installations

WDS includes extensive support for using the command line and scripting to
enable remote, automated, and repeatable deployment scenarios. For
example, ImageX, Migration, and SIM are completely scriptable.

How Does Windows Deployment Services Work?

WDS is the updated version of Remote Installation Services (RIS). WDS allows rapid
adoption and deployment of Windows operating systems. By using WDS, you can
deploy new computers through network-based installation. You can install Windows
Server 2008 or Windows Vista by using WDS.
WDS Components

WDS is a suite of components that enable the deployment of Windows

operating systems. These components can be categorized into:

• Management components. Management components are a set of tools

used to manage the server, operating system images, and client
computer accounts. The WDS Microsoft Management Console (MMC)
snap-in is a management component.
• Server components. Server components include a Pre-Boot eXecution
Environment (PXE) server, Trivial File Transfer Protocol (TFTP) server,
and a shared folder and image repository. By using the server
components, you can network boot a client to load and install an
operating system.
• Client components. Client components include GUI that run in the
Windows PE. The client components communicate with the server
components to select and install an operating system.

The Windows Deployment Process

The steps involved in deploying a Windows operating system are:

1. Create an answer file by using SIM. The steps to create an answer file
are:
o Build a catalog and then create a new blank answer file.
o Add components and configure Windows settings.
o Validate the answer file and then save it to removable media.
2. Build a master installation by using the product DVD and your answer
file. A master installation is a customized installation of Windows,
which you can duplicate onto one or more destination computers.
3. Create an image of the master installation by using Windows PE and
ImageX technologies. The steps to create an image of the master
installation are:
o Create a CD that you can use to start Windows PE.
o Start the master installation by using Windows PE media.
o Capture the installation image by using ImageX.
o Store the image on a network share.
4. Deploy the image from a network share onto a destination computer
by using Windows PE and ImageX technologies. The steps to deploy
the image from a network share are:
o Start the computer by using Windows PE media.
o Format the hard drive.
o Connect to your network share and copy the custom image
down to the destination computer's local hard drive.
o Apply the image by using ImageX.
Multicast Support in Windows Deployment Services

Multicast is defined as the communication between a single sender and multiple

receivers on a network. For example, you can use multicast to distribute real-time
audio and video to a set of network hosts.

The main benefit of multicast is optimized network performance. If you want to send
the same data to multiple TCP/IP clients, it is more efficient to send that data to all
clients at once, rather than sending multiple separate transmissions.

WDS supports a new multicast protocol that has congestion control and flow control.
By using this protocol, clients can request an image anytime and trigger a new
multicast deployment or join an existing deployment, mid-transmission and receive
all the data. Windows Server 2008 can perform ImageX multicast deployments,
without requiring full-blown WDS or Active Directory. Windows Server 2008 consists
of a CMD-line multicast client application, which can run within Windows Server
2008, Windows PE, Windows Vista, Windows XP SP2, and Windows Server 2003 SP2.

WDS supports the following options for multicasting:

• New management tasks in WDS MMC and WDSUTIL.

• New WDS Client User Interface (UI) page that indicates multicast
transmission.
• Real-time multicast client view with the ability to remove clients from a
transmission by using WDS management tools.
• Real-time transmission progress or monitoring by using WDS management
tools.
• Installation logging and reporting by using Crimson to the application logs.
• Installation of a “stand-alone” WDS multicast server complete with
management tools and command-line client.

Managing Images by Using ImageX

ImageX is a command-line tool that you can use to create and manage WIM image
files (installation files for Windows Vista). By using ImageX, you can store multiple
images in a single image file and mount the WIM image files as folders. You can also
edit images offline by using ImageX.

Features of ImageX?

ImageX enables you to manage file-based disk images. ImageX works with
WIM files to build and deploy disk images. By using ImageX you can:

• View the contents of a WIM file.

• Capture desktop images.
• Mount images for offline image editing.
• Store multiple images in a single file.
• Compress image files.
 • Implement scripts for image creation.

Using ImageX

ImageX includes a number of command-line options that you can use to view
and manage a WIM file. The following are some of the common commands
and their functions:

• Info. This command is used to return information about the WIM file.
• Capture. This command is used to capture a volume image from a
drive to a new WIM file.
• Apply. This command is used to apply a volume image to a specified
drive.
• Append. This command is used to add a volume image to an existing
WIM file and create a single instance of the file.
• Delete. This command is used to remove the specified volume image
from a WIM file.
• Mountrw. This command is used to mount a WIM file with Read/Write
permission, thereby, allowing the contents of the file to be modified.
• Unmount. This command is used to unmount an image from a specified
directory.

Process for Installing Windows Deployment Services

You can install the WDS server role on Windows Server 2008. You can configure WDS
to deploy images to clients as long as the underlying infrastructure is in place. After
installing, you can configure WDS by using WDS MMC or the command-line utility.

Prerequisites for implementing WDS

You need to have the following infrastructure to implement WDS:

• AD DS. A WDS server must be either a member of an Active Directory

domain or a domain controller for an Active Directory domain. All
domain and forest configurations, irrespective of their version
numbers, support WDS.
• DHCP. You must have a working DHCP server with an active scope on
the network because WDS uses PXE, which, in turn, uses DHCP.
• DNS. You need a working DNS server on the network to run WDS.
• New Technology File System (NTFS) volume. The server running WDS
requires an NTFS file system volume for the image store.
• Administrative Credentials. During WDS installation, the administrator
must be a member of the Local Administrators group on the WDS
server. To start the WDS client, you must be a member of the Domain
Users group.
 Installing WDS

At the time of WDS installation, the administrator needs to be a member of

the Local Administrators group on the WDS server. You must authorize the
WDS service to run in Active Directory directory services.

The WDS service is installed as a server role. Once the WDS server role is
installed, you need to launch the WDS MMC. Also, you need to add the server
to the MMC and authorize the server in AD DS.

TechNet Virtual Lab: Deployment Services (WDS) in Windows Server 2008

Beta 3

KMS Activation

The Key Management Service (KMS) establishes a local activation enablement

service (the Key Management Service or KMS) that is hosted locally in your
environment. Use of the KMS thus eliminates any need for individual machines to
connect to Microsoft. KMS functionality can be enabled on any computer running
Windows Vista or Windows Server 2008 by installing the KMS key and then
activating the computer against Microsoft once, either over the Internet or by the
telephone. For a detailed description of KMS and KMS keys, please see the Volume
Activation 2.0 Overview.

Prerequisites for KMS Activation

• You must install a KMS host with the appropriate Volume License media. KMS clients
must also have the appropriate Volume License media to activate against the KMS host.
• KMS clients must be able to access a KMS host. Consider the following:
• Firewalls and the router network may need to be configured to pass communications
for the TCP port that will be used (default 1688).
If the Windows Firewall is used, no configuration is required on the client
computer, because bi-directional TCP sessions that originate from the client
computer are automatically allowed. You can configure the TCP port on the client
computer or KMS host by using the slmgr.vbs script or setting registry values.
You can also set up Group Policy for this. An exception has been added to the
Windows Firewall to facilitate opening the default port 1688.
• If IPSec authentication is used to restrict end-to-end communication between
computers in the network, you may need to configure one or more KMS hosts as
“boundary machines,” that is, communication may need to be allowed without IPSec
authentication in some situations. For example, some of your clients may be in
workgroups or you may have domain-based clients that must access a KMS host
across an Active Directory forest. The procedure for configuring this is beyond the
scope of this guide.
• You may need to configure the Applications and Services Logs\Key Management Service
event log on KMS hosts to ensure that it is large enough to accommodate the volume
 expected in your organization. Each 12290 event, which occurs every time a KMS client
connects to the KMS host, requires approximately 1,000 bytes. You can set the log size
in the Log Properties dialog box.

Known Issues for KMS Activation

On using KMS activation, you may encounter the following known issues:

• Changing the Renewal Interval will not take effect on a KMS client until after the
change is received by the client and the software licensing service (slsvc) is
restarted or the client computer restarted.
• Beta versions of KMS (including Windows Server 2008 beta hosts) cannot support
activation of released Windows Vista clients.

Steps for Installing, Configuring, and Deploying KMS Activation

To install and configure KMS hosts, perform the steps provided in the following
sections:

• Install KMS hosts

• Configure KMS hosts
For information and steps to configure KMS publishing to DNS, see the following
sections:

• KMS publishing to DNS overview

• Prerequisites for KMS Publishing to DNS
• Known Issues for KMS Publishing to DNS
• Steps for Configuring KMS Publishing to DNS

To manually create a KMS SRV record in DNS, see the following sections:
• Manually Create KMS SRV Records in DNS
• Guidance for creating KMS SRV Records on Non-Microsoft DNS hosts

To install, configure, deploy, and activate KMS clients, perform the steps in the
following sections:

• Install KMS clients

• Configure KMS clients
• Deploy KMS clients
• Activate KMS clients manually
• Convert a client using MAK Activation to use KMS Activation
•
KMS Hosts
This section includes procedures for installing and configuring computers as KMS
hosts.

Installing KMS Hosts

Install and activate a computer as a KMS host using the following procedure.

To install KMS hosts for KMS activation

1. Choose and install the desired volume licensed media. No product key is required during
setup.
2. Start the computer, log on and launch an elevated Command Prompt.
3. Install your KMS key. Do not use the Windows Change Product Key wizard to install a
KMS key. Run the following script:
cscript C:\windows\system32\slmgr.vbs /ipk <KMS Key>
4. Activate the KMS host with Microsoft, either using online activation or telephone
activation:
- For online activation (You must be able to access the Internet from the computer), run
the following script:
cscript C:\windows\system32\slmgr.vbs /ato
- For telephone activation (if you do not have access to the Internet), run the following
command and follow the on-screen instructions:
slui.exe 4
The KMS host is now ready to be used by KMS clients for activation. Additional
configuration is optional and will usually not be required.

Notes:

1. You should always use the KMS key from the highest product group your
organization has licensed. This way, you are assured that all licensed KMS clients in
your organization can be activated. You do not need multiple KMS hosts to support
multiple product groups on your network.
2. If you install KMS on a virtual machine host which is then later moved to a different
physical location, the operating system will detect that the underlying hardware has
changed and the KMS host will require reactivation with Microsoft.
3. If you want to use a Windows Server 2003 computer (with Service Pack 1 [SP1] or
later) as the KMS host computer, download KMS from the Microsoft Download Center
at http://go.microsoft.com/fwlink/?LinkID=82964 for x86 systems or
http://go.microsoft.com/fwlink/?LinkId=83041 for x64 systems.
4. You can verify the KMS host is set up correctly by observing the KMS count and by
reviewing the KMS event log entries. Run slmgr.vbs /dli on the KMS host to obtain
the current KMS count. The KMS Event Log 12290 entries will show the name of the
computer and the time-stamp for each activation request.
If you have an existing volume license and then purchase a new volume license for
a Windows edition in a higher product group, you should upgrade your existing KMS
hosts.
For a KMS host with Internet access, run the following from an elevated Command
Prompt – waiting for each step to complete before moving on to the next.

Slmgr.vbs /ipk <New_KMS_Key>

Slmgr.vbs /ato

For a KMS host which does not have Internet access, you will have to phone activate
the KMS. Run the following from an elevated command prompt and follow the on-
screen prompts to phone activate:

Slmgr.vbs /ipk <New_KMS_Key>

Slui 4

NOTE Installing a new KMS key will erase the KMS cache. The KMS n-count will need
to be rebuilt. This should happen automatically as clients regularly reconnect to
renew their activations.

It is a good idea to stop and restart the licensing service after applying a new key.
For Windows Vista and Windows Server 2008 KMS hosts, the licensing service is
named slsvc.exe. On KMS for Windows Server 2003, the licensing service is named
sppsvc.exe.

Configuring KMS Hosts

All KMS configurations are optional and should only be used if required for the local
environment. All configuration options require that you launch an elevated
command prompt and use the built-in script “slmgr.vbs”.

Configure Optional KMS Host Settings

1. Configure the TCP communications port that the KMS host will use by running:
cscript C:\windows\system32\slmgr.vbs /sprt <port>
KMS clients that use direct registration have to be configured accordingly. Clients that
use auto-discovery will automatically receive and use the custom port when they select a
KMS host. Remember to restart the slsvc.exe service or restart the computer if you want
this to take effect immediately.
2. Disable automatic DNS publishing by using the following scripts:
cscript C:\windows\system32\slmgr.vbs /cdns
Re-enable automatic DNS publishing using the following script:
cscript C:\windows\system32\slmgr.vbs /sdns
3. Set the KMS host to process using lowered scheduler priority:
cscript C:\windows\system32\slmgr.vbs /cpri
4. Revert KMS processing to Normal priority:
cscript C:\windows\system32\slmgr.vbs /spri
5. Change the activation interval that clients will use if not activated (default is 120
minutes). Run the script:
Configure Optional KMS Host Settings
cscript C:\windows\system32\slmgr.vbs /sai <ActivationInterval>
6. Change the activation renewal interval. This defines the frequency that activated KMS
clients reconnect to the KMS host in minutes. The default is seven days).
Run the following script:
cscript C:\windows\system32\slmgr.vbs /sri <RenewalInterval>
Note You must restart the KMS service (or the computer) for changes to take effect. To
restart the KMS service, you can use the Services snap-in or run this command at an
elevated command prompt (answer Y when prompted):
net stop slsvc && net start slsvc

KMS Publishing to DNS

KMS publishing allows clients to automatically locate a KMS (called auto-discovery)
with zero client configuration. Clients automatically use DNS auto-discovery if they
have not been registered to use a specific KMS.

KMS Publishing to DNS Overview

KMS hosts automatically attempt to publish their existence in SRV Resource Records
as defined in RFC2782 (http://www.ietf.org/rfc/rfc2782.txt). SRV records support the
following fields:

1. Host Name – this corresponds to the FQDN of the KMS host

2. Priority – not used. Defaults to 0
3. Weight – not used. Defaults to 0
4. Port – this defaults to 1688

KMS publishes its host name and the configured TCP port in the SRV record. 1 record
exists per KMS host in the domain.
Clients query DNS and retrieve a list of KMS SRV records. They select a KMS host
randomly from this list and then attempt to use this information to connect to the
KMS. If the connection is successful, the KMS location is cached for subsequent
connections. Otherwise, the process repeats until the client is able to connect to a
KMS or until the list is exhausted.
Advantages of using SRV records include:

• Does not require the use of Active Directory

• Is not limited to Active Directory forests
• The KMS host’s TCP port number is configurable and will propagate to the KMS client
without user or administrative intervention.
DNS publishing is enabled by default. When a computer is configured as a KMS host,
it attempts to self-publish its location and port in the DNS domain defined by its
Primary DNS Suffix. Publishing can be disabled using slmgr.vbs or by setting the
registry value DisableDnsPublishing. This is described in Disable DNS Publishing.
System administrators can also create a list of DNS domains that a KMS host will
use to automatically publish their SRV records, see Automatically publish KMS in
multiple DNS domains.
For KMS publishing to work, the DNS system must support Dynamic updates
(DDNS). It may also be necessary to configure DNS security so that KMS hosts have
the required permissions to create or update these records. For more information
about DDNS, see http://www.ietf.org/rfc/rfc2136.txt. Microsoft’s implementation of
DNS supports DDNS, starting with Windows 2000, as do versions of BIND8.x and
later.
A KMS host will automatically update its SRV entries if the software licensing service
(slsvc.exe) detects that the computer name or TCP port has changed during service
startup. The KMS host will also update its DNS SRV records once each day in order
to ensure that they are not automatically removed (scavenged) by the DNS system.
The SRV record update interval is not configurable.
If KMS is uninstalled, DNS records are not automatically removed by KMS. Run slmgr
/cdns to disable DNS publishing and then manually delete the appropriate KMS SRV
resource records from DNS. Alternatively, if DNS Scavenging is enabled on the DNS
server, the SRV records will eventually be removed after the server determines they
have become stale. This is highly configurable and may take a couple of weeks.
Contact your DNS administrator if you are unsure of the record scavenging settings
within your DNS.
Not all DNS systems or network environments support SRV publishing. Additionally,
some organizations’ policies may prevent DNS publishing. In these cases, it is
necessary to create or copy the SRV record manually. This can readily be
accomplished from a command line or by scripting.
KMS client auto-discovery does not require Microsoft’s implementation of DNS.
Auto-discovery will work with any standards-compliant DNS system that supports
SRV resource records. However, the KMS host will need write permission to create
and update the SRV, A, and AAAA resource records in a Dynamic DNS system, or the
KMS resource records will have to be manually entered.

Prerequisites for KMS Publishing to DNS

To complete this task, ensure that you meet the following requirements:

• The following procedures assume the use of Active Directory and Microsoft DNS.
Configuring non-Microsoft DNS services like BIND is outside the scope of this guide.
However, a section has been included to detail the required content of a KMS SRV
record. See Guidance for creating KMS SRV Records on Non-Microsoft DNS hosts for
more information.
• Clients that will need access to KMS hosts across another domain or forest are able to do
so.
• If you are using Active Directory and Microsoft’s DNS server, you must be a member of
the Domain Administrators group, have delegated privileges, or have arranged for the
 procedures to be carried out by the authority responsible for DNS in your organization.
Equivalent requirements apply for non-Microsoft DNS services.

Known Issues for KMS Publishing to DNS

KMS publishing has been successfully tested with BIND 9.x. Any server that
supports DDNS and SRV resource records per the RFCs should support KMS
publishing. Any deployment utilizing a non-Microsoft DNS should be fully tested
before use in production.

Steps for Configuring KMS Publishing to DNS

To configure DNS in Active Directory, complete the following tasks:

• Configure security for KMS publishing to DNS

• Automatically publish KMS in multiple domains

Configure Security for KMS publishing to DNS

1. If you are using only one KMS host, you may not need to configure any permissions in
DNS. The default behavior is to allow a computer to create an SRV record and then
update it. However, if you have more than one KMS host (the usual case), the other
hosts will be unable to update the SRV record unless SRV default permissions are
changed.
This procedure is an example that has been implemented in the Microsoft environment.
It is not the only way to achieve the desired result.
Detailed steps for each of the tasks are not provided – these may differ from one
organization to another.
2. A domain administrator can delegate the ability to carry out the following steps to others
in the organization. To do so, create a security group in Active Directory, give that group
permission to change the SRV records, and add the delegates.
Consider this example:
1. Create a group called Key Management Service Administrators.
2. Delegate permissions to manage the DNS SRV privileges to this security group.
3. Add the appropriate user accounts to this group.
The remainder of this procedure assumes that either a domain administrator or delegate
is performing the steps.
3. Create a global security group in Active Directory that will be used for your KMS hosts
(ex: Key Management Service Group).
4. Add each of your KMS hosts to this group. They must all be joined to the same domain.
5. Once the first KMS host is created, it will create the original SRV record.
6. If the first computer is unable to create the SRV record, it may be because your
organization has changed the default permissions. In this case, you will need to create
the SRV record manually with the name _VLMCS._TCP (service name and protocol) for
the domain. Set the time-to-live (TTL to 60 minutes).
7. Set the permissions for the SRV group to allow updates by members of the global
security group.
Automatically Publish KMS in Multiple DNS Domains
8. On the KMS host, create or navigate to the following registry key using regedit.exe.
Navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL
Value Name: DnsDomainPublishList
Type: REG_MULTI_SZ
Value Data: Enter each DNS Domain that KMS should publish to on separate lines. Be
certain to list all zones that need the KMS SRV records. Setting this registry value
suspends the KMS host’s default behavior of publishing in the domain specified by the
Primary DNS Suffix.
Important note: This section contains information about how to modify the registry.
Make sure to back up the registry before you modify it. Make sure that you know how to
restore the registry if a problem occurs. For more information about how to back up,
restore, and modify the registry, click the following article number to view the article in
the Microsoft Knowledge Base: 256986 (http://support.microsoft.com/kb/256986/)
Description of the Microsoft Windows registry.
It is useful to export the registry key for documentation or to import into additional KMS
hosts.
Restart the Software Licensing Service. The SRV records should be created immediately.
The application event log will contain a 12294 event for each successfully published
domain and a 12293 event for each unsuccessful domain publishing attempt.
For the 12293 event, the failure code can be diagnosed by running the following:
slui.exe 0x2a 0x<error code>
See “Mapping error codes to text messages” in the Volume Activation 2.0 Operations
Guide for an example.

Manually Create KMS SRV Records in DNS

In some DNS environments, security policies and other factors may require that DNS
records are manually created. Follow these steps to create a proper KMS SRV record
in Microsoft DNS.
Manually created SRV records can coexist with KMS-published SRV records in other
domains. However, care should be taken to prevent conflicts and to ensure that all
records are maintained. A disjointed structure like that could be difficult to maintain,
and would not be recommended if other solutions could be found.
For environments in which DDNS is not supported, it is recommended that DNS
auto-publishing be disabled on all KMS hosts. This will prevent the Event logs from
collecting Failed DNS Publishing events.
Manually Create a KMS SRV record in Microsoft DNS Server
9. Open the DNS Manager
10. Select the DNS server the SRV will be created in
11. Expand “Forward Lookup Zones”
12. Expand the first domain which will contain the SRV resource record
13. Right-click the Domain and choose “Other New Records”
14. Scroll down and select “Service Location (SRV)”
15. Click [Create Record]
16. Enter the following information, typing over any existing text
Service: _VLMCS
Protocol: _TCP
Port number*: 1688
Host offering the service**: <FQDN_of_KMS_Host>
Click [OK], then [Done]
Repeat steps 4-9 for any other domains which will require the KMS SRV record.

* Port 1688 is the default. If the KMS host is configured to use a custom port, input that
port number instead.
** The Host Name field requires the FQDN of the KMS host. For example:
KMS01.contoso.com

If a custom port for the KMS is used and the SRV records are manually maintained,
be certain to change the port data in the SRV record to match the custom port
configured on the KMS. Otherwise, the KMS clients will not be able to communicate
with the KMS host.

Guidance for creating KMS SRV Records on Non-Microsoft DNS hosts

KMS activation uses SRV resource records to store and communicate KMS location
and configuration information through DNS. Any DNS server that supports SRV
records (per RFC 2782) and dynamic updates (per RFC 2136) will support KMS client
auto-discovery and KMS SRV RR publishing. Berkeley Internet Domain Name (BIND)
versions 8.x and 9.x support both SRV records and DDNS.

NOTE DNSSEC, ACLs, and any other security mechanisms must be configured to
allow writing of SRV and A resource records to the necessary DNS zones if DDNS is
to be implemented. Alternatively, a static SRV RR can be created in any zone where
it is needed.

If DDNS is not supported, an administrator can manually create the necessary SRV
record for a KMS host. It should contain the following information:
Name=_vlmcs._TCP

Type=SRV

Priority = 0

Weight = 0

Port = 1688

Hostname = <FQDN or A-Name of the KMS host>

In a sample BIND 9.x zone file, a proper KMS SRV RR looks like this:

_vlmcs._tcp SRV 0 0 1688 kms01.contoso.com

Notes:

• Priority and Weight are not used by the KMS service and are ignored by the KMS
client. However, they do need to be included in the zone file.
• Port 1688 is the default port, but it can be changed on the KMS and KMS client
computers. For more information, see Configure Optional KMS Host Settings.
If a custom port for the KMS is used and the SRV records are manually maintained,
be certain to change the port data in the SRV record to match the custom port
configured on the KMS. Otherwise, the KMS clients will not be able to communicate
with the KMS host.

To configure a BIND 9.x DNS server to support KMS auto-publishing, the BIND server
must be set up to enable resource record updates from the KMS host. For example,
add the following line to the zone definition in named.conf (or named.conf.local):

allow-update { any; };

NOTE An allow-update statement can also be added in named.conf.options to

allow DDNS for all zones hosted on the server for which this server is authoritative.
The administrator should consider and understand the ramifications of any changes
to DNS security.

KMS Clients
This section includes procedures for installing and configuring computers as KMS
clients.

Install KMS clients

Install KMS clients using this procedure.

Install KMS clients for KMS activation

17. Choose and install the desired volume licensed media. No product key is required during
setup.
Install KMS clients for KMS activation
18. If you use DNS auto-discovery, no further configuration is required.
19. For domain-joined computers, the DNS auto-discovery of KMS requires that the DNS
zone corresponding to either the primary DNS suffix of the computer or the Active
Directory DNS domain contain the SRV resource record for a KMS.
20. For workgroup computers, DNS auto-discovery of KMS requires that the DNS zone
corresponding to either the primary DNS suffix of the computer or the DNS domain
name assigned by DHCP (option 15 per RFC 2132) contain the SRV resource record for a
KMS.

Configuring KMS Clients

Configure KMS clients using this procedure.

Configure KMS clients for KMS activation

21. Configuration is only required for KMS clients that will use direct registration with their
KMS host. Direct registration overrides DNS auto-discovery. Configuration of volume
clients can be scripted, run remotely, or applied via Group Policy, assuming that:
• The required services are enabled on the computer.
• The port used for KMS communications is not blocked by firewalls or routers.
• Access permissions are set correctly. (All methods that are implemented in WMI or
through the registry require Administrator privileges unless standard user activation
has been enabled).
On the KMS client, register the KMS host's fully qualified domain name (FQDN), for example
kms03.site5.contoso.com and, optionally, the TCP port used to communicate with KMS (if
you are not using the default):
cscript \windows\system32\slmgr.vbs /skms <KMS_FQDN>[:<port>]
Optionally, the IP address or NetBIOS ID (name of the computer) can be used instead of the
FQDN.
cscript \windows\system32\slmgr.vbs /skms <IPv4 Address><:port>
cscript \windows\system32\slmgr.vbs /skms <IPv6 Address><:port>
cscript \windows\system32\slmgr.vbs /skms <MachineName><:port>
To re-enable auto-discovery for a client computer that was registered to use a specific KMS,
run the following built-in script:
cscript \windows\system32\slmgr.vbs /ckms

If a client computer mostly connects through virtual private network (VPN), and is past
the activation or renewal period, it will attempt to connect to a KMS host five minutes
after establishing a VPN connection. You can force the computer to refresh its activation
by adjusting the Renewal Interval at the KMS; the change will be propagated to all KMS
clients the next time the client renews its activation.

Deploying KMS Clients

Deploy KMS clients using this procedure.
Deploy KMS clients for KMS activation
22. Build and completely configure the Reference system.
23. Run sysprep /generalize immediately prior to shutting down your deployment reference
computer. This resets the activation timer, security identifier, and other important
parameters. Resetting the activation timer prevents the image’s Grace Period from
expiring before the image is deployed.
Note that running Sysprep does not remove the installed product key and you will not be
prompted for a new key during mini-setup.
or
If sysprep causes changes that complicate the deployment, run the following script:
cscript \windows\system32\slmgr.vbs /rearm
This resets the activation timer but makes no other changes to the system. Both
Sysprep /Generalize and slmgr /rearm can only reset the activation timer 3 times.
However, to allow for progressive changes, a KMS-activated client can be rearm’d more
than 3 times. Note that you cannot run slmgr.vbs in Safe Mode.
24. Use an imaging technology that is compatible with Windows Vista/Windows Server 2008
to capture the resulting image.
25. Deploy using standard techniques such as disk duplication or WDS.

Activating a KMS Client Manually for KMS Activation

You can activate a computer that uses KMS activation with the following procedures.
Note that KMS clients attempt to activate automatically at preset intervals. However
you may wish to be sure that some clients (mobile clients, for instance) are
activated before distributing them.

• Using the Windows Interface

• Using a script

Activate a KMS client manually using the Windows interface

26. Open System Properties in Control Panel.
If you are prompted for permission, click Allow.
27. Click “Click here to activate Windows now.”
This launches the activation wizard. If you are prompted for permission, click Allow.
If your computer has access to the network and a KMS, Windows reports that activation
was successful.
If activation fails, the wizard will report the failure. For KMS activation of Windows Vista to
occur, the KMS n-count must equal or exceed 25. Windows Server 2008 requires a KMS n-
count of 5. Until that count is reached, activation will fail with error code 0xC004F038. To
troubleshoot other errors, run SLUI per the instructions in the error message, or consult
“Troubleshooting by Error Code” in the Volume Activation 2.0 Operations Guide.
Activate a KMS client manually using a script
28. Launch an elevated Command Prompt
29. Run the following script to activate:
cscript \windows\system32\slmgr.vbs /ato
The script reports activation success or failure, along with a result code.
If activation fails, the wizard will report the failure. For KMS activation of Windows Vista to
occur, the KMS n-count must equal or exceed 25. Windows Server 2008 requires a KMS n-
count of 5. Until that count is reached, activation will fail with error code 0xC004F038. To
troubleshoot other errors, run SLUI per the instructions in the error message, or consult the
Troubleshooting by Error Code section in the Volume Activation 2.0 Operations Guide.

Converting a Client Computer using MAK Activation to use KMS Activation

Volume Activation 2.0 is very flexible. A volume client can be changed from MAK to
KMS activation and back by simply installing the proper key. The Volume Activation
Management Tool can be used to convert computers to MAK activation.

Convert a client computer from MAK Activation into a KMS client

1. Ensure that the computer is connected to the network and can access a KMS host.
2. Obtain the 5x5 Setup key from the file sources\pid.txt on the installation media
(Windows Vista editions only), or from the list in Table 2.
3. Launch an elevated Command Prompt.
4. Run the following script to install the setup key (this automatically removes the MAK):
cscript \windows\system32\slmgr.vbs /ipk <setup key>
Be sure to include the dash between each set of five characters.
5. Run the following script to activate the computer:
cscript \windows\system32\slmgr.vbs /ato
The script reports success or failure, along with a result code.
Important Note It is important that Windows be activated before the computer is rebooted
if more than 30 days have elapsed since initial installation. If the original Out of Box Grace
will have expired, the computer will boot into Reduced Functionality Mode if it’s not activated
with the new key.

Configure Windows Server Hyper-V and virtual machines

Virtualization Scenarios in Windows Server 2008

What Is Virtualization?

Virtualization technology enables a computer to run multiple operating systems

simultaneously. With virtualization, you can install multiple virtualized operating
systems on the host computer. Every virtualized operating system runs in isolation
from the other operating systems. Each virtual operating system is a full operating
system with applications.

In earlier versions of Windows Server, Virtual Server and Virtual PC were used for
virtualization. In a computer running Windows Server 2008, virtualization requires
64-bit hardware and the 64-bit version of the operating system. The 64-bit
environment provides additional processing power and a large addressable memory
space. Windows Server 2008 provides a powerful platform to run multiple
virtualized operating systems that use up to eight processors.

You can run legacy or non-Microsoft operating systems in the virtualized

environment of a Windows Server 2008 computer. You can deploy virtualization in
the following scenarios:

• Production server consolidation. To improve hardware utilization by running

multiple services on a single physical computer
• Business continuity management. To provide high availability and disaster
recovery by ensuring quick recovery of virtual servers in the event of a
hardware failure
• Dynamic datacenter. To re-provision servers to hardware that is not working
at capacity to distribute workloads
• Test and development. To rapidly duplicate a production environment and an
ideal test environment

TechNet Webcast: Virtualization and Windows Server 2008 (Level 300)

Overview of the Production Server Consolidation Scenario

One of the important scenarios for virtualization in Windows Server 2008 is server
consolidation. In the server consolidation scenario, organizations can use
virtualization to reduce the number of physical servers that they need to deploy,
while maintaining service levels or supporting legacy operating systems and
applications.

The production server consolidation scenario enables the physical consolidation of

servers. Quite frequently, organizations deploy Windows Server servers that run
important network services such as DHCP or DNS. These services often require low
hardware utilization, but organizations may not want to combine all the services on
a single computer. By using virtualization, you can improve hardware utilization by
deploying several of these servers as virtualized operating systems onto fewer
highly scalable and reliable enterprise class servers.

When you reduce the number of servers in the datacenter, you can significantly
decrease the cost of running the servers. For example, you can reduce electrical
costs for cooling and costs for server power consumption and may be able to reduce
the overall datacenter physical footprint. By moving the servers on a standardized
platform rather than having a variety of systems to support them, you can reduce
operational costs. Server management becomes easier because you need to
manage fewer servers.
Windows Server 2008 provides additional features to enhance the management of
multiple servers running virtualization. For example, you can use group policies to
apply consistent policies to all servers hosting virtualization in the domain. Windows
Server 2008 provides health-monitoring tools that can be used to monitor the health
and performance of the Windows Virtualization servers.

Overview of the Business Continuity Management Scenario

An important scenario for virtualization in Windows Server 2008 is business

continuity management. Business continuity management is the ability of a
business to minimize scheduled or unscheduled downtime by ensuring that the
network servers and services are highly available.

Business continuity includes disaster recovery, business recovery, business

resumption, and contingency planning. The goal of IT business continuity planning is
to ensure that network services are always available when required and to minimize
the unscheduled downtimes for network services. Because of the critical
functionality provided by network services, any disruption in network services can
result in a significant reduction in business productivity. Many global organizations
also require that network services should be available 24 hours a day and 7 days a
week.

Virtualization in Windows Server 2008 provides significant benefits for business

continuity planning. By implementing virtualization, you can deploy all network
servers and services on a server hardware that has fully redundant components
such as power supplies, network interface cards, and storage. You can also deploy
virtualization on clustered host computers, or deploy services on clustered
virtualized operating systems. This will decrease the chances of a hardware failure
resulting in a service disruption.

Virtualization also provides virtual machine migration, which means that you can
move virtual machines from one Windows virtualization server to another. If one
host computer needs to be taken offline for maintenance, you can move the
virtualized operating system to another host without disrupting service availability.
You can also enable automatic failover of datacenter operations to a recovery site.
This gives you the ability to replicate, automatically fail over, and resume
operations in a recovery site with minimal disruption to network services.

A critical component for maintaining business continuity is ongoing monitoring. By

using virtualization, you will have fewer servers that you need to monitor.
Virtualization provides monitoring tools and critical failure notification that enable
virtualization to recognize and respond appropriately to critical notifications.

Overview of the Dynamic Datacenter Scenario

If you deploy Windows Server 2008 servers without virtualization, it can be very
difficult to manage changes in the IT environment. If the demand for a network
service increases and resources on the server providing the service are over-
utilized, it can be difficult to increase the server resources to meet the increased
demand. If the demand for a network service decreases and the server hosting the
network service is under-utilized, it is not profitable to invest on such server
resources. The goal of the dynamic datacenter is to easily and rapidly reallocate
server resources among various servers on the network to ensure the optimal use of
server hardware, while providing highly available network services.

Virtualization can help you to meet the goals of the dynamic datacenter by ensuring
that all server resources are appropriately sized and used. If the demand for a
network service increases, you can dedicate more hardware resources from the host
computer to the virtual machine. In this manner, you can maximize hardware
utilization.

Virtualization can also reduce IT complexity and management in the dynamic data
center. Virtualization decouples workload from server hardware and makes it easy
to rapidly provision workload. Because the virtual machine is not dependant on a
particular host or host configuration, you can easily move the virtual machine to
another host, or modify the hardware dedicated to the virtual machine on the
current host, depending on your organizational requirements.

With virtualization, you can address resource requirements by providing additional

hardware resources for a specific virtual server. For example, you can dynamically
add physical resources such as CPUs or memory to a specific virtual server.

Overview of the Test and Development Scenario

One of the most often used scenarios for virtualization is the test and development
scenario. Many organizations have implemented virtualization technologies in their
test environment to reduce the hardware requirements for the test lab.

Virtualization makes it easy to provide a test and development environment. If you

have multiple users working on the same project, you can provide a test
environment for each user that is identical to the other test environments. You can
also deploy multiple test computers on a single host computer, thus reducing the
hardware requirements for the test lab.

Virtualization can also streamline test and development efforts. For example,
virtualization can significantly reduce the time required to provision test and
development environments. By using virtualization, you can rapidly duplicate a
production environment to ensure the validity of any tests that you perform.

Virtualization also makes it easy to run multiple test scenarios. Because you can
save changes to the virtual machine at any point during the testing process, you
can easily duplicate test scenarios for multiple passes. You can also run through
different test scenarios on the same virtual machine without rebuilding the test lab
environment.
Hardware Support for Virtualization

In Windows Server 2008, hardware support, such as 32-bit (x86) and 64-bit (x64)
child partitions, symmetric multiprocessing (SMP) (2/4/8) core virtual machines
(VM), and large memory support (>32GB) within VMs, is available for virtualization.

To install virtualization, the host server must meet the following requirements:

• 64-bit hardware. You can install virtualization only on servers running 64-bit
hardware. Virtualization supports both Intel and AMD processors.
• Hardware assisted virtualization. You must enable hardware assisted
virtualization on the host computer. To enable this feature, you must
configure Intel Virtualization Technology or AMD Pacifica.
• Hardware enabled Data Execution Prevention (DEP). You must configure DEP
on the host computer. To configure this, use the AMD no-execute (NX) bit or
the Intel execute disable (XD) features.
• Longhorn Server x64 Enterprise edition or Data Center editions. You must
install a 64-bit version of Windows Server 2008 on the server. Windows
Server 2008 installs in the parent partition. You can install the full version of
Windows Server 2008, or you can install Server Core.

Note

You must install the 64-bit version of Windows Server 2008 on the host computer,
but you can run both 64-bit and 32-bit versions of Windows Server 2008 as virtual
operating systems.

Virtualization Features in Windows Server 2008

Windows Server virtualization uses the powerful enhancements of processors and

provides users with a scalable, reliable, secure, and highly available virtualization
platform.

Windows Server 2008 has the following virtualization features:

• Windows Server 2008 Server Core as the parent operating system. Server
Core is a version of Windows Server 2008 that does not provide a graphical
user interface (GUI) to manage the server. If you use Server Core as the
parent operating system, you reduce the attack surface on the host computer
and the resources required to run the host computer.
• Group policy integration. You can use group policies to publish configuration
changes to Windows Virtualization servers on a domain. The group policy
settings can be applied to the parent operating system or the virtual
operating system.
• Non-Microsoft guest operating system support. You can run earlier versions of
Windows and non-Microsoft operating systems as virtual operating systems.
• Dynamic and secure networking. You can dynamically add or remove virtual
network interface cards and take advantage of underlying virtual local area
network (VLAN) security when configuring the network connections for virtual
 machines. You can also configure features, such as Network Address
Translation (NAT), firewall, or quarantine settings, for virtual machines.
• Virtual machine snapshots. You can dynamically create multiple checkpoints
of the current state for any virtual machine, and revert to any previous
checkpoint. This can be useful during testing.
• Scripting interface. Virtualization supports Windows PowerShell, a rich
scripting interface that can be used to monitor and control the virtual
machine environment.
• Live virtual machine migration. You can move virtual machines, which are
running, from one Windows Virtualization server to another without disrupting
the operating system availability.

Features of System Center Virtual Machine Manager

Microsoft System Center Virtual Machine Manager provides a comprehensive

management solution for the virtualized data center that enables increased physical
server utilization and centralized management of virtual machine infrastructure.

System Center Virtual Machine Manager provides the following benefits:

• Manages server consolidation. When you deploy a virtual machine, the Virtual
Machine Manager analyzes performance data and resource requirements for
both the workload and the host. This console allows you to fine-tune
placement algorithms to get the best-matched deployment
recommendations. You can use the historical performance data to understand
the actual resource requirements of the workload. Then, check the minimum
CPU, disk, RAM, and network capacity requirements in the virtual machine
configuration. After determining the virtual machine requirements, you have
to gather the performance data for candidate virtual machine hosts. Finally,
you have to factor in the pre-selected business rules to optimize placement
recommendations, either for resource maximization or for load balancing, and
to weigh the importance of different resource types for the workload.
• Manages Physical-to-Virtual (P2V) conversions. Virtual Machine Manager
improves the Physical-to-Virtual user experience by integrating the
conversion process and by using the Volume Shadow Copy Service (VSS) of
Windows Server 2003. VSS facilitates you to create the virtual machine faster
and without having to interrupt the physical source server.
• Provisions new machines. Virtual Machine Manager enables quick
provisioning of new virtual machines. Using the wizard-based user interface,
you can rapidly deploy virtual machines from approved templates. Virtual
Machine Manager also allows you to manage and reallocate existing virtual
machines between virtual machine hosts, giving you an integrated and
holistic view of their virtual and physical infrastructure.
• Offers Library for managing virtual machines. The library organizes not only
stored virtual machines but also the various virtual machine building blocks
such as virtual hard disks, CD and DVD media, ISO images, post deployment
customization scripts, hardware configurations and templates.
• Offers Familiar administration interface. The Virtual Machine Manager
Administrator console is built on the System Center Operations Manager 2007
 user interface. Therefore, you can become proficient in managing your virtual
machines. You can do a comprehensive health monitoring of hosts, virtual
machines, and library servers using the Virtual Machine Manager
components. These components are provided through the Virtualization
Management Pack in Operations Manager 2007.

Configure high availability

TechNet Webcast: Achieving High Availability with Windows Server 2008

Clustering (Level 200)

What Is Failover Clustering?

A cluster is a set of independent computers that work together to increase the

availability of services and applications. The clustered servers, or nodes, are
connected through a network connection as well as by failover. If one of the nodes
fails, another node begins to provide service through a process known as failover.

New Cluster Validation Tool

You can use this tool to verify if the computers, storage, and network
configuration meet the requirements for setting up a cluster.

Improved Setup and Migration

Administrators can use the failover cluster in Windows Server 2008 to

validate configuration before cluster installation. The Cluster Setup Wizard is
simplified to help administrators to set up a cluster in one step. Because
cluster setup is fully scriptable, administrators can automate cluster
deployment. Cluster settings is captured from one cluster and then applied to
another cluster.

Simplified Configuration Interface

The interface for administering a cluster is simplified in Windows Server

2008. This makes it easier for the administrator to perform tasks such as
making a shared folder highly available. Administrators can troubleshoot a
cluster by using Event Tracing to easily gather, manage, and report
information about the sequence of events that occurred on the cluster.

Improved Networking and Security

Administrators can use failover cluster in Windows Server 2008 to improve

network security and performance. Failover clusters improve the method in
which the cluster communicates with storage. This improves the performance
of a storage area network (SAN) or Direct Attached Storage (DAS).
 Because the failover cluster offers configuration options, quorum resource
need not 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. Failover clusters also
support globally unique identifier (GUID) partition table disks that have
volumes up to 18 exabytes in size and up to 128 partitions per disk. This
provides high availability of the disks.

Process for Validating the Server Environment for Clustering

You can use the Validate a Configuration Wizard to run tests to confirm that the
hardware and the hardware settings are compatible with failover clustering. You can
run a complete set of configuration tests, or you can select only the tests that you
want to run.

You can run the tests on a set of servers and storage devices before or after you
have configured them as a failover cluster. However, the failover cluster feature
must be installed on all servers that are included in the tests. You can use the
Validate a Configuration Wizard to run the System Configuration test, Inventory
Tasks test, Network tests, and Storage test.

System Configuration

This test validates that the system software and configuration settings are
compatible across the servers.

The System Configuration Tests include a variety of tests such as:

• Validate Active Directory Configuration. This test validates that each

tested server is in the same domain and organizational units. This test
also validates that all computers are domain controllers or member-
servers.
• Validate Same Processor Architecture. All servers in a failover cluster
must either be 32-bit systems or 64-bit systems.
• Validate All Signed Drivers. This test validates that all tested servers
contain only signed drivers.
• Validate Software Update and Service Pack Levels. This test validates
that all tested servers have the same updates and service packs.

Inventory Task

This test provides an inventory of the hardware, software, and network

settings on the servers, along with the information about the storage.
 Network

This test validates that the network is set up correctly for clustering. This test
includes verifying that there are at least two network adapters for each
server and verifying that each network adapter has a different IP address.
The test also validates that the computers can communicate on all network
connections.

Storage
This test validates that the storage, which is configured for failover cluster,
supports the required functions of the cluster. The tests validate that the
computers can access the shared storage required for the quorum disk.

Requirements for Installing Failover Clustering

Before installing a two-node failover cluster in Windows Server 2008, you need to
ensure that the server, network, storage, and infrastructure fulfills certain
requirements.

Server

You require two identical failover cluster computers that are compatible with
Windows Server 2008. The servers should have identical components,
including identical processors of the same brand, model, and version.

The servers must run Windows Server 2008 Enterprise edition and have the
same hardware version, such as 32-bit, x64, or Itanium. The servers should
also have the same software updates and service packs.

Network

You need to have at least two network adapters dedicated to network

communication in each clustered server. The network adapter must be
independent of the network adapter that is used for Internet Small Computer
System Interface (iSCSI).

Storage

You need to use identical mass-storage device controllers that are dedicated
to the cluster storage. This is required if you are using Serial Attached Small
Computer Systems Interface (SCSI) or Fibre Channel. You also need to use
identical firmware version.
 You should have either a network adapter or a host bus adapter that is
dedicated to the cluster storage. This is required if you are using iSCSI. If you
are using a network adapter, it must be dedicated to iSCSI.

The storage should contain at least two separate logical unit numbers (LUNs)
that are configured at the hardware level. One volume functions as the
quorum, and the other quorum contains the files that are being shared to
users.

Infrastructure

The servers in the cluster must use Domain Name System (DNS) for name
resolution. You can also use the DNS dynamic update protocol.

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
as member server or domain controller. However, it is recommended that you
configure the member server role for the clustered servers.

How to Install Failover Clustering

You need to perform various steps to install failover clustering in Windows Server
2008. First, you need to configure a network on each cluster and connect the server
to the cluster storage. You also need to install the failover cluster on all servers in
the cluster. You can also run the Cluster Validate Wizard and the Create Cluster
Wizard to analyze the nodes and servers in the cluster.

To ensure a successful installation, you must configure the following services on the
clustered server:

Configure the networks on each node in the cluster. To implement a failover cluster,
you must create at least two separate networks for network communication. You
should install two network interface cards in each node and then configure separate
IP addresses on separate networks for each network card.

Connect the servers to the cluster storage. Because failover clustering requires a
shared storage disk, you must configure the servers to enable access to the shared
storage. You must have at least two LUNs available, one for the quorum disk and the
other for storing data.

Install the failover cluster feature on all servers. All servers participating in the
cluster must be running Windows Server 2008 Enterprise edition.
Run the Cluster Validation Wizard. When you run the wizard, analyze all the nodes
that are participating in the cluster. After running the wizard, review the report and
resolve any issues identified by the wizard.

Run the Create Cluster Wizard. When you run the wizard, you must identify the
servers that need to be included in the cluster, the name of the cluster, and any IP
address information that is not automatically supplied by the Domain Host
Configuration Protocol (DHCP) settings.

Configure servers in a cluster. Before the cluster provides any service, you must
install and configure the services on the clustered servers. For example, if you are
creating a file server cluster, you should use the Manage Failover Cluster option in
the Failover Cluster console to add file server roles. You can also use the Manage
Failover Cluster option to configure options such as the name of the clustered file
server and the storage locations used by the file server.

Implementing Network Load Balancing in Windows Server 2008

When you configure NLB between servers, the network load is shared between the
servers. In earlier versions of Windows Server, you could perform NLB by using
Internet Protocol version 4 (IPv4) only. With Windows Server 2008, you can configure
NLB by using Internet Protocol version 6 (IPv6). You can implement NLB between
two Internet Information Services servers. After configuring NLB, you can integrate
it with Terminal Services to connect users to the existing sessions.

By using IPv6, you can configure NLB. NLB enables you to balance loads between IIS
servers. By using Terminal Services session directory service, you can integrate NLB
with Terminal Services to maintain a database on terminal server sessions in load-
balanced farms. Windows Server 2008 supports the following NLB features:

• Support for IPv6. NLB extends full support to IPv6 for all communication.
• Support for NDIS 6.0. The NLB driver has been completely redeveloped to use
the new NDIS 6.0 lightweight filter model. NDIS 6.0 retains backward
compatibility with earlier versions of NDIS. NDIS 6.0 is a simplified driver
model and includes design enhancements such as better driver performance
and scalability.
• Support for IPv6 and dedicated IP address through WMI Enhancements. The
WMI enhancements to the MicrosoftNLB namespace provide support for
IPv6. The classes in the MicrosoftNLB namespace support IPv6 addresses, in
addition to IPv4 addresses.
• Enhanced functionality with ISA Server. By using ISA Server, you can
configure multiple dedicated IP addresses for each NLB node for scenarios
where there are IPv4 and IPv6 clients. To manage traffic, both IPv4 and IPv6
clients need to access a particular ISA Server. ISA Server can also provide
NLB with SYN attack and timer starvation notifications. These scenarios
usually occur when a computer is overloaded or infected by a virus.
• Support for multiple dedicated IP addresses per node. NLB extends full
support for defining more than one dedicated IP address for each node. In
 previous versions of Windows Server, only one dedicated IP address per node
was supported.

Implementing High Availability and Virtualization in Windows Server 2008

By using IPv6, you can configure NLB. NLB enables you to balance loads between IIS
servers. By using Terminal Services session directory service, you can integrate NLB
with Terminal Services to maintain a database on terminal server sessions in load-
balanced farms. Windows Server 2008 supports the following NLB features:

Support for IPv6. NLB extends full support to IPv6 for all communication.

Support for NDIS 6.0. The NLB driver has been completely redeveloped to use the
new NDIS 6.0 lightweight filter model. NDIS 6.0 retains backward compatibility with
earlier versions of NDIS. NDIS 6.0 is a simplified driver model and includes design
enhancements such as better driver performance and scalability.

Support for IPv6 and dedicated IP address through WMI Enhancements. The WMI
enhancements to the MicrosoftNLB namespace provide support for IPv6. The
classes in the MicrosoftNLB namespace support IPv6 addresses, in addition to IPv4
addresses.

Enhanced functionality with ISA Server. By using ISA Server, you can configure
multiple dedicated IP addresses for each NLB node for scenarios where there are
IPv4 and IPv6 clients. To manage traffic, both IPv4 and IPv6 clients need to access a
particular ISA Server. ISA Server can also provide NLB with SYN attack and timer
starvation notifications. These scenarios usually occur when a computer is
overloaded or infected by a virus.

Support for multiple dedicated IP addresses per node. NLB extends full support for
defining more than one dedicated IP address for each node. In previous versions of
Windows Server, only one dedicated IP address per node was supported.

TechNet Virtual Lab: Windows Server 2008 Enterprise Failover Clustering

Lab

Windows Server 2008 Availability and Scalability Article

Configuring Terminal Services

Core Functionality of Terminal Services

Overview of Functionalities of Terminal Services

Terminal Services is a component of the Windows operating system that enables a

client application to connect to the terminal server. By using Terminal Services, a
user can securely access applications or data stored on a remote computer over a
network connection. Terminal Services uses the Remote Desktop Protocol (RDP)
over Transmission Control Protocol/ Internet Protocol (TCP/IP) to transmit user inputs
to the terminal server, and then returns screen refreshes to the client desktop. This
allows centralization and management of applications. By using Terminal Services,
users can share applications and desktops over the network, and administrators can
manage a remote computer from their desktop. Windows Server 2008 has several
enhancements in Terminal Services such as Remote Desktop Connections (RDC) 6.0,
Remote Programs, Additional Functionalities, and Plug and Play Device Redirection
Framework.

RDC 6.0

In Windows Server 2008, the RDC functionality provides the following

features:

• Users can access a single application instead of accessing the entire

desktop.
• Users can set 128-bit encryption by using the RC4 encryption algorithm
and Transport Layer Security (TLS).
• Users can redirect the output of an audio program that is running on a
remote desktop to their local computers.
• Users can access their local files, printers, or ports directly within a
terminal session by using file system redirection, printer redirection,
and port redirection. They can also share the clipboard between the
local computer and the remote computer.
• Users can configure a front-end Internet Information Services server to
accept connections for a back-end Terminal Services server over an
HTTPS connection by using the TS Gateway feature.
• Users can remotely use the Aero Glass Theme and Windows
Presentation Foundation applications by using the RDC feature
supported in Windows Server 2008. The Aero Glass Theme provides a
clean and aesthetic user interface that includes transparencies, live
thumbnails, live icons, and animations. Windows Presentation
Foundation provides a programming model for applications that
separates the UI from the business logic.

Remote Programs

By using the Remote Programs feature in Windows Server 2008, users can
publish only their programs or applications instead of the complete desktop
environment. Remote applications can run in a seamless manner on a client
computer by using an RDC. Users will not experience much of a difference
between an RDC and a local application. You must configure file type
associations on the clients so that the clients can automatically launch a
 terminal server application for certain file types. You can distribute these
remote programs as an MSI package, which is created in the Terminal
Services Console, or through TS Web Access.

Plug and Play Device Redirection Framework

By using RDP, you can make Plug and Play devices available to applications
that are running on remote sessions over Terminal Server in Windows Server
2008. To be eligible for redirection, the device and its driver must meet the
Windows Logo Program requirement.

Additional Functionalities in Terminal Services

Windows Server 2008 supports the following additional functionalities in

Terminal Services:

• TS Web Access. TS Web Access is an interface, which makes the

Terminal Services remote programs available to users from a Web
browser. It is a customizable Web part, which can also be integrated in
an Office SharePoint site.
• TS Gateway. TS Gateway provides access to terminal server sessions
by encapsulating the RDP protocol in the HTTPS protocol. The session
is secure and you need to keep only firewall port 443 open to make a
connection. You can control access through this gateway for each user
or for each workstation.
• Session Directory. Terminal Services Session Directory is a feature that
allows users to easily and automatically reconnect to a disconnected
session in a load-balanced Terminal Server farm. The session directory
contains a list of sessions indexed by user name and server name. By
using the Terminal Services Session Directory, users can reconnect to
the same terminal server from which they got disconnected and users
can resume working in that session. Users can also reconnect to the
session from a different client computer. The Session Directory server
must be a highly available network server that is not a terminal server.
Terminal Services Session Directory is a service role available in
Terminal Services.

What Is Terminal Services Licensing?

Windows Server 2008 provides a license management system known as Terminal

Service Licensing. By using Terminal Services Licensing, terminal servers can obtain
and manage Terminal Services client access licenses for devices and users, who are
connecting to a terminal server. Terminal Services Licensing supports terminal
servers that run Windows Server 2008 as well as computers running the Windows
Server 2003 operating system. By using this system, you can simplify the task of
license management and minimize the under-purchasing or over-purchasing of
licenses for an organization.
Features of Terminal Services Licensing

The following are the features and benefits of Terminal Services Licensing:

• Centralized administration for Terminal Services Client Access Licenses

(TS CALs) and the corresponding tokens.
• License accountability, tracking, and reporting for each device and
each user.
• Simple support for various communication channels and purchase
programs.
• Minimal impact on network and servers.

Components of Terminal Services Licensing

To use Terminal Services Licensing, there must be at least one terminal server
with the following primary components:

• Microsoft Clearinghouse. Microsoft Clearinghouse is a facility that

Microsoft maintains to activate license servers, to issue Client Access
Licenses (CALs) to license servers, to recover CALs, and to reactivate
license servers.
• Terminal Services License Server. A Terminal Services license server is
a computer on which the Terminal Services Licensing Service is
installed. A license server stores all TS CAL tokens that have been
installed for a group of terminal servers and tracks the license tokens
that have been issued. One license server can serve many terminal
servers and must connect to an activated license server. In most large
deployments, the license server is deployed on a separate server,
though it can be a co-resident on the terminal server.
• Terminal Servers. A terminal server provides clients access to
Windows-based applications that run entirely on the server, and
supports multiple client sessions on the server.
• CALs. You must purchase and install the appropriate number of CALs
for each user or each device that connects to the terminal server. CALs
are available on a user-based or device-based licensing. You can decide
on the appropriate licensing mode for your organization.

By using the Terminal Server License Server Activation Wizard, you can
activate a license server to certify the server, and to enable the server to
issue client-access license tokens. A licensing server that has not been
activated can only issue temporary licenses. You must activate the server
within 120 days.

You can activate a license server by using one of the following connection
methods:

• Web. You can use the Web method to activate a license server when
the device running the Terminal Services Licensing management tool
 does not have Internet connectivity, but you have connectivity through
a Web browser from another computer.
• Telephone. You can use the telephone method to talk to a Microsoft
customer service representative to complete the activation or license
installation transactions.
• Internet. You can use the Internet method when you have Internet
connectivity from the device running the Terminal Services Licensing
management tool.

Considerations for Implementing Terminal Services Licensing

Terminal Services Licensing in Windows Server 2008 supports several

functionalities. However, there are a few considerations that you must be aware of
while implementing Terminal Services Licensing.

License Server Migration

You need to go through the process of migration to move an existing license

server setup with CALs to another license server. To move licenses from one
computer to another, you could call Microsoft Clearinghouse and obtain the
keypacks that go with the new server ID. Each activated license server is
unique and is identified with a certificate provided during activation.
Therefore, it is not sufficient to move the licensing database from one
computer to another to complete the migration process. You must also
reinstall licenses on the new computer.

License Server Co-Existence

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.

License Server Discovery

The process of a terminal server automatically locating a license server is

called license server discovery. The license server can be installed on any
server, and not just the domain controllers. The license server discovery
process includes the following steps:

1. The terminal server first checks the local registry for information about
the license server.
2. Next, the terminal server tries discovery through Active Directory by
using Lightweight Data Access Protocol (LDAP) instead of RPC.
3. For domain discovery, the terminal server first tries the local or on-site
domain controllers. If the terminal server fails to locate the on-site
domain controllers, it tries contacting off-site domain controllers.
4. The terminal server stops the discovery process as soon as the first
license server is found.
 User-based License Tracking

When a terminal server receives a request for a user-based license, the

terminal server queries Active Directory for the associated user object and
checks if the object has a license to present. If not, the terminal server
requests a license from a license server. The license server queries Active
Directory and then updates the user account information in Active Directory
with information about the license issuance. To update the user account
information in Active Directory, the license server must be a member of the
Terminal Server License Server group in Active Directory.

Implementing Terminal Services Remote Programs

What Are Terminal Services Remote Programs?

Windows Server “Longhorn” supports Terminal Services Remote Programs, which is

a variation of the standard Terminal Services session. In a standard Terminal Server
environment, you can run applications on a Terminal Server. By using Terminal
Services Remote Programs, you can run applications transparently on a terminal
server. These remote applications run in a normal application window and appear to
be running locally on the user’s computer. You need to be aware of the various
requirements related to installation, clients, and configuration for Terminal Services
Remote Programs.

Server

Before you can post Terminal Services Remote Programs, you must apply the
Terminal Server role to the server that will be hosting the remote programs.
However, the sub-components of terminal services are not required to host
remote programs.

To configure a terminal server for remote programs, you must install the
application for Terminal Services and designate the program to run remotely.
Use the Remote Programs Wizard to designate each application that should
be available for remote execution. You can configure the following properties
for remote applications:

• Make application available through Terminal Services Web Access.

• Allow command line parameters.

Client

To run remote programs, the client computer must be running any one of the
following operating systems:

• Windows Server “Longhorn”.

• Windows Server 2003 with SP1.
 • Windows Vista.
• Windows XP with SP2.

The client computer must be running RDC client 6.0.

Users can access remote programs by:

• Double-clicking a RDP (.rdp) file or program icon that has been created
and distributed by the administrator.
• Double-clicking a file whose extension is associated with a Remote
Program that can be configured by the administrator with an .msi file.
• Accessing a link to the program on a Web site by using Terminal
Services Web Access.

Permissions

A user can access a Remote Program only when the Remote Program exists in
the Allow List of the Terminal Server. The user should also be a member of the
Remote Desktop Users local group and Remote Desktop connections must be
allowed. When the administrator adds the Terminal Services role to a server,
Windows Server “Longhorn” automatically enables the remote desktop
feature.

Remote Program Links

A remote program link can appear either as a shortcut on the desktop, or as

an application on the Start menu. The file that acts as a link to the remote
program uses the .rdp extension. You can either install the RDP file to a user’s
workstation manually, or you can create an MSI file that acts as an installer
for the RDP file. By creating an MSI file, you can use a group policy to
distribute and install the link.

How to Manage Remote Programs

Remote Programs are accessed remotely through Terminal Services and behave as if
they were running on the user's local computer. The following steps will tell you how
to manage Remote Programs:

1. Open Terminal Services Remote Programs.

2. Add the following Remote Programs to the Allow List:
o Paint
o WordPad
3. Use Remote Programs to Create RDP Package.
4. Use Remote Word Pad to Create MSI Package.

Implementing Terminal Services Web Access

How to Implement Terminal Services Web Access
Before installing the Terminal Services Web Access role service, you must install the
Terminal Server role and Internet Information Services 7.0.

After installing Terminal Services Web Access, you can specify the data source that
must be used to populate the list of Remote Programs that appears in the Web Part.
The Web server need not be a terminal server because it can populate the list of
Remote Programs from an external data source.

You can enable users to access the Web page from the Internet by using TS
Gateway to help secure remote connections.

Specifying a Data Source

Terminal Services Web Access can populate the list of Remote Programs,
which appears in the Web Part, from Active Directory or from a single terminal
server.

By default, Terminal Services Web Access populates the list of Remote

Programs from Active Directory. However, by using Simple Publishing
configuration, you can configure the Terminal Services Remote Programs Web
Part to populate its list of Remote Programs from a single terminal server.
When you specify a single terminal server as the data source, the Web Part is
populated by all Remote Programs that are configured for Web access on that
server's Allow List. Moreover, the list of programs is not customized for the
user.

You can configure the data source by using the browser to connect to
http://server_name/ts and by editing the properties of the Web Part.

Client Requirements and Configuration

To connect to Terminal Services Web Access, the client computer must be

running any one of the following operating systems:

• Windows Server 2008 Beta 2.

• Windows Server 2003 with SP1.
• Windows Vista.
• Windows XP with SP2.

Additionally, you must configure the client computer by:

• Running RDC client 6.0 on the client computer.

• Enabling the Terminal Services ActiveX Client control.
• Adding the Terminal Services Web Access server to the Trusted sites
zone or the Local intranet zone in Internet Explorer.

Implementing Terminal Services Gateway

What Is Terminal Services Gateway?

TS Gateway is a role service that provides a secure, encrypted connection between

authorized remote users on the Internet and terminal servers on the corporate
network. Authorized users can access the remote programs from any Internet-
connected device that is running RDC 6.0. TS Gateway uses RDP tunneled over
HTTPS to provide a secure and encrypted connection.

TS Gateway allows the users to connect remotely over the Internet to computers
that are hosted behind firewalls in private networks and across network address
translators (NATs).

TS Gateway also eliminates the need to deploy VPN servers for users to connect
remotely to the corporate network from the Internet. It also provides a security
configuration model for network administrators to control access to specific
resources on the network. You can configure TS Gateway servers and Terminal
Services clients to use NAP to further enhance security.

By using the TS Gateway Management snap-in console, you can configure policies
to define conditions that users must meet to connect to resources on the network.
For example, you can specify the local user groups or Active Directory user groups
that are allowed to connect to resources on the corporate network. You can also
specify whether the client computers must be members of Active Directory domains
and whether the clients need to use smart card authentication or password
authentication.

If NPS is deployed in your organization, you can configure TS Gateway policies, and
then use NPS to store, manage, and validate those policies. NPS is the Microsoft
implementation of a RADIUS server.

Considerations for Planning the Terminal Services Gateway Installation

By using the TS Gateway role, you can enable authorized users to remotely connect
to terminal servers and remote desktops on a corporate network. To install TS
Gateway, you need to consider various requirements such as client name
specification, connection authorization policies (CAPs), resource allocation policies
(RAPs) and firewall configuration and network location.

Client Name Specification

To access a computer on the corporate network by using a TS Gateway

server, users can specify a NetBIOS name or fully qualified domain name
(FQDN) on the Terminal Services client. The connection will succeed when
users specify the FQDN name of the remote computer, and when the
associated resource authorization policy (RAP) in TS Gateway uses a NetBIOS
name for that remote computer.
A user will not be able to connect to the remote computer in the following
situations:

• If the user tries to connect to a remote computer by using its NetBIOS

name, but the RAP on the TS Gateway server uses an FQDN name for
the remote computer.
• If the TS Gateway server contains a domain global computer group
from other groups.

You need to avoid name resolution failures and you need to support either
NetBIOS names or FQDNs by including each computer name in the resource
group that you create.

CAPs

By using CAPs, you can specify whether user groups on the local TS Gateway
server or on AD DS can connect to a TS Gateway server. You must specify the
conditions required to access a TS Gateway server. For example, you can
specify that all users who connect to a specific terminal server by using a TS
Gateway server must be members of that particular user group. You must
also specify that a client computer must be a member of an Active Directory
domain in the corporate network to connect to the TS Gateway server.

To enhance security, you must specify whether client device redirection

should be disabled for all devices that the Terminal Services client supports,
or just for a specific device. You must also specify whether clients must use
smart card authentication or password authentication to access computers.
Users can connect to the TS Gateway server only if they meet the conditions
specified in the CAP. You can allow users to access specific resources on your
network by creating resource authorization policies.

RAPs

You can use RAPs to specify the computers that users can access on the
network from the Internet by using the TS Gateway server. Before creating
RAPs, you need to create resource groups by adding a list of computers or a
group of computers. To access remote computers on the corporate network,
TS Gateway users need to meet the conditions in one CAP and one RAP.

Firewall Configuration

By configuring Internet Security and Acceleration (ISA) Server to function as

an SSL termination device, you can use ISA Server 2004 with TS Gateway.
When you use SSL termination, ISA Server can terminate SSL sessions,
inspect packets, and re-establish SSL sessions. ISA Server helps in enhancing
 security by decrypting incoming SSL traffic, inspecting the traffic for
malicious code, and then blocking connections containing suspicious packets.
ISA Server also performs HTTP filtering.

You can use ISA Server and TS Gateway server to enhance security for
remote connections to internal corporate network resources in the following
three scenarios:

• ISA Server as an SSL termination device.

• ISA Server as a firewall and SSL termination device.
• ISA Server as a firewall that performs port filtering.

Network Location

The TS Gateway server can be hosted in the perimeter network. RDP traffic is
tunneled using SSL. The external firewall needs to have port 443 open to
allow the SSL traffic. The TS Gateway server strips off the SSL and passes the
RDP traffic through the internal firewall to the internal Terminal Servers. The
internal firewall needs to have port 3389 open to support the RDP protocol.

Installing the Terminal Services Gateway Role

Prerequisites for Installing the TS Gateway Service

Before installing the TS Gateway service on your server, you must ensure
that Windows Server 2008 is installed on the server. You must also install the
following features and services, to ensure that the TS Gateway functions
properly:

• The RPC over HTTP Proxy service.

• The Web server Internet Information Services 7.0 must be installed and
must be running the RPC over HTTP Proxy service.
• The NPS must be installed. If you have already deployed NPS for
remote access such as VPN and dial-up networking, you can use the
existing NPS for installing the TS Gateway role. By doing this, you can
centralize the storage, management, and validation of the TS Gateway
CAPs.

Note: When you use the Server Manager to install the TS Gateway role
service, these additional role services and features are automatically
installed.

When you install the TS Gateway on your server, you must obtain an SSL
certificate. By default, the RPC/HTTP Load Balancing service and the Internet
Information Services use the Transport Layer Security (TLS) 1.0 to encrypt
communication between the TS Gateway servers and clients over the
 Internet. To ensure proper functioning of the TLS, you must install an SSL
certificate on the TS Gateway server.

Installing the TS Gateway Service

You can install the TS Gateway role service for the terminal server by using
the Server Manager. To support the TS Gateway role, the following services
and features are provided by the Add Roles Wizard:

• Web Server Internet Information Services

• NPS
• RPC over HTTP
• Windows Activation Service (WAS)

The Add Roles Wizard also allows you to:

• Import an existing SSL certificate or create a self-signed certificate at

the time of installation or later.
• Create CAPs at the time of installation or later.

Managing Terminal Services by Using Windows System Resource

Manager
What Is Windows System Resource Manager?

WSRM is included in Windows Server 2008, but it is not installed by default. By

using the Add Features link in Server Manager, you can add or remove Windows
components. While you perform these features of Server Manager, a pop-up box
directs you to install Microsoft SQL Server 2005 Embedded Edition. When you click
the Install button, the necessary services are installed on the server.

You can use the WSRM tool to allocate CPU and memory resources to applications,
services, and processes. By using WSRM, you can reduce the chances of
applications, services, or processes affecting the performance of the system. You
can manage resources and create a consistent, predictable experience for users of
applications and services. You can use WSRM to manage applications on a single
computer or to mange users on a computer with Terminal Services.

Process-Matching

A running process is matched when the WSRM service discovers it, or when
changes are made to the active resource-allocation policy. If changes are
made to the policy, WSRM examines the processes again. WSRM checks the
system-defined exclusion list and the user-defined exclusion list and places
the all matching processes in the excluded processes group. After a process is
placed in a group, WSRM enforces the associated resource allocation for the
process by setting resource limits or by modifying the priority of the process.
The processes in the system-defined exclusion list or the user-defined
exclusion list are never modified.

Resource-Allocation Policy

A resource-allocation policy specifies the resource usage for a managed

process. A resource allocation policy includes one or more process-matching
criterion and one or more allocations such as a CPU consumption target,
memory limit, or processor affinity. You can have multiple resource allocation
policies, each one providing different limits for different process-matching
criteria. For example, one resource allocation policy may limit resources for
LOB applications while another limits an Internet Information Services
application pool.

Process Matching Criteria

Process matching is the mechanism used by WSRM to match processes and

to aggregate the processes into groups. A process-matching criterion creates
an association between matched processes and a resource-allocation policy.
For example, all the Microsoft Office application executables could be
grouped together in process-matching criteria named Office_Apps. Then that
Office_Apps criterion could be managed by a resource allocation policy that
limits CPU utilization and/or memory consumption.

WSRM groups the new process with other processes if the new process has
properties that meet the process-matching criterion. The resource allocations
specified in the resource-allocation policy are then applied to the new
process. If a new process does not match the process-matching criteria, the
process is added to the default group.

Default Group

The default group includes all running processes that have not been matched
to any process-matching criteria in the managing resource-allocation policy.
The processes in the default group are given CPU bandwidth that has not
been allocated to other processes. The default group has unlimited memory
for its processes.

Exclusion Lists

By using WSRM, you can manage most of the applications. However, you
should not use WSRM to manage the Windows processes that are listed in the
system-defined exclusion list. In addition, the user exclusion list contains the
other services or processes that might not perform properly under
management. A process that is included in either of these lists is known as an
unmanaged process.
Summary
Core Functionality of Terminal Services

• Terminal Services is a component of the Windows operating system that

enables a client application to connect to the terminal server. A user can
securely access applications or data stored on a remote computer over a
network connection. Terminal Services uses RDP to transmit user inputs to
the terminal server, and then returns screen refreshes to the client desktop.
• Windows Server 2008 provides several enhancements such as RDC 6.0,
remote programs, plug-and-play redirection framework. Terminal server also
provides additional functionalities such as TS Web Access, TS Gateway, and
Session Directory.
• You can use various functionalities in Terminal Services by using the Remote
Desktop Connection. You can specify the IP address of a remote computer
and change the display properties of the remote desktop. You can select a
program and pre-configure the server name and logon method. You can also
choose not to use a Terminal Services gateway server.
• Terminal servers use the Terminal Services Licensing to obtain and manage
Terminal Services client access licenses for devices and users, who are
connecting to a terminal server. Terminal Services Licensing Centralizes
administration for TS CALs, supports communication channels, and reduces
impact on network and servers. TS CALs provides license accountability,
tracking, and reporting for all devices and users. You can activate a license
server to certify the terminal server. You can also activate a license server by
using the Web method or the telephone method or the Internet method.
• Terminal Services Licensing supports several functionalities in Windows
Server 2008. These functionalities include, license server migration, license
server co-existence, license server discovery, and user based license
tracking.
• You can configure Terminal Services connections by using Terminal Services
Configuration console. You can use this console to control RDP over TCP
protocol. You can set the logon information to be provided by the client and
set the connection timeout and the reconnection settings. You can limit the
number of connections to the terminal server.
• You can configure Terminal Services server settings in Terminal Services
Configuration management console. You can delete temporary files on exit,
use temporary folders per session, and restrict users to one session. You can
configure licensing mode per device and the behavior of Terminal Server
Services Directory.

Implementing Terminal Services Remote Programs

• Windows Server 2008 supports Terminal Services Remote Programs, which is

a variation of the standard Terminal Services session. By using Terminal
Services Remote Programs, you can run applications transparently on a
terminal server. You need to consider various requirements related to servers,
clients, permissions and Remote Program Links while configuring Terminal
Services Remote Programs.
 • You can access Remote Programs remotely through Terminal Services. The
Remote Programs Wizard helps you to manage Remote Programs. You can
use the Remote Programs to create RDP package. You can use the Remote
Word Pad to create MSI package.
• To access remote programs, you can either use the Terminal Server Web
access or install a package on your machine to provide the rdp file. The
mspaint application is launched remotely on the terminal server by using rdp.
You can also use the msi file to remotely open another application and create
the msi file by using group policies.

TechNet Virtual Lab: Centralized Application Access with Windows Server

2008 Beta 3

Implementing Terminal Services Web Access

• Terminal Services Web Access enables you to allow users to access the
Terminal Services Remote Programs from a Web browser. You can use the
Terminal Services Web client to log on to a Terminal Server from your Web
browser. This provides easy access to Terminal Server sessions.
• Terminal Services Web Access can populate the list of Remote Programs,
which appears in the Web Part, from Active Directory or from a single terminal
server. Before installing the Terminal Services Web Access role service, you
must install the Terminal Server role and IIS 7.0. After installing Terminal
Services Web Access, you can specify the data source that must be used to
populate the list of Remote Programs that appears in the Web Part.
• You can access the Terminal Services Remote Programs from a Web browser.
Accessing the terminal server provides access to all remote applications. You
can populate applications either from Active Directory Domain Services or
from a single Terminal server.

Implementing Terminal Services Gateway

• TS Gateway is a role service that provides a secure, encrypted connection

between authorized remote users on the Internet and terminal servers on the
corporate network. TS Gateway allows users to connect remotely over the
Internet to computers that are hosted behind firewalls in private networks. It
also eliminates the need to deploy VPN servers for users to connect remotely
to the corporate network from the Internet.
• By using the TS Gateway role, you can enable authorized users to remotely
connect to terminal servers and remote desktops on a corporate network. To
install TS Gateway role, you need to consider various requirements such as
client name specification, CAPs, RAPs and firewall configuration, and network
location.
• A Windows Server 2008 must be installed on a server before the TS Gateway
service is installed on the server. You need to install RPC over HTTP Proxy
services, Web Server IIS 7.0, and NPS to ensure effective functioning of TS
Gateway. To support the TS Gateway role, the Add Roles Wizard provides Web
Server Internet Information Services, NPS, RPC over HTTP, and WAS.
 • You can configure the Terminal Services Gateway role by using the Add Roles
Wizard. You can select the role and the role services you want to install on the
server. TS Gateway provides access to Terminal Servers inside a corporate
network by using HTTP. Network Access Services delivers a variety of
methods to provide users with local and remote network connectivity and to
allow network administrators to centrally manage network access.
• You can configure the terminal server gateway service by creating Connection
Authorization Policies and Resource Authorization Policies in the Terminal
Services Manager. You can create a group of terminal servers as a local
resource group. You can list the servers by the BIOS name, Internet Protocol
address, or a fully qualified domain name. You can use the Resource
Authorization Policies to define access for users to the remote computers on
the network.

Managing Terminal Services by Using Windows System Resource Manager

• You can use the WSRM tool to allocate CPU and memory resources to
applications, services, and processes. By using WSRM, you can reduce the
chances of applications, services, or processes affecting the performance of
the system. You can use WSRM to manage applications on a single computer
or to mange users on a computer with Terminal Services.
• The various features of WSRM are process matching, resource allocation
policy, process matching criteria, default group and exclusion lists.
• You can manage Terminal Server Resources by using WSRM. You can create a
new process matching criteria and allocate processor and memory resources
to each process matching criteria. You can also suballocate processor
resources. You can specify the amount of sub-allocation you want to apply to
the original allocation for each process-matching criterion.

TechNet Virtual Lab: Managing Terminal Services Gateway and

RemoteApps in Windows Server 2008

Configuring a Web Services Infrastructure

Manage Internet Information Services (IIS)

TechNet Webcast: End-to-End Overview of Internet Information Services

7.0 (Level 200)

Benefits of the IIS 7.0 Server Role

Using the Server Manager, you can add the IIS server role which is split into
modules, individual features that the server uses to process requests. These
modules are installed as role services. Splitting the IIS functionality into modules
provides detailed control over the configuration settings.
IIS 7.0 includes around 40 modules, including Static Compression, Anonymous
Authentication, and File Transfer Protocol (FTP) Server. Static Compression
compresses .htm, .html, and .txt files; Anonymous Authentication provides
anonymous users with access to content; FTP Server provides FTP services to users.

Load Minimum Modules

Because each module has a specific function, you need to load only the
module that is required to support specific Web applications. By loading only
the required module, you can reduce the attack surface, in-memory footprint,
running module code, and CPU load. You can also reduce patching and
management requirements to the installed modules.

Replace with Custom Components

You can replace IIS modules with custom components that are developed by
using the native IIS 7.0 C++ application programming interfaces (APIs) or the
ASP.NET 2.0 APIs. You can add modules that can replace or enhance present
IIS features. For example, you can add an IIS module for authenticating users
to a third-party database. You can enable secure FTP transfers by developing
and adding an enhanced FTP module.

Features of the Administrative Tools in IIS 7.0

IIS 7.0 in Windows Server 2008 offers a broad set of administration features that
simplify the day-to-day tasks of managing Web sites and applications. These
features include an updated graphical user interface (GUI), updated command-line
tool, configuration store, and Windows Media Instrumentation (WMI) provider.

GUI

The important GUI administrative tool in IIS 7.0 offers a new and more
efficient method to manage the Web server.

You can use this tool to:

• Delegate administrative control of Web sites and applications to non-

administrators.
• Connect to remote administration over HTTP/SSL.
• Install and download automatically important UI modules.

Command Line

You can use Appcmd.exe to display all key server functionality through a set
of intuitive management objects. These objects can be manipulated from the
 command line or from the scripts. You can use the command line to install
modules, create web sites, and modify application pools from the command
line.

Configuration Store

XML configuration files are based on the NET Framework 2.0 configuration
store. The configuration store is made up of Machine.config,
ApplicationHost.config, and the Web.config files. You can modify these files by
using an XML editor.

WMI Provider

You can read or change settings in the configuration store by using the WMI
provider. You can use the WMI provider to automate configuration changes for
deployment of applications across multiple servers.

Managed Interface

Managed interface and Microsoft.Web.Administration provides information

that is similar to the information provided by the WMI provider.

Configuration Files in IIS 7.0

IIS 7.0 enables distributed configuration of IIS settings. This allows you to
specify certain IIS configuration settings in files that are stored and deployed
with the code and content. Distributed configuration also allows server
administrators to delegate configuration settings to site developers, as well
as simplifying configuration because a server administrator does not have to
log on to each server to configure IIS settings.

NET Framework Configuration

The configuration file

%windir%\Microsoft.NET\Framework\v2.0.50727\config\machine.config
contains settings for the whole server. All other .NET configuration files,
including IIS configuration files, will inherit the settings stored in this
configuration file.

ApplicationHost.config file

The %windir%\system32\inetsrv\config\ApplicationHost.config configuration

file contains computer-wide configuration stored in one of the two section
groups. They are:
 • System.applicationHost, which contains configuration settings for sites,
applications, virtual directories, and application pools, in addition to
support for non-HTTP protocols.
• System.webServer, which contains configuration settings, such as
security settings, HTTP compression, and logging, for Web sites. It also
contains Web applications, virtual and physical directories, and files.

Web.config file

The %windir%\Microsoft.NET\Framework\v2.0.50727\config\web.config
configuration file consists of default settings for individual Web sites, Web
applications, or virtual or physical directories. You can store this file in the
same directory with code or content. In this file, you can override settings
that are inherited from higher levels in the configuration hierarchy, or lock
inherited settings.

The web.config file in the root of each Web site consists of the Web site
settings and the web.config file in the application or virtual directory folder
consists of the application or the virtual directory settings.

Options for Replicating Settings between Servers

In the earlier versions of IIS, the configuration information was stored in the
metabase, which contained data specific to each IIS server computer. IIS 7.0 stores
configuration information in XML-based files. The ApplicationHost.config file
contains information about the web site and the application pool configuration for a
particular IIS server. The Web.config file contains specific information on the
operations of a specific web site, an application, or a virtual directory. You can
configure multiple servers in a network load balanced cluster by using both types of
files. You can replicate the IIS configuration information in both the
ApplicationHost.config file and in the web.config file.

ApplicationHost.config

The following are the methods for replicating IIS configuration in

ApplicationHost.config:

• You can leverage the built-in “Internet User” account for the
application; you do not need to use machine specific Security
Identifiers (SIDs).
• You can use a simple file copy.
• You do not require command line tools.
• You need to install and enable the same modules on each IIS server.
• Before replication, you need to modify information that varies by
machine such as IP Addresses and drive letters.
• You need to terminate and restart all worker processes within the
affected application pools.
 Web.config

The following are the methods for replicating IIS configuration in web.config:

• You use XCOPY to copy the application code and content with this file.
• You can replicate files from a centralized location by using Distributed
Files System Replication (DFSR). To implement DFSR to replicate the
Web.config file, you first need to create a DFS namespace for the
content to be replicated. Then, you need to add each IIS server to the
DFSR group.

Options for Managing Security in IIS 7.0

You need to implement security in any IIS deployment. IIS 7.0 provides various
options to implement security.

Authentication and Authorization

Depending on where the user information is stored, you can choose the type
of authentication and the level of authentication required. You can configure
two types of authentication:

• Challenged-base authentication. This type of authentication will

prompt for the login credentials. It provides various authentication
mechanisms such as Windows, Client Certificates, Digest, and Basic.
• Forms-based authentication. This type of authentication will redirect
the user to a login page if appropriate credentials are not provided for
accessing a requested resource.

Server and IIS Security

To reduce the attack surface, configure server and IIS security and load only
the required modules to the Web. To block administrators with lower level
permissions from overriding critical settings, you must set the AllowOveride
property to False on each critical setting in ApplicationHost.config and
Web.config.

Certificates and SSL

By configuring SSL encryption, you can protect information sent between a

client and a server. You need an SSL certificate that is trusted by both the
server and the client to successfully allow encrypted communication. By
using client certificates you can authenticate Web users.
Options for Troubleshooting IIS 7.0

The Runtime State and Control API in IIS 7.0 gives you real-time information about
application pools, worker processes, sites, application domains, and running
requests. The information is in an XML-format so you can troubleshoot the problem
without reproducing it. You can also configure the API to create a detailed log of the
events that led up to the error.

The Health and Diagnostics features in IIS Manager are: Failed Request Tracing,
Logging, and Worker Processes.

Failed Request Tracing

The server administrator can generate an error log by defining specific error
conditions in the Failed Request Tracing Rules; the rules can be based on IIS
status codes or on the length of time a process takes to run. Once an error
condition is detected, a detailed trace of events is written to an XML-based
log so you can troubleshoot the problem without having to reproduce it.

Logging

Logging provides detailed information about requests made to the server.

These logs enable you to identify any unauthorized attempts to compromise
the Web server.

Worker Processes

The Worker Processes monitor manages a list of worker processes running in

application pools on a Web server. The monitor allows an administrator to
view the worker process state, percentage of CPU used, and the amount of
memory or virtual address space committed to a worker process.

TechNet Virtual Lab: Using APPCMD Command Line or UI with IIS 7 in

Windows Server 2008

Configuring Network Application Services

Configure Windows Media server

Configuring Advanced Streaming Solutions in Windows Media Server

With Windows Media Services, you can customize streaming content to meet
specific business needs. For example, you can edit Synchronized Multimedia
Integration Language (SMIL)–based playlists and add advertisements to publishing
points.

Editing SMIL-based playlists

A playlist is an XML-based language standard that is being developed by the

World Wide Web Consortium (W3C). The playlist will enable Web developers
to send separate content streams to a client computer where they will be
displayed as a single stream. You can edit playlists with the following
methods:

• Using the Playlist Editor. The Playlist Editor provides a simple, graphical
interface for creating playlists and specifying attributes for the items in
the playlist. You can access the Playlist Editor from the Summary tab of
the Publishing Points console tree or by clicking the View Playlist Editor
button on the Source tab of a publishing point.
• Using the Source tab. The Source tab of a publishing point includes an
embedded version of the Playlist Editor. You can use the embedded
version to edit playlists that are currently assigned to publishing
points.
• Using a text or XML editor. You can use a Text or XML editor to create
and edit playlist files. In addition, you can add comments to your file
and modify all XML elements and attributes.

Adding advertisements to publishing points

For many content providers it is important to have advertisements or

promotions in between content segments to generate revenue. Windows
Media Services provides three methods to provide advertisements:

• Wrapper advertisements. Wrapper advertisements are streaming

advertisements that play before or after the user views the live
content. The wrapper advertisements are created in a playlist. The
playlist is assigned to the publishing point on the Advertising tab in the
Windows Media Services snap-in.
• Interstitial advertisements. Interstitial advertisements are streaming
advertisements that are inserted in a playlist with your content. You
must use a playlist to make use of interstitial advertising. In the playlist
editor, the element defines the streaming content that has the role
attribute set to Advertisement.
• Banner advertisements. Banner advertisements are static or
multimedia advertisements that appear on a player independent of the
streaming content. You can implement these advertisements by
associating an advertising banner Uniform Resource Locator (URL) with
a banner metadata element in the announcement file. You can also
implement these advertisements by using the bannerURL attribute
with a clientData element in a playlist file.
Options for Configuring Security in Windows Media Server

Securing Windows Media Server from unwanted user access is a concern when
designing an enterprise-wide streaming infrastructure. Windows Media Server has
various security configuration options such as IP address restriction, user
authentication, content expiration, and digital rights management.

IP Address Restriction

You can set a range of IP addresses from the local network. You can either
allow or deny access to the Windows Media Services or a specific publishing
point based on the client computer’s IP address.

User Authentication

You can use Windows NT LAN Manager (NTLM), Kerberos protocol, or Digest
authentication to restrict client access. These authentication methods are
primarily suited for intranet applications.

You can authorize users and give them specific permissions on the publishing
point or on the streamed content files stored on a New Technology File
System (NTFS) partition.

Content Expiration

Using Windows Media Rights Manager, you can assign usage rules to content.
You can ensure the security of downloadable media to local users, remote
users, vendors, clients, and partners.

You can use Windows Media Rights Manager to gather information about the
people who request the media or to make content licenses expire after a
specific duration.

Digital Rights Management

You can use Windows Media Rights Manager to assign usage rules to content.
You can stream the content to users and also allow enforcement of license
usage rules provided by Windows Media Rights Manager. You can apply the
following limits to the content:

• Number of client connections to the server

• Amount of bandwidth that can be consumed by streams for a specific
publishing point
• Amount of bandwidth that can be consumed by a single client
Active Directory Rights Management Service
Features

• Licensing and distributing rights-protected information. An AD RMS

system issues certificates that identify trusted entities, such as users,
groups, and services, who can publish rights-protected content. Once
trust has been established, users can assign usage rights and
conditions to the content that they want to protect. These usage rights
specify who can access rights-protected content and what they can do
with it.
• Acquiring licenses to decrypt rights-protected content and applying
usage policies. Users, who have been granted a rights account
certificate, can access rights-protected content by using an AD RMS-
enabled client application that allows users to view and work with
rights-protected content. When users attempt to access rights-
protected content, a unique license is used for applying the usage
rights and conditions specified in the publishing licenses.
• Creating rights-protected files and templates. Users, who are trusted
entities in an AD RMS system, can create and manage protection-
enhanced files by using authoring applications and tools in an AD RMS-
enabled application. In addition, AD RMS-enabled applications can help
users to efficiently apply a predefined set of usage policies by
providing a set of centrally defined and authorized usage rights
templates.
• AD RMS integration. AD RMS can be integrated with existing
technologies and standards. When you configure an application to
support AD RMS, you can use the services of AD RMS to protect the
content created by the application.

Requirements

The software requirements for installing AD RMS on Windows Server

2008 includes:

• Internet Information Services 7.0 with ASP.NET and World Wide Web
Publishing Service.
• Microsoft Message Queuing (MSMQ) and Directory Service Integration
must be enabled to activate AD RMS logging.
• Windows Internal Database, Microsoft SQL Server 2005 or other
compatible database servers. If no database is available during the
installation, you can install the Windows Internal Database on the
server.
• Installation of AD RMS in an Active Directory DS domain that include
domain controllers that run Windows Server 2000 with Service Pack 3
(SP3) or later versions.
The client-side requirements for AD RMS includes:

• Windows 2000 Server Service Pack 4, Windows Server 2003, Windows

Server 2003 Service Pack 1, Windows XP Service Pack 1, or Windows
XP Service Pack 2. AD RMS is installed by default on Windows Vista
computers. However, an AD RMS client must be installed for other
operating systems.
• AD RMS-compatible applications, such as Microsoft Office 2003 or later
versions.