windows scheduling of a power-shell script is unreliable - windows

I'm attempting to run an automated powershell script all day, everyday. But I'm have problems getting it to run consistently and reliably, the script itself runs fine, it's getting the windows scheduler to run it consistently that's the problem.
The script is invoked every morning by windows scheduler at 1am as powershell.exe with the command arguments:
-windowstyle Normal -NoExit -file "d:\work\PwrShellScripts\FlmToDb_010.ps1"
Once invoked, the script will run continuously until 11pm at night when it will exit.
The script itself works reliably, but the scheduling only works nine times out of ten, once in a while it fails with the error:
Task Scheduler did not launch task "\DailyFlm" because instance "{aa18e048-d8b2-4e16-8737-fc7babbb609e}" of the same task is already running.
The question is, how to get the script to run reliably every day?
Other info that may be relevant…....
The arguments -windowstyle Normal -NoExit mean that the powershell script runs in a command window (rather than as background process) and the window will remain open if the session ends.
This is done for two reasons, firstly it provides a visual indication that the process is actually running, and secondly if the process fails, it allows the error message to be inspected. The powershell script doesn’t include any file logging, so running it in a command prompt also allows me to confirm that the previous days session made a clean exit when it stopped.
One of the issues is that because the process works 90% of the time, if I make any tweaks I have to wait 10 days or more to confirm if they’ve really worked!
I suspect that the issue may be related to the fact that the console remains open (-NoExit) when the script exits. Most of the time windows seems to recognise that although the console is still open, the associated script has exited.
My guess is that occasionally it decides that since the console is open the process is still running. I'm unable to spot any difference between those occasions when the scheduling works fine and those when it doesn't.
Any suggestions?
Updates...
The scheduler fails to start the job on average once every 10 days. I would prefer to keep the script running in the foreground, it makes monitoring it's progress so much easier, and makes it so obvious if it does fail.

the same task is already running.
The script may do what it's supposed while it runs, but there is one flaw... it's not closing properly. It's exactly the -NoExit issue you talk about. When you run a powershell task, the process name is powershell.exe, with it's associated process id, and that's how the task scheduler knows if it's finished or not.
To fix this, I suggest writing a script to kill all powershell.exe processes and scheduling it to run right at 12:55am every day.

Related

Schedule script on windows so that it should always be running in background when someone logins

I am a beginner at developing Windows apps. I have created a VB script that executes the EXE file in background. I have referred some articles online and scheduled the script with windows scheduler. Now Every time I log in to the computer, the script starts running in the background normally as expected. The problem occurs when I lock the computer for a long period of time, somehow script gets killed by Windows. If I try to log in again, script(which got killed) doesn't start once again.
I want the script to run every time the computer gets unlocked no matter whether the computer was restarted/power-on/woke up from sleep and it should start running the script. But I am unable to achieve this.
This is what my current trigger looks like . Please tell me if I am doing something wrong

Windows Task Scheduler wont start task because it thinks previous version is still running

I have an occasional problem (maybe twice a month) were windows task scheduler won't start a new task because it thinks the old version is still running.
The task is a powershell script, it runs all day, every day. The task scheduler starts the script at 5 past midnight every day (UTC), and then the scripts exits itself everyday at 23:55 (UTC). The script does the following actions.
logs its own startup in a database
spends all day reading records from a remote server.
logs its own shutdown at 23:55 every night and exits with 'exit 0'
Task scheduler runs the script with the -NoExit option, so the powershell console remains open on the screen even after the task has exited (allowing a visual check of any output generated)
This all works fine 95% of the time, however, occasionally when the task scheduler attempts to start the new task at 00:05 I see the message 'Launch request ignored, instance already running' in the history. But when I check the log records from the powershell script I see that it started and finished at it's normal time, and I can double check this against the console.
Curiously, on these occasions the task scheduler history indicates that the blocking task finished at about 8am - a time which always corresponds to when I logged on that day.
Any suggestions on what's going wrong and how to sure it? I've already tried tweaking some of the task settings "if the task is already running then the following rule applies - stop the existing instance" but because the fault is intermittent, it's very hard to pin down.
Update - following further testing.
I've tried creating 100s of similar tasks and running them with similar conditions. So far I've reached two conclusions, firstly everything seems to work OK if I remove the -NoExit option. It's almost as if the scheduler has trouble differentiating between the command window, and the PowerShell script itself.
Secondly, everything seems to work ok if increase the gap between the previous schedule dying and the new one starting from about 15 minutes to half an hour or longer. It's as if the task scheduler takes time to work out that the old task has stopped.

Powershell script pauses when executing it as background process

I am working with a log analytics tool called Splunk, which executes a Powershell script and stores the output.
The script execution takes pretty long time and the output is around 100MB+ when the script completes the execution.
When I check the log of the script, I found out that the execution was paused and continued after around an hour!
After looking at the question about QuickEdit mode of the Powershell console metioned here, There are 2 possible reasons why this can happen:
If the QuickEdit mode of the Powershell console is On, and if there are any selected words or area in terminal. But, this is not the case, as the Powershell is invoked as a background process
If the stdout throughput is too much than the host console can handle. Possible reason as the output of the script is very large as mentioned.
Note: there is no sleep or stdin expected in the powershell script as it is meant for collecting performance metrics.
What is the exact reason of the hang of the process in this case, (from 2 mentioned about or any other) and how can I prevent it?

Powershell: how to pause or delay or block shutdown to give time for cleanup tasks?

I have a powershell script that is running all the time on windows 7. If user does computer shutdown or reboot, I need a little time to do cleanup tasks such as updating log file.
Is there a way to delay shutdown from within script?
Solutions I've found from searching don't work well:
*Listening for events such as SessionEnding are too late and powershell is closed before script has time to do anything
*I'm looking for a solution within the script that runs at startup instead of separate solution such as adding a 2nd script to group policy that runs on shutdown
I've looked at WM_QUERYENDSESSION but I can't get it to work for powershell script.
Add the script on GPE on your local computer, So the script will run while shutdown.

Windows Task Scheduler will run app only once

So my situation is that I am running an app on the Windows Task Scheduler. This app is run once a day at 1pm. the app does some queries and transfers data to an FTP site. All that is working great except on the weekends when i am not here the app is run and the GUI is still displayed for me to review. This seems to make it stop running on the scheduler until I shut down the app. So on Saturday it will run and the app will remain displayed for me to review when I get back on Monday. but on Sunday when the scheduler attempts to run it again it will fail because the app has not been closed down.
First let me confirm that this is how the Task Scheduler is supposed to work. Second, what are my alternatives for scheduling to run every day and keep the GUI displayed so that I can review. The app can run multiple times as each session does not interfere with the other sessions. So if I'm gone for a week on vacation I would expect that when i get back that 7 instances of the app have been run and are waiting for my review.
Thanks
AGP
Your best bet is to eliminate the UI and log messages to the Event Log or a log file. The UI could be spawned from the CLI as a separate process if you prefer, but it should be done so in as its own non-child process.
Alternatively, you could run a batch file instead of the process directly. In the batch file, invoke "START path_to_exe" instead of the EXE. That will cause the batch file to "finish" instantly, and the exe to be run in its own process. This is not a good long term solution, but will give you a temporary solution to your immediate problem.
This is the default behavior of the Scheduled Task system, as it doesn't know that the job is complete until the application actually exits. Therefore, if your application is still open after 24 hours, the next run will simply be skipped because the current run is "still going" as far as the scheduler is concerned.
Personally I would re-visit the way that you handle your job process, as your are setting up a scenario that will be hard to manage long term.
I recommend writing to a log file instead of displaying a UI for any output and/or errors. This way, the application can write, then exit, and you can review the log at your convenience. This is a very common solution for automated processes.

Resources