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 
.
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’..
