Features Available in Windows Server 2008 R2

Features are software programs available in Windows Server® 2008 R2 that, though they are not directly parts of roles, can support or augment the functionality of one or more roles, or enhance the functionality of the entire server, regardless of which roles are installed. For example, the Failover Clustering feature augments the functionality of other roles, such as File Services and DHCP Server, by enabling them to join server clusters for increased redundancy and improved performance. Another feature, Telnet Client, allows you to communicate remotely with a telnet server over a network connection, functionality which enhances the communication options of the server as a whole.

Features in Windows Server 2008 R2

The following list identifies features that you can install by using the Server Manager Add Features Wizard, available as part of Windows Server 2008 R2. You can also install features by using the Windows PowerShell cmdlet Add-WindowsFeature, or the Server Manager command-line utility, ServerManagerCmd.exe. For more information about how to install or remove features, see the Server Manager Help.

  • Background Intelligent File Transfer Service (BITS) Overview

  • Biometrics Overview

  • BitLocker Active Directory Recovery Password Viewer Overview

  • BitLocker Drive Encryption Overview

  • BranchCache Overview

  • Connection Manager Administration Kit Overview

  • Desktop Experience Overview

  • DirectAccess Overview

  • Group Policy Management Overview

  • Failover Cluster Overview

  • Ink and Handwriting Services Overview

  • Internet Printing Client Overview

  • iSNS Server Overview

  • Line Printer Remote Port Monitor Overview

  • Message Queuing Overview

  • Multipath I/O Overview

  • .NET Framework 3.5.1 Features Overview

  • Network Load Balancing Overview

  • Peer Name Resolution Protocol Overview

  • Quality Windows Audio Video Experience Overview

  • Remote Assistance Overview

  • Remote Differential Compression Overview

  • Remote Server Administration Tools Overview

  • RPC over HTTP Proxy Overview

  • Services for Network File System Overview

  • Simple Mail Transfer Protocol Overview

  • Simple Network Management Protocol Overview

  • Simple TCP/IP Services Overview

  • SNMP WMI Provider Overview

  • Storage Manager for SANs Overview

  • Subsystem for UNIX-based Applications Overview

  • Telnet Server Overview

  • Telnet Client Overview

  • Trivial File Transfer Protocol (TFTP) Overview

  • Windows Internal Database Overview

  • Windows Internet Name Service (WINS) Overview

  • Windows PowerShell Integrated Scripting Environment Overview

  • Windows Process Activation Service (WAS) Overview

  • WinRM IIS Extension Overview

  • Windows Server Backup Overview

  • Windows System Resource Manager Overview

  • Windows TIFF IFilter Overview

  • Wireless LAN Service Overview

  • XPS Viewer Overview


Background Intelligent File Transfer Service (BITS) Overview

The Background Intelligent Transfer Service (BITS) has two role services: the Compact Server and the IIS Server Extension. The Compact Server is a stand-alone HTTP or HTTPS file server, whereas the IIS Server Extension is an Internet Information Services (IIS) plug-in that requires a server running IIS.

IIS Server Extension

The BITS IIS Server Extension lets you configure a server that is running IIS to allow BITS clients to perform background, resumable file uploads to IIS virtual directories. On completion of a file upload, the BITS Server can notify a Web application of the newly uploaded file. This allows the application to process the uploaded file. The Web application can then optionally reply to the client responsible for the upload.

Compact Server

The BITS Compact Server is a stand-alone HTTP or HTTPS file server, which allows applications to host files for BITS clients to download, and allows the asynchronous transfer of a limited number of large files between computers.

Additional resources

  • Background Intelligent Transfer Service http://go.microsoft.com/fwlink/?LinkId=140888

  • BITS Reference http://go.microsoft.com/fwlink/?LinkId=140985


Biometrics Overview

For enhanced convenience, Windows 7 enables administrators and users to use fingerprint biometric devices to log on to computers, grant elevation privileges through User Account Control (UAC), and perform basic management of the fingerprint devices. Administrators can manage fingerprint biometric devices in Group Policy by enabling, limiting, or blocking their use.

What is biometrics?

A growing number of computers, particularly portable computers, include embedded fingerprint readers. Fingerprint readers can be used for identification and authentication of users in Windows. Until now, there has been no standard support for biometric devices or for biometric-enabled applications in Windows. Computer manufacturers had to provide software to support biometric devices in their products. This made it more difficult for users to use the devices and administrators to manage the use of biometric devices.

Windows 7 includes the Windows Biometric Framework that exposes fingerprint readers and other biometric devices to higher-level applications in a uniform way, and offers a consistent user experience for discovering and starting fingerprint applications. It does this by providing the following:

  • A Biometric Devices Control Panel item that allows users to control the availability of biometric devices and whether they can be used to log on to a local computer or domain.

  • Device Manager support for managing drivers for biometric devices.

  • Credential provider support to enable and configure the use of biometric data to log on to a local computer and perform UAC elevation.

  • Group Policy settings to enable, disable, or limit the use of biometric data for a local computer or domain. Group Policy settings can also prevent installation of biometric device driver software or force the biometric device driver software to be uninstalled.

  • Biometric device driver software available from Windows Update.

Who will want to use biometric devices?

Fingerprint biometric devices offer a convenient way for users to log on to computers and grant elevation through UAC.

What are the benefits of the new biometric features?

The new biometric features provide a consistent way to implement fingerprint biometric–enabled applications and manage fingerprint biometric devices on stand-alone computers or on a network. The Windows Biometric Framework makes biometric devices easier for users and for administrators to configure and control on a local computer or in a domain.

What's the impact of these changes on biometrics?

The introduction of the Windows Biometric Framework allows the integration of fingerprint biometric devices in Windows. It offers a consistent user experience for logging on to Windows and performing UAC elevation. In addition, it provides a common set of discovery and integration points that offers a more consistent user experience across devices and applications. The Windows Biometric Framework also includes management functions that allow administrators to control the deployment of biometric fingerprint devices in the enterprise.


BitLocker Active Directory Recovery Password Viewer Overview

The BitLocker Active Directory Recovery Password Viewer tool is an optional feature included with the Remote Server Administration Toolkit (RSAT) that you can install by using the Add Feature wizard in the RSAT management console. This tool lets you locate and view BitLocker recovery passwords that are stored in Active Directory Domain Services (AD DS). You can use this tool to help recover data that is stored on a volume that has been encrypted by using BitLocker. The BitLocker Active Directory Recovery Password Viewer tool is an extension for the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in. Using this tool, you can examine a computer object's Properties dialog box to view the corresponding BitLocker recovery passwords. Additionally, you can right-click a domain container and then search for a BitLocker recovery password across all the domains in the Active Directory forest.

Usage requirements

To view recovery passwords, you must be a domain administrator, or you must have been delegated permissions by a domain administrator. In addition, to use the BitLocker Active Directory Recovery Password Viewer, the following conditions must be true:

  • The domain must be configured to store BitLocker recovery information.

  • The computers protected by BitLocker must be joined to the domain.

  • BitLocker Drive Encryption must have been enabled on the computers.

Common tasks

The following procedures describe the most common tasks performed by using the Active Directory Recovery Password Viewer.

To view the recovery passwords for a computer

  1. In Active Directory Users and Computers, locate and then click the container in which the computer is located.

  2. Right-click the computer object, and then click Properties.

  3. In the Properties dialog box, click the BitLocker Recovery tab to view the BitLocker recovery passwords that are associated with the particular computer.
To copy the recovery passwords for a computer

  1. Follow the steps in the previous procedure to view the BitLocker recovery passwords.

  2. On the BitLocker Recovery tab of the Properties dialog box, right-click the BitLocker recovery password that you want to copy, and then click Copy Details.

  3. Press CTRL+V to paste the copied text to a destination location, such as a text file or spreadsheet.
To locate a recovery password

  1. In Active Directory Users and Computers, right-click the domain container, and then click Find BitLocker Recovery Password.

  2. In the Find BitLocker Recovery Password dialog box, type the first eight characters of the recovery password in the Password ID (first 8 characters) box, and then click Search.


BitLocker Drive Encryption Overview

BitLocker Drive Encryption is a data protection feature available Windows Server 2008 R2 and in some editions of Windows 7. Having BitLocker integrated with the operating system addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers.

Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software-attack tool against it or by transferring the computer's hard disk to a different computer. BitLocker helps mitigate unauthorized data access by enhancing file and system protections. BitLocker also helps render data inaccessible when BitLocker-protected computers are decommissioned or recycled.

BitLocker provides the most protection when used with a Trusted Platform Module (TPM) version 1.2. The TPM is a hardware component installed in many newer computers by the computer manufacturers. It works with BitLocker to help protect user data and to ensure that a computer has not been tampered with while the system was offline.

On computers that do not have a TPM version 1.2, you can still use BitLocker to encrypt the Windows operating system drive. However, this implementation will require the user to insert a USB startup key to start the computer or resume from hibernation, and it does not provide the pre-startup system integrity verification offered by BitLocker with a TPM.

In addition to the TPM, BitLocker offers the option to lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable device, such as a USB flash drive, that contains a startup key. These additional security measures provide multifactor authentication and assurance that the computer will not start or resume from hibernation until the correct PIN or startup key is presented.

System integrity verification

BitLocker can use a TPM to verify the integrity of early boot components and boot configuration data. This helps ensure that BitLocker makes the encrypted drive accessible only if those components have not been tampered with and the encrypted drive is located in the original computer.

BitLocker helps ensure the integrity of the startup process by taking the following actions:

  • Provide a method to check that early boot file integrity has been maintained, and help ensure that there has been no adversarial modification of those files, such as with boot sector viruses or rootkits.

  • Enhance protection to mitigate offline software-based attacks. Any alternative software that might start the system does not have access to the decryption keys for the Windows operating system drive.

  • Lock the system when it is tampered with. If any monitored files have been tampered with, the system does not start. This alerts the user to the tampering, because the system fails to start as usual. In the event that system lockout occurs, BitLocker offers a simple recovery process.

Hardware, firmware, and software requirements

To use BitLocker, a computer must satisfy certain requirements:

  • For BitLocker to use the system integrity check provided by a TPM, the computer must have a TPM version 1.2. If your computer does not have a TPM, enabling BitLocker will require you to save a startup key on a removable device such as a USB flash drive.

  • A computer with a TPM must also have a Trusted Computing Group (TCG)-compliant BIOS. The BIOS establishes a chain of trust for pre-operating system startup and must include support for TCG-specified Static Root of Trust Measurement. A computer without a TPM does not require a TCG-compliant BIOS.

  • The system BIOS (for TPM and non-TPM computers) must support the USB mass storage device class, including reading small files on a USB flash drive in the pre-operating system environment. For more information about USB, see the USB Mass Storage Bulk-Only and the Mass Storage UFI Command specifications on the USB Web site (http://go.microsoft.com/fwlink/?LinkId=83120).

  • The hard disk must be partitioned with at least two drives:

    • The operating system drive (or boot drive) contains the operating system and its support files; it must be formatted with the NTFS file system.

    • The system drive contains the files that are needed to load Windows after the BIOS has prepared the system hardware. BitLocker is not enabled on this drive. For BitLocker to work, the system drive must not be encrypted, must differ from the operating system drive, and must be formatted with the NTFS file system. The system drive should be at least 1.5 gigabytes (GBs).

Installation and initialization

BitLocker is installed automatically as part of the operating system installation. However, BitLocker is not enabled until it is turned on by using the BitLocker setup wizard, which can be accessed from either the Control Panel or by right-clicking the drive in Windows Explorer.

At any time after installation and initial operating system setup, the system administrator can use the BitLocker setup wizard to initialize BitLocker. There are two steps in the initialization process:

  1. On computers that have a TPM, initialize the TPM by using the TPM Initialization Wizard, the BitLocker Drive Encryption item in Control Panel, or by running a script designed to initialize it.

  2. Set up BitLocker. Access the BitLocker setup wizard from the Control Panel, which guides you through setup and presents advanced authentication options.

When a local administrator initializes BitLocker, the administrator should also create a recovery password or a recovery key. Without a recovery key or recovery password, all data on the encrypted drive may be inaccessible and unrecoverable if there is a problem with the BitLocker-protected drive.

Note

BitLocker and TPM initialization must be performed by a member of the local Administrators group on the computer.

For detailed information about configuring and deploying BitLocker, see the Windows BitLocker Drive Encryption Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=140225).

Enterprise implementation

BitLocker can use an enterprise's existing Active Directory Domain Services (AD DS) infrastructure to remotely store recovery keys. BitLocker provides a wizard for setup and management, as well as extensibility and manageability through a Windows Management Instrumentation (WMI) interface with scripting support. BitLocker also has a recovery console integrated into the early boot process to enable the user or helpdesk personnel to regain access to a locked computer.

For more information about writing scripts for BitLocker, see Win32_EncryptableVolume (http://go.microsoft.com/fwlink/?LinkId=85983).

Computer decommissioning and recycling

Many personal computers today are reused by people other than the computer's initial owner or user. In enterprise scenarios, computers may be redeployed to other departments, or they might be recycled as part of a standard computer hardware refresh cycle.

On unencrypted drives, data may remain readable even after the drive has been formatted. Enterprises often make use of multiple overwrites or physical destruction to reduce the risk of exposing data on decommissioned drives.

BitLocker can help create a simple, cost-effective decommissioning process. By leaving data encrypted by BitLocker and then removing the keys, an enterprise can permanently reduce the risk of exposing this data. It becomes nearly impossible to access BitLocker-encrypted data after removing all BitLocker keys because this would require cracking 128-bit or 256-bit AES encryption.

BitLocker security considerations

BitLocker cannot protect a computer against all possible attacks. For example, if malicious users, or programs such as viruses or rootkits, have access to the computer before it is lost or stolen, they might be able to introduce weaknesses through which they can later access encrypted data. And BitLocker protection can be compromised if the USB startup key is left in the computer, or if the PIN or Windows logon password are not kept secret.

The TPM-only authentication mode is easiest to deploy, manage, and use. It might also be more appropriate for computers that are unattended or must restart while unattended. However, the TPM-only mode offers the least amount of data protection. If parts of your organization have data that is considered highly sensitive on mobile computers, consider deploying BitLocker with multifactor authentication on those computers.

For more information about BitLocker security considerations, see Data Encryption Toolkit for Mobile PCs (http://go.microsoft.com/fwlink/?LinkId=85982).

Implementing BitLocker on servers

For servers in a shared or potentially non-secure environment, such as a branch office location, BitLocker can be used to encrypt the operating system drive and additional data drives on the same server.

By default, BitLocker is not installed with Windows Server 2008 R2. Add BitLocker from the Windows Server 2008 R2 Server Manager page. You must restart after installing BitLocker on a server. Using WMI, you can enable BitLocker remotely.

BitLocker is supported on Extensible Firmware Interface (EFI) servers that use a 64-bit processor architecture.

Note

BitLocker does not support cluster configurations.

Key management

After the drive has been encrypted and protected with BitLocker, local and domain administrators can use the Manage BitLocker page in the BitLocker Drive Encryption item in Control Panel to change the password to unlock the drive, remove the password from the drive, add a smart card to unlock the drive, save or print the recovery key again, automatically unlock the drive, duplicate keys, and reset the PIN.

Note

The types of keys that can be used on a computer can be controlled by using Group Policy. For more information about using Group Policy with BitLocker, see the BitLocker Deployment Guide (http://go.microsoft.com/fwlink/?LinkID=140286).

Disabling BitLocker protection temporarily

An administrator may want to temporarily disable BitLocker in certain scenarios, such as:

  • Restarting the computer for maintenance without requiring user input (for example, a PIN or startup key).

  • Updating the BIOS.

  • Installing a hardware component that has optional read-only memory (option ROM).

  • Upgrading critical early boot components without triggering BitLocker recovery. For example:

    • Installing a different version of the operating system or another operating system, which might change the master boot record (MBR).

    • Repartitioning the disk, which might change the partition table.

    • Performing other system tasks that change the boot components validated by the TPM.

  • Upgrading the motherboard to replace or remove the TPM without triggering BitLocker recovery.

  • Turning off (disabling) or clearing the TPM without triggering BitLocker recovery.

  • Moving a BitLocker-protected drive to another computer without triggering BitLocker recovery.

These scenarios are collectively referred to as the computer upgrade scenario. BitLocker can be enabled or disabled through the BitLocker Drive Encryption item in Control Panel.

The following steps are necessary to upgrade a BitLocker-protected computer:

  1. Temporarily turn off BitLocker by placing it into disabled mode.

  2. Upgrade the system or the BIOS.

  3. Turn BitLocker back on.

Forcing BitLocker into disabled mode will keep the drive encrypted, but the drive master key will be encrypted with a symmetric key stored unencrypted on the hard disk. The availability of this unencrypted key disables the data protection offered by BitLocker but ensures that subsequent computer startups succeed without further user input. When BitLocker is enabled again, the unencrypted key is removed from the disk and BitLocker protection is turned back on. Additionally, the drive master key is keyed and encrypted again.

Moving the encrypted drive (that is, the physical disk) to another BitLocker-protected computer does not require any additional steps because the key protecting the drive master key is stored unencrypted on the disk.

Caution

Exposing the drive master key even for a brief period is a security risk, because it is possible that an attacker might have accessed the drive master key and full drive encryption key when these keys were exposed by the unencrypted key.

For detailed information about disabling BitLocker, see Windows BitLocker Drive Encryption Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=140225).

System recovery

A number of scenarios can trigger a recovery process, for example:

  • Moving the BitLocker-protected drive into a new computer.

  • Installing a new motherboard with a new TPM.

  • Turning off, disabling, or clearing the TPM.

  • Updating the BIOS.

  • Updating option ROM.

  • Upgrading critical early boot components that cause system integrity validation to fail.

  • Forgetting the PIN when PIN authentication has been enabled.

  • Losing the USB flash drive containing the startup key when startup key authentication has been enabled.

An administrator can also trigger recovery as an access control mechanism (for example, during computer redeployment). An administrator may decide to lock an encrypted drive and require that users obtain BitLocker recovery information to unlock the drive.

Recovery setup

Using Group Policy, an IT administrator can choose which recovery methods to require, deny, or make optional for users who enable BitLocker. The recovery password can be stored in AD DS, and the administrator can make this option mandatory, prohibited, or optional for each user of the computer. Additionally, the recovery data can be stored on a USB flash drive.

Recovery password

The recovery password is a 48-digit, randomly generated number that can be created during BitLocker setup. If the computer enters recovery mode, the user will be prompted to type this password by using the function keys (F0 through F9). The recovery password can be managed and copied after BitLocker is enabled. Using the Manage BitLocker page in the BitLocker Drive Encryption item in Control Panel, the recovery password can be printed or saved to a file for future use.

A domain administrator can configure Group Policy to generate recovery passwords automatically and back them up to AD DS as soon as BitLocker is enabled. The domain administrator can also choose to prevent BitLocker from encrypting a drive unless the computer is connected to the network and AD DS backup of the recovery password is successful.

Recovery key

The recovery key can be created and saved to a USB flash drive during BitLocker setup; it can also be managed and copied after BitLocker is enabled. If the computer enters recovery mode, the user will be prompted to insert the recovery key into the computer.


BranchCache Overview

BranchCache installs the services that are required to provide BranchCache client functionality. It also provides BranchCache server support for the HTTP protocol, Hosted Cache, and applications other than network files.

BranchCache server support for network files is provided by the BranchCache for network files role service of the File Services server role.

BranchCache Overview

BranchCache reduces the utilization of the wide area network (WAN) links connecting branch offices to the data center or headquarters and increases access speeds for content that has already been downloaded into the branch office.

BranchCache does this by enabling computers in a branch office to cache files and HTTP traffic from Intranet servers on which BranchCache is enabled. Computers in the branch office can retrieve the cached content if they have permission to access the content and are authorized by the source server. Once authorized, the computers retrieve cached content from a hosted cache server in the branch (when you are using Hosted Cache mode), or from other client computers in the branch (when you are using Distributed Cache mode).

Additional References

  • BranchCache Deployment Guide


Connection Manager Administration Kit Overview

Connection Manager is a client network connection tool that allows a user to connect to a remote network, such as an Internet service provider (ISP), or a corporate network protected by a Virtual Private Network (VPN) server.

The Connection Manager Administration Kit (CMAK) is a tool that you can use to customize the remote connection experience for users on your network by creating pre-defined connections to remote servers and networks. To create and customize a connection for your users, you use the CMAK wizard.

You can use the CMAK Wizard to customize a connection profile to automate many aspects of a connection:

  • Login information for the remote network.

  • Virtual Private Network (VPN) connection details.

  • Dial-up modem configuration and phone number information.

  • Custom routing tables.

  • Custom Internet Explorer proxy settings.

  • Custom bitmaps and icons.

  • Custom Help file.

  • Custom actions that use other programs, either already on the client system or that you include with the connection profile installation program.

You can use the wizard to customize as much or as little of the connection profile as you want. You can automate almost everything, or provide many options from which your user can select to provide flexibility.

Installing Connection Manager Administration Kit

You can install CMAK by using the Add Features Wizard in Server Manager. Although Server Manager opens by default when a member of the Administrators group logs on to the computer, you can also open Server Manager by using commands on the Start menu in Administrative Tools, and by opening Programs in Control Panel.

Additional references

For more information about installing or using CMAK, see the Connection Manager Administration Kit Operations Guide (http://go.microsoft.com/fwlink/?linkid=57535).


Desktop Experience Overview

The Desktop Experience feature enables you to install a variety of Windows 7 features on your server running Windows Server 2008. If you use Windows Server 2008 as your primary operating system, you might want to have some of these Windows 7 features available for your daily use.

What does the Desktop Experience feature include?

Desktop Experience includes the following Windows 7 components and features:

  • Windows Media Player

  • Desktop themes

  • Video for Windows (AVI support)

  • Windows SideShow

  • Windows Defender

  • Disk Cleanup

  • Sync Center

  • Sound Recorder

  • Character Map

  • Snipping Tool

Note

Installing Desktop Experience does not automatically turn on any of the features it installs. After installation, you must manually enable any features that require configuration changes. For example, to use a desktop theme, use the Services snap-in for Microsoft Management Console to enable and start the Themes service, and then select the theme.

Installing or uninstalling the Desktop Experience feature

You can install or uninstall Desktop Experience using the Initial Configuration Tasks Wizard or Server Manager.

To install Desktop Experience using the Initial Configuration Tasks Wizard

  1. In the Customize This Server section, click Add features.

  2. Select the Desktop Experience check box, and then click Next.

  3. Complete the wizard by clicking Install.

To install Desktop Experience using Server Manager

  1. Open Server Manager: click Start, point to Administrative Tools, and click Server Manager.

    Notes
    • You can also open Server Manager by typing the following at a command prompt:
    • servermanager.msc

  2. In the Features Summary section, click Add features.

  3. Select the Desktop Experience check box, and then click Next.

  4. Complete the wizard by clicking Install.

You can uninstall Desktop Experience at any time by using either method above to start the Add Features Wizard. When the wizard opens, clear the Desktop Experience check box, click Next, and then click Remove to complete the wizard.


DirectAccess Overview

DirectAccess allows remote users to securely access internal network file shares, Web sites, and applications without connecting to a virtual private network (VPN). An internal network is also known as a private network or intranet. DirectAccess establishes bi-directional connectivity with an internal network every time a DirectAccess-enabled computer connects to the Internet, even before the user logs on. Users never have to think about connecting to the internal network and IT administrators can manage remote computers outside the office, even when the computers are not connected to the VPN.

You can use the DirectAccess Management Console to set up a DirectAccess infrastructure by performing the following tasks:

  • Specify the client computers that can use DirectAccess by selecting the security groups to which they belong

  • Configure the network adapters on the DirectAccess server that are connected to your internal network and the Internet and the certificates that you want to use for authentication

  • Configure the location of an internal Web site so that DirectAccess client computers can determine when they are located on the internal network

  • Configure the Domain Name Service (DNS) names that must be resolved by internal network DNS servers

  • Identify infrastructure servers (network location, DNS, and management servers)

  • Identify application servers for optional authentication

When you monitor DirectAccess, use the DirectAccess Management Console to determine the state of DirectAccess components that are running on the server.

Additional references

Understanding DirectAccess Components

Understanding DirectAccess Deployment Models

For more information, see the DirectAccess home page on Microsoft Technet (http://go.microsoft.com/fwlink/?LinkID=142598).


Group Policy Management Overview

Group Policy Management includes the Group Policy Management Console (GPMC), the Microsoft Management Console that allows you to manage Group Policy cost effectively for your enterprise.

The Group Policy Management Console simplifies the management of domain-based Group Policy by providing a single experience for managing, editing, and reporting the core aspects of Group Policy. You can think of the GPMC as a one-stop resource for managing your Group Policy needs.

The Group Policy Management Console includes:

  • A user interface that improves the ease of use of Group Policy.

  • Backup and restore of Group Policy objects (GPOs).

  • Import/export and copy/paste of GPOs and Windows Management Instrumentation (WMI) filters.

  • Simplified management of Group Policy–related security.

  • HTML reporting for GPO settings and Resultant Set of Policy (RSoP) data.

  • The ability to include text-based comments in Group Policy objects and registry-based policy settings.

  • Filtered views of registry-based policy settings based on keywords within the title, Help text, or comment of policy settings.

  • Starter Group Policy objects: portable collections of registry-based policy settings, which provide starting points for GPOs.

  • Preferences: twenty-one additional Group Policy extensions that allow you to manage drive mappings, registry settings, local users and groups, services, files, folders, and more without the need to learn a scripting language.


Failover Cluster Overview

This topic contains the following sections:

  • Availability, scalability, and clustering technologies

  • Failover cluster overview

Availability, scalability, and clustering technologies

Windows Server® 2008 provides two clustering technologies: failover clusters and Network Load Balancing (NLB). Failover clusters primarily provide high availability; Network Load Balancing provides scalability and at the same time helps increase availability of Web-based services.

Your choice of cluster technologies (failover clusters or Network Load Balancing) depends primarily on whether the applications you run have long-running in-memory state:

  • Failover clusters are designed for applications that have long-running in-memory state, or that have large, frequently updated data states. These are called stateful applications, and they include database applications and messaging applications. Typical uses for failover clusters include file servers, print servers, database servers, and messaging servers.

  • Network Load Balancing is intended for applications that do not have long-running in-memory state. These are called stateless applications. A stateless application treats each client request as an independent operation, and therefore it can load-balance each request independently. Stateless applications often have read-only data or data that changes infrequently. Front-end Web servers, virtual private networks (VPNs), File Transfer Protocol (FTP) servers, and firewall and proxy servers typically use Network Load Balancing. Network Load Balancing clusters can also support other TCP- or UDP-based services and applications.

Failover cluster overview

By using a failover cluster, you can ensure that users have nearly constant access to important server-based resources. A failover cluster is a set of independent computers that work together to increase the availability of services and applications. The clustered servers (called nodes) are connected by physical cables and by software. If one of the nodes fails, another node begins to provide service through a process known as failover.

You can use the Failover Cluster Manager snap-in to validate failover cluster configurations, create and manage failover clusters, and migrate some resource settings to a cluster running Windows Server 2008 R2.

In Windows Server 2008, the changes to failover clusters (formerly known as server clusters) are aimed at simplifying cluster setup and management, making the clusters more secure and stable, improving networking in clusters, and improving how failover clusters communicate with storage.

What are failover clusters?

A failover cluster is a group of independent servers that are running Windows Server 2008 and working together to increase the availability of services and applications. When a failure occurs on one computer in a cluster, resources are redirected and the workload is redistributed to another computer in the cluster. You can use failover clusters to ensure that users have nearly constant access to important server-based resources.

Hardware and software considerations for failover clusters

Note

A limited set of server roles is available for the Server Core installation option of Windows Server 2008 and for Windows Server 2008 for Itanium-Based Systems.

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

The software used for managing a failover cluster is the Failover Cluster Manager snap-in, which is installed as part of the failover cluster feature in Windows Server 2008 R2. The underlying service that supports failover clusters is the Cluster service.

Installing the failover cluster feature

Use Initial Configuration Tasks or Server Manager to install features. To install the failover cluster feature:

  1. In the list of tasks, click Add features.

  2. In the list of features presented in the wizard, click Failover Clustering.

Managing a failover cluster

Server roles and features are managed by using Microsoft Management Console (MMC) snap-ins. To open the failover cluster snap-in, click Start, click Administrative Tools, and then click Failover Cluster Manager.

Additional references for failover clustering

To learn more about failover clusters, you can view the Help on your server. To do this, open the failover cluster snap-in as described in the previous section, and then press F1.

For more information about failover clusters, see the following resources on the Microsoft Web site:

  • For a list of links to a variety of topics about failover clusters, see http://go.microsoft.com/fwlink/?LinkId=68633.

  • For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137832.

  • For operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137835.

  • For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137836.


Ink and Handwriting Services Overview

Ink and Handwriting Services are optional role features that provide support for pen input and recognition for handwriting and math expressions. The Handwriting Recognition feature requires that Ink Support be installed.

For more information on Ink and Handwriting Services, see Ink and Handwriting Services.

What is Handwriting Recognition?

Handwriting Recognition allows users to launch the Tablet Input Panel (TIP), write in their desired language and insert the automatically converted, recognized text into applications such as Microsoft Outlook® or Word. Personalization, a feature of handwriting recognition, enables the recognizer to learn how and what a user writes, improving that user's handwriting experience over time.

What is Ink Support?

The Ink Support feature includes Tablet PC-related components that were previously included in the Desktop Experience pack for Windows Server 2008, e.g., support for user input using pen digitizers, mice, and touch-screen devices.


Internet Printing Client Overview

The Internet Printing Client feature enables users to connect and print to printers on the local network or over the Internet by using Internet Printing Protocol (IPP). You can use the Internet Printing Client and IPP to connect to the shared printer using a Web browser (if the print server has the Internet Printing role service installed).

To use the Internet Printing Client to connect or print to a print server using IPP:

  • The print server must have the Internet Printing role service and the Web Server (IIS) role installed.

  • The client computer must be able to reach the print server over a local, wide area network (WAN) or Internet connection.

Note

If the client computer can access the print server over a local area network (LAN) or WAN connection, Windows establishes a remote procedure call (RPC) connection to the print server, which is faster than IPP. When you can connect to the print server by using an RPC connection, you do not need the Internet Printing Client.

Additional references

For more information about Internet Printing Client, see the following on the Microsoft Web site:

  • How to Install and Use the Internet Printing Protocol Client (http://go.microsoft.com/fwlink/?LinkId=143901).


iSNS Server Overview

Internet iStorage Name Service Server

The Internet Storage Name Service (iSNS) protocol is used for interaction between iSNS servers and iSNS clients. iSNS clients are computers, also known as initiators, that are attempting to discover storage devices, also known as targets, on an Ethernet network. iSNS facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network.

Note

The Microsoft iSNS Server only supports the discovery of iSCSI devices, and not Fibre Channel devices.

iSNS Server provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. iSNS facilitates a seamless integration of IP networks and manages iSCSI devices. iSNS thereby provides value in any storage network comprised of iSCSI devices.

Features of iSNS Server

  • iSNS Server is a repository of currently active iSCSI nodes, as well as their associated portals, entities, etc.

  • Nodes can be initiators, targets, or management nodes.

  • Typically, initiators and targets register with the iSNS server, and the initiators query the iSNS server for the list of available targets.

  • A dynamic database of the iSCSI devices and related information that are currently available on the network: The database helps provide iSCSI target discovery functionality for the iSCSI initiators on the network. The database is kept dynamic by using the Registration Period and Entity Status Inquiry features of iSNS. Registration Period allows the server to automatically deregister stale entries. Entity Status Inquiry provides the server a functionality similar to ping to determine whether registered clients are still present on the network, and allows the server to automatically deregister those clients which are no longer present.

  • State Change Notification Service: This allows registered clients to be made aware of changes to the database in the iSNS server. It allows the clients to maintain a dynamic picture of the iSCSI devices available on the network.

  • Discovery Domain Service: This allows an administrator to assign iSCSI nodes and portals into one or more groups called discovery domains. Discovery domains provide a zoning functionality by which an iSCSI initiator can only discover those iSCSI targets who have at least one discovery domain in common with it.

Benefits of iSNS Server in iSCSI Storage Area Networks

  • Centralized management

  • Easily scalable to large IP storage networks

  • Extensible

  • Asynchronous notification of changes in the iSCSI storage network

  • Ability to monitor the status and availability of clients

  • Microsoft-preferred discovery method for iSCSI

  • Designed for Windows Logo Program requirement for iSCSI HBAs

iSNS Architectural Components

The following section describes the components included in iSNS Server.

iSNS Protocol (iSNSP)

The iSNS Protocol (iSNSP) is a flexible and lightweight protocol that specifies how iSNS clients and servers communicate. It is suitable for various platforms, including switches and targets as well as server hosts.

The iSNS Protocol is a message-based protocol, with most operations utilizing a request and a corresponding response message which together form a single transaction.

Each protocol message consists of a header followed by a list of attributes. Typically, a source attribute (i.e. the iSCSI name of the requesting node) is followed by one or more key attributes, and optionally by one or more operating attributes. A delimiter attribute is used to separate the operating attributes from key attribute.

  • All attributes are in tag-length-value (TLV) format

  • The length of all attribute values is padded to a multiple of four

  • All fields are in "big-endian" or network byte format

iSNS clients

iSNS clients initiate transactions with iSNS servers by using the iSNSP. iSNS clients are processes that are co-resident in the storage device, and can register device attribute information, download information about other registered clients in a common discovery domain (DD), and receive asynchronous notification of events that occur in their DDs. Management stations are a special type of iSNS client that have access to all DDs stored in the iSNS.

iSNS servers

iSNS servers respond to iSNS protocol queries and requests, and initiate iSNS protocol state change notifications. Properly authenticated information submitted by a registration request is stored in an iSNS database.

iSNS databases

The iSNS database is the information repository for iSNS servers. It maintains information about iSNS client attributes. A directory-enabled implementation of iSNS may store client attributes in a Lightweight Directory Access Protocol (LDAP) directory infrastructure.

iSCSI

iSCSI (Internet Small Computer System Interface) is an encapsulation of SCSI for a new generation of storage devices interconnected with TCP/IP (iSCSI).

iSNS Functional Overview

The following are the services provided by iSNS.

  • A name service providing storage resource discovery

  • Discovery domain and logon control services

  • State change notification

  • Open mapping of Fibre Channel and iSCSI devices

Name registration service

The iSNS provides a registration function to allow all entities in a storage network to register and query the iSNS database. Both targets and initiators can register in the iSNS database, as well as query for information about other initiators and targets. This allows, for example, a client initiator to obtain information about target devices from the iSNS server. This service is modeled on the Fibre Channel Generic Services Name Server described in Internet Engineering Task Force (IETF) request for comment (RFC) documents, with extensions, operating within the context of an IP network.

Discovery domain and logon control service

The discovery domain (DD) service facilitates the partitioning of storage nodes into manageable groupings for administrative and logon control purposes. It allows the administrator to limit the logon process of each host to the more appropriate subset of targets registered in the iSNS. This is important to reduce the number of unnecessary iSCSI logons, and to limit the time that the host spends initializing logon relationships as the size of the storage network increases. Storage nodes must be in at least one common enabled DD in order to obtain information about other storage nodes. Devices can be members of multiple DDs.

Logon control allows targets to delegate their access control or authorization policy to the iSNS server. This helps centralize management of those storage devices that are using the iSNS server. The target node or device downloads the list of authorized initiators from iSNS. Each node or device is uniquely identified by an iSCSI name (also known as iqn). Only initiators that match the required identification and authorization provided by the iSNS will be allowed access by that target node during session establishment.

Placing portals of a network entity into discovery domains allows administrators to indicate the preferred IP portal interface through which storage traffic should access specific storage nodes of that network entity. If no portals of a network entity have been placed into a DD, then queries scoped to that DD report all portals of that network entity. If one or more portals of a network entity have been placed into a DD, then queries scoped to that DD report only those portals that have been explicitly placed in the DD.

DDs can be managed offline by using a separate management computer that is using the iSNSP or SNMP. If the target uses the logon control feature of iSNS, the target delegates management of access control policy (the list of initiators allowed to logon to that target) to the management computers that control the configuration in the iSNS database.

If administratively authorized, a target can upload its own logon control list. This is accomplished using the DDReg message and listing the iSCSI name of each initiator to be registered in the target's DD.

An implementation might sort newly-registered devices that are not assigned to a DD into a default DD contained in a default discovery domain set (DDS) whose initial DDS Status value is enabled. This makes them visible to other devices in the default DD. Other implementations can interpret newly-registered devices as belonging to no DD, making the devices inaccessible to source-scoped iSNSP messages.

The iSNS server uses the source attribute of each iSNSP message to determine the originator of the request and scope the operation to a set of discovery domains. For example, only control nodes are authorized to create or delete discovery domains.

Valid and active discovery domains belong to at least one active DDS. Discovery domains that do not belong to an activated DDS are not enabled. The iSNS server maintains the state of DD membership for all storage nodes, even for those storage nodes that have been deregistered. DD membership is persistent regardless of whether a storage node is actively registered in the iSNS database.

State change notification service

The state change notification (SCN) service allows the iSNS Server to issue notifications about network events that affect the operational state of storage nodes. The iSNS client may register for notifications on behalf of its storage nodes for notification of events detected by the iSNS server. SCNs notify iSNS clients of changes to the iSNS database; they do not necessarily indicate the state of connectivity to peer storage devices in the network. The response of a storage device to receipt of an SCN is implementation-specific; the policy for responding to SCNs is outside of the scope of this module.

There are two types of SCN registrations: Regular registrations and management registrations. Management registrations result in management SCNs, while regular registrations result in regular SCNs. The type of registration and SCN message is indicated in the SCN reply packet (typically a bitmap).

A regular SCN registration indicates that the discovery domain service is used to control the distribution of SCN messages. Receipt of regular SCNs are limited to the discovery domains in which the SCN-triggering event takes place. Regular SCNs do not contain information about discovery domains.

A management SCN registration can only by requested by control nodes. Management SCNs resulting from management registrations are not bound by the discovery domain service. Authorization to request management SCN registrations may be administratively controlled.

An iSNS server should be implemented with sufficient hardware and software resources needed to support the expected number of iSNS clients. However, if resources are unexpectedly exhausted, the iSNS server might refuse SCN service by returning a SCN Registration Rejected (status code 17) event message. The rejection can occur when the network size or current number of SCN registrations has passed an implementation-specific threshold. A client not allowed to register for SCNs can monitor its sessions with other storage devices directly.

The specific notification mechanism by which the iSNS server learns of the events that trigger SCNs is implementation-specific, but can include examples such as explicit notification messages from an iSNS client to the iSNS server, or a hardware interrupt to a switch-hosted iSNS server as a result of link failure.

iSNS usage model

The following is a high-level description of how each type of device in a storage network uses iSNS. Each type of device interacts with the iSNS server as an iSNS client, and must register itself in the iSNS database to access services provided by iSNS.

iSCSI initiator

An iSCSI initiator queries the iSNS server to discover iSCSI target devices. It may also request state change notifications (SCNs) so that it can be notified of new targets on the network after initial startup and discovery. SCNs can also inform the iSCSI initiator of targets that have been removed or are no longer available in the storage network, so that incomplete storage sessions can be gracefully terminated and resources for non-existent targets can be reallocated.

iSCSI target

An iSCSI target is discovered by iSCSI initiators by registering with the iSNS server. It may also register for SCNs to detect the addition or removal of initiators for resource allocation purposes. The iSCSI target device can also register for entity status inquiry (ESI) messages, which allow the iSNS server to monitor the target device's availability in the storage network.

Management station

A management station uses iSNS to monitor storage devices and enable or disable storage sessions by configuring discovery domains. A management station usually interacts with the iSNS server as a control node endowed with access to all iSNS database records and privileges to modify discovery domains. Through manipulation of discovery domains, the management station controls the scope of device discovery for iSNS clients querying the iSNS server.

See Also

  • Features Available in Windows Server 2008 R2


Line Printer Remote Port Monitor Overview

The Line Printer Remote (LPR) Port Monitor allows a computer running Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 to print to the Line Printer Daemon (LPD) service on a UNIX print server.

Note

You do not need to install the LPR Port Monitor to print to a printer or print server using the LPD protocol, unless the print server is a UNIX print server. To use a computer that is running Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 to print to a printer or print server that uses the LPD protocol, you can use the Network Printer Installation Wizard and a Standard TCP/IP printer port, which is faster than an LPR port.

After installing the LPR Port Monitor, Windows adds the LPR Port type to the Network Printer Installation Wizard. To install a printer on an LPR Port, use the following steps:

Install a printer on an LPR Port

  1. Click Start, click Administrative Tools, and then double-click Print Management.

  2. Expand Print Servers, and then right-click the print server to which you want to add the printer, and then click Add Printer. The Network Printer Installation Wizard appears.

  3. Click Create a new port and add a new printer, and then choose LPR Port.

  4. Use the Add LPR compatible printer dialog box to type the IP address or host name of the UNIX print server that is hosting the shared printer, and the name of the print queue.

  5. Click OK, and then follow the instructions in the Network Printer Installation Wizard to choose or install printer drivers and share the printer on the network.

Additional references

For more information about Line Printer Remote Port Monitor, see the following on the Microsoft Web site:

  • Network Printer Ports (http://go.microsoft.com/fwlink/?LinkId=143902)


Message Queuing Overview

Message Queuing (also known as MSMQ) is a messaging infrastructure and a development tool for creating distributed messaging applications for Microsoft Windows. Applications developed for Message Queuing send messages to queues, which are temporary storage locations, from which messages can proceed to their final destination as conditions permit. Such applications can communicate across heterogeneous networks and can send messages between computers that might be temporarily unable to connect to one another. Message Queuing provides the following benefits:

  • Guaranteed message delivery

  • Efficient routing

  • Improved security

  • Support for sending messages within transactions

  • Priority-based messaging

Software products with these features are often referred to in the industry as:

  • Message-queuing software

  • Store-and-forward software

  • Message-oriented middleware

With Message Queuing, end users can communicate across networks and computers that might be offline, regardless of the current state of the network and computers. System administrators can use Message Queuing to efficiently manage large, complex networks of computers and message queues.

This topic describes the features that are available with Message Queuing.

Message Queuing Server

This feature is the core component of Message Queuing, which enables you to perform basic Message Queuing functions. For more information about the Message Queuing Server feature, see What is Message Queuing (http://go.microsoft.com/fwlink/?LinkId=93512).

Directory Service Integration

This feature enables publishing of queue properties to Active Directory, out-of-the-box authentication and encryption of messages using certificates registered in Active Directory, and routing of messages across sites. For more information about the Directory Service Integration feature, see Directory Service Integration Feature (http://go.microsoft.com/fwlink/?LinkId=93513).

Message Queuing Triggers

This feature enables the invocation of a COM component or an executable depending on the filters that you define for the incoming messages in a given queue. For more information about the Message Queuing Triggers feature, see Triggers Overview (http://go.microsoft.com/fwlink/?LinkId=93514).

HTTP Support

This feature enables the sending and receiving of messages over HTTP. For more information about the HTTP Support feature, see Internet Messaging (http://go.microsoft.com/fwlink/?LinkId=93515).

Multicasting Support

This feature enables queuing and sending of multicast messages to a multicast IP address. For more information about the Multicasting Support feature, see IP Multicasting (http://go.microsoft.com/fwlink/?LinkId=93516).

Routing Service

This feature routes messages between different sites and within a site. For more information about the Routing Service feature, see Message Queuing Routing at (http://go.microsoft.com/fwlink/?LinkId=93517).

Message Queuing DCOM Proxy

This feature enables the MSMQ DCOM API to connect to a remote Message Queuing server.

Subqueues

This feature enables you to logically group messages in a queue without creating another physical queue. Subqueues are implicitly created local queues that are logical partitions of a physical queue. Applications can use subqueues to group messages.

Moving Messages

You can move messages in one of three ways:

  • Using the Move Message dialog box.

  • Performing a cut-and-paste operation.

  • Performing a drag-and-drop operation.

You can move messages between subqueues of the same main queue, or from a main queue to its subqueue. You cannot move messages from a main queue to a subqueue of a different main queue or between two main queues or between two subqueues of different main queues.

The message is moved as is, from the source queue to the target queue. The properties of the message remain unchanged, except for the current move count.

Per-Application Dead-Letter Queues

Message Queuing 4.0 introduced per-application dead-letter queues, so that each application can use its own dead-letter queue. An application can request its own dead-letter queue by using the PROPID_M_DEADLETTER_QUEUE property as part of the message. Instead of being sent to the system transactional dead-letter queue, the message is sent to the queue that is specified in the PROPID_M_DEADLETTER_QUEUE property.

The PROPID_M_DEADLETTER_QUEUE can be set to any legal path of a transactional queue. The transactional queue must be local to the queue manager that will move the negative acknowledgment (NACK) message to the queue. A legal path is defined in Queue Path Names (http://go.microsoft.com/fwlink/?LinkId=69583).

Transactional Remote Receive

Transactional remote receive is a transactional receive of a message from a remote queue. There are scenarios where a transactional remote receive is necessary. For example, when work orders from a remote central queue need to be processed across a farm of application servers, a transactional remote receive will enable the message processing to be load-balanced across the server farm.

Ability to Handle a Large Number of Message Queuing Queues

The following new feature is introduced in Message Queuing 5.0, released with Windows 7 and Windows Server 2008 R2:

Message Queuing 5.0 provides functionality to handle a significantly larger number of queues than Message Queuing 4.0. While Message Queuing 4.0 does not impose a specific limit on the number of queues that can be created, performance is negatively impacted if several thousand queues are created. Specifically, start up time of the Message Queuing 4.0 services is greatly increased when loading a very large number of queues into memory because of the queue lookup algorithm that is used. The queue lookup algorithm used by Message Queuing 5.0 at start up has been optimized to dramatically improve start up performance of Message Queuing when a very large number of queues are hosted on the system.

Additional references

Message Queuing Features (http://go.microsoft.com/fwlink/?LinkId=93518)


Multipath I/O Overview

Multipathing Support for High Availability

Windows Server® 2008 includes many enhancements for the connectivity of a computer running a Windows server-class operating system to storage area networking (SAN) devices.

Among the enhancements enabling high availability for connecting Windows-based servers to SANs is integrated Multipath I/O (MPIO) support. Microsoft MPIO architecture supports iSCSI, Fibre Channel and serial attached storage (SAS) SAN connectivity by establishing multiple sessions or connections to the storage array.

Multipathing solutions use redundant physical path components — adapters, cables, and switches — to create logical paths between the server and the storage device. In the event that one or more of these components fails, causing the path to fail, multipathing logic uses an alternate path for I/O so that applications can still access their data. Each network interface card (in the iSCSI case) or HBA should be connected by using redundant switch infrastructures to provide continued access to storage in the event of a failure in a storage fabric component.

Failover times vary by storage vendor, and can be configured by using timers in the Microsoft iSCSI Software Initiator driver, or modifying the Fibre Channel host bus adapter driver parameter settings.

New MPIO features in Windows Server 2008 include a Device Specific Module (DSM) designed to work with storage arrays that support the asymmetric logical unit access (ALUA) controller model (as defined in SPC-3), as well as storage arrays that follow the Active/Active controller model.

Features of the included DSM

The Microsoft DSM provides the following load balancing policies. Note that load balance policies are generally dependent on the controller model (ALUA or true Active/Active) of the storage array attached to Windows-based computers.

  • Failover No load balancing is performed. The application specifies a primary path and a set of standby paths. The primary path is used for processing device requests. If the primary path fails, one of the standby paths is used. Standby paths must be listed in decreasing order of preference (the most preferred path first).

  • Failback Failback is the ability to dedicate I/O to a preferred path whenever it is functioning. If the preferred path fails, I/O is directed to an alternate path until function is restored to the preferred path, but I/O automatically switches back to the preferred path when function is restored.

  • Round-robin The DSM uses all available paths for I/O in a balanced, round-robin fashion.

  • Round-robin with a subset of paths The application specifies a set of paths to be used in a round-robin fashion, and a set of standby paths. The DSM uses paths from primary pool of paths for processing requests, as long as at least one of the paths is available. The DSM uses a standby path only when all primary paths fail. Standby paths must be listed in decreasing order of preference (most preferred path first). If one or more of the primary paths become available, DSM uses the standby paths in their order of preference. For example, given 4 paths — A, B, C, and D — A, B, and C are listed as primary paths, and D is standby path. The DSM chooses a path from A, B, and C in round-robin fashion as long as at least one of them is available.

    If all three fail, the DSM uses D, the standby path. If A, B, or C become available, DSM stops using D and switches to available paths among A, B, and C.

  • Dynamic Least Queue Depth The DSM routes I/O to the path with the least number of outstanding requests.

  • Weighted Path The application assigns weights to each path; the weight indicates the relative priority of a given path. The larger the number, the lower the priority. The DSM chooses the path that has the least weight from among the available paths.

The Microsoft DSM preserves load balance settings even after the computer is restarted. When no policy has been set by a management application, the default policy that is used by the DSM is either Round Robin, when the storage controller follows the true Active/Active model, or simple failover in the case of storage controllers that support the SPC-3 ALUA model. With simple Failover, any one of the available paths can be used as the primary path, and remaining paths are used as standby paths.

Adding and removing MPIO support

To install Multipath I/O on a computer running Windows Server 2008, complete the following steps.

To install Multipath I/O

  1. Open Server Manager.

    To open Server Manager, click Start, point to Administrative Tools, and then click Server Manager.

  2. In the Features area, click Add Features.

  3. On the Select Features page of the Add Features Wizard, select Multipath I/O, and then click Next.

  4. On the Confirm Installation Selections page, click Install.

  5. When installation has completed, click Close.

To install Multipath I/O on a computer by using the Server Manager command line, complete the following steps.

To install Multipath I/O by using a command line

  1. Open a Command Prompt window with elevated privileges.

    Right-click the Command Prompt object on the Start menu, and then click Run as administrator.

  2. Type the following, and press ENTER.

    ServerManagerCmd.exe -install Multipath-IO

  3. When installation has completed, you can verify that Multipath I/O has installed by entering the following command and reviewing the query results in the command window. Multipath I/O should show in the list of installed packages.

    ServerManagerCmd.exe -query

Removing Multipath I/O

To remove Multipath I/O, complete the following steps.

To remove Multipath I/O

  1. Open Server Manager.

    To open Server Manager, click Start, point to Administrative Tools, and then click Server Manager.

  2. In the Features area, click Remove Features.

  3. On the Select Features page of the Add Features Wizard, select Multipath I/O, and then click Next.

  4. On the Confirm Installation Selections page, click Install.

  5. When installation has completed, click Close.

To remove Multipath I/O by using the Server Manager command line, complete the following steps.

To remove Multipath I/O by using a command line

  1. Open a Command Prompt window with elevated privileges.

    Right-click the Command Prompt object on the Start menu, and then click Run as administrator.

  2. Type the following, and press ENTER.

    ServerManagerCmd.exe -remove Multipath-IO

  3. When removal has completed, you can verify that Multipath I/O was removed by entering the following command and reviewing the query results in the command window. Multipath I/O should not be in the list of installed packages.

    ServerManagerCmd.exe -query

Opening and configuring Multipath I/O

After Multipath I/O has been installed, you can open the MPIO Properties dialog box either from within Control Panel, or by clicking MPIO in Administrative Tools on the Start menu.

Configuration and DSM installation

Additional connections through Microsoft MPIO can be configured by using the MPIO Properties dialog box or by using the command line interface.

Adding third-party DSMs

Many storage arrays which are Active/Active and SPC-3-compliant also work with the MPIO universal DSM. Some storage array vendors also provide their own DSMs to interface with the Microsoft MPIO architecture. Third-party DSMs should be installed by using the DSM Install tab in the MPIO Properties dialog box.

The Discover Multi-Paths tab checks for devices that for which multiple paths to the storage array exist. The Device Hardware ID field should be populated automatically, once the check is complete.

If multiple paths to the storage do not exist, or if the storage device is not connected, you can add the device hardware ID manually by providing information on the MPIO-ed Devices tab.

Using the MPclaim command-line tool

Multipath I/O can be managed by using the MPclaim command-line tool.

Note

The command line is the only method of Multipath I/O configuration available on computers running a Server Core installation of Windows Server 2008.

Syntax of MPclaim

mpclaim restart_option install_switch device_switch device_hwid

MPclaim parameters

The following table describes the command parameters you can use with the MPclaim command to manage Multipath I/O by using a command line.

Parameter | Description |
Restart_option | Option | Description
-r | -r | Automatically restarts without prompting
-n | -n | Suppress restart request.
Install_switch | Option | Description
-i | -i | Installs MPIO and adds multipath support for a storage device
-u | -u | Remove MPIO and discontinue support for a storage device
device_switch | Option | Description
-d <device_hwid> | -d <device_hwid> | Specifies devices for which you want MPIO support. Device IDs are separated by a space.
-a | -a | Apply MPIO support to all compatible devices.
-c | -c | Apply MPIO support only to SPC-3 compatible devices. This parameter is only applicable to installation; if you are removing MPIO (by using the -u parameter for install_switch) then -c is interpreted by the command similarly to -a.
device_hwid | device_hwid | IDs of devices to be supported by MPIO, in the format VendorProduct, in which Vendor represents the manufacturer or vendor name, and Product represents the product or model name. Multiple IDs must be delimited by a space. This parameter is used only with the -d device switch option.

See Also

  • Features Available in Windows Server 2008 R2


.NET Framework 3.5.1 Features Overview

.NET Framework 3.5.1 Features in Windows Server 2008

Microsoft .NET Framework 3.5.1 combines the power of the .NET Framework 2.0 and 3.0 APIs with new technologies for building applications that offer appealing user interfaces, protect your customers’ personal identity information, enable seamless and secure communication, and provide the ability to model a range of business processes.

.NET Framework 3.5.1 elements are required by server roles such as Application Server.

Elements of .NET Framework 3.5.1 Features

The following table describes the elements that are part of .NET Framework 3.5.1 Features.

Feature Description

Windows Communication Foundation Activation Components

Windows Communication Foundation (WCF) Activation Components use Windows Process Activation Service to call applications remotely over a network by using protocols such as HTTP, Message Queuing, TCP, and named pipes. Windows Communication Foundation Activation Components allows applications to start and stop dynamically in response to incoming work items, resulting in application hosting that is more robust, manageable, and efficient.

  • HTTP Activation

HTTP Activation supports process activation by using HTTP. Applications that use HTTP Activation can start and stop dynamically in response to work items transmitted over the network by using HTTP.

  • Non-HTTP Activation

Non-HTTP Activation supports process activation by using either Message Queuing, TCP, or named pipes. Applications that use Non-HTTP Activation can start and stop dynamically in response to work items transmitted over the network by using either Message Queuing, TCP, or named pipes.

Additional resources for .NET Framework 3.5.1 Features

For more information about implementing .NET Framework 3.5.1 Features in your enterprise, see the .NET Framework Developer Center (http://go.microsoft.com/fwlink/?LinkId=94265) on MSDN.

See Also

  • What's New in the .NET Framework Version 3.5 SP1


Network Load Balancing Overview

This topic contains the following sections:

  • Availability, scalability, and clustering technologies

  • Network Load Balancing overview

Availability, scalability, and clustering technologies

Windows Server 2008 R2 provides two clustering technologies: failover clusters and Network Load Balancing (NLB). Failover clusters primarily provide high availability; Network Load Balancing provides scalability and at the same time helps increase availability of Web-based services.

Your choice of cluster technologies (failover clusters or Network Load Balancing) depends primarily on whether the applications you run have long-running in-memory state:

  • Failover clusters are designed for applications that have long-running in-memory state, or that have large, frequently updated data states. These are called stateful applications, and they include database applications and messaging applications. Typical uses for failover clusters include file servers, print servers, database servers, and messaging servers.

  • Network Load Balancing is intended for applications that do not have long-running in-memory state. These are called stateless applications. A stateless application treats each client request as an independent operation, and therefore it can load-balance each request independently. Stateless applications often have read-only data or data that changes infrequently. Front-end Web servers, virtual private networks (VPNs), File Transfer Protocol (FTP) servers, and firewall and proxy servers typically use Network Load Balancing. Network Load Balancing clusters can also support other TCP- or UDP-based services and applications.

Network Load Balancing overview

The Network Load Balancing (NLB) service enhances the availability and scalability of Internet server applications such as those used on Web, FTP, firewall, proxy, virtual private network (VPN), and other mission-critical servers.

What are NLB clusters?

A single computer running Windows can provide a limited level of server reliability and scalable performance. However, by combining the resources of two or more computers running one of the products in Windows Server 2008 R2 into a single virtual cluster, NLB can deliver the reliability and performance that Web servers and other mission-critical servers need.

Each host runs a separate copy of the desired server applications (such as applications for Web, FTP, and Telnet servers). NLB distributes incoming client requests across the hosts in the cluster. The load weight to be handled by each host can be configured as necessary. You can also add hosts dynamically to the cluster to handle increased load. In addition, NLB can direct all traffic to a designated single host, which is called the default host.

NLB allows all of the computers in the cluster to be addressed by the same set of cluster IP addresses, and it maintains a set of unique, dedicated IP addresses for each host. For load-balanced applications, when a host fails or goes offline, the load is automatically redistributed among the computers that are still operating. When a computer fails or goes offline unexpectedly, active connections to the failed or offline server are lost. However, if you bring a host down intentionally, you can use the drainstop command to service all active connections prior to bringing the computer offline. In any case, when it is ready, the offline computer can transparently rejoin the cluster and regain its share of the workload, which allows the other computers in the cluster to handle less traffic.

Hardware and software considerations for NLB clusters

  • NLB is installed as a standard Windows networking driver component.

  • NLB requires no hardware changes to enable and run.

  • NLB Manager enables you to create new NLB clusters and to configure and manage clusters and all of the cluster's hosts from a single remote or local computer.

  • NLB lets clients access the cluster by using a single, logical Internet name and virtual IP address—known as the cluster IP address (it retains individual names for each computer). NLB allows multiple virtual IP addresses for multihomed servers.

    Note

    In the case of virtual clusters, the servers do not need to be multihomed to have multiple virtual IP addresses.

  • NLB can be bound to multiple network adapters, which allows you to configure multiple independent clusters on each host. Support for multiple network adapters is different from virtual clusters in that virtual clusters allow you to configure multiple clusters on a single network adapter.

Installing the NLB feature

To use Network Load Balancing (NLB), a computer must have only TCP/IP on the adapter on which NLB is installed. Do not add any other protocols (for example, IPX) to this adapter. NLB can load balance any application or service that uses TCP/IP as its network protocol and is associated with a specific Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port.

To install and configure NLB, you must use an account that is listed in the Administrators group on each host. If you are not using an account in the Administrators group as you install and configure each host, you will be prompted to provide the logon credentials for such an account. To set up an account that NLB Manager will use by default: in NLB Manager, expand the Options menu, and then click Credentials. We recommend that this account not be used for any other purpose.

You can use Initial Configuration Tasks or Server Manager to install NLB. To install NLB, in the list of tasks, click Add features and in the list of features in the wizard, click Network Load Balancing.

Managing NLB

Server roles and features are managed by using Microsoft Management Console (MMC) snap-ins. To open the Network Load Balancing Manager snap-in, click Start, click Administrative Tools, and then click Network Load Balancing Manager. You can also open Network Load Balancing Manager by typing Nlbmgr at a command prompt.

Additional references for NLB

To learn more about NLB, you can view the Help on your server. To do this, open Network Load Balancing Manager as described in the previous section and press F1.

  • For deployment information for NLB, see http://go.microsoft.com/fwlink/?LinkId=87253.

  • For operations information for NLB, see http://go.microsoft.com/fwlink/?LinkId=87254.

  • For troubleshooting information for NLB, see http://go.microsoft.com/fwlink/?LinkId=87255.


Peer Name Resolution Protocol Overview

Peer Name Resolution Protocol (PNRP) is used by Windows Peer-to-Peer Networking to resolve names for peer communication.

In peer-to-peer environments, peers rely on name resolution systems to resolve each other's network locations (addresses, protocols, and ports) from names or other types of identifiers. PNRP provides a secure, scalable, and dynamic name registration and name resolution protocol first developed for Windows XP, and then upgraded in Windows Vista and Windows Server 2008. PNRP works very differently from traditional name resolution systems, opening up new possibilities for applications.

PNRP has the following properties:

  • Distributed and serverless for scalability and reliability.

  • Effortless name publication without using third-party applications.

  • Real-time updates to identifiers and addresses.

  • Identifies more than just computers.

  • Protected name publication (secure and non-secure name publication).

For PNRP troubleshooting information, see Peer Name Resolution Protocol (PNRP) Client (http://go.microsoft.com/fwlink/?LinkId=143296).


Quality Windows Audio Video Experience Overview

Quality Windows Audio Video Experience (qWave)

Quality Windows Audio Video Experience (qWave) is a networking platform for audio video (AV) streaming applications on IP home networks. qWave enhances AV streaming performance and reliability by ensuring network quality-of-service (QoS) for AV applications. It provides mechanisms for admission control, run time monitoring and enforcement, application feedback, and traffic prioritization.

On Windows Server platforms, qWave provides only rate-of-flow and prioritization services.

For more information about qWave, see the Windows Server® 2008 TechCenter (http://go.microsoft.com/fwlink/?LinkId=48541).


Remote Assistance Overview

Understanding Remote Assistance

Computer users, particularly users without much technical expertise, often have configuration problems or usage questions that are difficult for a support professional to diagnose and fix over the phone. Remote Assistance (RA) solves these problems by enabling support personnel to view the user’s desktop in real time. The user seeking assistance can demonstrate the nature of the problem to the support person. This is a quicker and more efficient way to communicate a problem than using words or e-mail. If necessary, the user can also give the support person permission to assume shared interactive control of the user’s computer to show the user how to resolve the problem. The result of using Remote Assistance is faster problem resolution, an improved support experience, and a lower Total Cost of Ownership (TCO) for supporting end users in large, corporate environments.

For more information about RA, see Windows Remote Assistance: frequently asked questions (http://go.microsoft.com/fwlink/?LinkId=143295) on the Microsoft Web site.

See Also

  • Features Available in Windows Server 2008 R2


Remote Differential Compression Overview

The Remote Differential Compression (RDC) feature is a set of application programming interfaces (APIs) that applications can use to determine if a set of files have changed, and if so, to detect which portions of the files contain the changes. RDC detects insertions, removals, and rearrangements of data in files, which enables an application to replicate only the changed portions of a file. This is useful when replicating files over a limited-bandwidth network such as a wide area network (WAN) connection.

To install RDC, open Server Manager and then use the Add Features Wizard, or type the following command at an elevated command prompt: Servermanagercmd -Install Rdc

Note

You do not need to install the RDC feature to use RDC with DFS Replication or AD DS.

Additional references

  • Remote Differential Compression on MSDN (http://go.microsoft.com/fwlink/?LinkId=94399)

  • DFS Replication Frequently Asked Questions (http://go.microsoft.com/fwlink/?LinkId=93056)


Remote Server Administration Tools Overview

To ease remote server management, Microsoft has included a remote administration tools pack with Windows Server® 2008 R2.

You can install the Remote Server Administration Tools pack on computers running the Windows Server 2008 R2 operating system, and use the Remote Server Administration Tools pack to manage computers running either Windows Server 2008 R2, Windows Server 2008, or for some tools, Windows Server 2003.

What is the Remote Server Administration Tools pack?

The Remote Server Administration Tools pack is a feature available with Windows Server 2008 R2 that enables remote management of Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003 from a computer running Windows Server 2008 R2, by allowing you to open and run management tools and snap-ins to manage roles, role services, or features on a remote computer.

As with other management tools included with Windows Server 2008 R2, Remote Server Administration Tools are secure by default. The default Remote Server Administration Tools configuration opens only those ports and enables only those services required for remote management to work.

For more information about roles, role services, and features in Windows Server 2008 R2, see the topic "Roles, Role Services, and Features" in the Server Manager Help.

Roles and features you can manage with Remote Server Administration Tools

Management tools for the following roles and features are available in Windows Server 2008 R2.

Remote Server Administration Tools for roles

Note

This list of roles may have been updated since this content was published. To check for updates, see the Windows Server 2008 R2 TechCenter (http://go.microsoft.com/fwlink/?LinkId=122006).

Remote Server Administration Tools role Description

Active Directory Certificate Services Tools

Active Directory Certificate Services Tools includes the Certification Authority, Certificate Templates, Enterprise PKI, and Online Responder Management snap-ins.

Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS) Tools

Active Directory Domain Services includes Active Directory Users and Computers, Active Directory Domains and Trusts, Active Directory Sites and Services, Active Directory Administrative Center, Server for NIS tools, the Active Directory Windows PowerShell provider and cmdlets, and other snap-ins and command-line tools for remotely managing Active Directory Domain Services.

Active Directory Lightweight Directory Services Tools includes Active Directory Sites and Services, ADSI Edit, Schema Manager, and other snap-ins and command-line tools for managing Active Directory Lightweight Directory Services.

Active Directory Rights Management Services (AD RMS) Tools

Active Directory Rights Management Services (AD RMS) Tools includes the Active Directory Rights Management Services (AD RMS) snap-in.

DHCP Server Tools

DHCP Server Tools includes the DHCP snap-in.

DNS Server Tools

DNS Server Tools includes the DNS Manager snap-in and dnscmd.exe command-line tool.

Fax Server Tools

Fax Server Tools includes the Fax Service Manager snap-in.

File Services Tools

File Services Tools include the following:

  • Distributed File System Tools includes the DFS Management snap-in, and the dfsradmin.exe, dfsrdiag.exe, dfscmd.exe, dfsdiag.exe, and dfsutil.exe command-line tools.

  • File Server Resource Manager Tools includes the File Server Resource Manager snap-in, and the filescrn.exe and storrept.exe command-line tools.

  • Services for Network File System Tools includes the Network File System snap-in, and the nfsadmin.exe, showmount.exe, and rpcinfo.exe command-line tools.

Hyper-V™ Tools

Hyper-V Tools includes the Hyper-V Manager snap-in and other tools for managing Hyper-V.

Network Policy and Access Services Tools

Network Policy and Access Services Tools includes the Routing and Remote Access and Health Registration Authority snap-ins.

Print and Document Services Tools

Print and Document Services Tools includes the Print Management snap-in.

Remote Desktop Services Tools

Remote Desktop Services Tools includes the RemoteApp Manager, RD Gateway Manager, and RD Licensing Manager snap-ins.

  • RD Connection Broker Tools includes the RemoteApp and Desktop Connection Manager snap-ins.

Web Server (IIS) Tools

Web Server (IIS) Tools includes the Internet Information Services (IIS) 6.0 Manager and IIS Manager snap-ins.

Windows Deployment Services Tools

Windows Deployment Services Tools includes the Windows Deployment Services snap-in, wdsutil.exe command-line tool, and Remote Install extension for the Active Directory Users and Computers snap-in.

Remote Server Administration Tools for features

Note

This list of features may have been updated since this content was published. To check for updates, see the Windows Server 2008 R2 TechCenter (http://go.microsoft.com/fwlink/?LinkId=122006).

Remote Server Administration Tools feature | Description
BitLocker Drive Encryption Administration Utilities | BitLocker Drive Encryption Administration Utilities includes the manage-bde.wsf script, and the BitLocker Active Directory Recovery Password Viewer.
BITS Server Extensions Tools | BITS Server Extensions Tools includes the Internet Information Services (IIS) 6.0 Manager and IIS Manager snap-ins.
Failover Clustering Tools | Failover Clustering Tools includes the Failover Cluster Manager snap-in and the cluster.exe command-line tool.
Network Load Balancing Tools | Network Load Balancing Tools includes the Network Load Balancing Manager snap-in, and the nlb.exe and wlbs.exe command-line tools.
SMTP Server Tools | SMTP Server Tools includes the Internet Information Services (IIS) 6.0 Manager snap-in.
WINS Server Tools | Windows Internet Name Service (WINS) Server Tools includes the WINS snap-in.

Installing Remote Server Administration Tools

Note

You must either be a member of the Administrators group on the server on which you want to install the Remote Server Administration Tools pack, or you must be logged on to the computer using the built-in Administrator account. Additionally, if you are installing Remote Server Administration Tools by using the command-line interface, you must open the Command Prompt window with elevated privileges.

You can install Remote Server Administration Tools in one of the following ways.

  • Add Features Wizard. Commands that open the Add Features Wizard are found in three locations.

    • Server Manager. Server Manager opens by default when the Initial Configuration Tasks window is closed, or you can open it by clicking Server Manager on the Administrative Tools menu.

    • Initial Configuration Tasks. The Initial Configuration Tasks window opens by default after starting a computer running Windows Server 2008.

    • Control Panel. Open Control Panel, open Programs and Features, and then click Turn Windows features on or off. A command in the Server Manager home page opens the Add Features Wizard.

  • Windows PowerShell. To install Remote Server Administration Tools by using Windows PowerShell, see the topic see the topic "Installing the Remote Server Administration Tools pack" in the Remote Server Administration Tools help. The Windows PowerShell cmdlet set for Server Manager can be used either to install or remove Remote Server Administration Tools.

  • Server Manager command line. To install Remote Server Administration Tools by using the Server Manager command line, see the topic "Installing the Remote Server Administration Tools pack" in the Remote Server Administration Tools help. Because of security restrictions imposed by User Account Control, you must open the Command Prompt with elevated privileges by right-clicking the Command Prompt executable, or the Command Prompt object on the Start menu, and then clicking Run as administrator.

Note

When you install tools for specific roles, role services, and features within Remote Server Administration Tools, you install only a set of snap-ins and tools for remote management of those roles, role services, and features installed on other computers. Installing Remote Server Administration Tools does not install any roles or features on the local computer.

Managing with Remote Server Administration Tools

To manage roles, role services, or features on remote computers by using Remote Server Administration Tools, you must specify in the snap-in or management tool the name of the computer on which the role, role service, or feature that you want to manage is installed. Typically, in a snap-in, you can specify the remote computer by clicking the Connect to another computer command in the Actions pane, or on the Action menu.

For More Information

To learn more about Remote Server Administration Tools, you can view the Help on your server. To do this, search for and then double-click RSAT.chm to open it. RSAT.chm is typically stored in %windir%\Help\mui\0409.

For more information about Remote Server Administration Tools and managing roles, role services, and features by using their remote administration tools, see the Windows Server 2008 R2 TechCenter (http://go.microsoft.com/fwlink/?LinkId=122006).


RPC over HTTP Proxy Overview

RPC over HTTP Proxy

Objects that receive remote procedure calls (RPC) over Hypertext Transfer Protocol (HTTP) use RPC Over HTTP Proxy. This proxy makes it possible for clients to discover these objects even if the objects are moved between servers or if they exist in discrete areas of the network, usually for security reasons.

Additional resources for RPC over HTTP Proxy

For more information about RPC over HTTP Proxy, see the following Web sites:

  • Remote Procedure Calls Using RPC over HTTP (http://go.microsoft.com/fwlink/?LinkId=93826)

  • Application Server (http://go.microsoft.com/fwlink/?LinkID=93880)


Services for Network File System Overview

Services for Network File System (NFS) provides a file sharing solution for enterprises that have a mixed Windows and UNIX environment. With Services for NFS, you can transfer files between computers running Windows Server 2008 and UNIX operating systems using the NFS protocol.

For more information about Services for NFS, see the Windows Server TechCenter (http://go.microsoft.com/fwlink/?LinkId=92798).

What new functionality is provided in Windows Server 2008 R2?

Services for NFS includes the following improvements between Windows Server 2008 and Windows Server 2008 R2:

  • Netgroup support. Services for NFS supports netgroups, which are used to create network-wide named groups of hosts. Netgroups simplify control of user and group login and shell access to remote computers, and enable system administrators to more easily manage NFS access control lists.

  • RPCSEC_GSS support. Services for NFS provides native support for RPCSEC_GSS, which enables applications to take advantage of GSS-API security features.

    Note

    RPCSEC_GSS support includes authentication and integrity. Privacy is not provided.

  • Using WMI to manage Server for NFS. WMI enables NFS remote management by allowing Web Based Enterprise Management (WBEM) applications to communicate with WMI providers on the local or remote computers to manage WMI objects.

  • Unmapped UNIX User access. An Unmapped UNIX User option is now available for NFS shares. Windows servers can be used for storing NFS data without creating UNIX-to-Windows account mapping. Mapped user accounts will use standard Windows security identifiers (SIDs) and unmapped users will use Custom NFS SIDs.

Note

Although User Name Mapping server functionality does not exist for Windows Server 2008 R2, User Name Mapping client functionality is present. Services for NFS can still retrieve mappings from existing legacy User Name Mapping servers.

Additional references

For more information about Services for NFS, see the following Web site:

  • Windows Server TechCenter (http://go.microsoft.com/fwlink/?LinkId=92798).


Simple Mail Transfer Protocol Overview

Windows Server® 2008 SMTP Server uses the Internet-standard Simple Mail Transfer Protocol (SMTP) to transport and deliver messages based on specifications in Request for Comments (RFC) 2821 and RFC 2822. It also includes enhancements that build on the basic delivery functions of the protocol. Various options help you control the routing and delivery of messages, and configure more secure communications.

SMTP Server Features

SMTP Server provides the following features.

  • Standard Internet Protocol Support SMTP Server provides full support for SMTP and is compatible with SMTP mail clients.

  • Scalability With SMTP Server, you can configure SMTP virtual servers to support multiple domains and hundreds of client connections in a single-server configuration.

  • Easy Administration and Integration with the Windows Server 2008 Operating System SMTP Server uses a Microsoft Management Console for administration. SMTP virtual servers are created and configured by using Internet Information Services (IIS) 6.0 Manager. Administrators can use other Windows Server 2008 administration features including Simple Network Management Protocol (SNMP), event logs, and transaction logs to collect usage statistics, track messages and transactions, and examine usage patterns.

  • Advanced Security SMTP Server supports the use of Transport Layer Security (TLS) for encrypting transmissions.

  • Directed Mail Drop and Pickup For the default domain, SMTP Server supports placement of all incoming messages directly into a Drop directory. This means you can use SMTP Server as a mail receiver for other applications. In addition to connecting to a TCP port to send messages, applications can also use a Pickup directory. After a message that is formatted as a text file is copied to the Pickup directory, SMTP Server delivers it.

See Also

  • Features Available in Windows Server 2008 R2


Simple Network Management Protocol Overview

The Simple Network Management Protocol (SNMP) is a network management standard widely used in TCP/IP networks.

SNMP provides a method of managing network hosts such as workstation or server computers, routers, bridges, and hubs from a centrally-located computer running network management software. SNMP performs management services by using a distributed architecture of management systems and agents.

Because network management is critical for both auditing and resource management, SNMP can be used to:

  • Configure remote devices. Configuration information can be sent to each networked host from the management system.

  • Monitor network performance. You can track the speed of processing and network throughput and collect information about the success of data transmissions.

  • Detect network faults or inappropriate access. You can configure trigger alarms on network devices when certain events occur. When an alarm is triggered, the device forwards an event message to the management system. Common types of alarms include a device being shut down and restarted, a link failure being detected on a router, and inappropriate access.

  • Audit network usage. You can monitor both overall network usage to identify user or group access and types of usage for network devices and services.

SNMP Service

The Simple Network Management Protocol (SNMP) service is an optional feature that can be installed after the TCP/IP protocol has been successfully configured.

The SNMP service provides an SNMP agent that allows remote, centralized management of computers running:

  • Windows Vista®

  • Windows Server® 2008

  • Microsoft® Windows® XP

  • Microsoft Windows 2000

  • Windows Server 2003 operating systems

The SNMP agent also allows management of the following services:

  • Windows XP or the Windows Server 2003 operating systems and Microsoft Windows 2000-based WINS

  • Windows XP or the Windows Server 2003 operating systems and Windows 2000-based DHCP

  • Windows XP or the Windows Server 2003 operating systems and Windows 2000-based Internet Information Services (IIS)

  • LAN Manager

To access the information that the SNMP agent service provides, you need at least one SNMP management system software application. The SNMP service supports, but does not currently include, SNMP management software. SNMP management software must be running on the host, which acts as the management system.


Simple TCP/IP Services Overview

Simple TCP/IP Services provides support for the optional TCP/IP protocol services listed in the following table.

Protocol | Description | RFC
Character Generator (CHARGEN) | Sends data made up of the set of 95 printable ASCII characters. Useful as a debugging tool for testing or troubleshooting line printers. | 864
Daytime | Returns messages containing the day of the week, month, day, year, current time (in hh:mm:ss format), and time-zone information. Some programs can use the output from this service for debugging or monitoring variations in system clock time or on a different host. | 867
Discard | Discards all messages received on this port without response or acknowledgment. Can serve as a null port for receiving and routing TCP/IP test messages during network setup and configuration or, in some cases, can be used by programs as a message discard function. | 863
Echo | Echoes back data from any messages it receives on this server port. Echo can be useful as a network debugging and monitoring tool. | 862
Quote of the Day (QUOTE) | Returns a quotation as one or more lines of text in a message. Quotations are taken at random from the following file: systemroot\System32\Drivers\Etc\Quotes. A sample quote file is installed with the Simple TCP/IP Services. If this file is missing, the quote service fails. | 865

All of these protocol services are classified as elective Internet standards and are defined and described in the specified Request for Comments (RFC) document listed in the table. For more information about these protocol services, see the RFCs.

Important

Do not install Simple TCP/IP Services unless you specifically need this computer to support communication with other systems that use these protocol services.

Note

After Simple TCP/IP Services are installed, you cannot enable or disable the separate services individually.

See Also

  • Features Available in Windows Server 2008 R2


SNMP WMI Provider Overview

The Microsoft Windows Management Instrumentation (WMI) technology is the Microsoft implementation of the Distributed Management Task Force (DMTF) Web-Based Enterprise Management (WBEM) initiative that extends the Common Information Model (CIM) to represent management objects in Windows-based management environments. The Common Information Model, also a DMTF standard, is an extensible data model for logically organizing management objects in a consistent, unified manner in a managed environment.

Based on the Common Information Model, WBEM is a DMTF initiative and technology that establishes management infrastructure standards and provides a standardized way to access information from various hardware and software management systems in an enterprise environment. Using WBEM standards, developers can create tools and technologies that reduce the complexity and costs of enterprise management. By providing such standards, WBEM contributes to industry-wide efforts to lower total cost of ownership (TCO). TCO refers to the administrative costs associated with computer hardware and software purchases, deployment and configuration, hardware and software updates, training, maintenance, and technical support.

WBEM provides a point of integration through which data from management sources can be accessed, and it complements and extends existing management protocols and instrumentation such as Simple Network Management Protocol (SNMP), Desktop Management Interface (DMI), and Common Management Information Protocol (CMIP).

Windows Management Instrumentation Technology

The Windows Management Instrumentation (WMI) technology is a management infrastructure that supports the syntax of CIM, the Managed Object Format (MOF), and a common programming interface. The MOF syntax defines the structure and contents of the CIM schema in human and machine-readable form. Windows Management Instrumentation offers a powerful set of services, including query-based information retrieval and event notification. These services and the management data are accessed through a Component Object Model (COM) programming interface. The WMI scripting interface also provides scripting support.

The WMI technology provides:

  • Access to monitor, command, and control any managed object through a common, unifying set of interfaces, regardless of the underlying instrumentation mechanism. WMI is an access mechanism.

  • A consistent model of Windows operating system operation, configuration, and status.

  • A COM Application Programming Interface (API) that supplies a single point of access for all management information.

  • Interoperability with other Windows management services. This approach can simplify the process of creating integrated, well-architected management solutions.

  • A flexible, extensible architecture. Developers can extend the information model to cover new devices, applications, and so on, by writing code modules called WMI providers.

  • Extensions to the Windows Driver Model (WDM) to capture instrumentation data and events from device drivers and kernel-side components.

  • A powerful event architecture. This allows management information changes to be identified, aggregated, compared, and associated with other management information. These changes can also be forwarded to local or remote management applications.

  • A rich query language that enables detailed queries of the information model.

  • A scriptable API which developers can use to create management applications. The scripting API supports several languages, including Microsoft Visual Basic; Visual Basic for Applications (VBA); Visual Basic, Scripting Edition (VBScript); Microsoft JScript development software. Besides VBScript and JScript, developers can use any scripting language implementation that supports Microsoft ActiveX scripting technologies with this API (for example, a Perl scripting engine). Additionally, you can use the Windows Script Host or Microsoft Internet Explorer to write scripts using this interface. Windows Script Host, like Internet Explorer, serves as a controller engine of ActiveX scripting engines. Windows Script Host supports scripts written in VBScript, and JScript.

WMI Architecture Overview

The WMI technology architecture consists of the following:

  • A management infrastructure - This includes the CIM Object Manager, which provides applications with uniform access to management data and a central storage area for management data called the CIM Object Manager repository.

  • WMI Providers - These function as intermediaries between the CIM Object Manager and managed objects. Using the WMI APIs, providers supply the CIM Object Manager with data from managed objects, handle requests on behalf of management applications, and generate event notifications.

The management infrastructure consists of CIM Object Manager and the CIM Object Manager repository. Applications depend on the Object Manager to handle the interface between management applications and data providers. WMI facilitates these communications by providing a common programming interface to Windows management services using COM. This COM API supplies event notification and query processing services, and can be used in several programming language environments such as C and C++. The CIM Object Manager repository holds the CIM and extension schemas, and data information or data source details. CIM Object Manager uses the schema data in this repository when servicing requests from management applications for managed objects.

Managed objects are either physical or logical enterprise components that are modeled using CIM. For example, a managed object can be hardware such as a cable, or software such as a database application. Management applications can access managed objects through CIM Object Manager.

Management applications are applications or Windows services that use or process information originating from managed objects. Management applications can access managed object information by making a request to CIM Object Manager through one of the methods in the WMI API.

WMI providers are standard COM and Distributed Component Object Model (DCOM) servers that function as mediators between managed objects and the CIM Object Manager. If the CIM Object Manager receives a request from a management application for data that is not available from the CIM Object Manager repository or for event notifications that are not supported by the CIM Object Manager, it forwards the request to a WMI provider. Providers supply data and event notifications for managed objects that are specific to their particular domain.

To implement a provider, you should use one of the following supported server types:

• Microsoft Windows 2008 services, local or remote.

• Standard executables (.exe files), local or remote.

• In-process dynamic-link libraries (DLLs).

Note that local or remote Windows 2008 services and standard executables are recommended server types.

WMI ships with built-in providers (or standard providers) that supply data from sources such as the system registry. The built-in providers include:

  • Active Directory Provider - Acts as a gateway to all the information stored in the Active Directory service. Allows information from both WMI and Active Directory to be accessed using a single API.

  • Windows Installer Provider - Allows complete control of Windows Installer and installation of software through WMI. Also supplies information about any application installed with Windows Installer.

  • Performance Counter Provider - Exposes the raw performance counter information used to compute the performance values shown in the System Monitor tool. Any performance counters installed on a system will automatically be visible through this provider.

  • Registry Provider - Allows Registry keys to be created, read, and written. WMI events can be generated when specified Registry keys are modified

  • SNMP Provider - Acts as a gateway to systems and devices that use the Simple Network Management Protocol (SNMP) for management. SNMP MIB object variables can be read and written. SNMP traps can be automatically mapped to WMI events.

  • Event Log Provider - Provides access to data and event notifications from the Windows Server 2008 Event Log.

  • Win32 ProviderProvides information about the operating system, computer system, peripheral devices, file systems and security information.

  • WDM Provider - Supplies low level Windows Driver Model driver information for user input devices, storage devices, network interfaces, and communications ports.

  • View Provider - Allows new aggregated classes to be built up from existing classes. Source classes can be filtered for only the information of interest, information from multiple classes can be combined into a single class and data from multiple machines can be aggregated into a single view.

The WMI technology also provides support for third party custom providers. Custom providers can be used to service requests related to managed objects that are environment-specific. Providers typically use the MOF language to define and create classes. Providers use the WMI API to access the CIM Object Manager repository, and to respond to CIM Object Manager requests made initially by applications.

Simple Network Management Protocol Overview

Simple Network Management Protocol (SNMP) is a network management standard that defines a strategy for managing TCP/IP networks.

SNMP uses a distributed architecture that includes:

  • Multiple managed nodes, each with an SNMP entity called an agent which provides remote access to management instrumentation.

  • At least one SNMP entity referred to as a manager which runs management applications to monitor and control managed elements. Managed elements are devices such as hosts, routers, and so on; they are monitored and controlled by accessing their management information.

  • A management protocol, SNMP, is used to convey management information between the management stations and agents. Management information refers to a collection of managed objects that reside in a virtual information store called a Management Information Base (MIB).

SNMP Messages

To communicate host information, management systems and agents use SNMP messages. These messages are sent using the User Datagram Protocol (UDP) and are routed between the management system and host by using the Internet Protocol (IP).

A Management Information Base contains the information requested by the management system. The MIB for a networked computer may include information on the configuration and performance of the network interface card, the available hard drive space, the version of drivers and applications, and so on. Additional MIBs may be written and loaded, to expose the data that is specified for collection, as long as the system itself supports the collection of the requested information.

Processing Information Requests

When a management system requests information, the following sequence occurs:

  1. A management system sends a request to an agent using the agent's IP address.

  2. The agent forms an SNMP datagram that contains an SNMP message and the community name to which the management system belongs.

  3. The SNMP agent receives the datagram and confirms the community name. If the community name is valid, the SNMP agent retrieves the appropriate data. Otherwise, if the community name is invalid, the request is rejected. If the agent has been configured to send an authentication trap, a trap message is sent.

  4. The SNMP datagram is returned to the management system with the requested information.

Messages

The following SNMP message types are used:

  • GetThis is a request message. SNMP management systems use Get messages to request information about a MIB entry on an SNMP agent.

  • GetnextA type of request message that can be used to browse an entire tree of managed objects.

  • GetbulkA type of request that specifies that the agent transfer as much data as possible, within the limits of message size.

  • SetThis is used to send and assign an updated MIB value to an agent.

  • Notify (or Trap)This is an unsolicited message that an agent sends to a SNMP management system when it detects a certain type of event has occurred locally on the managed host.

SNMP events (or traps) are sent unsolicited to a management station that filters the events; therefore, network traffic is involved. With WMI, the events are filtered locally and only those passing the filter criteria are sent over the network, thus reducing the required bandwidth for events of interest.

WMI SDK support for SNMP

The SNMP Provider includes the following components:

  • Class, instance, and event Providers that integrate the SNMP information modeling and processing into WMI. These SNMP providers map collections of object values to property values of CIM class instances.

  • An SNMP information module compiler that compiles native SNMP schema information into the format that CIM uses.

SNMP Providers

The SNMP Providers return dynamic information. You can specify the set of classes that the instance Provider will operate against in one of two ways:

  • Statically - By creating classes in the CIM object repository namespace associated with the proxy device.

  • Dynamically - By using the SNMP class Provider, which returns the set of classes located within the SNMP Module Information Repository (SMIR) namespace.

Additionally, you can also specify whether or not to use correlation for the set of classes returned from the SMIR namespace. Correlated classes define the set of classes that a given SNMP agent is known to support at the time the enumeration occurs. Noncorrelated enumeration returns all classes present within the SMIR namespace, regardless of whether the agent device supports them or not.

The SNMP Providers include:

  • SNMP class and instance providers, which applications use to access and modify data pertaining to SNMP devices.

  • SNMP event providers, which generate events from SNMP traps and notifications. These report the same types of events, but in different formats: Encapsulated and Referent. Encapsulated means that the event class has simple properties describing the information mapped directly from the TRAP-TYPE and NOTIFICATION-TYPE macros, described in the next section. Referent classes abstract the information present within the macros so that properties which share the same class and instance are presented as embedded objects. This allows extraction of the __RELPATH so that the unique instance to which the trap is associated can be retrieved after the receipt of the event. To choose a format, consumers register for a particular class of events.

Mapping Device Data to CIM Classes

The SNMP Providers map device data to CIM classes through the following methods:

  • Enumerating SNMP Class Definitions. To enumerate a set of class definitions, applications can call IWbemServices::CreateClassEnum or IWbemServices::CreateClassEnumAsync.

    MIB objects are mapped to SNMP CIM classes using the OBJECT-TYPE macro; events are mapped to classes using the TRAP-TYPE and NOTIFICATION-TYPE macros.

    The OBJECT-TYPE macro is used to describe the basic characteristics of a MIB object. The SNMPv1 TRAP-TYPE and SNMPv2C NOTIFICATION-TYPE macros describe the characteristics of an SNMP event.

  • Instantiating SNMP Class Definitions. To instantiate a class definition, applications can call IWbemServices::GetObject or IWbemServices::GetObjectAsync.

  • Enumerating SNMP Class Instances. The SNMP instance Provider services requests to enumerate instances associated with classes that represent device MIBs.

  • Instantiating SNMP Class Instances. The SNMP instance Provider processes requests to instantiate instances of classes that represent MIB objects.

  • Retrieving SNMP Class Instances. To retrieve a particular instance of a SNMP CIM class, applications can call IWbemServices::GetObject or IWbemServices::GetObjectAsync.

SNMP and the CIM Schema

The schema that SNMP uses to define objects differs from that used in the WMI Common Information Model. The SNMPv1 and SNMPv2 schema is called the Structure of Management Information (SMI); it is packaged as MIB files. To define objects, the MIB files use Abstract Syntax Notation 1 (ASN.1), a standard language, and macro definitions that are used as templates for describing the objects. These macros supply information about the object, including its name, identifier, syntax, description, access rights, and so on.

The WMI SNMP Providers convert these MIB macros:

  • OBJECT-TYPEDescribes the basic characteristics of an object, such as the object name, syntax, access rights, and so forth. Pertains to SNMPv1 and SNMPv2C.

  • TEXTUAL-CONVENTIONAssigns a name and, in some cases, a range of values to an existing datatype. Pertains to SNMPv2C only.

  • TRAP-TYPEDescribes event messages (traps). Pertains to SNMPv1 only.

  • NOTIFICATION-TYPEDescribes event messages (notifications). Pertains to SNMPv2C only.

The SNMP class Provider enumerates and instantiates a set of class definitions against a CIM namespace. It does so by using an MIB correlator and the SNMP Module Information Repository, an SNMP schema database. The SNMP class Provider supports correlated and non-correlated modes. You designate one of these modes by setting a context value (IWbemContext) correlate of type Boolean and passing this into the IWbemServices method. The SNMP class provider supports both enumeration of class definitions and retrieval of a class definition.

The SNMP instance provider maps SNMP MIB objects to class instances.

SNMP Namespace

To define a view of a network device, an SNMP namespace is used. You can create an SNMP namespace by using the WMI SDK's WMI Common Information (CIM) Studio application, by compiling a MOF file, or programmatically with the WMI API.

The Namespace system class is used to represent an SNMP namespace. To generate a new namespace, you create an instance of this class. You must associate at least one descriptor (or qualifier) with the class instance. The qualifiers contain implementation-specific context information, and transport properties that define how the SNMP Providers access an SNMP agent.

SNMP Device Representation

SNMP devices are represented within WMI by using a proxy namespace that contains a set of instance qualifiers. These qualifiers describe the transport characteristics pertaining to the device. WMI uses a MOF file, snmpreg.mof, to create the \\.\root\snmp\localhost namespacethis is a standard namespace that represents the local SNMP agent.

SNMPv2C

SNMPv2C is supported within the WMI context. The main purpose of SNMPv2C was to provide a stronger security context for SNMP. This version uses the simple and unsecure password-based authentication feature, known as the community feature (provided in SNMPv1). The SNMPv2 SMI makes certain additions and enhancements to the community security, such as including bit strings, network addresses, and counters to the SNMPv1 SMI specific data types. Additionally, the SNMPv2 SMI specifies information modules, which specify a group of related definitions. SNMPv2 also defines two new protocol operations: GetBulk and Inform.

Security

WMI security validates a user's logon information both for the local computer and for remote access. WMI grants a validated user some form of controlled access to the entire CIM repository. In its current release, WMI does not provide security for system resources such as individual classes and instances. However, administrators can use WMI to control global permissions on schema operations, such as limiting the access of some users to read-only operations. WMI also supports per namespace security. In addition, the SNMP Provider provides support for all SNMP-based security, including the security enhancements in SNMPv2C.

SNMP Information Module Compiler

The SNMP information module compiler is used to compile native SNMP management information that is defined in a MIB into an equivalent CIM schema definition that can be used with the SNMP Providers. The CIM schema can exist as output in a MOF file or it can be loaded into an SNMP schema database (the SNMP Module Information Repository or SMIR). The SNMP dynamic class Provider uses the SNMP Module Information Repository to create and retrieve instances of class definitions.

The SNMP information module compiler runs in command-line mode as an executable file, using one SNMP information module as input, and any additional files that might be needed to resolve external references. SNMP information modules are collections of management information that typically consist of a combination of MIB modules, and AGENT-CAPABILITIES and MODULE-COMPLIANCE statements. AGENT-CAPABILITIES statements describe an agent's compliance to the set of MIB modules it supports. MODULE-COMPLIANCE statements describe an agent's capabilities regarding object definitions.

The SNMP information module compiler also provides the following functionality:

  • Performs checking operations on the information module. For example, it checks local syntax and external references against information in the subsidiary modules.

  • Removes all previously loaded data from the SMIR, or removes data loaded from one information module.

  • Returns either the ASN.1 module name of a specified file, or the ASN.1 module names of all imported modules in a specified file.

  • Returns the ASN.1 module names of all SNMP information modules currently loaded in the SMIR.

  • Performs automatic resolution of imported modules instead of requiring users to manually specify the required modules.

  • Performs a silent-loading mode of operation that does not generate output, but can be used to load data into the SMIR during an installation operation.

See Also

  • Simple Network Management Protocol Overview


Storage Manager for SANs Overview

You can use Storage Manager for SANs to create and manage logical unit numbers (LUNs) on both Fibre Channel and iSCSI disk storage subsystems that support Virtual Disk Service (VDS).

Because of hardware, protocol, and security differences, LUN configuration and management are different in Fibre Channel and iSCSI environments. This section explains those differences.

Managing LUNs in a Fibre Channel environment

In a Fibre Channel environment, LUNs created on a disk storage subsystem are assigned directly to a server or cluster, which accesses the LUN through one or more Fibre Channel host bus adapter (HBA) ports. You only need to identify the server or cluster that will access the LUN, and then select which HBA ports on that server or cluster will be used for LUN traffic.

When a server or cluster is identified, Storage Manager for SANs automatically discovers the available Fibre Channel HBA ports on that server or cluster. You can also add ports manually by typing their World Wide Name (WWN).

Managing LUNs in an iSCSI environment

Unlike in a Fibre Channel environment, LUNs created on an iSCSI disk storage subsystem are not only assigned to a server or cluster. For iSCSI, LUNs are first assigned to logical entities called targets.

Targets are created in order to manage the connections between an iSCSI device and the servers that need to access it. A target defines the portals (IP addresses) that can be used to connect to the iSCSI device, as well as the security settings (if any) that the iSCSI device requires in order to authenticate the servers that are requesting access to its resources.

Note

In most cases, you can create and manage targets yourself. However, some iSCSI storage subsystems only support simple target configurations, where targets are automatically created when you create a LUN. With simple target configurations, you also cannot delete a target or manually assign LUNs to it. LUNs are automatically assigned when they are created. For this type of subsystem, you just need to identify the server or cluster that will access the LUN, and the iSCSI subsystem will enable access from that server or cluster to the LUN.

To connect to a target, a server in the storage area network (SAN) uses an iSCSI initiator. An iSCSI initiator is a logical entity that enables the server to communicate with the target. The iSCSI initiator first logs on to the target, and only after access is granted by the target, the server can start reading and writing to LUNs assigned to that target. Each iSCSI initiator can have one or more network adapters through which communication is established.

As with Fibre Channel environments, you only need to identify the server or cluster that will access the LUN, and Storage Manager for SANs automatically discovers the iSCSI initiators on that server or cluster, and lists all the available adapters for those initiators. After the iSCSI initiator adapters have been discovered, you can select which adapters will be used for LUN traffic.

For more information about iSCSI, see http://go.microsoft.com/fwlink/?LinkId=93543.


Subsystem for UNIX-based Applications Overview

Subsystem for UNIX-based Applications (SUA) is a source-compatibility subsystem for compiling and running custom UNIX-based applications on a computer running a Microsoft® Windows® server-class operating system. You can make UNIX-based applications fully interoperable with Windows in SUA with little or no change to your original source code.

Subsystem for UNIX-based Applications provides an operating system for Portable Operating System Interface (POSIX) processes. SUA, along with its package of support utilities (such as shells and a Visual Studio® 2005 debugger extension) available for download on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=139521), provides a complete UNIX-based environment. The download package includes a comprehensive set of scripting utilities, and a software development kit (SDK) designed to fully support the development capabilities of SUA and to provide a complete UNIX-based application development experience.

SUA also supports case-sensitive file names, job control, compilation tools, and the use of over 300 UNIX commands, utilities, and shell scripts. Because the subsystem installs separately from the Windows kernel, it offers true UNIX functionality without emulation.

Features in Subsystem for UNIX-based Applications

Features in Subsystem for UNIX-based Applications include the following:

  • Database (OCI/ODBC) library connectivity SUA supports connectivity to Oracle and SQL Server from database applications by using the Oracle Call Interface (OCI) and the Open Database Connectivity (ODBC) standard.

  • Microsoft Visual Studio® Debugger Extension for debugging POSIX applications SUA includes support for debugging your POSIX processes by using the Visual Studio integrated development environment (IDE).

  • Utilities based on SVR-5 and BSD UNIX environments The SUA download package supports two different UNIX environments: SVR-5 and BSD.

  • Support for 64-bit applications By using a process called thunking, SUA provides support not only for 64-bit applications running on a 64-bit operating system, but also default support for 32-bit binaries running on a 64-bit operating system.

For more information, and to download the scripting utilities and the SDK, see the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=139521).

Installing Subsystem for UNIX-based Applications

Subsystem for UNIX-based Applications (SUA) is a feature included with Microsoft® Windows Server® 2008 R2 and Windows® 7.

Note

Until the download package Utilities and Software Development Kit for Subsystem for UNIX-based Applications (Utilities and SDK for SUA) has been installed on the computer, you cannot run or modify UNIX-based scripts and custom UNIX-based applications. The Utilities and SDK for SUA package is available for download on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=139521).

On Windows Server 2008 R2, you can install SUA by using the Add Features Wizard in Server Manager. Although Server Manager opens by default when a member of the Administrators group logs on to the computer, you can also open Server Manager by using commands on the Start menu in Administrative Tools, and by opening Programs in Control Panel. Windows Server 2008 R2 users can also install SUA by using either the Server Manager command line (ServerManagerCmd.exe) or the Server Manager set of Windows PowerShell cmdlets. For more information about the Server Manager command line or installing features by using Windows PowerShell cmdlets, see the Server Manager Help, either by pressing F1 from within the Server Manager console, or by opening the Help file at %windir%\Help\mui\0409\rmt.chm.

Note

Because of security restrictions imposed by User Account Control in Windows Server 2008 R2 and Windows 7, to install or remove features on your computer by using either Windows PowerShell cmdlets or the Server Manager command-line utility, you must run the Windows PowerShell or Command Prompt session as an administrator. To do this, right-click the shortcut for Windows PowerShell or Command Prompt, and then click Run as administrator.

On Windows 7, you can install SUA by opening Control Panel, clicking Programs, and then clicking Turn Windows features on or off.

Opening Subsystem for UNIX-based Applications

Installing the subsystem by using the Add Features Wizard or Turn Windows features on or off adds an SUA object to the Start menu. This object is not a shortcut, however; it does not open any SUA windows as other Start menu shortcuts typically do. The object is a container for the shells and utilities available in the SUA download package. After the download package is installed, you can access SUA by opening and working in UNIX-based command shells, the shortcuts to which populate the SUA object on the Start menu.


Telnet Server Overview

Telnet is an Internet-standard utility and protocol based on Request for Comments (RFC) 854. This RFC specifies a method for transmitting and receiving unencrypted ASCII characters (plaintext) across a network. You can use a Telnet client running on one computer to connect to a command line-based session to run applications. Only character-based interfaces and applications are supported. There is no graphics capability in the Telnet environment.

The RFC documents that define Telnet can be found at the Internet Engineering Task Force Web site (http://go.microsoft.com/fwlink/?linkid=121). On that page, click RFC Pages, and then type 854 in the RFC number text box and click Go.

Telnet consists of two components: Telnet Client and Telnet Server.

Telnet Server

Telnet Server hosts the remote sessions for Telnet clients. When Telnet Server is running on a computer, users can connect to the server with a Telnet client from a remote computer. Telnet Server is implemented in Windows as a service that can be configured to always run, even when no one is logged on to the server.

When a Telnet client connects to a computer running Telnet Server, the remote user is asked to enter a user name and password. The user name and password combination must be one that is valid on the Telnet Server. Telnet Server on Windows supports two types of authentication: NTLM and Password (or plaintext).

Once logged on, a user is presented with a command prompt that can be used as if it had been started locally on the server console. Commands that you type at the Telnet client command prompt are sent to the Telnet Server and executed there, as though you were locally logged on to a command prompt session at the server. Output from the commands you run are sent back to the Telnet client where they are displayed for you to view.

Telnet does not support applications that require a graphical user interface. However, Telnet Server and Telnet Client understand special character sequences that provide some level of formatting and cursor positioning within the Telnet client window. Telnet Server and Telnet Client support the emulation of four types of terminals: ANSI, VT-100, VT-52, and VT-NT.

Installing Telnet Server

On Windows Server 2008, you can install Telnet Server by using the Add Features Wizard in Server Manager. Although Server Manager opens by default when a member of the Administrators group logs on to the computer, you can also open Server Manager by using commands on the Start menu in Administrative Tools, and by opening Programs in Control Panel. On Windows Vista and later versions, you can install Telnet Server (and Telnet client) by opening Control Panel, then Programs, and then Turn Windows features on or off.

For more information about installing or using Telnet Server, see the Telnet Operations Guide (http://go.microsoft.com/fwlink/?linkid=86992) on the Microsoft Web site.


Telnet Client Overview

Telnet is an Internet-standard utility and protocol based on Request for Comments (RFC) 854. This RFC specifies a method for transmitting and receiving unencrypted ASCII characters (plaintext) across a network. You can use a Telnet client running on one computer to connect to a command line-based session to run applications. Only character-based interfaces and applications are supported. There is no graphics capability in the Telnet environment.

The RFC documents that define Telnet can be found at the Internet Engineering Task Force Web site (http://go.microsoft.com/fwlink/?linkid=121). On that page, click RFC Pages, and then type 854 in the RFC number text box and click Go.

Telnet consists of two components: Telnet Client and Telnet Server.

Telnet Client

Telnet Client allows a computer to connect to a remote Telnet server and run applications on that server. Once logged on, a user is given a command prompt that can be used as if it had been opened locally on the Telnet server's console. Commands that you type at the Telnet client command prompt are sent to the Telnet Server and executed there, as though you were locally logged on to a command prompt session at the server. Output from the commands that you run are sent back to the Telnet client where they are displayed for you to view.

Telnet does not support applications that require a graphical user interface. However, Telnet Server and Telnet Client understand special character sequences that provide some level of formatting and cursor positioning within the Telnet client window. Telnet Server and Telnet Client support the emulation of four types of terminals: ANSI, VT-100, VT-52, and VT-NT.

Installing Telnet Cient

On Windows Server 2008, you can install Telnet Client by using the Add Features Wizard in Server Manager. Although Server Manager opens by default when a member of the Administrators group logs on to the computer, you can also open Server Manager by using commands on the Start menu in Administrative Tools, and by opening Programs in Control Panel. On Windows Vista and later versions, you can install Telnet Client (and Telnet Server) by opening Control Panel, then Programs, and then Turn Windows features on or off.

For more information about installing or using Telnet Client, see the Telnet Operations Guide (http://go.microsoft.com/fwlink/?linkid=86992) on the Microsoft Web site.


Trivial File Transfer Protocol (TFTP) Overview

Trivial File Transfer Protocol

The Trivial File Transfer Protocol (TFTP) client allows the transfer of files using the TFTP protocol between a TFTP client and a TFTP server. The TFTP protocol is implemented using the User Datagram Protocol (UDP) to send and receive data. The TFTP protocol implements its own reliability scheme using UDP.

The TFTP protocol does not support any authentication or encryption mechanism, and as such can introduce a security risk when present. Installing the TFTP client is not recommended for systems that access the Internet.

The TFTP client is optional software, and marked as deprecated on Windows Vista® and later versions of the Windows operating system. A TFTP server is no longer provided by Microsoft for similar security issues.


Windows Internal Database Overview

Windows Internal Database is a relational data store used by the following applications and services.

  • Active Directory Rights Management Services (AD RMS)

  • Windows Server Update Services

  • Windows System Resource Manager

These applications and services share a single instance of the data store.

Installing Windows Internal Database

You typically do not need to install Windows Internal Database. It is installed by the first application or service that requires it.

Removing Windows Internal Database

Because multiple applications and services use the same instance of Windows Internal Database, removing these applications and services does not remove the data store. If you have removed all applications and services that use Windows Internal Database, you can then remove it by using the Server Manager Remove Features Wizard.

See Also

  • Features Available in Windows Server 2008 R2


Windows Internet Name Service (WINS) Overview

Windows Internet Name Service (WINS) is a computer name registration and resolution service that maps computer NetBIOS names to IP addresses. When you deploy WINS servers on your network, end users can access network resources by name rather than by harder-to-remember IP addresses. In addition, software and other services running on computers and other devices can perform name queries against your WINS server to resolve names to IP addresses.

What a WINS server can provide

WINS provides the following benefits for administering your TCP/IP-based network:

  • A dynamic name-to-address database that maintains support for computer name registration and resolution.

  • Centralized management of the name-to-address database, alleviating the need for managing Lmhosts files.

  • Reduction of NetBIOS-based broadcast traffic on subnets, by permitting clients to query WINS servers to directly locate remote systems.

  • Support for earlier Microsoft® Windows® and NetBIOS-based clients on your network, permitting these types of clients to browse lists for remote Windows domains without requiring a local domain controller to be present on each subnet.

  • Support for DNS-based clients by enabling those clients to locate NetBIOS resources when WINS lookup integration is implemented.

Name resolution for WINS clients is an extension of the same name resolution process used by all Microsoft NetBIOS over TCP/IP (NetBT) clients to resolve NetBIOS name queries on your network. The actual method of name resolution is transparent to the user.

For Windows XP and Windows 2000, WINS clients use the following sequential flow of options for resolving a name after the query has been made by using net use or a similar NetBIOS-based application:

  1. Determine if the name is longer than 15 characters or if it contains periods ("."). If so, query DNS for the name.

  2. Determine if the name is stored in the remote name cache on the client.

  3. Contact configured WINS servers to attempt to resolve the name using WINS.

  4. Use local IP broadcasts to the subnet.

  5. Check an Lmhosts file if Enable LMHOSTS Lookup is enabled in the Internet Protocol (TCP/IP) properties for the connection.

  6. Check a Hosts file.

  7. Query a DNS server.

Components of a WINS server

WINS consists of two main components, WINS servers and WINS clients. In some configurations, WINS proxies are used.

WINS servers

The WINS server handles name registration requests from WINS clients, registers their names and IP addresses, and responds to NetBIOS name queries from clients by returning the IP address of a queried name if it is listed in the server database.

You can also configure your WINS servers to replicate the contents of their databases (which contain NetBIOS computer name mappings to IP addresses) to other WINS servers. When a WINS client (such as a workstation computer) starts on the network, its computer name and IP address are sent in a registration request directly to its configured primary WINS server. Because the server registers these clients, it is said to be the owner for the records of the clients in the database.

WINS database

The WINS database stores the NetBIOS name-to-IP address mappings for your network. If you configure your WINS servers with replication partners to which the database contents are "pushed," the contents of the database on the local server is replicated to the replication partner server. If replication partners are configured as "pull" partners, records from the remote WINS server are copied to the local database. The intervals at which these replication events occurs is configurable in the WINS Microsoft Management Console (MMC) using the WINS snap-in, also called the WINS console.

In addition, The WINS console provides the tools you need to maintain, view, back up, and restore the WINS server database. Back up the database whenever you back up other files on the WINS server.

WINS clients

WINS clients attempt to register their names with a WINS server when they start or join the network. Clients thereafter query the WINS server to resolve remote names as needed.

WINS-enabled clients are computers that can be configured to make direct use of a WINS server. Most WINS clients typically have more than one NetBIOS name that they must register for use with the network. These names are used to publish various types of network service, such as the Messenger or Workstation service, that each computer can use in various ways to communicate with other computers on the network.

WINS proxies

A WINS proxy is a WINS client computer configured to act on behalf of other host computers that cannot directly use WINS. WINS proxies help resolve NetBIOS name queries for computers located on routed TCP/IP networks.

By default, most computers cannot use WINS use broadcasts to resolve NetBIOS name queries and register their NetBIOS names on the network. You can configure a WINS proxy to listen on behalf of these computers and to query a WINS server for names not resolved by broadcast.

WINS proxies are only useful or necessary on networks that include NetBIOS broadcast-only (or b-node) clients. For most networks, WINS-enabled clients are common and WINS proxies are typically not needed.

WINS proxies listen for b-node NetBIOS name service functions (name registration, name release, and name query) and can respond for those names that are remote and not used on the local network. Proxies communicate directly with a WINS server to retrieve the information necessary to respond to these local broadcasts.

WINS proxies are used in the following ways:

  • When a b-node client registers its name, the proxy checks the name against the WINS server database. If the name exists in the WINS database, the proxy might send a negative registration response back to the b-node client attempting to register the name.

  • When a b-node client releases its name, the proxy deletes the client name from its remote name cache.

  • When a b-node client sends a name query, the proxy attempts to resolve the name using information either locally contained in its cache of remote names or through the use of information it obtains from the WINS server.

Managing a WINS server

The primary tools that you use to manage WINS servers are the WINS console and the Netsh commands for WINS.

WINS console

The WINS console is a Microsoft Management Console (MMC) snap-in.

After you install a WINS server, you can use the WINS console or the Netsh WINS commands to perform these basic administrative server tasks:

  1. View and filter NetBIOS name registrations stored at the WINS server for client names used on your network.

  2. Add and configure replication partners for the WINS server.

  3. Perform maintenance-related tasks on the WINS server database, including backup, restore, compaction, and scavenging.

In addition, you can use the WINS console or the Netsh WINS commands to perform the following optional or advanced setup tasks:

View and modify WINS properties, such as the Renew Interval and other intervals that are used when registering, renewing, and verifying name records stored in the server database.

  • Add and configure static WINS mappings, if they are needed for use on your network.

  • Delete or tombstone WINS records that appear in WINS server data used throughout your network.

Netsh commands for WINS

You can type the Netsh WINS commands in a command prompt window at the netsh wins> command prompt, or you can run the Netsh WINS commands in batch files and other scripts. All of the functionality that is available in the WINS console is also available at the netsh wins> command prompt.


Windows PowerShell Integrated Scripting Environment Overview

Windows PowerShell Integrated Scripting Environment (ISE) is a graphical host application for Windows PowerShell. Windows PowerShell ISE lets you run commands, and write, edit, run, test, and debug scripts in an environment that displays syntax in colors and that supports Unicode.

Windows PowerShell is a command-line shell and scripting language built on the Microsoft .NET Framework. It is designed especially for Windows administration. Its simple cmdlet (pronounced "command-let") tools and built-in Help system let you start working immediately. You can combine the cmdlets into pipelines that contain multiple commands and then save your favorite command sequences in functions that automate tasks. More experienced users can use Windows PowerShell as a development platform and extend it by adding functions, cmdlets, and providers.

Windows PowerShell ISE is designed for users at all levels of proficiency. Beginners will appreciate the syntax colors and the context-sensitive Help. Multiline editing makes it easy to try the examples that you copy from the Help topics and from other sources. Advanced users will appreciate the availability of multiple execution environments, the built-in debugger, and the extensibility of the Windows PowerShell ISE object model.

Windows PowerShell 2.0 is a feature of Windows Server 2008 R2. Windows PowerShell ISE is an optional feature. To install it, use the Add Features Wizard.

Windows PowerShell ISE Features

The features of Windows PowerShell ISE include:

  • A Command pane for running interactive commands.

  • A Script pane for writing, editing, and running scripts. You can run the entire script or selected lines from the script.

  • A scrollable Output pane that displays a transcript of commands from the Command and Script panes and their results.

  • Up to eight independent Windows PowerShell execution environments in the same window, each with its own Command, Script, and Output panes. This tabbed environment allows you to work on several tasks at the same time.

  • Multiline editing in the Command pane lets you paste multiple lines of code, run them, and then recall them as a unit.

  • A built-in debugger for debugging commands, functions, and scripts. You can set and remove breakpoints, step through your code, check the values of variables, and display a call-stack trace.

  • Customizable features let you adjust the colors, font, and layout.

  • A scriptable object model lets you further customize and extend Windows PowerShell ISE. You can add functionality, including menu items. Also, you can access the session, the files, and the editor to create your own features.

  • Line and column numbers, keyboard shortcuts, tab completion, context-sensitive Help, and Unicode support make Windows PowerShell ISE an efficient and productive environment for using Windows PowerShell. Windows PowerShell even lets you open files by using a drag-and-drop operation.

Windows PowerShell ISE Requirements

Windows PowerShell ISE runs on Windows XP and later versions of Windows, except for Server Core installations of Windows Server.

Windows PowerShell ISE requires the Microsoft .NET Framework 3.5 with Service Pack 1. If this version of the Microsoft .NET Framework is not installed on your system, Server Manager installs it when you install Windows PowerShell ISE.

For more information about Windows PowerShell and Windows PowerShell ISE, see Windows PowerShell (http://go.microsoft.com/fwlink/?LinkID=107116).


Windows Process Activation Service (WAS) Overview

The Windows Process Activation Service

Windows Process Activation Service generalizes the Internet Information Services (IIS) process model, removing the dependency on HTTP. All the features of IIS that were previously available only to HTTP applications are now available to applications hosting Windows Communication Foundation (WCF) services, by using non-HTTP protocols. IIS 7.0 also uses Windows Process Activation Service for message-based activation over HTTP.

Conditions for installing and running WAS

From a security standpoint, you should not run Windows Process Activation Service unless you are supporting a .NET Framework 3.5.1 application or IIS 7.0.

IIS and .NET Framework 3.5.1 automatically install Windows Process Activation Service as needed. You should not install Windows Process Activation Service by itself.

See Also

  • Features Available in Windows Server 2008 R2


WinRM IIS Extension Overview

WinRM IIS Extensions is a new feature in Windows Server® 2008 R2.

What is WinRM IIS Extension?

The Windows Remote Management (WinRM) IIS Extension module provides an Internet Information Services (IIS)-based hosting model. WinRM IIS Extension can be enabled at the either the Web site or virtual directory level. It works by intercepting and redirecting incoming requests to the associated Web site or virtual directory.

Incoming requests are redirected to a WinRM module that scans request contents to determine the correct WinRM plug-in to handle the request. It is recommended that all redirections use Secure Socket Layer (SSL), and that all applications validate the redirected URI before starting a new session.

For more information about WinRM IIS Extension, see Windows Remote Management (http://go.microsoft.com/fwlink/?LinkId=136946).

See Also

  • Features Available in Windows Server 2008 R2


Windows Server Backup Overview

Windows Server Backup consists of a Microsoft Management Console (MMC) snap-in, command-line tools, and Windows PowerShell cmdlets that provide a complete solution for your day-to-day backup and recovery needs. You can use Windows Server Backup to back up a full server (all volumes), selected volumes, the system state, or specific files or folders—and to create a backup that you can use for bare metal recovery. You can recover volumes, folders, files, certain applications, and the system state. And, in case of disasters like hard disk failures, you can perform a bare metal recovery. (To do this, you will need a backup of the full server or just the volumes that contain operating system files, and the Windows Recovery Environment—this will restore your complete system onto your old system or a new hard disk.)

You can use Windows Server Backup to create and manage backups for the local computer or a remote computer. And, you can schedule backups to run automatically.

Windows Server Backup is intended for use by everyone who needs a basic backup solution—from small business to large enterprises—but is even suited for smaller organizations or individuals who are not IT professionals.

Considerations

  • You must be a member of the Administrators group or Backup Operators group to use Windows Server Backup.

  • Certain backup or recovery tasks must be performed with two computers running the same version of Windows Server 2008 or Windows Server 2008 R2, while others may be performed with computers running either version. For more information about compatibility, see http://go.microsoft.com/fwlink/?LinkId=143709.

  • To perform a system state or full system recovery, you must use backups from the same version of Windows that you are recovering. For example, you cannot use a backup from Windows Server 2008 to recover the system state of a computer running Windows Server 2008 R2.

  • The firewall may be enabled. If you are managing the backups of another computer using the Windows Server Backup snap-in, your connectivity to the remote computer may be affected and can be resolved by changes in the firewall rules. While working on the local computer, you are not affected.

  • Windows Server Backup does not support backing up of data from or storing backups on Clustered Shared Volumes. (You can, however, back up virtual machines using Windows Server Backup from within the virtual machine.) For more information about managing failover clusters, see http://go.microsoft.com/fwlink/?LinkID=92360. For more information about managing Hyper-V, see http://go.microsoft.com/fwlink/?LinkID=93752. And for more information about Hyper-V and cluster shared volumes, see http://go.microsoft.com/fwlink/?LinkID=139667.

  • If you are using a virtual hard disk to store backups, if the virtual hard disk is on a physical disk that contains system volumes or critical volumes, there may be limitations to what you can recover. In addition, virtual volume files will be excluded from the backup if the virtual volumes are online. For more information about working with virtual hard disks, see http://go.microsoft.com/fwlink/?LinkId=143712.

  • If you are a current user of the previous backup feature (Ntbackup.exe), and plan to switch to the new Windows Server Backup, you might be affected by the following issues and changes:

    • Settings for creating backups will not be upgraded when you upgrade to Windows Server 2008. You will need to reconfigure settings.

    • You cannot use Windows Server Backup to back up file and folders on volumes that require more than 2040 GB (or 2 TB). However, as long as the data size is less than 2 TB, you can perform a file or folder backup. For example, you can back up 1.5 TB of data from a 3-TB volume. But, a full server or volume recovery using the backup will recreate a 2-TB volume instead of a 3-TB volume.

    • Only NTFS-formatted volumes on a locally attached disk can be backed up. (For instructions to convert a FAT partition to a NTFS partition, see http://go.microsoft.com/fwlink/?LinkID=70318.)

    • You cannot store backups on tape. (However, support of tape storage drivers is still included in Windows Server 2008). Windows Server Backup supports backing up to external and internal disks, optical and removable media such as DVDs, and remote shared folders.

    • You cannot recover backups that you created with Ntbackup.exe by using Windows Server Backup. However, a version of Ntbackup.exe is available as a download to Windows Server 2008 for users who want to recover data from backups created using Ntbackup.exe. The downloadable version of Ntbackup.exe is only for recovering backups for older versions of Windows and cannot be used to create new backups in Windows Server 2008. To download Ntbackup.exe, see http://go.microsoft.com/fwlink/?LinkId=82917.

New functionality

Windows Server Backup in Windows Server 2008 R2 includes the following improvements:

  • More flexibility in what you can back up. Windows Server Backup enables you to back up selected files instead of full volumes. You can also exclude files based on file type and path.

  • Automatic management of full and incremental backups. You no longer need to manage full and incremental backups. Instead, Windows Server Backup will, by default, create an incremental backup that behaves like a full backup. You can recover any item from a single backup, but the backup will only occupy space needed for an incremental backup. In addition, Windows Server Backup does not require user intervention to periodically delete older backups to free up disk space for newer backups—older backups are deleted automatically.

  • Expanded options for backup storage. You can now store backups created using a scheduled backup on a remote shared folder or volume. (If you store backups on a remote shared folder, only one version of your backup will be maintained.) You can also store backups on virtual hard disks.

  • Improved options for system state backups and recoveries. You can now use the Windows Server Backup snap-in user interface to create backups that you can use to perform system state recoveries. In addition, you can now use a single backup to back up both the system state and other data on your server. These system state backups are now faster and require less space for multiple versions because they use shadow copies for versioning, similar to volume based backups, and not individual folders for each version. For more information about how system state backups are stored on Windows Server 2008 R2, see http://go.microsoft.com/fwlink/?LinkId=143713.

  • Expanded command-line and Windows PowerShell support. The Wbadmin command and documentation enable you to perform the same tasks at the command line that you can perform by using the snap-in. For more information, see the Command Reference (http://go.microsoft.com/fwlink/?LinkId=140216). You can also automate backup activities through scripting.

    Changes to this command are the same as the changes for the Windows Server Backup snap-in.

    In addition, Windows Server 2008 R2 contains an updated collection of Windows PowerShell cmdlets for Windows Server Backup that you can use to write Windows PowerShell scripts to perform backups. For more information, see http://go.microsoft.com/fwlink/?LinkId=140217.

Supported operating systems

Windows Server Backup is available in all editions of Windows Server 2008 and Windows Server 2008 R2. However, like other snap-ins, the Windows Server Backup snap-in is not available for the Server Core installation option of Windows Server 2008 R2. To run backups for computers with a Server Core installation, you need to use the Wbadmin command, Windows PowerShell cmdlets for Windows Server Backup, or manage backups remotely from another computer.

Additional resources

  • For more information about backing up or recovering your server, see http://go.microsoft.com/fwlink/?LinkId=93012.


Windows Server Migration Tools and Guides

Migration documentation and tools ease migrating server roles, operating system settings, and data from an existing server that is running Windows Server® 2003, Windows Server 2008, or Windows Server 2008 R2 to a computer that is running Windows Server 2008 R2.

By using migration guides linked from this topic—and where it is appropriate, Windows Server Migration Tools—to migrate roles, you can simplify deployment of new servers (including those that are running the Server Core installation option of Windows Server 2008 R2, and virtual servers), reduce migration downtime, increase accuracy of the migration process, and help eliminate conflicts that could otherwise occur during the migration process.

Most of the migration documentation and tools featured on the Windows Server Migration Portal support cross-architecture migrations (x86-based to x64-based computing platforms), migrations between physical and virtual environments, and migrations between both the full and Server Core installation options of the Windows Server operating system, where available.

Windows Server 2008 R2 Migration Guides

Step-by-step migration guides for supported server roles, features, operating system settings, and data are available on the Windows Server 2008 R2 TechCenter (http://go.microsoft.com/fwlink/?LinkID=128554).

Windows Server Migration Tools

Windows Server Migration Tools is a feature that is available for installation on computers that are running Windows Server 2008 R2 by using the Add Features Wizard in Server Manager. Windows Server Migration Tools can be removed from Windows Server 2008 R2 by using the Remove Features Wizard.

To migrate roles, features, and other data by using Windows Server Migration Tools, you must also deploy Windows Server Migration Tools on source servers from which you want to migrate data. Windows Server Migration Tools is deployed on source servers by creating a deployment folder on a computer that is running Windows Server 2008 R2, and then copying it to the pre-Windows Server 2008 R2 source computer operating systems shown in the table in this topic.

You must be a member of the Administrators group on the computer on which you want to install, register, or use Windows Server Migration Tools. Additionally, if you are running Windows Server Migration Tools on servers that are running either Windows Server 2008 or Windows Server 2008 R2, you must run Windows Server Migration Tools with elevated user rights. To do this, click Start, click Administrative Tools, right-click Windows Server Migration Tools, and then click Run as administrator.

Complete instructions for the installation, configuration, and removal of Windows Server Migration Tools are available on the World Wide Web, in the Windows Server Migration Tools Installation, Access, and Removal (http://go.microsoft.com/fwlink/?LinkId=134763) step-by-step guide on the Windows Server 2008 R2 TechCenter.

Supported operating systems

The following table shows operating systems for which migration by using Windows Server Migration Tools is supported.

Source server processor | Source server operating systems | Destination server operating systems | Destination processor
x86- or x64-based | Windows Server 2003 | Windows Server 2008 R2 and Server Core | x64-based
x86- or x64-based | Windows Server 2003 R2 | Windows Server 2008 R2 and Server Core | x64-based
x86- or x64-based | Windows Server 2008 | Windows Server 2008 R2 and Server Core | x64-based
x64-based | Windows Server 2008 R2 | Windows Server 2008 R2 and Server Core | x64-based
x64-based | Windows Server 2008 R2 Server Core | Windows Server 2008 R2 and Server Core | x64-based
Notes
  • Foundation, Standard, Enterprise, and Datacenter editions of Windows Server are supported on both full and Server Core installation options, as either source or destination servers.
  • Migrations between physical operating systems and virtual operating systems are supported.
  • Migration from a source server to a destination server that is running an operating system in a different system UI language (that is, the installed language) than the source server is not supported. For example, you cannot use Windows Server Migration Tools to migrate roles, operating system settings, or data, from a computer that is running Windows Server 2008 in the French system UI language to a computer that is running Windows Server 2008 R2 in the German system UI language.
  • The system UI language is the language of the localized installation package that was used to set up the Windows operating system.
  • Both x86- and x64-based migrations are supported for Windows Server 2003 and Windows Server 2008. All editions of Windows Server 2008 R2 are 64-bit.
  • Roles that are running on Server Core installations of Windows Server 2008 cannot be migrated, because there is no .NET Framework available on Windows Server 2008 Server Core.


Windows System Resource Manager Overview

With Windows System Resource Manager for the Windows Server® 2008 R2 operating system, you can manage server processor and memory usage with standard or custom resource policies. Managing your resources can help ensure that all the services provided by a single server are available on an equal basis or that your resources will always be available to high-priority applications, services, or users.

Windows System Resource Manager only manages processor resources when the combined processor load is greater than 70 percent. This means that it does not actively limit the resources that can be used by each consumer when processor load is low. When there is contention for processor resources, resource allocation policies help ensure minimum resource availability based on the management profile that you define.

Features of Windows System Resource Manager

You can use Windows System Resource Manager to:

  • Manage system resources (processor and memory) with preconfigured policies, or create custom policies that allocate resources per process, per user, per Remote Desktop Services session, or per Internet Information Services (IIS) application pool.

  • Use calendar rules to apply different policies at different times without manual intervention or reconfiguration.

  • Automatically select resource policies that are based on server properties and events (such as cluster events or conditions) or changes to installed physical memory or number of processors.

  • Collect resource usage data locally or in a custom SQL database. Resource usage data from multiple servers can be consolidated on a single computer running Windows System Resource Manager.

  • Create a computer group to help organize remote desktop servers that you want to manage. Policies can easily be exported or modified for an entire computer group.

Benefits of resource management

Because Windows Server 2008 R2 is designed to give as many resources as possible to non-operating system tasks, a server running a single role usually does not require resource management. However, when multiple applications and services are installed on a single server, they are not aware of competing processes. An unmanaged application or service will typically use all available resources to complete a task. Thus, it is important to use a tool such as Windows System Resource Manager to manage system resources on multipurpose servers. Using Windows System Resource Manager provides two key benefits:

  • More services can run on a single server because service availability can be improved through dynamically managed resources.

  • High-priority users or system administrators can access the system even during times of maximum resource load.

Methods of resource management

Windows System Resource Manager includes five built-in resource management policies that you can use to quickly implement management. In addition, you can create custom resource management policies to meet your specific needs.

Built-in resource management policies

You can enable built-in resource management policies by selecting the type of policy to use. No further configuration is required.

Policy Description

Equal per process

When the Equal_Per_Process resource allocation policy is managing the system, each running process is given equal treatment. For example, if a server that is running ten processes reaches 70 percent processor utilization, Windows System Resource Manager will limit each process to using 10 percent of the processor resources while they are in contention. Note that resources not used by low utilization processes will be allocated to other processes.

Equal per user

When the Equal_Per_User resource allocation policy is managing the system, processes are grouped according to the user account that is running them, and each of these process groups is given equal treatment. For example, if four users are running processes on the server, each user will be allocated 25 percent of the system resources to complete those processes. A user running a single application is allocated the same resources as a user running several applications. This policy is especially useful for application servers.

Equal per session

When the Equal_Per_Session resource allocation policy is managing the system, resources are allocated on an equal basis for each session connected to the system. This policy is for use with remote desktop servers.

Equal per IIS application pool

When the Equal_Per_IISAppPool resource allocation policy is managing the system, each running IIS application pool is given equal treatment, and applications that are not in an IIS application pool can only use resources that are not being consumed by IIS application pools.

Weighted Remote Sessions

When the Weighted_Remote_Sessions resource allocation policy is managing the system, the processes are grouped according to the priority assigned with the user account. For example, if three users are remotely connected, the user assigned Premium priority will receive highest priority access to the CPU, the user assigned Standard priority will receive second priority to the CPU, and the user assigned Basic priority will receive lowest priority to the CPU. This policy is for use with remote desktop servers.

Note

When Weighted_Remote_Sessions is set as the managing policy, system management is delegated to the Windows Server 2008 R2 scheduler, and Windows System Resource Manager only profiles the system. Setting or removing Weighted_Remote_Sessions as the managing policy requires a restart of the computer imposed by the kernel.

Custom resource management

You can use custom resource management methods to identify resource users and allocate resources to them based on your own criteria.

Feature Description

Process matching criteria

Enable you to select services or applications to be managed by resource allocation policy rules. You can choose by file name or command, or you can specify users or groups. For example, you could create a process matching criterion that applies management to the application iexplore.exe when it is run by the user Administrator.

Resource allocation policies

Allocate processor and memory resources to processes that are specified by the process matching criteria that you create.

Exclusion lists

Exclude applications, services, users, or groups from management by Windows System Resource Manager.

Note

You can also use command-line path matching in a resource allocation policy to exclude an application from management by only that policy.

Scheduling

Use a calendar interface to control one-time events or recurring changes to resource allocation. Different resource allocation policies can be active at different times of day, on different days of the week, or according to other scheduling paradigms.

Conditional policy application

Automatically switch resource allocation policies in response to certain system events (such as installing new memory or additional processors, starting or stopping a node, or changing the availability of a resource group in a cluster).

Additional references

  • For more information about Windows System Resource Manager, see http://go.microsoft.com/fwlink/?LinkId=90924.


Windows TIFF IFilter Overview

Windows TIFF IFilter enables you to search for Tagged Image File Format (TIFF) documents based on text content. Windows TIFF IFilter supports all TIFF documents that are complaint with Adobe TIFF Revision 6.0 specifications, and includes the most frequent compressions, such as LZW, JPG, CCITT v4, CCITT v6, uncompressed, and so forth.

When loaded, Windows TIFF IFilter performs Optical Character Recognition (OCR) processing of TIFF images, and then provides the recognized text to the caller for building the search index.

Windows TIFF IFilter can be used by Indexing Service (for Desktop Search), Microsoft Office SharePoint Server 2007 or later, Microsoft SQL Server 2008, and Microsoft SQL Server 2005.

Search result considerations

Windows TIFF IFilter focuses on text-based documents, which means that searching will be more successful for documents that contain clearly identifiable text (for example, black text on a white background), and less successful for documents that contain mixed content (for example, artistic text or text inside of pictures). Additionally, low-quality images and mixed languages can negatively impact OCR processing, and consequently, lower the quality of the search results.

Installing Windows TIFF IFilter

Note

The following procedure installs Windows TIFF IFilter, but does not enable the Indexing Service. For instructions about how to enable the Indexing Service on Windows Server 2008 R2, see the Indexing Service documentation. If you are using Windows TIFF IFilter with Microsoft SharePoint 2007 or later, Microsoft SQL Server 2008 or Microsoft SQL Server 2005, see the product documentation for information about how to deploy Windows TIFF IFilter.

To install Windows TIFF IFilter on Windows 2008 R2

  1. Click Start, and then, in Search programs and files, type Server Manager.

  2. In Programs, click Server Manager.

  3. Click Features, and then click Add Features.

  4. Select Windows TIFF IFilter, and then click Next.

  5. Click Install.


Wireless LAN Service Overview

The Wireless LAN service is a feature in Windows Server® 2008 R2 and Windows Server® 2008 that you can use to enable the wireless WLAN Auto Configuration service, and to configure WLAN AutoConfig for automatic startup. Once enabled, WLAN AutoConfig dynamically selects the wireless network to which the computer will automatically connect, and configures the necessary settings on the wireless network adapter. This includes automatically selecting and connecting to a more preferred wireless network when one becomes available.

Wireless LAN Service and WLAN AutoConfig Service

The Wireless LAN Service configures the WLAN AutoConfig service to start automatically, regardless of whether the computer has any IEEE 802.11 wireless adapters installed. When enabled, WLAN AutoConfig enumerates every wireless network adapter installed on the computer, manages IEEE 802.11 wireless connections, and manages the wireless connection profiles that contain the settings required to configure a wireless client to connect to a wireless network. WLAN AutoConfig allows you to connect to an existing wireless network, change wireless network connection settings, configure a connection to a new wireless network, and specify preferred wireless networks. WLAN AutoCofig also notifies you when new wireless networks are available. When you switch wireless networks, WLAN AutoConfig dynamically updates your wireless network adapter settings to match the settings of that new network and a network connection attempt will be made.

If you are connecting to a wireless network for the first time, WLAN AutoConfig will configure basic network settings, if the service is enabled. However, you might need to configure additional settings, such as the data encryption type or network key, if they are not automatically configured for your account through the Wireless Network (IEEE 802.11) Policies in Active Directory. You might also need to request account permissions from your network administrator.

Enabling and Starting WLAN AutoConfig

There are several methods to enable and start the WLAN AutoConfig service:

  • The New Features Wizard

    Configure Wireless LAN Service in the New Features Wizard in Windows Server 2008 R2 or Windows Server 2008.

  • Wireless Network (IEEE 802.11) Policy

    Enable the Windows Vista® Wireless Network (IEEE 802.11) Policy setting, Use Windows WLAN AutoConfig Service for clients. In the properties of the Windows Vista Wireless Network (IEEE 802.11) Policy, on the General tab, select Use Windows WLAN AutoConfig Service for clients.

    This setting enables administrators to specify that the WLAN AutoConfig Service is used to configure and connect wireless clients running Windows® 7, Windows Vista, Windows Server 2008 R2, or Windows Server 2008 to the wireless network.

  • Netsh WLAN set autoconfig

    To run Netsh WLAN commands on computers running Windows Server 2008 R2 Windows Server 2008, you must first install the Wireless LAN Service.

    Use the netsh wlan set autoconfig command using the following syntax:

    set autoconfig enabled={yes|no} interface=InterfaceName

    You can use Netsh wlan commands to configure the local computer, or to configure multiple computers by using a logon script.

  • In the Services Microsoft Management Console (MMC) snap-in.

    Navigate to WLAN AutoConfig Service, then modify the properties of the service to meet your requirements.

Differences in wireless services

This section summarizes differences between the wireless configuration service in computers running Windows Server 2008 R2, Windows Server 2008, Windows 7 and Windows Vista, and the wireless service in computers running Windows Server 2003 and Windows XP:
Changes in the wireless auto configuration service name

Windows Server 2003 and Windows XP | Windows Server 2008 R2, Windows Server 2008, Windows 7 and Windows Vista
Wireless auto configuration service name: Wireless Zero Configuration service (WZCSVC) | Wireless auto configuration service name: WLAN AutoConfig service (Wlansvc)

Wireless auto configuration details for broadcasting and non-broadcasting wireless networks.

Note

In wireless broadcasting networks, the wireless network name or Service Set Identifier (SSID) is included in the Beacon frames sent by the wireless access point (AP). In non-broadcasting networks, the Beacon frame value for SSID is set to NULL.

Windows Server 2003 and Windows XP Windows Server 2008 R2, Windows Server 2008, Windows 7 and Windows Vista

In Windows XP and Windows Server 2003, the Wireless Zero Configuration service attempts to match wireless networks that are broadcasting their network name with preferred wireless networks profiles that are configured on the computer. If there are no available networks that match a preferred wireless network profile, then WZCSVC sends probe requests to determine if any preferred networks in the ordered list are non-broadcast networks.

The result is that the computer connects to broadcast networks before non-broadcast networks, regardless of whether a non-broadcast network is ranked higher in the preferred list than a broadcast network.

Additionally, Windows XP and Windows Server 2003 wireless clients advertise their list of preferred wireless networks when sending probe requests.

In Windows Server 2008 R2, Windows Server 2008, Windows 7 and Windows Vista, you can configure wireless network configuration profiles as broadcast or non-broadcast wireless networks.

The result is that WLAN AutoConfig attempts to connect to wireless networks in order they are ranked in the list of preferred networks, regardless of whether they are broadcast or non-broadcast networks.

Because the wireless networks are explicitly marked as broadcast or non-broadcast, wireless clients running Windows Server 2008 R2, Windows Server 2008, Windows 7 and Windows Vista, send only probe requests for non-broadcast wireless networks.

Behavior changes for no available preferred wireless networks

Windows Server 2003 and Windows XP Windows Server 2008 R2, Windows Server 2008, Windows 7 and Windows Vista

In Windows XP and Windows Server 2003, if a preferred wireless network cannot be connected and the wireless client is configured to prevent automatic connection to wireless networks that are not in the preferred list (the default), Wireless Auto Configuration creates a random wireless network name and places the wireless network adapter in infrastructure mode. However, the random wireless network does not have a security configuration, making it possible for a malicious user to connect to the wireless client using the random wireless network name. The new Wireless Client Update for Windows XP with Service Pack 2 modifies this behavior by configuring the wireless network adapter with a random name and a security configuration consisting of a 128-bit random encryption key and the strongest encryption method supported by the wireless network adapter. This new behavior helps prevent a malicious user from connecting to the wireless client using the random wireless network name.

For computers running Windows Server 2008 R2, Windows Server 2008, Windows 7 and Windows Vista, that use updated wireless drivers designed for Windows Vista, the wireless WLAN AutoConfig service places the wireless network adapter in a passive listening mode to remove the vulnerability that effects computers running Windows XP and Windows Server 2003. While in the passive mode, the wireless network adapter will not send Probe Request frames for a random wireless network name or any other name; malicious users cannot connect to the wireless client.

Note

Most wireless network drivers have been updated for Windows Vista. If you are using a wireless network adapter driver that was designed for Windows XP on computers running Windows Server 2008 R2, Windows Server 2008, Windows 7 and Windows Vista, these computers will use the behavior of the Wireless Client Update for Windows XP with Service Pack 2 (a random wireless network name with a security configuration).

For more information, see 802.1X Authenticated Wireless Access (http://go.microsoft.com/fwlink/?LinkID=93650).


XPS Viewer Overview

An XPS document is any file that is saved to the XML Paper Specification, or .xps, file format. You can create XPS documents (.xps files) by using any program that you can print from in Windows; however, you can view XPS documents only by using the XPS Viewer, which is included in this version of Windows.

What is the XPS Viewer?

When you click an XPS document, it will open automatically in the XPS Viewer. There are several options for viewing and managing XPS documents in the XPS Viewer, including:

  • Saving a copy of an XPS document to your computer

  • Searching the document for a word or phrase

  • Zooming in or out to make text and pictures easier to read

  • Digitally signing the XPS document

  • Determining who can access the document and for how long by applying document permissions

For more information about the XPS document format, see XML Paper Specification (http://go.microsoft.com/fwlink/?LinkId=62045) on the Microsoft Web site.

Using the XPS Viewer

XPS Viewer is a program you can use to view, search, set permissions for, and digitally sign XPS documents. To begin using the XPS Viewer, open an XPS document. The following table describes toolbar buttons available in XPS Viewer.

Toolbar buttons in the XPS Viewer

Toolbar button Description

File

Open an XPS document in the viewer, save a copy of a document, or exit the viewer. You can also view document information, like the author or creation date.

Permissions

Set, make changes to, and view document permissions. You can also select the account you want to use for permissions. If you're the document author, you can set or make changes to document permissions. If you're not the document author, you can see which document permissions you have.

Signatures

Digitally sign the document, request signatures from other people, and view digital signatures that have already been applied to the document.

Contents

View an outline of the document on the Contents pane.

Note

Some documents might not have outlines.

Print

Print an XPS document. If permissions have been applied to the document, make sure you have print permissions before you try to print it.

Find box

Search the document for a word or phrase. The search results will appear in the Contents pane.

XPS documents: frequently asked questions

Here are answers to some common questions about XPS documents.

What is an XPS document?

An XML Paper Specification (XPS) document is a document format you can use to view, save, share, digitally sign, and protect your document’s content. An XPS document is like to an electronic sheet of paper: You can’t change the content on a piece of paper after you print it, and you can’t edit the contents of an XPS document after you save it in the XPS format. In this version of Windows, you can create an XPS document in any program you can print from, but you can only view, sign, and set permissions for XPS documents in the XPS Viewer.

How do I create an XPS document?

You can create an XPS document in any program you can print from, including the entire Microsoft Office system. To learn how to create an XPS document in Microsoft Office, go to the Microsoft Office Help and How-to Web site and search for information about how to save a file in XPS format.

To create an XPS document in other programs, such as Notepad or WordPad

  1. Click the File menu, and then click Print.

  2. In the Print dialog box, select Microsoft XPS Document Writer from the list of available printers, and then click Print.

  3. In the Save the file as dialog box, name your XPS document, and then click Save.

How do I view an XPS document?

While you can create an XPS document in any program you can print from, you can only view, digitally sign, or set permissions for an XPS document in the XPS Viewer, which is included in Windows Server® 2008 R2.

Double-click an XPS document to view it in the XPS Viewer; the document opens in the viewer automatically. To learn more about the toolbars and features in the XPS Viewer, see Using the XPS Viewer.

How can I verify and protect an XPS document?

You can verify an XPS document's authenticity with a digital signature and protect a document's contents with permissions.

A digital signature serves two purposes: It enables you to verify that your XPS document hasn’t been changed since you signed it, and to verify another XPS document’s publisher so you can make sure it comes from a trusted source before you open it.

You can also create permission restrictions for your XPS document so that no one can view, copy, print, or digitally sign your document without your permission. You can set time restrictions on permissions, allow as many or as few permissions as you want to other users, and allow different users to have different levels of access.