Preparation Guide For 71-643

Preparation Guide for Exam 70643 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 imagebased 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 sectorbased 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 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 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 onscreen prompts to phone activate: Slmgr.vbs /ipk 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 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 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. 2. 3. 4.

Host Name – this corresponds to the FQDN of the KMS host Priority – not used. Defaults to 0 Weight – not used. Defaults to 0 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**: 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 = 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 [:<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 <:port> cscript \windows\system32\slmgr.vbs /skms <: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 ncount 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 ncount 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 overutilized, 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 memberservers. 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 loadbalanced 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 loadbalanced 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 Windows Windows Windows

Server 2008 Beta 2. Server 2003 with SP1. Vista. 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 Internetconnected 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 nonadministrators. 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 RMSenabled client application that allows users to view and work with rights-protected content. When users attempt to access rightsprotected 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 protectionenhanced files by using authoring applications and tools in an AD RMSenabled 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.