InstallAware

I have a single-EXE application that must always run with the latest version (forced updates), even if run by a limited user. I currently have a custom-built update mechanism that handles this, but I like some aspects of InstallAware's facilities. I have read the WebUpdates whitepaper.

The only way I can see to ensure that an app runs with the latest version is to check for available updates every time the app runs. If there are other options, let me know, but assuming that is the only way to do it, I need to know if IA's WebUpdates can support the following, either out of the box or with some moderate custom scripting on my part:

- IA's update client can be called from my app (yes, according to whitepaper)
- disable any update schedule (I know from the whitepaper that a) the scheduler must be run once and b) the installer can run the update client scheduler function silently, but I don't know if that method can be used to configure the update client to have no schedule at all). Updating on a schedule is superfluous and potentially counter-productive in my use-case.
- IA's update client, when called from the app, can update the app without a reboot. I am open to suggestions about how this might be possible, but if the update client can return an exit code indicating that an update is available without installing the update, then my app could invoke the update client again and immediately terminate before the update client tries to overwrite the app's EXE.
- IA's update client runs the app automatically after an update (yes, according to installaware.com)
- IMPORTANT: update the app's EXE even if the app is run without admin privileges (keep in mind that the app is invoking the update client, and the user running the app may not have admin privileges). In my current system, I make this work by having the app be installed to %APPDATA% rather than Program Files.
- ALSO: app is originally installed by user with admin privileges for a single user (who might not have admin privileges).

There are a couple additional things my current system doesn't do that would be nice to have:
- app is installed by user with admin privileges for all users, but some users forcing updates might not have admin privileges. (Again, keep in mind that the app EXE is invoked without admin privileges, and it in turn invokes the update client)
- app can be installed as an MSI by GP, in some way that allows for forced updates later when the app is invoked by a non-admin user. (I know nothing about GP)

Hey,

- Yep - thats possible, just is described in the white paper

- Unfortunately, no. However, what you could do, is edit the updates MSIcode script and control the flow of the update yourself (for example by keeping count in the registry). Remember, the update script is coded in MSIcode.

- You could have your update script terminate your program (or signal it to terminate) and then restart it when its done - is that what you meant?

- Yes, that is indeed possible, again by editing the updates MSIcode script.

- I doubt this will work, however you can give it a shot and play around with it.

giaviv wrote:Hey,

- Yep - thats possible, just is described in the white paper

- Unfortunately, no. However, what you could do, is edit the updates MSIcode script and control the flow of the update yourself (for example by keeping count in the registry). Remember, the update script is coded in MSIcode.

- You could have your update script terminate your program (or signal it to terminate) and then restart it when its done - is that what you meant?

Yes, that is what I meant. I take it that your first 3 replies correspond to my first 3 questions.

giaviv wrote: - Yes, that is indeed possible, again by editing the updates MSIcode script.

- I doubt this will work, however you can give it a shot and play around with it.

I regret not numbering my original points, as I am not sure which points the above 2 answers refer to. For expediency, I am re-listing and numbering my last 5 points, as some of them didn't get responses:

4) IA's update client runs the app automatically after an update (yes, according to installaware.com)
5) IMPORTANT: update the app's EXE even if the app is run without admin privileges (keep in mind that the app is invoking the update client, and the user running the app may not have admin privileges). In my current system, I make this work by having the app be installed to %APPDATA% rather than Program Files.
6) ALSO: app is originally installed by user with admin privileges for a single user (who might not have admin privileges).

There are a couple additional things my current system doesn't do that would be nice to have:
7) app is installed by user with admin privileges for all users, but some users forcing updates might not have admin privileges. (Again, keep in mind that the app EXE is invoked without admin privileges, and it in turn invokes the update client)
8 ) app can be installed as an MSI by Group Policies, in some way that allows for forced updates later when the app is invoked by a non-admin user. In other words, does using the Group Policies MSI option in InstallAware in any way impact the options or functionality available with WebUpdates?

4) IA's update client runs the app automatically after an update (yes, according to installaware.com)
5) IMPORTANT: update the app's EXE even if the app is run without admin privileges (keep in mind that the app is invoking the update client, and the user running the app may not have admin privileges). In my current system, I make this work by having the app be installed to %APPDATA% rather than Program Files.
6) ALSO: app is originally installed by user with admin privileges for a single user (who might not have admin privileges).

There are a couple additional things my current system doesn't do that would be nice to have:
7) app is installed by user with admin privileges for all users, but some users forcing updates might not have admin privileges. (Again, keep in mind that the app EXE is invoked without admin privileges, and it in turn invokes the update client)
8 ) app can be installed as an MSI by Group Policies, in some way that allows for forced updates later when the app is invoked by a non-admin user. In other words, does using the Group Policies MSI option in InstallAware in any way impact the options or functionality available with WebUpdate

4) Yes, that is indeed possible, again by editing the updates MSIcode script.
5, 6) I doubt this will work, however you can give it a shot and play around with it.
7) Again this goes back to 5) - I doubt it will work but you can try.
Same as previous answers. Though I guess you are really asking a GP question that you are better off asking a GP expert. Running the Group Policy Wizard does not affect the functionality of web updates.

Thanks for your reply. I'm eager to try this out for myself, but I asked because I presently can't get IA to install my app in a user rather than machine folder (this is the issue you are helping me out with in this topic: http://forums.installaware.com/viewtopic.php?f=2&t=6646 )

Let me ask this instead:

a) With scheduled updates, under which account does the IA update client run? e.g. SYSTEM, domain admin, local admin, whichever account that originally installed the software, etc.
b) With manual updates, does the IA update client run under the same account as with scheduled updates? If not, which account?

Hey,

a) The end user can choose which account he wants to run the scheduled update under
b) This is hard-coded in the MSIcode script called updates - this is the script in charge of your update mechanism. You can look at it and review what it does, it will give you a better idea of how the update mechanism works.

giaviv wrote:Hey,

a) The end user can choose which account he wants to run the scheduled update under
b) This is hard-coded in the MSIcode script called updates - this is the script in charge of your update mechanism. You can look at it and review what it does, it will give you a better idea of how the update mechanism works.

For a): Which accounts appear in the list? Does it vary depending upon the rights of the current user? If the scheduler is being invoked silently, can the account be selected via the the command line?

For b): Where can I find the updates script? I don't have access to msiCode, but if it's human readable, I can find a way to review it.

Thanks again for all your replies, and I am appreciative that you are continuing to answer my queries. I don't mean to be a pain, but permissions issues with updates can be tricky in some environments. I'd like to suggest that the WebUpdates whitepaper be updated to address permissions issues (updates by limited users, manual updates by users other than the user that performed the initial installation,etc.).

a) you simply enter your username and password.
b) I would recommend downloading the InstallAware 10.10 trial.
When you go to the Design tab and check Receive Application Updates under the Project Properties section, a script called updates is automatically added to your MSIcode Included Script (MSIcode tab). Even if you can't edit it, you will be able to look at it - it is definitely human readable.

giaviv wrote: b) I would recommend downloading the InstallAware 10.10 trial.
When you go to the Design tab and check Receive Application Updates under the Project Properties section, a script called updates is automatically added to your MSIcode Included Script (MSIcode tab). Even if you can't edit it, you will be able to look at it - it is definitely human readable.

Will do. I assume that 10.10 trial be installed without uninstalling my current non-trial version.

Which version do you currently have installed?

giaviv wrote:Which version do you currently have installed?

CodeGear Special Edition. Seems to be equivalent to IA 7 R2 Express

I would recommend installing IA 10 on a clean virtual machine to prevent conflicts with your currently installed version.

giaviv wrote:I would recommend installing IA 10 on a clean virtual machine to prevent conflicts with your currently installed version.

OK, thanks. I figured the trial version wouldn't work in a VM, but that's great.

It definitely would - I got a bunch of them set up over here