Features Available in Windows Server 2008

Features are software programs available in Windows Server® 2008 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

The following table identifies and describes features that you can install by using the Server Manager Add Features Wizard, available as part of Windows Server 2008.

Feature | Description
Microsoft .NET Framework 3.0 Features | Microsoft .NET Framework 3.0 combines the power of the .NET Framework 2.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.
BitLocker Drive Encryption | BitLocker Drive Encryption helps to protect data on lost, stolen or inappropriately decommissioned computers by encrypting the entire volume and checking the integrity of early boot components. Data is only decrypted if those components are successfully verified and the encrypted drive is located in the original computer. Integrity checking requires a compatible trusted platform module (TPM).
BITS Server Extensions | Background Intelligent Transfer Service (BITS) Server Extensions allow a server to receive files uploaded by clients using BITS. BITS allows client computers to transfer files in the foreground or background asynchronously, preserve the responsiveness of other network applications, and resume file transfers after network failures and computer restarts.
Connection Manager Administration Kit | Connection Manager Administration Kit (CMAK) generates Connection Manager profiles.
Desktop Experience | Desktop Experience includes features of Windows Vista®, such as Windows Media Player, desktop themes, and photo management. Desktop Experience does not enable any of the Windows Vista features by default; you must manually enable them.
Group Policy Management | Group Policy Management makes it easier to understand, deploy, manage, and troubleshoot Group Policy implementations. The standard tool is Group Policy Management Console (GPMC), a scriptable Microsoft Management Console (MMC) snap-in that provides a single administrative tool for managing Group Policy across the enterprise.
Internet Printing Client | Internet Printing Client enables clients to use Internet Printing Protocol (IPP) to connect and print to printers on the network or Internet.
Internet Storage Name Server (iSNS) | Internet Storage Name Server (iSNS) provides discovery services for Internet Small Computer System Interface (iSCSI) storage area networks. iSNS processes registration requests, deregistration requests, and queries from iSNS clients.
LPR Port Monitor | Line Printer Remote (LPR) Port Monitor enables the computer to print to printers that are shared using any Line Printer Daemon (LPD) service. (LPD service is commonly used by UNIX-based computers and printer-sharing devices.)
Message Queuing | Message Queuing provides guaranteed message delivery, efficient routing, security, and priority-based messaging between applications. Message Queuing also accommodates message delivery between applications that run on different operating systems, use dissimilar network infrastructures, are temporarily offline, or that are running at different times.
Multipath I/O | Microsoft Multipath I/O (MPIO), along with the Microsoft Device Specific Module (DSM) or a third-party DSM, provides support for using multiple data paths to a storage device on Microsoft Windows.
Peer Name Resolution Protocol | Peer Name Resolution Protocol (PNRP) allows applications to register on and resolve names from your computer, so other computers can communicate with these applications.
qWave | Quality Windows Audio Video Experience (qWave) is a networking platform for audio and video (AV) streaming applications on Internet protocol home networks. qWave enhances AV streaming performance and reliability by ensuring network quality-of-service for AV applications. It provides 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.
Remote Assistance | Remote Assistance enables you (or a support person) to offer assistance to users with computer issues or questions. Remote Assistance allows you to view and share control of the user’s desktop in order to troubleshoot and fix the issues. Users can also ask for help from friends or co-workers.
Remote Server Administration Tools | Remote Server Administration Tools enables remote management of Windows Server 2003 and Windows Server 2008 from a computer running Windows Server 2008 by allowing you to run some of the management tools for roles, role services, and features on a remote computer.
Removable Storage Manager | Removable Storage Manager (RSM) manages and catalogs removable media and operates automated removable media devices.
Remote Differential Compression | 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.
RPC Over HTTP Proxy | RPC Over HTTP Proxy is a proxy that is used by objects that receive remote procedure calls (RPC) over Hypertext Transfer Protocol (HTTP). This proxy allows 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.
Services for NFS | Services for Network File System (NFS) is a protocol that acts as a distributed file system, allowing a computer to access files over a network as easily as if they were on its local disks. This feature is available for installation on 64-bit versions of Windows Server 2008 only; in other versions of Windows Server 2008, Services for NFS is available as a role services of the File Services role.
SMTP Server | SMTP Server supports the transfer of e-mail messages between e-mail systems.
Storage Manager for SANs | Storage Manager for Storage Area Networks (SANs) helps you create and manage logical unit numbers (LUNs) on Fibre Channel and iSCSI disk drive subsystems that support Virtual Disk Service (VDS) in your SAN.
Simple TCP/IP Services | Simple TCP/IP Services supports the following TCP/IP services: Character Generator, Daytime, Discard, Echo and Quote of the Day. Simple TCP/IP Services is provided for backward compatibility and should not be installed unless it is required.
SNMP Services | Simple Network Management Protocol (SNMP) is the Internet standard protocol for exchanging management information between management console applications—such as HP Openview, Novell NMS, IBM NetView, or Sun Net Manager—and managed entities. Managed entities can include hosts, routers, bridges, and hubs.
Subsystem for UNIX-based Applications | Subsystem for UNIX-based Applications (SUA), along with a package of support utilities available for download from the Microsoft Web site, enables you to run UNIX-based programs, and compile and run custom UNIX-based applications in the Windows environment.
Telnet Client | Telnet Client uses the Telnet protocol to connect to a remote telnet server and run applications on that server.
Telnet Server | Telnet Server allows remote users, including those running UNIX-based operating systems, to perform command-line administration tasks and run programs by using a telnet client.
Trivial File Transfer Protocol (TFTP) Client | Trivial File Transfer Protocol (TFTP) Client is used to read files from, or write files to, a remote TFTP server. TFTP is primarily used by embedded devices or systems that retrieve firmware, configuration information, or a system image during the boot process from a TFTP server.
Failover Clustering | Failover Clustering allows multiple servers to work together to provide high availability of services and applications. Failover Clustering is often used for file and print services, database and mail applications.
Network Load Balancing | Network Load Balancing (NLB) distributes traffic across several servers, using the TCP/IP networking protocol. NLB is particularly useful for ensuring that stateless applications, such as a Web server running Internet Information Services (IIS), are scaleable by adding additional servers as the load increases.
Windows Server Backup | Windows Server Backup allows you to back up and recover your operating system, applications, and data. You can schedule backups to run once a day or more often, and can protect the entire server or specific volumes.
Windows System Resource Manager | Windows System Resource Manager (WSRM) is a Windows Server operating system administrative tool that can control how CPU and memory resources are allocated. Managing resource allocation improves system performance and reduces the risk that applications, services, or processes will interfere with each other to reduce server efficiency and system response.
Windows Internet Name Service (WINS) | Windows Internet Name Service (WINS) provides a distributed database for registering and querying dynamic mappings of NetBIOS names for computers and groups used on your network. WINS maps NetBIOS names to IP addresses and solves the problems arising from NetBIOS name resolution in routed environments.
Wireless LAN Service | Wireless LAN (WLAN) Service configures and starts the WLAN AutoConfig service, regardless of whether the computer has any wireless adapters. WLAN AutoConfig enumerates wireless adapters, and manages both wireless connections and the wireless profiles that contain the settings required to configure a wireless client to connect to a wireless network.
Windows Internal Database | Windows Internal Database is a relational data store that can be used only by Windows roles and features, such as UDDI Services, Active Directory Rights Management Services, Windows Server Update Services, and Windows System Resource Manager.
Windows PowerShell | Windows PowerShell is a command line shell and scripting language that helps IT professionals achieve greater productivity. It provides a new administrator-focused scripting language and more than 130 standard command line tools to enable easier system administration and accelerated automation.
Windows Process Activation Service | Windows Process Activation Service (WAS) generalizes the 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, using non-HTTP protocols. IIS 7.0 also uses WAS for message-based activation over HTTP.


Background Intelligent File Transfer (BITS) Server Extension Overview

The Background Intelligent Transfer Service (BITS) Server lets you configure a server that is running Internet Information Services (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, allowing the application to process the uploaded file. The Web application can then optionally reply to the client responsible for the upload.


BitLocker Drive Encryption Technical Overview

Windows® BitLocker™ Drive Encryption (BitLocker) is a data protection feature available in Windows Vista® Enterprise and Windows Vista® Ultimate for client computers, and in Windows Server® 2008. BitLocker addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned personal computers by providing a closely integrated solution in Windows Vista.

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 Windows Vista file and system protections. BitLocker also helps render data inaccessible when BitLocker-protected computers are decommissioned or recycled.

This document describes BitLocker, including its life cycle on an enterprise computer. The information in this paper applies to Windows versions with BitLocker. For server-specific information, see Implementing BitLocker on Servers.

Topics in this Technical Overview

This technical overview includes the following topics:

  • BitLocker Concepts

  • BitLocker Benefits

  • BitLocker Security Considerations

  • Implementing BitLocker on Servers

  • Hardware, Firmware, and Software Requirements

  • BitLocker Architecture

  • BitLocker Life Cycle

  • System Recovery

BitLocker Concepts

BitLocker helps prevent unauthorized access to data on lost or stolen computers by combining two major data-protection procedures:

  • Encrypting the entire Windows operating system volume on the hard disk.

  • Verifying the integrity of early boot components and boot configuration data.

The most secure implementation of BitLocker leverages the enhanced security capabilities of 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 running Windows Vista has not been tampered with while the system was offline.

In addition, BitLocker offers the option to lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable USB device, such as a 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.

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

Offline data enhancements

BitLocker helps protect data while the system is offline by:

  • Encrypting the entire Windows operating system volume, including both user data and system files, the hibernation file, the page file, and temporary files.

  • Providing an umbrella protection for non-Microsoft applications, which benefit automatically when installed on the encrypted volume.

System integrity verification

BitLocker uses the TPM to verify the integrity of early boot components and boot configuration data. This helps ensure that BitLocker makes the encrypted volume 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:

  • Providing 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.

  • Enhancing 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 volume.

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

BitLocker Benefits

BitLocker benefits include enhancements for ease of use, enterprise implementation, and computer decommissioning or recycling.

Ease of use

In day-to-day use, BitLocker protection is virtually transparent to the user. And in the event that system lockout occurs—for example, due to hardware failure, hardware changes, or an attempted security breach—BitLocker offers a simple, efficient recovery process.

Enterprise implementation

BitLocker is tightly integrated into Windows Vista and provides enterprises with a seamless and easily manageable data protection solution. For example, BitLocker can utilize an enterprise’s existing Active Directory® Domain Services (AD DS) infrastructure to remotely escrow 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. And BitLocker 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 or recycling

BitLocker simplifies the process of decommissioning or recycling computers. Data in the encrypted volume can be rendered inaccessible by deleting the BitLocker keys that are required to access the volume.

BitLocker Security Considerations

Because security is a process of risk management, it is important to be aware that 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 the PIN or Windows logon password are not kept secret.

The TPM-only authentication mode (that is, no startup key or PIN) provides the most transparent user experience for organizations that need a baseline level of data protection to meet security policies. The TPM-only 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. This mode protects against some attacks that modify early boot components, but the level of protection can be affected by potential security weaknesses in the operating system, hardware, or BIOS. The addition of a PIN or USB startup key can help mitigate many of these attacks. 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 Windows Server 2008 servers in a shared or potentially non-secure environment, such as a branch office location, BitLocker can offer the same level of data protection that it offers on client computers. This additional feature, which is available for Windows Server 2008, enables an IT administrator to encrypt both the operating system volume and additional data volumes on the same server.

By default, BitLocker is not installed with Windows Server 2008. Add BitLocker from the Windows Server 2008 Server Manager page. After BitLocker is installed, setup and maintenance are performed as described later in this document. You must restart after installing BitLocker on a server. Using WMI, you can enable BitLocker remotely.

PIN support

It might not be desirable to enable the PIN feature on a server where startup speed is a factor or where human intervention in case of a restart is not possible. In many server environments, uptime and remote management are critical. One feasible deployment scenario is to enable BitLocker with PIN authentication in branch offices where an employee must turn on the server at the start of every work shift. In this scenario, the individual responsible would know and enter the PIN at startup.

Startup key support

USB startup keys are supported for servers, but they only increase data protection if they are not left in the server after startup. Therefore, to maximize data protection, someone must manually insert the startup key at each server restart and then remove the key until needed again.

Extensible Firmware Interface support

BitLocker is supported on Extensible Firmware Interface (EFI) servers using a 64-bit processor architecture installed with Windows Server 2008.

Data volumes

Volumes other than the operating system volume and the system volume are called data volumes. BitLocker encryption of data volumes is supported only in Windows Server 2008. BitLocker encrypts Windows Server 2008 data volumes the same way that it encrypts the operating system volume. The operating system can read a BitLocker-protected data volume as normal.

Automatic unlock

You can configure BitLocker to unlock mounted data volumes automatically during startup, without human interaction. BitLocker accomplishes this by encrypting a data volume's volume master key with an external wrapping key, and then storing a plaintext copy of the external wrapping key in the registry of the encrypted operating system volume. Because the external wrapping key is stored within the encrypted operating system volume, it is protected by BitLocker as well as by the Windows Server 2008 operating system itself. If the operating system enters recovery mode, the data volumes remain protected.

If you enable automatic unlock, turning off BitLocker has the same effect on data volumes as it does on the operating system volume:

  • If you decrypt the operating system volume, BitLocker will also decrypt the protected data volumes and remove all automatic unlock keys from the registry.

  • If you temporarily disable BitLocker, the operating system volume and data volumes will remain encrypted; however, the key protecting the operating system volume will be accessible until you turn BitLocker back on.

Using a scriptable WMI interface, a system administrator can enable or disable automatic unlocking for each server. To maintain a high level of protection for data volumes, you cannot enable automatic unlocking unless BitLocker is enabled for the operating system volume and the volume is encrypted.

Cluster configurations

BitLocker does not support cluster configurations.

Data volume recovery

The recovery of a data volume is similar to recovery for an operating system volume. A copy of the recovery key must be stored on other media prior to a failure (preferably at the time of setup). If the data volume is moved to a new server, or if the operating system cannot retrieve the external wrapping key to automatically unlock the data volume, then a user must insert the media containing the recovery key.

Recovery of data volumes is supported by the BitLocker control panel and the WMI provider.

Hardware, Firmware, and Software Requirements

To use BitLocker, a computer must satisfy certain requirements that are specified by the BitLocker Windows Vista system logo requirements.

  • For BitLocker to take advantage of 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 USB device such as a flash drive. For more information about using BitLocker on a non-TPM computer, see Startup key-only scenario (no TPM).

  • 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 volumes:

    • The operating system volume (or boot volume) contains the Windows Vista operating system and its support files; it must be formatted with the NTFS file system. BitLocker is enabled on this volume.

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

BitLocker Architecture

BitLocker helps protect the operating system volume of the hard disk from unauthorized access while the computer is offline. To achieve this, BitLocker uses full-volume encryption and the security enhancements offered by the TPM. On computers that have a TPM, BitLocker also supports multifactor authentication.

BitLocker uses the TPM to perform system integrity checks on critical early boot components. The TPM collects and stores measurements from multiple early boot components and boot configuration data to create a system identifier for that computer, much like a fingerprint. If the early boot components are changed or tampered with, such as by changing the BIOS, changing the master boot record (MBR), or moving the hard disk to a different computer, the TPM prevents BitLocker from unlocking the encrypted volume and the computer enters recovery mode. If the TPM verifies system integrity, BitLocker unlocks the protected volume. The operating system then starts and system protection becomes the responsibility of the user and the operating system.

Figure 1 shows how the BitLocker-protected volume is encrypted with a full volume encryption key, which in turn is encrypted with a volume master key. Securing the volume master key is an indirect way of protecting data on the volume: the addition of the volume master key allows the system to be re-keyed easily when keys upstream in the trust chain are lost or compromised. This ability to re-key the system saves the expense of decrypting and encrypting the entire volume again.

Figure 1 Relationship between different encryption keys in BitLocker

BitLocker key protector architecture

Once BitLocker authenticates access to the protected operating system volume, a filter driver in the Windows Vista file system stack encrypts and decrypts disk sectors transparently as data is written to and read from the protected volume. When the computer hibernates, the hibernation file is saved encrypted to the protected volume. When the computer resumes from hibernation, the encrypted hibernation file is decrypted. After BitLocker encrypts the protected volume during setup, the impact on day-to-day system performance for encryption and decryption is typically minimal.

If you temporarily disable BitLocker (for example, to update the BIOS), the operating system volume remains encrypted, but the volume master key will be encrypted with a "clear key" stored unencrypted on the hard disk. The availability of this unencrypted key disables the data protection offered by BitLocker. When BitLocker is re-enabled, the unencrypted key is removed from the disk, the volume master key is keyed and encrypted again, and BitLocker protection resumes.

IT administrators can configure BitLocker locally through the BitLocker setup wizard, or both locally and remotely with the interfaces exposed by the Win32_EncryptableVolume WMI provider of the Windows Vista operating system. Interfaces include management functionality to begin, pause, and resume encryption of the volume and to configure how the volume is protected.

A management script (manage-bde.wsf), which is available with Windows Vista and Windows Server 2008, provides IT administrators with a simple command-line interface to manage and check BitLocker status. This script is written based on the available WMI providers, and can be modified to help build custom solutions for different enterprise administrative needs. For more information about the BitLocker Drive Encryption Provider, see http://go.microsoft.com/fwlink/?LinkId=80600.

Architectural diagram

Figure 2 shows the overall BitLocker architecture, including its various subcomponents. It displays the user mode and the kernel mode components of BitLocker, including the TPM, and the way they integrate with the different layers of the operating system.

Figure 2 Overall BitLocker architecture

BitLocker architecture

Authentication modes in the boot sequence

BitLocker supports four different authentication modes, depending on the computer's hardware capabilities and the desired level of security:

  • BitLocker with a TPM (no additional authentication factors)

  • BitLocker with a TPM and a PIN

  • BitLocker with a TPM and a USB startup key

  • BitLocker without a TPM (USB startup key required)

Each time Windows Vista starts up with BitLocker enabled, the boot code performs a sequence of steps based on the volume protections set. These steps can include system integrity checks and other authentication steps (PIN or USB startup key) that must be verified before the protected volume is unlocked.

For recovery purposes, BitLocker uses a recovery key (stored on a USB device) or a recovery password (numerical password), as shown in Figure 1. You create the recovery key or recovery password during BitLocker initialization. Inserting the recovery key or typing the recovery password enables an authorized user to regain access to the encrypted volume in the event of an attempted security breach or system failure.

BitLocker searches for keys in the following sequence:

  1. Clear key: System integrity verification has been disabled and the BitLocker volume master key is freely accessible. No authentication is necessary.

  2. Recovery key or startup key (if present): If a recovery key or startup key is present, BitLocker will use that key immediately and will not attempt other means of unlocking the volume.

  3. Authentication

    1. TPM: The TPM successfully validates early boot components to unseal the volume master key.

    2. TPM + startup key: The TPM successfully validates early boot components and a USB flash drive containing the correct startup key has been inserted.

    3. TPM + PIN: The TPM successfully validates that early boot components and the user enters the correct PIN.

  4. Recovery

    1. Recovery password: The user must enter the correct recovery password.

    2. Recovery key: If none of the above steps successfully unlocks the drive, the user is prompted to insert the USB flash drive that holds the recovery key, and then restart the computer.

Foreign volumes

Foreign volumes are operating system volumes that were BitLocker-enabled on another computer and have been transferred to a different Windows Vista computer. Transferring a foreign volume to another Windows Vista computer is a quick and straightforward procedure to recover BitLocker-protected data from a broken computer. The only authentication operation available on such a volume is recovery, which requires a recovery key or recovery password. For more information about recovery, see System Recovery.

BitLocker Life Cycle

There are four major stages in the BitLocker life cycle, as shown in Figure 3. Those stages include installation, initialization, daily use, and computer decommissioning or recycling.

Figure 3 BitLocker life cycle

BitLocker lifecycle
  1. Installation: BitLocker is installed as part of Windows Vista or added as an option for Windows Server 2008.

  2. Initialization: BitLocker is initialized and enabled.

  3. Daily use: The computer is used in everyday scenarios. BitLocker provides a level of protection based on the authentication option selected during initialization.

  4. Computer decommissioning and recycling: A BitLocker-enabled computer needs to be decommissioned or recycled.

The following sections describe each of these stages. For a detailed architectural diagram, see the architectural diagram.

Installation

For Windows Vista Enterprise and Windows Vista Ultimate, BitLocker is installed automatically as part of the operating system installation. However, BitLocker is not enabled until it is turned on using the BitLocker control panel.

Initialization

At any time after installation and initial operating system setup, the system administrator can use the Control Panel in Windows Vista 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 control panel, or by running a script designed to initialize it. The TPM Initialization Wizard is accessible through the TPM Management Console Wizard, which is started from a link in the BitLocker control panel. Opening the BitLocker control panel will automatically start TPM initialization, if necessary. Remote initialization of the TPM is also supported. Although physical presence is generally required to initialize a computer's TPM, if a computer is shipped with the TPM already turned on, then physical presence is not required. The TPM services component of BitLocker includes a management API that allows scripting the initialization procedures — including setting an owner and creating the TPM administration password.

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

Caution

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 operating system volume.

BitLocker and TPM initialization must be performed by a member of the local Administrators group on the computer. A non-administrator user benefits from BitLocker data protection, but cannot enable or disable it.

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

Daily use

Once BitLocker has been initialized and the volume encrypted, a user encounters it only during authentication and occasional administrative tasks.

BitLocker supports four different authentication modes, depending on the computer's hardware capabilities and the desired level of security:

  • BitLocker with a TPM

  • BitLocker with a TPM and a PIN

  • BitLocker with a TPM and a USB startup key

  • BitLocker without a TPM (USB startup key required)

BitLocker-enabled computers that rely solely on a TPM for authentication, with no additional BitLocker authentication factors, can be used just like any other computer. Users start Windows and are prompted for their user name and password, which is a normal logon experience. Unless informed about BitLocker, users are likely unaware that their computers include an extra level of data protection.

If BitLocker is configured for enhanced security, the user is required to enter a PIN or insert a USB startup key in order to start Windows Vista. In this case, the normal startup flow or resume flow is modified to prompt for the additional authentication factor.

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

TPM-only scenario

In this scenario, BitLocker is enabled on a computer that has a TPM, but no additional authentication factors have been enabled. The hard disk is partitioned with two volumes:

  1. The system volume

  2. The Windows Vista operating system volume

As shown in Figure 4, BitLocker encrypts the operating system volume with a full volume encryption key. This key is itself encrypted with the volume master key, which, in turn, is encrypted by the TPM.

Figure 4 Accessing a BitLocker-enabled volume with TPM protection

BitLocker with TPM protection

This scenario can be enabled or disabled by the local administrator using the Security item in Control Panel in Windows Vista. Turning BitLocker off decrypts the volume and removes all keys. New keys are created once BitLocker is turned back on at a later time.

Caution

When a local administrator turns on 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 might be inaccessible and unrecoverable if there is a problem with the operating system volume.

Enhanced authentication scenarios

These scenarios add additional authentication factors to the basic scenario described previously. As shown in Figure 5, using BitLocker on a computer that has a TPM offers two multifactor authentication options:

  • The TPM plus a PIN (system integrity check plus something the user knows)

  • The TPM plus a startup key stored on a USB flash drive (system integrity check plus something the user has)

The advantage of these scenarios is that not all key material is stored on the local computer.

Figure 5 Accessing a BitLocker-enabled volume with enhanced protection

BitLocker with two-factor authentication
PIN authentication

In this scenario, the administrator sets up a numeric PIN during BitLocker initialization. BitLocker hashes the PIN using SHA-256 and the first 160 bits of the hash are used as authorization data sent to the TPM to seal the volume master key. The volume master key is now protected by both the TPM and the PIN. To unseal the volume master key, the user will be required to enter the PIN each time the computer starts up or resumes from hibernation.

Note

For server implementations, it might not be desirable to enable PIN authentication where startup speed is a factor or where human intervention in case of a restart is not possible.

Startup key authentication

In this scenario, the administrator creates a startup key during BitLocker initialization. The key is stored on any BIOS-enumerated storage device such as a pluggable USB flash drive, and the user must insert that device in the computer each time the computer starts up or resumes from hibernation. While the USB flash drive holding the startup key must be plugged into the computer from power up through startup, it should be removed after Windows is loaded.

Startup key-only scenario (no TPM)

In this scenario, the administrator enables BitLocker on a computer that does not contain a TPM. The computer user must insert the USB flash drive containing a startup key each time the computer starts or resumes from hibernation.

Note

The security profile of a system using a startup key-only scenario will be different from the security profile of a system using a TPM; the integrity of the early boot components will not be validated on the non-TPM system.

The startup key for a non-TPM computer must be created during BitLocker initialization, either through the BitLocker setup wizard or through scripting. BitLocker generates the startup key, the user inserts a USB flash drive, and the system stores the startup key on that device.

Using the BitLocker Control Panel item, the user can create a backup copy of the startup key. The startup key is saved unencrypted, in a “.bek” file as raw binary data. In the case of a lost startup key, the volume must be recovered by using the recovery key or the recovery password and a new startup key must be generated (this process will revoke the original startup key). All other volumes also using the lost startup key must go through a similar procedure, to ensure that the lost startup key is not used by an unauthorized user.

Administration

The administrator can manage BitLocker using the BitLocker control panel, accessible from the Security item in the Windows Vista Control Panel. A command-line management tool, manage-bde.wsf, is also available for IT administrators to perform scripting functionality remotely.

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

Once the volume has been encrypted and protected with BitLocker, the Manage Keys page in the BitLocker control panel enables local and domain administrators to duplicate keys and reset the PIN.

BitLocker configuration and TPM management

The BitLocker control panel, accessible from the Security item in the Windows Vista Control Panel, displays BitLocker status and provides the functionality to enable or disable BitLocker. If BitLocker is actively encrypting or decrypting data due to a recent installation or uninstall request, the progress status appears. An administrator can also use the BitLocker control panel to access the TPM management MMC. For more information, see Initialization.

Computer updates and upgrades: disabling BitLocker protection

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

  • 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 disk volume 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 item in Control Panel in Windows.

The following steps are necessary to upgrade a BitLocker-enabled 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 volume encrypted, but the volume 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 re-enabled, the unencrypted key is removed from the disk and BitLocker protection is turned back on. Additionally, the volume master key is keyed and encrypted again.

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

Caution

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

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

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 leave the company 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.

Caution

Perform the procedures described in this section only if you do not want or need the data in the future. The data in the encrypted volume will not be recoverable.

An administrator can remove a volume’s BitLocker keys by formatting that volume from Windows Vista. The “format” command has been updated to support this operation. To format the operating system volume, you can open a command prompt using the recovery environment included in the Windows Vista installation DVD.

Alternatively, an administrator can create a script that effectively removes all BitLocker key protectors. Running such a script will leave all BitLocker-encrypted data unrecoverable when you restart the computer. As a safety measure, BitLocker requires that an encrypted volume have at least one key protector. Given this requirement, you can decommission the drive by creating a new external key protector, avoid saving the created external key information, and then removing all other key protectors on the volume. For more information about writing scripts for BitLocker, see Win32_EncryptableVolume (http://go.microsoft.com/fwlink/?LinkId=85983).

Once the BitLocker keys have been removed from the volume, follow-up tasks are needed to complete the decommissioning process. For example: reset the TPM to its factory defaults by clearing the TPM, and discard saved recovery information for the volume such as printouts, files stored on USB devices, and information stored in Active Directory.

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

  • 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 down an encrypted drive and require that users obtain BitLocker recovery information to unlock the drive

If BitLocker enters recovery mode, the data in the encrypted volume can be recovered through a process that requires minimal setup. For detailed information, see Windows BitLocker Drive Encryption Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=53779).

Recovery setup

Using Group Policy, an IT administrator can choose what recovery methods to require, deny, or make optional for users who enable BitLocker. The recovery password can be stored in Active Directory Domain Services (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 scenarios

In BitLocker, recovery consists of decrypting a copy of the volume master key using either a recovery key stored on a USB flash drive or a cryptographic key derived from a recovery password. The TPM is not involved in any recovery scenarios, so recovery is still possible if the TPM fails boot component validation, malfunctions, or is removed.

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 using the function keys (F0 through F9). The recovery password can be managed and copied after BitLocker is enabled. Using the BitLocker 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 transparently 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.


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

CMAK is a feature included with Microsoft® Windows Server® 2008.

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.

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


Desktop Experience Overview

The Desktop Experience feature is a new feature in the Microsoft® Windows Server® 2008 operating system. The Desktop Experience includes a variety of applications and features that are provided in the Windows Vista® operating system. If you use Windows Server 2008 as your primary operating system you might want to have some of these Windows Vista features available for your daily use.

What’s in the Desktop Experience feature

The Desktop Experience feature includes the following Windows Vista components and features:

  • Windows Calendar

  • Windows Mail

  • Windows Media Player

  • Windows Aero™ and other desktop themes

  • Video for Windows (AVI support)

  • Windows Photo Gallery

  • Windows SideShow™

  • Windows Defender

  • Disk Cleanup

  • Sync Center

  • Sound Recorder

  • Character Map

Installing or uninstalling the Desktop Experience feature

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

To install Desktop Experience with 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 with 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.


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, Explain 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 Management snap-in to validate failover cluster configurations, create and manage failover clusters, and migrate some resource settings from a cluster running Microsoft Windows Server® 2003 to a cluster running Windows Server 2008.

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." In addition, the complete configuration (servers, network, and storage) must pass all tests in the Validate a Configuration wizard, which is included in the Failover Cluster Management snap-in.

The software used for managing a failover cluster is the Failover Cluster Management snap-in, which is installed as part of the failover cluster feature in Windows Server 2008. 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 Management.

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=86168.

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

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


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), or using the Network Printer Installation Wizard.

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. If you can connect to the print server by using an RPC connection, you do not need the Internet Printing Client.


iSNS Server Overview

Internet Storage 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 are the parts of

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.


Line Printer Remote Port Monitor Overview

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

Note

You don't 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 or Windows Server 2008 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. Open Print Management from the Administrative Tools folder.

  2. 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.


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 at 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 at 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 at 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 at 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 at 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.

Windows 2000 Client Support

This feature provides Active Directory access for Message Queuing 2.0 clients running on Windows 2000 computers in the domain. If you intend to install Message Queuing on a Windows 2000 computer in a site, you must install Message Queuing with Windows 2000 Client Support on a Windows Server® 2008 domain controller in the site, or install a Message Queuing server on a Windows 2000 domain controller in the site, or promote the Windows 2000 computer on which you want to install a Message Queuing server to a domain controller

Message Queuing DCOM Proxy

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


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

-r

-n

Option | Description
-r | Automatically restarts without prompting
-n | Suppress restart request.

Install_switch

-i

-u

Option | Description
-i | Installs MPIO and add multipath support for a storage device
-u | Remove MPIO and discontinue support for a storage device

device_switch

-d <device_hwid>

-a

-c

Option | Description
-d <device_hwid> | Specifies devices for which you want MPIO support. Device IDs are separated by a space.
-a | Apply MPIO support to all compatible devices.
-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

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.


.NET Framework 3.0 Features Overview

.NET Framework 3.0 Features in Windows Server 2008

Microsoft .NET Framework 3.0 combines the power of the .NET Framework 2.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.0 elements are required by server roles such as Application Server.

Elements of .NET Framework 3.0 Features

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

Feature | Description
XPS Viewer | An XML Paper Specification (XPS) document is electronic paper that provides a high-fidelity reading and printing experience. The XPS Viewer facilitates the viewing, signing, and protection of XPS documents.
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.0 Features

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


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 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 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 instructions on how to configure NLB with Terminal Services, see http://go.microsoft.com/fwlink/?LinkId=80406.

  • 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)


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.

Remote Assistance (RA) in Windows Vista® includes a number of improvements in connectivity, performance, usability, and security along with feature enhancements that make it even more useful than RA in Windows® XP. With increased Group Policy support, command-line scripting capabilities, session logging, bandwidth optimization, and more, Remote Assistance is now an essential tool for enabling enterprises to support users in Help Desk scenarios.

Improvements to Remote Assistance in Windows Vista

Windows Vista includes a number of new features and enhancements for Remote Assistance compared to the Remote Assistance available in Windows XP, including the following.

  • Connectivity improvements with transparent NAT traversal using Teredo and Internet Protocol version 6 (IPv6).

  • An improved user interface that is easier to launch and use.

  • A standalone executable (msra.exe) that accepts command-line arguments and can easily be scripted.

  • Improved overall performance with a smaller footprint, quicker startup and connect times, and optimized bandwidth usage for screen updates.

  • Enhanced security with mandatory password and integration with User Account Control (UA)C.

  • New Offer RA via IM scenario and an open API for integration with peer-to-peer applications.

  • Additional Group Policy settings for improved manageability.

Remote Assistance in Windows Vista deprecates the following features that were available in Windows XP.

  • No more support for the MAILTO method of solicited Remote Assistance

  • No more support for voice sessions

How Remote Assistance Works

In Remote Assistance, the person needing help is referred to as the User (or Novice) and the support person providing assistance is called the Helper (or Expert). RA is launched from the Start Menu by navigating to All Programs, clicking Maintenance, and then selecting Windows Remote Assistance. It can also be launched from a command prompt by typing msra.exe.

Remote Assistance has two basic modes of operation.

  • Solicited RA. In Solicited RA (also known as Escalated RA) the User requests assistance from the Helper by initiating the RA session using e-mail, instant messaging, or by providing the Helper with a saved copy of an invitation file (*.MsRcIncident). Each of these methods uses a different underlying mechanism:

    • Solicited RA Using E-mail. This method requires that the e-mail clients being used by the User support Simple Mail Application Programming Interface (SMAPI). An example of an e-mail client that supports SMAPI is Windows Mail, which is included with Windows Vista. Other examples of SMAPI-compliant e-mail clients include Microsoft Outlook and other third-party clients. In this approach, the User launches the RA user interface to create an e-mail message that has an RA invitation file (*.MsRcIncident) attached to the message. The User must enter a password for the RA session, which must be communicated to the Helper using an out-of-band (OOB) method such as calling the Helper on the telephone. When the Helper receives the User’s RA invitation, she opens the attached ticket, enters the password that was conveyed by the User, and the RA session starts. The Helper must respond to the invitation from the User within a specified time limit (default is 6 hours) or the invitation will expire and a new one will need to be sent. In a domain environment this ticket lifetime can also be configured using Group Policy. See the section titled “Managing Remote Assistance Using Group Policy.”

    • Solicited RA Using File Transfer. This method requires that both the User and Helper have access to a common folder (such as a network share on a file server) or that they use some other method for transferring the file (for example, by using a USB key to manually transfer the file or by uploading the file to an FTP site). The user creates an RA invitation file and saves it in the shared folder. The User must provide a password that must be communicated to the Helper using an out-of-band (OOB) method such as a telephone call. The Helper retrieves the ticket from the shared folder, opens it, enters the password, and the RA session starts. Again, the Helper must respond to the invitation within a specified time or the invitation will expire and a new one will be needed (the expiration time is configurable using Group Policy).

    • Solicited RA Using Instant Messaging. This method for soliciting assistance requires that the instant messaging (IM) applications being used by both the User and the Helper support Microsoft’s new Rendezvous API. Windows Live Messenger is an example of an IM application that supports Rendezvous. Windows Live Messenger is available as a download. In this approach, the User requests assistance from someone on his buddy list. To ensure that the remote person is really the User’s buddy (and not someone masquerading as the buddy), Remote Assistance requires that a password be relayed from the User to the Helper by other means (such as a phone call) before the Helper can connect. For more information on the Rendezvous API, see the Windows SDK on MSDN at http://windowssdk.msdn.microsoft.com/en-us/library/default.aspx.

  • Unsolicited RA. In Unsolicited RA (also known as Offer RA) the Helper offers help to the User by initiating the RA session.

    • Offer RA using DCOM. This is a typical corporate Help Desk scenario in which all the users are in a domain. The Helper enters either the fully qualified name (FQDN) or IP address of the User’s computer to connect to the User’s computer. This method requires that the Helper has been previously authorized a domain administrator to be able to offer Remote Assistance to the Users. (For information on how to authorize Helpers for offering RA, see the section titled “Managing Remote Assistance Using Group Policy.”) This method also requires that the Helper either knows the name (the host name on a local subnet; the fully qualified name otherwise) or address (IPv4 or IPv6) of the User’s computer.

    • Offer RA using Instant Messaging. This method for soliciting assistance requires that the instant messaging (IM) applications being used by both the User and the Helper support the Rendezvous API. In this approach, the Helper offers assistance to someone on her buddy list. If the buddy agrees, then he must enter a password to be used by the Helper. The password must be relayed by an OOB mechanism to ensure that the remote person is really the User’s buddy (and not someone masquerading as the buddy).

Remote Assistance Operational States

Remote Assistance has three operational states.

  • Waiting For Connect. This state occurs when either:

    • The Helper has offered RA to the User but the User has not yet agreed to allow the Helper to connect to his computer.

    • The User has sent the Helper an invitation but the Helper has not yet responded by opening the invitation, or the Helper has opened the invitation and the User has not yet agreed to allow the Helper to connect to his computer.

    In the Waiting For Connect state, the Helper cannot view or control the screen of the User’s computer until an RA connection has been established and both computers have entered the Screen Sharing state. Once the RA application has been started and is running in the Waiting For Connect state, the application should not be closed until the other party responds and establishes the connection. For example, if the User uses the Solicit RA Using E-mail method and sends an invitation file to a Helper, the RA application opens on the User’s computer and waits for the Helper to accept the invitation. If the User closes RA on her computer before the Helper accepts the invitation, the Helper will not be able to connect to the User’s computer and the User will need to send a new invitation.

  • Screen Sharing. This state occurs when the User has consented to allow the Helper to connect to his computer—either after the User has sent the Helper an invitation or the Helper has offered RA to the User. In the Screen Sharing state, an RA session has been established and the Helper can view—but not control—the screen of the User’s computer.

    When the User is prompted for consent to allow the Helper to connect to his computer, a warning message appears on the User’s computer saying that the Helper wants to connect to his computer. This warning message is customizable using Group Policy. For more information, see the section titled “Managing Remote Assistance Using Group Policy.”

  • Control Sharing. This state occurs after the Screen Sharing state, when the Helper has requested control of the User’s computer and the User has consented to allow the Helper to have shared control of his computer. In the Control Sharing state, the Helper has the same level of access to the User’s computer that the User has and the Helper can use his own mouse and keyboard to remotely perform actions on the User’s computer. Specifically:

    • If the User is a standard user on his computer, the Helper will only be able to perform actions on the User’s computer that can be performed by a standard user on that computer.

    • If the User is a local administrator on his computer, the Helper will be able to perform any actions on the User’s computer that can be performed by a local administrator on that computer.

    For more information on the level of control that a Helper has on a User’s computer, see the section titled “Remote Assistance and the Secure Desktop” in the Windows Vista Resource Kit.

User vs. Helper Functionality

Once an RA connection has been established and both computers have entered the Screen Sharing state, the User and Helper are able to perform the tasks listed in the following table.

Description of Task | User? | Helper?
Chat | Yes | Yes
Send files | Yes | Yes
Save a log of session activity | Yes (default) | Yes (default)
Configure bandwidth usage | Yes | No
Pause (temporarily hide screen) | Yes | No
Request shared control | No | Yes
Give up shared control | Yes | Yes
Disconnect | Yes | Yes
Disconnect using Esc key | Yes | No

Remote Assistance and NAT Traversal

Remote Assistance works by establishing a peer-to-peer connection between the User’s computer and the Helper’s computer. One challenge this poses is that it can be difficult to establish peer-to-peer connections if one or both of the computers involved are behind a gateway or router that uses Network Address Translation (NAT). NAT is an IP routing technology described by RFC 1631 that is used to translate IP addresses and TCP/UDP port numbers of packets being forwarded. NAT is typically used to map a set of private IP addresses to a single public IP address (or to multiple public addresses). Home networks using a wireless or wired router also use NAT technology.

To overcome this difficulty, Windows Vista includes built-in support for Teredo, an IPv6 transition technology described in RFC 4380 that provides address assignment and automatic tunneling for unicast IPv6 connectivity across the IPv4 Internet. The NAT traversal capability provided by Teredo in Windows Vista allows RA connectivity when one or both of the users involved in an RA session are hidden behind a NAT. The RA experience is transparent from the perspective of the users involved, regardless of whether NAT is being used on either user’s network. For most small business and home user environments, The RA in Windows Vista will seamlessly traverse a NAT-enabled router with no additional router configuration required. For information on enterprises that need to remotely support users who work from home, see the section titled “Enterprise Remote Assistance Scenarios.”

Note

Offering RA using DCOM is not usually a Teredo scenario because enterprise users are behind a corporate firewall and not separated from each other by NATs.

Remote Assistance will not connect in certain configurations. Specifically:

  • Teredo cannot traverse a symmetric NAT. Remote Assistance can only connect across restricted NATs and cone NATs. In most cases, this is not a significant limitation because the large majority of deployed NATs are either the restricted or cone variety.

  • RA will not work if the NAT-enabled router is configured to block the specific ports used by RA. For more information, see the section titled “Remote Assistance and Windows Firewall.”

  • Remote Assistance will not work if the user’s NAT-enabled router is configured to block all UDP traffic.

Note

To determine the type of NAT a network is using, open an elevated command prompt and type netsh interface teredo show state.

Remote Assistance and IP Ports Used

The ports used by a Remote Assistance session depend on whether the session is between two computers running Windows Vista or between a computer running Windows Vista and a downlevel Windows XP computer. Specifically:

  • Windows Vista to Windows Vista RA Session: Dynamic ports allocated by the system in the range TCP/UDP 49152–65535

  • Windows Vista to Windows XP RA Session: Port 3389 TCP (local/remote)

    In addition, the Offer RA via DCOM scenario uses Port 135 (TCP).

Remote Assistance and Windows Firewall

Windows Firewall is configured with a group exception for Remote Assistance. This group exception has multiple properties that are grouped together as part of the RA exception. The RA exception properties will change depending on the network location of the computer (private, public, or domain). For example, the default RA exception when the computer is in a public location is stricter than when the computer is in a private location. In a public location (such as an airport), the RA exception is disabled by default and does not open ports for UPnP technology and Simple Service Discovery Protocol (SSDP) traffic. In a private network (a home or work network, for example) the RA exception is enabled by default and UPnP and SSDP traffic is permitted.

The following table summarizes the state of the Remote Assistance firewall inbound exception for each type of network location. The RA exception has outbound properties as well; however, the Windows Firewall is not by default configured to enable outbound properties.

Default State Of Remote Assistance Firewall Inbound Exception For Each Type Of Network Location

Network Location State of RA Exception Default Properties of the RA Exception

Private (Home or Work)

Enabled by default
  • Msra.exe application exception

  • UPnP enabled for communications with UPnP NATs

  • Edge traversal enabled to support Teredo

Public

Disabled by default—must be enabled by user with Admin credentials
  • Msra.exe application exception

  • Edge traversal enabled to support Teredo

Domain

Disabled by default—typically enabled by Group Policy
  • Msra.exe application exception

  • RAServer.exe (the RA COM server) application exception

  • DCOM Port 135

  • UPnP enabled for communications with UPnP NATs

In other Windows Firewall profiles, the default configuration of the Remote Assistance exception is as follows.

  • Private profile. The RA exception in the Windows Firewall is enabled by default when the computer location is set to “private.” It is configured for NAT traversal using Teredo by default so that users in a private networking environment (for example, the home environment) can solicit help from other users who may also be behind NATs. The private profile includes the appropriate exceptions needed to allow communication with UPnP NAT devices. If there is a UPnP NAT in this environment, Remote Assistance will attempt to use the UPnP for NAT traversal. Offer RA via DCOM is not configured in this profile.

  • Public profile. The RA exception is disabled by default and no inbound RA traffic is permitted. Windows Firewall is configured this way by default to better protect users in a public networking environment (such as a coffee shop or airport terminal). When the RA exception is enabled, NAT traversal using Teredo is enabled. However, traffic to UPnP devices is not enabled and Offer RA via DCOM is not enabled.

  • Domain Profile. The RA exception when the computer is in a domain environment is geared towards the Offer RA scenario. This exception is disabled by default and is typically enabled via Group Policy. Teredo is not enabled in this profile because corporate networks typically have a corporate firewall that blocks Teredo UDP traffic. However, UPnP is enabled so that UPnP NATs can be communicated with.

Remote Assistance and the Secure Desktop

When a User consents to having a Helper share control of her computer during a Remote Assistance session, the User has the option of allowing the Helper to respond to UAC prompts (Figure 23-1). Typically, User Account Control (UAC) prompts appear on the Secure Desktop (which is not remoted) and consequently the Helper cannot see or respond to Secure Desktop prompts. The Secure Desktop mode is the same mode that a user sees when she logs on to her computer or presses the Secure Attention Sequence (SAS) keystroke (Ctrl+Alt+Delete). UAC elevation prompts are displayed on the Secure Desktop instead of the user’s normal desktop to protect the user from unknowingly allowing malware to run with elevated privileges on her computer. The user must provide consent to a UAC prompt to return to her normal desktop and continue working. This consent requires either clicking Continue (if the user is a local admin on her computer) or by entering local admin credentials (if she is a standard user on her computer).

It is important to understand that the Secure Desktop on the User’s computer is not remoted to the Helper’s computer. In other words, the Helper can only respond to UAC prompts on the User’s computer using the User’s own credentials. This means that if the User is a standard user on her computer while the Helper is a local administrator on the User’s computer, the Helper can only have administrative privileges on the User’s computer if the User can first supply those credentials.

Enforcing this limitation is essential to ensure the security of Windows Vista desktops. The reason behind this design decision is that if RA was architected to allow the Helper to remotely elevate the User’s privileges, the User would be able to terminate the RA session and thus steal local admin credentials from the Helper.

Remote Assistance Logging

Remote Assistance can generate a session log of RA-associated activity. Session logging is enabled by default and consists of time-stamped records that identify RA-related activities on each computer. Session logs only contain information about activities that specifically relate to RA functionality, such as who initiated the session, whether consent was given to a request for shared control, and so on.

Session logs do not contain information on actual tasks that the User or Helper performed during a session. For example, if the Helper is given Shared Control privileges, starts an Admin command prompt, and performs steps to reconfigure the TCP/IP configuration on the User’s computer during an RA session, the session logs will not contain a record of this action.

Session logs do include any chat activity performed during an RA session. The log generated during a session is also displayed within the chat window so that both the User and the Helper can see what is being logged during the session. Session logs also include any file transfer activity that occurs during the session, and also record when the session has been paused.

Purpose of RA Session Logging

Session logs for RA are mainly intended for enterprises that are required to maintain records of system and user activity for record-keeping purposes. They are not intended as a way to record every action performed by Help Desk personnel when troubleshooting problems with users’ computers. A typical environment in which session logging might be required would be in a banking environment, where a financial institution is required by law to maintain records of who accessed a computer and at what time.

Because the ACLs on these session logs grant the User full control over logs stored on her own computer, by default session logs are generated on both the User’s computer and Helper’s computer so that the Helper can protect and archive them from tampering. The logs created on each side of an RA session are similar but not identical. This is because session logs are generated from the perspective of the computer involved—whether the User’s computer or the Helper’s computer—and therefore complement each other instead of being identical.

In an enterprise environment, Group Policy can be used to enable or disable session logging. If session logging is not configured using Group Policy, both the User and Helper are free to disable session logging on their own computers.

Session Log Path and Naming Convention

Session logs are XML-formatted documents so that they can be easily integrated into other data sets—for example, by importing them into a database managed by Microsoft SQL Server 2005. All session logs are stored under each user’s Documents folder within the following path.

Users\user_name\Documents\Remote Assistance Logs

A unique session log file is created for each RA session on the computer. Log files stored within this folder are formatted using XML and are named using the convention YYYYMMDDHHMMSS.xml, where the time format is 24-hour. For example, a session log created at 3:45:20 p.m. on August 13, 2006, would be named 20060813154520.xml.

The XML content of a typical session log resembles the following.

<?xml version="1.0" ?>
<SESSION>
  <INVITATION_OPENED TIME="3:24 PM" DATE="Wednesday, August 09, 2006" EVENT="A Remote Assistance invitation has been opened." />
  <INCOMING_IP_ADDRESS TIME="3:26 PM" DATE="Wednesday, August 09, 2006">fe80::2856:e5b0:fc18:143b%10</INCOMING_IP_ADDRESS>
  <CONNECTION_ESTABLISHED TIME="3:26 PM" DATE="Wednesday, August 09, 2006" EVENT="A Remote Assistance connection has been established.">jdow</CONNECTION_ESTABLISHED>
  <EXPERT_REQUEST_CONTROL TIME="3:27 PM" DATE="Wednesday, August 09, 2006" EVENT="jdow has requested to share control of the computer." />
  <EXPERT_GRANTED_CONTROL TIME="3:27 PM" DATE="Wednesday, August 09, 2006" EVENT="jdow has been granted permission to share control of the computer." />
  <EXPERT_CONTROL_STARTED TIME="3:27 PM" DATE="Wednesday, August 09, 2006" EVENT="jdow is sharing control of the computer." />
  <EXPERT_CONTROL_ENDED TIME="3:27 PM" DATE="Wednesday, August 09, 2006" EVENT="jdow is not sharing control of the computer." />
  <CHAT_MESSAGE TIME="3:30 PM" DATE="Wednesday, August 09, 2006">jdow: test</CHAT_MESSAGE>
  <CHAT_MESSAGE TIME="3:30 PM" DATE="Wednesday, August 09, 2006">jchen: ok</CHAT_MESSAGE>
  <CONNECTION_ENDED TIME="3:30 PM" DATE="Wednesday, August 09, 2006" EVENT="The Remote Assistance connection has ended." />
  <INVITATION_CLOSED TIME="3:30 PM" DATE="Wednesday, August 09, 2006" EVENT="A Remote Assistance invitation has been closed." />
</SESSION>

Using Remote Assistance in the Enterprise

The main Remote Assistance scenario within a corporate networking environment is supporting desktop computers that are on the corporate network and joined to a domain. Users’ computers must be configured appropriately before they can be offered RA. This is done via Group Policy. Additionally, the Remote Assistance exception in the Windows Firewall must be enabled.

Because most corporate networks have a perimeter firewall blocking access from outside the internal network, supporting remote users who are connecting from outside the corporate network can be more difficult. However, most enterprises now use virtual private network (VPN) technologies to allow remote users to connect to their corporate networks over the Internet, and this kind of scenario generally poses no problem to RA functionality.

Note

Offer RA needs preconfiguration of the User’s computer via Group Policy. See “Managing Remote Assistance Using Group Policy” for more information.

Interoperability with Remote Assistance in Windows XP

Remote Assistance in Windows Vista is backward-compatible with Remote Assistance in Windows XP, with the following limitations:

  • Offer RA from Windows Vista to Windows XP is supported, but Offer RA from Windows XP to Windows Vista is not supported. This means that enterprises who want to implement Offer RA as a support solution for their Help Desk departments should ensure that computers used by support personnel who will help users running Windows Vista are themselves running Windows Vista (and not Windows XP).

  • NAT traversal using Teredo and IPv6 is supported on Windows Vista to Windows Vista RA only, and not on Windows Vista to Windows XP.

  • Voice support for RA in Windows XP is not supported by RA in Windows Vista, and any attempt by a User on a computer running Windows XP to use this feature during an RA session with a Helper on a Windows Vista computer will cause a notification message regarding this limitation to appear.

  • The MAILTO method of soliciting assistance that is supported by RA in Windows XP is not supported by RA in Windows Vista.

  • Windows Messenger (which shipped with Windows XP) does not ship with Windows Vista. Users of RA with Windows Messenger in Windows XP will need to migrate to an IM vendor that supports Windows Vista and Remote Assistance. Windows Live Messenger currently supports Windows XP, Windows Vista, and Remote Assistance.

  • Offer RA via Messenger is a new feature in Windows Vista and is not available in Windows XP.

Managing Remote Assistance Using Group Policy

In an enterprise environment, Remote Assistance can be managed by using Group Policy. The policy settings for Remote Assistance are all per-computer settings and are found in the following policy location:

Computer Configuration\Administrative Templates\System\Remote Assistance

When these policy settings are written to the registry on targeted computers, they are stored under the following registry key:

HKLM\SOFTWARE\Policies\Microsoft\WindowsNT\Terminal Services

Remote Assistance policy settings are summarized in the following table.

Group Policy Settings for Remote Assistance

Policy Description

Solicited Remote Assistance

Enabling this policy allows users of targeted computers to use Solicited RA to request assistance using e-mail, file transfer, or instant messaging. Disabling this policy prevents users from using Solicited RA. The default setting is Not Configured, which allows users to change their Remote Assistance settings using the Remote tab of the System CPL in Control Panel.

If the policy is Enabled, you can further configure whether Helpers can be prevented from sharing control of the User’s computer, the maximum ticket lifetime, and the method used for sending invitations my e-mail. (Windows Vista does not support the MAILTO method—select SMAPI instead if the targeted computers are running Windows Vista.) Ticket lifetime applies only to RA invitations sent by e-mail or file transfer. The default ticket lifetime when Group Policy is not being used is 6 hours.

If this policy is Enabled, you must also enable the Remote Assistance exception in Windows Firewall to allow Solicited RA to work.

In an unmanaged environment, this setting can also be configured using the Remote tab of the System CPL in Control Panel.

This policy is also supported on Windows XP Professional and Windows Server® 2003.

Offer Remote Assistance

Enabling this policy allows designated Helpers to use Offer RA to offer assistance to users of targeted computers. Disabling this policy or leaving it Not Configured prevents Offer RA from being used to offer assistance to users of targeted computers.

If the policy is Enabled, you can further configure whether Helpers can view or control the Users’ computers, and you must specify a list of Helpers who are allowed to Offer RA to the users of the targeted computers. Helpers can be either users or groups and must be specified in the form domain_name\user_name or domain_name\groupname.

If this policy is Enabled, you must also enable the Remote Assistance exception in Windows Firewall to allow Offer RA to work.

This policy is also supported on Windows XP Professional and Windows Server 2003. See the Explain tab of this policy setting for more details.

Allow Only Vista Or Later Connections

The default Windows Vista invitation file includes a Windows XP-specific node for backward compatibility. This node is not encrypted and allows Windows XP computers to connect to the Windows Vista computer that created the ticket. Enabling this policy causes all RA invitations generated by users of targeted computers to not include the Windows XP node, thereby providing an additional level of security and privacy. Disabling this policy or leaving it Not Configured leaves information such as IP address and port number unencrypted in RA invitations This policy setting only applies to RA invitations sent using e-mail or file transfer, and has no effect on using instant messaging to solicit assistance or on using Offer RA to offer assistance.

In an unmanaged environment, this setting can also be configured by clicking Advanced from the Remote tab of the System Properties dialog.

This policy is supported only on Windows Vista and later platforms.

Customize Warning Messages

Enabling this policy causes a specified warning to be displayed on targeted computers when a Helper wants to enter Screen Sharing State or Control Sharing State during an RA session. Disabling this policy or leaving it Not Configured causes the default warning to be displayed in each instance.

If the policy is Enabled, you can further specify the warning message to be displayed in each instance.

This policy is supported only on Windows Vista and later platforms.

Turn On Session Logging

Enabling this policy causes RA session activity to be logged on the targeted computers. For more information, see the section titled “Remote Assistance Logging.” Disabling this policy causes RA auditing to be disabled on the targeted computers. The default setting is Not Configured, in which case RA auditing is automatically turned on.

This policy is supported only on Windows Vista and later platforms.

Turn On Bandwidth Optimization

Enabling this policy causes the specified level of bandwidth optimization to be used to enhance the RA experience over low-bandwidth network connections . Disabling this policy or leaving it Not Configured allows the system defaults to be used.

If the policy is Enabled, you must specify the level of bandwidth optimization you want to use from the following options:

  • No Optimization

  • No Full Window Drag

  • Turn Off Background

  • Full Optimization (Use 8-Bit Color)

If No Optimization is selected, the User’s computer will use the Windows Basic theme with full background, and during a shared control session the Helper will be able to drag full windows across the User’s screen. Additional optimization turns off effects to allow a more responsive experience for the Helper.

This policy is supported only on Windows Vista and later platforms.
Note

In Windows XP, members of the Domain Admins group were implicitly granted Helper privileges even if they were not added to the Helpers list of the Offer Remote Assistance policy setting. This is no longer the case in Windows Vista, where the Domain Admins group must now be explicitly added to the Helpers list to grant them Helper privileges for Offer RA.

Configuring Remote Assistance in Unmanaged Environments

Users of unmanaged computers can enable and configure Remote Assistance using the Remote tab of the System CPL in Control Panel. Enabling or disabling Remote Assistance and configuring its settings this way requires local administrator credentials on the computer, so a UAC prompt will appear when the user tries to change this setting.

Note that settings changes made this way will affect all users on the system. The per-computer registry settings for Remote Assistance are found under the following key:

HKLM\SYSTEM\CurrentControlSet\Control\Remote Assistance

In managed environments, when the following Group Policy setting is Enabled, the Control Panel settings for configuring Remote Assistance become unavailable (are grayed out).

Computer Configuration\Administrative Templates\System\Remote Assistance\Solicited Remote Assistance

Note

Group Policy settings always prevail over locally configured settings when they overlap.

Additional Registry Settings for Configuring Remote Assistance

Additional behavior for Remote Assistance can be configured by modifying certain registry settings. Specifically, per-user registry settings for Remote Assistance are found under the following key:

HKCU\Software\Microsoft\Remote Assistance

These settings are changeable when in the Waiting To Connect mode or when in the connected mode from the Settings button.

Note

If Group Policy is used to manage Remote Assistance settings and any configured policy settings overlap these registry settings, the policy settings prevail.

Summary

Remote Assistance has been enhanced in Windows Vista to provide better performance, improved usability, NAT-traversal flexibility, and increased security. Best practices for implementing Remote Assistance in an enterprise environment include:

  • Use Group Policy to enable users of targeted computers in a domain or OU to receive offers of RA from Help Desk personnel.

  • Use Group Policy to enable the RA exception in the Windows Firewall.

  • Use Group Policy to deploy scripts to enable users to run the msra.exe executable if you want to customize how they launch RA sessions—for example, to upload an invitation to a network share monitored by support personnel.

  • If all of your support computers are running Windows Vista, use Group Policy to encrypt RA tickets to hide sensitive information such as users’ IP addresses and computer names.

  • If corporate policy requires RA records for auditing purposes, use Group Policy to enable RA logging on your company’s desktop computers and run scripts to periodically move both Helper and User RA logs to a safe storage.

  • To meet corporate privacy and security requirements, use Group Policy to customize the text message that users see before they allow the Helper view their screens or share control.


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 on the Windows Server® 2008 product DVD-ROM.

You can install the Remote Server Administration Tools pack on computers running the Windows Server 2008 operating system, and use the Remote Server Administration Tools pack to manage computers running either Windows Server 2008 or 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 that enables remote management of Windows Server 2008 and Windows Server 2003 from a computer running Windows Server 2008, 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, 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, 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.

Remote Server Administration Tools for roles

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) Tools

Active Directory Domain Services Tools includes Active Directory Users and Computers, Active Directory Domains and Trusts, Active Directory Sites and Services, and other snap-ins and command-line tools for remotely managing Active Directory Domain Services.

Active Directory Lightweight Directory Services (AD LDS) Tools

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, 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.

Network Policy and Access Services Tools

Network Policy and Access Services Tools includes the Health Registration Authority snap-in.

Print Services Tools

Print Services Tools includes the Print Management snap-in.

Terminal Services Tools

Terminal Services Tools includes the TS RemoteApp Manager, TS Gateway Manager, and TS Licensing Manager snap-ins.

Universal Description, Discovery, and Integration (UDDI) Services Tools

UDDI Services Tools includes the UDDI Services snap-in.

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

Remote Server Administration Tools feature | Description
BitLocker Drive Encryption Tools | BitLocker Drive Encryption Tools includes the manage-bde.wsf script.
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.

  • 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 Microsoft Windows Server® TechCenter (http://go.microsoft.com/fwlink/?LinkId=48541).


Removable Storage Manager Overview

About Removable Storage Manager

Removable Storage Manager (RSM) manages and catalogs removable media and operates automated removable media devices.

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


RPC over HTTP Proxy Overview

RPC over HTTP Proxy

RPC Over HTTP Proxy is a proxy that is used by objects that receive remote procedure calls (RPC) over Hypertext Transfer Protocol (HTTP). This proxy allows 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 on MSDN (http://go.microsoft.com/fwlink/?LinkId=93826)

  • Application Server in the Windows Server® 2008 Technical Library (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 functionality has been removed from Windows Server 2008?

To streamline and simplify Services for NFS, the following features were removed from this release:

  • Gateway for NFS

  • Server for PCNFS

  • All PCNFS components of Client for NFS

  • User Name Mapping

Note

User Name Mapping has changed—server functionality no longer exists, but client functionality is present. Services for NFS can still retrieve mappings from existing legacy User Name Mapping servers.

What new functionality is provided in Windows Server 2008?

Services for NFS includes the following improvements:

  • Active Directory Lookup. The Identity Management for UNIX Active Directory schema extension includes UNIX user identifier (UID) and group identifier (GID) fields. This enables Server for NFS and Client for NFS to look up Windows-to-UNIX user account mappings directly from Active Directory Domain Services. Identity Management for UNIX simplifies Windows-to-UNIX user account mapping management in Active Directory Domain Services.

  • 64-bit support. You can install Services for NFS components on all editions of Windows Server 2008, including 64-bit editions.

  • Enhanced server performance. Services for NFS includes a file filter driver, which significantly reduces common server file access latencies.

  • Unix special device support. Services for NFS supports UNIX special devices (mknod).

  • Enhanced UNIX support. Services for NFS supports the following versions of UNIX: Sun Microsystems Solaris version 9, Red Hat Linux version 9, IBM AIX version 5L 5.2, and Hewlett Packard HP-UX version 11i.


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.


Simple Network Management Protocol (SNMP) 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

  • Microsoft Windows Server 2003 family

The SNMP agent also allows management of the following services:

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

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

  • Windows XP or the Windows Server 2003 family and Windows 2000-based Internet Information Services

  • Microsoft 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 provide 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.


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.

  • 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.


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 your UNIX 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=67558), 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.

New features in this release

New features in Subsystem for UNIX-based Applications in this release 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=67558).

Installing Subsystem for UNIX-based Applications

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

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=67558).

On Windows Server 2008, 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 users can also install SUA by using the Server Manager command line. For more information about the Server Manager command line, see the Help in %windir%\rmt.chm.

On Windows Vista, you can install SUA by opening Control Panel, then Programs, then 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

Telnet Server is a feature included with Microsoft® Windows Server® 2008 and Windows Vista®.

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, you can install Telnet Server by opening Control Panel, then Programs, 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

Telnet Client is a feature included with Microsoft® Windows Server® 2008 and Windows Vista®.

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, you can install Telnet Client by opening Control Panel, then Programs, 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.

  • UDDI 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.


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 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.0 application or IIS 7.0.

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


Windows PowerShell Overview

Windows PowerShell is a new task-based command-line shell and scripting language designed especially for system administration. Built on the .NET Framework, Windows PowerShell helps IT professionals and power users control and automate the administration of the Windows operating system and applications that run on Windows.

Built-in Windows PowerShell commands, called cmdlets, let you manage the computers in your enterprise from the command line. Windows PowerShell providers let you access data stores, such as the registry and certificate store, as easily as you access the file system. In addition, Windows PowerShell has a rich expression parser and a fully developed scripting language.

Windows PowerShell 1.0 includes the following features:

  • 129 standard cmdlets for performing common system administration tasks, such as managing the registry, services, processes, and event logs, and using Windows Management Instrumentation.

  • A task-based scripting language and support for existing scripts and command-line tools.

  • Consistent design. Because Windows PowerShell cmdlets and system data stores use common syntax and naming conventions, data can be shared easily and the output from one cmdlet can be used as the input to another cmdlet without reformatting or manipulation.

  • Simplified, command-based navigation of the operating system, which lets users navigate the registry and other data stores by using the same techniques that they use to navigate the file system.

  • Powerful object manipulation capabilities. Objects can be directly manipulated or sent to other tools or databases.

  • Extensible interface. Independent software vendors and enterprise developers can build custom tools and utilities to administer their software.

Learning Windows PowerShell

To begin learning Windows PowerShell, start with the following resources, which are included in the tool:

  • Getting Started. A brief introduction and tutorial. To open it, click Start, All Programs, Windows PowerShell 1.0, and then click Getting Started.

  • User Guide. A detailed introduction, including real-world scripts and scenarios to get you started.

  • Get-Help cmdlet. A Windows PowerShell cmdlet that you can use to quickly learn about the cmdlets and providers on your system. To begin, start Windows PowerShell, and at the prompt, type:

    get-help
    To learn about the Windows PowerShell scripting language and other concepts, read the "about" topics. To see a list of "about" topics, type:

    get-help about

Other Resources

In addition to the Help available at the command line, the following resources provide more information.

Windows PowerShell Team Blog. The best resource for learning from and collaborating with other Windows PowerShell users. Read the Windows PowerShell Team blog, and then join the Windows PowerShell User Forum (microsoft.public.windows.powershell). Use Windows Live Search to find other Windows PowerShell blogs and resources. Then, as you develop your expertise, please freely contribute your ideas.

Windows PowerShell SDK. Provides reference content used to develop cmdlets, providers, and hosting applications.

Windows PowerShell Programmer's Guide. Provides tutorials for creating cmdlets, providers, and hosting applications. Also contains information about fundamental Windows PowerShell concepts.


Windows Server Backup Overview

The Windows Server Backup feature in Windows Server 2008 consists of a Microsoft Management Console (MMC) snap-in and command-line tools that provide a complete solution for your day-to-day backup and recovery needs. You can use four wizards to guide you through running backups and recoveries. You can use Windows Server Backup to back up a full server (all volumes), selected volumes, or the system state. 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 system recovery, which will restore your complete system onto the new hard disk, by using a full server backup and the Windows Recovery Environment.

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 owners to IT professionals in large enterprises. However, the design makes it especially well-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.

In Windows Server 2008, the firewall has been enabled by default. 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.

Also, if you are a current user of the previous backup feature (Ntbackup.exe) that shipped in earlier versions of Windows, 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 will need a separate, dedicated disk for running scheduled backups.

  • Only NTFS-formatted volumes on a locally-attached disk can be backed up.

  • You can no longer back up to 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, DVDs, and 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 includes the following improvements:

  • Faster backup technology. Windows Server Backup uses Volume Shadow Copy Service (VSS) and block-level backup technology to back up and recover your operating system, files and folders, and volumes. After the first full backup is created, you can configure Windows Server Backup to automatically run incremental backups by saving only the data that has changed since the last backup. Even if you choose to always perform full backups, your backup will take less time than it did in earlier versions of Windows.

  • Simplified restoration. You can restore items by choosing a backup and then selecting specific items from that backup to restore. You can recover specific files from a folder or all the contents of a folder. In addition, previously, you needed to manually restore from multiple backups if the item was stored on an incremental backup. But this is no longer true—you can now choose the date of the backup version for the item you want to restore.

  • Simplified recovery of your operating system. Windows Server Backup works with new Windows recovery tools to make it easier for you to recover your operating system. You can recover to the same server—or if the hardware fails, you can recover to a separate server with similar hardware that has no operating system.

  • Ability to recover applications. Windows Server Backup uses VSS functionality that is built into applications like Microsoft SQL Server™ to protect application data.

  • Improved scheduling. Windows Server Backup includes a wizard that guides you through the process of creating daily backups. System volumes are automatically included in all scheduled backups so that you are protected against disasters.

  • Offsite removal of backups for disaster protection. You can save backups to multiple disks in a rotation, which enables you to move disks from an offsite location. Add each disk as a scheduled backup location and, if the first disk is moved offsite, Windows Server Backup will automatically save backups to the next disk in the rotation.

  • Remote administration. Windows Server Backup uses an MMC snap-in to give you a familiar and consistent experience for managing your backups. After you install the snap-in, you can access this tool through Server Manager or by adding the snap-in to a new or existing MMC console. Then, you can manage backups on other servers by clicking the Action menu in the snap-in, and then clicking Connect to Another Computer.

  • Automatic disk usage management. After you configure a disk for a scheduled backup, Windows Server Backup automatically manages the disk usage—you do not need to be concerned about running out of disk space after repeated backups. Windows Server Backup will automatically reuse the space of older backups when creating new backups. The management tool displays the backups that are available and the disk usage information. This can help you plan for provisioning additional storage to meet your recovery time objectives.

  • Extensive command-line support. Windows Server Backup includes the Wbadmin command and documentation, which enable you to perform all of 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=93131). You can also automate backup activities through scripting.

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

  • Support for optical media drives and removable media. You can manually back up volumes directly to optical media drives, such as DVD drives, and also to removable media. This offers a solution if you want to create backups that can easily be moved offsite on a one-time basis. This version of Windows Server Backup retains support for manual backups to shared folders and hard disks.

Supported operating systems

Windows Server Backup is available in all editions of Windows Server 2008 (both 32-bit and 64-bit versions). However, the Windows Server Backup snap-in is not available for the Server Core installation option of Windows Server 2008. To run backups for computers with a Server Core installation, you need to either use the command line or manage backups remotely from another computer. In addition, Windows PowerShell is not available for the Server Core installation option, so the cmdlets for Windows Server Backup are also not available on this type of installation.

Additional resources

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


Windows System Resource Manager Overview

With Windows System Resource Manager for the Windows Server® 2008 operating system, you can manage server processor and memory usage with standard or custom resource policies. Managing your resources can help ensure that all of 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%. 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, 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.

Benefits of resource management

Because Windows Server 2008 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 four 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% processor utilization, Windows System Resource Manager will limit each process to using 10% 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% 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 terminal 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.

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 process the 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 technical details about Windows System Resource Manager, see http://go.microsoft.com/fwlink/?LinkId=93726.


Wireless LAN Service Overview

The Wireless LAN service is a feature in this version of Windows Server 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 is a feature in this version of Windows Server that 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 on client computers running this version of Windows Server or Windows Vista:

  • The New Features Wizard

    Configure Wireless LAN Service in the New Features Wizard in this version of Windows Server.

  • Wireless Network (IEEE 802.11) Policy

    Enable the Windows Vista Wireless Network (IEEE 802.11) Policy setting, Use the 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 to configure wireless network settings for clients.

    This setting enables administrators to specify that the WLAN AutoConfig Service is used to configure and connect wireless clients running Windows Vista or this version of Windows Server to the wireless network.

  • Netsh WLAN set autoconfig

    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, the modify the properties of the service to meet your requirements.

Changes in the wireless auto configuration

This version of Windows Server and Windows Vista® include the following changes to wireless auto configuration:
Changes in the wireless auto configuration service name

Windows Server 2003 and Windows XP | This version of Windows Server and Windows Vista
Wireless auto configuration service name: Wireless Zero Configuration service (WZCSVC) | Wireless auto configuration service name: WLAN AutoConfig service (XXX)

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 This version of Windows Server 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 this version of Windows Server and in 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 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 This version of Windows Server 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 this version of Windows Server" or 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, computers running Windows Vista or this version of Windows Server 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).