Collection of Useful Posts

Posts

App-V 5.0 OS Integration - Part 4 - State Changes

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 changes get

App-V 5.0 OS Integration - Part 3 – Registry

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\Microsoft\AppV\Client\Packages. In this loc

App-V 5.0 OS Integration - Part 2 - File System Cache

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 see a very fa

App-V 5.0 OS Integration - Part 1 - Package Format

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

A trust certificate import prompt after upgrade to new version of Acrobat

Issue: After upgrade to new version, a trust certificate import prompt comes up as older version of Acrobat had Trusted Certificates recorded over time. Analysis: The Certificates are saved in user profiles at this location: %appdata%\ Adobe\Acrobat\ <version> \Security\addressbook.acrodata If the file is copied to new version Security folder for each users then it will not prompt for import, and all the Trust Certificates will be imported to new version. Solution: Create a custom VBScript to copy addressbook.acrodata from older versions to new version for each users (e.g. upgrading from versions 9.0/10.0 to 11.0) for Win7 Add it to Execute Immediate Installation Sequence after InstallFinalize Copy_Trust_Cert.vbs Script: dim arcfolder, arc10folder, arc9folder Set objFSO = CreateObject("Scripting.FileSystemObject") Set objFolder = objFSO.GetFolder("C:\Users") Set colSubfolders = objFolder.Subfolders

Active Setup for MSI with no Entry Points

Active setup provides a solution when the aim is to deliver user based components when no advertised entry points exist in an MSI package. Most packages will contain some kind on entry point; commonly an advertised shortcut. When launching this kind of shortcut Windows Installer will check the keypath of the component the shortcut belongs to and verifies that the component is installed. If it is found to be missing Windows Install will kick off a repair. This provides a great solution for installing current user data when the package is not installed in the user context. It is also a very good reason why you should never mix machine and user data in the same feature. So what do you do if there are no shortcuts to advertise? Active Setup will solve the problem. An MSI package has been created to install an Outlook plug-in. This package installs both user and machine data. User preferences are stored as a combination of HKCU registry and a XML file written to %USERPROFILE%. As t