Traditional MSI trying (and failing) to extract to Q: (APP-V) drive.
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.
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
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
Jon_Kidd
13 years ago
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 ?
Might be worth a try.
Strange that its writing tmp files there, where is yor %TEMP% folder pointed to ?
Posted by:
listless
13 years ago
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.
All system and user variables are normal as far as I can see, certainly nothing pointing at Q:.
Thanks for the reply.
Posted by:
dunnpy
13 years ago
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.
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,
Dunnpy
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,
Dunnpy
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.