none
App-v 5 and Office2013 Volume Licence Edition - package fails to install with script error

    Question

  • We have used the MS Office Depolyment Tool for click-to-run to download the latest Office 365 version, and flatten it into an app-v 5 package - not a problem.

    When we try to add the package to our client machine (running the app-v 5 SP2 client software), it fails with an message that a script has failed and not returned a 0 code.  We have not added any scripting to this automatically created package, so it seems that the app-v client does not like the "official" package.  Any hints and tips gratefully accepted, thanks

    The powershell command line we are using is:

    PS C:\windows\system32> Set-ExecutionPolicy Unrestricted
    PS C:\windows\system32> Add-AppvClientPackage -path file://hostname/app-v/o365-noaccess/ProPlusVolume_en-us_zh-cn_x86.appv -DynamicDeploymentConfiguration \
    \hostname\app-v\O365-NoAccess\ProPlusVolume_en-us_zh-cn_x86_DeploymentConfig.xml

    with a result of:

    Add-AppvClientPackage : Embedded Script process exited with an error code indicating failure (return code other than 0). Please ensure that Embedded
    Script process can complete successfully and exits with 0.
    Operation attempted: Configure AppV Package.
    AppV Error Code: 100000000C.
    Please consult AppV Client Event Log for more details.
    At line:1 char:1
    + Add-AppvClientPackage -path
    file://hostname/app-v/o365-noaccess/ProPlusVolum ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~
        + CategoryInfo          : InvalidResult: (:) [Add-AppvClientPackage], ClientException
        + FullyQualifiedErrorId : ConfigurePackageError,Microsoft.AppV.AppvClientPowerShell.AddAppvPackage

     and these are the error messages we see in the debug app-v client logs:

     Script Launcher successfully waited for script with command line: '"C:\ProgramData\App-V\D24C3BDD-8FAD-44D3-998C-933F8F053682\CD9725CE-4503-4932-863B-4FCDA3F9551D\Root\..\Scripts\Integrator.exe" /I /Msi /License /AppV PackageGUID=D24C3BDD-8FAD-44d3-998C-933F8F053682 PackageRoot="C:\ProgramData\App-V\D24C3BDD-8FAD-44D3-998C-933F8F053682\CD9725CE-4503-4932-863B-4FCDA3F9551D\Root" MsiName=SPPRedist.msi,SPPRedist64.msi PidKey=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx,xxxxx-xxxxx-xxxxx-xxxxx-xxxxx,xxxxx-xxxxx-xxxxx-xxxxx-xxxxx PRIDName=ProPlusVolume'.

    Package {d24c3bdd-8fad-44d3-998c-933f8f053682} version {cd9725ce-4503-4932-863b-4fcda3f9551d} failed configuration in folder 'C:\ProgramData\App-V\D24C3BDD-8FAD-44D3-998C-933F8F053682\CD9725CE-4503-4932-863B-4FCDA3F9551D' with error 0x79100E10-0xC.

    machine script for event AddPackage with command line: '"C:\ProgramData\App-V\D24C3BDD-8FAD-44D3-998C-933F8F053682\CD9725CE-4503-4932-863B-4FCDA3F9551D\Root\..\Scripts\Integrator.exe"' exited with failure error code: The extended attributes are inconsistent.. Because Rollback is set to true in the script definition, the current AppV Client operation was rolled back.

    Tuesday, January 07, 2014 8:32 PM

Answers

  • There is a script in the automatically created package that enables integration.  You will need to enable package scripts on the App-V client.  You can do it with the following Powershell command:

    Set-AppVClientConfiguration -EnablePackageScripts 1


    Wednesday, January 08, 2014 4:11 PM

All replies

  • There is a script in the automatically created package that enables integration.  You will need to enable package scripts on the App-V client.  You can do it with the following Powershell command:

    Set-AppVClientConfiguration -EnablePackageScripts 1


    Wednesday, January 08, 2014 4:11 PM
  • Sorry, I should have mentioned that this setting is enabled in the App-v install script, and we have confirmed that it is turned on.

    Next idea??

    Wednesday, January 08, 2014 7:53 PM
  • If you look at the error message, it does not complain that scripts are not allowed, it is complaining about the "extended attributes" of the script command.  Since this script command is system generated (i.e. nothing changed by us), we are trying to find out whether this is a system error or not.

    Wednesday, January 08, 2014 7:55 PM
  • Did you get anywhere with this? I have the same exact problem.
    Monday, January 20, 2014 7:59 PM
  • I also posted this on the app-v forum, and a guy there had the same problem and raised a call with MS support.  MS support say he is the only person in the world with this problem, so I am trying to raise a supporting call. 

    We are not alone in this, and MS is supposedly working on it.

    Monday, January 20, 2014 9:12 PM
  • thanks for the response, this happens with visio 2013 published to the machine, the full office pro plus 2013 works when published to the machine. working on it more today.
    Tuesday, January 21, 2014 1:15 PM
  • I'd like to reply to this that I also have (or had) the same issue. The "AppV Error Code: 100000000C."

    For me it was a script that I tried to call from a network drive:
        <MachineScripts>
          <AddPackage>
            <Path>powershell.exe</Path>
            <Arguments>K:\someFolder\copy.ps1</Arguments>
            <Wait RollbackOnError="true" Timeout="30"/>
          </AddPackage>
        </MachineScripts>

    I tried using the sharename, I tried using vbs instead of ps, I tried to rename the files it was copying (it was a dll) I tried a different destination (it was Windows\sysWoW64)
    In the end it seems to be the AppV client does not have access to the drive/share, even though 'everyone' had read rights. 

    When I changed the location of my script and file to C:\users\administrator\Desktop\copy.ps1 the appv added just fine.
    I'm looking at what to do, probably give all domain computers access to the share\folder because AppV client seems to use the system account for it's actions (also apparant if you call the var %username% from within the appv!), and because my destination is sysWoW64 users are not allowed to write there (so the userConfig.xml is not an option)

    So in short: for me it was a NTFS rights issue, the AppV client is not allowed to go and load the .ps1 that is defined in the deploymentConfig.xml

    Check your ProPlusVolume_en-us_zh-cn_x86_DeploymentConfig.xml, it probably calls something that the system account has no access to



    • Edited by blueskin1978 Tuesday, March 18, 2014 2:45 PM better detailed
    Tuesday, March 18, 2014 2:29 PM
  • we ended up publishing the whole office package to the machine but disabled all apps. we then made AD groups for different office combinations (i.e office with visio, office with project, office with project and visio, and just office). It was important that we did not redirect appdata, if you want to do that, your SYSTEM acct needs R/W to your roaming appdata, or you may see errors like above.


    • Edited by jgsieve Tuesday, March 18, 2014 2:52 PM
    • Proposed as answer by blueskin1978 Tuesday, March 18, 2014 3:04 PM
    Tuesday, March 18, 2014 2:52 PM