Software Deployment

ORIGINAL: chipfork

I'm a bit stuck with an application patch/upgrade issue, the problem being existing HKCU registry data that needs to be updated.

Overview
I've a relatively simple repackaged application. The application configuration is defined on a per-user basis, i.e. HKCU\Software\AppName. So I've connstructed a parent level "CurrentUser" feature and a couple of sub-features with the core application and some other configuration.
I've used Property to define an IP address used by the application (it can't use host names and the developers even struggle with file versioning, they use it but can't remember to increment during releases [:@]). This property is used solely in the HKCU registry, some ODBC configuration (User DSN) and two custom actions which I use to manage/update the HOSTS file. This application has been deployed, many users have logged on to these machines, the application has self-repaired on launch and populated any user configuration as required.

Objective
The IP address needs to change (if only these developers could use host names - I have asked). So I need to install a patch or upgrade that will fix the IP address. Ideally it will need to be able to trigger a repair/update of the relevant HKCU registry keys when the user next launches the application.

Results
I've dabbled with patches and upgrades with varying results. I've tried restructuring the features and adding keys etc. to try and trigger an HKCU self repair as required but nothing that works as I need it to. The stumbling block seems to be fixing existing keys (because they're present, inducing self repair needs additonal non-present keys/values).

Ideally I want the application to "msiexec /fu newapp.msi" when the user launches the application the first time after the application is patched or upgraded.

Conclusion
The easiest option I can see is to create a patch which includes some ActiveSetup config to repair the HKCU registry keys in question (reg patch or msiexec /fu). However this relies on the user logging off and on and these machines are often left on for months at a time and getting the management system to induce a logoff event could be awkward.

Any suggestions/advice would be much appreciated.

Many thanks

Looks like you've researched this pretty well. All I can suggest is a couple of good links giving different approaches to Active Setup. Active setup is the only way I can think of unless you can figure out a way to force a logoff, which would be problematic.
This link is on appdeploy
This one is from Ed Tippelt

But basically it seems like it's an app architecture problem if you have to jump thru hoops to do all these updates. Is it really a per user config or a machine config? Will it really be unique to each user?

Hi Iain,
this shouldn't be an installer job, IMHO.
This belongs to the application responsibilities
For a quick and dirty approach, i would start the main app indirectly through a batch job or script and update this ip-address on each launch.
Regards, Nick

Thanks all.

It's definately per user, it's to do with the licencing principally and different users will have different configs depending on their role, however that could have still be managed by the app without incorporating machine specific properties into the HKCU config.

I've a patch which includes the revised configuration and an Active Setup routine: MSIEXEC /FU {App-Prod-ID}. That works fine but it does rely on a logoff in between. I can enforce this through our management software, I can use our wrapper to make sure the logoff event is managed so that users won't lose data.

However I figured I could upgrade the existing application and rely on self repair as a user launches the advertised shortcut. Here's what I tried quickly before I realised my mistake.

I added a new feature "PatchTCPIP1" because a patch or upgrade needs a new component/feature for these sorts of changes (so Wise UpgradeSync tells me - could I just create a new component? - will have to try that).

Features:

CurrentUser
PatchTCPIP1 (contains revised config)
CoreApp (contains entry point - advertised application EXE)
ODBC

After the app is patched and the user launches it, the app self repairs. I thought it would perform component level repairs in only the PatchTCPIP1 feature, however I think (I'll check the logs) that this is repairing the parent, "CurrentUser" last - i.e. back to the original config. I was going to try to make this the top parent level feature and then see how it behaves.

Thanks.