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/library/windows/desktop/aa376977(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

[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 ;-)

LOL - exactly!


:-)

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]

Hi Andre,

> 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

All software that I use just handles this setting in the program itself,
rather than at installation time. Simply default the program to start
automatically by letting it add the RUN key value first time it runs.

Here is how I would solve it:

When the program starts for the first time, set it to run automatically.
Simply write to the registry key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Run

The name of the value is whatever software name you want and the value
is the full path and parameters to run the program. For example here is
what OneDrive put in my machine:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Curre ntVersion\Run
Value Name: OneDrive
Value: "C:\Users\Arnor\AppData\Local\Microsoft\OneDrive\On eDrive.exe"
/background

The "/background" is a parameters.

This means that it will always run at startup for THIS user.

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

[NewsArchive]

Hi Andre,

> HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Curre ntVersion\Run
> Value Name: OneDrive
> Value: "C:\Users\Arnor\AppData\Local\Microsoft\OneDrive\On eDrive.exe"
> /background

To do this in Clarion:


PUTREG(REG_CURRENT_USER,'SOFTWARE\Microsoft\Window s\CurrentVersion\Run','OneDrive','"C:\Users\Arnor\AppData\Local\Microsoft\OneDrive\On eDrive.exe"
/background')

That's all there is to it. The program will now run automatically
whenever this user starts windows.

PS: Letting people who are NOT supposed to install anything, install
*your software* is unlikely to make your software popular by those who
are in charge of the networks! Personally I would never encourage
people to break the rules they are supposed to work under. That could
come back and bite you badly later on.

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

[NewsArchive]

Hi Jane

This is not an SB issue. No problem there. It is a conceptual issue
and a windows behavior issue.

First prize I want administrator to install and the run to be written to
current user and whoever the current user is gets to run the app. That
seems to be impossible now. Current user seems to include the user who
has installed so only they get to the automatic run when logged on. I
understand the logic as it is the only way you can exclude public
access. The OS needs to know who owns it and that could only occur at
the level of who installed it I guess.

If I write to the local machine then I guess anyone who logs on gets the
program automatically starting. If that is the case then the security
goes out of the window. But I can live with that - the end user just
needs to know that thr risk is there. I will give the HKLM entry a shot.

Cheers
Andre

[NewsArchive]

Hi Charles

The install does not need to be made by non-Admin accounts. I can see
now that whoever installs if writing to current user will be the current
user who gets to see the app on startup. So I am pretty snookered.

The only solution would appear to be your one - write to the registry on
first startup. It makes sense.

Not a Clarion app this but sure can be done with any language. Will
investigate.

Cheers
Andre

[NewsArchive]

Hi Jane

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

While Charles' solution will work in theory, only domain admin rights
can install so probably not going to cut it. It does make sense though.

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

From the get go I want admin to install the app and current user to see
the app launch. From what I understand now it is not going to happen.
Seems like your solution is the only one that will work in this
situation - write to HKLM and it launches for all users.

Cheers
Andre

[NewsArchive]

Hi Arnor

Thanks - I am going to try this. I do worry about the data path though.
It is currently under users etc. I am sure that should not be a problem
though.

Cheers
Andre

[NewsArchive]

Hi Arnor

They would never let users install anything on this or any other
corporate network. The domain admin will install.

My test is going to be as follows:

1. Install with domain admin rights.

2. Confirm that the app works when starting it from the desktop [your
code would be writing to this admin current users].

3. Log into the machine as normal user and run the app to see that it
launches and works as expected [using code to write to this new current
user]. I expect it will not launch automatically as the registry would
not have been written to yet as this current user.

4. Shut down the machine and cold reboot. Log in as the normal user
and see if the app launches.

If that works we are in business for all machines and scenarios. The
typical situation for 99.999999999% of user owned machines out there is
that they are local admin and can install on their own machines so will
never need to know about any of this. It is just the corporate networks
where domain admin will need to install.

Writing on startup is pretty sneaky. Thanks a ton.

Cheers
Andre

[NewsArchive]

Hi Andre,

> Thanks - I am going to try this. I do worry about the data path though.
> It is currently under users etc. I am sure that should not be a problem
> though.

If you use a CSIDL under the user profile, then you should be good. If
you need something to help with that, check out my old SpecialFolder
program:

https://www.icetips.com/downloadfile.php?FileID=71

It shows you all the CSIDL places and values and whatever so it's easy
to pick the right code :)

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

[NewsArchive]

Hi Andre,

> They would never let users install anything on this or any other
> corporate network. The domain admin will install.

OK! Just got worried ;)

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

[NewsArchive]

Thanks.

Andre Labuschagne