ACL issue on user-published App-V 5.0 SP2 packages

There is a known issue when you publish an App-V 5.0 SP2 package user-based. The issue will be seen when it’s published to roughly ~250 users. This can be observed in the eventlog:

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

The issue happens because every user that got the app published has been added to the ACL of the published App-V package below c:\programdata\app-V reaches its limit (~250 entries) and therefore the whole publishing mechanism doesn’t work properly anymore. The reason is the PSAC feature (Package Store Access Control) that is depreciated and won’t exist anymore in App-V 5.0 SP3 that will be released soon. So SP3 will fix the issue. In the meantime, the following workarounds exist:

  • Publish the app globally and not user-based
  • Delete the cache
  • Run a scheduled script that will reset the permissions on the folder

Thanks to Sebastian Gernert who posted about the issue (it’s in German): http://blogs.msdn.com/b/sgern/archive/2014/10/17/10565434.aspx

App-V 5.0 SP2 HF5 on Windows 10

Already tried using App-V 5.0 SP2 HF5 on Windows 10 Technical Preview or are you just before trying it? If yes, make sure you have at least installed Build 9860. There is a known issue with junctions. App-V 5.0 uses junctions, i.e. in “C:\ProgramData\Microsoft\AppV\Client\Integration”. You will get an error message when launch an App-V package thru the shortcut in the start menu because the file that is part of a junction folder cannot be found.

Other than that, App-V 5.0 SP2 HF5 worked perfectly on Windows 10, I haven’t experienced any issues so far with my packages….

App-v app knows its real path

Ever wondered what is being returned if a virtualized app in App-V 5.0 asks for its own path? I tested it with a simple C++ exe that I created for that particular case. It uses the GetModuleFileName API to get its own path on the system. When running the exe, the output is its path and the directory listing of the folder it’s located in.

I created an App-V 5.0 package with the exe twice in it, once in the VFS and once in the PVAD path (PVAD = c:\getPathOfExe):

– c:\getPathOfExe\getPathOfExe.exe (PVAD)
– c:\Program Files\getPathOfExe\getPathOfExe.exe (VFS)

There is nothing else in the App-V package than these 2 files.

So to finally test the behavior after having added and published the package, I opened a cmd.exe within its virtual environment and did run both of the exe files.

Running getPathOfExe.exe in PVAD:
getPathOfExe-PVAD

Right after running the exe, you see the output of the exe’s path itself. Although it has been installed to c:\getpathofexe\, it knows that the real location is in c:\programdata\app-v\…

The next output is the directory listing of the folder it’s located in. It automatically merges with the local folder c:\getpathofexe\. C:\getpathofexe\hahahaha\ exists on my system, so it merges the folder absolutely correct. Additionally I created the folder “test” within the virtual environment which is also shown as it should.

Running getPathOfExe.exe in VFS:
getPathOfExe-VFS

The behavior is the same in PVAD and VFS. GetPathOfExe.exe recognizes that it’s located in c:\programdata\app-v\… and not in the VFS c:\program files\getPathofExe\.

In the App-V package I configured to merge c:\program files\getpathofexe\ with the local folder, that why you see the folder “hahaha” shown in the directory listing. “test” folder has been, like in the PVAD test before, manually created within the virtual environment. Directory listing works as expected.

What is the take away of the lesson? Files running in a virtual environment exactly know their “real” location.