Posts Tagged ‘deploymentconfig’

App-V 5: On Virtual Fonts

App-V has many virtualization subsystems that make up how App-V isolates itself from other applications. Often I, and others have discussed virtual COM, virtual kernel objects, virtual services, etc. when discussing App-V in depth. Until now, one virtual subsystem that has not been discussed much in the context of App-V 5 is the virtual fonts subsystem. That is usually because you don’t really have to deal with it unless something has gone wrong.

Fonts are installed on-demand at process runtime in App-V 5. This is pretty much similar to the method used in previous versions of App-V with some technical-specific details. (Font information pulled from the AppX Manifest inside APPV package file instead of from .CP file as in previous releases.)

This font information is stored as an extension point (AppV.Fonts) with the fonts designated with the direct path within the AppV package of where the fonts are stored.

By default, the fonts will be deployed during the publishing process. If the fonts are loaded on demand at runtime, then the path will also be specified with the DelayLoad="true” value:

        <appv:Font Path="[{ProgramFilesX86}]NetManageRUMBAAS400RUMBA400.FON" DelayLoad="true"></appv:Font>

Missing Fonts

If fonts have been designated inside the manifest but for some reason are missing in the package, this can be problematic and will cause a package launch to fail as the VFonts subsystem is unable to initialize the fonts properly. When would you see something like this? Well, as you may have figured out by now, any time an application has failed to launch, a generic error message is thrown to the user:

The application failed to launch

This may be due to a network failure


When this occurs, you have to go to the AppV-specific logs in the Event Viewer to get a more component-specific error code. Often, it is not a network failure. Let’s say you are missing font files inside the package.

You may receive a more specific error code: 0x83401D2A-80070490

(This happened to an MVP friend of mine with Office as a matter of fact – )

If you are noticing that certain applications may be causing increases to the publishing process (especially when using a publishing server) fonts could be a factor. If there are many fonts specified in a package that do *NOT* have the Delayload=true option, then they could be a contributing factor.

Excluding Fonts from a Virtual Package

If you are encountering a publishing delay issue with a specific package, or are encountering an issue similar to the above scenario (where missing fonts are causing packages to fail top launch) you can disable the virtual fonts subsystem by utilizing a deployment or user dynamic configuration file which best suits the user targeting.

To disable the virtual fonts subsystem using via XML configuration of the DeploymentConfig.XML or UserConfig.XML file, utilize the following syntax:



      <Fonts Enabled="false" />


App-V 5: On Dynamic Configuration

March 17, 2014 3 comments

When you create a package using the App-V sequencer, everything that you will need for the package will be self-contained inside the .APPV package file. In addition to the file and registry assets, the APPV file also maintains XML metadata that governs the operating system integration configuration and extension points. This configuration is referred to as the manifest configuration. Most of the key information revolving around this information is found in the AppxManifest.xml and [Content_Types].xml files inside the package. You can view these files by renaming the extension of the App-V file to .ZIP and browse the contents using Windows Explorer.

In many deployment situations, you may require some slight adjustments to specific configurations and/or certain operating system extension points. It would be very cumbersome and unrealistic to have to open these packages up in the sequencer to make simple minor changes that affect only this metadata.

Dynamic Configuration is what allows Administrators to make these modifications to an App-V package without having to make any changes to the AppV package itself. Dynamic Configuration are XML files similar to the legacy OSD files in previous versions of AppV and Softgrid. Unlike the OSD files, the dynamic configuration files are technically optional. Unlike the SFT package with earlier versions of App-V and Softgrid, the APPV file is technically all you need to publish and App-V package in version 5.

But let’s say we want to adjust the deployment configuration or other user-specific settings. We have two type of dynamic configuration files:

  • The Dynamic Deployment Configuration file: <PACKAGE_NAME>_DeploymentConfig.xml
  • The Dynamic User Configuration: <PACKAGE_NAME_UserConfig.xml

We can use these configuration files to do a number of things, including:

  • Assign scripts to run during specific packageapplication events
  • Enable or disable a virtual subsystem
  • Override Shortcut Configuration

Dynamic User Configuration

The Dynamic User Configuration (<PACKAGE_NAME>_UserConfig.xml) file contains information that applies configuration for the package to the individual user. For example, if you supply shortcut configuration within this file, this will override the shortcut configuration that is contained within the package manifest. Also note, that if a Dynamic Deployment Configuration exists for the package, Dynamic User Configuration replaces the “User Configuration” section.

Dynamic Deployment Configuration

The Dynamic Deployment Configuration (<PACKAGE_NAME>_DeploymentConfig.xml) file contains information that applies to all users of that machine. It can have a “User Configuration” section which can be overridden by dynamic user configuration.


Let’s say you have a package deployed with the following extension point configuration:

  • Package Manifest: Contains two shortcuts
  • Dynamic Deployment Configuration: Has the shortcut subsystem enabled and two extra shortcuts targeted to users. Shortcut 3 and 4.
  • Dynamic User Configuration: Also has the shortcut subsystem enabled and one extra shortcut. Shortcut 5

In the example above, there are five shortcuts across all of the configuration files. To determine the effective configuration, we use the following formula:

  • If no dynamic deployment configuration or dynamic deployment configuration provided, Shortcut 1 and Shortcut 2 are integrated
  • If dynamic deployment configuration is provided, only Shortcuts 3 and 4 are integrated
  • If dynamic user configuration is provided, only Shortcut 5 is integrated
  • If both dynamic deployment configuration and dynamic user configuration are provided, only Shortcut 5 is integrated


Package Events and the Application of Dynamic Configuration

Dynamic Configuration can be applied using the Add-AppVClientPackage and Publish-AppVClientPackage package events. Dynamic Deployment Configuration can be optionally applied using the following syntax:

Add-AppvClientPackage <path to package> [- DynamicDeploymentConfiguration <path to file>]

While the configuration is added and downloaded, it will not take effect until the Publish Package event. At this time, optional dynamic user configuration can also be applied using the following syntax:

Publish-AppvClientPackage … [- DynamicUserConfigurationPath <path to file>] [-Global]

If Dynamic Deployment Configuration is provided on package add  and/or Dynamic User Configuration is provided on package publish (to user), they will be used during publishing integration. The [UserConfiguration] section (if available) from Deployment Configuration only is used during global publishing (thus targeting all users.) If the –DynamicUserConfigurationPath is specified using the Publish-AppVClientPackage cmdlet with the –Global switch, then the command will error out. The UserConfiguration section (if available) from the dynamic deployment configuration file is used if no explicit dynamic user configuration file is specified during Publish package operation.

Once the package has been deployed and the configuration has been applied, it is cached locally in the following locations:

  • Deployment Configuration:  %ProgramData%MicrosoftAppVClientCatalog Packages<PkgGuid><VerGuid>DeploymentConfiguration.xml
  • Dynamic user configuration file (if published to user) in both %AppData%MicrosoftAppVClientCatalog Packages<PkgGuid><VerGuid>UserConfiguration.xml

and %ProgramData%MicrosoftAppVClientCatalog Packages<PkgGuid><VerGuid>UserConfiguration.xml

But What if you are using a Publishing Server?

Since the publishing agent on the App-V client combines Package Add and Package Publish into a special event (Configure Package.) The default configuration will still be the configuration within the manifest, however, if you added optional deployment and user configuration data, it too will be downloaded with the package configuration. The App-V Client publishing agent can also optimize dynamic configuration content download and subsequent add/publish if client already has matching package with dynamic configuration. Bear in mind if you run into a potential conflict where you may have the same package deployed from multiple publishing servers with different dynamic configuration, the last configuration to download will override and become the effective configuration (last writer wins.)


App-V 5: Useful Stuff for the App-V Professional (I hope!)

November 15, 2013 2 comments

So I’ve been receiving a lot of feedback on ways to enhance  App-V toolkits for customers and their in-house troubleshooting. I’ve received usually two kinds of feedback on previous articles such as
and – 1) This is great! Can I have more?” and 2) “It’s about @*#&% time!Can I have more?

Do we have a “Cached OSD” equivalent in App-V 5.0?

Remember when you were troubleshooting configuration for a virtual application in App-V 4.x? Instead of going through the trouble of modifying the OSD file at the content root, removing and republishing as well as re-streaming the application – instead you locate the application’s cached OSD file and make modifications there while you do your temporary testing of adjustments to the XML configuration. The cached OSD files were located in a subdirectory of where you set the GlobalDataDirectory value in V4. Identifying which of the OSD files applied to your application could easily be achieved by viewing the properties of the application using the App-V 4 Client Admin UI.

In v5, this information will likely be stored in either the deployment configuration or the user configuration file (what we refer to as the dynamic configuration files.) To determine the source of the Deployment Configuration for a particular application, you can take advantage of PowerShell and the App-V Client API’s to find the location of this information without having to know the actual GUID of the package.

$AppVPackage = Get-AppvClientPackage –name <PACKAGE>



You can then proceed to test out these changes.

How can I tell which Virtual Environment (packageconnection group) an Application is Running in?

Often on systems that are running a bunch of different virtual applications that may or may not be grouped together via connection groups (RDSCitrix Servers) you might want to verify a running process is running in the correct virtual environment. You can use the following PowerShell commands to determine the current package version and also possible connection groups (virtual environments.)

$AppVPackage = Get-AppvClientPackage –name <PACKAGE>

Start-AppVVirtualProcess cmd –AppvClientObject $AppVPackage

Get-AppvVirtualProcess | select -ExpandProperty AppvPackageData

In the example below, we use the CMD prompt to verify the version and package ID running.


How Can I tell if an Application was Running Virtualized simply by looking at a Process Monitor Log?

Any executable that is running within an App-V virtual environment will have the module “AppVEntSubsystems64.dll” injected into the process. So all you have to do when viewing a process monitor trace is double-click on any event containing the process you need to check. When the “Event Properties” dialog box appears, Click on “Module” tab and look for AppVEntSubsystems64.dll.