Share via

App-V 5: On AddPackage and ConfigurePackage

  • Article

The other day I was troubleshooting a package add issue where I was running into a brick wall that turned out to be an awfully simple solution. While troubleshooting this, it came to me that I have not really gone into much depth as to what happens during an AddPackage or a ConfigurePackage operation in App-V 5. I mention both because they both refer to the process of laying down the necessary assets that will be needed for publishing and streaming the application. Whether we are adding the package manually using PowerShell (Add-AppvClientPackage) deploying through Config Manager, or synchronizing with the App-V Publishing Server, the methodology is the same.

You’ll notice that all of the critical XML files extracted from the APPV file will be fully cached in the base package directory even in shared content store mode. You’ll also notice the registry hive will be downloaded as well. The base catalog assets will be laid down as well in the packages catalog root. Finally, all of the assets required for publishing (under FB0 Feature Block 0 – the publishing block – mostly icons) will be cached. This is why even if Shared Content Store mode, all of these small files are usually fully populated files and not just sparse files. All of this before the actual publishing events regardless of targeting. If all goes well, you will see a value of 1 under the PackageState registry value for each package under:

HKLM\Software\Microsoft\AppV\Client\Streaming]\Packages\<GUID>\<GUID>

The values possible for PackageState are:

1 – Package has been staged/configured successfully.

2 – Package has been deleted.

3 – The package has been fully mounted (loaded) into the App-V cache.

0 or anything else (HRESULT) – means a problem has occurred.

If you are running in Shared Content Store mode, the only files that will be fully cached into the sparse files will be publishing assets and probably most of the initial executables for the applications. Prior to streaming, this will also be the case with the default stream-to-disk scenario. Once the package has been streamed down, the files will be fully populated. Note that EVEN in Shared Content Store mode, if you pre-cache the application using Mount-AppVClientPackage all of the files and assets will be fully streamed to the disk or cached for that particular package.

Package Rollback

If for some reason, the AddPackage/ConfigurePackage event fails, the AppV client will try to clean up everything be it a script failure (where rollback action is selected) or an issue with the package itself. The PackageState will be 2. If the package cannot be removed because files are in use (which could be the case when scripts are involved) the package will be marked for pending deletion. Look for 0x8007012F which means “Pending Delete.” When the client service is restarted, the client will re-attempt the deletion of packages that are in the deleted state. Once the removal is successful, the registry entries for the package will be gone.