Powershell – Why do weekly tasks created via PowerShell using a different user fail with error 0x41306

powershellpowershell-v3.0scheduled-taskwindows-server-2008-r2

We have some scripts that create scheduled jobs using PowerShell as part of our application. When testing them recently, I noticed that some of them always failed immediately, and no output is ever produced (they don't even appear in the Get-Job list).

After many days of tweaking, we've managed to isolate it to any jobs that are set to run weekly. Below is a script that creates two jobs that do exactly the same thing. When we run this on our domain, and provide credentials of a domain user, then force both jobs to run in the Task Scheduler GUI (right-click -> Run), the daily one runs fine (0x0 result) and the weekly one fails (0x41306).

Note: If I don't provide the -Credential param, both jobs work fine. The jobs only fail if the task is both weekly, and running as this domain user.

I can't find information on why this is happening, nor think of any reason it would behave differently for weekly jobs. The "History£ tab in the Task Scheduler has almost no useful information, just "Task stopping due to user request" and "Task terminated", both of which have no useful info:

Task Scheduler terminated "{eabba479-f8fc-4f0e-bf5e-053dfbfe9f62}"
instance of the "\Microsoft\Windows\PowerShell\ScheduledJobs\Test1"
task. Task Scheduler stopped instance
"{eabba479-f8fc-4f0e-bf5e-053dfbfe9f62}" of task
"\Microsoft\Windows\PowerShell\ScheduledJobs\Test1" as request by
user "MyDomain\SomeUser" .

What's up with this? Why do weekly tasks run differently, and how can I diganose this issue?

This is PowerShell v3 on Windows Server 2008 R2. I've been unable to reproduce this locally, but I don't have a user set up in the same way as the one in our production domain (I'm working on this, but I wanted to post this ASAP in the hope someone knows what's happening!).

Import-Module PSScheduledJob

$Action =
{
    "Executing job!"
}

$cred = Get-Credential "MyDomain\SomeUser"

# Remove previous versions (to allow re-running this script)
Get-ScheduledJob Test1 | Unregister-ScheduledJob
Get-ScheduledJob Test2 | Unregister-ScheduledJob

# Create two identical jobs, with different triggers
Register-ScheduledJob "Test1" -ScriptBlock $Action -Credential $cred -Trigger (New-JobTrigger -Weekly -At 1:25am -DaysOfWeek Sunday)
Register-ScheduledJob "Test2" -ScriptBlock $Action -Credential $cred -Trigger (New-JobTrigger -Daily -At 1:25am)

Best Answer

I have just had to figure this one out myself, so here is what I found.

In the poweshell documentation I found the following:

Get-ScheduledJob gets only scheduled jobs that are created by the current user using the Register-ScheduledJob cmdlet.

http://technet.microsoft.com/en-us/library/hh849784.aspx

The impact of this is that if you create jobs with user 'A' and then run scripts trying to access them with user 'B' an error is thrown stating it can not find the job.

Related Solutions

Windows Server 2008 R2 – Process Runs Slower as a Scheduled Task

It appears that there is more than just "regular" process priority at work here. As I noted in the question, the task scheduler by default runs your task at lower than normal priority. This question on StackOverflow describes how to fix any task to run at Normal priority, but the fix still leaves one thing slightly different: memory priority. Memory priority was a new feature for Windows Vista, and is described in this Technet article. You can see memory priority using Process Explorer, which is a must-have tool for any administrator or programmer.

Anyway, even with the scheduled task priority fix, the memory priority of your task is set to 4, which is one notch below the normal setting of 5. When I manually boosted the memory priority of my task up to 5, the performance was on par with running the process interactively.

For info on boosting the priority, see my answer to a related StackOverflow question about IO priority; setting memory priority is done similarly, via NtSetInformationProcess, with PROCESS_INFORMATION_CLASS set to ProcessMemoryPriority (the value of this is 39 or 0x27). I might make a free utility that can be used to set this, if others need it and don't have access to programmer tools.

EDIT: I've gone ahead and written a free utility for querying and setting the memory priority of a task, available here. The download contains both source code and a compiled binary.

Powershell – Why does powershell -command “Restart-Service Tomcat6” fail when run from a Scheduled Task

tl;dr

My SDDL was incomplete. I needed to add SW (EnumDeps) to the already added LCRPWP permissions in the SDDL.

Long Version

Here is the (sanitized) version of my (broken) SDDL:

D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;LCRPWP;;;S-1-1-11-1111111111-1111111111-1111111111-1111)

The problem is in the last clause permissions:

(A;;LCRPWP;;;S-1-1-11-1111111111-1111111111-1111111111-1111)

The SID S-1-1-11-1111111111-1111111111-1111111111-1111 is correct for the group DOMAIN\Tomcat Restarters that DOMAIN\tomcat.restarter is a member of. That much is right. The permissions granted (LCRPWP) are insufficient for Restart-Service.

For the Restart-Service Cmdlet to work it needs the right to Enumerate Dependent Services. In SDDL this is SW (EnumDeps) in the SDDL string. I had LCRPWP which allows QueryStat, Start and Stop.

The correct SDDL for Tomcat 6 for me is:

D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;LCSWRPWP;;;S-1-1-11-1111111111-1111111111-1111111111-1111)

The mystery is why Powershell could run Restart-Service from a runas Command Prompt, but not from the Task Scheduler.

I got the necessary revelation from reading @splattered bits answer to his own similar issue with Restart-Service at https://serverfault.com/a/357753/57073.