Daniele Tosatto

Microsoft has announced the availability of the white paper “Deploying a Virtualized Session-Based Remote Desktop Services Solution.”  This document provides guidance on deploying Remote Desktop Session Host (RD Session Host) and other Remote Desktop Services role services in a virtualized environment with minimal hardware resources. The document also provides scalability information for a virtualized Remote Desktop Services role configuration by using the Knowledge Worker scenario to help size hardware for similar workloads.

You can download the white paper here.

For all of you that are approaching virtualization topic  for new projects or assessments, don’t hesitate to contact me for assistance!

I will help you with info and strategic decision about this.

Contact me at dt@danieletosatto.com

Regards

Introduction

Many companies have multiple versions of Remote Desktop Session Host servers (formerly known as terminal servers), such as Windows 2000 Server, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2, in their environment. A remote desktop connection to any of these host servers requires a client access license (CAL) of the same or higher version. The CALs are installed on and managed by a Remote Desktop license server by using Remote Desktop Licensing Manager (RD Licensing Manager). Here you can find how to install and manage different version CALs on a single Remote Desktop license server.
What CALs can a specified license server manage?

Any license server can manage all lower version CALs along with the current version. For example, a license server that is running Windows Server 2008 R2 can manage all lower version CALs including Windows 2000 Server, Windows Server 2003, Windows Server 2008, as well as Windows Server 2008 R2 CALs. These CALs can be installed and managed by the Licensing Administrator on the license server by using RD Licensing Manager in Windows Server 2008 R2.

The license server running Windows Server 2008 R2 will also be able to cater to requests from all lower version terminal servers appropriately, allowing the customer business to continue seamlessly.

Note: Beginning with Windows Server 2008 R2, terminal servers are now called Remote Desktop Session Host servers. All earlier versions are still referred to as terminal servers.

A new feature introduced in Windows Server 2008 R2 allows you to migrate user CALs from one server to another. With this capability, you can migrate your existing Windows Server 2003 CALs from a license server running Windows Server 2003 to a license server running Windows Server 2008 R2 and manage them from the latest server. The attached compatibility matrix shows which CALs can be managed by which license servers.

http://www.danieletosatto.com/wp-content/uploads/2010/03/license_matrix.pdf

 FAQ

1. When a lower version CAL is migrated or installed on a higher version license server, do the rights of the CAL change?

No. For example, if you install a Windows Server 2003 Terminal Services client access license (TS CAL) on a license server running Windows Server 2008 R2, that CAL will only allow the user to access a terminal server running Windows Server 2003 or lower; you cannot use it to access an RD Session Host server running Windows Server 2008 R2.

2. Can a license server manage higher version CALs?

No, a license server can only manage CALs of the same version or lower. For example, a license server running Windows Server 2003 can manage Windows Server 2003 TS CALs and Windows 2000 Server TS CALs, but not Windows Server 2008 or Windows Server 2008 R2 CALs. Note that Windows Server 2008 R2 CALs are compatible with Windows Server 2008 CALs, so both can be managed by Windows Server 2008 (as well as by Windows Server 2008 R2). For more information, see Windows Server 2008 R2 RDS and Windows Server 2008 TS CAL Compatibility.

Similar to RemoteApp, the RemoteApp for Hyper-V feature allows users to access a specific hosted application remotely, as opposed to the entire desktop. When using RemoteApp, the application runs in the context of a server session; however, RemoteApp for Hyper-V enables remote access to an application running on a Hyper-V virtual machine (VM). That is, this feature allows you to launch applications that are hosted on VMs as remote applications.

Here I outline setup steps and common troubleshooting tricks for deploying RemoteApp for Hyper-V.

Supported Operating Systems

The supported SKUs for this feature are as follows:

• Guest operating systems on the Hyper-V server (all client operating systems):

1. Windows® 7 Enterprise, 32-bit edition; Windows 7 Ultimate, 32-bit edition
2. Windows Vista® Enterprise with Service Pack 1 (SP1), 32-bit edition; Windows Vista Ultimate with SP1, 32-bit edition
3. Windows® XP Professional with SP3, 32-bit edition

• Client operating system

1. Windows 7 64-bit / 32-bit

This feature can be deployed in either of the following two ways:

1. Stand-alone scenario

The administrator completes the following steps:

a. Set up the Hyper-V computer and install a supported guest operating system as outlined above in the “Supported Operating Systems” section.

For more information, see http://technet.microsoft.com/en-us/library/cc753637(WS.10).aspx.

b. Install the applications on the guest operating system and create RemoteApp RDP files specific to each application that would be launched as RemoteApp programs. How to create RemoteApp RDP files is explained in detail below.

c. Share these RDP files with the end user to launch this application as a RemoteApp program.

d. The user then launches these RDP files and enters their credentials to get access to the RemoteApp programs hosted on the guest operating system on the Hyper-V computer.

2. Virtual Desktop Infrastructure (VDI) scenario

The administrator completes the following steps:

a. Set up the entire VDI solution, which would involve deploying RD Connection Broker, farms, and personal desktops.

• • For more information about deploying VDI farms, see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e33b0953-e89a-4b97-a6fe-60da44add5c7.
  • For more information about deploying VDI personal desktops, see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0d278f5c-37fa-43fb-8032-614c7bf1d617.

b. Install the applications on the guest operating systems in the farm or personal desktop, and create RDP files according to the farm or personal desktop deployment.

c. Share these RDP files with the end user so that they can launch these applications as RemoteApp programs.

d. The user then launches these RDP files and enters their credentials to get access to the RemoteApp programs hosted on the guest operating system on the Hyper-V computer.

To set up guest operating systems on which we can enable RemoteApp for Hyper-V:

1. Windows XP SP3 32-bit guest operating system

a. Setting up the guest operating system

1. Install Windows XP Professional SP3, 32-bit edition, on the Hyper-V computer as a virtual machine.

2. Enable Remote Desktop on this VM.

3. Install the Windows XP SP3 RemoteApp for Hyper-V package on this VM.

Note: The update package for Windows XP SP3 can be found here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=2f376f53-83cf-4e5b-9515-2cb70662a81b&displaylang=en

4. Restart this VM after the package is installed.

5. Change the following regkey on this VM:

• • Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList.
  • Set the value of fDisabledAllowList to 1.

b. Creating the RDP file

1. Launch Remote Desktop Connection (MSTSC) and click Save As to save the RDP file that the administrator can use for the RemoteApp for Hyper-V feature.

2. Here is a sample RDP file for the stand-alone scenario described above:

The RDP file launches Notepad from the Windows XP SP3 guest operating system. The administrator can follow the steps below to create the RDP file.

As can be seen from the sample RDP file, the administrator would do the following:

1. Change the parameters

• • “remoteapplicationmode:i:1”
  • Alternate shell:s:rdpinit.exe

2. Add the parameters

• • RemoteApplicationName:s:<user friendly name>
  • RemoteApplicationProgram:s:<path to the application>
  • DisableRemoteAppCapsCheck:i:1
  • Prompt for Credentials on Client:i:1

After modifying the RDP file, the administrator saves the RDP file. For each application that he wants to publish as a RemoteApp program, the administrator creates an RDP file in a similar way as described above.

2. Windows Vista with SP1 32-bit guest operating system

a. Setting up the guest operating system

1. Install Windows Vista SP1 Enterprise or Ultimate, 32-bit edition on the Hyper-V computer as a VM.

2. Enable Remote Desktop on this VM.

3. Install the Windows Vista SP1 RemoteApp for Hyper-V package on this VM.

Note: Update the package for Windows Vista SP1:

http://www.microsoft.com/downloads/details.aspx?familyid=097B7478-3150-4D0D-A85A-6451F32C459C&displaylang=en

4. Restart this VM after the package is installed.

5. Change the following regkey on this VM:

• • Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList.
  • Set the value of fDisabledAllowList to 1.

b. Creating the RDP file

1. Launch Remote Desktop Connection (MSTSC) and click Save As to save the RDP file that the administrator can use for the RemoteApp for Hyper-V feature.

2. Here is sample RDP file for the stand-alone scenario described above:

The RDP file launches Notepad from the Windows Vista SP1 guest operating system. The administrator can follow the steps below to create the RDP file.

As can be seen from the sample RDP file, the administrator would do the following:

1. Change the parameters

• • “remoteapplicationmode:i:1”

2. Add the parameters

• • RemoteApplicationName:s:<user friendly name>
  • RemoteApplicationProgram:s:<path to the application>

After modifying the RDP file, the administrator saves the RDP file. For each application that he wants to publish as a RemoteApp program, the administrator creates an RDP file in a similar way as described above.

3. Windows 7 32-bit guest operating system

a. Setting up the guest operating system

1. Install Windows 7 Enterprise or Ultimate, 32-bit edition on the Hyper-V as a VM.

2. Enable Remote Desktop on this VM.

3. Change the following regkey on this VM:

• Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList.
• Set the value of fDisabledAllowList to 1.

b. Creating the RDP file

1. Launch Remote Desktop Connection (MSTSC) and click Save As to save the RDP file that the administrator can use for the RemoteApp for Hyper-V feature.

2. Here is sample RDP file for the stand-alone scenario described above:

The RDP file launches Notepad from the Windows 7 guest operating system. The administrator can follow the steps below to create the RDP file.

As can be seen from the sample RDP file, the administrator would do the following:

1. Change the parameters

• • “remoteapplicationmode:i:1”

2. Add the parameters

• • RemoteApplicationName:s:<user friendly name>
  • RemoteApplicationProgram:s:<path to the application>

After modifying the RDP file, the administrator saves the RDP file. For each application that he wants to publish as a RemoteApp program, the administrator creates an RDP file in a similar way as described above.

Some facts about the RemoteApp for Hyper-V feature

1. This feature is enabled by setting the following registry key on the Guest VM:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList, and setting the value of fDisabledAllowList to 1.
This means that we are disabling the application allow list on the VM, which means that any application from the VM can be launched as a RemoteApp program. The administrator does not have control over what applications are published or what applications can be launched. After the customer has the created RDP file, he can change the “RemoteApplicationName:s:” parameter and launch any application by setting the correct application path.

Troubleshooting issues that you might observe when enabling this feature

1. While launching RemoteApp for HyperV, you see the error “Windows cannot start the RemoteApp program.”

a. You might observe this error while enabling this feature.

b. This might happen if the fDisabledAllowList regkey is set to 0 on the VM.

c. Change the following regkey on this VM:

• Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList.
• Set the value of fDisabledAllowList to 1.

2. While launching RemoteApp on Windows XP SP3, the application does not launch and the connection is stuck in the details pane.

a. You might observe this error while enabling this feature on Windows XP SP3.

b. If you see this error, there is probably a missing parameter in your created RDP file.

c. Check to see if your created RDP file has alternate shell:s:rdpinit.exe.

d. If this parameter is missing, add this parameter to the RDP file and this should solve your problem.

3. “The remote computer does not support RemoteApp” error

a. You might observe this error while enabling this feature on Windows XP SP3.

b. If you see this error, there is probably a missing parameter in your created RDP file.

c. Check to see if your created RDP file has DisableRemoteAppCapsCheck:i:1

d. If this parameter is missing, add this parameter to the RDP file and this should solve your problem.

4. While launching RemoteApp on Windows XP SP3 / Windows Vista SP1, the application might get stuck in Remote Desktop

a. You might observe this if the update package for Windows XP SP3 or Windows Vista SP1 is not installed correctly on the VM.

b. Uninstall the package and restart the VM to make sure that the package is completely removed.

c. Now, reinstall the package and following the setup instructions as described above for Windows XP SP3 or Windows Vista SP1.

5. While launching RemoteApp, the credential window is shown in the details pane.

a. You might observe this error while enabling this feature on Windows XP SP3.

b. If you see this error, there is probably a missing parameter in your created RDP file.

c. Check to see if your created RDP file has Prompt for Credentials on Client:i:1.

d. If this parameter is missing, add this parameter to the RDP file and this should solve your problem.

The white paper, RD Session Host Capacity Planning in Windows Server 2008 R2, is now live on the Download Center.  This white paper describes the most relevant factors that influence the capacity of a given deployment, methodologies to evaluate capacity for specific deployments, and a set of experimental results for different combinations of usage scenarios and hardware configurations.

The Microsoft Virtual Desktop Infrastructure (Microsoft VDI) involves multiple role services. To develop a true high availability solution for this setup, you need to understand the high availability solution for each role service. This blog post identifies the key pieces of the Microsoft VDI solution and provides details on the high availability options available.

Key Microsoft role services that should be made highly available

1. Remote Desktop Session Host (RD Session Host) in redirection mode
2. Remote Desktop Connection Broker (RD Connection Broker)
3. Remote Desktop Virtualization Host (RD Virtualization Host)
4. Remote Desktop Web Access (RD Web Access)
5. Remote Desktop Licensing (RD Licensing) and Remote Desktop Gateway (RD Gateway)

High availability options for each role service

1. RD Session Host in redirection mode

A high availability solution for the RD Session Host server consists of high availability of the hardware, as well as high availability of the Remote Desktop Session Host role service.  You can use multiple RD Session Host servers and round robin DNS to provide high availability at both levels. High availability is obtained by virtue of the Remote Desktop Protocol (RDP) client trying all the IP addresses returned by the DNS server. All the RD Session Host servers should be running in active-active mode.

2. RD Connection Broker

Similar to RD Session Host, the RD Connection Broker role service can be made highly available at both the hardware and the service level by clustering multiple servers running the RD Connection Broker role service. Failover clustering guarantees that in the event of hardware or software (service) failure on the active node, a failover is triggered. In other words, a new active node would be selected at that time.  A step-by-step guide about how to configure an RD Connection Broker server in active-passive mode for high availability will be available soon on TechNet.

3. RD Virtualization Host

The Microsoft VDI solution supports highly available Hyper-V virtual machines. Setting up a failover cluster environment with multiple Hyper-V hosts will ensure that in the event of a hardware failure on a Hyper-V host, the virtual machines will fail over to another Hyper-V host and automatically start. If the Remote Desktop Virtualization Host Agent service fails, this service is configured to restart automatically. Thus all the Hyper-V virtual machines would be available all the time.

4. RD Web Access

High availability of the RD Web Access role service is achieved by deploying it in an active-active mode. Multiple RD Web Access servers can be configured as part of a Network Load Balancing (NLB) cluster to achieve this. You could also use round robin DNS in place of an NLB cluster to make the RD Web Access role service highly available.

5. RD Licensing and RD Gateway

For high availability of RD Licensing and RD Gateway, see the following:

· Deploying Remote Desktop Licensing Step-by-Step Guide (http://technet.microsoft.com/en-us/library/dd983943(WS.10).aspx)

· Improving TS Gateway availability using NLB (http://blogs.msdn.com/rds/archive/2009/03/24/improving-ts-gateway-availability-using-nlb.aspx)

Unsupported high availability deployment configurations

There are two deployment configurations that are not supported:

1. Clustering RD Connection Broker servers on RD Virtualization Host servers.
2. An active-active RD Connection Broker installation.

More information about setting up highly available VDI

A step-by -step guide for high availability of all the components mentioned above will be published soon.

Glossary

· Active/Active failover cluster model. All nodes in the failover cluster are functioning and serving clients. If a node fails, the resource will move to another node and continue to function normally, assuming that the new server has enough capacity to handle the additional workload.

· Active/Passive failover cluster model. One node in the failover cluster typically sits idle until a failover occurs. After a failover, this passive node has enough capacity to serve the new application without any performance degradation.

The Remote Desktop Services (RDS) Application Compatibility Analyzer is a runtime program analysis tool that enables administrators and users to determine the compatibility of an application with a Remote Desktop Session Host (RD Session Host) server before deploying it. The tool provides a summary of incompatible behaviour between the RD Session Host server and an application, and provides recommendations for deploying the application on an RD Session Host server. The RDS Application Compatibility Analyzer uses the LUA (Least Privileged User Account) Predictor technology, which is part of Microsoft Application Verifier. 

This blog post describes how to:

1. Install the RDS Application Compatibility Analyzer
2. Run an application in the RDS Application Compatibility Analyzer
3. Test an application for RDS compliance
4. Debug info and blog feeds
5. Filter noise, detailed stack trace, and logging
6. Interpret RDS Application Compatibility Analyzer logs

1. Installing the RDS Application Compatibility Analyzer

The RDS Application Compatibility Analyzer installer can be found at https://connect.microsoft.com/tsappcompat/Downloads.

The Application Verifier must be installed before the RDS Application Compatibility Analyzer is launched. The recommended version (3.5) of Application Verifier can be found at [X64] [X86]. On 64-bit operating systems, the RDS Application Compatibility Analyzer needs both 32-bit and 64-bit versions of Application Verifier. If Application Verifier is not installed, or the installed Application Verifier version is less than 3.5, the RDS Application Compatibility Analyzer will point to the Application Verifier 3.5 download location. If the installed Application Verifier version is greater than 3.5, the tool does not prompt for Application Verifier. However, we recommend that you uninstall the latest version of Application Verifier and install Application Verifier 3.5. Microsoft .NET Framework 3.5 is also required to run the tool. The tool can be run on a client or server operating system. It does not require that the RD Session Host role service be installed.

2.Running an application in the RDS Application Compatibility Analyzer

A. From the UI:

1. Click Start, point to All Programs, and then click RDS Application Compatibility Analyzer.

2. On the App Info tab, in the Target Application box, enter the directory location of the target application’s executable file or use the Browse function.

3. On the App Info tab, in the Parameters box, enter parameters for the application, if applicable.

4. Ensure that the RDSAnalyzerService is up and running. Select or clear the Launch Elevate check box as appropriate.

5. Click Launch.

B. From the command-line (batch mode and no UI):

The RDS Application Compatibility Analyzer can be run in a batch mode (without UI). This feature makes it easier to deploy it to multiple users seamlessly without using the user interface, which can be intrusive. Following are the supported command-line options:

1. Tsa.exe /? : This pops up a dialog box which lists all the command-line options.

2. Tsa.exe <logfilename>: This opens an already created log file for analysis.

3. Tsa.exe –l <logfilename> <Application> <”parameters to the application”>: This launches the application with given parameters, and logs are stored in the log file. No UI is displayed in this case. For log analysis, run “Tsa.exe <logfilename>”; this opens an already created log file for analysis.

3. Testing an application for RDS compliance

When an application is launched by using the RDS Application Compatibility Analyzer, the RDS Application Compatibility Analyzer monitors the application’s actions while it is running and waits for the application to be closed. The RDS Application Compatibility Analyzer waits for all child processes created by the application to exit before it starts to load the log file. Sometimes a certain child process might still be running even after the main application process has exited. In that case, you can either manually find and terminate that child process, or use the Refresh Log button to manually load the log file.

The RDS Application Compatibility Analyzer then generates and parses a log for the application, which might take some time to complete. After the log has been generated and parsed, click any tab (File, Registry, INI, Token, Privilege, Namespace, Other Objects, Process) to view specific issues found by the RDS Application Compatibility Analyzer in that category.

Use the following procedure to detect issues:

 Run application as a standard user versus run as elevated:

The Launch Elevate check box controls whether the application that you selected will run as an administrator or as a standard user (without administrator-level user rights and Windows privileges). The option that you select will impact the types of UAC problems that the RDS Application Compatibility Analyzer detects. 

If the RDS Application Compatibility Analyzer launches the application as a standard user, there will be many errors related to ACCESS_DENIED issues. These errors occur due to the application running with reduced user rights and privileges. Many applications terminate at the first unexpected error. In this case, you will find only one error with each execution of the application.

If the RDS Application Compatibility Analyzer launches the application as an administrator, it predicts errors that result from the application’s successful access attempts. In this case, you will find most of the application errors because the application did not stop at the first error. Certain classes of errors may distort the analysis. For example, if an application performs a COM registration during initialization, that application may behave correctly after running the RDS Application Compatibility Analyzer because the COM object was already registered. The application might generate a false-negative reading from the RDS Application Compatibility Analyzer indicating that the application will behave correctly with the application.

4. Debugging info and blog feeds

Debug info:

The Debug Info tab shows commands executed by the tool and their success or failure status. The Repro button on the Debug Info tab helps to analyze actions done during the repro period. For example, if the user wants to analyze logs for a specific action, he/she can start the repro by clicking Repro and perform the action, and then stop the repro by clicking Stop Repro. In this case, the actions performed during the repro period will be analyzed.

Blog feeds:

On the Blog Feeds tab, you can add RSS feed URLS that will be used to search blog posts for related problems. Following are the steps to add RSS feed URLS:

1. On the Blog Feeds tab, select the Enable Blog Feeds check box.

2. In the Feed URL box, type the RSS feed URL, and then click Add New Feed.

3. Select the feed URL by selecting the Blog Feed URL check box, and then click Update. 

Updated RSS feeds are used for finding similar problems posted in blog feeds. To view related problems for an error from blog posts, enable the Show RSS Feeds option. This option can be enabled on the View tab by selecting Show RSS Feeds under Detailed Information. When this option is enabled, the lower-left panel of the RDS Application Compatibility Analyzer displays the blog post that is related to the selected error. 

5. Filtering noise, detailed stack trace, and logging

Filter noise:

Noise filtering can be enabled or disabled by using the Filter Noise option. The tool filters noise by using a filter file in xml format. The noise filter file can be loaded or exported by clicking Load Noise Filter File or Export Noise Filter File on the Options menu. Logging for a specific API call can be filtered by adding a node to the noise filter file. For example, to filter the RegOpenKeyExA call for the registry key Internet Settings, add the following node to the noise filter file and then load the noise filter file:

<avrf:logEntry Time=”9/09/2009 9:09:09 AM” LayerName=”LuaPriv” StopCode=”0″ Severity=”any”> <avrf:formatmessage>(\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings) (RegOpenKeyExA) </avrf:formatmessage>
<avrf:IsNoise>true</avrf:IsNoise>
</avrf:logEntry>

Detailed stack trace:

Detailed stack trace can be enabled by selecting the option Show More Details in StackTrace. This will show additional stack frames that are related to the SUA but not the application being diagnosed. Debug information for other applications can be filtered by selecting the Only Display Records With Application Name In StackTrace option. The tool captures the first 32 stack frames, so enabling this option might filter out real issues if a call stack is deeper than 32 frames.

If the Detailed Information option on the View menu is enabled, when an issue on any individual tab is selected, the lower-left panel of the RDS Application Compatibility Analyzer displays all related records from the log file. The lower-right panel will display the detailed information for the selected record, including a detailed message and the stack trace. 

Logging:

The tool categorizes logging into errors, warnings, and information. By default, logging is done for warnings and errors. Logging for warnings, errors, and information can be enabled or disabled on the Options menu by selecting Logging.

6. Interpreting RDS Application Compatibility Analyzer logs

The tool categorizes processed logs onto different tabs. Found issues are categorized by severity levels Warnings and Problems. The focus should be only on Problems unless you are trying to pinpoint a problem source. One key thing to understand about a Problem is that the tool has detected that a non-RDS-compatible API call has been made by the application, but this call itself can be a part of a condition in the application. So Problems are potential problems and need to be analyzed to interpret them correctly. The tool highlights potential problems in an application that might not always manifest. It is essential to understand this to correctly interpret and use the results effectively.

The following table shows details about each tab in the RDS Application Compatibility Analyzer GUI:

 

Tab	Details
File / Registry	Lists file system and registry access issues (for example, an application attempting to write to a file or a registry key under HKLM that normally only administrators can access). Applications create various registry entries, folders and files during installation. Usually the application files are created in an application repository (typically the “Program Files” directory) and the registry entries are created in HKLM and HKCU hives. User data files are created within the user profile folder (%userprofile%). Application shortcuts are created within the user profile as well. Most application installations are designed for a single-user client system and this could cause problems in the Remote Desktop Services environment. Installation can be broadly divided into two parts:1. Installation activities: The application should create all common application files, libraries and registry entries at installation.· The application should not create files and registries that contain user-specific data that is not needed by other users at this stage.· The application should store user shortcuts or any truly common files that will be used by all users (typically read-only files with common application settings or database/repository files) in the All Users stores (%allusersprofile% for data and %public% for shortcuts, desktop content, etc.).· Files and registry entries stored in locations that need privileged access can cause problems when they are used by a non-administrative user. While user-specific files and registries must be created in the user’s hive, the application should not do this at install time because these files and registries will be available only to the installing user. The application should do this after installation. Most of the RDS-specific problems occur because of user-specific deployment: · Any registry entries made in HKCU at installation are available only to the user installing the software, who is usually the administrator. When another user then tries to use that application, these entries would not be available to that user. · Similarly any data files created within the installing user’s user profile would not be available when the application is executed by another user. 2. Post-installation activities: The application should create all user-specific data files, registry entries, etc. after installation. This can usually be triggered by user-logon or the first run of the application. · Common scripts and definitions created after installation can be stored in the common and public files as discussed above. · These scripts can be executed at first run of the application by a particular user to create files and registry entries for that user. This ensures that every user creates and owns their own user-specific data in their user profile that is isolated from all other users. Microsoft Windows Installer supports creating per-user scripts that can be leveraged for this purpose.
INI	Lists WriteProfile APIs issues. WriteProfile APIs were originally used for 16-bit Windows but are still popular in some modern applications.
Token	Lists access token checking issues. If an application explicitly checks for the Builtin\Administrators security identifier (SID) in a user’s access token, the application most likely will not work for a standard user.
Privilege	Lists privilege issues. For example, if an application explicitly enables SeDebugPrivilege, it will not work for a standard user.
Name Space	Lists issues that are caused when an application creates system objects (e.g. events, memory mappings) in restricted namespace. Applications that have this error will not work for a standard user.
Other Objects	Lists issues related to accessing objects other than files and registry keys. The following are some generic recommendations for applications working in a concurrent user environment:· All objects, such as pipes, ports, shared libraries, and components, must be isolated per session or locked for exclusive access for modification as per application scenarios. To avoid data corruption, concurrent writes by multiple instances should not be allowed.· The application should not use a fixed port number for listening or a pipe name for an application, but rather have a unique identifier for each instance.
Process	Lists issues related to process elevation. On Windows Vista®, if an application uses the CreateProcess API to launch an executable that requires elevation, the application will not work for a standard user.

The Remote Desktop Gateway (RD Gateway, formerly known as TS Gateway) ISA configuration script helps ease the process of setting up an ISA server for RD Gateway supported scenarios such as the RD Gateway-ISA core scenario and the RD Gateway-ISA OTP scenario. The script runs on the ISA server and completely eliminates the need to configure the ISA server through wizards. Instead, users can create web listeners and web publishing rules through the command line. Additionally, the script can validate existing web publishing rules and web listeners. In the event that issues are discovered with them, the script provides a list of warnings and errors to the user. The script is supported on ISA server 2004 and later versions. It can be used to publish Windows Server 2008 and higher versions of RD Gateway. This script, along with information on its usage, can be found here.

I want to talk about a little known feature in Windows Server 2008 R2 that could be described as RemoteApp for Hyper-V. Like Microsoft RemoteApp, it allows users to access a specific hosted application remotely, as opposed to the entire desktop. With RemoteApp, the application runs in the context of a server session; however, RemoteApp for Hyper-V enables remote access to an application running in a Hyper-V VM.

With the advent of Windows 7, some enterprise customers were facing application compatibility issues with line-of-business applications that were specifically written for Windows XP and would not work on Windows 7.

One obvious way to resolve this issue is to run those incompatible applications in Windows XP Mode, a new feature that is available in certain Windows 7 SKUs and which simplifies migration to the new OS by allowing legacy XP applications to seamlessly run in their own context within a Windows 7 environment. Windows XP mode has specific hardware, OS and memory requirements. While this solution works well on newer machines with hardware virtualization support, the hardware requirements for XP mode might be prohibitive for some older PCs.

RemoteApp for Hyper-V allows users to remotely access Windows XP applications from their Windows 7 desktop with no additional hardware requirements.

• SKU support: RemoteApp for Hyper-V is supported on the following SKUs running as the guest OS:
  • Windows XP SP3: Professional
  • Windows Vista SP1 and above: Enterprise and Ultimate
  • Windows 7: Enterprise and Ultimate

Here are some examples of applications that will benefit from this feature:

• • Applications that are compatible only with Windows XP SP3
  • Applications that can run on Windows Server 2003, but not Windows Server 2008 or Windows Server 2008 R2
  • Applications that are supposed to be run only on a data center server for data security or compliance reasons

To use this feature, a user connects remotely from a client computer to the VM-hosted application. To host the applications, an administrator sets up a virtual machine with a guest OS on a Hyper-V server hosting the virtual machine.

The client computer must run Windows 7, but the guest OS on the virtual machine can run Windows XP SP3, Windows Vista (with SP1 and above) or Windows 7. For a guest OS running Windows XP SP3, an update is required; for a guest OS running Windows Vista SP1 or above, another update is needed.

• So, how can an administrator deploy this?

There are two ways in which RemoteApp for Hyper-V can be deployed. The first way is the stand-alone scenario, in which all the administrator needs to do is set up a Hyper-V server with virtual machines running a client OS (for example, Windows XP SP3). The administrator would then set up the application and create RDP files that launch this application. A user can connect to the application via a simple Remote Desktop connection using the RDP file.

Here’s how this setup would look:

While this is a simple setup that an administrator can use to pilot the RemoteApp for Hyper-V, it offers no extra efficiency or ability to load balance. One serious drawback of this method is that since only one user can connect to an application at a time, one user connecting to multiple virtual machines effectively blocks out other users.

To get around this problem, the recommended way to install RemoteApp for Hyper-V is over a complete VDI farm or personal virtual desktop setup, including setting up the RD Connection Broker role. An administrator would still need to perform the same manual steps of setting up the application and creating an RDP file, but there are significant advantages to going through the RD Connection Broker. An obvious one is load balancing. In addition, there is increased efficiency, simply because when a user is connected to a virtual machine, all applications launched by that user are redirected to the same virtual machine. Only one user can connect to applications running on a particular virtual machine at a time.

One single user cannot block out an entire farm by holding onto different virtual machines on it at the same time. Until a user’s virtual machine is terminated, redirection is always to the same VM. RD Connection Broker ensures that a user connected to a VM stays connected until logged out.

Here’s how the second setup scenario described above would look (running from a Windows XP SP3 farm, for instance):

Hosting applications in a farm of virtual machines running Windows XP SP3 is a simple way to give multiple people on the domain access to the applications. There is no security filtering for applications on a virtual machine farm. All domain users who have access to the farm will have access to the applications.

If an administrator wants to give only a specific user access to an application, the application should be hosted on a personal desktop. In all cases–farms or personal desktops–an administrator only needs to create an RDP file and hand it over to a user, either via a network share or email.

RemoteApp for Hyper-V is a basic but powerful platform capability which was designed with advanced administrators in mind who are willing to do the manual configuration steps to enable an environment that includes remote access to VM-hosted applications. It serves also as an extensibility point for our RDS partner ecosystem who may want to take advantage of this infrastructure capability and provide additional value-add to RDS customers by streamlining the configuration and expanding the usability and manageability of it. For example, with additional code, it is possible to integrate the RDP files with Remote Desktop Web Access.

Related links:

Update package for Windows XP SP3:

http://www.microsoft.com/downloads/details.aspx?FamilyID=2f376f53-83cf-4e5b-9515-2cb70662a81b&displaylang=en

Update package for Windows Vista SP1 or above:

http://www.microsoft.com/downloads/details.aspx?familyid=097B7478-3150-4D0D-A85A-6451F32C459C&displaylang=en

Overview

The purpose of this post is to help an Administrator configure a Windows Vista or Windows XP operating system in a virtual machine for a Remote Desktop Services Virtual Desktop Infrastructure (VDI) deployment.

This post is an addendum to the Step 2: Installing and Configuring the Virtual Machine section for the following Step-by-Step guides published in Microsoft ®TechNet:

1. Deploying Virtual Desktop Pools by Using Remote Desktop Web Access Step-by-Step Guide.
2. Deploying Virtual Desktop Pools by Using RemoteApp and Desktop Connection Step-by-Step Guide.
3. Deploying Personal Virtual Desktops by Using Remote Desktop Web Access Step-by-Step Guide.
4. Deploying Personal Virtual Desktops by Using RemoteApp and Desktop Connection Step-by-Step Guide.

Additional Steps required to support Windows Vista and Windows XP

The following steps need to be completed before the Configure the virtual machine for Remote Desktop Services section in the guides mentioned above.

1. Choose supported operation system: Install the supported version of the Windows Vista or Windows XP as the guest operating system. The following link contains the reference to the list of various supported versions of Windows Vista or Windows XP.
2. Install Integration Services component: Follow the instructions here at Step 4: To install the integration services on the virtual machine.
3. Only for Windows XP: Install PowerShell package: Follow the instructions here to install this package. This step is not needed if you are using VBS script for configuring the guest operating systems.

   The following steps need to be completed before moving on the Step 3 in the guides mentioned above.

4. Only for Windows XP: Restart the Windows XP machine.

Additional Resources

1. Configure Guest OS for Microsoft VDI using Powershell: http://gallery.technet.microsoft.com/ScriptCenter/en-us/bd2e02d0-efe7-4f89-84e5-7ad70f9a7bf0
2. Configure Guest OS for Microsoft VDI using VB Script: http://gallery.technet.microsoft.com/ScriptCenter/en-us/68462b23-0890-4dbd-95b6-8de5763e4f68)
   Note: If you choose to use the VB Script to automate configuring the settings, then you can skip Step# 3 in the section above.