Software Deployment

Athi,

You may want to rethink your use of an MSI for the purpose of what you're trying to accomplish since reinstalling an application just to change registry settings "true/false" can't be very efficient...I'll assume you've explored all other options and this is what you determined the best for your environment and leave it at that :).

Have you considered every time you need to modify your msi to actually create it as an upgrade of the previous one? So have you version1.msi with registry settings true, then you create version2.msi with registry settings false and you add version1.msi to its upgrade table.

So, you're changing the version of the msi per each deployed version of it (as you should), it will upgrade previously installed version, and it will have it's own ActiveSetup entry to trigger at log on. This should accomplish what you're trying to do...right or not :P.

Yes, the Upgrade every time will solve my problem. But my scenario is different. Just to change a reg setting, do i need to ask the admin to run an Upgraded version? He can change setting by installing the same MSI with REINSTALL=ALL option in command line while running msiexec, right? This option changes the reg entry for current user context. But I need this change to propogate to other users (non-admin) of the machine.

The scenario is like the Admin pushed the MSI with a mispelled db connection string. Then the non-admin users logged in and got the application installed with that mispelled connection string via Active Setup. Now the admin realizes that he needs to push the MSI with corrected db connection string with the following command.

msiexec.exe /i MyProduct.msi DB_CONNSTR=<Conn Str> REINSTALL=ALL /qb

Admin's HKCU has the corrected db connection string now. I need the corrected one for the non-admin users HKCU.

Any workaround I can apply to get the corrected db conn string?

What is the difference between modifying an MSI to change a registry setting, updating whatever your distribution points are, and then sending out a reinstall vs modifying an MSI to change its Product code, add the upgrade, change a registry setting, updating whatever your distribution points are, and then sending out a new install?

Seems like nearly the exact same thing...and it solves your problem, no?

[Edit: forgot the upgrade part :) ]

Ok. The Option (DB conn str) admin changes when he does reinstallation is exposed via a property variable and a custom action script modifies it to the new value provided. So, the admin can change the value as and when required, just by running the MSI again with REINSTALL=ALL along with the modifying property in command line.

When I install the product, I can key in any DB connection string, thats why it is exposed to the admin user to change it. When I install the product by double clicking the MSI, the UI sequence asks for the same connection string in a dialog and that is what Admin tries it via command line with the help of REINSTALL=ALL when he wants to modify it.

If that property is hardcoded and handled inside MSI rather than user driven value, I could have created a new version MSI with different Product Code and Version which will automatically triggered by Active Setup for non-admin users.

Is this makes sense?

i am guessing english is not your first language as this is so difficult to grasp what you are after.

AS to install
Landesk to install
AS to repair ?

wtf does all this mean.

I am guessing you want to be able to easily set properties and have them changed easily. This does that.

http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!197.entry