AppDNA provides information about compatibility issues that have been detected in applications. In AppDNA, the term remediation refers to the process of resolving these issues by making changes to applications or the environment so that the applications work on the target platform.
Remediation reports provide detailed remediation information for a specific application. Sometimes more than one alternative approach is provided. The remediation reports also provide details of the application components that are affected by each issue.
There are two remediation report views for desktop applications and three for web applications:
- Remediation Issues – Provides a breakdown of the issues identified by the algorithms and information about the affected components.
- Remediation Actions – Provides a breakdown of the number and type of actions required to remediate the application.
- Site Map – (Web applications only.) Provides a summary of the pages, objects, scripts, and style sheets, that the AppDNA directed spider visited, skipped, or failed to capture.
To open a Remediation report:
Click Reports: Applications and then click the name of a report, such as Windows 8/8.1, to expand the list of report views.
To view Remediation Issues, click Application Issues and then click an application link in the report.
To view Remediation Actions, click Application Actions and then click an application link in the report.
To swap between views, click the Switch to link at the top of the report.
For desktop applications for which AppDNA provides an automatic fix, you can download the fix in the form of an .mst file that contain modifications that can be applied to the application’s .msi file during installation to correct issues. Click the Get MST fixes button to download the fix.
You can optionally merge remediation report views for multiple standard reports (not custom reports). For example, you can merge the results for the Windows 8 and App-V reports. To do this:
- On the Export toolbar, click Merge report.
- Select the other report or reports that you want to merge with the current one, and click View merged report.
If relevant to the report, the currently selected OS Images are shown at the top of the screen. To change the selection, click Change images on the Export toolbar.
Detail – Shows the application’s name, manufacturer, version, installation file, package type, standard RAG status, and the date the remediation report view was generated.
Journal – If the application has any external data or manual journal entries, they are shown in this section. If AppDNA has matched the application with an entry in one of the PCA (shim) database external data sources, this section shows the matching executable (.exe) file(s) and, when relevant, the name of the shim(s). You can click Accept to convert an external data entry into a standard journal entry. This means that the application’s RAG status will be overridden by the corresponding compatibility (journal) status.
The remaining details are different in the Issue view and the Action view.
For the Issue view, there is a list of the algorithms that the application has triggered. For each algorithm, the report shows the module and report name, along with the algorithm and algorithm group, the standard RAG, and the number of times the application has triggered the algorithm. The algorithm name is a link that takes you straight to the detailed information about the algorithm below.
The detailed information about each algorithm shows the description of the group, the manifestation of the problem identified by the algorithm, an explanation of the remediation, and a list of the application’s components that triggered the algorithm. These details vary depending on the algorithm.
For the Action view, there is a list of the actions that need to be implemented to fix the issues that the algorithms have uncovered. For each action and action detail combination, the report shows the effort involved, the after action RAG, and the number of issues that need to be addressed. The action detail is a link that takes you straight to the detailed information about it below. This shows details about each algorithm to which the action applies, including the description of the algorithm group, the manifestation of the problem identified by the algorithm, an explanation of the remediation, and a list of the application’s components that triggered the algorithm. These details vary depending on the algorithm.
Tip: Use the Report Export Wizard to export remediation reports for multiple applications.
Standard remediation actions
Remediation reports list the remediation actions and action details for each application. Here are example remediation actions that a report can include:
- Additional testing is required:
- Application requires functionality testing
- Assess application security risk
- Driver compatibility test required
- Verify application publisher is trustworthy
- Additional XenApp testing required
- Apply Shim
- Change Group Policy
- Change hardware
- Change operating system build:
- Add certificate trusted list
- Add non-supported component to OS
- Add redistributable to OS
- Run application on 64-bit OS
- Change software
- Deploy using a desktop virtualization technology
- Deploy using an application virtualization technology
- Edit OSD file
- Modifications are required in the App-v Management Console:
- Create global FTAs
- Select one application to be FTA provider, change the other application’s verb
- Redevelopment required
- Repackage application:
- Create a Merge Module for shared resource
- Edit the script file called by the MSI
- Provide the missing resource or install a redistributable
- Rename the setup to Setup.EXE
- Sequencing steps need to be followed:
- Add placeholders in INI files
- Configure environment variable changes
- Include missing files in the sequence
- Publish shortcuts in the Start Menu’s startup folder
- Sequence application with its required service
- Use App-V 5.0
To view the actions for each algorithm available for a report, go to Configure > Modules > Module > Report Name.
What do the green algorithms tell you?
Some of the algorithms built into the AppDNA reports have a green RAG status. Generally, a green RAG status means that the application is ready for user acceptance testing (UAT) on the target platform. However, these algorithms can be broken down into several groups:
- Some algorithms have a green RAG status because they detect an issue that typically only becomes a problem in certain circumstances. If those circumstances apply in your environment, you may want to configure the custom RAG status to amber. For example, the Windows 7 W7_VDEPNX_001 algorithm detects an issue that is relevant only when Data Execution Prevention (DEP) is enabled. This algorithm has a green RAG status because by default DEP is off for general applications. If DEP is enabled in your environment, you may therefore want to change this algorithm’s custom RAG status and default action. See Configure algorithms for step-by-step instructions.
- Some algorithms detect things that contradict generally accepted best practice but that do not typically have a compatibility impact. These algorithms therefore have a green RAG status. However, they provide useful information when you are considering which applications to retire, for example. Similarly, if you need to redevelop the application to resolve another issue, you may want to address the best practice issue at the same time.
- Other algorithms have a green RAG status because they detect an issue that only rarely causes a problem. These algorithms provide useful information if after addressing all of the issues identified by the amber and red algorithms, you find the application still has issues.