ScheduledTask: Resource is never in compliance when BuiltInAccount is used

[DelectableMechanisations]

Details of the scenario you tried and the problem that is occurring

I am trying to apply a configuration using the ScheduledTask resource and the BuiltInAccount property. Whilst the configuration applies successfully, running Test-DscConfiguration always returns false. This ultimately seems to boil down to the SYSTEM principal account name sometimes displaying as 'SYSTEM' and other times as 'NT AUTHORITY\SYSTEM'.

Verbose logs showing the problem

VERBOSE: [ServerName]:[[ScheduledTask]Dsc_ScheduledTask_Taskname] MATCH: Value (type 'System.String') for property 
'LogonType' does match. Current state is 'ServiceAccount' and desired state is 'ServiceAccount'.
VERBOSE: [ServerName]:[[ScheduledTask]Dsc_ScheduledTask_Taskname] MATCH: Value (type 'System.String') for property 
'User' does match. Current state is 'SYSTEM' and desired state is 'SYSTEM'.
VERBOSE: [ServerName]:[[ScheduledTask]Dsc_ScheduledTask_Taskname] NOTMATCH: Value (type 'System.String') for property
 'BuiltInAccount' does not match. Current state is 'SYSTEM' and desired state is 'NT AUTHORITY\SYSTEM'.
VERBOSE: [ServerName]:[[ScheduledTask]Dsc_ScheduledTask_Taskname] MATCH: Value (type 'System.String') for property 
'ExecuteAsCredential' does match. Current state is 'SYSTEM' and desired state is 'SYSTEM'.

Suggested solution to the issue

My guess is that when commit 1ae52d58a809b5604101dc1bf443e478ac34b88c was implemented it didn't go far enough to resolve the underlying issue OR a recent Windows Update has changed the operation of the Get-ScheduledTask cmdlet and the values it returned.

I believe a change needs to be made to source/DSCResources/DSC_ScheduledTask/DSC_ScheduledTask.psm1, most likely in the section of code below:

Current:

Function Get-CurrentResource
...
if (($result.ContainsKey('LogonType')) -and ($result['LogonType'] -ieq 'ServiceAccount'))
{
    $result.Add('BuiltInAccount', $task.Principal.UserId)
}
...

Proposed:

Function Get-CurrentResource
...
if (($result.ContainsKey('LogonType')) -and ($result['LogonType'] -ieq 'ServiceAccount'))
{
    switch ($task.Principal.UserId -like 'NT AUTHORITY\*')
    {
        $true  {$result.Add('BuiltInAccount', $task.Principal.UserId)}
        $false {$result.Add('BuiltInAccount', "NT AUTHORITY\$($task.Principal.UserId)")}
    }
}
...

The DSC configuration that is used to reproduce the issue (as detailed as possible)

ScheduledTask Dsc_ScheduledTask_Taskname
{
    TaskName           = "Remove Log Files"
    ActionArguments    = "-ExecutionPolicy Bypass -NonInteractive -Command Remove-LogFile -Path 'D:\Temp' -Recurse -Filter '*' -Age 30"
    ActionExecutable   = '%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe'
    BuiltInAccount     = 'SYSTEM'
    DaysInterval       = 1
    Description        = 'Remove all temporary files older than 30 days from "D:\Temp".'
    Enable             = $true
    Ensure             = 'Present'
    ExecutionTimeLimit = '01:00:00'
    MultipleInstances  = 'IgnoreNew'
    RunLevel           = 'Highest'
    ScheduleType       = 'Daily'
    StartTime          = '2019-09-17 23:56:00'
    StartWhenAvailable = $true
    TaskPath           = '\'
}

The operating system the target node is running

OsName               : Microsoft Windows Server 2016 Standard
OsOperatingSystemSKU : StandardServerEdition
OsArchitecture       : 64-bit
WindowsBuildLabEx    : 14393.3630.amd64fre.rs1_release.200407-1730
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

Version and build of PowerShell the target node is running

Name                           Value
----                           -----
PSVersion                      5.1.14393.3471
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.3471
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Version of the DSC module that was used ('dev' if using current dev branch)

master (version 8.1.0 downloaded from PowerShell Gallery)

[PlagueHO]

Adding some additional information to this as I think #328 is a duplicate (will close #328):

The ScheduledTask integration tests are failing when using a Service Account as the credential on Windows Server 2016.

The tests fail because on Windows Server 2016 the BuiltInAccount does not match:

2020-05-03T02:00:45.4481278Z VERBOSE: [fv-az172]:                            [[ScheduledTask]ScheduledTaskServiceAccountAdd] NOTMATCH: Value (type 
2020-05-03T02:00:45.4481906Z 'System.String') for property 'BuiltInAccount' does not match. Current state is 'LOCAL SERVICE' and desired state is 
2020-05-03T02:00:45.4482371Z 'NT AUTHORITY\LOCAL SERVICE'.

https://dev.azure.com/dsccommunity/ComputerManagementDsc/_build/results?buildId=1640&view=logs&j=d204ecb0-679f-5511-000c-e44e68a2d8e0&t=5c1ba461-30de-5960-3c67-72972b008e62&l=1708

On Windows Server 2019 the logs show:

2020-04-27T04:31:32.2808264Z VERBOSE: [fv-az674]:                            [[ScheduledTask]ScheduledTaskServiceAccountAdd] MATCH: Value (type 
2020-04-27T04:31:32.2809050Z 'System.String') for property 'BuiltInAccount' does match. Current state is 'NT AUTHORITY\LOCAL SERVICE' and desired 
2020-04-27T04:31:32.2809421Z state is 'NT AUTHORITY\LOCAL SERVICE'.

The tests fail because on Windows Server 2016 the BuiltInAccount does not match:

2020-05-03T02:00:47.3387033Z VERBOSE: [fv-az172]:                            [[ScheduledTask]ScheduledTaskServiceAccountMod] NOTMATCH: Value (type 
2020-05-03T02:00:47.3387834Z 'System.String') for property 'BuiltInAccount' does not match. Current state is 'NETWORK SERVICE' and desired state is 
2020-05-03T02:00:47.3388450Z 'NT AUTHORITY\NETWORK SERVICE'.

https://dev.azure.com/dsccommunity/ComputerManagementDsc/_build/results?buildId=1640&view=logs&j=d204ecb0-679f-5511-000c-e44e68a2d8e0&t=5c1ba461-30de-5960-3c67-72972b008e62&l=1874

On Windows Server 2019 the logs show:

2020-04-27T04:31:34.3290037Z VERBOSE: [fv-az674]:                            [[ScheduledTask]ScheduledTaskServiceAccountMod] MATCH: Value (type 
2020-04-27T04:31:34.3290645Z 'System.String') for property 'BuiltInAccount' does match. Current state is 'NT AUTHORITY\NETWORK SERVICE' and desired 
2020-04-27T04:31:34.3291030Z state is 'NT AUTHORITY\NETWORK SERVICE'.

The tests fail because on Windows Server 2016 the ExecuteAsCredential does not match:

2020-05-03T02:01:00.7419639Z VERBOSE: [fv-az172]:                            [[ScheduledTask]ScheduledTaskExecuteAsAdd] NOTMATCH: Value (type 
2020-05-03T02:01:00.7420261Z 'System.String') for property 'ExecuteAsCredential' does not match. Current state is 'Users' and desired state is 
2020-05-03T02:01:00.7424061Z 'BUILTIN\Users'.

https://dev.azure.com/dsccommunity/ComputerManagementDsc/_build/results?buildId=1640&view=logs&j=d204ecb0-679f-5511-000c-e44e68a2d8e0&t=5c1ba461-30de-5960-3c67-72972b008e62&l=1874

On Windows Server 2019 the logs show:

2020-04-27T04:31:49.5811142Z VERBOSE: [fv-az674]:                            [[ScheduledTask]ScheduledTaskExecuteAsAdd] MATCH: Value (type 
2020-04-27T04:31:49.5811856Z 'System.String') for property 'ExecuteAsCredential' does match. Current state is 'BUILTIN\Users' and desired state is 
2020-04-27T04:31:49.5812199Z 'BUILTIN\Users'.

[PlagueHO]

Thanks for raising @DelectableMechanisations BTW! I've got to fix this as part of PR #326 because the CI pipeline is currently in a failed state. So I'll test out your change in that PR and see if it works.

[PlagueHO]

I've managed to fix one of the problems: BuiltInAccount, but still working on the ExecuteAsCredential problem.