This blog is a follow-up to the RemoteApp for Hyper-V blog at http://blogs.msdn.com/rds/archive/2009/12/15/remoteapp-for-hyper-v.aspx.

Introduction

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.

This blog outlines 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

As outlined in the “RemoteApp for Hyper-V” blog, 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.

Microsoft’s VDI solution offers two deployment scenarios: virtual desktop pools and personal virtual desktops. Virtual desktop pools are not dependent on a specific Active Directory schema level; however, personal virtual desktops do need a Windows Server 2008 or Windows Server 2008 R2 schema.

Here are the Active Directory requirements for personal virtual desktops:

• To deploy personal virtual desktops, your schema for the Active Directory forest must be at least Windows Server 2008. To use the added functionality provided by the Personal Virtual Desktop tab in the User Account Properties dialog box in Active Directory Users and Computers, you must run Active Directory Users and Computers from a computer running Windows Server 2008 R2 or from a computer running Windows 7 that has Remote Server Administration Tools (RSAT) installed.
• You must use a domain functional level of at least Windows 2000 Server native mode. The functional levels Windows 2000 Server mixed mode and Windows Server 2003 interim mode are not supported.

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

I’m the partner program manager for the Remote Desktop Services (RDS) team. I help our ISV partners develop on our platform. Any API that is available to partners outside of Microsoft is documented on MSDN, but the MSDN format doesn’t always make it easy to publish longer documents or sample code. That’s why we created a new site on Microsoft’s Code Gallery, where we can publish this kind of information.

Remote Desktop Services Developer Resources currently contains the following documents:

· How to use the pluggable authentication and authorization framework for RD Gateway (in short, it enables companies to plug in a custom authentication and authorization scheme)

· How to send the publishing feed to another Web site or to a new client application

· The Visual Studio settings you should use for creating plug-ins for RDS

It also contains samples for the following:

· Creating filter plug-ins for the RD Connection Broker server

· Creating resource plug-ins for the RD Connection Broker server

· Consuming the publishing feed on a new Web page

· Consuming the publishing feed in a client application

That’s just the beginning. If you’re a developer and there are samples that you’d like to see, please comment in the Discussions section on the site and we’ll try to help out. I’m afraid we can’t help debug your code, but we do want to get the information out there that you need to be successful. Your feedback helps us deliver what you need.

Thanks, and I hope to see you there!

P.S. If you’re an IT pro looking for server management scripts, please check out the RDS site on Script Center, where you’ll find a plethora of PowerShell and VBScript administrative scripts.

Hi, I’m Joe and I’m the programming writer who maintains the RDS content on MSDN. We welcome your comments and observations about MSDN Library content. Topics in MSDN Library offer various methods for providing feedback about the accuracy and thoroughness of the content. Here they are, from most effective to least effective, as seen in Classic View:

1. (Recommended) "Send comments about this topic to Microsoft" link, where available. This link generates an e-mail message that is sent to the writing team that maintains the topic. By using this link, you can provide detailed suggestions for improving the topic. The writer may contact you if clarification is required. After the writer has addressed your suggestions, we remove all personally identifiable information, including your e-mail address, from our system. For more information about Microsoft's privacy policy, see http://privacy.microsoft.com/en-us/default.aspx.
2. "Community Content" annotation control at the bottom of each topic, where available. Have you discovered something that would help other readers? You can share it here. To ask questions or participate in discussions about the APIs, please use the MSDN Forums (http://forums.microsoft.com/msdn/) or the Microsoft discussion group for Remote Desktop Services.
3. "Click to Rate and Give Feedback" stars in the upper right of each topic, where available. Your rating and feedback comments are recorded and reviewed to understand how you would like us to improve the topic. No personally identifiable information (PII) is collected.

With the growing trend toward desktop virtualization, it is Microsoft’s goal to provide enterprises with a flexible model for centralized computing, whereby the broadest range of client devices can help securely access company data and applications from any location on the network.

As with Remote Desktop Services in Windows Server 2008 R2, virtual machine-based desktop virtualization faces increasing performance challenges when enterprises attempt to use this technology to support a globally distributed workforce. A key consideration of performance relates to Remote Desktop protocol efficiency which continues to present an issue for bandwidth constrained environments. This limitation can manifest itself by limiting the number of users who can access virtualized desktops (user density) over available bandwidth, and with a degraded user experience. Remote Desktop Protocol (RDP) 7.0, similar to previous RDP versions, provides a competitive experience for low bandwidth (e.g. 56 Kbps) connections. After bandwidth requirements, network latency is the second fundamental challenge for customers and partners that wish to deploy virtualized desktops for a broad range of end-users and applications.

With the release of the Windows Server® 2008 R2 and Windows® 7 operating systems, RDP 7.0 is even more feature-rich than its predecessors—enabling new remoting functionality such as accelerated bitmap rendering, multi-media redirection streaming, and network topology awareness. In short, RDP 7.0 is better able to support today’s ever increasingly complex and rich multi-media environment.

To improve the user experience when connecting over high latency networks, RDP 7.0 added “client hint” functionality. “Client hint” can be enabled by using the Remote Desktop Connection (RDC) 7.0 client UI to set the connection speed on the Experience tab.

The same setting can be configured via .rdp files by selecting WAN (10 Mbps or higher with high latency) or Satellite (2 Mbps–16 Mbps with high latency) with connection type:i:5 or connection type:i:3 respectively.

As these features become integrated into the enterprise environment, it is important to analyze and understand their impact on enterprises’ current network infrastructure and end-user experience. The Remote Desktop Protocol Performance Improvements in Windows Server 2008 R2 and Windows 7 white paper details RDP features and the potential for improvements to usability and the quality of the end-user remoting experience, as well as system deployment metrics.

Note: You should not interpret the performance characteristics presented in the white paper as benchmark measurements that all systems can support. Only empirical testing on the target system can provide an accurate benchmark of your specific scenario.

Remote Desktop Services partners are very important to the RDS team. We’ve had a partner page up for a long time, but wanted to refresh it to better show what our partners do and what value they add to the RDS platform, as well as help you find the resources you want. Today, I’d like to announce the kickoff of the updated site.

Four of our partners (so far) have put together free offerings for this site. In addition, we have several other partners working on limited version downloads that will be included on our site over the upcoming months. In alphabetical order:

· Desktopsites has created a limited version of their Konect management tools that allow you to manage heterogeneous Terminal Services/Remote Desktop Services deployments from a central console. For thirty days, the free version allows you to manage settings for two users across multiple servers; at the thirty-day mark, the trial becomes a limited-version for two users with no expiration.

· Ericom has created a limited version of their PowerTerm WebConnect for Windows Server 2008 R2. This solution provides centralized application publishing, simplified configuration management, real-time monitoring, logging, and control.

· Immidio has created a Resource Kit (note, this is separate from the Resource Kits offered by Microsoft) that contains several utilities useful for both administrators and users. My favorite is the one that remotes the display of the battery-life SysTray icon, so that if you’re working on a virtual machine (VM) or full-desktop session from an unplugged laptop, you won’t be taken unawares when the battery dies.

· RES Software has a management tool for controlling which applications users can view from a desktop. Their freeware version of PowerFuse not only hides application icons that users don’t have permission to use, but it locks them down so that they can’t be launched from the command line or Windows Explorer.

For more details, stop by and visit our new partner page. If you have suggestions for additional tools that you feel would help you with your RDS deployments for VDI or session virtualization, make a note on this blog and do check back often as we will continually be adding new case studies and product offerings from our partners.

People have asked us how easy it is to install a complete MS VDI solution and how many servers does it take.  I’ve created a video to showcase that you can setup a complete solution including backend, broker, and web publishing to provide virtualized clients on a single physical Windows Server 2008 R2 box.  This sample uses Windows 7 for the guest.     The complete 16 minute video is at http://www.microsoft.com/showcase/en/us/details/fbaf6f70-45fd-4c81-be70-6d276d54776b

To learn more about Microsoft VDI:

http://technet.microsoft.com/en-us/library/dd647502(WS.10).aspx (step-by-step guides)

http://social.technet.microsoft.com/Profile/en-US/?user=RemoteDesktopServices&sp=tng (scripts)

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.

Imagine that you are responsible for managing Remote Desktop Services at Woodgrove Bank. Woodgrove Bank has recently approved a new authentication vendor and you must upgrade all edge services -- including Remote Desktop Gateway (RD Gateway) – to support this new authentication service. How can you integrate the new authentication service with RD Gateway?

The RD Gateway 2008 R2 server platform enables you to integrate custom authentication schemes using the pluggable authentication and authorization (PAA) framework. PAA provides your authentication vendor an interface for developing and integrating custom authentication and authorization plug-ins to the RD Gateway platform. For more details, please refer to the following article hosted on the code gallery: https://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=rdsdev&ReleaseId=3745

Scenario

The two virtual machine deployment scenarios supported by the Microsoft VDI solution are: 1) Virtual desktop pool and 2) Personal virtual desktops. These two scenarios present two different models of assigning virtual machines to end users. This post explains the virtual desktop pool scenario.

Assignment

A virtual desktop pool temporarily assigns a virtual machine to the user. The Remote Desktop Connection Broker (RD Connection Broker) automatically makes this assignment without any prior assignment configuration. The user–to-virtual-machine assignment is removed as soon as the user logs off. Since there is no permanent assignment of a virtual machine in a virtual desktop pool to a user, as long as there is a virtual machine available in the pool, one will be assigned to the user. It is a misconfiguration to assign a virtual machine in a virtual desktop pool to a user as if it were a personal virtual desktop. When a user makes a connection to such a personal desktop which is part of a virtual desktop pool, the connection will fail and a target mismatch event is logged by RD Connection Broker.

Access

A virtual desktop pool is a group of identically configured virtual machines on a Remote Desktop Virtualization Host (RD Virtualization Host) server. Users can access the virtual machines in a pool through RemoteApp and Desktop Connection or RD Web Access. When a user clicks on the Virtual Desktop pool icon, RD Virtualization Host prepares a pre-created virtual machine from this virtual desktop pool for a remote RDP connection. A virtual machine can be a member of only one virtual desktop pool. All virtual machines in a virtual desktop pool are identically configured; a user sees the same virtual desktop regardless of which virtual machine in the virtual desktop pool the user connects to. Since a user might be connected to a different virtual machine in the virtual desktop pool each time he logs on, it is recommended to use roaming profiles and folder redirection to centrally manage user settings and data. Please refer to the link for more details:

http://blogs.msdn.com/rds/archive/2009/06/02/user-profiles-on-windows-server-2008-r2-remote-desktop-services.aspx

Load Balancing

To assign a virtual machine from a virtual desktop pool a Hyper-V server which has the least number of running virtual machines is chosen and a virtual machine belonging to this virtual desktop pool is selected. A random selection is made if two or more Hyper-V servers have the same number of running virtual machines. ISVs can enhance the inbox solution by implementing their own load balancing algorithm. Please refer to the link for more details:

http://msdn.microsoft.com/en-us/library/dd401684(VS.85).aspx

http://blogs.msdn.com/rds/archive/2008/09/25/ts-session-broker-extensibility-part-2.aspx

Disconnected VMs

When a user disconnects from a virtual machine in a virtual desktop pool, the user will be redirected to his disconnected VMs the next time he logs back. However, when a user logs off from the virtual machine, the virtual machine can be configured to rollback (refer to the links at the end on how to set up a virtual desktop pool to find details on this) to a state determined by an administrator. Since a user might be connected to a different virtual machine in the virtual desktop pool each time he logs on, it is recommended to use roaming profiles and folder redirection to save user state.

Installation

A virtual desktop pool can span multiple Hyper-V servers with each server possibly having virtual machines from multiple virtual desktop pools. The 3 supported guest operating systems inside a virtual machine are –Win7, Vista SP1 and SP2 and XP SP2 and SP3. For details on the specific versions of these software please refer to the following link - http://technet.microsoft.com/en-us/library/cc794868(WS.10).aspx

For details on how to set up a virtual desktop pool, please refer to:

Technical Library

Microsoft Download Center

Deploying Virtual Desktop Pools by Using Remote Desktop Web Access Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=147906)

Deploying Virtual Desktop Pools by Using Remote Desktop Web Access Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=147907)

Deploying a Virtual Desktop Pool by Using RemoteApp and Desktop Connection Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=154802)

Deploying a Virtual Desktop Pool by Using RemoteApp and Desktop Connection Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=154803)

In our earlier blog post, we introduced RemoteApp and Desktop Connections to enable users to have their RemoteApp and Desktop icons integrated on their Windows 7 start menu.  RemoteApp and Desktop Connections works with this new feature of Remote Desktop Web Access (RD Web Access)--the RemoteApp and Desktop Connection feed. This RemoteApp and Desktop Connection feed provides significant extensibility to partners and customers in presenting remote resources in various ways. The connection feed feature contains information about published remote resources (e.g. RDP files and their associated icon and image files) in a software-parsable XML format.

On Remote Desktop Web Access (RD Web Access) Server, there are two URLs available to serve the connection feed. You need to choose one depending on the extensibility scenario.

1. “/rdweb/pages/webfeed.aspx” URL:
   This URL is used for RD Web Access website extensibility. You can create a new web page similar to the RD Web Access default webpage. Below are some of the features that are possible by using this URL

• Branding or customizations for your customers or organization.
• Visually sorting or segregating remote resource types (e.g. RemoteApp and Remote Desktop resources).
• Filtering remote resources at display time (for example, additional filtering apart from RemoteApp filtering ).
• Silverlight-based webpage for a rich user experience.

By using this connection feed URL

• There is no need to write a custom authentication mechanism because the webpage runs within the RD Web Access web application.
• It is easier to support Single Sign On for launching remote resources. In a future post, we will cover on how to enable SSO.

2. “/rdweb/feed/webfeed.aspx” URL:
   This URL can also be used to provide extensibility and is more flexible than the above URL. In addition to above feature set, below are some of the other features that are possible by using this URL:

• Creating new client applications similar to RemoteApp and Desktop Connections for downlevel windows clients and for thin clients.
• Creating new web portal similar to RD Web Access, not just a webpage alone.
• Integrating remote resource presentation with your existing web portal.

By using this connection feed URL

• Client applications get an authentication cookie that will not expire. This can be used for easier automatic updates without re-prompting user for credentials.

Here is a sample connection XML containing information about remote resources:

<?xml version="1.0" encoding="utf-8"?> <ResourceCollection PubDate="2009-07-09T17:57:30.323Z" SchemaVersion="1.1" xmlns="http://schemas.microsoft.com/ts/2007/05/tswf"> <Publisher LastUpdated="2009-07-09T17:57:12.588625Z" Name="Remote Desktop Services Default Connection" ID="Contoso" Description=""> <Resources> <Resource ID="60fb077b94a241a473cf982140337213e4d93177" Alias="mspaint" Title="Paint" LastUpdated="2009-07-09T17:57:12.588625Z" Type="RemoteApp" ExecutableName="mspaint.exe"> <Icons> <IconRaw FileType="Ico" FileURL="/RDWeb/Pages/rdp/mspaint032x32.ico" /> <Icon32 Dimensions="32x32" FileType="Png" FileURL="/RDWeb/Pages/rdp/mspaint032x32.png" /> </Icons> <FileExtensions /> <HostingTerminalServers> <HostingTerminalServer> <ResourceFile FileExtension=".rdp" URL="/RDWeb/Pages/rdp/Contoso-mspaint.rdp" /> <TerminalServerRef Ref="Contoso" /> </HostingTerminalServer> </HostingTerminalServers> </Resource> </Resources> <TerminalServers> <TerminalServer ID="Contoso" Name="Contoso" LastUpdated="2009-07-09T17:57:12.588625Z" /> </TerminalServers> </Publisher> </ResourceCollection> .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

The bolded attributes in the connection provide information about the remote resources. The schema file for the connection is located at %windir%\schemas\tsworkspace\tswf.xsd in Windows Server 2008 R2 or on a Window 7 client machine.

Website extensibility: Using the connection to create a new web page

Following is a code sample in C# (ASP.NET) on how to use the connection to create a new web page as demonstrated at PDC 2008. This code sample uses a connection at the “/rdweb/pages/webfeed.aspx” location. Below are the steps that need to complete in creating the new web page.

1. In Page PreInit, check for user authentication. If the user is not authenticated, redirect the request to the login page.
2. In Page Load, get the connection by calling Server.Execute on the webfeed.aspx page.
3. Parse the connection XML to get information on the remote resources. Use this information to present remote resources in your customized way.
4. Replace the default.aspx at %windir%\Web\RDWeb\Pages\en-US folder with this newly created page. This webpage will run inside the RD Web Access web application using an out-of-the box authentication mechanism.

Notes on this sample code:

1. It does not show how to enable RemoteApp and Desktop Connection’s Single Sign On feature.
2. It does not show how to differentiate the page content between the admin and a regular user.
3. It assumes that application locale is en-US.

<%@ Page Language="C#" Debug="false" Trace="false" %> <% @Import Namespace="System.IO" %> <% @Import Namespace="System.Collections.Generic" %> <% @Import Namespace="System.Web.Configuration" %> <% @Import Namespace="System.Xml" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <script language="C#" runat="server"> protected void Page_PreInit(object sender, EventArgs e) { AuthenticationMode eAuthenticationMode = AuthenticationMode.None; AuthenticationSection objAuthenticationSection = ConfigurationManager.GetSection("system.web/authentication") as AuthenticationSection; if (objAuthenticationSection != null) { eAuthenticationMode = objAuthenticationSection.Mode; } if (eAuthenticationMode == AuthenticationMode.Forms) { if (HttpContext.Current.User.Identity.IsAuthenticated == false) { // User is not logged in, so redirect the request to login page. Response.Redirect("login.aspx?ReturnUrl=" + Request.FilePath); } } } protected void Page_Load(object sender, EventArgs e) { try { string connectionXml; // Execute the handler for webfeed.aspx in the context of current request // and capture output connectionXml. using (StringWriter stringWriter = new StringWriter()) { // This new web page is running under the same web application, and // with using existing authentication. // So We need run the Server.Execute to get the connection Xml. HttpContext.Current.Server.Execute("..//webfeed.aspx", stringWriter); connectionXml = stringWriter.ToString(); } // Set current reponse content type Response.ContentType = "text/HTML"; //Strip out the BOM (U+FEFF) connectionXml = connectionXml.Trim(); // Sample code to parse the connection xml. Instead of parsing the connection xml, we can also use XSL transformations directly to display the remote resources List<ConnectionResourceInfo> listConnectionResourceInfos = GetConnectionResourceInfo(connectionXml); dataListResources.DataSource = listConnectionResourceInfos; dataListResources.DataBind(); labelStatus.Text = "Connection Resources : " + listConnectionResourceInfos.Count; } catch (Exception ex) { labelStatus.Text = "Error occurred ~ " + ex.Message; } } private String GetAbsolutePath(string relativePath) { return String.Format("{0}://{1}{2}", Request.Url.Scheme, Request.Url.Host, relativePath); } // Parse the XML file for demo purpose. In this function we are not using all // the xml information available, just the title and resource's image file path. private List<ConnectionResourceInfo> GetConnectionResourceInfo(string connectionXml) { List<ConnectionResourceInfo> listConnectionResourceInfos = new List<ConnectionResourceInfo>(); XmlDocument xmlDocument = new XmlDocument(); // Load the connection xml string xmlDocument.LoadXml(connectionXml); XmlNamespaceManager xmlNamespaceManager = new XmlNamespaceManager(xmlDocument.NameTable); xmlNamespaceManager.AddNamespace("tswf", "http://schemas.microsoft.com/ts/2007/05/tswf"); // Get the list of Resource elements XmlNodeList xmlNodeList = xmlDocument.SelectNodes("/tswf:ResourceCollection/tswf:Publisher/tswf:Resources/tswf:Resource", xmlNamespaceManager); // For each resource get the title and image file relative path for (int i = 0; i < xmlNodeList.Count; i++) { ConnectionResourceInfo connectionResourceInfo = new ConnectionResourceInfo(); connectionResourceInfo.Title = xmlNodeList[i].Attributes["Title"].Value; XmlNode xmlNodeIcon32 = xmlNodeList[i].SelectSingleNode("tswf:Icons/tswf:Icon32", xmlNamespaceManager); // Convert the image's relative path to ablosute path connectionResourceInfo.ImageFilePath = GetAbsolutePath(xmlNodeIcon32.Attributes["FileURL"].Value); listConnectionResourceInfos.Add(connectionResourceInfo); // Here you would want to retrieve any other XML information you // want for each resource from the connection } return listConnectionResourceInfos; } protected void SignOut_Click(object sender, EventArgs e) { //Redirect the request to logoff page Response.Redirect("LogOff.aspx"); } // Entity class to hold connection resource info, for now it contains only the resource title, and its image path private class ConnectionResourceInfo { private string title; private string imageFilePath; public string Title { get { return title; } set { title = value; } } public string ImageFilePath { get { return imageFilePath; } set { imageFilePath = value; } } } .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } </script> <html> <head id="Head1" runat="server"> <meta http-equiv="CONTENT-TYPE" content="TEXT/HTML; CHARSET=UTF-8"> <meta http-equiv="CACHE-CONTROL" content="NO-CACHE"> <meta http-equiv="PRAGMA" content="NO-CACHE" /> <title>New RD Web Access</title> </head> <body> <form id="form1" runat="server"> <div> <asp:Button ID="btnSignOut" runat="server" Text="SignOut" OnClick="SignOut_Click" /> <br /> <asp:Label ID="labelStatus" runat="server" Text=""></asp:Label> <br /> <asp:DataList ID="dataListResources" runat="server" RepeatDirection="Horizontal" RepeatColumns="4" BorderColor="black" CellPadding="1" BorderWidth="1" ItemStyle-BorderWidth="1"> <ItemTemplate> <asp:Image ID="ResImage" ImageUrl='<%# DataBinder.Eval(Container.DataItem, "ImageFilePath") %>' runat="server" /><br /> <%# DataBinder.Eval(Container.DataItem, "Title") %> </ItemTemplate> </asp:DataList> </div> </form> </body> </html> .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

The sample page will appear as below.

Customized client applications: Using the connection to create a new client application

Following is a code sample in C# on how to use the connection to create a client application. This code sample uses the connection at the “/rdweb/feed/webfeed.aspx” location.

1. Send request to the connection URL page with auto-redirect enabled along with user credentials. The connection URL uses cookie-based authentication, so this initial request sent to the connection URL will be redirected to the login page. The login page, which uses Windows-based authentication, responds with the authentication cookie. The supplied user credentials in the request will be used in RemoteApp filtering.
2. Cache the authentication cookie for all subsequent requests. The cookie will not expire, so you can also reuse the same cookie for easy automatic connection updating without prompting the user for credentials.
3. Send the request to the connection URL with the authentication cookie, and get the connection XML in response.
4. Parse the connection XML, and download subsequent resource files and their associated icon and image files.

using System.IO; using System.Net; using System.Web.Security; private void GetConnectionContents() { System.Diagnostics.ConsoleTraceListener trace = new System.Diagnostics.ConsoleTraceListener(); //RemoteApp and Desktop Connections uses HTTPS to connect to the server. //In order to connect properly, the client operating system must trust the SSL certificate of the RD Web Access server. //Also, the server name in the URL must match the one in the server’s SSL certificate // User credentials to access the connection. Fill in <username>, <password>, <domainname> with your user credentials. NetworkCredential networkCredential = new NetworkCredential("<username>", "<password>", "<domainname>"); //This URL will generally be of this form. Fill in <servername> with your server’s name string connectionUrl = "https://<servername>/rdweb/feed/webfeed.aspx"; string formsAuthenticationCookie = GetFormsAuthenticationCookie(connectionUrl, networkCredential, trace); string connectionXml = GetConnectionXml(connectionUrl, formsAuthenticationCookie, trace); //Fill in your code to parse the connection, and to download resource files and associated icon & image files. Use earlier cache cookie for authentication. } private string GetFormsAuthenticationCookie(string connectionUrl, NetworkCredential networkCredential, System.Diagnostics.ConsoleTraceListener trace) { // // Request connection page is protected by Forms Authentication Cookie. So making a request to that page will be redirected to login page // The login page is // trace.Write("Requesting : " + connectionUrl); HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(connectionUrl); CredentialCache credentialCache = new CredentialCache(); credentialCache.Add(new Uri(connectionUrl), "Negotiate", networkCredential); httpWebRequest.Credentials = credentialCache; httpWebRequest.AllowAutoRedirect = true; HttpWebResponse httpWebResponse = (HttpWebResponse)httpWebRequest.GetResponse(); if (httpWebResponse.StatusCode == HttpStatusCode.OK) { trace.Write("Response: 200 "); trace.WriteLine(httpWebResponse.StatusCode); } else { trace.Fail("Response status is " + httpWebResponse.StatusCode + ". Expected was OK"); } trace.WriteLine("Response will be the Forms Authentication Cookie"); trace.WriteLine(""); string formsAuthenticationCookie; using (StreamReader streamReader = new StreamReader(httpWebResponse.GetResponseStream())) { formsAuthenticationCookie = streamReader.ReadToEnd(); streamReader.Close(); } trace.WriteLine("formsAuthenticationCookie " + formsAuthenticationCookie); return formsAuthenticationCookie; } private string GetConnectionXml(string connectionUrl, string formsAuthenticationCookie, System.Diagnostics.ConsoleTraceListener trace) { // // Request connection page // trace.Write("Requesting : " + connectionUrl); HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(connectionUrl); httpWebRequest.CookieContainer = new CookieContainer(); // // Set Froms Authentication Cookie // httpWebRequest.CookieContainer.Add(new Cookie(FormsAuthentication.FormsCookieName, formsAuthenticationCookie, "/", httpWebRequest.RequestUri.Host)); // Get response HttpWebResponse httpWebResponse = (HttpWebResponse)httpWebRequest.GetResponse(); if (httpWebResponse.StatusCode == HttpStatusCode.OK) { trace.Write("Response: 200 "); trace.WriteLine(httpWebResponse.StatusCode); } else { trace.Fail("Response status is " + httpWebResponse.StatusCode + ". Expected was OK"); } trace.WriteLine("Response will be the connectionXml"); trace.WriteLine(""); string connectionXml; using (StreamReader streamReader = new StreamReader(httpWebResponse.GetResponseStream())) { connectionXml = streamReader.ReadToEnd(); } trace.WriteLine("connectionXml " + connectionXml); return connectionXml; } .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

As shown above, RemoteApp and Desktop Connection provides an easy way to customize the standard look and feel of RD Web Access or to present remote resources in new ways.

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

The Windows Server team is running a Haiku contest for Windows Server 2008 R2.  Come up with the best Haiku, and you could win a Home Entertainment System.  See http://www.r2haiku.com/ to enter.

Maybe Remote Desktop Services will provide your inspiration!