I encountered an issue when trying to load balance and publish the App-V 5.0 web services behind an F5 hardware appliance. The design and fix below will also apply to other methods of load balancing and publishing if a wildcard certificate is involved.

Design

The App-V content is stored on a redundant file share published by an IIS Virtual Directory.

network layout

Example:

\\san.internal\appv5\AppV5_7-zip_9.20_x64\AppV5_7-zip_9.20_x64.appv ->
https: //srv-appv-1.internal/applications/AppV5_7-zip_9.20_x64/AppV5_7-zip_9.20_x64.appv

Published as:

https: //appv.domain.com/Applications/AppV5_7-zip_9.20_x64/AppV5_7-zip_9.20_x64.appv

Internally, the servers are using certificates signed by the internal CA. Externally, the F5 load balancer is publishing the servers with a wildcard (*.domain.com) certificate.

Problem

When browsing to the internal servers directly, everything worked great. Trying to add packages to the Management Console using the external URL however, became a problem.

Digging in the event log showed a "Content Decoding Failed" error. After checking with a few people at Microsoft, this error seems to be related to certificate problems. Specifically if using a wildcard certificate. Turns out the Management Console doesn't like importing packages from a webserver published with a wildcard certificate.

Solution

The solution is simple! Adding a single line to the hosts file of each App-V 5.0 Publishing Server solves the problem.

127.0.0.1    appv.domain.com

Note: Don't forget to add the external domain name as a SAN to the certificate or this method will not work.

When the Management Service connects to the URL to verify the files, it will connect to itself rather than the load-balancer; using the internally signed (non-wildcard) certificate.

Bonus: The App-V 5.0 client (and PowerShell cmdlets) work perfectly fine with the wildcard cert and load-balanced configuration.


//jourdant