Overview of RemoteApp

Applies To: Windows Server 2008 R2

What is RemoteApp?

RemoteApp enables you to make programs that are accessed remotely through Remote Desktop Services appear as if they are running on the end user's local computer. These programs are referred to as RemoteApp programs. Instead of being presented to the user in the desktop of the Remote Desktop Session Host (RD Session Host) server, the RemoteApp program is integrated with the client's desktop. The RemoteApp program runs in its own resizable window, can be dragged between multiple monitors, and has its own entry in the taskbar. If a user is running more than one RemoteApp program on the same RD Session Host server, the RemoteApp program will share the same Remote Desktop Services session.
Users can access RemoteApp programs several ways. They can:

1. Access a link to the program through RemoteApp and Desktop Connection by using Remote Desktop Web Access (RD Web Access).
2. Double-click a Remote Desktop Protocol (.rdp) file that has been created and distributed by their administrator.
3. Double-click a program icon on their desktop or Start menu that has been created and distributed by their administrator with a Windows Installer (.msi) package.
4. Double-click a file where the file name extension is associated with a RemoteApp program. This can be configured by their administrator with a Windows Installer package.

Users can access RemoteApp and Desktop Connection through the Start menu on a computer that is running Windows® 7 or through the RD Web Access Web site. For more information about making RemoteApp programs available through RemoteApp and Desktop Connection, see the Remote Desktop Connection Manager Help in Windows Server 2008 R2. For more information about RemoteApp and Desktop Connection, see the Remote Desktop Services page on the Windows Server 2008 R2 TechCenter (http://go.microsoft.com/fwlink/?LinkId=143108).
The .rdp files and Windows Installer packages contain the settings that are needed to run RemoteApp programs. After opening a RemoteApp program on their local computer, the user can interact with the program that is running on the RD Session Host server as if it were running locally.

Why use RemoteApp?

RemoteApp can reduce complexity and reduce administrative overhead in many situations, including the following:

• Branch offices, where there may be limited local IT support and limited network bandwidth.
• Situations where users need to access programs remotely.
• Deployment of line-of-business (LOB) programs, especially custom LOB programs.
• Environments, such as "hot desk" or "hoteling" workspaces, where users do not have assigned computers.
• Deployment of multiple versions of a program, particularly if installing multiple versions locally would cause conflicts.

For more information about RemoteApp, see the Remote Desktop Services page on the Windows Server 2008 R2 TechCenter (http://go.microsoft.com/fwlink/?LinkId=140439).

Additional references

• Checklist: Configure RemoteApp
  
  
• Configuring the RD Session Host Server to Host RemoteApp Programs
  
  
• Configuring RemoteApp Programs
  
  
• Checklist: Make RemoteApp Programs Available from the Internet
  
  
• Remote Desktop Web Access (RD Web Access)

AD DS Auditing Step-by-Step Guide

Applies To: Windows Server 2008, Windows Server 2008 R2

This guide includes a description of the new Active Directory® Domain Services (AD DS) auditing feature in Windows Server® 2008. It also provides procedures to implement this new feature.

Note
This new auditing feature also applies to Active Directory Lightweight Directory Services (AD LDS). However, this guide refers only to AD DS.

What’s new in AD DS auditing?

In Windows Server 2008 you can now set up AD DS auditing with a new audit subcategory to log old and new values when changes are made to objects and their attributes.
In Microsoft® Windows® 2000 Server and Windows Server 2003, Active Directory audit logs can show you who made changes to what object attributes, but the events do not display the old and new values. For example, the audit log can show that Joe modified his favorite drink attribute in the directory, but it cannot show his previous favorite drinks or what the attribute was after he changed it. With the new auditing feature, you can log events that show old and new values; for example, you can show that Joe's favorite drink changed from single latte to triple-shot latte.

Auditing changes to objects in AD DS

In Windows 2000 Server and Windows Server 2003, there was one audit policy, Audit directory service access, that controlled whether auditing for directory service events was enabled or disabled. In Windows Server 2008, this policy is divided into four subcategories:

• Directory Service Access
  
  
• Directory Service Changes
  
  
• Directory Service Replication
  
  
• Detailed Directory Service Replication
  
  

The ability to audit changes to objects in AD DS is enabled with the new audit policy subcategory Directory Service Changes. This guide provides instructions for implementing this audit policy subcategory.
The types of changes that you can audit include a user (or any security principal) creating, modifying, moving, or undeleting an object. The new audit policy subcategory adds the following capabilities to auditing in AD DS:

• When a successful modify operation is performed on an attribute, AD DS logs the previous and current values of the attribute. If the attribute has more than one value, only the values that change as a result of the modify operation are logged.
  
• If a new object is created, values of the attributes that are populated at the time of creation are logged. If the user adds attributes during the create operation, those new attribute values are logged. In most cases, AD DS assigns default values to attributes (such as samAccountName). The values of such system attributes are not logged.
  
• If an object is moved, the previous and new location (distinguished name) is logged for moves within the domain. When an object is moved to a different domain, a create event is generated on the domain controller in the target domain.
  
• If an object is undeleted, the location where the object is moved to is logged. In addition, if the user adds, modifies, or deletes attributes while performing an undelete operation, the values of those attributes are logged.
  
  

  Note
  When you undelete an object, you clear the isDeleted attribute and specify a new location for the object by setting the distinguishedName attribute, in a single LDAP modify operation. For more information, see Microsoft Knowledge Base article 84001 (http://go.microsoft.com/fwlink/?LinkId=89248).

• The events that are generated by these actions appear in the Security log in Event Viewer.
  

Implementing AD DS change auditing

In Windows Server 2008, you implement the new auditing feature by using the following controls:

• Global audit policy
  
• System access control list (SACL)
  
• Schema
  

Global audit policy

Enabling the global audit policy, Audit directory service access, enables all directory service policy subcategories. You can set this global audit policy in the Default Domain Controllers Group Policy (under Security Settings\Local Policies\Audit Policy). In Windows Server 2008, this global audit policy is not enabled by default. Although the subcategory Directory Service Access is enabled for success events by default, the other subcategories are not enabled by default.
In Windows 2000 Server and Windows Server 2003, the Audit directory service access policy was the only auditing control available for Active Directory. The events generated by this control did not show the old and new values of any modifications. This setting generated audit events in the Security log with the ID number 566. In Windows Server 2008, the audit policy subcategory Directory Service Access still generates the same events, but the event ID has been changed to 4662.

Note
The new audit policy subcategory Directory Service Access functions similarly to the Audit directory service access policy in Windows 2000 Server and Windows Server 2003, which was enabled for Success events by default. No other new audit policy subcategories are enabled by default so that administrators are not overburdened by additional events that they are not prepared for.

With the new audit policy subcategory Directory Service Changes, successful changes to the directory are logged along with the previous and current values. There are new event ID numbers associated with Directory Service Changes. Settings for both Directory Service Access and Directory Service Changes are stored in the Local Security Authority (LSA) database. They can be queried by using new LSA application programming interfaces (APIs).
The two audit subcategories are independent of each other. You can disable Directory Service Access and still be able to see change events that are generated if the subcategory Directory Service Changes is enabled. Similarly, if you disable Directory Service Changes and enable Directory Service Access, you can see Security log events with the ID number 4662.
You can use the command-line tool Auditpol.exe to view or set audit policy subcategories. There is no Windows interface tool available in Windows Server 2008 to view or set audit policy subcategories.

SACL

The SACL on the object is still the ultimate authority in determining whether an access check must be audited or not. The SACL is the part of an object's security descriptor that specifies which operations are to be audited for a security principal.
The content of the SACL is controlled by security administrators for the local system. Security administrators are users who have been assigned the Manage Auditing and Security Log (SeSecurityPrivilege) privilege. By default, this privilege is assigned to the built-in Administrators group.
If there is no access control entry (ACE) in the SACL requiring attribute modifications to be logged, even if the Directory Service Changes subcategory is enabled, no change auditing events are logged. For example, if there is no ACE in a SACL requiring Write Property access on the telephone number attribute of a user object to be audited, no auditing events are generated when the telephone number attribute is modified, even if the subcategory Directory Service Changes is enabled.

Schema

To avoid the possibility of an excessive number of events being generated, there is an additional control in the schema that you can use to create exceptions to what is audited.
For example, if you want to see what values have changed as a result of all but a few attribute modifications on a user object, you can set a flag in the schema for the attributes that you do not want audited. The searchFlags property of each attribute defines behavior such as whether the attribute is indexed or replicated to the global catalog. The searchFlags property has seven currently-defined bits.
If bit 8 (zero-based indexing, value 256) is set for an attribute, AD DS will not log change events when modifications are made to the attribute. This applies to all objects that contain that attribute.

Example modify operation and log entry

The following table shows an example of how events are logged when a user modifies a group object by adding values to two attributes (description and member) and the global audit policy Audit directory service access has been enabled. In this example, you see both events 4662 and 5136 because both subcategories Directory Service Access and Directory Service Changes are enabled. However, you do not see an event 5136 for the Description field because the searchFlag attribute for the property is set to disable auditing changes.

 

SACL	User action	Audit policy settings	Audit events logged
Object: CN=GroupX, CN=Users, ACE in SACL: {WP; AU}	Object modified: CN=GroupX, CN=Users, Attribute modified: Member Operation: Add Value: User1 Attribute modified: Description Operation: Add Value: Group of users with role 'X'	Subcategory: Directory Service Access ON Subcategory: Directory Service Changes ON Description attribute in schema: search flag bit 8 set to disable change auditing	Event ID: 4662 Object: CN=GroupX, CN=Users, Permission: Write Property Attributes: Member; Description Event ID: 5136 Object: CN=Group X, CN=Users, Operation: Add Attribute: Member Value: User1

Who should use this new feature?

Domain Admins who set up the required objects that they want to audit should use this feature. In general, permissions to modify SACLs and view the Security log are given only to Administrators, including Domain Admins, Built-in Administrators, and Enterprise Admins.

Benefits of auditing changes in AD DS

If you can identify how object attributes have changed, the event logs are more useful as a tracking mechanism for changes that occur over the lifetime of an object.

How to set up AD DS auditing

This section provides step-by-step procedures for enabling auditing of changes to objects in AD DS. This process consists of two primary steps:

• Enabling the global audit policy in Group Policy
  
• Setting up auditing in object SACLs using the Active Directory Users and Computers snap-in.
  

This section also includes examples of Security log entries that appear when you create, modify, or move a user object and Directory Service Changes is enabled.

Prerequisites

• User: To perform this set of procedures, you should be familiar with editing Group Policy, using the Active Directory Users and Computers snap-in, AD DS auditing, and event logs.
  
• Computer: To set up auditing for changes to objects in AD DS, you must have Windows Server 2008 with the AD DS role installed on your computer.
  

Steps to set up auditing

This section includes procedures for each of the primary steps for enabling change auditing:

• Step 1: Enable audit policy.
  
• Step 2: Set up auditing in object SACLs by using Active Directory Users and Computers.
  

Step 1: Enable audit policy.

This step includes procedures to enable change auditing with either the Windows interface or a command line:

• By using Group Policy Management, you can turn on the global audit policy, Audit directory service access, which enables all the subcategories for AD DS auditing. If you need to install Group Policy Management, click Add Features in Server Manager. Select Group Policy Management and then click Install.
  
• By using the Auditpol command-line tool, you can enable individual subcategories.
  

To enable the global audit policy using the Windows interface

1. Click Start, point to Administrative Tools, and then Group Policy Management.
   
2. In the console tree, double-click the name of the forest, double-click Domains, double-click the name of your domain, double-click Domain Controllers, right-click Default Domain Controllers Policy, and then click Edit.
   
3. Under Computer Configuration, double-click Policies, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then click Audit Policy.
   
4. In the details pane, right-click Audit directory service access, and then click Properties.
   
5. Select the Define these policy settings check box.
   
6. Under Audit these attempts, select the Success, check box, and then click OK.
   

To enable the change auditing policy using a command line

1. Click Start, right-click Command Prompt, and then click Run as administrator.
   
2. Type the following command, and then press ENTER:
   auditpol /set /subcategory:"directory service changes" /success:enable
   

Step 2: Set up auditing in object SACLs.

The following procedure presents an example of just one of many different types of SACLs that you can set based on the operations that you want to audit.

To set up auditing in object SACLs

1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
   
2. Right-click the organizational unit (OU) (or any object) for which you want to enable auditing, and then click Properties.
   
3. Click the Security tab, click Advanced, and then click the Auditing tab.
   
4. Click Add, and under Enter the object name to select, type Authenticated Users (or any other security principal), and then click OK.
   
5. In Apply onto, click Descendant User objects (or any other objects).
   
6. Under Access, select the Successful check box for Write all properties.
   
7. Click OK until you exit the property sheet for the OU or other object.
   

Example audit events

This section presents examples of the new events that appear in the Security event log when you create, modify, or move a user object and Directory Service Changes is enabled.

Create a user object

If you create a new user, you see the Security event in the following figure.

Modify a user object

When you change an attribute for a user object, you see the event in the following figure.

Move a user object

If you move a user object, you see the event in the following figure.

Summary of new AD DS auditing events

The following table describes the events for each of the operations that are audited and appear in the Security event log. The table columns provide the following information:

• Operation: Describes the AD DS operation that has the potential of generating a change audit event.
  
• Event ID: The ID that each of the new events will have in the Security event log.
  
• Event description: A brief description of the parameters that are logged for the particular event.
  
• ACE in SACL that triggers event: The type of ACE that must be present in the SACL for the particular event to be generated. This column also describes which object should hold the ACE.
  

 

Operation	Event ID	Event description	ACE in SACL that triggers event
Modify	5136	: Add/Delete For existing objects: For new objects: For reanimated objects:	ACE {Write Property; or or blank; Trustee} For existing objects: ACE should be in the SACL of the object. For new objects: ACE should be in the SACL of the new object. The new object Security Descriptor (including the SACL) is a sum of explicitly assigned ACEs + ACEs inherited from parent + default ACEs in the schema definition of the object. For reanimated objects: ACE should be in the SACL of the reanimated object. The Security Descriptor (including the SACL) of a reanimated object is a sum of the SD that persisted when the object was deleted + ACEs inherited from the new parent.
Create	5137		{Create Child; ACE should be on parent object
Undelete	5138		{Create Child; ACE should be on target parent object (not source)
Move	5139		{Create Child; ACE should be on target parent object (not source)
Delete	5141	A directory service object was deleted. Security ID:\ Tree delete: Yes or No	{Delete (sometimes known as Delete Self); ACE should be on the source object {Delete Child; ACE should be on the parent object {Delete Tree; ACE should be on the root object of the tree deletion. A Delete Tree ACE on a root object does not ensure that every object included in the tree deletion will have its deletion audited. The deletion is audited only if the Delete self ACE is also on the SACL of object that is being deleted as part of the tree deletion.

Summary of attribute syntaxes

Because change audit events log old and new values, different values may have different syntaxes. The following table shows directory service attribute syntaxes and how they are represented in the Security event log.
String values have a limit on the number of bytes that will be logged in the event log. This limit prevents logs from being overloaded with large string values that could slow down the system.
Registry setting information is as follows:

• Location: HKLM\System\CurrentControlSet\Services\NTDS\Parameters that can be configured by the administrator to control the maximum limit for strings
  
• Setting name: MaximumStringBytesToAudit
  
• Type: REG_DWORD
  
• Values
  
  
  • Default registry value: 1000
    
  • Minimum registry value: 0
    
  • Maximum registry value: 64000
    

Binary values are stripped off completely and replaced with the term (localized to the system language). Therefore, if you have an attribute called JpegPhoto and you change the photograph in this attribute, the change is logged, but the old and new value that is logged does not show the old and new photograph. Instead, it shows the term .

 

Syntax	Attribute syntax object identifier	String limit	Example	Notes
Distinguished Name (DN)	2.5.5.1	-	CN=Users, DC=ntdev, DC=com
Object Id	2.5.5.2	-	5.77.3.7
String (Case Sensitive)	2.5.5.3	Yes	Hello World
String (Case Insensitive)	2.5.5.4	Yes	Hello World
String (Print Case) String (IA5)	2.5.5.5	Yes	Hello World
String (Numeric)	2.5.5.6	Yes	12345
DN-Binary OR Name	2.5.5.7	-	B:32:3F67…:CN=User, DC=ntdev, DC=com	Will be represented as: B:32::CN=User, DC=ntdev, DC=com
Boolean	2.5.5.8	-	TRUE
Integer Enumeration Enumeration (Delivery-Mechanism) Enumeration (Export-Information-Level) Enumeration (Preferred-Delivery-Method)	2.5.5.9	-	588
Octet String Object (Replica Link)	2.5.5.10	-	x5a x74 x03 …	Will be represented as:
Time (Generalized)	2.5.5.11 (OM ID =24)	-	20010928060000.0Z	YYYYMMDD HHMMSS.0Z YYYYMMDD HHMMSS.0 [+/-]HHMM
Time (UTC)	2.5.5.11 (OM ID =23)	-	910131145503Z	YYMMDDHH MMSSZ YYMMDDHH MMSS[+/-]HHMM
Unicode String	2.5.5.12	Yes	Hello World
Presentation-Address	2.5.5.13	Yes	Hello World
DN-String Access-Point	2.5.5.14	Yes*	S:32:some string:CN=Users, DC=ntdev, DC=com	*Limit applies to the string portion, not the DN portion
NT Security Descriptor	2.5.5.15	-	O:AOG:DAD:(A;;RPWPCCDCLCSWRCWDWOGA;;;S-1-0-0)	Expressed in SDDL
Large Integer Interval	2.5.5.16	-	75859769
SID	2.5.5.17	-	S-1-….	SID string format

Additional resources

The following resources can help you resolve problems that you might encounter while using auditing in AD DS:

• For more information about using Group Policy to configure detailed security auditing settings, see article 921469 (http://go.microsoft.com/fwlink/?LinkId=186143) in the Microsoft Knowledge Base.
  
• For community-based support, see the Directory Services forum on TechNet (http://go.microsoft.com/fwlink/?LinkID=166141). 

Create an IIS Manager User Account (IIS 7)

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

Add an IIS Manager user account in IIS Manager when you want to allow a user to connect to a site or an application on your server, but you do not want to create a Windows user account or add the user to a Windows group. IIS Manager user credentials consist of a user name and password that are created in IIS Manager and are used exclusively for IIS Manager to access the IIS configuration files.
After you create an IIS Manager user account, you can allow the user to connect to sites and applications. The user can then configure delegated features in those sites and applications.

Prerequisites

For information about the levels at which you can perform this procedure, and the modules, handlers, and permissions that are required to perform this procedure, see IIS Manager Users Feature Requirements (IIS 7).
Exceptions to feature requirements

• None.

To add an IIS Manager user

1. Open IIS Manager. For information about opening IIS Manager, see Open IIS Manager (IIS 7).
   
2. In the Connections pane, click the server node.
   
3. In Features View, double-click IIS Manager Users.
   
4. On the IIS Manager Users page, in the Actions pane, click Add User.
   
5. In the Add User dialog box, in the User name box, type a user name.
   
6. In the Password and Confirm password boxes, type a password.
   
7. Click OK.
   

See Also

Concepts

Configuring IIS Manager Users (IIS 7)
Configuring Permissions for IIS Manager Users and Windows Users (IIS 7)
Configuring Delegation for a Site or an Application in IIS 7

Configuring IIS Manager Users (IIS 7)

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

Create an IIS Manager user account when you want to allow a non-Windows user to configure delegated features in a site or an application in IIS Manager. After you create the IIS Manager user account, you can allow the user to connect to sites and applications in which you want them to manage delegated features.

Prerequisites

For information about the levels at which you can perform these procedures, and the modules, handlers, and permissions that are required for these procedures, see IIS Manager Users Feature Requirements (IIS 7).

Procedures

This task includes the following procedures:
View a List of IIS Manager User Accounts (IIS 7)
Create an IIS Manager User Account (IIS 7)
Change the Password for an IIS Manager User Account (IIS 7)
Remove an IIS Manager User Account (IIS 7)
Disable an IIS Manager User Account (IIS 7)

See Also

Concepts

Configuring Permissions for IIS Manager Users and Windows Users (IIS 7)

Configure the Web Server to Redirect Requests to an Exact Destination (IIS 7)

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

Configure the redirection destination to be an exact destination when you want to change the default redirection behavior. When you configure the destination to be an exact destination, all incoming requests are redirected to the exact destination instead of the relative destination. This is useful when you want all requests to be redirected to the same Web page, such as when a site is down for maintenance or when it is undergoing construction.

Note
You must first enable redirection and configure the redirection destination. For more information about how to enable redirection and configure the destination, see Configure the Web Server to Redirect Requests to a Relative Destination (IIS 7).

Prerequisites

For information about the levels at which you can perform this procedure, and the modules, handlers, and permissions that are required to perform this procedure, see HTTP Redirection Feature Requirements (IIS 7).
Exceptions to feature requirements

• None
  

To enable redirection

You can perform this procedure by using the user interface (UI), by running Appcmd.exe commands in a command-line window, by editing the configuration files directly, or by writing WMI scripts.

User Interface

To use the UI

1. Open IIS Manager and navigate to the level you want to manage. For information about opening IIS Manager, see Open IIS Manager (IIS 7). For information about navigating to locations in the UI based on your IIS administrative role, see Navigation in IIS Manager (IIS 7).
   
2. In Features View, double-click HTTP Redirect.
   
3. On the HTTP Redirect page, under Redirect Behavior, select Redirect all requests to exact destination (instead of relative to destination).
   
4. In the Actions pane, click Apply.
   

Command Line

To configure the redirection destination to be an exact destination, use the following syntax:
appcmd set config /section:httpRedirect /exactDestination:true | false
By default, this attribute is false, but you can specify true for the exactDestination attribute. To do this, type the following at the command prompt, and then press ENTER:
appcmd set config /section:httpRedirect /exactDestination:true
For more information about Appcmd.exe, see Appcmd.exe (IIS 7).

Configuration

The procedure in this topic affects the following configuration elements:
attribute of the element

WMI

Use the following WMI classes, methods, or properties to perform this procedure:

• HttpRedirectSection.ExactDestination property
  

For more information about WMI and IIS, see Windows Management Instrumentation (WMI) in IIS 7. For more information about the classes, methods, or properties associated with this procedure, see the IIS WMI Provider Reference on the MSDN site.

See Also

Concepts

Configuring HTTP Redirection in IIS 7

How Online Responders Work

Applies To: Windows Server 2008 R2

Most applications that depend on X.509 certificates need to validate the status of the certificates used when performing authentication, signing, or encryption operations. This certificate validity and revocation check is performed on all certificates in a certificate chain, up to the root certificate. If the root certificate, or any certificate in the chain, is invalid, then the certificates below the invalid certificate in the chain are also invalid.
The validation includes the following:

• Each certificate's signature is valid.
  
• The current date and time are within each certificate's validity period.
  
• No certificate is corrupt or malformed.
  

In addition, each certificate in the certificate chain is checked for its revocation status. Revocation checking can be performed by using either a certificate revocation list (CRL) or Online Certificate Status Protocol (OCSP) response.

What is OCSP?

The Microsoft Online Responder implements the OCSP protocol, which allows a recipient of a certificate to submit a certificate status request to an OCSP responder by using the Hypertext Transfer Protocol (HTTP). This OCSP responder returns a definitive, digitally signed response indicating the certificate status. The amount of data retrieved per request is constant regardless of the number of revoked certificates in the CA.
For more information, see RFC 2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP" (http://go.microsoft.com/fwlink/?LinkID=71068).

Online Responder

The Microsoft implementation of OCSP—the Online Responder—is divided into client and server components. The client component is built into the CryptoAPI 2.0 library, while the server component is introduced as a new service provided by the Active Directory Certificate Services (AD CS) server role. The following process describes how the client and server components interact:

1. When an application attempts to verify a certificate that specifies locations to OCSP responders, the client component first searches local memory and disk caches to find a cached OCSP response that contains current revocation data.
   
2. If an acceptable cached response is not found, a request is sent to an Online Responder by using the HTTP protocol.
   
3. The Online Responder Web proxy decodes and verifies the request. If the request is valid, the Web proxy cache is checked for the revocation information needed to fill the request. If current information is not available in the cache, the request is forwarded to the Online Responder service.
   
4. The Online Responder service takes the request and checks a local CRL, if available, and a cached copy of the most recent CRL issued by the CA.
   
5. If the certificate does not appear on the local or cached revocation lists, the revocation provider obtains an updated CA CRL, if available, from the locations listed in the revocation configuration to check the status of the certificate. The provider, in turn, returns the status of the certificate to the Online Responder service.
   
6. The Web proxy then encodes and sends the response back to the client to notify the client that the certificate is valid. It also caches a copy of the response for a limited time in case there are additional status requests about this certificate.
   

Additional references

• What Is an Online Responder?
  
  
• Components of an Online Responder

Configure Desktop Composition on an RD Session Host Server

Desktop composition provides the user interface elements of Windows Aero, such as translucent windows, for remote desktop sessions. By default, desktop composition is not allowed when connecting to a computer running Windows Server 2008 R2.

Important
Because Windows Aero requires additional system and bandwidth resources, allowing desktop composition for remote desktop sessions can reduce connection performance, particularly over slow links, and increase the load on the Remote Desktop Session Host (RD Session Host) server.

Desktop composition is not available for RemoteApp sessions. In addition, the client computer must have the necessary hardware to support Windows Aero features.

Manually configuring desktop composition

To manually configure desktop composition on an RD Session Host server, you need to do the following:

• Install the Desktop Experience feature.
  
• Start the Themes service.
  
• Enable the Allow desktop composition for remote desktop sessions Group Policy setting.
  
• Set the maximum color depth to 32 bits per pixel.
  

Install the Desktop Experience feature

For information about installing Desktop Experience, see Install Desktop Experience on an RD Session Host Server.

Start the Themes service

Use the following procedure to start the Themes service on the RD Session Host server.
Membership in the local Administrators group, or equivalent, on the RD Session Host server that you plan to configure, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
To start the Themes service

1. On the RD Session Host server, open the Services snap-in. To open the Services snap-in, click Start, point to Administrative Tools, and then click Services.
   
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
   
3. In the Services pane, right-click Themes, and then click Properties.
   
4. On the General tab, in the Startup type box, select Automatic, and then click Apply.
   
5. Under Service status, click Start.
   
6. Click OK to close the Themes Properties dialog box.
   
7. Confirm that the Status column for the Themes service displays Started.
   

Enable the Allow desktop composition for remote desktop sessions Group Policy setting

To allow desktop composition when connecting to a computer running Windows Server 2008 R2, you must enable the Allow desktop composition for remote desktop sessions Group Policy setting. The Allow desktop composition for remote desktop sessions Group Policy setting is located in Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment and can be configured by using either Local Group Policy Editor or the Group Policy Management Console (GPMC).
For more information about Group Policy settings for Remote Desktop Services, see the Remote Desktop Services Technical Reference (http://go.microsoft.com/fwlink/?LinkId=138134).

Set the maximum color depth to 32 bits per pixel

Use the following procedure to set the maximum color depth to 32 bits per pixel on the RD Session Host server.
Membership in the local Administrators group, or equivalent, on the RD Session Host server that you plan to configure, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
To set the maximum color depth to 32 bits per pixel

1. On the RD Session Host server, open Remote Desktop Session Host Configuration. To open Remote Desktop Session Host Configuration, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Session Host Configuration.
   
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
   
3. Under Connections, right-click the name of the connection that you want to configure (for example, RDP-Tcp), and then click Properties.
   
4. On the Client Settings tab, in the Limit Maximum Color Depth box, select 32 bits per pixel.
   
5. Click OK. Changes to color depth settings are not applied to sessions that are connected when the change is made. The changes will take effect the next time the user establishes a new connection to the RD Session Host server.
   

You can also set the maximum color depth by applying the Limit maximum color depth Group Policy setting. This Group Policy setting is located in Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment and can be configured by using either Local Group Policy Editor or the Group Policy Management Console (GPMC). Note that the Group Policy setting will take precedence over the setting configured in Remote Desktop Session Host Configuration.
For more information about Group Policy settings for Remote Desktop Services, see the Remote Desktop Services Technical Reference (http://go.microsoft.com/fwlink/?LinkId=138134).

Additional references

• Configure the Client Experience on an RD Session Host Server

Desktop Experience Feature

The Desktop Experience feature allows you to install a variety of components and features that are provided in the Windows 7 operating system onto a computer that is running the Windows Server 2008 R2 operating system. After you install Desktop Experience, the Windows 7 components and features, such as Windows Media Player, will appear under All Programs on the Start menu.

Note
Installing Desktop Experience does not automatically turn on any of its features or components. After installing Desktop Experience, you must manually enable or configure the features or components.

For information about installing Desktop Experience, see Install Desktop Experience on an RD Session Host Server.

What’s in the Desktop Experience feature

Desktop Experience includes the following Windows 7 components and features:

• Windows Media Player
  
• Desktop themes
  
• Video for Windows (AVI support)
  
• Windows SideShow
  
• Windows Defender
  
• Disk Cleanup
  
• Sync Center
  
• Sound Recorder
  
• Character Map
  
• Snipping Tool
  

Additional references

• Configure the Client Experience on an RD Session Host Server

WSUS 3.0 SP2 Reports

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Standard

You can use Reports in Windows Server Update Services (WSUS) 3.0 SP2 to monitor the WSUS network, including updates, client computers, and downstream servers. If a WSUS server has replica servers, you can roll up client status information for the replica servers to the upstream server.
You can generate update reports from the following areas of the WSUS administration console:

1. General reports on the Reports page.
   
2. Reports about specific updates. (Right-click the update (or go to the Actions pane) and click Status Report.)
   
3. Reports on specific computers. (Right-click the computer (or go to the Actions pane) and click Status Report.)
   

Note
Generating detailed reports for large numbers of computers and/or updates can be memory intensive. Detailed reports are most effective for subsets of computers or updates. If you must create a very large report, and you are concerned about CPU and memory resources on the WSUS server, you can generate the report on a non-WSUS server that has the WSUS administration console installed.

In this topic:

• The Reports page
  
  
• Enable reporting rollup from replica servers
  
  

The Reports page

You can generate of the following reports in WSUS:

 

Report name	Function
Update Reports	View update status
Computer Reports	View computer status
Synchronization Reports	View the results of the last synchronization

Update reports

Update reports provide the status of the updates. You can run update reports in the following ways: summary, detailed, tabular, and tabular for approved updates. You can filter an update report by update classification, product, target computer group, and update installation status.
An update report displays information about the most recent contact between client computers and the WSUS server. We recommend that you generate this report the day after you approve updates, so that it reflects the latest approvals.

Note
To immediately connect a client computer to a WSUS server, you can run the wuauclt /detectnow command. This command is mainly used to update the status for a particular computer. After you issue this command on the client computer, you can get the computer status by running an update status report. For more information about wuauclt, seeManage WSUS 3.0 SP2 from the Command Line.

To run an update report

1. In the WSUS administration console, select the Reports node.
   
2. In the Reports pane, click one of the options in the Update Reports section: Update Status Summary, Update Detailed Status, Update Tabular Status, or Update Tabular Status for Approved Updates.
   
3. In the Updates Report window, you can select the updates that you want to see by classification, product, computer group, and update installation status.
   
4. Click Run Report.
   

   Note
   See the Update Status Report Terminology for WSUS 3.0 SP2 section for information about the status values that are shown on the report.

   
   
5. To change the view of an Update report to a detail, summary, or tabular view, click Report View in the Updates Report toolbar.
   

Update Status Summary View

The Update Status Summary view contains the elements that are listed in the following table.

Elements displayed in the Update Status Summary view

Column name	Description
Updates Report tree view	The tree that lists all the updates in the report.
Title	The title of the update.
Description	The description of the update.
Classification	The classification of the update.
Products	The products to which the update applies.
MSRC Severity Rating	Microsoft Security Response Center rating.
MSRC Number	Microsoft Security Response Center identification number.
More information	Redirection to the relevant website.
Approval Summary for Computer Group	The list of groups and approvals.
Group	The computer group.
Approval	Approval status (Approved, Not approved, Declined).
Deadline	The date by which the update must be installed.
Administrator	The administrative action.

Enable reporting rollup from replica servers

You can roll up the computer and update status from replica servers to their upstream server.

To enable reporting rollup from replica servers

1. In the WSUS administration console on the upstream server, click Options, and then Reporting Rollup.
   
2. Select the Roll up status from replica downstream servers check box, and then click OK.
   

Note
During the client scan, if the server detects that the client computer changed group membership (or name, IP address, or operating system version), it marks the client computer as needing a full rollup. The downstream server will roll up these changes to the upstream server during the next rollup after scan on the client computer.

Computer reports

Computer reports show you the status of computers. You can run computer reports in four ways: summary, detailed, tabular, and tabular for approved updates. You can also filter a computer report by update classification, product, target computer group, and update installation status.

To run a status report for computers

1. In the WSUS administrative console, select the Reports node.
   
2. In the Reports pane, click one of the options in the Computer Reports section: Computer Status Summary, Computer Detailed Status, Computer Tabular Status, or Computer Tabular Status for Approved Updates.
   
3. In the Computers Report window, you can select the updates that you want to see by classification, product, computer group, and update installation status.
   Note that for the Computer Tabular Status for Approved Updates report, the scope of the update approvals and the set of computers that are considered for the report is based on the selected target group.
   
   • The updates that are considered for the report are those for which the selected target group has direct or inherited approval for installation.
     
   • The computers that are considered for the report are those that are direct members of the selected target group, and optionally, its child target groups.
     
4. Click Run Report.
   
5. You can change the view of a Computer report to a detail, summary, or tabular view by clicking Report View in the Updates Report toolbar.
   

Synchronization Results report

The Synchronization Results report enables you to see synchronization information for the WSUS server for a given time period, including errors that occurred during synchronization and a list of new updates. In addition, you can get general, status, and revision information for each new update.

To run a Synchronization Results report

1. In the WSUS administrative console, click Reports.
   
2. In the Reports pane, click Synchronization Results. By default, the report shows any synchronization that was done today.
   
3. To change the synchronization period for the report, in the Synchronization Report window, click Between these dates and specify the dates that you want included in the report.
   
4. Click Run Report.
   

The report has four components, which are described in the following table.

Components of the Synchronization Results report

Component name	Purpose
Report Options	Shows the start and end dates of the period that is shown in the report, the date of the report, and the server for which the report was made.
Synchronization Summary	Displays summary information for the numbers of new, revised, and expired updates in each synchronization.
New Updates	Displays the new updates that have been synchronized to the WSUS server during the report's time period. You can view the properties for each update by clicking the update. An update status report will be generated for that individual report.
Revised Updates	Displays the revised updates that have been synchronized to the WSUS server during the report's time period. You can view the properties for each update by clicking the update. An update status report will be generated for that individual report.
Expired Updates	Displays the updates that have been expired during the report's time period.

Printing a report

You can print the report in update summary, detailed, or tabular views, depending on how you have formatted the update status report.

Exporting a report

You can print a report in its original format, or you can export it to Microsoft Excel® or to a PDF format.

Important
Exporting a large report can be extremely time consuming and may exceed your computer's memory resources. If you are planning to export a report, consider limiting the size of the report to 200 pages or fewer. You can use different filters to reduce the size of the report, or you can choose the tabular format rather than the detailed format to reduce the number of pages to export.

To export a report to Excel or PDF format

1. Run the report you want to export.
   
2. On the report toolbar, click the down arrow associated with the Save icon.
   
3. You will see two options: Excel and Acrobat (PDF) file. Click one of the options.
   

Extending reports

You can customize WSUS reports as follows:

1. Use the WSUS APIs to create a custom report.
   
2. Use WSUS public views to create and extend custom reports.
   

Use WSUS APIs to create custom reports

For more information about WSUS APIs, see the Windows Server Update Services SDK on MSDN. You can use these APIs to create reports for updates, approvals, installation information, and such.

Use WSUS public views to create custom reports

For more information about public views, in addition to sample queries, see the WSUS SDK conceptual documentation on MSDN. If you are using SQL Server as the WSUS database, you can use the SQL Server Report Builder to generate custom reports by using these views, or you can access the views from the command line.
If you are using Windows Internal Database as the WSUS database, you can access it through the command line if you download the Microsoft SQL Server Command Line Query Utility and the SQL Server Native Client. To download and install packages, seethe Feature Pack for Microsoft SQL Server 2005 in the Microsoft Download Center.