velogo
  • Home
    • About Us
    • Our Approach
    • Partners & Vendors
  • Services
    • Consultancy
      • Windows 11 Migration Service
      • NHS N365 Migration Service
      • Defender for Endpoint Migrations
      • Intune Health Check
      • Intune for Mobiles Migration
    • Managed Services
      • Modern Device Managed Service
      • Evergreen Package Service
      • Microsoft Automated Upgrade Service
      • Microsoft Azure Virtual Desktop
      • Ivanti Patch Management
  • Solutions
    • Modern Device Management
    • Desktop as a Service
    • Cloud
    • Secure Access
    • Cloud Migration
  • Support
    • Service Desk
  • Success Stories
    • Events
    • Success Stories
  • Contact
Menu
  • Home
    • About Us
    • Our Approach
    • Partners & Vendors
  • Services
    • Consultancy
      • Windows 11 Migration Service
      • NHS N365 Migration Service
      • Defender for Endpoint Migrations
      • Intune Health Check
      • Intune for Mobiles Migration
    • Managed Services
      • Modern Device Managed Service
      • Evergreen Package Service
      • Microsoft Automated Upgrade Service
      • Microsoft Azure Virtual Desktop
      • Ivanti Patch Management
  • Solutions
    • Modern Device Management
    • Desktop as a Service
    • Cloud
    • Secure Access
    • Cloud Migration
  • Support
    • Service Desk
  • Success Stories
    • Events
    • Success Stories
  • Contact

Tag: User Preferences

Posted on 20th February 2012

RES Workspace Manager Migration Settings

Following on from the Application Upgrades in RES Workspace Manager post, I thought I would put pen to paper to put to bed the confusion surrounding the whole “Migration settings” for RES Workspace Manager 2011 User Preferences/Settings. In fact, RES Workspace Manager allows for two separate types of User Settings migration; the migration of user settings stored in a previous location and migration of User Settings when switching between Zero-Profiling modes (from RES Workspace Manager 2011 SR2 onwards). There is often the miscomprehension that the migration options will automagically migrate user settings between defined applications, i.e. Word 2003 to Word 2007. This is categorically not the case (and will be a future post!). So what are the differences between the two options?

User Settings Storage Migration

This option available under the Composition > User Settings within the RES Workspace Manager console allows you to migrate stored User Settings from a previous location and looks just a little bit like this:

image

When would we enable this option? You will use this option when you want to move or copy settings stored in a prior location to an alternative location. Historically, RES PowerFuse always required that you stored the user’s User Settings in their home drive location. Although hidden, this could quite often cause confusion and had serious consequences if hard quotas were in place.

Starting with RES Workspace Manager 2011, this is no longer the case. User Settings still have to reside within an assigned drive letter location, but this no longer has to be the same location as the user’s home directory. This very option enables you to migrate existing user settings from a previous location to another drive. Nothing more, nothing less (and no migration of settings defined behind a Word 2003 application to Word 2007!). Here’s an example:

  • User home directories are mapped to H: and you previously stored the User Settings in the \PWRMENU subfolder (may or may not be mapped via Active Directory).
  • You wish to store User Settings in the X:\UserSettings folder that will be hidden by RES Workspace Manager (how and where you map X: are up to you!).
  • Configuring the migration settings as above will move all the User Settings from H:\PWRMENU to X:\UserSettings, but only if they exist.
  • All new captured User Settings will be put into X:\UserSettings.

Zero-Profile Migration

The second User Settings migration option allows you to migrate existing User Settings captured with one Zero-Profile mode to the other, i.e. migrate UPR/UPF files to/from UPR2/UPF2 files. You may or may not know this, but the way in which RES Workspace Manager stores User Settings depends on the configured Zero-Profile mode. If an application is configured to “Capture” then the settings are stored in the traditional format, e.g. .UPR and .UPF files. If you happen to configure an application in “Tracking” mode then you’ll end up with .UPR2 and .UPF2 files. I am informed that this is due to the fact that tracked settings are appended to the resulting file (and compressed) as they’re changed etc.

By default, if you switch from one Zero-Profile mode to another, RES Workspace Manager will suddenly be looking for User Settings files that don’t exist. Worse still, if you happened to have had the other mode configured for a while, changed it and then reverted, you may place some old Users Settings back into the user’s profile!

The migration setting on the User Settings tab behind an application is designed to help avoid this situation and migrate the captured User Settings to/from UPR/UPR2 (and UPF/UPF2) files.

image

The settings above have the following definitions:

  • Ignore – RES Workspace Manager will ignore the other file type (if present) and start capturing in the configured mode.
  • Remove – RES Workspace Manager will delete the User Settings stored (if present) in the alternative format.
  • Apply and Remove – RES Workspace Manager will migrate the stored User Settings (if present) and then delete the alternative format.

All this is fairly straight forward once you know the in’s and out’s (and still no migration of settings defined behind a Word 2003 application to Word 2007 regardless of the configured Zero-Profile mode!). You can manually move User Settings from one application to another and this might be a future post or even make it into the Virtual Engine Toolkit.

As always, I hope this helps clarify things for somebody, some day! Iain

Posted on 6th September 2010

Capture Targeted Items Once, Then Track Further Changes

New in RES PowerFuse 2010 Service Release 2 (are they being called Service Packs now!?) is the “Capture Targeted Items Once, Then Track Further Changes” option that applies to User Settings. This has been introduced to solve a particular problem and I’d thought I’d elaborate on this a bit further.

There are two modes of operation with User Settings at an application level within PowerFuse; “Track specified settings on application/session start/end” and the new“Track any setting changed by the application immediately” settings.

Track Specified Settings on Application/Session Start/End

This is the legacy PowerFuse 2008 User Preferences mode. During an upgrade to PowerFuse 2010, User Preferences are preserved in this mode.

To capture user registry and profile information, the items we wish to capture have to be explicitly defined. That is to say, ‘if we don’t tell PowerFuse exactly what we want to capture, it won’t be captured and won’t necessarily persist across user sessions’.

It works well, but as administrators we need to know where in the profile/registry application settings are stored and more importantly, what actually to we need to capture for our users. Many an hour will have been spent running applications with SysInternal’s Process Monitor to find out what an application is doing and then transferring this in to PowerFuse. If you’ve been using Mandatory profiles then you’ll know how painful and laborious this can be. Fret not – I feel your pain!

Track Any Setting Changed by the Application Immediately

Welcome to 2010. The ‘zero profile’ mode in PowerFuse 2010 is our saviour! What the new mode means is that we no longer need to know exactly where an application is making changes as the AppGuard and RegGuard drivers can monitor the application process and capture any changes that are made the HKCU registry hive or the user’s Profile directory.

Now don’t get too excited (you knew that was coming didn’t you!?)… It doesn’t always work and we have to revert to the old PowerFuse 2008 way of doing things if external processes are involved. Fortunately, these are the exception and not the norm.

The Problem

Unfortunately for us, this has one major short coming. If you deploy RES PowerFuse 2010 in to an existing site (not running RES PowerFuse 2008 previously) to capture user settings (read Stealth Mode here), then changes to user settings will be captured and stored in the user’s UserPref folder. But (and it’s a BIG BUT!), only the changes are captured. Therefore, if a user does not make a change settings within an application that may have been changed prior to deployment, they are never captured. DOH! Now my Windows XP to Windows 7 migration is never going to work Angry smile.

The Solution

This my friends is where the ‘Capture Targeted Items Once, Then Track Further Changes’ comes in. It does exactly what it says. The first time PowerFuse is invoked for the user the defined settings will be captured once. From then on it’ll track only the changes made to the user’s registry and profile directory. It solves the issue of not capturing the settings that the user never changes. Again, we’re back to square one and have to know roughly where the application settings are stored to be able to capture them the very first time PowerFuse kicks in.

Fortunately for us, our kind friends at RES have provided us with some application Templates for the major applications and system settings. This is another blog post, but even they’re still not perfect and need the odd ‘tweak’..

Recent Posts

  • Mocking Missing Cmdlet Pipelines with Pester
  • App-V 5 Configuration Editor (ACE) v1.4 Released!
  • Configuring CredSSP for Deploying XenDesktop via DSC
  • Deploying Citrix XenDesktop 7 with DSC
  • Mocking Missing Cmdlet ErrorAction with Pester

Recent Comments

  • Iain Brighton on App-V 5 Configuration Editor (ACE) v1.4 Released!
  • Ralf Lippok on App-V 5 Configuration Editor (ACE) v1.4 Released!
  • Arenas on Updating and Writing XML Files with PowerShell
  • Nqobizwe Ngubane on Creating .CAB files with Powershell
  • Rinzler on Updating and Writing XML Files with PowerShell

Archives

  • September 2015
  • August 2015
  • June 2015
  • May 2015
  • January 2015
  • May 2014
  • April 2014
  • August 2013
  • July 2013
  • May 2013
  • April 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • October 2009
  • September 2009

Categories

  • ACE
  • App-V
  • Blog
  • Citrix
  • JET
  • JETCMD
  • Latest News
  • PowerShell
  • RES
  • Training Schedule
  • Uncategorized
  • VDI
  • VET

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org
  • Privacy Policy
  • Terms
  • Cookies Policy
Menu
  • Privacy Policy
  • Terms
  • Cookies Policy

Virtual Engine Limited
450 Brook Drive, Green Park, Reading RG2 6UU

  • +44 (0)20 3855 0000
  • info@virtualengine.co.uk
  • virtualengine