Vista - VISTA and Power Users?

On Jul 6, 4:38 pm, Jimmy Brush <j...@mvps.org> wrote:
> Superfreak3wrote:
> > On Jul 5, 10:39 am,Superfreak3<Matt.Wal...@synergis.com> wrote:
> >> Earlier in our thread, you mentioned:
>
> >> "However, the Power Users group still exists in Vista, but like the
> >> document says, they are not ACL'ed access to system resources, so you
> >> have to run the special file first to grant them extra access."
>
> >> What 'special file' do you mean? I guess I need to know what exactly
> >> do I have to do to mimic the Power Users group of XP.
> >> I don't know if I mentioned this before, but I'm getting the no access
> >> to Program Files messages with UAC Disabled. If I install with my
> >> Power User with UAC enabled, I simply have to apply credentials
> >> currently.
>
> >> Any more info in setting up Power Users as in XP on VISTA would be
> >> GREATLY APPRECIATED!
>
> >> Thanks for the help/great information so far!!- Hide quoted text -
>
> >> - Show quoted text -
>
> > Also, if I write a service to launch our silent updates, what would I
> > have to set ALLUSERS to, I wonder?
>
> I would like to strongly discourage you from putting your users into the
> legacy role of power users to solve this problem.
>
> It is simply not necessary for this.
>
> If you have the kind of control over your users' computers to make them
> power users (admin privileges), then it would be much easier for you
> just to authorize your MSI to be installed.
>
> That being said, I had assumed from the technet document you referenced
> that there was a security template available somewhere that would set up
> power user permissions on Vista. However, I couldn't find it. This means
> you would have to roll your own security template to change the
> permissions that you need (i.e., allow power users access to the
> appropriate registry keys, files, and privileges).
>
> I found some more good sites that deal with MSI's and UAC that you might
> find useful:
>
> http://msdn2.microsoft.com/en-us/lib...n-msi-notes-an...
>
> As for allusers, launching the MSI from a service account has
> administrator privileges, so I believe it should work out as long as it
> isn't null.
>
> --
> -JB
> Microsoft MVP - Windows Shell/User
> Windows Vista Support FAQ -http://www.jimmah.com/vista/- Hide quoted text -
>
> - Show quoted text -

Quote: "If you have the kind of control over your users' computers to
make them
power users (admin privileges), then it would be much easier for you
just to authorize your MSI to be installed."

By saying this, do you mean elevate the installation by applying
credentials at runtime or in some other way authorizing the install
package, such as a digital signature or manifest it in some way? I'm
experiencing the problem with UAC disabled so applying credentials is
not the problem. You can't manifest an .msi, can you. I thought I
would have to wrap it in an .exe, but that won't work in our scenario
as it stands currently. Also, do manifests only really have effect
when UAC is enabled?

I'm starting to tread water in the vast Vista knowledge sea and I'm
getting tired, so I may not be making any sense or may be rambling at
this point.

When its all said and done, we may just have to require that the end
users have the ability or should have access to Admin credentials if
UAC is enabled or they must be an Admin if UAC disabled. From
reading, it seems that this is what installations are headed towards.

Thanks again for the help so far and anything additional you can/might
add is always GREATLY appreciated!!

Superfreak3 wrote:
> On Jul 6, 4:38 pm, Jimmy Brush <j...@mvps.org> wrote:
>> Superfreak3wrote:
>>> On Jul 5, 10:39 am,Superfreak3<Matt.Wal...@synergis.com> wrote:
>>>> Earlier in our thread, you mentioned:
>>>> "However, the Power Users group still exists in Vista, but like the
>>>> document says, they are not ACL'ed access to system resources, so you
>>>> have to run the special file first to grant them extra access."
>>>> What 'special file' do you mean? I guess I need to know what exactly
>>>> do I have to do to mimic the Power Users group of XP.
>>>> I don't know if I mentioned this before, but I'm getting the no access
>>>> to Program Files messages with UAC Disabled. If I install with my
>>>> Power User with UAC enabled, I simply have to apply credentials
>>>> currently.
>>>> Any more info in setting up Power Users as in XP on VISTA would be
>>>> GREATLY APPRECIATED!
>>>> Thanks for the help/great information so far!!- Hide quoted text -
>>>> - Show quoted text -
>>> Also, if I write a service to launch our silent updates, what would I
>>> have to set ALLUSERS to, I wonder?
>> I would like to strongly discourage you from putting your users into the
>> legacy role of power users to solve this problem.
>>
>> It is simply not necessary for this.
>>
>> If you have the kind of control over your users' computers to make them
>> power users (admin privileges), then it would be much easier for you
>> just to authorize your MSI to be installed.
>>
>> That being said, I had assumed from the technet document you referenced
>> that there was a security template available somewhere that would set up
>> power user permissions on Vista. However, I couldn't find it. This means
>> you would have to roll your own security template to change the
>> permissions that you need (i.e., allow power users access to the
>> appropriate registry keys, files, and privileges).
>>
>> I found some more good sites that deal with MSI's and UAC that you might
>> find useful:
>>
>> http://msdn2.microsoft.com/en-us/lib...n-msi-notes-an...
>>
>> As for allusers, launching the MSI from a service account has
>> administrator privileges, so I believe it should work out as long as it
>> isn't null.
>>
>> --
>> -JB
>> Microsoft MVP - Windows Shell/User
>> Windows Vista Support FAQ -http://www.jimmah.com/vista/- Hide quoted text -
>>
>> - Show quoted text -
>
> Quote: "If you have the kind of control over your users' computers to
> make them
> power users (admin privileges), then it would be much easier for you
> just to authorize your MSI to be installed."
>
> By saying this, do you mean elevate the installation by applying
> credentials at runtime or in some other way authorizing the install
> package, such as a digital signature or manifest it in some way?
> I'm
> experiencing the problem with UAC disabled so applying credentials is
> not the problem. You can't manifest an .msi, can you. I thought I
> would have to wrap it in an .exe, but that won't work in our scenario
> as it stands currently. Also, do manifests only really have effect
> when UAC is enabled?

I think you are making this MUCH more complicated than it needs to be.

I probably haven't helped very much, but I've had a hard time trying to
understand your actual situation.

Forget about manifests, signatures, and UAC.

There is only ONE scenario you need your MSI to successfully work under:

* An administrator installs your application.

Just forget about everything else. Is all that other junk gone? OK. Log
in as an admin, and see if your program works when you install it while
logged in as an administrator. Try it with UAC on and off.

Does it work?

If so, you are DONE from a programming perspective for this MSI!
Congratulations! There are no other changes to be done to the MSI - no
manifests, no signatures - nothing! It works.

You've solved the problem "How do I make my MSI installable in a UAC
environment."

Now, you will need to take off your programmer's hat and put on your
administrator's hat.

Now you have to solve the problem "How do I install my MSI on my user's
computers?"

It is an *administrative* task to deploy your MSI to the computers you
want to put it on. An administrator causes this to happen. An actual
person (an administrator) flips a switch somewhere that does this.

The easiest way to deploy the MSI is to use group policy. Are your
computers joined to a domain? If so, it's easy-peasy-lemon-squeezy. (If
not, there are other EASY solutions)

If in a domain, read this little tutorial about group policy deployment:

http://www.windowsnetworking.com/art...lications.html

It so easy. You simply pick the computers you want to install your MSI
on. You choose whether you want to force the install to occur, or if you
want your users to choose whether to install the program or not (using
add/remove programs). Then, you stick your MSI on a network path
somewhere where all the computers can get to it. That's it! Deployment
done. Your program either gets installed as if by magic on your user's
computers, or they go to add/remove programs to install it if they need it.

The only other thing you have left to work on is your auto-updater. You
have some options:

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).

2) Make an MSP for your updates. This will require that your initial
setup program as well as any additional MSP updates follow certain
conventions. I gave you a link that details exactly how this is
accomplished in a previous post. If you go this route, you don't have to
mess with services or scheduled tasks, your main program can launch the
MSP's and they will install fine from a standard user account.

3) Or, you could just forget about all the auto-update logic and just
deploy your updated MSI using group policy like you did for the main
app! It's up to you.

> I'm starting to tread water in the vast Vista knowledge sea and I'm
> getting tired, so I may not be making any sense or may be rambling at
> this point.
>
> When its all said and done, we may just have to require that the end
> users have the ability or should have access to Admin credentials if
> UAC is enabled or they must be an Admin if UAC disabled. From
> reading, it seems that this is what installations are headed towards.

That's simply not necessary.

You're just getting frustrated because you can't find an easy
programming-type solution to your problem where you flip a bit on your
installer and it just magically works. Because there isn't one.

The solution really is simple, but it's an administrative solution, not
a programming one.

> Thanks again for the help so far and anything additional you can/might
> add is always GREATLY appreciated!!
>

You're welcome.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

On Jul 9, 8:51 pm, Jimmy Brush <j...@mvps.org> wrote:
> Superfreak3wrote:
> > On Jul 6, 4:38 pm, Jimmy Brush <j...@mvps.org> wrote:
> >> Superfreak3wrote:
> >>> On Jul 5, 10:39 am,Superfreak3<Matt.Wal...@synergis.com> wrote:
> >>>> Earlier in our thread, you mentioned:
> >>>> "However, the Power Users group still exists in Vista, but like the
> >>>> document says, they are not ACL'ed access to system resources, so you
> >>>> have to run the special file first to grant them extra access."
> >>>> What 'special file' do you mean? I guess I need to know what exactly
> >>>> do I have to do to mimic the Power Users group of XP.
> >>>> I don't know if I mentioned this before, but I'm getting the no access
> >>>> to Program Files messages with UAC Disabled. If I install with my
> >>>> Power User with UAC enabled, I simply have to apply credentials
> >>>> currently.
> >>>> Any more info in setting up Power Users as in XP on VISTA would be
> >>>> GREATLY APPRECIATED!
> >>>> Thanks for the help/great information so far!!- Hide quoted text -
> >>>> - Show quoted text -
> >>> Also, if I write a service to launch our silent updates, what would I
> >>> have to set ALLUSERS to, I wonder?
> >> I would like to strongly discourage you from putting your users into the
> >> legacy role of power users to solve this problem.
>
> >> It is simply not necessary for this.
>
> >> If you have the kind of control over your users' computers to make them
> >> power users (admin privileges), then it would be much easier for you
> >> just to authorize your MSI to be installed.
>
> >> That being said, I had assumed from the technet document you referenced
> >> that there was a security template available somewhere that would set up
> >> power user permissions on Vista. However, I couldn't find it. This means
> >> you would have to roll your own security template to change the
> >> permissions that you need (i.e., allow power users access to the
> >> appropriate registry keys, files, and privileges).
>
> >> I found some more good sites that deal with MSI's and UAC that you might
> >> find useful:
>
> >>http://msdn2.microsoft.com/en-us/lib...ttp://blogs.ms......
>
> >> As for allusers, launching the MSI from a service account has
> >> administrator privileges, so I believe it should work out as long as it
> >> isn't null.
>
> >> --
> >> -JB
> >> Microsoft MVP - Windows Shell/User
> >> Windows Vista Support FAQ -http://www.jimmah.com/vista/-Hide quoted text -
>
> >> - Show quoted text -
>
> > Quote: "If you have the kind of control over your users' computers to
> > make them
> > power users (admin privileges), then it would be much easier for you
> > just to authorize your MSI to be installed."
>
> > By saying this, do you mean elevate the installation by applying
> > credentials at runtime or in some other way authorizing the install
> > package, such as a digital signature or manifest it in some way?
> > I'm
> > experiencing the problem with UAC disabled so applying credentials is
> > not the problem. You can't manifest an .msi, can you. I thought I
> > would have to wrap it in an .exe, but that won't work in our scenario
> > as it stands currently. Also, do manifests only really have effect
> > when UAC is enabled?
>
> I think you are making this MUCH more complicated than it needs to be.
>
> I probably haven't helped very much, but I've had a hard time trying to
> understand your actual situation.
>
> Forget about manifests, signatures, and UAC.
>
> There is only ONE scenario you need your MSI to successfully work under:
>
> * An administrator installs your application.
>
> Just forget about everything else. Is all that other junk gone? OK. Log
> in as an admin, and see if your program works when you install it while
> logged in as an administrator. Try it with UAC on and off.
>
> Does it work?
>
> If so, you are DONE from a programming perspective for this MSI!
> Congratulations! There are no other changes to be done to the MSI - no
> manifests, no signatures - nothing! It works.
>
> You've solved the problem "How do I make my MSI installable in a UAC
> environment."
>
> Now, you will need to take off your programmer's hat and put on your
> administrator's hat.
>
> Now you have to solve the problem "How do I install my MSI on my user's
> computers?"
>
> It is an *administrative* task to deploy your MSI to the computers you
> want to put it on. An administrator causes this to happen. An actual
> person (an administrator) flips a switch somewhere that does this.
>
> The easiest way to deploy the MSI is to use group policy. Are your
> computers joined to a domain? If so, it's easy-peasy-lemon-squeezy. (If
> not, there are other EASY solutions)
>
> If in a domain, read this little tutorial about group policy deployment:
>
> http://www.windowsnetworking.com/art...up-Policy-Depl...
>
> It so easy. You simply pick the computers you want to install your MSI
> on. You choose whether you want to force the install to occur, or if you
> want your users to choose whether to install the program or not (using
> add/remove programs). Then, you stick your MSI on a network path
> somewhere where all the computers can get to it. That's it! Deployment
> done. Your program either gets installed as if by magic on your user's
> computers, or they go to add/remove programs to install it if they need it.
>
> The only other thing you have left to work on is your auto-updater. You
> have some options:
>
> 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).
>
> 2) Make an MSP for your updates. This will require that your initial
> setup program as well as any additional MSP updates follow certain
> conventions. I gave you a link that details exactly how this is
> accomplished in a previous post. If you go this route, you don't have to
> mess with services or scheduled tasks, your main program can launch the
> MSP's and they will install fine from a standard user account.
>
> 3) Or, you could just forget about all the auto-update logic and just
> deploy your updated MSI using group policy like you did for the main
> app! It's up to you.
>
> > I'm starting to tread water in the vast Vista knowledge sea and I'm
> > getting tired, so I may not be making any sense or may be rambling at
> > this point.
>
> > When its all said and done, we may just have to require that the end
> > users have the ability or should have access to Admin credentials if
> > UAC is enabled or they must be an Admin if UAC disabled. From
> > reading, it seems that this is what installations are headed towards.
>
> That's simply not necessary.
>
> You're just getting frustrated because you can't find an easy
> programming-type solution to your problem where you flip a bit on your
> installer and it just magically works. Because there isn't one.
>
> The solution really is simple, but it's an administrative solution, not
> a programming one.
>
> > Thanks again for the help so far and anything additional you can/might
> > add is always GREATLY appreciated!!
>
> You're welcome.
>
> --
> -JB
> Microsoft MVP - Windows Shell/User
> Windows Vista Support FAQ -http://www.jimmah.com/vista/- Hide quoted text -
>
> - Show quoted text -

My concerns/efforts are basically centered around:

> "Now you have to solve the problem "How do I install my MSI on my user's
> computers?""

I'm not really worried about our Server install as this will not be
installed on VISTA machines at present and I know its difficult for
you to determine 'good' answers for me as you have no idea what we're
doing.

Basically, the client .msi is in a network share and I believe, for
the initial install, users browse to that location and execute
the .msi. It is for this initial install I say they would probably
need to be an Admin or supply credentials with UAC.

After the initial install, the updates to these clients are silently
run if a new file is detected. This is where I might possibly use a
service.

> Basically, the client .msi is in a network share and I believe, for
> the initial install, users browse to that location and execute
> the .msi. It is for this initial install I say they would probably
> need to be an Admin or supply credentials with UAC.
>

Why aren't you using group policy for deployment?

If it's because you don't have a domain, I can recommend another process.

I honestly am flabberghasted that you would be able to make all your
users administrators, effectively wiping out the security of your
enviornment, but would not be able to minutely change this procedure.

Instead of double-clicking the msi, your users would go to add/remove
programs.

Seriously, if you are prevented from changing this procedure for a
non-technical reason, but allowed to make your users admins, something
is VERY WRONG in your company.

However, for the sake of completeness, I do have a solution that would
allow your standard users to install your MSI without making them
administrators. This would require a registry edit on all the vista
machines.

Unfortunately, this would also allow them to install *ANY* program. They
could still elevate their privilege to admin, but it would be harder for
them to do than - well, making them a power user or an admin.

This is security thru obscurity, and if you rely on this, it will bite
you in the butt 100% of the time.

So I strongly recommend that you change your distribution policy to a
secure solution where an admin controls who can install what, and not
leave it up to your non-admin users.

But, you are the one in charge, not me, so if you want the bad solution,
I will give it to you.


- JB

On Jul 10, 3:50 pm, Jimmy Brush <j...@mvps.org> wrote:
> > Basically, the client .msi is in a network share and I believe, for
> > the initial install, users browse to that location and execute
> > the .msi. It is for this initial install I say they would probably
> > need to be an Admin or supply credentials with UAC.
>
> Why aren't you using group policy for deployment?
>
> If it's because you don't have a domain, I can recommend another process.
>
> I honestly am flabberghasted that you would be able to make all your
> users administrators, effectively wiping out the security of your
> enviornment, but would not be able to minutely change this procedure.
>
> Instead of double-clicking the msi, your users would go to add/remove
> programs.
>
> Seriously, if you are prevented from changing this procedure for a
> non-technical reason, but allowed to make your users admins, something
> is VERY WRONG in your company.
>
> However, for the sake of completeness, I do have a solution that would
> allow your standard users to install your MSI without making them
> administrators. This would require a registry edit on all the vista
> machines.
>
> Unfortunately, this would also allow them to install *ANY* program. They
> could still elevate their privilege to admin, but it would be harder for
> them to do than - well, making them a power user or an admin.
>
> This is security thru obscurity, and if you rely on this, it will bite
> you in the butt 100% of the time.
>
> So I strongly recommend that you change your distribution policy to a
> secure solution where an admin controls who can install what, and not
> leave it up to your non-admin users.
>
> But, you are the one in charge, not me, so if you want the bad solution,
> I will give it to you.
>
> - JB

We are creating software that is installed/deployed in the field. We
really have no idea how a larger end user group will deploy or may
want to deploy our software, which is why I have to come up with
something that will work in most cases. I guess you could say they
created their own monster here in placing the client install in a
network and devising their own update detection/deployment mechanism.

I've inherited the installs since starting here last December and this
it just how it was designed when I got here. I know it probably needs
some rework, but that is for a later time (I hope as the company is
planning bigger changes for the app. due out in November). I was just
hoping to get the current mechanism functioning in VISTA to some
extent. The powers that be would like our next release to be Vista
ready by the end of July. Time is ticking and I'm getting
nervous! ; )

I guess I'm a little confused by the use of Group Policy or an
Administrator 'blessing' the installation in some way as opposed to
the actual installation of the software. If an Administrator blesses
the installation, do the actual installation processes run with
elevated privileges when the workstation User attempts to install?
Like I said, if I double click the .msi on a workstation, I need Admin
rights (or Power User in XP world) due to restricted install locations
and stuff written to the registry. Currently, if a non-Admin accesses
our application for the first time, Windows Installer will add the
necessary user information. Is that how it would work with Group
Policy?

In other words, if a workstation User goes to Add/Remove programs to
install the package as you say, after it has been blessed, how is it
known on that workstation that the install should run with elevate
privileges even if someone at the User level initiates it?

Also for the update piece of my puzzle, it is silent so is that where
the Service concept comes in?

To also clear up some confusion in my head, can I eliminate the
concepts of Advertisement and Administrative Install from this
discussion in my own head (that doesn't even sound healthy)?
Advertisement only places access points for later install and Admin
Install really only places a copy of the installation media somewhere
on a network to be hit by installing users, correct? These really
have nothing to do with security/privileges in that when the install
would actually occur, I would see similar prompts and/or behavior
based on what User type is actually installing. They are not
'blessed' in any way?

To sum it all up, I guess it would be up to the end user to employ
Group Policy for deployment or maybe we would have to recommend that
if that is the route on which we base our development.

I'm a bit confused in that you say you are shocked that we would be
able to make all users Administrators, but then you said earlier that:

"There is only ONE scenario you need your MSI to successfully work
under: * An administrator installs your application."

So within the environments to which our software is deployed in the
field, there is probably an Administrator that installs our Server
install (which, again, places the client install in a network share)
and then there are the workstation Users. Those users are exposed to
the client install. You are saying that Group Policy could be used to
install to the workstations, but if Group Policy is not used, then
they would have to be administrators, correct? I would then guess
that this is true for the initial install on a workstation, but then a
Service could be used to update the application?

I definitely want this thing turned in the right direction once and
for all so believe me when I say I am looking for a GOOD solution. I
know I'm rambling but bear with me! Thanks for the help so far. The
information provided is great!

> We are creating software that is installed/deployed in the field. We
> really have no idea how a larger end user group will deploy or may
> want to deploy our software, which is why I have to come up with
> something that will work in most cases. I guess you could say they
> created their own monster here in placing the client install in a
> network and devising their own update detection/deployment mechanism.
>
> I've inherited the installs since starting here last December and this
> it just how it was designed when I got here. I know it probably needs
> some rework, but that is for a later time (I hope as the company is
> planning bigger changes for the app. due out in November). I was just
> hoping to get the current mechanism functioning in VISTA to some
> extent. The powers that be would like our next release to be Vista
> ready by the end of July. Time is ticking and I'm getting
> nervous! ; )

Ahhh OK so you are distributing this to customers to install. I got the
impression that this was an "internal" software app that you were
releasing inside of your company.

> I guess I'm a little confused by the use of Group Policy or an
> Administrator 'blessing' the installation in some way as opposed to
> the actual installation of the software. If an Administrator blesses
> the installation, do the actual installation processes run with
> elevated privileges when the workstation User attempts to install?

Yes.

> Like I said, if I double click the .msi on a workstation, I need Admin
> rights (or Power User in XP world) due to restricted install locations
> and stuff written to the registry. Currently, if a non-Admin accesses
> our application for the first time, Windows Installer will add the
> necessary user information. Is that how it would work with Group
> Policy?

I'm not sure what you mean by "if a non-Admin accesses our application
for the first time, Windows Installer will add the necessary user
information".

> In other words, if a workstation User goes to Add/Remove programs to
> install the package as you say, after it has been blessed, how is it
> known on that workstation that the install should run with elevate
> privileges even if someone at the User level initiates it?

It is known via registry settings and whatnot that come from active
directory in a domain environment.

This is a built-in feature of Windows. When the admin at your customer's
site marks your MSI (located on some network share) as "blessed" using
active directory management tools, this gets propagated down to all the
selected client computers in the domain via active directory.

Instead of the "users" directly starting the install by double-clicking
on the MSI, the computer will either 1) automatically start the install
the next time the user logs on, or 2) will start the install when the
user selects it from add/remove programs.

The install will then run "elevated", because it has been blessed.

It is important to realize that this is something that your MSI has no
control over. This is something that your customers must do, but that
you can give instructions/guidance on.

>
> Also for the update piece of my puzzle, it is silent so is that where
> the Service concept comes in?
>

Yes. The update service or scheduled task will run in a system account.
You will need to make a seperate .exe for this - that checks to see if
there is an update, downloads it, and then launches it. Because this is
running as a service/task in a system account, it is elevated (running
with admin power, and so the launched MSI will act exactly as if an
administrator had double-clicked on it). But, it cannot show UI, because
it is not running inside of any particular user account (it will run
even if there is no user logged on).

> To also clear up some confusion in my head, can I eliminate the
> concepts of Advertisement and Administrative Install from this
> discussion in my own head (that doesn't even sound healthy)?
> Advertisement only places access points for later install and Admin
> Install really only places a copy of the installation media somewhere
> on a network to be hit by installing users, correct? These really
> have nothing to do with security/privileges in that when the install
> would actually occur, I would see similar prompts and/or behavior
> based on what User type is actually installing. They are not
> 'blessed' in any way?
>
> To sum it all up, I guess it would be up to the end user to employ
> Group Policy for deployment or maybe we would have to recommend that
> if that is the route on which we base our development.

From a development perspective, yes, you can ignore this as it has
nothing to do with how you make the MSI.

Group policy is how your customers would deploy this app to their
desktops. They would use "administrative install" to force install your
app on their computers without giving the users of those computers the
option to install it. They would use "advertisement" to allow the users
to install your app on demand.

Standard users would NOT be prompted for permission once an admin has
blessed the install - it would just work for them. The install would run
elevated (as if an administrator double-clicked on it) even though a
standard user is logged in. Windows Installer and the group
policy/blessed install stuff handles all of this magic for you - you
have nothing special to do progrmmatically to support this - it just works.

That's why I said:

> I'm a bit confused in that you say you are shocked that we would be
> able to make all users Administrators, but then you said earlier that:
>
> "There is only ONE scenario you need your MSI to successfully work
> under: * An administrator installs your application."

Right, from a programmatic perspective, your MSI only has to work when
an administrator installs the program.

There are administrative ways (like using group policy) that will allow
your MSI to be installed by standard users, with an administrator's
blessing. From your MSI's perspective, it is elevated and has admin
power... even though the user who is asking for it to be installed may
not. The admin blessing the install is what allows this, and Windows
takes care of making this work.

> So within the environments to which our software is deployed in the
> field, there is probably an Administrator that installs our Server
> install (which, again, places the client install in a network share)
> and then there are the workstation Users. Those users are exposed to
> the client install. You are saying that Group Policy could be used to
> install to the workstations, but if Group Policy is not used, then
> they would have to be administrators, correct? I would then guess
> that this is true for the initial install on a workstation, but then a
> Service could be used to update the application?
>

If group policy is not used (which it would not be available to your
customers who do not have domains), their users would either have to be
administrators, or they would need to use some other way of automating
software installs to their computers. There are third party solutions
for this, and there are some "do it yourself" solutions as well.

For example, if the customer is not using a domain, but there is an
administrator account on every computer that has the same password,
they can automate installs by making a script that connects to each of
their computers and creates a scheduled task that runs inside of a
system account that launches the setup program.

In any case, it is up to the customer to figure out how automate the
installation of your program on their computers, considering your
program requires admin power to install.

The only other solution would be to make your setup program NOT require
admin power to install (i.e. not install to program files, but a
per-user location; not write any settings to HKLM; your auto-updater
would also not be able to run as a service/scheduled task in this
instance, since non-admins cannot register services; etc).


> I definitely want this thing turned in the right direction once and
> for all so believe me when I say I am looking for a GOOD solution. I
> know I'm rambling but bear with me! Thanks for the help so far. The
> information provided is great!
>

Good to hear

Basically, there is nothing you can do programmatically to cause your
setup program to be installable by non-admins, if it has to do admin stuff.

If you think about this, it makes sense. That would totally break the
security in Vista.

It is up to your customers to have some method of automated software
installs to get this to work for them.

If they have a Windows domain, this is super simple for them - Windows
in a domain environment comes with all the tools they need to make this
happen.

If not, they will need to either have a third-party tool that allows
managed software installations, or will have to "roll their own" solution.

If your program does not require admin power and you change your setup
program to not require admin power, then it can be installed by
non-admins without your customers having to do anything special.

In this case, you would have to handle two cases in your MSI: 1) an
admin installs the program and 2) a non-admin installs the program.

However, in a corporate environment, it is sometimes better to leave
your setup program as requiring admin power, because allowing non-admin
installs can increase complexity for both you and your customers.

For example, non-admin installs are usually placed in a per-user
location. This means that every user has their own copy of the program.
If each computer has a lot of users, this is a lot of rendundant data,
and makes upgrading more time-consuming and wasteful, as every user will
need to download and install their own copy of an update.

Also, if your install requires admin power, then the very fact that
standard users CANNOT install your program without an admin's blessing
can help your customers out if they have a lot of users, as this makes
sure that the software only goes to the computers that the admin's want.

For example, if they are rolling out your software in stages or they
don't want some users to have your software installed, they won't have
to worry about users that they don't want to install the software from
doing so.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

On Jul 11, 10:34 pm, Jimmy Brush <j...@mvps.org> wrote:
> > We are creating software that is installed/deployed in the field. We
> > really have no idea how a larger end user group will deploy or may
> > want to deploy our software, which is why I have to come up with
> > something that will work in most cases. I guess you could say they
> > created their own monster here in placing the client install in a
> > network and devising their own update detection/deployment mechanism.
>
> > I've inherited the installs since starting here last December and this
> > it just how it was designed when I got here. I know it probably needs
> > some rework, but that is for a later time (I hope as the company is
> > planning bigger changes for the app. due out in November). I was just
> > hoping to get the current mechanism functioning in VISTA to some
> > extent. The powers that be would like our next release to be Vista
> > ready by the end of July. Time is ticking and I'm getting
> > nervous! ; )
>
> Ahhh OK so you are distributing this to customers to install. I got the
> impression that this was an "internal" software app that you were
> releasing inside of your company.
>
> > I guess I'm a little confused by the use of Group Policy or an
> > Administrator 'blessing' the installation in some way as opposed to
> > the actual installation of the software. If an Administrator blesses
> > the installation, do the actual installation processes run with
> > elevated privileges when the workstation User attempts to install?
>
> Yes.
>
> > Like I said, if I double click the .msi on a workstation, I need Admin
> > rights (or Power User in XP world) due to restricted install locations
> > and stuff written to the registry. Currently, if a non-Admin accesses
> > our application for the first time, Windows Installer will add the
> > necessary user information. Is that how it would work with Group
> > Policy?
>
> I'm not sure what you mean by "if a non-Admin accesses our application
> for the first time, Windows Installer will add the necessary user
> information".
>
> > In other words, if a workstation User goes to Add/Remove programs to
> > install the package as you say, after it has been blessed, how is it
> > known on that workstation that the install should run with elevate
> > privileges even if someone at the User level initiates it?
>
> It is known via registry settings and whatnot that come from active
> directory in a domain environment.
>
> This is a built-in feature of Windows. When the admin at your customer's
> site marks your MSI (located on some network share) as "blessed" using
> active directory management tools, this gets propagated down to all the
> selected client computers in the domain via active directory.
>
> Instead of the "users" directly starting the install by double-clicking
> on the MSI, the computer will either 1) automatically start the install
> the next time the user logs on, or 2) will start the install when the
> user selects it from add/remove programs.
>
> The install will then run "elevated", because it has been blessed.
>
> It is important to realize that this is something that your MSI has no
> control over. This is something that your customers must do, but that
> you can give instructions/guidance on.
>
>
>
> > Also for the update piece of my puzzle, it is silent so is that where
> > the Service concept comes in?
>
> Yes. The update service or scheduled task will run in a system account.
> You will need to make a seperate .exe for this - that checks to see if
> there is an update, downloads it, and then launches it. Because this is
> running as a service/task in a system account, it is elevated (running
> with admin power, and so the launched MSI will act exactly as if an
> administrator had double-clicked on it). But, it cannot show UI, because
> it is not running inside of any particular user account (it will run
> even if there is no user logged on).
>
> > To also clear up some confusion in my head, can I eliminate the
> > concepts of Advertisement and Administrative Install from this
> > discussion in my own head (that doesn't even sound healthy)?
> > Advertisement only places access points for later install and Admin
> > Install really only places a copy of the installation media somewhere
> > on a network to be hit by installing users, correct? These really
> > have nothing to do with security/privileges in that when the install
> > would actually occur, I would see similar prompts and/or behavior
> > based on what User type is actually installing. They are not
> > 'blessed' in any way?
>
> > To sum it all up, I guess it would be up to the end user to employ
> > Group Policy for deployment or maybe we would have to recommend that
> > if that is the route on which we base our development.
>
> From a development perspective, yes, you can ignore this as it has
> nothing to do with how you make the MSI.
>
> Group policy is how your customers would deploy this app to their
> desktops. They would use "administrative install" to force install your
> app on their computers without giving the users of those computers the
> option to install it. They would use "advertisement" to allow the users
> to install your app on demand.
>
> Standard users would NOT be prompted for permission once an admin has
> blessed the install - it would just work for them. The install would run
> elevated (as if an administrator double-clicked on it) even though a
> standard user is logged in. Windows Installer and the group
> policy/blessed install stuff handles all of this magic for you - you
> have nothing special to do progrmmatically to support this - it just works.
>
> That's why I said:
>
> > I'm a bit confused in that you say you are shocked that we would be
> > able to make all users Administrators, but then you said earlier that:
>
> > "There is only ONE scenario you need your MSI to successfully work
> > under: * An administrator installs your application."
>
> Right, from a programmatic perspective, your MSI only has to work when
> an administrator installs the program.
>
> There are administrative ways (like using group policy) that will allow
> your MSI to be installed by standard users, with an administrator's
> blessing. From your MSI's perspective, it is elevated and has admin
> power... even though the user who is asking for it to be installed may
> not. The admin blessing the install is what allows this, and Windows
> takes care of making this work.
>
> > So within the environments to which our software is deployed in the
> > field, there is probably an Administrator that installs our Server
> > install (which, again, places the client install in a network share)
> > and then there are the workstation Users. Those users are exposed to
> > the client install. You are saying that Group Policy could be used to
> > install to the workstations, but if Group Policy is not used, then
> > they would have to be administrators, correct? I would then guess
> > that this is true for the initial install on a workstation, but then a
> > Service could be used to update the application?
>
> If group policy is not used (which it would not be available to your
> customers who do not have domains), their users would either have to be
> administrators, or they would need to use some other way of automating
> software installs to their computers. There are third party solutions
> for this, and there are some "do it yourself" solutions as well.
>
> For example, if the customer is not using a domain, but there is an
> administrator account on every computer that has the same password,
> they can automate installs by making a script that connects to each of
> their computers and creates a scheduled task that runs inside of a
> system account that launches the setup program.
>
> In any case, it is up to the customer to figure out how automate the
> installation of your program on their computers, considering your
> program requires admin power to install.
>
> The only other solution would be to make your setup program NOT require
> admin power to install (i.e. not install to program files, but a
> per-user location; not write any settings to HKLM; your auto-updater
> would also not be able to run as a service/scheduled task in this
> instance, since non-admins cannot register services; etc).
>
> > I definitely want this thing turned in the right direction once and
> > for all so believe me when I say I am looking for a GOOD solution. I
> > know I'm rambling but bear with me! Thanks for the help so far. The
> > information provided is great!
>
> Good to hear
>
> Basically, there is nothing you can do programmatically to cause your
> setup program to be installable by non-admins, if it has to do admin stuff.
>
> If you think about this, it makes sense. That would totally break the
> security in Vista.
>
> It is up to your customers to have some method of automated software
> installs to get this to work for them.
>
> If they have a Windows domain, this is super simple for them - Windows
> in a domain environment comes with all the tools they need to make this
> happen.
>
> If not, they will need to either have a third-party tool that allows
> managed software installations, or will have to "roll their own" solution.
>
> If your program does not require admin power and you change your setup
> program to not require admin power, then it can be installed by
> non-admins without your customers having to do anything special.
>
> In this case, you would have to handle two cases in your MSI: 1) an
> admin installs the program and 2) a non-admin installs the program.
>
> However, in a corporate environment, it is sometimes better to leave
> your setup program as requiring admin power, because allowing non-admin
> installs can increase complexity for both you and your customers.
>
> For example, non-admin installs are usually placed in a per-user
> location. This means that every user has their own copy of the program.
> If each computer has a lot of users, this is a lot of rendundant data,
> and makes upgrading more time-consuming and wasteful, as every user will
> need to download and install their own copy of an update.
>
> Also, if your install requires admin power, then the very fact that
> standard users CANNOT install your ...
>
> read more »

Thank you so much for that extended explanation and taking the time to
do so. It is MUCH APPRECIATED!

On Jul 12, 10:01 am, Superfreak3 <Matt.Wal...@synergis.com> wrote:
> On Jul 11, 10:34 pm, Jimmy Brush <j...@mvps.org> wrote:
>
>
>
> > > We are creating software that is installed/deployed in the field. We
> > > really have no idea how a larger end user group will deploy or may
> > > want to deploy our software, which is why I have to come up with
> > > something that will work in most cases. I guess you could say they
> > > created their own monster here in placing the client install in a
> > > network and devising their own update detection/deployment mechanism.
>
> > > I've inherited the installs since starting here last December and this
> > > it just how it was designed when I got here. I know it probably needs
> > > some rework, but that is for a later time (I hope as the company is
> > > planning bigger changes for the app. due out in November). I was just
> > > hoping to get the current mechanism functioning in VISTA to some
> > > extent. The powers that be would like our next release to be Vista
> > > ready by the end of July. Time is ticking and I'm getting
> > > nervous! ; )
>
> > Ahhh OK so you are distributing this to customers to install. I got the
> > impression that this was an "internal" software app that you were
> > releasing inside of your company.
>
> > > I guess I'm a little confused by the use of Group Policy or an
> > > Administrator 'blessing' the installation in some way as opposed to
> > > the actual installation of the software. If an Administrator blesses
> > > the installation, do the actual installation processes run with
> > > elevated privileges when the workstation User attempts to install?
>
> > Yes.
>
> > > Like I said, if I double click the .msi on a workstation, I need Admin
> > > rights (or Power User in XP world) due to restricted install locations
> > > and stuff written to the registry. Currently, if a non-Admin accesses
> > > our application for the first time, Windows Installer will add the
> > > necessary user information. Is that how it would work with Group
> > > Policy?
>
> > I'm not sure what you mean by "if a non-Admin accesses our application
> > for the first time, Windows Installer will add the necessary user
> > information".
>
> > > In other words, if a workstation User goes to Add/Remove programs to
> > > install the package as you say, after it has been blessed, how is it
> > > known on that workstation that the install should run with elevate
> > > privileges even if someone at the User level initiates it?
>
> > It is known via registry settings and whatnot that come from active
> > directory in a domain environment.
>
> > This is a built-in feature of Windows. When the admin at your customer's
> > site marks your MSI (located on some network share) as "blessed" using
> > active directory management tools, this gets propagated down to all the
> > selected client computers in the domain via active directory.
>
> > Instead of the "users" directly starting the install by double-clicking
> > on the MSI, the computer will either 1) automatically start the install
> > the next time the user logs on, or 2) will start the install when the
> > user selects it from add/remove programs.
>
> > The install will then run "elevated", because it has been blessed.
>
> > It is important to realize that this is something that your MSI has no
> > control over. This is something that your customers must do, but that
> > you can give instructions/guidance on.
>
> > > Also for the update piece of my puzzle, it is silent so is that where
> > > the Service concept comes in?
>
> > Yes. The update service or scheduled task will run in a system account.
> > You will need to make a seperate .exe for this - that checks to see if
> > there is an update, downloads it, and then launches it. Because this is
> > running as a service/task in a system account, it is elevated (running
> > with admin power, and so the launched MSI will act exactly as if an
> > administrator had double-clicked on it). But, it cannot show UI, because
> > it is not running inside of any particular user account (it will run
> > even if there is no user logged on).
>
> > > To also clear up some confusion in my head, can I eliminate the
> > > concepts of Advertisement and Administrative Install from this
> > > discussion in my own head (that doesn't even sound healthy)?
> > > Advertisement only places access points for later install and Admin
> > > Install really only places a copy of the installation media somewhere
> > > on a network to be hit by installing users, correct? These really
> > > have nothing to do with security/privileges in that when the install
> > > would actually occur, I would see similar prompts and/or behavior
> > > based on what User type is actually installing. They are not
> > > 'blessed' in any way?
>
> > > To sum it all up, I guess it would be up to the end user to employ
> > > Group Policy for deployment or maybe we would have to recommend that
> > > if that is the route on which we base our development.
>
> > From a development perspective, yes, you can ignore this as it has
> > nothing to do with how you make the MSI.
>
> > Group policy is how your customers would deploy this app to their
> > desktops. They would use "administrative install" to force install your
> > app on their computers without giving the users of those computers the
> > option to install it. They would use "advertisement" to allow the users
> > to install your app on demand.
>
> > Standard users would NOT be prompted for permission once an admin has
> > blessed the install - it would just work for them. The install would run
> > elevated (as if an administrator double-clicked on it) even though a
> > standard user is logged in. Windows Installer and the group
> > policy/blessed install stuff handles all of this magic for you - you
> > have nothing special to do progrmmatically to support this - it just works.
>
> > That's why I said:
>
> > > I'm a bit confused in that you say you are shocked that we would be
> > > able to make all users Administrators, but then you said earlier that:
>
> > > "There is only ONE scenario you need your MSI to successfully work
> > > under: * An administrator installs your application."
>
> > Right, from a programmatic perspective, your MSI only has to work when
> > an administrator installs the program.
>
> > There are administrative ways (like using group policy) that will allow
> > your MSI to be installed by standard users, with an administrator's
> > blessing. From your MSI's perspective, it is elevated and has admin
> > power... even though the user who is asking for it to be installed may
> > not. The admin blessing the install is what allows this, and Windows
> > takes care of making this work.
>
> > > So within the environments to which our software is deployed in the
> > > field, there is probably an Administrator that installs our Server
> > > install (which, again, places the client install in a network share)
> > > and then there are the workstation Users. Those users are exposed to
> > > the client install. You are saying that Group Policy could be used to
> > > install to the workstations, but if Group Policy is not used, then
> > > they would have to be administrators, correct? I would then guess
> > > that this is true for the initial install on a workstation, but then a
> > > Service could be used to update the application?
>
> > If group policy is not used (which it would not be available to your
> > customers who do not have domains), their users would either have to be
> > administrators, or they would need to use some other way of automating
> > software installs to their computers. There are third party solutions
> > for this, and there are some "do it yourself" solutions as well.
>
> > For example, if the customer is not using a domain, but there is an
> > administrator account on every computer that has the same password,
> > they can automate installs by making a script that connects to each of
> > their computers and creates a scheduled task that runs inside of a
> > system account that launches the setup program.
>
> > In any case, it is up to the customer to figure out how automate the
> > installation of your program on their computers, considering your
> > program requires admin power to install.
>
> > The only other solution would be to make your setup program NOT require
> > admin power to install (i.e. not install to program files, but a
> > per-user location; not write any settings to HKLM; your auto-updater
> > would also not be able to run as a service/scheduled task in this
> > instance, since non-admins cannot register services; etc).
>
> > > I definitely want this thing turned in the right direction once and
> > > for all so believe me when I say I am looking for a GOOD solution. I
> > > know I'm rambling but bear with me! Thanks for the help so far. The
> > > information provided is great!
>
> > Good to hear
>
> > Basically, there is nothing you can do programmatically to cause your
> > setup program to be installable by non-admins, if it has to do admin stuff.
>
> > If you think about this, it makes sense. That would totally break the
> > security in Vista.
>
> > It is up to your customers to have some method of automated software
> > installs to get this to work for them.
>
> > If they have a Windows domain, this is super simple for them - Windows
> > in a domain environment comes with all the tools they need to make this
> > happen.
>
> > If not, they will need to either have a third-party tool that allows
> > managed software installations, or will have to "roll their own" solution.
>
> > If your program does not require admin power and you change your setup
> > program to not require admin power, then it can be installed by
> > non-admins without your customers having to do anything special.
>
> > In this case, you would have to handle two cases in your MSI: 1) an
> > admin installs the program and 2) a non-admin installs the program.
>
> > However, in a corporate environment, it is sometimes better to leave
> > your setup program as requiring admin power, because allowing non-admin
> > installs can increase complexity for both you and your customers.
>
> > For example, non-admin installs are usually placed in a per-user
> > location. This means that every user has their own copy of
>
> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -

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.

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?

This looks promising. I would guess the service would function in a
similar manner.

THANKS FOR ALL THE HELP TO THIS POINT!

On Jul 11, 10:34 pm, Jimmy Brush <j...@mvps.org> wrote:
> > We are creating software that is installed/deployed in the field. We
> > really have no idea how a larger end user group will deploy or may
> > want to deploy our software, which is why I have to come up with
> > something that will work in most cases. I guess you could say they
> > created their own monster here in placing the client install in a
> > network and devising their own update detection/deployment mechanism.
>
> > I've inherited the installs since starting here last December and this
> > it just how it was designed when I got here. I know it probably needs
> > some rework, but that is for a later time (I hope as the company is
> > planning bigger changes for the app. due out in November). I was just
> > hoping to get the current mechanism functioning in VISTA to some
> > extent. The powers that be would like our next release to be Vista
> > ready by the end of July. Time is ticking and I'm getting
> > nervous! ; )
>
> Ahhh OK so you are distributing this to customers to install. I got the
> impression that this was an "internal" software app that you were
> releasing inside of your company.
>
> > I guess I'm a little confused by the use of Group Policy or an
> > Administrator 'blessing' the installation in some way as opposed to
> > the actual installation of the software. If an Administrator blesses
> > the installation, do the actual installation processes run with
> > elevated privileges when the workstation User attempts to install?
>
> Yes.
>
> > Like I said, if I double click the .msi on a workstation, I need Admin
> > rights (or Power User in XP world) due to restricted install locations
> > and stuff written to the registry. Currently, if a non-Admin accesses
> > our application for the first time, Windows Installer will add the
> > necessary user information. Is that how it would work with Group
> > Policy?
>
> I'm not sure what you mean by "if a non-Admin accesses our application
> for the first time, Windows Installer will add the necessary user
> information".
>
> > In other words, if a workstation User goes to Add/Remove programs to
> > install the package as you say, after it has been blessed, how is it
> > known on that workstation that the install should run with elevate
> > privileges even if someone at the User level initiates it?
>
> It is known via registry settings and whatnot that come from active
> directory in a domain environment.
>
> This is a built-in feature of Windows. When the admin at your customer's
> site marks your MSI (located on some network share) as "blessed" using
> active directory management tools, this gets propagated down to all the
> selected client computers in the domain via active directory.
>
> Instead of the "users" directly starting the install by double-clicking
> on the MSI, the computer will either 1) automatically start the install
> the next time the user logs on, or 2) will start the install when the
> user selects it from add/remove programs.
>
> The install will then run "elevated", because it has been blessed.
>
> It is important to realize that this is something that your MSI has no
> control over. This is something that your customers must do, but that
> you can give instructions/guidance on.
>
>
>
> > Also for the update piece of my puzzle, it is silent so is that where
> > the Service concept comes in?
>
> Yes. The update service or scheduled task will run in a system account.
> You will need to make a seperate .exe for this - that checks to see if
> there is an update, downloads it, and then launches it. Because this is
> running as a service/task in a system account, it is elevated (running
> with admin power, and so the launched MSI will act exactly as if an
> administrator had double-clicked on it). But, it cannot show UI, because
> it is not running inside of any particular user account (it will run
> even if there is no user logged on).
>
> > To also clear up some confusion in my head, can I eliminate the
> > concepts of Advertisement and Administrative Install from this
> > discussion in my own head (that doesn't even sound healthy)?
> > Advertisement only places access points for later install and Admin
> > Install really only places a copy of the installation media somewhere
> > on a network to be hit by installing users, correct? These really
> > have nothing to do with security/privileges in that when the install
> > would actually occur, I would see similar prompts and/or behavior
> > based on what User type is actually installing. They are not
> > 'blessed' in any way?
>
> > To sum it all up, I guess it would be up to the end user to employ
> > Group Policy for deployment or maybe we would have to recommend that
> > if that is the route on which we base our development.
>
> From a development perspective, yes, you can ignore this as it has
> nothing to do with how you make the MSI.
>
> Group policy is how your customers would deploy this app to their
> desktops. They would use "administrative install" to force install your
> app on their computers without giving the users of those computers the
> option to install it. They would use "advertisement" to allow the users
> to install your app on demand.
>
> Standard users would NOT be prompted for permission once an admin has
> blessed the install - it would just work for them. The install would run
> elevated (as if an administrator double-clicked on it) even though a
> standard user is logged in. Windows Installer and the group
> policy/blessed install stuff handles all of this magic for you - you
> have nothing special to do progrmmatically to support this - it just works.
>
> That's why I said:
>
> > I'm a bit confused in that you say you are shocked that we would be
> > able to make all users Administrators, but then you said earlier that:
>
> > "There is only ONE scenario you need your MSI to successfully work
> > under: * An administrator installs your application."
>
> Right, from a programmatic perspective, your MSI only has to work when
> an administrator installs the program.
>
> There are administrative ways (like using group policy) that will allow
> your MSI to be installed by standard users, with an administrator's
> blessing. From your MSI's perspective, it is elevated and has admin
> power... even though the user who is asking for it to be installed may
> not. The admin blessing the install is what allows this, and Windows
> takes care of making this work.
>
> > So within the environments to which our software is deployed in the
> > field, there is probably an Administrator that installs our Server
> > install (which, again, places the client install in a network share)
> > and then there are the workstation Users. Those users are exposed to
> > the client install. You are saying that Group Policy could be used to
> > install to the workstations, but if Group Policy is not used, then
> > they would have to be administrators, correct? I would then guess
> > that this is true for the initial install on a workstation, but then a
> > Service could be used to update the application?
>
> If group policy is not used (which it would not be available to your
> customers who do not have domains), their users would either have to be
> administrators, or they would need to use some other way of automating
> software installs to their computers. There are third party solutions
> for this, and there are some "do it yourself" solutions as well.
>
> For example, if the customer is not using a domain, but there is an
> administrator account on every computer that has the same password,
> they can automate installs by making a script that connects to each of
> their computers and creates a scheduled task that runs inside of a
> system account that launches the setup program.
>
> In any case, it is up to the customer to figure out how automate the
> installation of your program on their computers, considering your
> program requires admin power to install.
>
> The only other solution would be to make your setup program NOT require
> admin power to install (i.e. not install to program files, but a
> per-user location; not write any settings to HKLM; your auto-updater
> would also not be able to run as a service/scheduled task in this
> instance, since non-admins cannot register services; etc).
>
> > I definitely want this thing turned in the right direction once and
> > for all so believe me when I say I am looking for a GOOD solution. I
> > know I'm rambling but bear with me! Thanks for the help so far. The
> > information provided is great!
>
> Good to hear
>
> Basically, there is nothing you can do programmatically to cause your
> setup program to be installable by non-admins, if it has to do admin stuff.
>
> If you think about this, it makes sense. That would totally break the
> security in Vista.
>
> It is up to your customers to have some method of automated software
> installs to get this to work for them.
>
> If they have a Windows domain, this is super simple for them - Windows
> in a domain environment comes with all the tools they need to make this
> happen.
>
> If not, they will need to either have a third-party tool that allows
> managed software installations, or will have to "roll their own" solution.
>
> If your program does not require admin power and you change your setup
> program to not require admin power, then it can be installed by
> non-admins without your customers having to do anything special.
>
> In this case, you would have to handle two cases in your MSI: 1) an
> admin installs the program and 2) a non-admin installs the program.
>
> However, in a corporate environment, it is sometimes better to leave
> your setup program as requiring admin power, because allowing non-admin
> installs can increase complexity for both you and your customers.
>
> For example, non-admin installs are usually placed in a per-user
> location. This means that every user has their own copy of the program.
> If each computer has a lot of users, this is a lot of rendundant data,
> and makes upgrading more time-consuming and wasteful, as every user will
> need to download and install their own copy of an update.
>
> Also, if your install requires admin power, then the very fact that
> standard users CANNOT install your ...
>
> read more »

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.

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?

This looks promising. I would guess the service would function in a
similar manner.

THANKS FOR ALL THE HELP TO THIS POINT!

>
> 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/