Installing under one user, running updater as another user

[SQLScott]

We have a scenario that we cannot get to work that we would like some help with, and we are hoping you guru's have the answer.

We have been successful in getting web updates to work (patch and full updates).

However, that is ONLY when everything is done under the same user. We are having problems when the install and updater configuration is done under one user but executed when logged in as someone else.

For example:

1) I log into my pc using my credentials (I am an administrator on my pc) and run the install.
2) I reboot my pc and upon logging in, get prompted to configure the update. I configure the update using my same set of credentials.
3) I then log off, and then log in as a local user (non admin).

Prior to the execution of the update, I open Task Manager. When the udpate (the scheduled task) executes, I see it in Task Manager. However, the update appears to "hang". Meaning, the update doesn't happen and the task remains in Task Manager. I have waited 15 minutes and it is still there, and verified that the application has not been updated.

Like I said, this works perfectly if I do everything as the same user.

This is critical for us. The users of our application are remote (thus the need for web updates).

Any ideas? Thanks, and greatly appreciated.

Scott

[JeffryPaul]

With the advent of Vista's enhanced security, the use of scheduled tasks to apply updates (regardless of logon user) has reached an untimely end.

http://msdn2.microsoft.com/en-us/library/bb203962.aspx

Session 0 Isolation: Services have always run in session 0. Before Windows Vista, the first user to log on was also assigned to session 0. Now, session 0 is reserved exclusively for services and other applications not associated with an interactive user session. (The first user to log on is connected to session 1, the second user to log on is connected to session 2, and so on.) Session 0 does not support processes that interact with the user.

IMHO, the only viable solution is for Installaware to provide us develoers with an Installaware Update service that can look for updates for all Installawre applications (rather than configuring multiple update services). It should also interact with the active user's desktop.

[MichaelNesmith]

We try not to do this with a service for a multitude of reasons:

1. Reducing the attack surface on the target machine. As you may have heard, InstallShield's update service compromised a lot of machines last year - a very upsetting outcome for most developers, no doubt, since its not even their fault!

2. Conserving system resources (possibly lesser of a concern given modern machine specs).

3. Providing update source code in a form you can edit - MSIcode script and dialogs that you can freely customize.

A hard coded service would lose all of the above benefits. Keep in mind that you can still do pretty much whatever you wish based on our template update script codes.

[JeffryPaul]

The most important aspect of updates for me is the ability to automatically download and install updates. If the user wants to do this, the updates should be downloaded and installed without prompting or any other notification; it should just work. Here's how I got it working:

If the user selects to automatically download and install updates:
a. schedule the update task using the SYSTEM account (no password, no domain), and bypass the account screen altogether.
b. The update task command line is "$UNINSTALLLINK$ /update /s" Since the scheduled task will not interact with the system, the /s is necessary to disable the interaction with the desktop.
c. Modify the update script to check for UPDATE_AUTO = TRUE. If true, then install the updates with "/s" parameter regardless of how updates.ini is configured.

[MichaelNesmith]

That's a great post!

Thank you Jeffry!

[JeffryPaul]

I should have given the caveat that this works only for VISTA only.
For some unknown reason the Schedule Task command in XP still enables the "run only if logged on" option even if scheduling the task as SYSTEM. Go figure...

[MichaelNesmith]

Did you uncheck the Interactive Task option in the Schedule Task command?

[MichaelNesmith]

I have been able to verify that this setting is currently forced by Schedule Task, apparently it doesn't stick on Vista but that explains why it sticks on XP with the SYSTEM account.

We'll take care of this for you and add a new flag to the Schedule Task command.

[Steve]

Hello Michael,
In your last post (above) you mentioned:

We'll take care of this for you and add a new flag to the Schedule Task command.

This was with regard to an update for the behaviour of the Interactive Task option (in the Schedule Task command) when used in XP.

Can you please tell me if this update has been completed and if so , how InstallAware customers can obtain this update.

Thanks vey much

[MichaelNesmith]

Yes, this is in-place in InstallAware 9. The command window now has an additional check-box exposing the extra functionality.