Program Run On Startup

[NewsArchive]

Hi All

I have no idea how to deal with this situation. I have a program that
is being downloaded by literally tens of thousands of folk. Most of
these folk will have standalone PCs. Some are on networks that are
pretty tied down. Foe example, the users are not allowed to install
anything on the machine. I have now got the binaries code signed using
SB of course. All good and well - except - I have an issue on sites
where the regular user of the machine cannot install anything. I did a
test with an IT fellow who has a regular login to the workstation, a
local administrator login to the workstation and a login to the domain.
He can only install with the domain login. None of the others will
work. If he starts the machine and logs in with domain admin the app
starts automatically and behaves as expected. If he logs in as any of
the other two logins it does not start automatically. The program can
be run but only as administrator. So my question is how I can get the
program to run when the machine starts even though the logged in user
will not be the user who has installed the program?

The registry entry is current version run.

And I have used all the defaults asinvoker when code signing through SB
install creation.

Hope that makes sense.

Cheers
Andre

[NewsArchive]

Hi Andre,

Question: so you have installed the program "per-machine" (elevated) for all
users, right? Not "per-user" (non-elevated).

Friedrich

[NewsArchive]

Hi Friedrich

This is my problem. Where do I check that?

Andre

[NewsArchive]

Hi Andre,

>
> This is my problem. Where do I check that?
>

By default, installations are "per-machine". General Information ->
Generator Settings -> "UAC Execution Level" is set to
"requireAdministrator". This will request administrator execution level
privileges and run the setup.exe elevated. As a result, you have write
access to all system resources.

If you set the "UAC Execution Level" to "asInvoker" then the setup.exe will
launch non-elevated and can only install the program "per-user". You do not
have write access to protected Windows resources (e.g. Program Files folder
tree, the HKEY_LOCAL_MACHINE registry, etc.).

So what is your deployment strategy? Install machine wide (for all users)
or only "per-user"?

Friedrich

[NewsArchive]

Hi Friedrich

Let us break this down. If I want to write to the registry I have no
choice but to run the install set as Administrator on the machine. And
so if I want to write an entry to the registry so that the program
starts automatically when the machine starts up I can only do this as
Administrator. So this will only ever work if the person logging onto
the machine is administrator and the same administrator that ran the
install set in the first place. Is this thinking correct? Non
Administrators on the machine could never install and change the
registry and therefore could never use this program where it starts when
the machine starts. Right?

Andre

[NewsArchive]

If you want to WRITE to HKEY Local Machine, you need to be Administrator.

If you want to READ from HKEY Local Machine, you can be any user. So any
user should be OK reading the HKLM\\\CurrentVersion\Run key that you've
written with your installer.

If you want to write to HKEY Current User, you do that as any user. And the
information you write is specific to your user account.

In trying to sort out these things, Andre, it's helpful to list exactly
what's being done by the installer (which should be requireAdministrator,
and writing to HKLM), and what's being done by the application (which should
be asInvoker and writing to HKCU but reading from HKCU or HKLM.)

As for your user with the three accounts... I'd speculate that they have
some altered security or group policy settings. A local administrator
should be able to to ANYTHING on a local machine (but no network access)
unless something has altered those permissions. How does the app behave if
he logs in as a domain user account that's an ordinary user, not a domain
admin?

jf

[NewsArchive]

Hi Jane

Thanks for that. Still learning here.

> If you want to WRITE to HKEY Local Machine, you need to be Administrator.

Maybe this is where it is going all pear shaped. I understand the need
to be Administrator part. But I am not writing to HKEY Local Machine. I
am writing to HKEY Current User. The entry is in
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run . When the machine
starts I want the app to launch. I do not see any option for this under
Local Machine nor Users.

> If you want to READ from HKEY Local Machine, you can be any user. So
> any user should be OK reading the HKLM\\\CurrentVersion\Run key that
> you've written with your installer.

No idea what is meant by this. I am not reading anything. I want the
OS to launch the program when the computer starts. Who decides when and
if this will be read? Surely the OS does?

> If you want to write to HKEY Current User, you do that as any user. And
> the information you write is specific to your user account.

Maybe this is the problem. Should the entry go in there and if so how?
I do not know what to tell SB to get this inserted. But it does seem
that current user is what is required as there is personal information
being read by this app.

> In trying to sort out these things, Andre, it's helpful to list exactly
> what's being done by the installer (which should be
> requireAdministrator, and writing to HKLM), and what's being done by the
> application (which should be asInvoker and writing to HKCU but reading
> from HKCU or HKLM.)

SB is set to generate for execution level requireAdministrator. Does
that equate to writing to HKLM? I have no idea what SB will be when set
to that.

The manifest for the app is set to UAC Execution Level asInvoker. Does
that equate to writing to HKCU? I have no idea what SB is doing here
either.

> As for your user with the three accounts... I'd speculate that they have
> some altered security or group policy settings. A local administrator
> should be able to to ANYTHING on a local machine (but no network access)
> unless something has altered those permissions. How does the app behave
> if he logs in as a domain user account that's an ordinary user, not a
> domain admin?

This is the case on most corporate networks it seems. He does not have
a domain user account that is not the domain admin user. But the rest
of the staff do - yet they are not allowed to install anything. Only
the admin domain user can install anything on any workstation. And I am
guessing this is where the problem lies. I have no idea how to get
around it. Are you suggesting that if local admin was allowed to
install apps then the settings I am using above would launch the app
when the machine is logged into as ordinary domain user even though the
app was installed on the workstation as local administrator? It does
not work when installed as domain admin user. For the app to launch on
startup the login then has to be admin domain user as that is how it was
installed. If installing as local administrator and then current user
logged on as domain user will have the app launched then sweet - that
could be a solution. It then becomes a matter of allowing someone the
right to log on as local administrator and install the app. A bit time
consuming on a large network but it would work. And what about
upgrades? Could very soon become impractical.

Cheers
Andre

[NewsArchive]

Andre,

Why aren't you using the HKLM key for that?
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

*You* may not be reading from the registry, but Windows is. It can read
from HKLM for any user who's logged on (IOW, that's common setup
information).

Anything that's per-user presents challenges. Particularly if you're trying
to have your setup program create that... because your setup program doesn't
run in a standard user context.

SB or Clarion or anything else interacting with the registry will do so as
you dictate. (Or will try. Writing to HKLM from a non-elevated program
will either fail altogether if the program is correctly manifested, or may
resort to virtualization if the program isn't manifested.)

In the Edit Registry script item in SB, if you select HKEY_Local_Machine
that's where you'll write. And successfully, since you're manifesting your
installer requireAdministrator.

I'd suggest you try having your installation write to the HKLM key I
reference above. This will mean that the installation will need to be
performed by somebody who has admin rights on the machine. After that, this
particular issue shouldn't be a problem for ordinary users.

As for your admin guy... if he's a domain admin, instruct him politely to
create for himself a non-admin account in his domain. I always have
"ordinary user" accounts for my use testing anything I need to test.

This stuff can easily get quite frustrating until you wrap your head around
it. Just remember, it's not an SB issue. It's the world that Microsoft
inverted starting with Vista. You'll find a lot of good info on Friedrich's
forum: http://www.lindersoft.com/forums/

jf

[NewsArchive]

> Why aren't you using the HKLM key for that?

Jane,

I think Andre is currently caught between a rock and a hard place.

If you re-read his posts, he says that he needs for the install to be able
to be made by non-Admin accounts.

So without an over the shoulder authorization, the installer could not be
an elevated installer (and I think he said the installer is currently
AsInvolker).

This means that both his app and his installer need to be manifested
AsInvolker AND he needs to install to some other path than under the
Program Files folder (as well as not need to update any Windows files or do
other Admin level things from the installer).

So that will eliminate the installer being able to write to HKLM.


Now this leaves him with the option of writing to HKCU, but IIRC he will
run into problems there because "Andre the user" could install the program
and have it set to auto-run, but if "Andre the administrator" logs in I
don't think it will see the setting (I could be wrong here - not tested).


What the answer may be for him is to forget about trying to write that
setting from inside SetupBuilder and simply use the Clarion app to write to
HKCU.

In the app he can simply read the setting on startup and if it is blank
(instead of 1/0) he can prompt the user about auto running the app (or
simply set it to auto run and store that in the Registry from the app as
the default).

Also if he is launching the program at the end of the install, he should
set that to run non-elevated just in case the install was from an Admin
level user and Windows decided to chain load the app as elevated. That
will prevent the app from being started elevated and writing data to the
wrong place in the Registry.

Then the app would always read from HKCU on startup.

After that if the user uses an option in the program to turn off auto run,
then the app would update the HKCU key and it should be successful (and
read correctly on the next startup).

I **believe** that might get him out of the woods.


:-)

Charles


--
-------------------------------------------------------------------------------------------------------
Charles Edmonds

cjeByteMeSpammers@lansrad.com (remove the "ByteMeSpammers" to email me)
www.clarionproseries.com - ImageEx, ProScan, ProImage, ProPath and other
Clarion developer tools!
www.seal-soft.com - The xProduct Clarion templates - xWordCOM, xToolTip,
xDataBackup Manager and more!
www.ezchangelog.com - "Free ChangeLog software to manage your projects!"
www.setupcast.com - "A revolutionary new publishing system for software
developers - enhanced for SetupBuilder users!"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms - Now with PNG support!
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------

[NewsArchive]

Agreed, Charles.
Rock and hard place.

Personally, I'd choose the rock - and say the app needs an admin
(over-the-shoulder, if need be) installation. So it's "done right".

Your approach is ultimately giving each user control over whether the app
runs at startup. Which is fine if that's what he wants, but didn't appear
to be the desired behavior.

As with so many situations, the carbon-based challenges often outweigh the
silicon-based ;-)

jf