locked
App-V 4.6 MSI deployment RRS feed

  • Question

  • I am using App-V 4.6 (the actual released versions, not the RC) to sequence applications into an MSI package, which I will then run on my workstations (probably using Novell ZENworks, or possibly just a link to a file share). I have followed the instructions in the "Microsoft application virtualization 4.5 standalone trial guide ".

    After sequencing, if I copy the MSI, SFT and everthing else to any location on the C: drive on the workstation where it is to be installed, and run the MSI, everything works fine. The virtual application installs and runs as expected.

    If I try to run the application from a file share e.g. L:\appv\application, then a few seconds after running the MSI, I receive the error message "The system cannot find the file specified 4605F3-14200C2A-00000003". The app-v error log (set to verbose) reads "The application virtualization client could not connect to stream URL File://L:\\app-v\application.sft".

    The MSI, SFT and all other files are present on the L: drive share, identical to the copy I have made on the local C: drive (from which the install works OK). I have also tried running the MSI from the command line and specifiying the location of the SFT file. I have also tried re-sequencing the application and telling it to use file share path rather than RTSP path. I still get the same error no matter what I do.

    The workstation is using Novell client to connect to the L: drive, so I was wondering if there was some sort of issue between App-V client and Novell client? Also, I thought that maybe the command line options for running the MSI and specifying the SFT location might be fussy about the syntax, and maybe I'm not specifying it correctly? I have read conflicting information as to the correct settings for app-v client in this mode i.e. allowindependentstreaming, network/online,  etc - if someone could confirm the correct settings this would be helpful.

    Any advice would be much appreciated.
    Monday, March 1, 2010 10:30 AM

Answers

  • Hello,

    The user account is not the computer account.
    The user account is your own credentials and context, whereas the Windows Installer engine is running in a different set of credentials and context (ergo, computer account).

    /Znack
    Monday, March 1, 2010 11:43 AM
  • Talking "windows", you'd have to give the <Domain>\<Computername>$ read access to the file share, but I don't know how that has to be handled in a Novell environment.
    You may refer to other aaplications/services that run underr the "Network Service" account and access Novell shares (maybe you have a web or FTP server that stores its files on a Novell share and the you could how that share is configured).

    An alternative of course would be to copy/install/delete the files using ZENworks, wouldn't it?

    Or you re-configure your clients not to use "Stand alone Mode" but rather "stream" the SFT from a file server. This "streaming" download then would be performed using the USER account.



    Falko
    Monday, March 1, 2010 2:27 PM
    Moderator

All replies

  • Hello,

    The computer must have read access to the L: drive and the share its mapped to.

    /Znack
    Monday, March 1, 2010 11:12 AM
  • Thanks for the reply. The USER account logged on at the client workstation has full access to the L: drive and share, and can view and change anything in the L: drive.  Is that what you mean? The L: drive share is on a Novell server, so there is no concept of domain membership of the client COMPUTER and client COMPUTER account rights to the share. The client computer is effectively standalone, running Novell client to connect to the share.
    Monday, March 1, 2010 11:31 AM
  • Hello,

    The user account is not the computer account.
    The user account is your own credentials and context, whereas the Windows Installer engine is running in a different set of credentials and context (ergo, computer account).

    /Znack
    Monday, March 1, 2010 11:43 AM
  • Talking "windows", you'd have to give the <Domain>\<Computername>$ read access to the file share, but I don't know how that has to be handled in a Novell environment.
    You may refer to other aaplications/services that run underr the "Network Service" account and access Novell shares (maybe you have a web or FTP server that stores its files on a Novell share and the you could how that share is configured).

    An alternative of course would be to copy/install/delete the files using ZENworks, wouldn't it?

    Or you re-configure your clients not to use "Stand alone Mode" but rather "stream" the SFT from a file server. This "streaming" download then would be performed using the USER account.



    Falko
    Monday, March 1, 2010 2:27 PM
    Moderator
  • Thanks znack and kirn_tn

    After some messing about getting my command line to access the correct SFT file, I then started getting "access denied" errors instead. I did some more searching on access denied. If you look at the following URL:

    http://appvirtguru.com/viewtopic.php?p=12199&sid=97cd5e9419993af635102607923e8914

    and then look at the comments, the last comment is:

    by kirk » Tue Nov 24, 2009 10:56 am
    Are you trying to "install" the app from a remote share? If so, that doesn't work: you have to copy the MSI and the SFT locally to the client (into the same folder) and launch the MSI locally.
    Basically, the App-V client uses the SYSTEM account when trying to access the SFT - and if that's on a network share, access will be denied
    Falko


    This person suggests that what I am trying to do is impossible i.e. I need to copy the MSI, SFT etc to a local drive first and then run it. If that's the case I guess I either use SFTMIME commands to stream the SFT as you suggest or use Novell ZENWorks to copy the MSI/SFT first before running the MSI.

    Thanks again for your assistance.
    Tuesday, March 2, 2010 3:55 PM


  • I got snooping around in the MSI to see if it could be fixed and came up with a way to deploy packages to the stand-alone client without copying to the local drive first.

    Also fixed the lack of proper rollback of app-v deployment MSIs - they usually leave the impression that the package is fully installed but fail to launch.

    Put the results together as transforms that you can apply during deployment or permanently to the sequencer template MSI.

    See http://csi-windows.com/toolkit/appv-msi-fixups for more details about the problems, how to fix them and downloadable files so you don't have to do the hard work yourself!

    Fyi,
    Darwin.
    Thursday, July 15, 2010 6:43 PM