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.
Related
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.
I'm trying to figure out how to install software when the PC reboots Note that this is on machine startup, not user login. Anyone have any suggestions? Google searches just return how to set programs to start on user login. That's not what I need.
You have a few puzzle pieces to unravel here:
Choosing a mechanism for running on startup prior to user login. For this, the fact that your task is installation of further software doesn't matter. A "service" is the usual way to do this, although for example antivirus software tends to use device drivers.
Automating scheduling your code to run at startup. If you chose a service in the above step, this means using the Service Control Manager API.
Actually doing the work, without having an active user login session. Services run in an environment where there is no UI available, the user registry is associated with a service account and not any real user, etc. Other than that, code runs normally (you can load DLLs, access files and directories, etc). Permissions needed by your installer may also become a problem and cause you to modify the service installation options in step 2.
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
I've a PS script which I use to keep track of my VMWare ESX servers. I need to run it as a service so that I'm not permanently logged on. Unfortunately, the script runs more slowly if I use a runspace inside a service rather than just running the script through the powershell console. It's taking 2-5 minutes to make calls to the VMWare web service instead of a second or so.
Is there some sort of magic I should be using when I invoke the runspace?
You can run the script as a scheduled task.
Without seeing what you're doing, I can't think of many things that would make that big of a difference:
Do you have profile customization that might be helping it out when it runs in PowerShell (test with PowerShell -noprofile)
Are you counting the time it takes to initially import a module or snapin in your service, but not in PowerShell.
Are you re-creating the whole runspace each time in your service?
Have you tried using the 2.0 API of PowerShell with PowerShell.Create() to run it?
Finally, you could also take a look at some of the open source PowerShell hosts like PoshConsole or bgHost on CodePlex ... if they don't run it slowly, then you could follow the process they use for creating their runspace.
Does the service authenticate as a user with the same rights you do? I suspect something is timing out when it runs as the service, which you don't see when you run the script yourself.
The script in question runs equally slowly whether it runs in a service using its
usual service account, or if I run as myself in a very basic console app (create
runspace, add script, execute).
Apart from the usual suspects (account rights, Set-ExecutionPolicy RemoteSigned, and firewall configuration) I can't think of a good reason why PowerShell shouldn't work exactly the same in a Windows Services as it does in a console application, which makes me think it might be something environmental. It's not something silly like poor DNS resolution, is it? Assuming you're running this on a server, does it also perform slowly on your development machine too?
PS: I wonder if this question might be more appropriate for ServerFault?
A colleague has a batch script program which needs to to run on a Windows Server in console mode, so that it has access to a Windows interactive session. The server is rebooted at regular intervals automatically (there's an unrelated closed-source application that runs on this machine that we have no control over). After a reboot he wants to automatically start a Windows interactive session and have this script run, plus the service needs to also have access to network resources (CIFS drives, in particular).
Here's what we've tried so far:
Start as Windows service. This failed, since a Windows service can either have access to interactive session or to network resources, but never both.
Used Microsoft management console to add the script to run at startup, however this did not work.
Used an HKLM registry key to start to run this script, however it only gets started when we manually open a remote desktop session on the server.
Creating a scheduled task. The program invoked did not have access to interactive windows session.
Any other suggestions? (Or maybe he missed something when he set up one of these suggestions?)
In case "Interact with desktop" on the service is not enough (I have seen a handful of cases where it is not), you can combine it with AutoAdminLogon. Create three (or four for a domain) REG_SZ values under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
DefaultUsername
DefaultPassword
DefaultDomain
AutoAdminLogon
AutoAdminLogon should be set to the string "1", the others are self-explanatory.
Obviously this has security issues big enough to fly Jupiter through.
Have you tried having your script run as a Windows service, but allowing it to interact with the desktop?
Specifically:
Go to the service properties page
Click on the "Log On" tab
Select "Local System account"
Check "Allow service to interact with desktop"
See my similar question and real answer to it: How to start a process from windows service into currently logged in user's session
NOTE: "Interact with desktop" checkbox is not enough at all.
I recommend going about this another way. You could build another Windows app that communicates via IPC to the Windows Service and that could be what deals with the closed souorce application. But if you must, you can specify an option in the service (you can do this through MMC, registry, etc). Basically, you can see this option by going to Computer Management->Services and Applications->Services->Right click your service->Change account to Local System and check "Allow system to interact with desktop."
However, again, I recommend choosing another path.
I had to do something similar recently; a route that I found but discarded due to security concerns is to have the interactive service set self as running in interactive mode and then run the ImpersonateUser function in the win32 API, which I think will provide the benefits of both a user and the interactive session available from the LocalSystem.
Needless to say, if someone broke into a service that did that, they would have total control of the machine.