I have seen references online that state that 'Scheduled Tasks' in Windows are stored in %SystemRoot%\Tasks, which I think usually equates to C:\Windows\Tasks.
However, I observe that while that folder exists on my Windows 7 system, Scheduled tasks doesn't use it.
My system appears to use, C:\Windows\System32\Tasks.
I have studied the Environment variables and there doesn't seem to be anything related to Scheduled Tasks there.
How do I discover which folder is used for Scheduled tasks?
Tasks are saved in filesystem AND registry
Tasks are stored in 3 locations: 1 file system location and 2 registry locations.
File system:
C:\Windows\System32\Tasks
Registry:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tasks
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tree
So, you need to delete a corrupted task in these 3 locations.
I want to extend #Jan answer:
It's seems, that Task Scheduler 1.0 API uses C:\Windows\Tasks folder for create and enumerate tasks (this example), while Task Scheduler 2.0 API uses C:\Windows\System32\Tasks to create and enumerate tasks (this example).
It's also seems, that windows console utility schtasks and GUI utility taskschd.msc uses Task Scheduler 2.0 API.
P.S.
I found, that if task placed in C:\Windows\Tasks and have not set AccountInformation, then task won't be displayed in windows console and GUI schedulers. If you set AccountInformation (even "" for SYSTEM account) and set flag TASK_FLAG_RUN_ONLY_IF_LOGGED_ON - task will be displayed in all standard applications.
Solution found here
For Windows 7 and up, scheduled tasks are not run by cmd.exe, but rather by MMC (Microsoft Management Console). %SystemRoot%\Tasks should work on any other Windows version though.
There are multiple issues with the MMC however as on almost every PC in my business the ask scheduler API will not open and has somehow been corrupted. So you cannot edit, delete or otherwise modify tasks that were developed before the API decided not to run anymore. The only way we have found to fix that issue is to totally wipe away a persons profile under the C:\Users\ area and force the system to recreate the log in once the person logs back in. This seems to fix the API issue and it works again, however the tasks are often not visible anymore to that user since the tasks developed are specific to the user and not the machine in Windows 7. The other odd thing is that sometimes, although not with any frequency that can be analyzed, the tasks still run even though the API is corrupted and will not open. The cause of this issue is apparently not known but there are many "fixes" described on various websites, but the user profile deletion and adding anew seems to work every time for at least a little while. The tasks are saved as XML now in WIN 7, so if you do find them in the system32/tasks folder you can delete them, or copy them to a new drive and then import them back into task scheduler. We went with the system scheduler software from Splinterware though since we had the same corruption issue multiple times even with the fix that does not seem to be permanent.
Looks like TaskCache registry data is in ...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache
... on my Windows 10 PC (i.e. add Schedule before TaskCache and TaskCache has an upper case C).
On newer versions of Windows (Windows 10 and Windows Server 2016) the tasks you create are located in C:\Windows\Tasks. They will have the extension .job
For example if you create the task "DoWork" it will create the task in
C:\Windows\Tasks\DoWork.job
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.
Let's say I have
c:\prod\foo.txt
and
c:\work\foo.txt
I would like to get c:\prod\foo.txt automatically and immediately updated from the other file, whenever I change & save c:\work\foo.txt
How can this be accomplished? Installing tools is okay. Windows 7 and up.
Symbolic linking is not a solution for me, as the c:\work is deleted every now and then.
Have you looked at SyncToy?
A: Run SyncToy silently addresses this issue.
SyncToy can be used in conjunction with the Windows Scheduler to automate sync operations.
I'm working on a project where the goal is to be able to update a windows computer 100%. That means a program or a script that updates windows automatically with no user interaction at all. Ideally a standalone script that can be run from another script.
The reason: I need to update a lot of computers in my line of work. They can be at any patch level and everything from Windows XP to Windows 8. My goal is to start a script, wait/do something else and then find a fully patched computer.
I've solved a lot by finding ZTIWindowsUpdate.wsf in the MDT Task Sequence.
This can be used like this from an admin cmd:
cssript.exe ZTIWindowsUpdate.wsf
My problem so far is that the computer requires a reboot between some of the updates. Probably because of dependencies. ZTIWindowsUpdate.wsf needs to be run as administrator and i can't seem to find a solution to start it as administrator at reboot. Additionally if I get the script to run on startup, how do I stop it, and how do I know when its time to stop it?
Can someone help med with a foolproof solution to this problem?
Thanks!
Don't need to FULL update a Windows OS, most of the updates are not needed, most updates are not relationated with security and we can survive without they, you need to read the description of each update to understand what changes made. FULLY updating a Windows can be negative point of performance in several scenarios.
All that you need is to download your desired updates, then store it in a folder with this batch script:
#Echo off
For %%# in (*.msu) Do (
Echo: Installing update: %%#
Wusa "%%#" /quiet /norestart
)
Echo Windows Update finished.
Pause&Exit
Also you can compress the folder (the updates + the script) into a Self executable with winrar to distribute it as a standalone file.
Info:
Wusa.exe is the Windows Update commandline application.
The files are processed one by one, not all at once.
The quiet switch makes the installation silent.
The norestart switch don't restart after installing the update even if needed.
If a update is installed in the OS then is not installed again, without getting an error window or stopping the execution of the script.
PS: See Wusa /? for more switches.
I hope this helps.
UPDATE:
Another alternative is to download and install ALL the updates with WSUS utility.
http://download.wsusoffline.net/
The updates for Win7 x64 (for example) are stored here: "...\wsusoffline\client\w61-x64\glb"
PS: The "DoUpdate.cmd" batch file in the "CMD" dir of the application is what you need if need to automate the task in "background".
The simplest solution to the problem you're describing is to get your script to configure automatic logon for the built-in Administrator account, then add itself to the Startup folder. You do need to know (or reset) the Administrator account password to use this option.
There are many other possibilities, some examples are: use a startup script and psexec; use srvany to create a service that runs your script; use task scheduler to schedule your script to run automatically, either interactively or non-interactively; disable WUA, configure automatic logon for the account you're using, and add your script to the Startup folder.
Note that you'll save time and bandwidth if you can set up a WSUS server or (even simpler, and cheaper if you don't already have a Windows server) a transparent caching proxy. However this won't avoid the need to reboot during the update sequence.
You may find my script useful as an alternative starting point to ZTIWindowsUpdate.wsf, if only because it is smaller and simpler to understand.
The moast time consuming thing of a WindowsUpadate procedere is the download of the Setupfiles for the Updates. You should look into a lokaly in the network installed WUS (Window Update Server) and make sure the PC updates from the WUS. If the PCs are all in a ActiveDirectory Domain then the needed settings are very easy to manage. But if not this setting could make a simple batch-script which uses the normal windows update routine.
Another solution would be to make batch-scripts where you install the predownloaded updateFiles with the silent-switch. Allmoast every setup.exe has such a silent switch. If a update isn't needed the update stops for this upload automatically. I'm using such a batch-script wizzardy now for quiet a time now.
PS: If the Computer were from one/your compagny you should "thank" your predecessor for many hours of work to the far future.
PPS: By the way XP and Vista should be phased out. They are now realy old and for XP the already extended supporttime is axed by Microsoft next year and should only used if it is realy realy needed for one small situation where a Windows 7 isn't a solution in any way possible.
To run
cssript.exe ZTIWindowsUpdate.wsf
as Administrator after reboots, you can create a Task in the Task Scheduler with the proper permissions and to run on boot. =]
An automated way is, WuInstall. I'm using it for 1 year now and it's perfect, it actually does what it should. It's a command line tool which automatically searches, downloads and installs the updates. There are several "switches" that let you allow to customize the process. Thanks to the rebootcycle-switch for instance, updating a newly setup PC is done with ease - in one go.
Here's another way ------
Perform instructions below at your own risk:
To automate windows update these instructions may or may not work for your system however it appears to work to an extent for Windows 7 as these instructions were tested on Windows 7.
MUST READ: 1. If the step below does not work verify then you are most likely part of a domain and your security policy may not allow you to perform steps below! 2. UAC prompts were also disabled for the duration of the windows updates so the batch files can run without interruption; be careful to restore this to default when done
Caution this step will make your computer less secure, immediately remove this after your computer is completely up to date. Set a reminder for 24 hours later if need be:
1.
First you will have to make sure your computer automatically logs into a user. You can do this by clicking start menu, type "netplwiz", press enter or open the wizard, under the users tab, select your username, and un-check "require password", type your password, close this window.
2.
Create 3 batch files to start the automated process. (Open notepad paste each code into a separate notepad and perform a save as corresponding_file_name.bat)
One. Save as: any_name.bat then copy this batch file to your startup folder for the user you made auto login. (Click start > All Programs > Startup)
start "" c:\autoupdate1.bat
exit
Two. Save as: autoupdate1.bat then copy this to C:\ drive
wuauclt /detectnow
wuauclt /updatenow
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired" > nul && shutdown -r -t 0
start "" c:\autoupdate2.bat
exit
Three. Save as: autoupdate2.bat then copy this to C:\ drive
ping 127.0.0.1 -n 61 > nul
start "" c:\autoupdate1.bat
exit
Restart or open the batch file in the startup folder and watch the magic begin!
3.
When it is completely done updating just delete the batch files from the startup folder & c:\ drive
Once again follow these instructions at your own risk as it can create an endless loop if you do not know how to stop this process by removing it from the startup folder or going into windows under safe-mode to remove the batch files
Final notes: If you run into issues running the batch files chances are you may have to look up how to disable UAC prompts for your Windows version
Before I start, another post for something similar to this request for help is located at Running a process at the Windows 7 Welcome Screen, but the responses were not quite what I believe I am looking for, and the post is over a year old so I thought it best to start a new thread for my needs.
In Windows 7 Ultimate, I am trying to create a script or task scheduler event that will run a Windows "rundll32.exe" process with arguments at the logon, lock, and switch user screens (basically any screen that is waiting for user to log into the machine).
I have tried using the startup script controls in group policy editor as well as creating a task scheduler event, but so far I am unable to get the process to display on the logon screens.
The command line I am using does work while logged into any account at any user level via the "Run.." dialog as well as via CMD prompt, and is only creating a popup that already exists in the Windows OEM Environment.
The hardest part is this: My friend just bought a new laptop. The new laptop came with this specific feature already enabled, but I have no idea what is making it happen and do not have access to the computer to check out gpedit.msc and task scheduler for possible solutions.
There are two reasons why I need this info: 1) I want the feature to work on my own laptop, and 2) my friend would like help disabling it on his as he doesn't like it.
I have been all over Google, posted at Microsoft Answers, and also posted on the laptop manufacturer's user forums. I have found very few pages that refer to the same question as I have, but none have answers that work, and since I have seen and know that this is possible, I am compelled to continue looking.
The laptop that this is currently working on was purchased with a fresh install of Win 7 Ultimate and no manufacturer bloatware/additional software added, so we know that the feature was made to happen by whomever it was that installed the OS and configured it for sale. Therefore I am certain it is just a matter of the right task or script in Windows itself before I see the results I need and then know how to direct my friend to disable his via phone.
The specific call is "rundll32.exe van.dll,RunVAN". In task scheduler I have set this to run as "SYSTEM" and set the triggers for startup, workstation lock, and local disconnect. I have tried using full path to rundll32.exe as well as the bare command. In gpedit startup scripts I have tried full path and bare command. Neither of which for either case is making this popup show on the logon screens.
Any and all help and/or advice on this would be greatly appreciated by both myself and my friend.
dynamic display of images for the credential provider
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.