Recently, I once again came across the problem of having to run my Windows app on startup and wondered which of the options is the most usual one and causing least trouble long term.
Registry
Add string value of the path to your exe to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run or \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run for x86 applications running on a x64 Windows.
Feels the most natural
Fairly easy, especially when using frameworks simplifying registry entry creation
When uninstalling an application, you could end up with a dead registry entry
User won't be able to edit this entry
Autostart
Create a .lnk inside the user or system wide autostart folder (shell:startup).
Able to do it programmatically
Very easy to create, add arguments and modify
User is able to edit entries in his usual environment
Task scheduler
Create a 'When the computer starts' or 'When I log on' run entry in the Task Scheduler.
Able to do it programmatically
There is a GUI, but I would assume the average user won't find it
So what are further considerations when selecting an option?
Registry is always being used by production software, since that's the most controlled way and Windows suggests it.
Pros:
No need to enter the users personal space (powershell:startup)
Option to autostart the software only once (windows cleans up the registry)
Decide if the software should autostart for the whole local machine or the current user
Can be executed even when the machine is started in safe mode by using RunOnce with an exclamation point (!)
Here you can read more information about using Run and RunOnce Registry Keys.
shell:startup(not recommended) is the personal startup folder of the user, where shortcuts are being stored, that have been created & copied over by the user. The user will also experience an error prompt, if the application has been deleted, but the shortcut still remains. [BAD USER EXPERIENCE]
Task Sheduler is great for scripting, conditional event triggering and mostly used by Administrators. This option would be overkill, since Registry is much simpler and doesn't leave a Task Event, that the user has to disable on his own.
There is a GUI, but I would assume the average user won't find it
Task Manager [Startup tab] will display applications that will be automatically executed by Windows (registry & startup), which allows the user to enable/disable the software from doing that, so that's not an issue.
TLDR: Registry is by far the most used and best option to automatically run software.
The registry and start-menu are pretty similar. The registry gives you zero control over the execution, the only setting is the command line arguments. The start-menu uses shortcuts so that gives you the ability to control the working directory and initial window state.
The task scheduler is not the traditional way to launch startup applications. It feels like overkill and that you are trying to be obscure on purpose.
Related
I am developing a program for Windows which consists of two components:
A kernel driver (signed with an EV certificate)
A user-level GUI component, the .exe file (written in Delphi).
The .exe requires to be run elevated, in order to start the driver and perform other elevated tasks.
How can such a program be automatically run on Windows startup without displaying UAC prompt?
I saw that many similar applications, such as Anti-Malware programs, are able to startup elevated, without UAC prompt.
I am considering the following options, and would be grateful if you can point to the right direction:
1. Set driver startup as automatic, launch .exe from kernel service
However, my research indicates that there is no documented way to start a user-level process from the kernel.
2. Create a separate user-level service which will start the .exe
I read that user-level services are exempt from UAC.
A possible approach would be to create an automatic startup user-level service, which just runs the .exe process (using CreateProcessAsUser()) and then terminates itself.
3. Convert the .exe program from a Delphi GUI application to a user-level service
Similar to option 2, but instead of creating a separate .exe for the service, we are converting the current GUI application to work also as a service.
I found some documentation about this on this StackOverflow thread.
However, this approach seems more complicated then creating a separate dedicated service.
4. Does an EV certificate provide some advantage to allow this task?
5. Is there any better way other then the above mentioned ones?
As it was pointed out by Sertac Akyuz in his comment you should use windows Task Schedluer for this.
With Task Scheduler you can create a task that will run at user logon and run your EXE with highest privileges available.
And when I say highest privilege available I mean the highest privilege of current user when you specify a group of users in When running the task, use the following user account field provided that current user is a member of that group. So if current user does not have sufficient right to execute programs with elevated privileges the task will execute your application with standard privileges.
But as field name suggest you can also specify that this task will always run your application using a specific user account meaning that it will use that account privilege levels instead of of the current user account.
Any way using task scheduler to execute GUI application that comes with some drivers is quite popular. For instance ASUS uses such approach to launch their AI Suite program that allows monitoring and tweaking various settings of their motherboards. Here is how such task is configured on my computer.
PS: I have purposely chose to show you task properties for ASUS AI Suite as it is actually made with Delphi
Let's say app.exe has been built with requireAdministrator manifest as detailed here (this is really needed for a reason that would be out of topic here). When launching the app, when Windows UAC is enabled, there is a normal prompt:
Now this application needs to run on Windows startup: in an Options dialog, there is a "Launch at Windows startup" checkbox that can be checked or not. When checked, it adds a key in the registry in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
to enable this "launch on Windows startup feature".
Problem: At Windows startup, when app.exe is (automatically) launched in background, there is this UAC dialog box (see screenshot before), which is annoying for the user.
Question: How to make that app.exe can be launched 1. with requireAdminstrator 2. silently at Windows startup ?
What is the clean way to do this? Lots of software do this (indexing software that both run on background since Windows startup, and don't show such a dialog box).
Note: I would like to avoid TaskScheduler method if possible: https://www.sevenforums.com/tutorials/11949-elevated-program-shortcut-without-uac-prompt-create.html
The indexing software "Everything" does show such a dlalog.
The others you are thinking of run only services with admin rights, not UI.
Running a service requires the software to be architected with that intent, ordinary user applications can be started with the service rules with the help of the "at" service, which you already know how to do (Task Scheduler).
You can substitute some other service for Task Scheduler, at the risk of annoying the user through needless duplication, waste of resources, and likely new security flaws.
Set aside your preference, and use Task Scheduler.
Or remove the background parts of your app and write a service to do those instead.
And be very careful when giving your code administrator rights. Any bug can result in subverting the entire security infrastructure. With great power comes great responsibility.
Like some cyber coffee applications that disables the user ability to use any other application but only the ones started inside that cyber admin application panel, I searched the Internet for some way of doing it in Delphi:
Remove the Windows Task bar;
Disable the Alt+Tab function;
Disable the Task Manager;
Be able to do/undo that changes in a configuration panel.
These needs are for keeping users from downloading viruses and making changes to Windows configuration or even play games, if it is the system administrator's preference. The own program would serve as a container for authorized applications to run inside then as if it were a MDI application. That is already working
Of course that the system manager will have the options to disable that or revert.
Is there a way to make those four configurations in run-time with Delphi XE3?
I'm not familiar with Delphi. I'm also not sure if it is possible during run-time. But you could do the following:
Write to the registry to prevent alt-tab see this.
Again write to the registry to disable Task Manager see this.
Sounds like you can disable the task bar too by the registry see this.
On your control panel have options and when they hit save, save and restart the computer.
This is provided that Delphi can write to the registry (I believe C# and C++ can). If not, you could create .reg files and execute those by calling cmd.exe with arguments. This I think will cause some pop-ups though.
Update: You may be able to load in the registry changes without a signing out by killing explorer.exe and then loading it again. This may only load parts of the updated registry though.
I'd suggest booting your hardware into Linux, and then run a Windows virtual machine that is as locked down as possible using the existing kiosk mode security settings in Windows. This VM then runs your MDI application when the VM boots. When the MDI application exists the VM reverts to a snapshot of the known good Windows configuration.
You strip down a Linux OS to include only the bare minimum components needed to host your Windows VM.
I'm assuming your MDI windows will only host applications your organization has written, not arbitrary Windows executables. Otherwise you are asking to re-write Windows itself, which will prove impossible.
I have an application that is installed per-machine (since it uses a service). One part of the application is a system tray application that allows the logged-in user to monitor the service operations. I'm trying to figure out how to best install this monitor application.
Each individual user should be allowed to configure whether or not he/she wants to run the monitor application at login. This means that the HKLM/Software/Microsoft/Windows/Run key is out - this only allows configuration for all users.
There is of course the corresponding HKCU-key, however if one simply installs to this key, it will only be for the user that installs the application.
The SO question Launch app on startup for all users, but also allow per-user setting (Windows) refers to the technique of simply having a user-configurable regkey or similar that is checked by the startup-application on to determine whether or not to run. But this means that the application has to start in order to check the value and I would prefer not to bloat the user's startup if I can avoid it. The benefit of this approach is that it is possible to remove the regkey on uninstall.
Another way to accomplish the installation part may be to use Active Setup to create the HKCU regkey on login, this is however undocumented and it seems to me that there is no easy way to uninstall the regkey if the application is uninstalled? I would assume that leaving registry values under the Run key for HKCU might create problems for users after uninstallation.
Is there a standard way to handle per-user startup applications using Windows Installer? Especially with regard to how to uninstall these later on?
Looks to me like you're close to answering your own question. I think you may just need to divide up the responsibility of configures whether to auto-run for each user... er, let me explain:
You can use either a self-healing component of HKCU Registry keys or ActiveSetup to ensure that every user gets the configuration.
If you use an HKCU Registry key, your MSI installer needs to have a component with it's "key file" as an HKCU entry--so thus the first time a new user launches the program, Windows Installer will do a self-heal to write those entries. One of those entries would be your HKCU/Software/Microsoft/Windows/Run value, but not the key value, because you want the users to be able to remove it and not have it come back every time they run the program! You would then want your program to have an option to remove the auto-run value.
If you use ActiveSetup (which I would recommend because it's simple and it "just works"), then you might find it easiest to make a simple app (or VBScript or such) which prompts the user if they want to have the monitor program auto-run. So your ActiveSetup would launch the prompt program/script, and the prompt program would create the HKCU/Software/Microsoft/Windows/Run value or, better yet, just a shortcut in the user's Start Menu\Programs\Startup directory.
A bit lowtech possibly, but can't you just add a shortcut to the user's startup folder (Start menu/Programs/Startup)?
I guess you would use the HKLM/Software/Microsoft/Windows/Run in this case. The feature to run the monitor application at startup or not really belongs to the monitor application and not the installer. At log-on the monitor application can detect if this is the first time that the monitor application has been run and present the user with an option to always run the monitor application on start up or not.
This is a Windows 2003 (or later) machine that gets switched on every morning, but no one logs on until some hours later.
I want to use the time in between to run a backup script c:\script\backup.cmd
How can I start this unattended after the machine has come up?
I tried 2 registry keys, but this resulted in the script being run after a user logs on (which is too late):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
In the end I used Windows TaskScheduler, who has such an option, but I was wondering if there is another possibility?
Short answer: GPEDIT.MSC (Start, Run, GPEdit.msc)
Windows 2000 and above [1] offer a computer Startup Scripts collection in the policy editor:
Computer Settings -> Windows Settings -> Scripts (Startup/Shutdown)
There's an equivalent logon script area (i.e. after computer startup, when a user logs on) in the User configuration bit.
Longer:
GPEDIT.MSC is the Group Policy editing console, and runs against the local computer's Local Group Policy store when it's used directly, so it's useful for setting local-only parameters. When using Active Directory, a similar interface is used to edit AD Forest-hosted group policy objects (GPOs), so the same settings are available across a bunch of machines.
The computer startup scripts run in the computer context, i.e. as LocalSystem, as you noted, so they often can't access network drives which require a certain user or group membership to work. When domain-member computers access network resources, they generally (with exceptions) authenticate using their MACHINENAME$ account - which lets you set Share/NTFS permissions to allow a computer to access those resources.
A startup script is a quick and easy way of getting a process running when the machine boots.
The computer startup process will be affected by the time it takes to run the program, though, so you might want to ensure you call it with the START command from a batch file, or specifying not to wait for the executable to complete in whatever script language you use. (the key point there is: run the script asynchronously unless it's critical, or doesn't need to be run asynchronously cos it will always take no time at all. Long boots = unhappy users).
Using a Win32 Service is an alternative option - you can use the SRVANY utility from the Resource Kit to "service-ify" pretty much any executable. VS.Net 2002 and later also let you build a managed service directly.
And Task Scheduler gets much more capable as of Vista/2008, able to run scripts at startup, on idle, and/or when Event Logs are generated or certain other conditions are met: it's pretty cool! Scheduled Tasks has the possible advantage of being able to specify the user account under which the task runs, if that's important to you.
Caveat Scriptor:
http://support.microsoft.com/kb/256320
Run Startup Scripts Asynchronously:
http://msdn.microsoft.com/en-us/library/ms811602.aspx
Vista Task Scheduler (what's new):
http://technet.microsoft.com/en-us/appcompat/aa906020.aspx
[1] Windows XP, 2003, Vista/2008, Windows 7/2008R2, Windows 8/2012, Windows 8.1/2012R2, Windows 10/Windows Server 2016. Everything. But NT4 didn't!
You have already outlined a good solution:
Setup a scheduled task to run at Start Up and allow the job to run when the user isn't logged on.
You can run a script at system startup using group policy gpedit.msc
The way you aleady do this seems fine to me; however if you want an alternative approach then services get started when the machine boots so you could write a service that detects if it's a new day (to allow for reboots) and if it is then run your backup.
If I was doing this as a service I'd use TCL because I know it and like it and it has an extension twapi that allows you to run a script as a service. Other scripting languages may well have similar facilities.
There is, if you're using Active Directory. If you can isolate the computer to its own OU or use WMI filtering, you could assign a GPO which has a startup script for the computer. This would ensure that even if someone went in via safe mode and disabled the Task Scheduler, upon startup and connection to the domain, the script would run.