A customer was using XenApp with PVS. The same PVS image was used on machines on a farm. They added App-V 5 to the PVS image and decided to use the PowerShell interface to add applications virtually at boot time. One of the servers refused every app, while everything else worked on the ‘identical’ servers.
Investigation showed that the Add cmdlet was failing with Error 0000012.
No other messages in the event logs, even turning on the debug logs.
In further investigation, the customer had configured the App-V client to place the package store on a secondary partition. On boot, while Windows was wiped out, this partition remained. The folder referenced existed on both good and bad machines, but was empty on the bad machines.
Looking at permissions, since the standard Windows error 12 is an Access error, the security settings and standard attributes of the good and bad server folders were Identical.
Solution: The App-V client protects the package cache. As such, it expects to create and set special attributes on this folder and everything under it. Possibly someone manually created this folder, causing the problem. The solution was just to delete the folder referenced in the registry config. The next time an app was added, the App-V client recreated the folder correctly, and everything worked.
The long term solution was to add the deletion of this permanent cashed to the bootup script. They also could reconfigure the client to the ‘standard’ location, but reducing writes to the PVS partition is probably preferred.
