IMPORTANT:
Thank you for visiting the Remote Desktop Services blog on the RDS Application Compatibility Analyzer. Unfortunately we no longer support the RDS Application Compatibility Analyzer tool. If you need help determining if your application will be compatible with Remote Desktop Products, please send email to RDS & TS forum and we’ll be happy to assist.
UPDATE: The new Application Compatibility Assessment is here: http://blogs.msdn.com/b/rds/archive/2011/07/06/free-rds-application-assessment-program-by-chang...
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:
- Install the RDS Application Compatibility Analyzer
- Run an application in the RDS Application Compatibility Analyzer
- Test an application for RDS compliance
- Debug info and blog feeds
- Filter noise, detailed stack trace, and logging
- Interpret RDS Application Compatibility Analyzer logs
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 AnalyzerA. 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 complianceWhen 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 feedsDebug 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>(REGISTRYMACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet 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 logsThe 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 BuiltinAdministrators 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. |