VISTA and Power Users?

[Superfreak3]

I'm working on getting our application installation ready for VISTA
and hope I'm almost there. I just want to verify the following...

from technet2.microsoft.com....

Understanding and Configuring User Account Control in Windows Vista
Migrating from the Power Users
"UAC does not leverage the Power Users group, and the
permissions granted to he Power Users group on Windows XP have been
removed from Windows Vista."

Does this mean that the concept of Power Users no longer exists in
Vista at all or only that the PU concept is no longer available if UAC
enabled?

Later in this section I see "To use the Power Users group on Windows
Vista, a new security template must be applied to change the default
permissions on system folders and the registry to grant PU gropu
permissions equivalent to Windows XP."

The reason I pose the question is that in testing the install, it runs
through with UAC enabled. If I disable it and try to install with a
user I've added to the Power Users group (no new security template
applied), I get a 1303 error indicating I don't have permissions to
the Program Files\My App location. If I install with UAC disabled as
an Admin, I'm OK.

I thought I also read somewhere, maybe in the same document, that
Program Files is now similar to System folders with regard to security
now in Vista. ??

A brief answer(s) is all I'm looking for here, nothing too detailed (I
know that may be impossible with Vista.). I think I've read all the
Microsoft 'stuff' I can at this point. My head is spinning.

Any help is greatly appreciated!

Thanks in advance!!

 

[Jimmy Brush]

I'm working on getting our application installation ready for VISTA
and hope I'm almost there. I just want to verify the following...

from technet2.microsoft.com....

Understanding and Configuring User Account Control in Windows Vista
Migrating from the Power Users
"UAC does not leverage the Power Users group, and the
permissions granted to he Power Users group on Windows XP have been
removed from Windows Vista."

Does this mean that the concept of Power Users no longer exists in
Vista at all or only that the PU concept is no longer available if UAC
enabled?

Later in this section I see "To use the Power Users group on Windows
Vista, a new security template must be applied to change the default
permissions on system folders and the registry to grant PU gropu
permissions equivalent to Windows XP."

The reason I pose the question is that in testing the install, it runs
through with UAC enabled. If I disable it and try to install with a
user I've added to the Power Users group (no new security template
applied), I get a 1303 error indicating I don't have permissions to
the Program Files\My App location. If I install with UAC disabled as
an Admin, I'm OK.

I thought I also read somewhere, maybe in the same document, that
Program Files is now similar to System folders with regard to security
now in Vista. ??

A brief answer(s) is all I'm looking for here, nothing too detailed (I
know that may be impossible with Vista.). I think I've read all the
Microsoft 'stuff' I can at this point. My head is spinning.

Any help is greatly appreciated!

Thanks in advance!!

The "concept" of power users is gone.

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.

Program Files has always been "restricted" for standard users in the
manner you speak of. It is important that this be so, because if any
user and any program could just overwrite system-wide .exe's, they could
easily hijack other applications, hijack other users, and elevate their
account/program to administrator status.

Also, in order for your program to use the extra "Power Users" power,
your application must explicitly tell Windows that it wants the extra
power by including a Vista-style manifest with your application that
specifies a requestedExecutionLevel of "highestAvailable".

This will cause your program to prompt for admin power if the user is an
administrator, silently receive the extra power if the user is a power
user, and run with no extra power if the user is a standard user.

The power users "experience" is pretty broken in Vista. For example,
explorer does not ask to use the "power user" power, so power users
cannot use their extra privileges when using windows explorer.

Confused yet?

 

[Superfreak3]

Superfreak3wrote:










The "concept" of power users is gone.

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.

Program Files has always been "restricted" for standard users in the
manner you speak of. It is important that this be so, because if any
user and any program could just overwrite system-wide .exe's, they could
easily hijack other applications, hijack other users, and elevate their
account/program to administrator status.

Also, in order for your program to use the extra "Power Users" power,
your application must explicitly tell Windows that it wants the extra
power by including a Vista-style manifest with your application that
specifies a requestedExecutionLevel of "highestAvailable".

This will cause your program to prompt for admin power if the user is an
administrator, silently receive the extra power if the user is a power
user, and run with no extra power if the user is a standard user.

The power users "experience" is pretty broken in Vista. For example,
explorer does not ask to use the "power user" power, so power users
cannot use their extra privileges when using windows explorer.

Confused yet?

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

- Show quoted text -

Oh, big time confused! I guess we'll just have to waddle our way
through.

My immediate concern if for installation of our software at the moment
as that is basically what I do.

Our previous installation was allowed or designed, I should say for
Admins and Power Users, so I was just wondering what the impact would
be to our installations where end users may have utilized Power Users
to install.

Painting with a broad stroke, it looks as though installation Custom
Actions and ensuring their execution is one of the big 'battles' with
readying pre-Vista install packages for Vista.

I guess the other concept would be to develop a purely Standard User
or user install. ??

Any more information with regard to impact on our installs caused by
Vista would be, as always, GREATLY appreciated!

Thanks for the info so far!!!

 

[Jimmy Brush]

Oh, big time confused! I guess we'll just have to waddle our way
through.

My immediate concern if for installation of our software at the moment
as that is basically what I do.

Our previous installation was allowed or designed, I should say for
Admins and Power Users, so I was just wondering what the impact would
be to our installations where end users may have utilized Power Users
to install.

Painting with a broad stroke, it looks as though installation Custom
Actions and ensuring their execution is one of the big 'battles' with
readying pre-Vista install packages for Vista.

I guess the other concept would be to develop a purely Standard User
or user install. ??

Any more information with regard to impact on our installs caused by
Vista would be, as always, GREATLY appreciated!

Thanks for the info so far!!!

Hello,

I am not very familiar with Windows Installer on a technical level, so
this may be a better question for the more programmer-oriented msdn forums.

However, I think I can kind of explain at a high-level what you will be
working towards..

- you will need to keep your installation program from requiring the
user to be an administrator when the setup first starts (which will lock
out power users). This can be tricky, since windows by default assumes
setup programs require an admin to run them, but if you are using
Windows Installer you should be able to get around this easily.

- Thing is, if the user really IS an administrator, and your setup
program does NOT ask for admin power, then you will end up locking out
administrators!

- And if you get your setup program to NOT prompt for admin power, I'm
not sure if it will run as highestAvailable (where it would be able to
use the extra power user privileges and it would work), or whether it
would just ignore the extra privileges and still locking out power users!

What you really need is for your installer to run under the setting I
mentioned in my previous post ("highestAvailable"), where if it's an
administrator then prompt for admin power, if not, just run with the
highest privilege we can get.

But I really don't know how you would accomplish that using Windows
Installer.

The solution might be to have some sort of bootstrapper program that
determines the type of user and then launches the appropriate setup
program based on that.

 

[Superfreak3]

Hello,

I am not very familiar with Windows Installer on a technical level, so
this may be a better question for the more programmer-oriented msdn forums.

However, I think I can kind of explain at a high-level what you will be
working towards..

- you will need to keep your installation program from requiring the
user to be an administrator when the setup first starts (which will lock
out power users). This can be tricky, since windows by default assumes
setup programs require an admin to run them, but if you are using
Windows Installer you should be able to get around this easily.

- Thing is, if the user really IS an administrator, and your setup
program does NOT ask for admin power, then you will end up locking out
administrators!

- And if you get your setup program to NOT prompt for admin power, I'm
not sure if it will run as highestAvailable (where it would be able to
use the extra power user privileges and it would work), or whether it
would just ignore the extra privileges and still locking out power users!

What you really need is for your installer to run under the setting I
mentioned in my previous post ("highestAvailable"), where if it's an
administrator then prompt for admin power, if not, just run with the
highest privilege we can get.

But I really don't know how you would accomplish that using Windows
Installer.

The solution might be to have some sort of bootstrapper program that
determines the type of user and then launches the appropriate setup
program based on that.

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

- Show quoted text -

--"To use the Power Users group on Windows
Vista, a new security template must be applied to change the default
permissions on system folders and the registry to grant PU group
permissions equivalent to Windows XP."

Would anyone know how to go about applying this 'new security
template' so that the Power Users group will mimic security behavior
as in XP?

Any pointers on doing this would be greatly appreciated and would
prove beneficial in my testing. Currently, my application
installation will run with UAC enabled after credentials are provided,
but when I attempt to install as a Power User (VISTA out of the box
with no changes to policies/security) with UAC disabled, the
installation fails because I do not have permission to access the
Program Files folder (at least that's what I recall the message
indicating).

APPRECIATED!!

 

[Superfreak3]

--"To use the Power Users group on Windows
Vista, a new security template must be applied to change the default
permissions on system folders and the registry to grant PU group
permissions equivalent to Windows XP."

Would anyone know how to go about applying this 'new security
template' so that the Power Users group will mimic security behavior
as in XP?

Any pointers on doing this would be greatly appreciated and would
prove beneficial in my testing. Currently, my application
installation will run with UAC enabled after credentials are provided,
but when I attempt to install as a Power User (VISTA out of the box
with no changes to policies/security) with UAC disabled, the
installation fails because I do not have permission to access the
Program Files folder (at least that's what I recall the message
indicating).

APPRECIATED!!- Hide quoted text -

- Show quoted text -

More information requests for help....

(From a different/previous post reply...) You say...

"Signing will not negatively affect your MSI file use downlevel from
Vista.
However it won't suddenly allow you to by-pass UAC prompts. Your
application will have to be elevated in order to silently run the
installation without prompts -- either that or have a service perform
the
installation for you. "

What do you mean by 'your application will have to be elevated in
order to silently run the installation without prompts'? Do you mean
there is a way to elevate the .msi so it can be run silently?

Also, you follow that up with 'either that or have a service perform
the installation for you'. How can this be accomplished, with a
service? Is there any documentation out there to explain this?

The reason I ask these questions it because we currently have an
install that is basically writing 'stuff' all over the place with
regards to the registry. It also defaults to an installation location
under Program Files, which most end users leave unchanged, but is now
considered sacred in VISTA so if they are not an Admin (this occurs
with UAC disabled in my testing as well) they receive a message
indicating the install cannot continue.

Our mechanism of updating our client piece is that our application
looks to an .ini for various information. If the information
indicates an update is available, our .msi is installed silently.
This probably will not work any longer in VISTA so I will have to
search for an alternative here as well.

I've inherited these various installs since starting my new job last
December. They basically have to be reworked. Its difficult because
there is some third party stuff in there that writes to HKLM, etc.,
which is tough to deal with in locked down environments where
installing users are not Admin's. The workaround in earlier OSs to
VISTA was to indicate that Power Users would be an acceptable means of
installation. In Vista, this concept seems to no longer apply really.

If anyone out there knows of where I can turn for possible consulting
services with regard to installation and security, please let me
know. It seems as though you really need someone close to or part of
Microsoft to guide you through.

THANKS IN ADVANCE FOR ANY HELP, INFORMATION, LINKS PROVIDED!!

 

[Jimmy Brush]

More information requests for help....

(From a different/previous post reply...) You say...

"Signing will not negatively affect your MSI file use downlevel from
Vista.
However it won't suddenly allow you to by-pass UAC prompts. Your
application will have to be elevated in order to silently run the
installation without prompts -- either that or have a service perform
the
installation for you. "

What do you mean by 'your application will have to be elevated in
order to silently run the installation without prompts'? Do you mean
there is a way to elevate the .msi so it can be run silently?

Elevated means that the program is running with admin power - which
means it was either started by an administrator interactively, or it was
started by the system outside of any user account(invisible), for
example, from a service or a scheduled task.

The important point here is that non-admins cannot install random
machine-wide programs.

An actual administrator will have to in some fashion choose to install
your program, since it needs to do muck about with system files and
settings. Standard users just can't do it.

Now, there are many ways an admin can install your program. This doesn't
necessarily mean that an admin will have to physically go to each
computer to perform the installation.

They can use group policy if in a domain environment to push the program
down to people.

http://www.windowsnetworking.com/ar...roup-Policy-Based-Application-Deployment.html
http://technet2.microsoft.com/windo...660d-4de6-aac4-8a03974796121033.mspx?mfr=true

Or, they can use alternative deployment methods to get the app there.
(It can be as simple as making a program or script that connects to all
the computers, creates a scheduled task that runs as system and launches
an msi file in silent mode located on a network share somewhere).

Also, you follow that up with 'either that or have a service perform
the installation for you'. How can this be accomplished, with a
service? Is there any documentation out there to explain this?

Basically, you create a service program that starts msiexec against your
msi, with the correct flags to run in quiet mode (since a service runs
outside of any user account, no UI is visible to any users).

The reason I ask these questions it because we currently have an
install that is basically writing 'stuff' all over the place with
regards to the registry. It also defaults to an installation location
under Program Files, which most end users leave unchanged, but is now
considered sacred in VISTA so if they are not an Admin (this occurs
with UAC disabled in my testing as well) they receive a message
indicating the install cannot continue.

Which is how it was in every previous version of Windows NT.

It worked for you before because you made your users administrators (aka
power users).

Our mechanism of updating our client piece is that our application
looks to an .ini for various information. If the information
indicates an update is available, our .msi is installed silently.
This probably will not work any longer in VISTA so I will have to
search for an alternative here as well.

You need to separate out your update logic into its own program that
will run privileged outside of any specific user account, and so will be
invisible - it cannot show UI.

You could either rewrite your update program as a service, or you could
just use it as-is and register it as a scheduled task that runs under a
system account.

Your initial setup program would register the update service or
scheduled task programmatically.

Alternatively, you might look into turning your updates into MSP's
(windows installer patches). If you follow the correct procedures, MSP's
can be launched and installed inside of a standard user account.

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

I've inherited these various installs since starting my new job last
December. They basically have to be reworked. Its difficult because
there is some third party stuff in there that writes to HKLM, etc.,
which is tough to deal with in locked down environments where
installing users are not Admin's. The workaround in earlier OSs to
VISTA was to indicate that Power Users would be an acceptable means of
installation. In Vista, this concept seems to no longer apply really.

You're right, power users aren't supported anymore because there really
is no such thing as a power user from a security perspective. Power
users = administrators.

If anyone out there knows of where I can turn for possible consulting
services with regard to installation and security, please let me
know. It seems as though you really need someone close to or part of
Microsoft to guide you through.

THANKS IN ADVANCE FOR ANY HELP, INFORMATION, LINKS PROVIDED!!

Hope this information helps.

 

[Superfreak3]

Elevated means that the program is running with adminpower- which
means it was either started by an administrator interactively, or it was
started by the system outside of anyuseraccount(invisible), for
example, from a service or a scheduled task.

The important point here is that non-admins cannot install random
machine-wide programs.

An actual administrator will have to in some fashion choose to install
your program, since it needs to do muck about with system files and
settings. Standard users just can't do it.

Now, there are many ways an admin can install your program. This doesn't
necessarily mean that an admin will have to physically go to each
computer to perform the installation.

They can use group policy if in a domain environment to push the program
down to people.

http://www.windowsnetworking.com/ar...t.com/windowsserver/en/library/45a873dd-660d-...

Or, they can use alternative deployment methods to get the app there.
(It can be as simple as making a program or script that connects to all
the computers, creates a scheduled task that runs as system and launches
an msi file in silent mode located on a network share somewhere).


Basically, you create a service program that starts msiexec against your
msi, with the correct flags to run in quiet mode (since a service runs
outside of anyuseraccount, no UI is visible to any users).


Which is how it was in every previous version of Windows NT.

It worked for you before because you made your users administrators (akapowerusers).




You need to separate out your update logic into its own program that
will run privileged outside of any specificuseraccount, and so will be
invisible - it cannot show UI.

You could either rewrite your update program as a service, or you could
just use it as-is and register it as a scheduled task that runs under a
system account.

Your initial setup program would register the update service or
scheduled task programmatically.

Alternatively, you might look into turning your updates into MSP's
(windows installer patches). If you follow the correct procedures, MSP's
can be launched and installed inside of a standarduseraccount.

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


You're right,powerusers aren't supported anymore because there really
is no such thing as apoweruserfrom a security perspective.Power
users = administrators.



Hope this information helps.

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

- Show quoted text -

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

 

[Superfreak3]

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?

 

[Jimmy Brush]

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/library/aa372468.aspx
http://blogs.msdn.com/rflaming/arch...ions-in-comments-from-earlier-blog-posts.aspx

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.

 

[Superfreak3]

Superfreak3wrote:


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/li...laming/archive/2006/10/01/uac-in-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!!

 

[Jimmy Brush]

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/articles_tutorials/Group-Policy-Deploy-Applications.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.

 

[Superfreak3]

Superfreak3wrote:



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/articles_tutorials/Group-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.



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.


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.

 

[Jimmy Brush]

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

 

[Superfreak3]

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!

 

[Jimmy Brush]

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.

 

[Superfreak3]

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'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".


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.




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



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:



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.


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


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!

 

[Superfreak3]

...

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!

 

[Superfreak3]

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'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".


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.




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



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:



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.


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


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!

 

[Jimmy Brush]

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.