Archive for July 16, 2014

App-V 5: On App-V 4.x to 5.x Token Transitions

July 16, 2014 1 comment

Tokenization is essential to application virtualization. This is where traditional directory paths are replaced with tokenized paths to ensure portability and flexibility. While hard-coded paths have not left the world of software development (although it should have more than two decades ago) most modern software is able to install to known paths and shell locations allowing App-V to easily capture and tokenize the paths during sequencing.

Application State and User State are kept portable through the use of App-V Tokens. This allows for the portability of applications across machines where the folders may be relocated to a different folder and/or drive. For example, %APPDATA% may be redirected to another drive or a network path. Another example would be having %ProgramFiles% being redirected to D:Program Files instead of the default on Drive C.


App-V 4.x Legacy Tokens

In versions of Softgrid and App-V prior to V5, the token paths were built upon objects leveraged by many API’s that are now deprecated – especially with the end of Windows XP’s life. These CSIDL folders, which are actually referred to as “special folders,” are folder which is presented to the application through an API interface abstracted instead of using the absolute folder path. You may hear these referred to erroneously as shell folders. I try not to use that term because while many of these folders relate to the “shell” not all of them do – as many are tied to the operating system in general regardless of “shell” being used. With that being said, the SHGetFolderPath function was the most common use of these in previous version of Windows:

The CSIDL reference on MSDN is here as well:

Softgrid and App-V 4.x had to also leverage custom tokens or CSIDL’s not previously defined in Windows for the purpose of abstraction. These were actually prefaced with SFT_ instead of CSIDL.

App-V 5 Tokens

App-V 5 uses two types of tokens as well: Known Folder tokens and Custom Tokens. Known Folder Tokens are tokens that resolve to KnownFolderIDs (instead of the legacy CSDIL) that are defined within the Windows shell:
( Custom Tokens are ones that have to be specifically defined by App-V 5 and apply only to those applications virtualized within App-V 5.

Known Folder Tokens

App-V 5 uses non-localized names to denote Known Folder tokens. These tokens and the paths they represent are built dynamically when a virtual application runs on a machine for a particular user. Some of these tokens represents system specific paths (i.e., C:Program Files) and others represent user state paths (i.e., C:Users<UserName>AppData). The folders are initially laid down in the immutable package cache using there token names. The actual translation to specific virtual path comes within the virtual environment. In some cases, the tokens have to be defined by bitness so the tokens remain consistent across bitness of platforms. This allows a sequencer running on a 32-bit sequencer to capture tokens that will be compliant – should this package also be ran under a 64-bit client. 64-bitspecific paths/tokens will not be available when the list is built on a 32-bit machine.

A list of Known Folder Tokens are found in the App-V 5 Sequencing guide found here: in section 16.2

Each of these tokens are parenthesized with a [{ and }]. For example, [{Local AppData}] reflects the token for the known folder variable %LOCALAPPDATA% which defaults to Known Folder path C:Users<UserName>AppDataLocal

 Custom Tokens

On top of the Known Folder tokens, App-V 5.0 uses custom tokens just as it did with earlier versions of App-V and Softgrid. Older custom tokens, however, have been renamed following the new naming convention. For example, SFT_SYSTEM32_SPOOL is now called AppVSystem32Spool.

Some of the older custom tokens are discontinued as their paths are now covered by Known Folder tokens. For example, the path represented by old custom token SFT_PROFILES_DIR did not have a CSIDL representation so a custom token was created. The path is now represented by the Known Folder token “UserProfiles.” Section 16.2 of the Sequencing document also lists the common custom tokens used by App-V 5.

Package Drive

We have no Q: drive in App-V 5. Previous versions of App-V used the custom token “SFT_MNT” to represent the virtual drive, or rather, default “Q drive”, where during sequencing the user would install the app on Q drive. This allowed having a different drive letter for virtual drive on the client machines from the one on the sequencer machine. Where in older App-V versions it explicitly represented virtual drive, in App-V 5.0, where there is not a virtual drive, it now represents the drive on which the user installed the application.

In App-V 5, we have the PVAD (Primary Virtual Application Directory.) The PVAD (which is laid down in the immutable package cache as Root and abstracted as [{AppVPackageRoot}]. If drive letters or multiple drives are specified and tokenized, the install drive name will be abstracted as “AppVPackageDrive.” For example: the path C:AppNameInstall would be translated to [{AppVPackageDrive}]AppNameInstall

If the application installer lays down files on the installation drive which do not fall under any other Known Folder or custom tokens, these paths are translated from the specific drive on Sequencer machine using “AppVPackageDrive” token.

Keeping Consistent with WoW64 Bitness Virtualization

Certain subdirectories under %windir%/system32 are exempt from Wow64 redirection (see Access to these subdirectories is not redirected to %windir%SysWOW64. The following custom tokens are used to represent these subdirectories so that they are not tokenized using “System” known folder. This is because 32-bit apps sequenced on 32-bit OS are when deployed on 64-bit OS, “System” known folder token is expanded to %windir%SysWOW64, which will not work for these subdirectories which are exempt from Wow64 redirection.

Custom Token

Custom Token Expansion