Application Compatibility Best Practices for Remote Desktop Services Introduction Remote Desktop Services in Windows Server 2008 R2 allows Windows Server to be accessed by multiple users concurrently to provide application and data hosting services by using Microsoft s presentation virtualization technology. While most 32- bit and 64- bit applications run as is on a Remote Desktop Session Host (RD Session Host) server, some do not perform as expected because of the special characteristics of the remote environment (that is, applications may be accessed concurrently by many users). The Remote Desktop Services application compatibility effort aims to make it easier for developers to create software that runs reliably on the Remote Desktop Services platform. Centralized deployment of an application by using Remote Desktop Services has many advantages over traditional deployment, including a lower cost of ownership. However, be aware of the special demands of this platform so that you can design and deploy your applications more effectively. For more information about the Remote Desktop Services platform, visit the Remote Desktop Services Product Evaluation site (Microsoft.com) and the Remote Desktop Services TechCenter (TechNet). Overview of application compatibility issues in Remote Desktop Services This document highlights some of the common application compatibility issues with Remote Desktop Services. For more information about the best practices for developing applications for Remote Desktop Services, see the Remote Desktop Services Programming Guidelines (MSDN). Application installation Most applications are designed for a single user client system which causes problems when installing them on an Remote Desktop Session Host (RD Session Host) server. Usually the installation does not create files and registry entries in a place that can be read by other user accounts who are logging on to the computer. Concurrent usage of applications Files, registry entries, pipes, IP addresses, and ports are used concurrently by multiple instances of applications when installed on an RD Session Host server. If an application is not designed to take care of such concurrent access/modification scenarios, it might face compatibility issues. Concurrent modification of these resources leads to data corruption and other unexpected behavior.
User data privacy in a multi- user environment Having your application in a multi- user environment makes it vulnerable to privacy breaches and unexpected sharing of data and user preferences. Performance Virtual desktops or sessions running on an RD Session Host server work over networks where multiple users may log on to a computer running Windows Server. When network bandwidth or hardware is a constraint, performance may become a bottleneck for applications. Remote devices in a Remote Desktop Services environment While an RD Session Host server redirects the Clipboard, printers, and drives to allow seamless integration from the client to the server, several features and devices might not be available over a remote session. Ensuring application readiness for Remote Desktop Services To develop applications that will run reliably on an RD Session Host server, you should give careful consideration to these application compatibility issues. Each of these potential trouble spots is discussed below along with mitigations and solutions. The mitigations and solutions incorporate best practices for use on an RD Session Host server. Many of these apply to the Fast User Switching environment as well, and should help improve the quality and reliability of your application. Application installation: Issues During installation, applications create various registry entries, folders, and files. Usually, the application files are created in the Program files folder and the registry entries are created in the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER hives. User data files and application shortcuts are created within the User Profile folder (%userprofile%) and ProgramData folder. Most application installations are designed for a single- user client system, which could cause problems when installing an application on an RD Session Host server. We can broadly divide the installation into two parts: 1. System- specific: Copying files, libraries, and other dependencies that are common to all users of that application 2. User- specific: Creating data files, registry entries, and shortcuts for a particular user Most of the problems specific to Remote Desktop Services occur because of user- specific deployment: Writing to the installing user s file and registry stores: o Any registry entries made in the HKEY_CURRENT_USER registry hive at installation are available only to the user installing the software. When another user tries to use that application, these registry entries are not available to that user.
o Similarly, any data files created within the installing user s profile would not be available when the application is executed by another user. Writing to common and system- wide registries and file stores: Any data files or registry entries created in common locations can be accessed by all users and are potentially vulnerable to concurrent access and modification; this can corrupt the data, lead to breach of user privacy, and other unexpected behavior. o Similarly, shortcuts and other resources would also not be available for other users if they are created just for the installing user. o Files and registry entries stored in locations that need privileged access can cause problems when they are used by a non- administrative user. Application installation: Mitigations and solutions While user- specific files and registry entries must be created in the user s hive, the application should not do this at the time of installation because these files and registries will consequently be available only to the installing user. The application should do this after installation. Application installation can be broken into two parts: 1. Installation activities: The application should create all common application files, libraries, and registry entries at installation. a. The application should not create files and registry entries that contain user- specific data that is not needed by other users at this stage. b. An exception to 1.a is database and repository stores that are explicitly designed to handle concurrent users and feature mechanisms, such as data locking, isolation, and encryption. c. 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.). d. We recommend, but don t require, that the administrator be allowed to determine if the given installation should be for all users or a given set of users. This preference should be respected at run- time and the post- installation activities should be tuned accordingly. 2. Post- installation activities: The application should create all user- specific data files and registry entries after installation. This can usually be triggered when a user logs on, or on the first run of the application. a. Common scripts and definitions created after installation can be stored in the common and public files as discussed above. b. These scripts can be executed on the 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. Concurrent usage of applications: Issues System resources such as files, registry entries, pipes, IP addresses, and ports are used concurrently by multiple instances of applications that are installed on an RD Session Host server. If an application is not designed to take care of such concurrent access and modification scenarios, it might face compatibility issues whe installed on an RD Session Host server. Concurrent modification of these resources leads to data corruption and other unexpected behavior.
Concurrent usage of applications: Mitigations and solutions After the basic design of the application is governed by the installation recommendations, it is easier to manage concurrent usage of the application, because all users write and modify data only in their own stores. The following are some generic recommendations for applications in a concurrent user environment: All data files must be isolated per user, either by using different files for every user or by enforcing locking and exclusive writing as per application scenarios. Common application files (non- data files) should never be locked by one instance of the application, as that would interfere with other users usage of the application. 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. User data privacy in a multi- user environment: Issues Applications installed on an RD Session Host server are vulnerable to privacy breaches and unexpected sharing of data and user preferences. It is not uncommon to see applications persisting or manifesting user preferences from one user to another. Applications that save preferences and data in a common (non- user specific) location often experience unwanted behavior on an RD Session Host server, such as one user s settings taking affect for another user, and one user being able to see another user s data. User data privacy in a multi- user environment: Mitigations and solutions Applications should maintain all user- specific data and application settings within the user profile (%userprofile%). We recommend using %userprofile% and HKEY_CURRENT_USER as the data stores. Depending on your application deployment requirements, you may need to design for roaming users (users who can log on from different computers at different times) to ensure that the user data is maintained across roaming locations. For more information about maintaining roaming user profiles, see the Managing Roaming User Data Deployment Guide (TechNet). Performance: Issues RD Session Host sessions work over networks where multiple users log on to a Windows Server over a network. When network bandwidth or hardware is a constraint, application performance may suffer. 1. Because Remote Desktop Services is a presentation virtualization platform, it transmits information about the display and graphical output and I/O over the network. This makes the graphical performance dependent on the network bandwidth. 2. High- bandwidth video and animation content may overwhelm the network and reduce the response time of the RD Session Host session. This may result in skipped display frames, flickering video display, and lag in I/O.
3. The slow speed of the network (relative to, for example, a desktop graphical system where display content is transmitted from the graphics card to the display device directly), can cause a general lag in display updates. Performance may be visibly affected on dial- up connections and other slow networks. 4. Using video memory (off- screen video buffers) to cache display content results in unnecessary network traffic. Similarly, applications that require a lot of CPU time (real- time applications) or memory may monopolize the resources of a server running the RD Session Host role service, resulting in poor user experiences. Performance: Mitigations and solutions It is important to optimize your applications to consume minimal system resources because these resources are shared across multiple users on an RD Session Host server. 1. It is a good practice to turn off any non- essential videos and animations over an RD Session Host session. 2. The application should not use off- screen or other video buffers for storing data or for computation. It is better to store any such data in RAM and only transmit actual display content to the video buffers and display device. 3. Disk and network I/O are usually the slowest operations and these should be used optimally on an RD Session Host server. The application should not unnecessarily use memory because doing so could cause virtual memory paging and thus disk I/O. Also, caching to disk can become a bottleneck when multiple users are sharing the same disk for various applications. Moreover, the application must not send data packets over the network when tasks can be completed in memory locally at the server. For more information about detecting the Remote Desktop Services environment to enforce conditional behavior over a Remote Desktop Services session, see Detecting the Remote Desktop Services Environment (MSDN). Remote devices in a Remote Desktop Services environment: Issues Virtual desktops and RD Session Host sessions provide redirection of devices, such as printers, drives, and the Clipboard, to allow applications to access client resources seamlessly. While virtual desktops and RD Session Host sessions support redirection of most commonly used devices and enables our partners to add support for other devices, it is possible that some devices needed by an application might not be redirected. The following are not redirected: CD drives, hard disk drives, and other special devices that are not available as native devices. Operations, such as burning CDs or disk defragmentation, do not work over with an RD Session Host session. Similarly any native operations that require native device access do not work unless the device has drivers for Remote Desktop Services. Remote devices in a Remote Desktop Services environment: Mitigations and solutions Applications targeted for Remote Desktop Services should not have critical dependencies on direct access to devices via native drivers. Microsoft provides some devices with native support for Remote
Desktop Services, and partners can develop and support other devices by developing Remote Desktop Services- aware drivers that use virtual channels. For more information about virtual channels, see Using Remote Desktop Services Virtual Channels (MSDN). Introducing the Remote Desktop Services Application Analyzer Remote Desktop Services Application Analyzer is a runtime program analysis tool that enables administrators and users to determine the compatibility of an application with an RD Session Host server before deploying it. The tool provides a summary of incompatible behavior between the RD Session Host server and an application, and provides recommendations for deploying the application on an RD Session Host server. The Remote Desktop Services Application Analyzer uses the Microsoft Application Verifier as the backend. When you analyze an application, the tool intercepts function calls from that application into the operating system, and notes the calls and the parameters passed. Depending on the function call and the parameters passed, it decides whether this call is going to cause problems on an RD Session Host server and categorizes the results as warnings or problems. Following are the classes of application compatibility issues that are being targeted for detection: 1. Shared resources, such as files and registry entries 2. Access or privilege issues 3. Windows API calls, with special cases for Remote Desktop Services The Remote Desktop Services Application Analyzer: 1. Enables administrators to analyze test runs on the given binary. 2. Decides whether the binary will face any problems when deployed on an RD Session Host server. If yes, finds out the type of problem and its severity. 3. Presents this information in a readable format and summarizes the results along with a recommendation. 4. Enables the results to be exported and analyzed or viewed at some other computer. 5. Can be deployed on a set of user computers or test computers (running the client operating system or the Windows Server operating system) seamlessly. The results can be gathered at the administrator s computer. The administrator goes through the results on all the computers and then makes a decision as to whether the application can be deployed on an RD Session Host server. Using the tool and interpreting the results Keep the following in mind when using the Remote Desktop Services Application Analyzer: 1. This tool primarily focuses on issues relating to concurrent usage and privacy (due to a multi- user environment). The potential problems it highlights may not always manifest. Understanding this is critical to correctly interpreting and effectively using the results. That an application generates no errors does not mean, for example, that it is not resource- hungry.
2. Second, the problems that the Remote Desktop Services Application Analyzer identifies are not necessarily deal- breakers. This tool breaks down issues into several categories by issue type such as File or Registry. The tool also breaks down the issues into two severity levels: Warnings and Problems. Most of the time you should focus on the problems unless you are actually trying to pinpoint a problem source (which a developer or tester might do). It is important to understand that when the Remote Desktop Services Application Analyzer identifies a problem, the tool has detected that the application has made an API call that is not compatible with RD Session Host, but this call itself can be a part of a condition in the application. For example, it can say, Try to open this file as an administrator, but if you can t, then just open it as a normal user. The Remote Desktop Services Application Analyzer would still see that the application tried to open a file as an Administrator and it would flag a problem. The key point is that just because something shows up as a problem, it still requires interpretation to determine if it s a real problem. If you are a developer and want to develop your application to be compatible with Remote Desktop Services, you can use the tool as a guideline. For a detailed programming reference, see the Remote Desktop Services developer documentation (MSDN). Resources Installing Remote Desktop Session Host Step- by- Step Guide (Download Center) Remote Desktop Services Programming Guidelines (MSDN) Remote Desktop Services (TechNet) Remote Desktop Services product homepage (Microsoft.com) Managing Roaming User Data Deployment Guide (TechNet) Detecting the Remote Desktop Services Environment (MSDN) Using Remote Desktop Services Virtual Channels (MSDN) Published October 2009. 2009 Microsoft Corporation. All rights reserved.