1
votes

I've got a script that deletes old temp files, and it works perfectly under the following scenarios:

  1. From the Console Host
  2. From the PowerShell ISE
  3. From the Run command. In other words, Start>>Run. Enter powershell.exe -file C:\Users\<userprofile>\Delete-TempFiles.ps1

But I want to set it up as a Scheduled Task since it can take some time to finish. My understanding is that if a command works at the Run line, then I simply need to copy that command into the proper field in Task Scheduler. Namely, the 'Program/script' text box under the 'Actions' tab. The Scheduler moves the verbiage after 'powershell.exe' to the 'Arguments' field, and everything should be good. So saith Ed Wilson, Scripting Guy.

But something breaks. When launched regularly, the script gets server names from a text file, checks temp folders on each server, and deletes old files, like so:

Get-ChildItem -Path \\$server\C$\Windows\Temp -File | Where-Object {$_.LastAccessTime -lt $cutoffdate} | Remove-Item -Recurse

On every server I've tested, at least something is found and deleted, as expected. But when I set up the Scheduled Task, zero files are found/deleted.

After some troubleshooting, I discovered that when I click Start>>Run>>PowerShell, it opens to my user profile, but when Scheduled Task launches PowerShell, it opens to C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe. Because my script was written to assume my source file was in my profile, PS couldn't find it. I thought that filling in the "Start In" text box in Scheduled Task would mean that PowerShell would open in that folder, but I guess not.

To fix that, I hard-coded the location of the source file in my script (ick) and I put Set-Location C:\Users\<userprofile> at the top of my script. But that doesn't change anything.

I've also tried the following for Actions:

powershell -noprofile -noexit -executionpolicy bypass -file C:\Users\<userprofile>\Delete-TempFolders.ps1

Again, the script when launched as a task works normally except it fails to find or delete any old temp files. I simply can't figure out where it's failing.

2
What user is the scheduled task running as?briantist
@briantist - approximately 90% of scheduled task problems right there.EBGreen
@EBGreen yeah, especially when UNC paths are involved.briantist
Running as my own userid, set to run whether user is logged on or not, password not stored (can't due to security restrictions), Highest privileges. The script gets my domain password from an xml file that I create using 'Get-Credential | Export-Clixml -path .\creds.xml'James Brown
Password not stored = you can only access local resources. "Local" is a bit misleading here, because HTTP will probably work, but no UNC paths or anything that requires NTLM auth.Alexander Obersht

2 Answers

1
votes

To formalize my previous comment as an answer, here's an excerpt from the TechNet article on the subject:

If you select the checkbox labeled Do not store password , Task Scheduler will not store the credentials supplied on the local computer, but will discard them after properly authenticating the user. When required to run the task, the Task Scheduler service will use the “Service-for-User” (S4U) extensions to the Kerberos authentication protocol to retrieve the user’s token.

When using S4U the ability of the service to use the security context of the account is constrained. In particular, the service can only use the security context to access local resources. If your task requires access to network resources, you cannot use S4U; doing so will cause your task to fail. The only exception is the case where constrained delegation was established between the computers involved in the operation. If you are using the S4U functionality, the task will not have access to encrypted files.

In other words, you have three options:

1) Store everything that the tasks needs locally (or move the task itself to the computer where the files are located).

2) Use a network protocol that doesn't require domain authentication. This can be insecure and you probably won't be able to make use of convenient stock cmdlets such as Get-ChildItem.

3) Set up Kerberos constrained delegation. This is easier said than done but it's still a possibility.

0
votes

This does not directly tries to answer your question. Instead, provides a way to troubleshoot better by redirecting the output to a log file. Run the script with powershell as the command and -NonInteractive -windowstyle minimized -c "powershell -c "C:\Users\<userprofile>\Delete-TempFolders.ps1" -verbose >> "C:\LogPath\ConsoleLogs\TempFoldersPS1.log" 2>&1" as argument.

Hope this helps. Else, let me know I would take this down.