Powershell Scheduled Tasks Permissions Sanity Check

Tessando
Tessando used Ask the Experts™
on
I have a Powershell script that works when I run it manually but not when I run it as a Scheduled Task.

I am running the Scheduled Task as the same user (for both Powershell & Task Scheduler) with "Run whether users is logged on or not" selected.

I have setup Group Policy as follows: Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> “Access to this computer from the Network” AND “Allow logon locally” ~ Both of those locations contain the User I'm running the Scheduled Task under.

When I run this as a Scheduled Task it immediately bombs out.

What's going on here? Can someone help me figure out what's happening? I would love to get this Powershell script to run as a Scheduled Task.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Sam JacobsCitrix Technology Professional / Director of TechDev Services, IPM

Commented:
Does the script have any graphical output (e.g. a MsgBox)?
TessandoIT Administrator

Author

Commented:
Thanks Sam.

No, the script doesn't have any graphical output. I do have a logfile attached to it that gives me "success" or "failure". This is how I'm seeing if the script ran properly.

Thanks!
Sam JacobsCitrix Technology Professional / Director of TechDev Services, IPM

Commented:
If you're logged on as the user the task is running under, does it work?
11/26 Forrester Webinar: Savings for Enterprise

How can your organization benefit from savings just by replacing your legacy backup solutions with Acronis' #CyberProtection? Join Forrester's Joe Branca and Ryan Davis from Acronis live as they explain how you can too.

TessandoIT Administrator

Author

Commented:
Thanks Sam.

No, logged on as the User and running as a scheduled task don't work. I've never been able to get this to run successfully as a Scheduled Task unless I give it Administrator permissions. In this case, I cannot give the User Admin permissions.

When I run the raw Powershell, the script works as expected.
Sam JacobsCitrix Technology Professional / Director of TechDev Services, IPM

Commented:
What is the command line and arguments that you are using in the scheduled task?
TessandoIT Administrator

Author

Commented:
Thanks Sam - Here's the "Action" of the Scheduled Task:

Program/Script:
Powershell.exe

Add Arguments: -NoProfile -ExecutionPolicy Bypass -file "\scheduled_tasks\Amazon\CloudWatch\push-smtp-metrics-to-cloudwatch.ps1"
Start In: \scheduled_tasks\Amazon\CloudWatch\


Thanks!
Sam JacobsCitrix Technology Professional / Director of TechDev Services, IPM

Commented:
Try using the full path to PowerShell … this is what I use:

Program/script:
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"

Arguments:
-ExecutionPolicy ByPass -File "C:\path to script\Script.ps1"
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
You should add a drive letter to your paths, too.
TessandoIT Administrator

Author

Commented:
Thanks! I tried both of those (adding in the full path to Powershell and putting in full paths). Unfortunately that does not get the script to run successfully.

Any other ideas?

Thanks again for your time. I really value the fast responses I've got today.
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
Does task history tell the process has been started and executed correctly? If yes, the script contains the culprit, else it's the commandline.
TessandoIT Administrator

Author

Commented:
Thank you, Qlemo. The task history states "Task Completed" as well as the Last Run Result being "The operation completed successfully. (0x0)".

This is why I find this so confusing, so thank you for the sanity check.

When I run the script by itself, it runs successfully (this is running it as the Scheduled Task user I created). It's in the context of running as a Scheduled Task where it fails.
Sam JacobsCitrix Technology Professional / Director of TechDev Services, IPM

Commented:
In regular PowerShell, if you do a RunAs the other user does it work?
TessandoIT Administrator

Author

Commented:
Yes, it runs as expected when I open a new Powershell window. I also run it as "Powershell" -> <Right-click> -> More -> Run as different User -> "Scheduled Task User".
Top Expert 2014

Commented:
Does the user account have "Log on as a batch job" rights on the computer?  That should be needed if you have the box checked "run whether user is logged on or not".
TessandoIT Administrator

Author

Commented:
Thanks Footech - Yes, the user is under "Log on as batch job" located at Local Group Policy Editor -> Computer Configuration -> Windows Settings -> Security  Settings -> User Rights Assignment -> Log on as Batch
Top Expert 2014

Commented:
You said it does work if the account used is a member of the local Administrators group, correct?

Have you tried adding Start-Transript and Stop-Transcript commands to the script to put all output in a log file?  This could show if a particular part of the script is failing.
Another test worth performing is in the scheduled task, check the box for "only run when user is logged on".  Add the switch "-NoExit" to the task arguments.   Log on as that user and run the task.  Examine the PS window which has been left open after running the script and look for errors.
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
Running with "only if logged in" while logged in as that respective user is always the next step to check if running scheduled tasks fails, so definitely do that.
TessandoIT Administrator

Author

Commented:
A'ight Qlemo - Nice work. So, I logged in as this Scheduled Tasks user and recreated the Task. When I selected "Run only when user is logged in" it worked successfully. This is the first time I've been able to get this script to run as a scheduled tasks, btw.

I tested this by then selecting "Run whether user is logged in or not" and the script failed.

So, what is going on here? How can I get this to repeat running the script for a certain amount of time?

Thanks for your help, this is further than I've got before.
Top Expert 2014

Commented:
See my previous comment.  

Clarify whether you have been able to get this to work (running as a scheduled task) when the account used is a member of the local Administrators group and "Run whether user is logged in or not" is checked.  It sounded like it from one of your previous comments, but now it sounds like you haven't.

The next step would be to add more logging to your script to see exactly where it fails (stops doing what you want it to do).
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
If you can, post the script here - if it makes sense, that is we are able to follow what it does.
Otherwise you'll have to add debugging output (written to a log file) in several places to narrow down where the script fails.
TessandoIT Administrator

Author

Commented:
Thanks for all your responses, I greatly appreciate them.

I don't think that going down the script itself will be fruitful, but that's not a bad suggestion.

Logged into the Windows 2k16 server as the Scheduled Task User, and setting up the task, I cannot select "Run with highest privileges" I presume because it's permission based. What I found to be frustrating is that when I enter in the password (that the Task Scheduler expects for the user), the account defaults to a local user account... meaning that every time I need to explicitly add the Domain (or select "Entire Directory"). Has anyone experienced this before?

Unfortunately I don't have the option to add this user to the local Administrator group. I know that would solve all of this in two seconds. I've never had this much of a challenge with setting up a Scheduled Task and I appreciate your patience.
Top Expert 2014

Commented:
I know that would solve all of this in two seconds.
Not necessarily...  But it could give a clue as to whether the issue has to do with account privileges, or something else.  There are some scripts that just cannot be run as a scheduled task when "Run whether user is logged in or not" is checked, because an element of the script requires an interactive desktop, even if it's not displaying anything.
TessandoIT Administrator

Author

Commented:
Ah, right. There is no interactive desktop or anything. This is actually just a script pushing a metric to CloudWatch.

This Powershell script can be successfully ran as a Scheduled Task as both a local and Domain administrator.

Thanks!
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
It doesn't matter if "only logged in" is used, only if admin privs are available?
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
AFAIK, the missing domain name is a visual issue only - see my commentat https://www.experts-exchange.com/questions/29146667/Server-2016-scheduled-task.html#a42870470

Interesting enough, the asker was only able to run the task with admin privs, too.
TessandoIT Administrator

Author

Commented:
I'm with ya about the missing domain name value.

I created a new local Administrator user and the Scheduled Task runs every 5 minutes just fine.

So, at this point, we this is permissions based. What is the next level "down" from local administrator where I can run this scheduled task?

Just a quick checklist:
  • The local user is in the "Log On As Batch" Group Policy
  • The local user is in the Power Users Group locally
  • The local user has "Modify" permissions in the file structure
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
My next step would be to run ProcMon from www.sysinternals.com with a filter of "Process Name equal PowerShell.exe", then run the task as non-admin user, stop recording in ProcMon, and look for failures. It might reveal something, in particular if there is a file system issue. But reading the generated, lengthy output is cumbersome.
TessandoIT Administrator

Author

Commented:
Thank you, Qlemo. I was able to run ProcMon and found the Scheduled Task being run. Unfortunately it only shows as a Success using ProcMon but as a failure in the log file of the script (sending to CloudWatch). I will keep digging.
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
You are on your own, as long as we cannot see the script ;-). Good luck!

Using ProcMon you can go the "drilldown" way - start with no filter, than exclude processes and paths via context menu in the output to reduce. Make sure to have "Drop Filtered Events" (or similar) checked, so ProcMon only collects filtered events and deletes everything else.
I usually start ProcMon, capture for a short period, then exclude as much as possible. Then capture again, ...., until the output is "reasonable". And then run the real test.
TessandoIT Administrator

Author

Commented:
I'm still trying to figure out the best way to use ProcMon. It's a very cool tool that, even with filtering according to what you are describing, is still like drinking out of a fire hydrant. :-) I will keep at it.

I've pasted the script below and (for the sake of a sanity check) can successfully run manually successfully (even as Non-Admin) but not using the Task Scheduler. This seems to be isolated to permissions based on the use of the Task Scheduler.

Thanks again for your assist. Here's the script:

Import-Module AWSPowerShell

$Namespace = 'service-monitor-smtp'

$logpath = "D:\custom_assemblies\scheduled_tasks\Amazon\CloudWatch\logs\sending-services-to-cloudwatch-logs.txt"

$instanceId = (New-Object System.Net.WebClient).DownloadString("http://169.254.169.254/latest/meta-data/instance-id")

$instanceId | Out-File -FilePath $logpath -Append

$instanceDimension = New-Object -TypeName Amazon.CloudWatch.Model.Dimension;
$instanceDimension.Name = "instanceid";
$instanceDimension.Value = $instanceId;

    $metrics = @();

    $runningServices = Get-Service -Name SMTPSVC | ? { $_.Status -eq 'Running' }
    $runningServices | Out-File -FilePath $logpath -Append

    # For each running service, add a metric to metrics collection that adds a data point to a CloudWatch Metric named 'Status' with dimensions: instanceid, servicename
        $runningServices | % { 
        $dimensions = @();

        $serviceDimension = New-Object -TypeName Amazon.CloudWatch.Model.Dimension;
        $serviceDimension.Name = "service"
        $serviceDimension.Value = $_.Name;

        Write-Output "SD = $($serviceDimension.Value)" | Out-File -FilePath $logpath -Append  

        $dimensions += $instanceDimension;
        $dimensions += $serviceDimension;

        $metric = New-Object -TypeName Amazon.CloudWatch.Model.MetricDatum;
        $metric.Timestamp = [DateTime]::UtcNow;
        $metric.MetricName = 'Status';
        $metric.Value = 1;
        $metric.Dimensions = $dimensions;

        $metrics += $metric;    
        
        Write-Output "$metrics" | Out-File -FilePath $logpath -Append   

        Write-Output "Service: $($_.Name) is running" | Out-File -FilePath $logpath -Append
    }

    # This cmdlet doesn't fail gracefully so we will run it in a try / catch. 
    try {
    Write-CWMetricData -Namespace $Namespace -MetricData $metrics -Verbose
    } catch {
        Write-Output "CWMetric Failed" | Out-File -FilePath $logpath -Append 
    }
    # 

Open in new window

Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
What does the logfile tell you?
TessandoIT Administrator

Author

Commented:
The logfile of the Script only shows "Running" (as in 'success') or "CW Metric Failed". So, it very quickly gives us a picture as to what happened.

One thing related to running ProcMon yesterday: One process I ran against was the Task scheduler (as in "schtasks.exe"). The only result that came up as "Access Denied" was this file: C:\Windows\System32\catroot2\dberr.txt

When I dig a little deeper it shows that has to do with Windows Update, so likely that's a red herring. Does this ring a bell with anyone?

WRT ProcMon, is that a proper way to test for the Scheduled Task failing? I get virtually the same ProMon results when I do this for Powershell.exe.

Thanks!
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
ProcMon can show some failures if everything fails than when it succeeds. But there are a lot of files, folders, path elements, registry values ... which get checked by default and report a failure just because they do not exist, as they are optional. ProcMon output is usually difficult to read for that reason.
And sometimes you need to compare outpiut for a successful and a failing run to get a hint. You can perform two captures - one if the user is admin, one if not -  and (try to) compare results (manually).
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
If the script fails, it does not log anything else than "CW Metric Failed"?
TessandoIT Administrator

Author

Commented:
I like the idea of 2 captures. Now that I know a little about how to use it I can do that this afternoon. That said, in your opinion, which is the best process to use for the capture: Powershell.exe or schtasks.exe?

Second question: When the script fails it only logged "CW Metric Failed" and the Instance ID of the running EC2 instance.

Thanks!
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
I'm still trying to see where and why the script could fail. But having looked more into it, the ProcMon approach is probably leading nowhere, at least not by monitoring PowerShell or schtasks. Your log output tells us the issue is in line 10 to 18, because line 9 gets logged, and line 18 does not.

So I recommend to start a scheduled task as non-admin, "only if logged on", with action to start PowerShell (without script), and while logged in as that user. You'll get a PowerShell console running in the restricted user context. Now paste line by line of your script into the PowerShell window. You can output variables, run methods and so on at some stages to make sure they are working objects.
My guess is that the AWS module calls require admin access for some reason, and are silently failing if not able to. Another thought is that they require a particular (web related) setting like proxy. But both would be strange, as you told us you have that issue only with scheduled tasks.
TessandoIT Administrator

Author

Commented:
This is a GREAT suggestion. I setup Powershell to only pop up when I login (as the non-Admin user). I logged in, went down each line of code and it successfully ran.

When I run the Scheduled Task from the Non-Admin account it fails (in the log file).

When I run the Scheduled Task from my Admin account I get the error "The user account does not have permissions to run this task."

Thank you for your help on this one.
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
Are you still using -NoProfile as switch in the scheduled task?

How do you know that the script ran successfully? Did you see a difference in the log file?
TessandoIT Administrator

Author

Commented:
For that troubleshooting, I was NOT running -NoProfile. I simply created a Scheduled Task that brought up Powershell and I logged in as that user. After logging in I manually ran each line in that open Powershell. Is that the best way to troubleshoot it?

The way I saw it as successful was in the log file.

I'm going to repeat the same process today.
TessandoIT Administrator

Author

Commented:
Last night, as the Non-Admin User, I setup the exact same Task as the Admin user.

When I went to view it this morning (and re-attempt the script line-by-line), I noticed that it's still Running. So, this Scheduled Task as the Non-Admin user has been running all night long, every 5 minutes with the Last Run Result as "The task is currently running. (0x41301)."

Could this be a clue? It seems like it's stuck somewhere.
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
That non-admin scheduled task runs with -NoProfile?

Yes, the script is stuck somewhere. Maybe it presents a prompt (authentication or the like). Otherwise the script would fail and stop, and get restarted every 5 minutes (or whatever you have set up as trigger).
The log file is showing an error/failure, or just missing entries?
TessandoIT Administrator

Author

Commented:
> That non-admin scheduled task runs with -NoProfile?

Yes, that was stuck in a "Running" state.

I ended the Scheduled Task, restarted it and now it's just failing.

Any other troubleshooting ideas?

I doubt this matter, but at this point I'm grasping for solutions: I've got this nested under two Scheduled Task folders. Would this affect permissions at all? Here's a screenshot to demonstrate:

nested-scheduled-tasks.jpg
IT Administrator
Commented:
I was able to get this to work soup-to-nuts by choosing the local "SYSTEM" user to run, effectively NT AUTHORITY\SYSTEM. If it helps, I checked the radio button for "Run with Highest Privileges".

Thanks to everyone for their contribution, this was a tough nut to crack and I couldn't have done it without you.
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
SYSTEM is no bad choice, but works only if you do not need access to network shares. So it fits here. Sad that we haven't been able to locate the root of the issue, though.

You can still award (bonus) points for getting help if you do not like to accept additional comments as (part of) the answer.
TessandoIT Administrator

Author

Commented:
Thanks to everyone who participated in helping me resolve this challenging issue.

Thank you!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial