xScheduledTask doesn't work on Windows Server 2008R2

[dronkoff]

I'm creating a DSC configuration with http pull server that will create certain scheduled tasks on both 2012R2 and 2008R2 servers. If target node is Windows Server 2008R2 the configuration cannot be applied.

PS C:\Windows\system32> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.0.10586.117
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.10586.117
CLRVersion                     4.0.30319.36392
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Here are errors I see when run Update-DscConfiguration -Wait -Verbose

PS C:\Windows\system32> Update-DscConfiguration -Wait -Verbose
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' =
PerformRequiredConfigurationChecks,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' =
root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer SKS06SP001 with user sid
S-1-5-21-2727014839-3263237905-4095819900-36884.
WARNING: LCM state is changed by non-DSC operations. If you wish to change the state of LCM, please use
Remove-DscConfigurationDocument cmdlet.
VERBOSE: [SKS06SP001]:                            [] Executing Get-Action with configuration 's checksum:
F6D859ED0118E0525C85CE3F9CD5FECFF7C937A3495E75FFB28841D7C84A5E7D.
VERBOSE: [SKS06SP001]:                            [] Executing Get-Action with configuration 's checksum returned
result status: GetConfiguration.
VERBOSE: [SKS06SP001]:                            [] Checksum is different. LCM will execute GetConfiguration to pull
configuration .
VERBOSE: [SKS06SP001]:                            [] Executing GetConfiguration succeeded. Configuration  was pulled
from server.
VERBOSE: [SKS06SP001]:                            [] Applying the new configuration(s) pulled.
....
VERBOSE: [SKS06SP001]: LCM:  [ Start  Resource ]  [[xScheduledTask]Task_RestartSPtimer]
VERBOSE: [SKS06SP001]: LCM:  [ Start  Test     ]  [[xScheduledTask]Task_RestartSPtimer]
VERBOSE: [SKS06SP001]:                            [[xScheduledTask]Task_RestartSPtimer] Testing scheduled task \Restart
 SPtimer
VERBOSE: [SKS06SP001]:                            [[xScheduledTask]Task_RestartSPtimer] Retrieving existing task
(\Restart SPtimer in \Microsoft\).
The term 'Get-ScheduledTask' is not recognized as the name of a cmdlet, function, script file, or operable program. Che
ck the spelling of the name, or if a path was included, verify that the path is correct and try again.
    + CategoryInfo          : ObjectNotFound: (Get-ScheduledTask:) [], CimException
    + FullyQualifiedErrorId : CommandNotFoundException
    + PSComputerName        : localhost

VERBOSE: [SKS06SP001]:                            [[xScheduledTask]Task_RestartSPtimer] No task found. returning empty
task \Restart SPtimer with Ensure = "Absent".
VERBOSE: [SKS06SP001]:                            [[xScheduledTask]Task_RestartSPtimer] Current values retrieved
VERBOSE: [SKS06SP001]:                            [[xScheduledTask]Task_RestartSPtimer] Testing DSC parameter state.
VERBOSE: [SKS06SP001]: LCM:  [ End    Test     ]  [[xScheduledTask]Task_RestartSPtimer]  in 0.8260 seconds.
The PowerShell DSC resource '[xScheduledTask]Task_RestartSPtimer' with SourceInfo 'C:\DSCConfigs\Ebz_TestConfig.ps1::39
::9::xScheduledTask' threw one or more non-terminating errors while running the Test-TargetResource functionality. Thes
e errors are logged to the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this channel for more details
.
    + CategoryInfo          : InvalidOperation: (:) [], CimException
    + FullyQualifiedErrorId : NonTerminatingErrorFromProvider
    + PSComputerName        : localhost

The SendConfigurationApply function did not succeed.
    + CategoryInfo          : NotSpecified: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : MI RESULT 1
    + PSComputerName        : localhost

[steveapalooza]

You might need to update WMF to 5.1 or later. What version is running on the 201R2 box?

[PlagueHO]

Hi @dronkoff , unfortunately this resource is dependent on the *-ScheduledTask powershell cmdlets. These were first introduced in Windows Server 2012 I think - so they don't exist in Windows Server 2008 R2. It is pretty unlikely that we'd be able to make this work with Windows Server 2008 R2 unfortunately.

[dronkoff]

@Hossman58 Pull server is 2012R2 and PS 5.1. Node is 2008R2 and PS 5.0. I didn't find official information about where ScheduledTasks module is included or how it can be installed on 2008R2, it would be great if you point me.

[dronkoff]

@PlagueHO Afaik, we can use schtasks.exe for automating scheduled tasks if ScheduledTasks module is missing. So it is possible. Module release page https://www.powershellgallery.com/packages/xComputerManagement/3.0.0.0 says that there do dependencies and a supported PS version is 4.0. I think it will be good either to support what's declared or declare what is really supported.

[PlagueHO]

Hi @dronkoff - This module is supported on PS 4.0. However, the problem isn't in the version of PowerShell. The issue is that the ScheduledTasks module, which this resource depends on, is not built into Windows Server 2008R2. It was first included in Windows Server 2012.

This is the case with many of the PowerShell modules: They are missing from older versions of Windows (Networking for example). In the odd occasion there is an easy work around. However in this case converting the resource over to use schtasks.exe is not possible without a complete rewrite and would probably result in something really unstable and buggy (not to mention the problems that would arise with different localized versions of schtasks). I really can't see this happening unfortunately (unless someone else from the community has some ideas on how to do this).

But you are correct, this should be mentioned that Windows Server 2008R2 is not currently supported.

[dronkoff]

Hi! If the solution is not to fix this, then we should update documentation as well as dependencies. I shouldn't be able to install xComputerManagement on a box without ScheduledTasks module.

[PlagueHO]

It is possible that some of the resources in this module do in fact work on Windows Server 2008 R2. So we'd need to confirm this before making a change like that to the manifest. But I'm not actually certain this is an approach the PowerShell DSC Team or the DSC community would recommend.

@kwirkykat are you able to offer some thoughts from the PSDSC team on this? If a resource module has a dependency on a module that may or may not be "built-in" to the OS, is it recommended practice to specify the dependent module in the resource manifest?

We've never done this in any of the resource kit resources that I know of and it seems like it might have some undesirable side-effects.

[dronkoff]

Module dependencies should address all dependencies of it's contents. If I write a script of two functions, one of them depend on some module, another is not. How do you think, does whole script depend on the module? Or if I write .Net assembly with two classes in it, one depends on another assembly, another is not. Does whole assembly depends on another one? I think both answers are yes. Usually such separation happens on assembly, script, module level. One function goes to the script without dependency and another function goes to the script with dependency. But two modules...

Now I have a successfully applied configuration on node that can not work.

PS C:\Windows\system32> Get-DscConfiguration
WARNING: [SKS06SP001]:                            [] The GET operation will be carried against a pending configuration
since the latest configuration has not converged yet.
Get-DscConfiguration : The term 'Get-ScheduledTask' is not recognized as the name of a cmdlet, function, script file, o
r operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try
again.
At line:1 char:1
+ Get-DscConfiguration
+ ~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Get-ScheduledTask:root/Microsoft/...gurationManager) [Get-DscConfigurat
   ion], CimException
    + FullyQualifiedErrorId : CommandNotFoundException,Get-DscConfiguration

Get-DscConfiguration : The PowerShell DSC resource '[xScheduledTask]Task_RestartSPtimer' with SourceInfo 'C:\DSCConfigs
\Ebz_TestConfig.ps1::39::9::xScheduledTask' threw one or more non-terminating errors while running the Get-TargetResour
ce functionality. These errors are logged to the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this ch
annel for more details.
At line:1 char:1
+ Get-DscConfiguration
+ ~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (MSFT_DSCLocalConfigurationManager:root/Microsoft/...gurationManager)
   [Get-DscConfiguration], CimException
    + FullyQualifiedErrorId : NonTerminatingErrorFromProvider,Get-DscConfiguration

[PlagueHO]

Hi @dronkoff - I do understand the difficulty here. I have had a bit of a think about this. The trouble with blocking installation of a resource on a computer because it has an apply time dependency isn't a good idea here. Many people (including myself) develop & compile MOF files on machines that are not the target node (e.g. develop on a Desktop OS and apply on a Server OS). So preventing us from developing on machines that don't have the modules required on the target node is going to cause a problems for many people.

I do agree, that the apply time module dependencies of a resource should be made clear, I just don't think preventing the installation of the resource if the dependencies can not be met on the development machine is the right solution.

[PlagueHO]

If there are no objections, I'd like to close this one because I don't think there is a good solution to this issue.

[dronkoff]

I don't think this issue should be closed without any resolution. If nobody is fixing it, it doesn't mean that it doesn't exist.

[PlagueHO]

I'm happy to leave this open. But it is unlikely that I'll be able to add support to it for Windows Server 2008. But if someone else can contribute a solution then it would be gratefully accepted.

[SwarfegaGit]

I don't see why this should be left open. There isn't going to be a fix for this as these modules will not be back ported to Windows 2008 R2. I don't believe even copying the modules from 2012 R2 to 2008 R2 will work as the modules are making API calls which simply don't exist in Windows 2008 R2.
The only answer is to update to a newer OS to get access to newer features.

I do agree though Microsoft could make it easier to say which operating systems a resource supports. That said I use xComputerManagement on 2008 R2 servers and make use of the xPowerPlan, xComputer and xVirtualMemory without issues.

[dronkoff]

To resolve this issue we have 2 options:

1. Document it and make is a "feature". (Document module and version dependencies on module level)
2. Implement it on Win2008. (There is no need to port 2012 modules to 2008, the resource can be implemented using COM interfaces)

Last stable release was published 2 weeks ago but none of the above options were implemented there.

[PlagueHO]

If someone were to make a submission for a Windows Server 2008 R2 compatible version using the COM interfaces it would be gladly accepted. But I don't think this is likely to happen, so in the meantime @dronkoff 's option 1 I think is the way to go (for now - could always change later if new options come to light).

So I'll submit a PR for this.

[PlagueHO]

I've added the requirements information to the README.MD. I'll close this issue for now, but someone wants to have a crack at implementing this on Windows Server 2008 R2 then we should definitely reopen this.