Weird registry Setting Behaviour

[NewsArchive]

Hi Andre,

> I took the registry setting command out of the script and it trashed a
> per-user setting. I crapped the project and rebuilt it with the exact
> same settings and it did not trash the settings. The only difference is
> the new project is a .sbp project and the old one is a version 7
> project. I will send you the old one.

See attached screenshot. You have added the "Create/update Registry Key and
Value" script command in Line 2. You can do this, sure. But you set the
real value for %_SB_INSTALLDIR% later in Line 30. So your write action in
Line 2 makes use of an empty %_SB_INSTALLDIR% value.

And another quick note: you are writing a "per-user" setting from an
elevated "per-machine" running application (the installer). Per-user
settings should never be done from an elevated running app!

Does this help?

Friedrich

[NewsArchive]

BTW, and "Data Type" should be "String".

Friedrich

[NewsArchive]

Hi Friedrich

I did not notice that.

This per user versus as invoker thing I have never really understood.

I now create/edit this registry setting when the user launches the app.
It is only that way that I know it will work. This registry setting
actually becomes irrelevant on a corporate network as users are
typically not allowed to install but only allowed to run. So SB cannot
attend to this at the point of installing.

When I created the new project I must have accidentally got it right,
copying from two others that are working.

Thanks for the help.

Cheers
Andre

[NewsArchive]

Hi Andre,

> I did not notice that.
>
> This per user versus as invoker thing I have never really understood.

Some background information: in Windows XP, the first user created when
installing the operating system was given administrative privileges by
default. As such, most users used this account for everyday use. As a
result, all software (including malware!) was also running with
administrator privileges, giving it full access to the operating system.

Windows Vista introduced the Windows User Account Control (UAC) feature.
UAC allows you to login as a Standard User, but still perform administrator
tasks without having to switch users, log off, or use 'Run As'. This limits
the risk of users making changes that could harm their computers. It also
prevents malware from attempting to infect computers undetected.
Administrators can run most applications with limited privileges, but can
temporarily "elevate" their privileges when they need to perform an
administrative task (e.g. installations). A "Standard User" account is
synonymous with a "Limited User" account in Windows XP.

With UAC enabled, all processes execute with Standard User (token)
privileges, unless specifically elevated by an administrator. UAC starts
working when a user logs onto the Windows machine. During an interactive
login, the Local Security Authority (LSA) takes the user's credentials and
performs the initial logon, evaluating the user's token to check if it has
"elevated privileges". If the LSA determines that the user has elevated
privileges, it will filter this token and then perform a second logon with
the filtered token.

That means, 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. When "elevation" is performed by a Standard User
account, it's referred to as an "Over the Shoulder" (OTS) elevation because
it requires the entry of credentials for an account that's a member of the
administrator's group, something that's usually completed by another user
typing over the shoulder of the Standard User. An elevation performed by an
Administrator Approval Mode (AAM) user is called a "Consent elevation"
because the user simply has to approve the assignment of his administrative
rights.

In other words, we have two types of administrators on UAC-aware operating
systems, with User Account Control in effect:

1.) a "non-elevated" administrator who is a member of the Administrators
group. He has performed a normal logon to the Windows machine and is
running with a special minimal set of privileges designed to approximate a
normal non-Administrator user.

2.) an "elevated" administrator running an application using the "Run As
Administrator" feature to run with elevated Administrator privileges.

The desktop session and explorer.exe will always be created with a token
that approximates the token of a member of the Users group. Any process
that is initiated from the Start Menu or by double-clicking in an Windows
Explorer window that doesn't require elevation will simply inherit this
filtered token. By default, every application will be running with the
Standard User token.

Let us assume, you have an "AndreL" administrator account and a "JoeUser"
Standard User account. If "JoeUser" starts the setup.exe installation, UAC
determines that the Current User does not have a token of sufficiently high
Integrity Level and the Credentials Prompt asks the user to provide a
username and password of someone who has sufficient rights (AndreL).
Windows will then create the necessary token for that user and uses it to
elevate the process so you can now continue with the installation. Please
note that you are on a completely different profile after the elevation
process. You have switched from the "JoeUser" profile to the "AndreL"
administrator profile! In other words, you write the per-user registry key
to the "AndreL" and not the "JoeUser" profile!

> I now create/edit this registry setting when the user launches the app. It
> is only that way that I know it will work. This registry setting actually
> becomes irrelevant on a corporate network as users are typically not
> allowed to install but only allowed to run. So SB cannot attend to this
> at the point of installing.

To write to the real user's "SOFTWARE\Microsoft\Windows\CurrentVersion\Run "
(per-user) registry key from a "per-machine" (elevated) running
installation, you can do the following (if you need any help, just let me
know). Just create a simple SetupBuilder "helper.exe" (Execution Level set
to "asInvoker", uninstall disabled, add all your per-user actions), add it
as a "Support File" to your main project and call it from your main
setup.exe (Run Program... -> Enable "Launch non-elevated under UAC").

http://www.lindersoft.com/forums/sho...9339#post39339

If you need this per-user key on all current and future OS profiles, you
have to do this from your own application (at first startup). This is by
Windows design.

Does this help?

Friedrich

--
Friedrich Linder
Lindersoft | SetupBuilder | www.lindersoft.com
954.252.3910 (within US) | +1.954.252.3910 (outside US)

--SetupBuilder "point. click. ship"
--Helping You Build Better Installations
--Create Windows 10 ready installations in minutes
--Official COMODO Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Andre,

> I now create/edit this registry setting when the user launches the app.
> It is only that way that I know it will work. This registry setting
> actually becomes irrelevant on a corporate network as users are
> typically not allowed to install but only allowed to run. So SB cannot
> attend to this at the point of installing.

I have some files that I install with BA, but because they are pr. user
and I can't install them pr. user when I install BA, what I do is I
simply copy the files from the "public" location to the "user" location
when the program runs. It checks every time it starts if the files are
in the "user" folder and if not, they are copied from the "public" folder.

Same with some registry keys - they get copied from HKLM to HKCU. Bit
of a pain, but works

Best regards,


--
Arnor Baldvinsson
Icetips Alta LLC

[NewsArchive]

Thanks for that explanation. Makes more sense now.

Andre Labuschagne