/build/static/layout/Breadcrumb_cap_w.png

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.

0 Comments   [ + ] Show comments

Answers (3)

Posted by: Jon_Kidd 12 years ago
Orange Senior Belt
0
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 ?
Posted by: listless 12 years ago
Yellow Belt
0
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.
Posted by: dunnpy 12 years ago
Red Belt
0
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,

Dunnpy
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ