none
AppV 5 - Part or all packages publish failed (part 2)

    Question

  • Hello,

    Regarding this issue: AppV 5 - Part or all packages publish failed:

    Part or all packages publish failed.
    published: 0
    failed: 7
    Please check the error events of 'Configure/Publish Package' before this message for the details of the failure.
    Event-ID: 19104

    I found out that this issue can be solved by checking the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Virtualization\LocalVFSSecuredUsers' and change a wrong entry to '%USERPROFILE%\AppData\Local\Microsoft\AppV\Client\VFS'

    But, there is another cause that can bring up event-id 19104. Difference is that not all packages have to fail, only one or a few.

    Part or all packages publish failed.
    published: 5
    failed: 2
    Please check the error events of 'Configure/Publish Package' before this message for the details of the failure.
    Event-ID: 19104

    In this case the issue is caused by a too large/wrongly maintained ACL on the application folder in C:\ProgramData. What the App-V client seems to do at logon is adding the user's account with Read & Execute permission to the ACL of each packagefolder the user has access to. (whether the user starts the application or not, and even though the user has already read & execute permissions via Everyone).

    Example:
    Application: AppV Client UI
    Folder: C:\ProgramData\App-V\237CB45B-20C7-4C91-985C-39A94507975A\F53D7A26-7FE3-40AB-990E-F244DC59FF43
    Permissions:
    - Everyone: Read & Execute
    - SYSTEM: Full Control
    - Administrators: Full Control
    - TrustedInstaller: Full Control
    - User1: Read & Execute
    - User2: Read & Execute
    - User3: Read & Execute
    - User4: Read & Execute
    - etcetera...

    After a while (approximately 1024 entries) the ACL becomes too large/corrupted and the App-V client can't read/set the permissions anymore resulting in an event-id 19104.

    The workaround can be removing that package, but in my case i got this error:
    Remove-AppvClientPackage : Application Virtualization Service failed to complete requested operation.
    Operation attempted: Remove AppV Package.
    Windows Error: 0x80070057 - The parameter is incorrect
    Error module: Streaming Manager. Internal error detail: A5602C2C80070057.

    After that i tried a permission reset to its defaults on the folder, and that did the trick.

    $folder = "C:\ProgramData\App-V\237CB45B-20C7-4C91-985C-39A94507975A\F53D7A26-7FE3-40AB-990E-F244DC59FF43"
    $Acl = Get-Acl $folder
    $acl.Access | %{$acl.RemoveAccessRule($_)}
    $Group = New-Object System.Security.Principal.NTAccount("NT AUTHORITY", "SYSTEM")
    $Acl.SetOwner($Group)
    $AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule("NT SERVICE\TrustedInstaller", "FullControl",  "ContainerInherit, ObjectInherit", "None", "Allow")
    $Acl.SetAccessRule($AccessRule)
    Set-Acl $folder $Acl
    $AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule("NT AUTHORITY\SYSTEM", "FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
    $Acl.SetAccessRule($AccessRule)
    Set-Acl $folder $Acl
    $AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule("Builtin\Administrators", "FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")
    $Acl.SetAccessRule($AccessRule)
    Set-Acl $folder $Acl
    $AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule("Everyone", "ReadAndExecute",  "ContainerInherit, ObjectInherit", "None", "Allow")
    $Acl.SetAccessRule($AccessRule)
    Set-Acl $folder $Acl

    Just to let you all know. I hope Microsoft will fix this in a future hotfix

    Jur Huisman


    • Edited by jwhuisman Tuesday, November 04, 2014 9:12 AM formatting
    Tuesday, November 04, 2014 9:12 AM

Answers

  • App-V 5.0 SP3 is on target to be released during 2014.

    User Experience Virtualization (UE-V) Senior PM @ Microsoft Corporation ----- More info on UE-V: http://aka.ms/UE-V_Info ----- UE-V 2.0 Admin guide: http://aka.ms/UE-V20_AdminGuide

    Monday, November 17, 2014 4:38 PM
    Moderator
  • Just to complete my previous post, Sebastian confirmed that the issue is still there with Hotfix 5 and PackageStoreAccessControl=0. You have to wait for another hotfix or use the workarounds mentioned by Sebastian:

    - Global Publishing
    - Delete the cache

    or I believe it's also possible to reset the permissions by a script, just run it regularly.


    Regards, Michael - http://blog.notmyfault.ch -

    Tuesday, November 04, 2014 3:21 PM

All replies

  • This issue might be caused by the fact that earlier versions of App-V 5 had that 'PackageStoreAccessControl' feature. It was introduced to avoid users from just browsing to 'any' executable in the App-V package store and launch 'any' application.

    However, that feature has been removed with HF5 for App-V 5 SP2 because of know issues. Furthermore that feature wasn't intent to be used on RDS environments.

    An 'ACL list full' issue has been described by Sebastian Gernet at http://blogs.msdn.com/b/sgern/archive/2014/10/17/10565434.aspx (German), though it names ~250 users as the limit.


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Tuesday, November 04, 2014 11:09 AM
    Moderator
  • Hello Falko, thanks for your reply.

    I didn't find Sebastian Gernert's thread while searching for a solution for this issue.

    Strange thing is that if hotfix 5 should fix the issue (or am i wrong with that?), it is not the case in our situation.

    We've already installed hotfix 5 in out test environment, removed all app-v connection groups and applications with powershell, removed all folders and registry keys, and still the issue persists. The client is still adding each user's account to the ACL of the folder.

    When i run Get-AppVClientConfiguration the value PackageStoreAccessControl is 0.

    Note: when you enumerate the ACL of a folder the number of unique SIDs differs from the number of total entries (more than one right-type per SID)

    (get-acl "C:\ProgramData\App-V\237CB45B-20C7-4C91-985C-39A94507975A\F53D7A26-7FE3-40AB-990E-F244DC59FF43" | Select-Object -ExpandProperty Access | Select IdentityReference -Unique | measure-object IdentityReference).Count
    (get-acl "C:\ProgramData\App-V\237CB45B-20C7-4C91-985C-39A94507975A\F53D7A26-7FE3-40AB-990E-F244DC59FF43" | Select-Object -ExpandProperty Access | Select IdentityReference | measure-object IdentityReference).Count 

    The error occurs at approximately 1000 of total entries (unique SIDs are approximately 315 at that time).

    Best regards,
    Jur Huisman

     

    Tuesday, November 04, 2014 12:35 PM
  • I can reproduce the issue with Hotfix 5 and PackageStoreAccessControl=0. If I understand Sebastian's post correctly, then this issue will be fixed in a future hotfix. Beside Publishing globally or deleting the Cache, a script that regularly resets the ACL might help as well...


    Regards, Michael - http://blog.notmyfault.ch -

    Tuesday, November 04, 2014 1:37 PM
  • Just to complete my previous post, Sebastian confirmed that the issue is still there with Hotfix 5 and PackageStoreAccessControl=0. You have to wait for another hotfix or use the workarounds mentioned by Sebastian:

    - Global Publishing
    - Delete the cache

    or I believe it's also possible to reset the permissions by a script, just run it regularly.


    Regards, Michael - http://blog.notmyfault.ch -

    Tuesday, November 04, 2014 3:21 PM
  • Thanks for the information. We'll wait for the hotfix.

    For the time being we're using a workaround.

    Tuesday, November 04, 2014 3:26 PM
  • Wednesday, November 05, 2014 3:06 PM
  • Thank you very much for the information you provided.  It was the exact same problem that I was experiencing with applications in my environment.

    I opened a case with Microsoft hoping to get a hotfix.  The good news is that they are aware of the issue (obviously), and even have a fix for it.  The bad news is that there is not a hotfix for the issue.  It is going to be fixed in Service Pack 3, which is scheduled to be released during 2014.  That leaves us up to 8 weeks (assuming it's on target) to wait for this fix.

    I confirmed with Sebastian that this problem was introduced with SP2.  If you want to continue to use App-V 5 without this problem, you would have to drop the clients back down to SP1. 

    Wednesday, November 05, 2014 4:50 PM
  • Going back to SP1 is like moving from Windows 8.1 to Windows XP ;-)

    Regards, Michael - http://blog.notmyfault.ch -

    Wednesday, November 05, 2014 5:24 PM
  • App-V 5.0 SP3 is on target to be released during 2014.

    User Experience Virtualization (UE-V) Senior PM @ Microsoft Corporation ----- More info on UE-V: http://aka.ms/UE-V_Info ----- UE-V 2.0 Admin guide: http://aka.ms/UE-V20_AdminGuide

    Monday, November 17, 2014 4:38 PM
    Moderator
  • Great news, thanks Aaron! I'm looking forward to it...

    Regards, Michael - http://blog.notmyfault.ch -

    Monday, November 17, 2014 4:43 PM
  • I had a similar problem. In my case, changing the value did not help. After a call to support, we determined that deleting the entire HKEY_LOCAL_MACHINE\Software\Microsoft\AppV\Client\Virtualization\LocalVFSSecuredUsers
    key resolved the issue (the App-V client recreates it automatically).

    Hope this helps someone!

    Ryan

    Tuesday, November 25, 2014 9:08 PM
  • Just to clarify (and to help others searching), in my case, these were some of the error messages:

    Publish-AppvClientPackage : Application Virtualization Service failed to complete requested operation.
    Operation attempted: Publish AppV Package.
    AppV Error Code: 040000002C.
    Error module: Virtualization Manager. Internal error detail: 4FC076040000002C.
    Please consult AppV Client Event Log for more details.
    At line:1 char:106
    + import-module 'C:\Program Files\Microsoft Application Virtualization\Client\Appv ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidResult: (:) [Publish-AppvClientPackage], ClientException
        + FullyQualifiedErrorId : PublishPackageError,Microsoft.AppV.AppvClientPowerShell.PublishAppvPackage

    <![LOG[    Required component [{AppVPackageRoot}]\<insertprogramname.exe> is not published]LOG]!><time="06:24:13.070+360" date="11-14-2014" component="AppVHandler" context="" type="1" thread="3984" file="appv5xhandler.cpp:225">

    <![LOG[+++ Did not detect app deployment type <AppV package name> - Microsoft Application Virtualization 5(ScopeId_BFBC49C1-A2CF-4F29-B37A-ECED8F54CDEA/DeploymentType_73880283-ace2-40b3-9555-78add60e5d5a, revision 3) for S-1-5-21-<SID>.]LOG]!><time="06:24:13.122+360" date="11-14-2014" component="AppDiscovery" context="" type="1" thread="3984" file="appprovider.cpp:540">

    [3]07CC.0DF0::‎2014‎-‎11‎-‎19 15:20:27.226 [Microsoft-AppV-Client-Orchestration]Activity PublishPackage  #36 failed on component VirtualizationManager  (error: 0x4FC08204-0x2C).

    [1]07CC.0DF0::‎2014‎-‎11‎-‎19 15:20:27.249 [Microsoft-AppV-Client-Orchestration]PublishPackage  activity #36 failed with error code 0x55900C02-0x501.

    HKEY_LOCAL_MACHINE\Software\Microsoft\AppV\Client\Virtualization\LocalVFSSecuredUsers had several REG_SZ entries, one of which had the value C:\Users\Default\AppData\Local\Microsoft\AppV\Client\VFS

    Tuesday, November 25, 2014 9:16 PM