Delivering Office with App-V – The Need for Profile Management

Because Office is a core application of most desktop deployments, user interaction with Office and the user experience are important factors in the deployment of Office. From an administration perspective, providing a seamless user experience requires managing the user preferences of an application, independent of the application delivery method.

Multiple App-V packages are common

Microsoft recommends sequencing applications on the same operating system as the target clients are running. This means that if your target clients are running Windows XP and Windows 7, then you should create two App-V packages for each application – one for each operating system.

However, in practice it is often advisable to sequence on the lowest common denominator. In the example with Windows XP and Windows 7 clients, sequencing should be performed on Windows XP. In the event that a package does not then execute correctly on Windows 7, then the application should be re-sequenced on Windows 7.

The same applies to x86 and x64 processor architectures – if you are deliverying 32-bit applications to both x86 and x64 Windows, you should sequence in a 32-bit Windows environment. If you find that a 32-bit virtual application package executes OK on x86 Windows but not on x64 Windows, you will have to create two packages, one for each processor architecture.

There are several reasons for this, but they’re out of scope of a discussion on profile management; however what this highlights is that if you have multiple packages for the same application due to different operating systems and/or processor architectures, again the only way to improve the user experience is to rely on a third party profile management solution that works independently of the App-V package.

App-V and User Profiles

The default behaviour of App-V is to not only virtualize the application, but also the user profile locations for that application (HKEY_CURRENT_USER and %APPDATA%). This means that that profile information for the Microsoft Office packages will be stored, in its entirety, in the PKG.

The implication of this is that the settings for a virtualized Office package will be specific to that package – that is, a user’s Office settings will not only be specific to a version of Office but also specific to an individual Office package.

Consider the following scenarios:

  • A user moves between desktops where Office Standard has been deployed to the first desktop, but Office Professional has been deployed to the second. These will be different App-V packages, so by default, no user preferences will be shared
  • You create an Office package which has been released to production and later find issues with the package that requires re-creating it from scratch – user preferences from the old package will not be shared with the new package
  • You find that you need to create multiple Office packages for different platforms – for example a package for desktops and a package for Remote Desktop Session Host servers. These are separate App-V packages and user preferences will not be consistent across those packages

Each scenario will result in separate App-V packages for the same applications.

If you need to upgrade a package or migrate between Office versions, you now have a further challenge that you would not have if Office were installed instead of virtualized.

By implementing a 3rd party profile management solution, you gain the ability to manage user’s Office preferences independent of the Office version (App-V package version or Office version) and remove the reliance on a specific Office package. A profile management solution will allow you to create, update and re-create Office packages without affecting the end-user experience.

What solution should I use?

The user profile management or user state virtualization tools built into Windows aren’t able to see into the App-V virtual environment and therefore aren’t able to manage an application user preferences independent of the App-V package. If you would like to manage user preferences more granularly, a 3rd party solution will be required.

A profile management solution that is capable of managing user preferences inside and across App-V packages will provide you with the flexibility and consistency of user experience required to support a core application like Microsoft Office. Without providing users with a consistent user experience or one that matches their existing Office deployments, user acceptance will be low.

For an objective comparison of the 3rd party solutions available, see the following white paper: UEM Smackdown: Head-to-head analysis of Appsense, Citrix, Immidio, Liquidware Labs, Microsoft, Quest, RES, Scense, Tricerat and others

Posted in Deployment | Tagged , | 3 Comments

An Archive and Analysis of #AppV Tweets

Several months ago, I used the The Archivist to create an archive and analysis of tweets with the #AppV hash tag. 1,740 tweets later (not all of which I’m sure are App-V related), we get an interesting picture of conversations around App-V. To view the archive visit this URL: http://bit.ly/appvarchive 

AppVArchive

The top users who have been tweeting about App-V over the past several months:

TopUsers

Quite a few of the top URLs have already expired or link to non-existent pages. What’s interesting though, is most of the top URLs link to several App-V videos on TechNet – I had hoped that community created content might feature more prominently.

TopUrls

It’s an interesting exercise and although the graphs that are rendered are a little buggy, I think the data is worthwhile reviewing.

Posted in Community | Tagged | Leave a comment

Sequencing Mozilla Firefox 8

Mozilla has just released Firefox 8, so it’s time to look at virtualizing the new version. It’s a simple task to virtualize Firefox, as it lends itself well to application virtualization; however getting it right takes a little more effort. Here’s how to successfully sequence Mozilla Firefox 8.x.

What you lose by virtualizing Firefox

Virtualizing Firefox with App-V will isolate the application from the OS, so the following features will not be available once Firefox has been sequenced:

  • Firefox Jump Lists in the Start Menu and Taskbar
  • The ability set the browser as default

Firefox features to disable

There are a couple of features that should be disabled when running Firefox under App-V:

  • Automatic updates for Firefox – Options / Advanced / Update – Automatically check for updates to: Firefox. Firefox updates should be delivered via new App-V packages. Updates for Add-ons and Search Engines should be OK as these are written to the user profile
  • Default browser check – Options / Advanced / General – Always check to see if Firefox is the default browser on startup. Once Firefox is isolated from the OS, the user won’t be able to make it the default browser

I will cover using a couple of customisation to ensure these features are disabled for any new Firefox profile.

Managing the Firefox profile – virtualize or not?

Firefox stores preferences, extensions and other user data in:

  • %APPDATA%\Mozilla (preferences, bookmarks etc.); and
  • %LOCALAPPDATA%\Mozilla (browser cache)

The default behaviour of the App-V Sequencer is to exclude %LOCALAPPDATA% – this is a good thing and I don’t recommend removing this exclusion. %APPDATA% will be included by default and whether you leave this location included in the package will depend on your specific deployment requirements; however my recommendation is to exclude this location by adding %CSIDL_APPDATA%\Mozillato the exclusion list in your sequence. On the client, Firefox will then create a new profile in the real file system when the user starts the browser for the first time. There are several reasons why this approach is a good idea:

  • Some of the configuration files within the Firefox profile include hard-codes paths – challenging if your App-V virtual drive changes between clients
  • Virtualizing the profile increases the complexity of upgrading Firefox packages especially challenging given Mozilla’s new approach to Firefox releases. By storing the Firefox profile on the real file system, Firefox can be deployed via completely unrelated packages – no need to create upgrade versions
  • Users can potentially create multiple Firefox profiles, with each stored in the users’ PKG file. The minimum size for a new Firefox profile is 12Mb – the PKG file will grow by 12Mb for each new Firefox profile created

By excluding %APPDATA% and not virtualizing the user profile you will gain some flexibility with your Firefox deployment.

Configuring Firefox Defaults

If a Firefox profile is not virtualized within the package any options set during the monitoring phase won’t be captured. Fortunately Firefox can be configured with defaults for any new profile so that it will contain your required configuration options.

Mozilla has made it easy to deploy custom default settings and preferences – by adding files to %ProgramFiles%\Mozilla Firefox\defaults\profile (change the path to suit your environment), new Firefox profiles will pick up a copy of these files when the profile is created. I will walk through adding a couple of files to this location to ensure that any new Firefox profile receives the required settings. You can find more detailed documentation on these features in the following articles:

To enforce user settings we can leverage user.js and the use UserChrome.css to remove those user interface elements. Available below is a copy of user.js that disables automatic updates of Firefox and checking whether it is the default browser:

Firefox user.js Firefox user.js

A simple approach to extending the options in user.js and prefs.js is to install Firefox and configure it the way you would like. Then open prefs.js from the new profile and use the entries to create custom versions.

Available here is a copy of userChrome.css that will remove from the user interface the options to enable browser updates and set Firefox as the default browser:

Firefox userChrome.css Firefox userChrome.css

Sequencing Platform

I have sequenced Firefox 8 on a clean Windows 7 SP1 x86 VM with all current updates and no other applications other than the App-V Sequencer. I’ve configured a Q: drive using a second vDisk, rather than let the Sequencer create a Q: drive for me. I’ve used a VFS install and tested successfully; however if you would prefer a MNT install just change the install folder when installing Firefox

The Firefox version available from Mozilla is an x86 application (x64 build are available from other sources), so I generally recommend sequencing Firefox on Windows 7 x86 virtual machine even though you may be deploying to 64-bit Windows. However confirm this in your own environment and re-sequence for 64-bit platforms if required.

Sequencer Configuration

Before Sequencing, add the following exclusions:

  • %CSIDL_APPDATA%\Mozilla
  • %CSIDL_COMMON_APPDATA%\Microsoft\RAC
  • \REGISTRY\USER\%SFT_SID%\Software\Microsoft\Windows\CurrentVersion\Internet Settings

If you are adding Adobe Flash Player to the package, add these exclusions as well:

  • %CSIDL_APPDATA%\Adobe
  • %CSIDL_APPDATA%\Macromedia
  • %CSIDL_WINDOWS%\Installer

I have included these in a Package Template for Firefox that you can download from here:

App-V Package Template for Firefox App-V Package Template for Firefox

Installing Firefox

Download the Firefox installer in your target language from the Mozilla site. Sequencing Firefox will require the following steps:

  • Install Firefox
  • Configure profile defaults
  • Optionally add global add-ons and install plug-ins such as Adobe Flash Player

Automating this process as much as possible will create a cleaner package and make it faster to re-create a new Firefox package if required.

For an example script that will automate the install and configuration of Firefox, see the script below:

@ECHO OFF
SET SOURCE=%~dp0
SET SOURCE=%SOURCE:~0,-2%

REM Create the Firefox answer file
ECHO [Install] > %SOURCE%\Firefox8.ini
ECHO ; InstallDirectoryName=Firefox8 >> %SOURCE%\Firefox8.ini
ECHO ; InstallDirectoryPath=Q:\MozillaFirefox8_en-GB >> %SOURCE%\Firefox8.ini
ECHO QuickLaunchShortcut=false >> %SOURCE%\Firefox8.ini
ECHO DesktopShortcut=false >> %SOURCE%\Firefox8.ini
ECHO StartMenuShortcuts=true >> %SOURCE%\Firefox8.ini
REM Install Firefox - the START command will not work if the Firefox setup filename includes spaces
START /WAIT FirefoxSetup8.exe /INI=%SOURCE%\Firefox8.ini

REM Configure Firefox profile defaults
MD "%ProgramFiles%\Mozilla Firefox\defaults\profile\chrome"
COPY %SOURCE%\user.js "%ProgramFiles%\Mozilla Firefox\defaults\profile\user.js"
COPY %SOURCE%\userChrome.css "%ProgramFiles%\Mozilla Firefox\defaults\profile\chrome\userChrome.css"

Shortcuts

If the monitoring phase was successful the Sequencer should create a single shortcut for Firefox. If you are including Flash Player, add an additional shortcut for the Flash Player Control Panel applet using “C:\Windows\System32\FlashPlayerCPLApp.cpl” as the target.

First Run Tasks and Primary Feature Block

If the steps above have been followed for exclusions, installation and configuration of Firefox, there will be no first run tasks to complete. Additionally the resultant package will be reasonably small so there is no need to create the Primary Feature Block. Because you don’t need to complete first run tasks or create the Primary Feature Block, you could automate the entire end-to-end process of creating a Firefox package using the App-V Sequencer command-line interface.

Finally

Save your package and deploy. With compression enabled, the package should be around 22Mb.

Posted in Virtualisation | Tagged , | 8 Comments

Sequencing Google Chrome 15

GoogleChromeHere’s how to successfully sequence Google Chrome 15; however the same approach should work for Chrome 13, 14 and 16 and maybe even some other versions.

What you lose by virtualizing Chrome

Virtualizing Chrome with App-V will isolate the application from the OS, so the following features will not be available once Chrome has been sequenced:

  • Chrome Jump Lists in the Start Menu and Taskbar
  • The ability set the browser as default
  • The Chrome sandbox (maybe)

Note: Note that disabling the sandbox will reduce the browser security. This is not recommended and as such, I actually do not recommend virtualizing Chrome, if it is to be your regular browser.

Managing the Chrome profile – virtualize or not?

Chrome stores preferences, extensions and other user datain:

  • %LOCALAPPDATA%\Google\Chrome\User Data\Default (preferences, bookmarks etc. and browser cache)

I don’t know why Google has chosen this location by default, however I suspect that it may be to encourage users to signup for a Google account to enable the native syncing features of the browser. The Chrome User Data folder can become very large and that’s without the Cache folder. You could potentially hit the limit of the user PKG file size.

Whether you the Chrome user profile in the package will depend on your specific deployment requirements; however my recommendation is to use this sync feature and leave the User Data outside of the App-V package.

There are a couple of reasons why this approach is a good idea:

  • Some of the configuration files within the Chrome profile include hard-codes paths – challenging if your App-V virtual drive changes between clients
  • Virtualizing the profile increases the complexity of upgrading Chrome packages especially challenging given how often the browser is updated. By storing the Chrome profile on the real file system, Chrome can be deployed via completely unrelated packages – no need to create upgrade versions

By not virtualizing the user profile you will gain some flexibility with your Chrome deployment.

However, if you absolutely must place the Chrome profile in the virtual environment, then here’s a couple of approaches to including the User Data folder in the App-V package:

  1. Use the –user-data-dir and –disk-cache-dir command line parameters to specify an alternate location for the User Data and Cache folders
  2. Remove the exclusions for the Local AppData location from the Sequencer before sequencing

For the first approach, add the parameters to the command line, placing the User Data folder in the roaming portion of the profile and the browser cache in the local portion:

chrome --user-data-dir=%AppData%\Google\Chrome\User Data --disk-cache-dir=%LocalAppData%\Google\Chrome\User Data

The second approach doesn’t require any command line parameters, but it will require modifying the default Sequencer exclusions and some scripting:

  • Remove the default exclusions of %CSIDL_LOCAL_APPDATA% and %CSIDL_PROFILE%\Local Settings
  • Add an exclusion for %CSIDL_LOCAL_APPDATA%\Google\Chrome\User Data\Default\Cache or %CSIDL_PROFILE%\Local Settings\Google\Chrome\User Data\Default\Cache, depending on the operating system you are sequencing on
  • Post sequencing, set the folder to Merge with Local and add a pre-launch script that creates the Cache folder outside of the virtual environment

The first approach would be the easiest way to go.

Chrome features to disable

There are a couple of features that should be disabled when running Chrome under App-V:

  • Browser auto updates. Chrome updates should be delivered via new App-V packages
  • Default browser check. Once Chrome is isolated from the OS, the user won’t be able to make it the default browser

Disabling browser auto updates on Windows requires setting a policy. This can be done via Group Policy, delivered post sequence, or placing the policy directly into the package. To deliver the setting via Group Policy, ensure that the Policies key is not captured in the package.

To set the policy during sequencing, run the following command:

REG ADD HKLM\SOFTWARE\Policies\Google\Update /v AutoUpdateCheckPeriodMinutes /d 0 /t REG_SZ /f

Google Update should also be excluded from the package, which I discuss below. The default browser check can be disabled with a couple of approaches including the master preferences file.

Configuring Chrome Defaults

If a Chrome profile is not virtualized within the package any options set during the monitoring phase won’t be captured. Fortunately Chrome can be configured with defaults for any new profile so that it will contain your required configuration options. Google has made it simple to deploy custom default settings and preferences – by adding a preference file to the same folder where Chrome is installed, Chrome will use these master preferences for any new user who runs Chrome.

For information on what these master preferences are, see the Chromium administrators documentation on master preferences. I’ve included a sample master_preferences file in which I have set several defaults including removing the default browser check, preventing Google from adding a shortcut to the user’s desktop on first run and setting a home page.

Google Chrome Master Preferences Google Chrome Master Preferences

Remove the .txt file extension to use

Sequencing Platform

I have sequenced Google Chrome 15.0.874.106 on a clean Windows 7 SP1 x86 VM with all current updates and no other applications other than the App-V Sequencer. I’ve configured a Q: drive using a second vDisk. I’ve used a VFS install because installing Chrome to the Q: drive isn’t an option, unless you want to move the application manually.

Sequencer Configuration

Before Sequencing, add the following exclusions:

  • \REGISTRY\USER\%SFT_SID%\Software\Microsoft\Windows\CurrentVersion\Internet Settings
  • %CSIDL_COMMON_APPDATA%\Microsoft\RAC
  • %CSIDL_WINDOWS%\Microsoft.NET
  • %CSIDL_WINDOWS%\Installer
  • %CSIDL_PROGRAM_FILES%\Google\Update
  • %CSIDL_WINDOWS%\Tasks

The last two exclusions will prevent Google Update related binaries from being captured. Additionally disable the option to “Allow Virtualization of Services” to prevent the capture of the Google Update services.

I have included these options in a Package Template for Chrome that you can download here:

Google Chrome App-V Sequence Template Google Chrome App-V Sequence Template

Sequencing Chrome

Download the Google Chrome Enterprise (or MSI) installer. Sequencing Chrome will require the following steps:

  1. Install Chrome using the Windows Installer file
  2. Delete the cached copy of the Chrome installer, which won’t be required once delivered with App-V
  3. Move chrome.exe to the same folder as the current version’s binaries (or vice-versa).

With the default folder structure, Chrome will execute during sequencing, but won’t execute once delivered to a client. The debug.log file will contain entries similar to this:

[1106/180706:ERROR:client_util.cc(231)] Could not get Chrome DLL version.
[1106/180706:ERROR:client_util.cc(268)] Could not find exported function RelaunchChromeBrowserWithNewCommandLineIfNeeded
  1. Copy the master_preferences file to the same location as chrome.exe to configure user profile defaults
  2. Disable browser auto updates
  3. Prevent the Sequencer from deleting the Chrome application folder once the monitoring phase is finished. To see why the Sequencer may process a reboot task that deletes the Chrome install folder read this article: The Case of the Disappearing Application during Sequencing.

Automating this process as much as possible will create a cleaner package and make it faster to re-create a new Chrome package if required. Here’s an example script that will perform the tasks above:

START /WAIT GoogleChromeStandaloneEnterprise.MSI ALLUSERS=TRUE /QB-
RD /Q /S "%ProgramFiles%\Google\Chrome\Application\15.0.874.106\Installer"
ROBOCOPY "%ProgramFiles%\Google\Chrome\Application\15.0.874.106" "%ProgramFiles%\Google\Chrome\Application" /mov /e
COPY master_preferences "%ProgramFiles%\Google\Chrome\Application\master_preferences
REG ADD HKLM\SOFTWARE\Policies\Google\Update /v AutoUpdateCheckPeriodMinutes /d 0 /t REG_SZ /f
REG ADD "HKLM\System\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations /d "" /t REG_MULTI_SZ /f

Shortcuts

For Chrome to run successfully under App-V there are a few additional command line parameters that will need to be added to the Chrome shortcut at the configure applications stage:

  • –disable-custom-jumplist: Disables the Windows 7 Jump List, which doesn’t work once Chrome is virtualized any way
  • –no-default-browser-check: A further flag to prevent the browser from prompting the user to set it as default
  • –in-process-plugins: Run plugins inside the renderer process. May be optional, but has been required in the past when virtualizing Chrome
  • –no-sandbox: Not required; however I have found that extensions do not install if this parameter has not been added

For the full list of command-line parameters for Chrome and Chromium see this page: List of Chromium Command Line Switches

With the sandbox running, you will see an error similar to this when attempting to add an extension:

ChromeExtension

Note: Note that disabling the sandbox will reduce the browser security. I recommend testing the browser functionality and see if you can get away without disabling the sandbox.

The browser will notify you when the sandbox is disabled:

GoogleChromeNoSandbox

First Run Tasks and Primary Feature Block

If the steps above have been followed for exclusions, installation and configuration of Chrome, there will be no first run tasks to complete. Additionally the resultant package will be reasonably small so there is no need to create the Primary Feature Block. Because you don’t need to complete first run tasks or create the Primary Feature Block, you could automate the entire end-to-end process of creating a Chrome package using the App-V Sequencer command-line interface.

Finally

Save your package and deploy. With compression enabled, the package should be around 36Mb.

Posted in Virtualisation | Tagged , | Leave a comment

The Case of the Disappearing Application during Sequencing

In the official Microsoft TechNet forums, a question had been asked about sequencing Google Chrome and the poster states that when using the Chrome Enterprise Installer (a downloadable MSI for deployment inside an organisation), Chrome installs OK during the monitoring phase, but the folder is deleted at the end of monitoring and thus isn’t captured.

I thought that that behaviour was a little strange, so decided to test this out myself and to my surprise I could replicate the issue. To track down what was going on, I had to perform some troubleshooting.

I tested this on a virtual machine running Windows 7 SP1 x86 and could see from browsing to the Google installation folder (C:\Program Files\Google\Chrome) that the Application sub-folder was being removed after the monitoring phase was complete. To work out which process was deleting the folder, I’ve used Process Monitor. To see what was going on, I’ve reset my VM back to a clean snapshot, started the App-V Sequencer and Process Monitor and set a filter in Process Monitor for Path beginning with C:\Program Files\Google\Chrome\Application and then re-started the sequencing process.

ProcessMonitorFilter

With this filter, I was able to see that the process that was deleting the folder is the Sequencer itself (SFTSequencer.exe). Click the screenshot for a larger view.

ProcessMonitorDeletes

The next most obvious place to look then is the Sequencer log file, hopefully it will hold some information about why the folder is being deleted. To view the Sequencer log, browse to C:\Program Files\Microsoft Application Virtualization Sequencer\Logs and open sft-seq-log.txt.

In this file I can see a number of lines where the Sequencer is attempting to copy files that no longer exist:

[11/03/2011 21:45:34 VRB VFSX] ...failed getting long path name for the file (C:\Program Files\Google\Chrome). Error: 2
[11/03/2011 21:45:34 VRB CORE] GetShortPathName failure using: C:\Program Files\Google\Chrome. Error is: 2
[11/03/2011 21:45:34 VRB CORE] Could not copy C:\Program Files\Google\Chrome to Q:\Google Chrome\VFS\CSIDL_PROGRAM_FILES\Google\Chrome.  Error is: 2.
[11/03/2011 21:45:34 VRB VFSX] ...failed getting long path name for the file (C:\Program Files\Google\Chrome\Application). Error: 3
[11/03/2011 21:45:34 VRB CORE] GetShortPathName failure using: C:\Program Files\Google\Chrome. Error is: 2
[11/03/2011 21:45:34 VRB CORE] Could not copy C:\Program Files\Google\Chrome to Q:\Google Chrome\VFS\CSIDL_PROGRAM_FILES\Google\Chrome.  Error is: 2.
[11/03/2011 21:45:34 VRB CORE] CopyResourceToVFS failed.
[11/03/2011 21:45:34 VRB VFSX] ...failed getting long path name for the file (C:\Program Files\Google\Chrome\Application\15.0.874.106). Error: 3
[11/03/2011 21:45:34 VRB CORE] GetShortPathName failure using: C:\Program Files\Google\Chrome. Error is: 2
[11/03/2011 21:45:34 VRB CORE] Could not copy C:\Program Files\Google\Chrome to Q:\Google Chrome\VFS\CSIDL_PROGRAM_FILES\Google\Chrome.  Error is: 2.
[11/03/2011 21:45:34 VRB CORE] CopyResourceToVFS failed.

A few lines previous to these is this line:

[11/03/2011 21:45:26 VRB RTSK] Reboot processing detected need to delete \??\C:\Program Files\Google\Chrome.

The Sequencer is doing exactly what’s it being told to do – process a reboot task at the end of the monitoring phase and delete the application. Interestingly though, only the Application sub-folder is being deleted, not the entire Chrome parent folder.

To get an idea of why, I’ve used WhyReboot, a fantastic free tool for finding out why a reboot has been requested. How many times have you suspected that an application installer asks to reboot Windows when it’s not actually needed?

Going through the sequencing process again and running WhyReboot before ending monitoring, gives me an idea of why the reboot has been requested:

WhyReboot

Note: I could also use PendMoves another Sysinternals tool to query this information as well.

PendingFileRenameOperations is a Registry value that lists file system operations that must be processed during a reboot or shutdown. Generally these types of operations need to be processed on reboot because there are open file handles that are only released once the system shuts down.

So what’s writing this entry to PendingFileRenameOperations and why does this only happen during sequencing? To find out, I’ve reached for Process Monitor again, but unfortunately I haven’t been able find which process is writing to the PendingFileRenameOperations value, as Process Monitor didn’t find any RegSetValue operations.

ProcessMonitorPendingFileRenameOperations

Circumstantial evidence points to SETUP.EXE, but without Process Monitor giving me more information I can’t say for sure. I do however, have a workaround that allow me to sequence Chrome – before finishing the monitoring phase, I clear the PendingFileRenameOperations data with this command:

REG ADD "HKLM\System\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations /d "" /t REG_MULTI_SZ /f
Posted in Virtualisation | Tagged | 7 Comments