App-V 4.6* and the case of the bad URL

When we sequence a package, the sequencer goes to great lengths to translate hard coded paths and your user ID into pseudo variables in the output package. The client then re-translates them dynamically to what is appropriate.

Of course, one of the things that the sequencer will map is the reference to the virtual drive, as in “Q:”. Since there isn’t a CSIDL for this, Microsoft uses %SFT_MNT% for the intermediate form to store.

But it has been beaten into our heads over the years that it is important to have ALL of the App-V clients use the same drive letter as the one we sequence on to improve application compatibility and consistency. I usually describe the reason for this need as being apps that hide file references in places that App-V doesn’t look (like a .dat file).

But there is this other case where the translation can generate a problem, and this is what we found when the app would not launch.

These translations also apply to command line parameters that you catch in the OSD. In our case, the “command” was to run iexplore.exe with an “https://server/path/file.html” parameter.

But it was sequenced on a machine with S: as the virtual drive letter. So the OSD reference had a parameter “http%SFT_MNT%//server/path/file.html”.

This is OK, when the client is also using “S:” for the virtual drive, as the client translates back the original form. But not when you drop it on a client with a different drive letter. Drop it on a lab client machine using “Q:”, and the translation reads “httpq://server/path/file.html”, which of course will not be found.

PS: The same problem should occur if you standardized on the “P:” drive.