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/archive/2006/10/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.

http://www.lindersoft.com/community_images/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.

http://www.lindersoft.com/community_images/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

http://www.lindersoft.com/community_images/figure3.jpg

5. Run as administrator

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

See figure4.jpg

http://www.lindersoft.com/community_images/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

http://www.lindersoft.com/community_images/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

http://www.lindersoft.com/community_images/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

[CMS Software]

If I understand this correctly, the SB Install program CAN write to HKEY_LOCAL_MACHINE, but the appications it installs to run under Vista cannot write to HKEY_LOCAL_MACHINE. However, those applications can READ from HKEY_LOCAL_MACHINE. Is this correct?

-O. D.-

[linder]

Hello,

Yes, this is correct. The install can read/write HKEY_LOCAL_MACHINE, the "asInvoker" privilege requesting application can only read HKEY_LOCAL_MACHINE.

The same is true for the "Program Files", "Windows", etc. folders. The install can write to those locations, the application can only read.

Friedrich

[CMS Software]

A follow on question.

In XP we've always put some universal constants in HKEY_LOCAL_MACHINE/CMSAPPS/.

This allows ALL users to find those constants when they run our programs. We also put some status settings in the same location. Those status settings can be changed by ANY user from within our application program, but the settings apply to ALL users.

Since our app cannot write to HKEY_LOCAL_MACHINE under Vista, where should our app store its universal constants so that they are accessible to all users. Obviously HKEY_CURRENT_USER would only be visible to the user logged in when the changes are made, other users would never see them.

Any suggestions?

-O. D.-

[linder]

Hello,

Well, the technically correct answer is that you can't use the Registry in this case.

As a workaround, we developed the following method (but it's really not recommended).

http://www.lindersoft.com/forums/showthread.php?p=11032&highlight=hkey_local_machine#post11032

I know that quite a few users are still using the above Vista workaround, but (IMO) we all should follow the new Vista "rules".

What you can do is to write such information to a file and store it in a folder that is accessible and writable by all users.

What do you think?

Friedrich