Scheduled task always has one hour added for the next run.

Woody Chiu at RASI 226 Reputation points
2024-03-06T17:34:33.4533333+00:00

I have two PS scripts created. They use New-ScheduledTask and corresponding commands to create two scheduled tasks. The script worked and scheduled tasks are created fine. However, I noticed that next run time always with one more hour added on top of the set time. The tasks are scheduled to run at 12:30am and 12:45am in two different scripts, and both their Next Run Time shown as 1:30am and 1:45am instead of keeping the set times in the scripts. Tried to run the scripts to remove and add the scheduled tasks multiple times, and still the same. Any idea, why?User's image

I will include one of the scripts here. Hope you can help find the trick. Please see the following.

Set the path for the log file

$logFilePath = "C:\IT\Intune-Script.log"

Check if the scheduled task already exists

$scheduledTaskName = "SFC Scan Weekly"

$existingTask = Get-ScheduledTask -TaskName $scheduledTaskName -ErrorAction SilentlyContinue

if ($existingTask -ne $null) {

# Task already exists, so attempt to remove it

try {

    Unregister-ScheduledTask -TaskName $scheduledTaskName -Confirm:$false -ErrorAction Stop | Out-File -FilePath $logFilePath -Append

    Write-Output "Existing task '$scheduledTaskName' successfully removed."

} catch {

    Write-Output "Error removing existing task '$scheduledTaskName': $_" | Out-File -FilePath $logFilePath -Append

}

}

Set Trigger, Task, Settings

$SFCTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Wednesday -At 00:30

$SFCAction = New-ScheduledTaskAction -Execute "SFC" -Argument "/SCANNOW"

$SFCSetting = New-ScheduledTaskSettingsSet -Compatibility Win8 -AllowStartIfOnBatteries -StartWhenAvailable -DontStopIfGoingOnBatteries

$SFCTask = New-ScheduledTask -Trigger $SFCTrigger -Action $SFCAction -Settings $SFCSetting -Description "SFC Scan Weekly"

Create/Register Scheduled Task

try {

Register-ScheduledTask -TaskPath RASULC -TaskName $scheduledTaskName -InputObject $SFCTask -User "NT AUTHORITY\SYSTEM" -ErrorAction Stop | Out-File -FilePath $logFilePath -Append

Write-Output "Scheduled task '$scheduledTaskName' successfully registered."

} catch {

Write-Output "Error registering scheduled task '$scheduledTaskName': $_" | Out-File -FilePath $logFilePath -Append

}

Windows for business | Windows Server | User experience | PowerShell
Microsoft Security | Intune | Other
0 comments No comments
{count} votes

4 answers

Sort by: Most helpful
  1. Michael Taylor 60,326 Reputation points
    2024-03-06T19:50:52.5333333+00:00

    The time is stored in UTC so a conversion happens when you give it a local time. Just a guess but validate that the stored UTC time is correct for the machine that is registering the task.

    New-ScheduledTaskTrigger -Weekly -DaysOfWeek Wednesday -At 00:30
    

    It should dump the StartBoundary which is what controls the time to execute. It should be in UTC.


  2. Rich Matheisen 47,901 Reputation points
    2024-03-06T20:34:37.1733333+00:00

    @Michael Tayler is correct you need to adjust the time from your local time to UTC.

    Something like this should work for you:

    $SFCTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Wednesday -At ((get-date "00:30") + (Get-TimeZone).BaseUtcOffset).ToString('HH:mm')
    

    If you're in the Eastern Time Zone, for example, that would put the scheduled time at 19:30 UTC (a -5 hour offset).


  3. Rich Matheisen 47,901 Reputation points
    2024-03-07T16:32:33.8733333+00:00

    Give this a try:

    $Date = Get-Date -Date "00:30"  # You can be more precise by providing the year/month/day and hour, seconds, and milliseconds if necessary
    $Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date -Day 1 -Month 1 -Year 1 -Hour 0)    # the place-holder date will be replaced below
    $Trigger.StartBoundary = (Get-Date -Date $Date -Format 'HH:mm') # time represents LOCAL time
    

    If that doesn't turn off the synchronization then you may have to resort to guerilla tactics and modify the XML that represents the finished scheduled task (not a difficult thing to do) by removing the leading "T" in the "StartBoundary" property. Or, if you don't want to go that far, you can also use the command line "schtasks" to provide the StartBoundary value.


  4. Paulius Petkevičius 0 Reputation points
    2025-04-01T06:54:45.9666667+00:00

    I faced the issue with "Synchronize across time zones" option while registering scheduled task, which has to run under group managed service account. You cannot modify scheduled task via GUI mmc (to uncheck time zones tickbox) when using GMSA, so Powershell is (one of?) the way to go. Using hints from this thread I modified StartBoundary property of the trigger object. As I found StartBoundary is simply a string which can be easily overwritten. As written in the mentioned thread, if you want 'Synchronize across time zones' to be unchecked: you must use a time value for start boundary that is as per the local time that you want the task to run and does not end with the time indicator Z.

    $arg = "-ExecutionPolicy Bypass -File C:\custom_scripts\myscript.ps1";
    $action = New-ScheduledTaskAction -Execute pwsh.exe -Argument $arg;
    
    $triggers = @(
        $(New-ScheduledTaskTrigger -At (Get-Date $(Get-Date "08:05").ToLocalTime() -Format "HH:mm") -Daily),
        $(New-ScheduledTaskTrigger -At (Get-Date $(Get-Date "13:15").ToLocalTime() -Format "HH:mm") -Daily)
    )
    foreach ($trigger in $triggers)
    {
        if($trigger.StartBoundary.EndsWith("Z"))
        {
            $trigger.StartBoundary = $trigger.StartBoundary.Substring(0,$trigger.StartBoundary.Length-1);
        }
    }
    
    $principal = New-ScheduledTaskPrincipal -UserID domain\gmsa_username$ -LogonType Password;
    Register-ScheduledTask -TaskName 'MyTask' -TaskPath '\CustomTasks\MyTask' -Action $action -Trigger $triggers -Principal $principal;
    
    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.