Vista - VISTA and Power Users?

On Jul 13, 5:02 pm, Jimmy Brush <j...@mvps.org> wrote:
> > As one of the alternate deployment methods your provided...
>
> > "1) seperate out your updater into another .exe, run it as a
> > scheduled
> > task or service, and have it launch the new .msi when it finds one.
> > Since the .msi will be launched from a service or a scheduled task
> > running as system, it has admin power, and so can install without
> > user
> > interaction. Be sure you run your setup in quiet mode for this, since
> > it
> > won't be able to display anything to the user (since it is running
> > outside of any user account and inside of a system account)."
>
> > I tested the Task method in the following manner, I logged in as
> > Administrator and added the Task. I used a small test .msi and
> > ensured that it prompted for elevation as the logged on Admin. After
> > removing the small test app., I tried installing via my Scheduled
> > Task, which appeared to work. I tested a small update in this manner
> > in this way too and it worked. I installed the initial app. manually
> > as we will do, then updated with the task and all looked OK.
>
> > Now I tried the same thing with a Standard User (UAC enabled) and all
> > worked OK here too, but it appears the Task has to be built as an
> > Admin. I guess because of using the System account. When I tried to
> > import the task into my Standard User's Task Administration, I got a
> > no-no message. Can't import this type of action.
>
> Standard users generally cannot create/modify/start tasks. You can
> create tasks programmatically from your main install using the COM
> interface to the task scheduler.
>
> http://msdn2.microsoft.com/en-us/library/aa384006.aspx
>
> > Another question that arises is will the Task, built while an Admin
> > was logged in, fire when trigger event arises if the Standard User is
> > the current login?
>
> Yes, a task follows its triggers regardless of which user is logged on.
> Note that a task running inside of a system account can run even if no
> user is logged in (depending on your specific triggers, of course), and
> will never be visible on the screen.
>
> > This looks promising. I would guess the service would function in a
> > similar manner.
>
> Yes, services are similar for what you are doing, except they require
> the .exe to be created differently than a normal program (different
> entry point, and it must handle messages from the service control
> manager, e.g. start, stop, etc).
>
> Services can never be visible on the screen.
>
> > THANKS FOR ALL THE HELP TO THIS POINT!
>
> You're welcome.
>
> --
> -JB
> Microsoft MVP - Windows Shell/User
> Windows Vista Support FAQ -http://www.jimmah.com/vista/- Hide quoted text -
>
> - Show quoted text -

I have a few more questions about using a task or service, which
regard specific user data written during our initial installs. If a
Standard User installs (after elevating processing), information is
written to the users profile in the form of an .ini file. How would
this information be updated correctly if run via the task or service
(run as SYSTEM account)? Or, is this not really possible or easily do-
able?

The reason I ask is because, for a Standard User, our updating
mechanism is failing. During the initial install, version information
is written to that user's roaming profile area in MyApp.ini. Now,
when our update fires off, Vista prompts for Admin credentials. After
providing the credentials, the Admin's profile is searched for
the .ini. Of course, it's not there as the initial install was done
as a Standard User.

Saying this, I wonder how/if running our update installs silently
under the System, will function properly in that it looks to and
writes to the correct .ini file of the initially installing user.

Any further information GREATLY appreciated!!!