Basically i have scheduled a task in windows task scheduler.
In the task i have scheduled a powershell script
in the program/script path we have given powershell path and in the argument path we have given
-command "& C:\Users\xxxx\Desktop\1.PS1"
I was checking if the task fails or not on powershell script failure.
so the powershell script is getting failed but the last run status says
"The operation completed successfully"
How to configure my task such that it will return fail if powershell script does not run successfully?
edit
I have 3 tasks(all 3 are powershell scripts having parameters)
basically i have created a custom trigger for task 2 and task 3
i.e if task1 is success then the task 2 will be triggered and if task 2 is success then task3 will be triggered.
while testing the above scenario, evenif the powershell script used in task 2 returns error(intentionally done error in code to check the scenario), the last run status says the operation completed successfully and the task 3 task getting triggered
Instead of the current situation, why do you not have 3 Scheduled Tasks.
The first runs the first script, and if the script itself deems itself successful, runs the 2nd Scheduled Task itself?
For example, using Start-ScheduledTask (https://technet.microsoft.com/en-us/library/jj649818(v=wps.630).aspx).
This way, each of your scripts could check themselves for issues, and if none are found, can call the next task. This has the additional bonus of letting you have full control over which scheduled task to run, and when.
Based on the comments in this thread and my own testing, it sounds like it's not possible to get the scheduled task to log itself as failed by the failure of the script because the purpose of the task is to kick off the program, which it does successfully.
However, it is possible to return an exit code to the scheduled task. The exit code will be logged in the event history (Information Level). As stated in this thread, the return code must be referenced in the parameters with which the scheduled task calls the script:
-ExecutionPolicy Bypass –NoProfile –Command "& {C:\ProgramData\ORGNAME\scripts\SetDNS.ps1; exit $LastExitCode}"
Related
I need help understanding why the scheduled task is not working, even though the last successful Run Time says,
The operation completed successfully.
The result is that it's not copied to the destination folder, but if I run the .ps1 script manually, it completes successfully.
1
2
FIG 3
**
Add-ExecutionPolicy Bypass C:\auto_p\applied.ps1
4
5
6
I have a situation where I want to make the execution of my scripts smarter. I have a set of scripts that execute at a given time, but because sometimes the input files are not posted at the correct times the scripts run into errors and get unexpected results. so one of the solutions I was thinking of is to make the execution of the scripts dependent of each other. Here is what I mean:
script 1 runs at 6 pm
validates that the file is there
if it's there, set a flag
the flag is active so execute script 2 at 9 pm
if it's NOT there, the flag is not set
the flag is not set so script 2 is not executed
Right now script 1 and script 2 are set with the Task Scheduler at those times, I checked the Scheduler for those type of conditions, but didn't find anything.
You can set triggers in Task Scheduler, like when an event happens for basically everything you can see in eventviewer.
I would suggest Write-Eventlog from the script which works on the file, and depending on the result the sched task would get triggerd.
I suggest you to have single script running every N-minutes on single scheduled task via Task Scheduler.
The master script will analyze activities and have all logical conditions those determine when and which external script to run. You can also have flag files.
I have a PowerShell task in my definition that calls another script file on its own which takes care of running several things on my build agent (starts several different processes) - emulators, node.js applications, etc.
Everything is fine up until the moment this step is done and the run continues. All of the above mentioned stuff gets closed with most of the underlying processes killed, thus, any further execution (e.g. tests run) is doomed to fail.
My assumption is that these processes are somehow dependent on the outermost (temporary) script that VSTS generates to process the step.
I tried with the -NoExit switch specified in the arguments list of my script, but to no avail. I've also read somewhere a suggestion to set this by default with a registry key for powershell.exe - still nothing.
The very same workflow was okay in Jenkins. How can I fix this?
These are the tasks I have:
The last PowerShell task calls a specified PowerShell file which calls several others on its own. They ensure some local dependencies and processes needed to start executing the tests, e.g. a running Node.js application (started in a separate console for example and running fine).
When the task is done and it is successful, the last one with the tests would fail because the Node.js application has been shut down as well as anything else that was started within the previous step. It just stops everything. That's why I'm currently running the tests within the same task itself until I find out how to overcome this behavior.
I am not sure how you call the dependencies and applications in your PowerShell script. But I tried with the following command in PowerShell script task to run a Node.js application:
invoke-expression 'cmd /c start powershell -Command {node main.js}'
The application keeps running after the PowerShell script task is passed and finished which should meet your requirement. Refer to this question for details: PowerShell launch script in new instance.
But you need to remember to close the process after the test is finished.
There is the Continue on error option (Control Options section). The build process will be continued if it is true (checked), but the build result will be partially succeeded.
You also can output the error or warning by using PowerShell or VSTS task commands (uncheck Fail on Standard Error option in the Advanced section) and terminate the current PowerShell process by using the exit keyword, for example:
Write-Warning “warning”
Write-Error “error”
Write-Host " ##vso[task.logissue type=warning;]this is the warning"
Write-Host " ##vso[task.logissue type=error;sourcepath=consoleapp/main.cs;linenumber=1;columnnumber=1;code=100;]this is an error "
More information about the VSTS task command, you can refer to: Logging Commands
When putting together a release definition in VSO, adding an Azure PowerShell
task
backed by a file Script1.ps only containing exit 1 does not fail the step when it runs - which I would expect it to do, given that the Continue on error box is not checked
If I add the PowerShell task, writing exit 1 using the inline variant would indeed fail the step. This also comes with an 'advanced configuration option' where the Fail on Standard Error is checked by default.
What did I miss? How would I go about making the Azure Powershell fail in the same manner?
Using this code instead:
[Environment]::Exit(1)
The task will fail if the script throws an exception or writes to stderr stream.
I'm trying to run a PowerShell script every minute using Task Scheduler. The script basically fires off an HTTP GET request and I want to have the task show the "Run Result" as an error if the request is not successful.
Right now, no matter what happens in my script, the Task Scheduler is showing the last "Run Result" as "Success", and I'm not sure what I should be doing to make it work properly. In my script, I am using Exit 1 if the request does not return a 200/OK, and Exit 0 otherwise.
My Task action is set up as follows:
Action: Start a program
Program/script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Add arguments: -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command "C:\MyScript.ps1; Exit $LASTEXITCODE"
Start in: C:\
You are running everything correctly, and have everything set up correctly.
To answer your question, the "Task Scheduler Library" view, "Last Run Result" is the correct result, and the correct View to see if things ran successfully or not.
The "Task Status" section of the "Task Scheduler (Local)" view is just purely telling you whether or not the Task ran or not. It does not return the results of the Task Actions. So it will only show an error if something caused it to miss it's scheduled running (for ex. going on battery power), and not if the Task Action failed.
Personally I always use the "Task Scheduler Library" view, "Last Run Result" as the only way to see whether or not things failed or not.
You can use EXIT %ERRORLEVEL% in cmd file to "bubble up" any non-zero return code from PowerShell to the Last Run Result column in Task Scheduler
as described in
http://www.technologytoolbox.com/blog/jjameson/archive/2011/11/19/tips-tricks-for-running-powershell-scripts-as-scheduled-tasks.aspx