TMEdit The Ultimate App-V Package Editor
To Documentation Index
Package Analysis and Fixes
When you open an App-V package, TMEdit will analyze the package for a variety of known possible issues. In many cases, it will also offer an automated fix for the issue. We generally recommend running the Automated fixes before any other editing is done, as your manual changes might interfere with our automated fix. So use the fix buttons first, and then perform additional editing!
The information on this page explains the analysis and fixes that are available. We will add to the capabilities over time.
Shortcut Analysis
Microsoft App-V does not deploy the actual shortcut laid down by the vendor. Instead it captures the idea of the shortcut, and must translate it into a shortcut that it deploys when the package is published. There are a variety of problems we have found with experience, either due to bad installers, errors in the package creation, or issues with how App-V renders the shortcut at the client.
Shortcut name ending in a space
There is a well known software vendor that sometimes creates shortcuts using a name that ends with the space character. While this works for a native installation, App-V will not render a usable shortcut upon publishing. When analysis detects this situation, a fix is offered. The fix consists of removing the offending trailing space from the lnk filename and fixing up the metadata.
Shortcut Target is of filetype CMD or BAT
If a shortcut has a target file that ends with the .CMD or .BAT file extension, the shortcut will not work in App-V. When analysis detects this situation, a fix is offered. The fix consists of making the target be cmd.exe, with arguments consisting of /c followed by the original target file and then any additional arguments.
Shortcut Target is of filetype REG
If a shortcut has a target file that ends with the .REG file extension, the shortcut will not work in App-V. When analysis detects this situation, a fix is offered. The fix consists of making the target be reg.exe, with arguments consisting of /import followed by the original target file..
Shortcut argument has single back-slash
Certain versions of the Sequencer have a bug wherein if a shortcut has an argument that is a UNC share, it drops the first back-slash of the double back-slash. When analysis detects this situation, a fix is offered. The fix consists of adding the missing back-slash.
Shortcut argument has Environment Variable
The App-V 5 sequencer will expand any environment variable found in shortcut arguments (meaning replace the variable name with its value) during package capture. App-V 5 packages created by converting App-V 4 packages (where variables in the arguments are supported) to App-V 5 using the sequencer's package converter do not perform this replacement. We frequently see these packages have a %SFT_SOFTGRIDSERVER% variable as part of a UNC path to locate an external script file. When analysis detects this situation, you are warned. If the variable is defined on the TMEdit machine, an automated fix will also be offered. The fix would expand out the variable for you. Ultimately, you may want to manually change the argument (and relocate that server file) so that things don't break when you decommission that old App-V 4 server!
Application Capabilities Registration for FTA Analysis
Software vendors will often create new File Type Associations (FTAs) or modify existing ones. Originally this created a "last write wins" situation. A long time back Microsoft expanded the registration using what it calls "Application Capabilities Registration". While this registration overs more than just FTAs, it is the FTA registration that is important to have. Unforumently, many (?most?) vendors have not added this registration to their products. With it, we can eliminate "last write wins" and the end-user can easily choose which programs to be the primary for a given file type and other programs appear in the right click menu as choices.
FTA with ProgID but no Registration
When this situation is detected in the Analysis, a fix is offered. The fix will consist of insuring that the ProgID is in the OpenWithProgIDs list and the application capabilities registration is added.
FTA without ProgID or Registration
When this situation is detected in the Analysis, a fix is offered. The fix will consist of creating a new unique ProgID for the file-type, adding the ProgID to the Op.enWithProgIDs list and the application capabilities registration is added.
App Path Registration Analysis
In Windows Vista Microsoft added App Path Registration. And yet few software vendors use it.
App Path for Start Menu Search
In Windows Vista and 7, the start menu included a "Run" box where the user could type in the name of a program to run. In Windows 8 this was moved to the Start Screen and the box renamed to Search. In Windows 10, this capability is accessed by clicking on either the start button or Cortana icon and typing. If there is no registration, the user must type in the full name of the program, and the program must be located in a "well known location" (which means the System32 or Program Files areas). With registration, the item may be found after typing in the first few letters of the name. With registration you can also have aliases (try this by typing "Write" in the start menu search; you end up with WordPad!) for the program name as well. We find end-users using this start menu search function much more often in Windows 10 than they did in 7.
When a primary application (referenced by a shortcut, FTA, or URL Protocol handler) is missing the registration, the analyzer will detect this and offer an automated fix to add the App Path entry for search.
App Path as Replacement for Path Variable Changes
When a program loads dlls, it loads them by filename and not path. Windows looks in the working directory for the process, then checks for an App Path registration AppPath list, and then checks in locations that are in the PATH environment variable. Prior to AppPath, if the vendor wanted to add there own dlls in a separate, private, folder then they would edit the Path variable during installation. Which could break other applications. Placing these additional paths in an AppPath registration instead linked to the executable that needs it prevents this potential conflict.
Also, we have seen changes to the Path variable break some App-V packages in certain versions of App-V.
When the analyzer detects either situation, it will offer an automated fix to create the appropriate Application Capabilities registration and remove the Path variable change.
Group Policy Object Analysis
For years, the App-V sequencer prevented the capture of group policy object keys, and the client ignored them. This meant that you could depend upon policies deployed externally by GPO to work. One day, without notice, Microsoft changed both of those things. We eventually noticed some externally deployed GPOs not working because those captured inside the package win.
The analyzer will detect if any policies are captured and offer a fix to remove them from the package. You will need to consider whether or not to remove them from the package. If the installer was adding them locally rather than going through normal Group Policy distribution, you might not have a GPO defined for this.
Windows Installer Cache File Anaysis
MSI based installers usually leave a lot of files in the Windows Installer folder. Usually, this is to allow self-repair of the application. Self-repair doesn't work in App-V 5. If attempted, the error that self-repair generates is confusing to both the end-user and help desk, so it is better to just let the application fail normally. These files also add significantly to the size of your App-V Package.
But blindly removing the files will also break things.
When files are detected in the installer cache, an analysis is made of the files looking for references to each file. Currently we are looking for references in shortcuts, file type associations, url protocol handlers, and font registrations. When applicable, an automated fix button is provided that will remove the unnecessary files.
VC Runtime Analysis
An analysis of VC++ runtimes is performed, both for known vulnerabilities and for those published externally by the client. We can't automate the fix for known vulnerabilities, but we can disable the publishing, and an automated fix is provided to do so should you require this.
Service Account Analysis
An analysis of Windows Services in the virtual registry is done looking for services that do not use the LocalSystem account. App-V ignores these services as the virtual services must run under the local system account.
If the analysis finds this situation, it will be listed in the informational section of the Package Analysis and Fixes. There is a chance that you can manually edit the virtual service in TMEdit and change the service account to "Local System" and the application will function properly. Some vendors incorrectly specify built-in accounts like Network System simply because the sample MSDN code they found used it and they didn't know any better. At this time, we have chosen not to automate this fix because if you make this change a significant amount of testing should be done to confirm that it doesn't break the application.
Office Plug-In Analysis
While there are no automated fixes, the analyzer will alert you if any plug-ins to Microsoft office are detected in the package. This is not only good as a heads up for your testing efforts, it serves as a reminder to check the mergewithlocal/overridelocal settings of the registration key. We'll point out what the setting is, but it is up to you to decide if you want to hide locally installed plugins or not.
MSIX Analysis
While we cannot analyze runtime issues, we can tell you quite a lot about issues you are likely to face should you decide to repackage this app into MSIX in the future. This are will tell you about known issues and potential ways to fix them. The output also shows differences between what OS that you deploy to that might affect the results.