Most people know that they can launch a script by double-clicking it, running a command in a command-shell window, or dragging the script onto the command-shell window. But did you know you can use several other automated techniques to launch scripts? Those techniques include the following:
- Launching the script as a computer-startup script in a Group Policy Object (GPO). A GPO computer-startup script is an excellent way to run a script against each computer in a target organizational unit (OU). The script runs in the background, so users are unaware of it.
- Launching the script as a remotely scheduled task. Before the days of OUs and GPOs, administrators launched many of their scripts remotely. There's still a role for this time-proven technique.
- Launching the script as a locally scheduled task. Task Scheduler lets you configure a variety of script launch options, including launching a script at system startup or user logon.
- Placing the script (or shortcut to it) in a computer's Startup group. This technique is one of the least stealthy.
- Adding a registry entry that points to a local or remote script. The entry goes in the HKEY_CURRENT_USER\Software\Microsoft\Windows\Current Version\Run subkey. This technique isn't recommended because it's difficult to remove the entry and track what PCs have had registry modifications. I included it here for reference purposes only.
Table A provides some more details about these techniques, including their advantages and disadvantages. There's no single right technique for every script. You might even find that you'll want to use more than one technique for a script. For example, if you want to run a script remotely and locally, you might create two versions of that script—one that you launch as a remotely scheduled task and another that you launch as a locally scheduled task. You need to look at the script's requirements and your environment's limitations to make the best choice.
Ruling out techniques is often helpful when trying to determine the best approach. For example, if you have a script that does a lot of processing, you wouldn't want to launch it as a GPO computer-startup script because it would noticeably slow down the logon process for users. If a script is to run on PCs that are offline most of the time, you wouldn't want to launch the script as a remotely scheduled task because the PCs might not get a chance to run the script.
