CM 2012 Software Center Error 0x87D00324 and App-V Detection Methods

Generally when deploying App-V 4.x packages with CM 2012 the publishing is one thing you don't worry about because the information harvested from the package is often sufficient. The problem is that I've found one instance where this can be broken, for example I have a package for HP Quality Center that delivers to the users machine but then the installation is marked as failed. If I look closer in Software Center I have an error 0x87D00324 as shown below.

The Internet suggests that this is a detection method error but this shouldn't be happening with an App-V package. In order to get a better idea of what is going on I decided to load up CMTrace.exe and merge a few CM client logs to get a better idea of what is going on. More specifically in the File -> Open dialogue I selected the Merge selected files checkbox then selected the AppDiscovery.log, AppEnforce.log, AppIntentEval,log and the VirtualApp.log files.

Below in CMTrace you can see the App-V sequence being installed but no errors.

As I went further info the logs I finally spot an indication that there is a problem. I've highlighted in the red box the App-V detection method being marked as failed.

This is where things get interesting because you have to manually validate a few things to find out the cause of the detection failure.  Unfortunately in this case the logs don't identify what detection method failed so I had to do some digging around to find out how App-V detection methods work. According to this Whitepaper CM 2012 checks to make sure that the App-V package and upgrade GUIDs match what is in the App-V client and that all shortcuts are published.

Checking the package and upgrade GUIDs is fairly straight forward, the first thing you want to do is open the _manifest.xml file for your App-V package. The second line of the package should have both the package GUID and the version GUID as shown below.

The next step is to check what is loaded on the client. Open the App-V client MMC in Administrative Tools, right click one of the shortcuts for the application and select Properties.

A window will pop up, select the Package tab and you should see at a minimum the package's GUID but you might not see the version GUID for the package.

If you don't see the version GUID it means the App-V package is not in the client cache. In this instance the package was set to stream from the distribution point rather than download and execute the package. To get the version GUID I launched the application forcing it into the  App-V client cache then refreshed the Applications node in the App-V client MMC. Now when you check the properties of the shortcut the package properties should match the values in the _manifest.xml.

Unfortunately this only proves that these detection methods are accurate and there must be a problem with the shortcuts for the application. It took some work but what was frustrating was that both shortcuts existed but of course the truth is in the details. The disconnect in this case was that the packager edited the shortcut names in one of the OSD files but did not make sure the shortcut name matched in the _manifest.XML. This means that the App-V client is loads the package via CM 2012 using the _manfiest.XML file but does not load the application  names from this file, it gets the application name from the OSD file (not the display name). This means the display name for the shortcut looks correct in the _manifest.xml.

And the Start Menu checks out with the same name as well.

If I go back to the App-V client MMC we start to see where the problem is, it looks to be the application name.

And if I go to the OSD file for the shortcut / application we can see the different name.

To be more specific this is the disconnect.

• XML: HP-ALM-Explorer 11
• OSD: HP ALM Explorer 11

In order to fix this scenario there are two solutions. Either change the NAME field in the _manifest.xml to be HP ALM Explorer 11 or change the NAME and DISPLAY fields in the OSD to be HP-ALM-Explorer 11. The deployment type will need its content updated and the deployment will have to be rerun on clients with the sequence previously loaded for the issue to clear up.