xScheduleTask - Time Zone issues

[Zuldan]

@PlagueHO I've started converting all my cScheduledTask (totally different resource) configurations to xScheduledTask and noticed some time zone issues. The configuration is being built in Australia but the servers are in New Zealand.

I need a task to run every 15 minutes for 23 hours a day. So I used the following config.

RepeatInterval     = '00:15:00'
RepetitionDuration = '23:00:00'

However, I get the following issue.

Invoke-CimMethod : PowerShell DSC resource MSFT_xScheduledTask  failed to execute Set-TargetResource functionality with error message: Repetition duration 01:00:00 is less than repetition interval 02:15:00. Please set RepeatInterval to a value lower or 
equal to RepetitionDuration

If I do something like this...

RepeatInterval     = [datetime]::Today.AddMinutes(15)
RepetitionDuration = '20:00:00'

...then the scheduled task is set to start 12:00AM, repeat every 02:15:00 for a duration of 22:00:00.

I think one solution would be to add a property to the resource called 'UseLocalTime' this would resolve the issue without having a breaking change.

Another question is how do I set the duration to Indefinitely?

[RobBiddle]

This is definitely a major bug in the 2.0.0.0 implementaion of xScheduledTask
I too am generating MOFs for systems in multiple time zones and this issue completely breaks the xScheduledTask resource, it can't be used as-is in a multi timezone scenario.

Either a switch to use the local timezone needs to be added as mentioned by Zuldan, or the resource parameters need to be changed to [String] or [Int] values and interpreted during the DSC run on the client

[PlagueHO]

This definitely sounds like a high priority problem. I was planning on doing some more work on this module this weekend, so ill make this a top priority. Thank you both for raising this.

[RobBiddle]

I'm sure you already have a good idea how to fix this, but in the off-chance that this is helpful, here's some things I noticed:

It looks like the New-ScheduledTaskSettingsSet cmdlet actually expects [System.TimeSpan] objects, whereas this DSC resource is using [System.DateTime] for its own parameters related to delay/duration/interval.

It looks like the only parameter that will need to be [DateTime] is the -AT parameter for New-ScheduledTaskTrigger, so the StartTime value for specifying the DSC resource configuration of a task is probably the only thing that needs to be adjusted to account for differing time zones and then the [TimeSpan] objects should work for all of the various delay/duration/interval parameters without needing to change a lot of code.

[PlagueHO]

@RobBiddle - that is great info, and +++ helpful, thank you! I'll make this change tonight (it's Saturday AM here)/tomorrow. If you're up for running it through a couple of tests after I've completed the change/unit tests/integration tests etc that would be very helpful.

[PlagueHO]

Sorry I haven't completed this one. I'm working on it this week - just been a bit of a lot on at work so haven't had the time to put into it yet. Definitely this week though.

[Zuldan]

@PlagueHO no worries. Appreciate you looking at this issue.

[RobBiddle]

@PlagueHO Sorry I wasn't available over the weekend; I was out of town for the solar eclipse. I'd be happy to test your changes when they're ready.

[PlagueHO]

Being a big supporter of TDD I've managed to create some failing tests for this scenario so I should be able to implement one of the suggested solutions. I am leaning towards @Zuldan 's solution of adding the UseLocalTime parameter because of it not requiring a breaking change. Will post an update soon.