per-user install with SetpubBuilder

[rbautistaole]

Hi.
I'm new user of SetupBuilder, and i have reached build a setup for my application.
However i´m a little frustrated because i don´t have reached build a per-user setup in windows vista. I set the setup requireAdministrador and when i run the setup in a standard user, a dialog box ask a administrator user and password, when the setup is finished, the shorcuts are not build in the standard user menus, but in the administrator menus. I understand this behavior related to UAC from windows vista, but i think that setubbuilder should be this scenary in your generated setups.

I read the next blog
http://blogs.msdn.com/rflaming/archi...01/780199.aspx
and this say about the "MSI install vs custom install"

"Generally elevated programs write to the administrator's profile that provided the credentials rather than the Standard User that invoked the program. Windows Installer is designed to handle this case correctly."

What do you think about this? Can build a per-user install with a setup builded developed with Setup builder?

thanks and excuse my bad english please.

[linder]

Hello,

As a SetupBuilder setup developer, it is possible (but not recommended) to create an installation that will not prompt the user for elevation.

Set "General Information -> Generator Settings -> Requested Execution Level to "asInvoker" and then use the "Set Installer Flag" to set the $SB_ALLUSERSFLAG$ to 0

Set Installer Flag $SB_ALLUSERSFLAG$ to "0"

In this case, it will be installed for the current user.

But please keep in mind that you cannot write to any protected area now. This means that all files and registry must be created in a per-user location and no function require administrator privileges. A Standard User CAN'T write

Anything protected by Windows Resource Protection.
Anything under c:\Windows
Anything under c:\Program Files
Anything under c:\Users\<Other Peoples Profiles>
Anything in c:\Users\All Users
Anything under c:\Program Data
Anything under the non-mapped root drive (c:, d:, e:, etc)

Does this help?

Friedrich

[rbautistaole]

Thanks Friedrich.

I understand your point.

However i wanted point to the fact that the Windows installer seems support build a msi thas ask for elevation and still can be installed for the current user. Creating the shortcuts for the current user.

From my point of view this make the windows installer a better option for building setups.

[rbautistaole]

Hi Friedrich.
Please don´t bad understand to me. (could be my bad english?). I have has using msi packages and found them very restrictive and because that I found SetupBuilder. But in the blog that I point to you seems say that is posible elevate and at the same time preserve info about the original standard user for configure it and not the elevated admin.

http://blogs.msdn.com/rflaming/archi...01/780199.aspx
"Generally elevated programs write to the administrator's profile that provided the credentials rather than the Standard User that invoked the program. Windows Installer is designed to handle this case correctly."

Therefore, i think that if WindoswInstaller can, then SetupBuilder can too.

You make me happy if SetupBuilder could handle a per-user installation with admin elevation and at the same time create shortcuts and other invoker user information.

thanks.

[linder]

Hello,

Your English is excellent

Most (I believe at least 97%) of all installations must be run in a per-machine context with administrative privileges. Even the brand new InstallShield 2008 and Wise Installation Studio set the ALLUSERS property to 1 by default now in all new MSI projects. This is the recommended implementation!

I have to disagree respectfully to your "From my point of view this make the windows installer a better option for building setups" statement <g>.

Friedrich

[CMS Software]

There is some confusion on my part and apparently on the part of many other software developers about the user privileges under Vista. In XP many machines were configured so that only Administrators could install software. This kept employees (who were all Restricted users) from introducing viruses and trojans by preventing them from installing anything!

The problem this created for us was that the Restricted end users could not install our software. IT would send somebody over (let's say he is Steve) to log in as himself (an Administrator) and install Linda's software (she is a Restricted user).

Big problem. Steve could now see and run our software but Linda, as a Restricted user, could not see the icon or run the software.

The workaround, which always worked, was to have the Administrator (Steve) log in using his elevated account and change Linda from Restricted to Administrator. He would then log out as Steve and log in as Linda who is now a temporary Administrator. Now he would install the software while logged in as Linda with Administrator level access.

Once the install was finished, Steve would log Linda out of the system, log back in as himself and change Linda back to a Restricted user. Since the software was installed under Linda's login while she was an Administrator, she could see the program icon and run the software even though she is now a Restricted user.

The IT department complained about the extra work, but most of them understood that with locked down machines there was no other way to do it.

Is this also the situation with Vista? Does the end user have to be elevated to Aministrator long enough to do the install and then be moved back to Standard User level?

I'm asking this because so many different sites give so many different answers. Since you are an install expert, I figure you will know the correct answer.

I'm also wondering if the Vista Manifest File feature helps with this situation at all?

-O. D.-

[linder]

Hello,

A normal Windows application should not require administrative privileges. That's why on Vista, even administrative accounts don't use the full-access token by default. The goal of a normal "UAC-aware" application is to start with the access token of the running account, and only request promotion to full-access token when actually needed. This process of promotion is called "privilege elevation", and requires that user confirms the action, before it is actually executed. Privilege elevation is a new feature and a permanent change to the Windows operating system.

Privilege elevation allows administrators to run the majority of their applications at a safe privilege level, but also allow processes and operations that require administrative privileges. UAC supports "over-the-shoulder" authentication so that an Administrator can grant elevated privileges to a program while a Standard User is currently logged onto the system.

So what you need for Vista and Windows Server 2008 is a Vista-aware application. You already have a Vista-aware installer with SetupBuilder 6. Now you have to make sure your applcation is Vista-aware (requests "asInvoker" execution privileges and follows the new Vista rules - e.g. do not write to Program Files, to the Windows folder, to HKEY_LOCAL_MACHINE, etc.). Your application should be a mixed-mode application that works fine elevated and non-elevated.

SetupBuilder requests administrator excution level privileges (installers should always do this) and installs your application. You do not start the installed application at the end of the installation from the installer (under Vista/2008)! The user starts the application and everything is running non-elevated.

Does this help?

Friedrich

[linder]

Sorry, we have been working on the .msi compiler for SetupBuilder all the day so the above ALLUSERS answer was somewhat cryptic. The ALLUSERS property set to 1 in a .msi means that the installation is excuted per-machine context with administrative privileges under Vista/2008.

Friedrich

[linder]

I think SetupBuilder 6 itself is a good example for a "mixed-mode" Vista application. SetupBuilder works fine on Vista/Windows Server 2008 in both Admin and Standard User modes. So let us use SetupBuilder to demonstrate the installation and configuration scenario.

1. Create a Standard User Account under Vista

We create a new "JoeUser" Standard User account under Vista and switch to it.

The main goal of User Account Control (UAC) is to reduce the exposure and attack surface of the operating system by requiring that all users run in standard user mode. This limitation minimizes the ability for users to make changes that could destabilize their computers or inadvertently expose the network to viruses through undetected malware that has infected their computer.

2. Execute the SetupBuilder installer

Whenever Standard Users attempt an administrative task, such as software installation, they will be prompted for an administrator password. If they know their local administrator password they may enter it then or ask an IT administrator for assistance. This process is called over-the-shoulder (OTS) credentials. IT administrators can disable this feature, in which case the user is simply informed that they do not have the permission to perform the operation.

See figure1.jpg.



The SetupBuilder install image is Vista-aware and code-signed. You see the "Linder Software" company name in this dialog. There are a couple of variations of the prompt, depending on whether executable is digitally signed or not. Vista encourages use of digital signatures by displaying a "nicer" elevation prompt for signed executables than unsigned ones.

3. Per-User Configuration

The installer finished the SetupBuilder installation process. Under Vista, it does not give the option to start the installed application at the end of the installation.

The application itself (not the installer!) should do all the Per-User Configurations now. This can be done at first run of your application and this enables per-user state for each user.

See figure2.jpg.



JoeUser started the SetupBuilder application unelevated (no elevation prompt - it does not request administrator execution level privileges) and the program did the per-user configuration. JoeUser has its own "SetupBuilder 6 Projects" folder under Documents now.

4. Compile a Project "unelevated"

We create and compile a test installation project. The project compiles into the C:\Users\JoeUser\Documents\SetupBuilder 6 Projects

See figure3.jpg



5. Run as administrator

What happens if SetupBuilder is started with "Run as administrator" under the Standard User account?

See figure4.jpg



Because we are running under the Standard User account, we are prompted for an administrator password. "Linder" is the administrator account.

See figure5.jpg



The application started elevated and, because it was the first run as Admin, the application does the per-user configuration.

6. Compile a Project "elevated"

See figure6.jpg



We create and compile a test installation project. Please note that we have administrative privileges now. So this time the project compiles into the C:\Users\Linder\Documents\SetupBuilder 6 Projects. That is the Admin's profile.

Hope this helps!

Friedrich

[Unregistered]

Very nice! Thank you for that information!

I really love the product

Alan Connor