I wrote a simple PowerShell script to back up a certain folder from a server to an external NAS, which is mapped as the N: drive. $sourcePath = "D:\SomeLocation\Folder" $destinationPath = "N:\BackupData" Copy-Item -Path $sourcePath -Destination $destinationPath -Recurse -Force The credentials for the NAS are stored in Windows Credential Manager The script, if run directly on its own manually by me, is able to perform the backup correctly and I see the files. The script is set to run as an administrator account, with highest privileges, whether logged in or not, and configured for Win Server 2019 However, when I call it with Task Scheduler (even clicking Run manually rather than waiting for the scheduled time), it doesn't seem to do anything. Looking at the history, it says it successfully completes it though, oddly. For the Program/script field I put the path to the PowerShell executable "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe**"** For the Add arguments field, I enter the path to the location of the script itself, for example in my Documents folder. I also later tried adding a -ExecutionPolicy Bypass to the arguments field, to no avail. Adding or removing quotes made no difference, as expected. I didn't think the Start In field was necessary in this case, but I have tried entering the location of the folder containing the script, or even of the folder that needs backing up, but none of it made a difference. As a workaround I also tried creating a .bat file and entering cmd.exe as the Program/script field and the location of the .bat file in the argument field C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -File "C:\Users\Administrator\Documents\BackupData.ps1" 1>C:\Windows\temp\BackupData.log 2>&1 But unfortunately this also didn't work. I also don't see log files for it. Not really sure what's going on. Any help would be appreciated. Thanks.

Powershell works the other way. You have to specify the -NoExit switch to keep it running after executing a command or a .ps1 file. Your main issue is one that we see quite frequently. User writes a script. User runs script just fine in desktop session. User tries to run in task scheduler (or startup) but doesn't get expected results. User does not include any error handling or logging in the code and has no visibility into what the unattended script did. User asks us what is wrong with the task scheduler. The simple solution is to include Out-File cmdlets in the script to write to a log file. If you need more detail, PS's Start-Transcript/Stop-Transcript might provide more info. Write out script start and end times. Put a try/catch around the main code block and write any error to your log file. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_try_catch_finally?view=powershell-5.1 If the log/transcript files aren't being created, then PS itself must be running into some kind of fatal error. You then need to capture stdout and stderr from PowerShell.exe to see the error. That's where the bat file comes into play. For low level debugging use Sysinternal's Process Monitor to trace what Powershell.exe does. https://learn.microsoft.com/en-us/sysinternals/downloads/procmon The task scheduler is perfectly capable of running powershell.exe directly. Once you implement error handling and logging in your script, you should be able to remove the bat file.

Create a folder C:\Logs and grant Everyone full control. Change C:\Windows\temp\BackupData.log to C:\Logs\BackupData.log In the bat file add a first statement that shows the run time. @echo Task is starting %date% %time% In the Powershell script add Test-Path cmdlets for both $sourcePath and $destinationPath When you map a drive, this is only for your logon session. If you are using a different account, you will need to map a drive for that account too. Also the task scheduler just does a user impersonation, not a full logon. You probably don't have an N drive visible to the script. Log on to the desktop with the account that the task runs as. Use credential manager to verify that it sees the saved credentials for the NAS. In that case try using the UNC notation \NASserver\sharename

Try using the UNC name instead of the mapped drive letter ("N:"). IIRC, a mapped drive is associated with a user interface, and a background task doesn't have one.

Having Trouble Running Powershell Scripts with Task Scheduler

Mikros476 45

I wrote a simple PowerShell script to back up a certain folder from a server to an external NAS, which is mapped as the N: drive. $sourcePath = "D:\SomeLocation\Folder" $destinationPath = "N:\BackupData" Copy-Item -Path $sourcePath -Destination $destinationPath -Recurse -Force

The credentials for the NAS are stored in Windows Credential Manager
The script, if run directly on its own manually by me, is able to perform the backup correctly and I see the files.
The script is set to run as an administrator account, with highest privileges, whether logged in or not, and configured for Win Server 2019
However, when I call it with Task Scheduler (even clicking Run manually rather than waiting for the scheduled time), it doesn't seem to do anything. Looking at the history, it says it successfully completes it though, oddly.
For the Program/script field I put the path to the PowerShell executable "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe**"**
For the Add arguments field, I enter the path to the location of the script itself, for example in my Documents folder. I also later tried adding a -ExecutionPolicy Bypass to the arguments field, to no avail. Adding or removing quotes made no difference, as expected.
I didn't think the Start In field was necessary in this case, but I have tried entering the location of the folder containing the script, or even of the folder that needs backing up, but none of it made a difference.
As a workaround I also tried creating a .bat file and entering cmd.exe as the Program/script field and the location of the .bat file in the argument field C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -File "C:\Users\Administrator\Documents\BackupData.ps1" 1>C:\Windows\temp\BackupData.log 2>&1 But unfortunately this also didn't work. I also don't see log files for it. Not really sure what's going on. Any help would be appreciated. Thanks.

Accepted answer

MotoX80 34,421 Reputation points

2023-04-24T22:51:33.3733333+00:00

Powershell works the other way. You have to specify the -NoExit switch to keep it running after executing a command or a .ps1 file.

Your main issue is one that we see quite frequently. User writes a script. User runs script just fine in desktop session. User tries to run in task scheduler (or startup) but doesn't get expected results. User does not include any error handling or logging in the code and has no visibility into what the unattended script did. User asks us what is wrong with the task scheduler.

The simple solution is to include Out-File cmdlets in the script to write to a log file. If you need more detail, PS's Start-Transcript/Stop-Transcript might provide more info. Write out script start and end times. Put a try/catch around the main code block and write any error to your log file.

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_try_catch_finally?view=powershell-5.1

If the log/transcript files aren't being created, then PS itself must be running into some kind of fatal error. You then need to capture stdout and stderr from PowerShell.exe to see the error. That's where the bat file comes into play.

For low level debugging use Sysinternal's Process Monitor to trace what Powershell.exe does.

https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

The task scheduler is perfectly capable of running powershell.exe directly. Once you implement error handling and logging in your script, you should be able to remove the bat file.
Please sign in to rate this answer.

3 people found this answer helpful.
C A 0 Reputation points

2024-07-01T15:57:45.3833333+00:00

Same here. Procmon did not show anything other than reading the batch file and finished. It flies through the powershell command as if it is not there. And if I add -NoExit it starts powershell blue console but does not run the script and does not exit. How is noexit helping, when I do want powershell to run my process and exit either before or right when my process exits. I don't want it to hang. And on top of that, the task scheduler task stays "Running" forever even though the script never ran and I exited manually the powershell console when I add -NoExit.

"The task scheduler is perfectly capable of running powershell.exe directly. Once you implement error handling and logging in your script, you should be able to remove the bat file."

No doubt the first statement is true in general but not in my case. I am not capable of getting it to run, and no advice so far has helped. The second is not. There is logging. It shows nothing.

MotoX80 34,421 Reputation points

2024-07-01T16:20:33.4766667+00:00

@C A

Create a bat file that executes Powershell. Echo %date% %time% as the first and last line the .bat so that you know when the task starts and ends.

@echo %date% - %time% MyScript is starting. Powershell.exe C:\Scripts\MyPsScript.ps1 @echo %date% - %time% MyScript is ending. Powershell RC=%errorlevel%

Then change the scheduled task to execute program "cmd.exe".

In the arguments field set it like this example:

/c C:\Scripts\MyScript.bat 1>>"C:\Scripts\Logs\MyScript-%date:~10,4%-%date:~4,2%%date:~7,2%.log" 2>&1

That will create a daily log file of all executions of the task. It will capture stdout and stderr for programs that get called. Look for a Powershell error message in the log.

C A 0 Reputation points

2024-07-03T20:22:51.9966667+00:00

Thank you. I found out that the PS script runs and ends with code 0 and no errors but does not execute the command that is supposed to when scheduled. When not scheduled, it works. The purpose of the script is to get the today's date in format YYYYMMDD and pass it as one of the parameters to a batch file. It is:
$timestamp = (Get-Date -format "yyyyMMdd")

Start-Process -FilePath "$env:comspec" -ArgumentList "/c","backup.cmd",$timestamp,"-i","-cp" | Out-File -FilePath C:\bin\backup.cmd.log -Append

Another problem is that the task does not end. I added a Start-Transcript and got a transcript with nothing between the start and the end. And the powershell.exe process does not stay behind.

The most useful part of your post for me is the %date:~10,4% etc. I didn't know it could be done. Now I don't need the powershell script.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

2 additional answers

MotoX80 34,421 Reputation points

2023-04-20T21:17:02.1333333+00:00
Create a folder C:\Logs and grant Everyone full control. Change C:\Windows\temp\BackupData.log to C:\Logs\BackupData.log

In the bat file add a first statement that shows the run time.

@echo Task is starting %date% %time%

In the Powershell script add Test-Path cmdlets for both $sourcePath and $destinationPath When you map a drive, this is only for your logon session. If you are using a different account, you will need to map a drive for that account too. Also the task scheduler just does a user impersonation, not a full logon. You probably don't have an N drive visible to the script. Log on to the desktop with the account that the task runs as. Use credential manager to verify that it sees the saved credentials for the NAS. In that case try using the UNC notation \NASserver\sharename
Please sign in to rate this answer.

1 person found this answer helpful.
Mikros476 45 Reputation points

2023-04-21T15:06:05.4166667+00:00

Hm, I followed what you said but no dice. I don't even see logs created in the folder I made C:\Logs, and set to everyone. Also I tested the path in Powershell directly (said True for both the paths, even with the mapped N: drive), and added it to the script. As I said the script goes through and works if I run it manually. Either way I set it to the full UNC path but that didn't help either unfortunately. To be honest I've noticed other problems with Powershell being launched by automatic processes, like a separate script I put in the Startup folder isn't doing anything, but it does if directly started.

MotoX80 34,421 Reputation points

2023-04-21T18:07:09.15+00:00

Did you add the echo statement to the bat file? If there is a Powershell issue, then you need to capture stdout and stderr, (1 and 2) so that you can see what the problem is. The echo statement verifies that the task ran and could write to the log file. It doesn't get much simpler than that. What about task history. Enable that if you haven't. What's in the history tab?

Mikros476 45 Reputation points

2023-04-21T19:33:16.8333333+00:00

So I did put the echo statement in there. I get logs where they're supposed to be when I directly run the .bat file, say on my Desktop. But again if I run it via Task Scheduler I get nothing. The History tab says it was triggered/started, is running, and I see nothing happening in the destination folder. After a few minutes of this I end the task.

Here is some info on the Task Scheduler settings:

Not sure if it's a Powershell issue. Looks more like the problem is with Task Scheduler itself. It seems like it's not actually running the .bat file (hence no logs), which in turn isn't running the PowerShell script.

Rich Matheisen 46,811 Reputation points

2023-04-21T20:25:25.3933333+00:00

When you look at the list of scheduled tasks, does it say "The operation completed successfully" and the code that follows it is "0x0"? FWIW, the Operational Code in the history is always going to be a 1 or a 2. Those don't represent the exit code of your script (if you look in the event log you'll find that they're there, too). Try deleting the scheduled task and create a new one. You can also try changing that "Configure for" value to an earlier version of the O/S.

MotoX80 34,421 Reputation points

2023-04-21T20:32:19.6366667+00:00

Add the /c switch and double check your spelling and if you have spaces in the file name make sure that you use quotes.

What return code does cmd.exe produce? This is what I get for "bat file not found".

Rich Matheisen 46,811 Reputation points

2023-04-21T22:40:34.57+00:00

@MotoX80 Slightly interesting. 2147942401 is 0x80070001. Error code 1 says "Invalid function".

MotoX80 34,421 Reputation points

2023-04-22T00:43:14.0533333+00:00

It wasn't just the bat file, I didn't have the folder defined either. Might be that. This has got to be a simple typo error.

Mikros476 45 Reputation points

2023-04-24T15:59:54.27+00:00

Hmm, well looks like adding that /c before the rest of the arguments did it somehow. Does that just execute the code and then stop? Why would that have made a difference in this case. By the way, before fixing that, my return code for cmd.exe was 2147943691.

MotoX80 34,421 Reputation points

2023-04-24T19:18:42.91+00:00

/C Carries out the command specified by string and then terminates If your bat file had an EXIT statement as the last command, then you would not need the /c switch. (Run "help exit") If you didn't use either exit or /c then cmd.exe is just sitting there doing nothing. so the 2147943691 rc would be from either you or the task scheduler ending the process.

Mikros476 45 Reputation points

2023-04-24T19:42:09.3133333+00:00

Oh I see. Thanks! I'm pretty new to the whole scripting thing. Which leads me to ask, would a similar or equivalent command need to be added at the end of a PowerShell script as well if it is being called by Task Scheduler? I wonder why it had problems working without this .bat script intermediate. Or why my .ps1 script in the Startup folder isn't running. But all of these things, including the .bat files, work if they are manually run. I guess the /c or exit only applies if they are being run by some other program? Come to think of it, I recall having to hit enter when running the manual batch file, as it just generated a command prompt window, and the exit command at the end would've avoided that.

Mikros476 45 Reputation points

2023-04-25T14:46:03.53+00:00

Also sorry one more thing, it seems like with this and another task I wrote like this, the Status remains Running indefinitely, even after the copying has been completed, and it looks like it needs to manually be ended. Which kind of defeats the purpose. EDIT- nvm I realize you have to click refresh to do see it change to 'Ready' again, which is odd

MotoX80 34,421 Reputation points

2023-04-25T15:58:50.1266667+00:00

Add logging to your script like this.

$LogFile = "C:\scripts\logs\MyScript-{0}.log" -f (get-date -format "yyyyMMdd" ) # This is your daily log file function LogIt($msg){ $msg "$(get-date) - $msg" | Out-File $LogFile -Append } # Procedure Division try { LogIt "Script starting." # junk code just for testing. remove this and put your code here. $user = Get-ADUser -Identity $UserName -Properties sAMAccountName,HomeDirectory $FolderName = $user.HomeDirectory + "\Recover" } catch { LogIt "We crashed." LogIt $_ } LogIt "Script ending."

Mikros476 45 Reputation points

2023-04-26T14:50:01.1766667+00:00

Thank you. I've read about the try and catch functions but haven't actually tried implementing them. Makes sense.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Rich Matheisen 46,811 Reputation points

2023-04-20T21:24:07.1+00:00

Try using the UNC name instead of the mapped drive letter ("N:"). IIRC, a mapped drive is associated with a user interface, and a background task doesn't have one.
Please sign in to rate this answer.

1 person found this answer helpful.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Having Trouble Running Powershell Scripts with Task Scheduler

2 additional answers

Your answer