Collection of Useful Posts

In previous parts of this series we looked at the App-V 5.0 package format, how it sits on our client OS in the file system cache and how the registry works. So that’s all well and good but what about when about when users make customisations to packages, how do we handle state changes? There are two types of changes that can be made to our packages, file based and registry based. Let’s take a look at how they are both handled in App-V 5.0. Registry In Part 3 of this series we really went behind the scenes of how the registry hangs together both from a native and virtual perspective for our App-V packages. So what happens when we make a customisation to an application that makes a registry based change? I’m going to customise Paint.NET above by hiding the floating windows Tools, Colors, History and Layers. This change is obviously retained every time I launch Paint.NET thereof as a customisation for the user. Let’s take a look at where in the registry those cha...

Now we understand the package format and client file system for App-V 5.0, let’s take a look out how the registry looks in terms of OS integration. As mentioned in Part 1 of this blog series, within the .appv package we can see a registry.dat file which contains the entire registry that was captured for the particular package. Also as discussed in Part 2 we can also see that the registry.dat sits in the cache location on the client once the package has been delivered. So what actually happens with this registry hive? Well it gets mounted and there twos views of this, native and virtual…. Native Registry Gone are the days when we have to break into the bubble to see an App-V applications registry, similar to the file system cache, we store assets in natively to windows standards. The only difference is the physical registry location is not stored directly in HKEY_LOCAL_MACHINE\SOFTWARE but rather HKEY_LOCAL_MACHINE\SOFTWARE\Microsof...

Following on from my post  App-V 5.0 OS Integration - Part 1 - Package Format   where we talked about how a App-V 5.0 package is made up, now we can move on to look at how this package is reflected on your client operating system after the package has been delivered in terms of file system and cache. Cache When App-V 5.0 packages are delivered by default they are stored in %ProgramData%\App-V, this is the physical cache location. In here we will find folders labelled with the GUID of the packages they contain. To easily find what our package GUID is we can use the Get-AppvClientPackage command, wildcards are great to return a filtered result, and for example here I am searching for Paint.NET: We can see Paint.NET has a package GUID starting with CA43, if we drill into this folder we are faced with another GUID! This is our version GUID, as we only have one version of this package published at present there is only one folder. If we go into this folder we...

In this series of posts I am going to take you behind the scenes of how our packages integrate with our operating system in App-V 5.0. The most logical place to start is with the package itself and understanding what is output by our Sequencer. Let’s take this Paint.NET package and try to understand how it is made up. report.xml This file is carried over from our 4.6 SP1 days and contains diagnostic and advisory items around our sequenced package such as any warnings or errors encountered during sequencing or any files that have been excluded. <PackageName>_UserConfiguration.xml This file is for user specific changes that can be influenced at the time of publishing a package to a user. For example if we want to deploy a package with different shortcuts or a specific script to a certain group of users. <PackageName>_DeploymentConfiguration.xml Similar to the above however this file is for global changes that can be influenced at the time of publishing a p...