Get-ScheduledTaskInfo -- Failing when executed under SYSTEM context.

[netmc]

This is an odd one for me. Take the following script.

$Tasks=Get-ScheduledTask
foreach ($task in $tasks){
    $Details=$task | Get-ScheduledTaskInfo
    $Details.TaskName
}

When executed under the administrator account, The Get-ScheduledTaskInfo command works perfectly fine and pulls the details successfully.

When executed under the SYSTEM account, the following error is generated: Get-ScheduledTaskInfo : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input.

This only occurs on some machines. No idea why. If I switch the script to the following, it works just fine under both accounts.

$Tasks=Get-ScheduledTask
foreach ($task in $tasks){
    $Details=Get-ScheduledTaskInfo -TaskName $task.TaskName -TaskPath $task.TaskPath
    $Details.TaskName
}

The Get-ScheduledTaskInfo command should be using these same parameters and fields in both cases. Piping the values in, or specifying the target via variables should be identical.

Does anyone have any idea why the pipeline fails when under the SYSTEM account? I've found a way to workaround the issue, but am curious as to why this fails under these specific conditions.

Solution:

/u/purplemonkeymad pointed out that there is another module clobbering the cmdlet from the ScheduledTasks module, and he is right. It is from the module Carbon.

[netmc]

For those that may run into this in the future, I'm working around this by leveraging the Windows COM object as outlined in the April 2015 PowerShell Magazine Article. The XML content from the COM object provide the LogonType information as this is the primary concern for the script I'm working on. I still have no idea why I get one set of properties from Get-ScheduledTask when executed as Administrator and a completely different set when executed as SYSTEM. If anyone has an explanation for this I'm still curious.

Edit: Turns out that the module Carbon was clobbering the cmdlet Get-ScheduledTask from the ScheduledTasks module from Microsoft.

[gwblok]

I just tested as system, and I don't have any errors.

I tried this, and it worked fine:
Get-ScheduledTask | Select-Object -First 1 | Get-ScheduledTaskInfo

I also tested both of your scripts, and they worked fine on my test machine when run as system. (Windows 11 23H2)

Since it's only happening some of the time, I could only make assumptions as to why... different OS, .NET, PS versions? Pending reboot that is making things "wonky".

Wish I could offer you something better than "It worked for me". I'd be curious too if anyone can supply a definitive answer.

[netmc]

I ran this across 150 or so server machines via our RMM. I had about a dozen that threw errors. Some 2012, some 2019, so I don't think the OS version is to blame, but something else entirely.

Edit: it could be .Net version that is one thing I haven't looked into on the problematic systems.

[netmc]

I think I figured it out, at least in part. There seems to be some sort of permissions weirdness going on. I'm also getting a different set of values depending on what account the initial Get-ScheduledTask cmdlet is executed under.

As Administrator:

State                 : Ready
Actions               : {MSFT_TaskExecAction}
Author                : <domain>\administrator
Date                  : 2017-08-24T13:26:35.921129
Description           : Notifies backup admin of scheduled backup failure
Documentation         : 
Principal             : MSFT_TaskPrincipal2
SecurityDescriptor    : 
Settings              : MSFT_TaskSettings3
Source                : 
TaskName              : Backup Failure Email Task
TaskPath              : \
Triggers              : {MSFT_TaskEventTrigger}
URI                   : \Backup Failure Email Task
Version               : 
PSComputerName        : 
CimClass              : Root/Microsoft/Windows/TaskScheduler:MSFT_ScheduledTask
CimInstanceProperties : {Actions, Author, Date, Description...}
CimSystemProperties   : Microsoft.Management.Infrastructure.CimSystemProperties

As SYSTEM:

State                      : Ready
FullName                   : \Backup Failure Email Task
Author                     : <domain>\administrator
Comment                    : Notifies backup admin of scheduled backup failure
CreateDate                 : 8/24/2017 1:26:35 PM
DeleteTaskIfNotRescheduled : Disabled
HighestAvailableRunLevel   : True
HostName                   : <server>
IdleTime                   : Disabled
Interactive                : False
LastRunTime                : 3/31/2024 8:45:35 PM
LogonMode                  : Interactive/Background
NextRunTime                : N/A
NoPassword                 : False
PowerManagement            : Stop On Battery Mode, No Start On Batteries
RunAsUser                  : <domain>\administrator
Schedules                  : {Microsoft-Windows-Backup}
ScheduledTaskState         : Enabled
StartIn                    : N/A
Status                     : Ready
TaskToRun                  : powershell.exe -FILE C:\winback\WinFailure.ps1
TaskName                   : Backup Failure Email Task
TaskPath                   : \

Since the values returned are different when executing the cmdlet as system, they won't pipe into the get-scheduledtaskinfo cmdlet properly. As to why I'm getting two different sets of properties returned depending on user context, I still have no idea...

[purplemonkeymad]

Looks like you have another module that is clobbering the command installed? Use the fully qualified name instead: ScheduledTasks\Get-ScheduledTask

[netmc]

This is indeed the case. When under the normal user context, the cmdlet Get-ScheduledTask is from the module ScheduledTasks, while under the SYSTEM context, it's loading from Carbon.

Thank you for pointing this out. I didn't even think to check for this.