Hi all,

I have a win2k3 terminal server with a range of traditionally installed applications and APP-V client on it to provide some applications which are incompatible with the build. I am trying to install a 3rd party app in the traditional way which via a packed MSI (when monitoring with procmon) tries to write *.tmp files to the Q: drive which is inaccessible outside of an APP-V bubble and so hangs. I was wondering if there was a way to resolve this easily that does not include re-packing the app or uninstalling APP-V. Is there a way to have the MSI ignore the fact that the Q drive exists?

Many Thanks indeed.
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


Have you tried setting ROOTDRIVE=C:\ on the command line for the MSI ?
Might be worth a try.
Strange that its writing tmp files there, where is yor %TEMP% folder pointed to ?
Answered 11/04/2010 by: Jon_Kidd
Orange Senior Belt

Please log in to comment
As much as I have identified that the MSI is the culprit it is packaged within an EXE which does more than just carry the MSI so installing the MSI in isolation with command line switches is not an option.

All system and user variables are normal as far as I can see, certainly nothing pointing at Q:.

Thanks for the reply.
Answered 11/04/2010 by: listless
Yellow Belt

Please log in to comment
Are you installing to the Q:\ mountpoint - are you telling your MSI installer to install to Q:\<path>?

Have you tried installing as a VFS? Start your monitoring and install the application as normal to the default location (usually on C:\) - the App-V sequencer will do the rest and create the virtual file system.

..APP-V client on it to provide some applications which are incompatible with the build

This bit is a concern - if an application won't work on your target OS as a native install, it won't work virtualised either. One of the main benefits of App-V is to 'bubble off' applications that may not co-exist together, but OS compatibility issues aren't generally resolved by App-V.

Although saying that there are various shims that could be utilised to 'fool' the virtualised application into working.

Hope that helps,

Answered 11/05/2010 by: dunnpy
Red Belt

Please log in to comment