App-V 5: On App-V Nomenclature
As you may have figured out by now, App-V 5 has components that are referred to by multiple names depending on context. In some cases, App-V 5 basically takes the synonym concept to interesting levels. This can be misleading if misinterpreted. This can lead ISV’s and IT Pros down the wrong path with regards to troubleshooting, integrating with, or developing for – App-V. App-V 5 also brought us a whole bunch of new things that were really only new to the App-V product itself and not necessarily new to Windows as a whole. This is pretty clear once you are pointed back to the API reference. So to clear up potential confusion. I would like to take the time to point some of this information out. For those of you who are already App-V 5 experts, you may find this a little rudimentary and (dare I say it) boring – but we do have users who are new to App-V now following this blog on a regular basis. ?
A Virtual Process is also an Application
Whereas we had packages that contained applications in App-V 4.x and each application had its own set of configuration metadata, now we have metadata tied only to the package and the applications are launched by executables directly. Virtual applications are specifically pointed out and enabled within the package metadata. Applications are referred to as virtual processes when it comes to manipulation through PowerShell (i.e. the Start-AppVVirtualProcess cmdlet), but when turning on or off applications within Configuration Manager or the App-V Management Console, we are speaking still of Applications.
Targeting Reflects Publishing Method
User Targeting within a management system translates to the application being published to the user on the client machine. Machine Targeting within a management system, translates to the application being published to the machine globally.
A Connection Group is a Virtual Environment . . . and also a Package Group
A Connection Group is a set of XML metadata that defines a virtual environment. When a Connection Group is defined manually or through the App-V Publishing System, it is referred to as a Connection Group. When a Connection Group is created and deployed via Configuration Manager, it is referred to as a Virtual Environment. You may have already been made aware of that but also be aware that Connection Groups are also referred to as Package Groups in the context of the Client Catalog. Speaking of the Client Catalog . . .
A Manifest is Configuration but not Policy
The Manifest is the embedded configuration XML metadata that stored in the AppXManifest.XML within the APPV package. Dynamic Configuration is an external configuration policy that is tied to users and/or computers. Dynamic Configuration is also referred to as policy. The Catalog is not just the manifest but rather the Catalog is the combination of the two configurations for each packages and package groups.
Once an application has been published to the client, depending on the target, this is where you would view catalog configuration for troubleshooting purposes.
Integration Links are Actually Junctions
For both User and Global Publishing, the integration links for shortcuts are created to sync up with the most recent package version within the immutable package cache. This saves us from having to recreate these when a package version changes. These links contain junction points not symbolic links. A symbolic link can be either a file or a directory. It looks to be the same as a Junction Point when viewed in Explorer, but it is spelled out as a Symbolic link to a file or a directory when viewed through the command prompt:
A symbolic link is defined here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365680(v=vs.85).aspx. A Junction Point is just that, a Junction point. Not a hard link. Junction Points are implemented through reparse points and are defined here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365006(v=vs.85).aspx
Can you create your own integration points? Yes, you can. You can use the https://technet.microsoft.com/en-us/sysinternals/bb896768.aspx instead of mklink /d which would actually create a symbolic link.
A Shadow File is a Sparse File . . . and Friggin’ Awesome as Well.
Shadow files are what are created in the immutable package cache when a package is published. This is where a file is created that denotes the total size but does not consume disk space other than the allocation unit required to create the NTFS file record. Data will then populate these files upon streaming the application’s files to the disk. In the case of the Shared Content Store, these files will not get populated on disk (with some exceptions for portions of primary executables.) Shadow files are implemented using NTFS Sparse files defined here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365564(v=vs.85).aspx
Sparse files appear in Explorer with a “x” to denote it has not been completely populated with data. The difference between the appearance is outlined visually below:
When viewing sparse files in the command prompt, you will see that the sparse file size indicator has parenthesis, if there are no parentheses, they are fully cached files.
To Mount is to Stream
To load or basically pre-cache, or pre-stream, we use the “Mount-AppVClientPackage” cmdlet in PowerShell. So if you wanted to manually pre-cache all of the binaries of a virtual application, you would Mount the package. In previous versions of App-V, this would also be referred to as loading.