Windows Server 2022 Task Scheduler saves UseUnifiedSchedulingEngine=true despite registering false

Question

Windows Server 2022 Task Scheduler saves UseUnifiedSchedulingEngine=true despite registering false

Hyuck Jun Ko 20

Environment: Windows Server 2022 Datacenter, build 20348.5622; Windows PowerShell 5.1; Task Scheduler COM API (Schedule.Service).

I am trying to register a task with UseUnifiedSchedulingEngine=false. Before registration, both the in-memory TaskDefinition property and its XML text show false.

I tested two isolated tasks:

TASK_UPDATE (flag 4) on an existing disabled task.
TASK_CREATE (flag 2) for a new disabled task with no triggers and a harmless action.

Both RegisterTaskDefinition calls returned without an error. However, the returned task object and a separate fresh GetTask readback both show UseUnifiedSchedulingEngine=true in the effective setting and saved XML. A separate RegisterTask XML update showed the same behavior. No task was enabled or run.

Is changing false to true an expected or known registration behavior on this Windows Server 2022 build? Which setting or condition controls it? Is there a supported way to register and retain false?

The setting matters because one production task uses a daily CalendarTrigger repeated every 5 minutes for 2 hours. I have kept that task disabled while investigating.

0 comments

Answer accepted by question author

Taki Ly (WICLOUD CORPORATION) 5,630 Microsoft External Staff Moderator

Hello @Hyuck Jun Ko ,

Thank you for the detailed and well-isolated report. I reproduced the behavior you describe and reviewed the relevant Microsoft documentation. Below is what I found.

I reproduced the behavior by running the same sequence you did (Windows PowerShell 5.1, Schedule.Service COM API, elevated) on Windows 11 build 10.0.26200, which shares the Task Scheduler service codebase with Windows Server 2022. I tested four paths:

RegisterTaskDefinition with TASK_CREATE (2): new disabled task, no triggers, harmless cmd.exe /c exit 0 action
RegisterTaskDefinition with TASK_UPDATE (4) on that task
RegisterTask with raw XML containing <UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine>
Same as (1) but with a daily CalendarTrigger repeating every 5 minutes for 2 hours (PT5M / PT2H), matching your production task shape

In every case the in-memory TaskDefinition and its XmlText showed false before registration, all calls returned S_OK, and both the returned IRegisteredTask and a fresh GetTask readback showed UseUnifiedSchedulingEngine = true in the effective setting and the stored XML. So this is not specific to build 20348.5622, not caused by the update path, flags, or trigger configuration, and not something in your code. The service rewrites the value to true on registration.

Below are my answers to your three questions.

Regarding whether changing false to true is an expected or known registration behavior on this build: it is consistent behavior of the Task Scheduler service on current Windows builds (I observed identical results on Windows 11), so it is not a regression unique to your build. However, I could not find it documented anywhere:

UseUnifiedSchedulingEngine (settingsType) Element still states the default is false.
ITaskSettings2::UseUnifiedSchedulingEngine describes it as read/write with no remarks about it being overridden.
MS-TSCH 3.2.5.4.2 SchRpcRegisterTask only describes the server modifying the Principal node of the submitted XML; it does not describe altering Settings.
MS-TSCH Appendix B: Product Behavior has no note about this setting.

I therefore cannot point you to an official statement that it is by design; it is undocumented behavior as far as the public docs go.

Regarding which setting or condition controls it: none that is exposed. I did not find any task setting, registration flag, registry value, or Group Policy that preserves false. The service applies true unconditionally regardless of TASK_CREATE/TASK_UPDATE, COM vs. XML registration, or trigger content.

Regarding whether there is a supported way to register and retain false: not on current builds. The unified scheduling engine is effectively the only engine in use on Windows 10 / Server 2016 and later.

I would also like to address your production task (daily CalendarTrigger, repeat every 5 minutes for 2 hours). If the concern comes from the What's New in Task Scheduler page, which lists "Repetition patterns for calendar triggers" among features the unified engine did not support, please note that list applies to Windows 7 / Server 2008 R2. The Windows 8 section of the same page documents that the unified engine was extended, and in my test (4) a daily trigger with Repetition.Interval = PT5M, Repetition.Duration = PT2H registered normally with the unified engine. You should be able to re-enable that task safely. If you see any scheduling anomaly after enabling it, check the Microsoft-Windows-TaskScheduler/Operational log for the specific trigger/launch events and share the details with me.

Since this is a community forum, my scope here is limited to public documentation and what I can reproduce myself. I don't have access to the Task Scheduler service internals or the product group's design decisions, so I can't confirm whether this behavior is intentional or give you an official statement on it. If you need an authoritative ruling, a Microsoft Support case is the right route, as that goes through a channel that can reach the product team directly. Go to https://support.microsoft.com/contactus, sign in, and select Server products; you will be redirected to the Microsoft Engage Center, where you can create a support request for Windows Server. Include the build number, your test script, and the before/after XML. You can also use the Feedback control on the right side of the document, just below the In** this **article section, to report the stale default="false" statement so the documentation can be updated.

Hope these information help! If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Hyuck Jun Ko 20 Reputation points

2026-09-28T09:07:28.69+00:00

Thank you for reproducing this. Is the conclusion that false cannot be retained confirmed specifically for Windows Server 2022 build 20348.5622? Is there an official Microsoft reference or a supported way to validate the behavior of our repeated daily task before enabling it?
RLWA32 52,931 Reputation points

2026-09-28T09:55:18.0533333+00:00

@Hyuck Jun Ko To add some additional background to the issue -- The scheduled task is configured for what version of Windows? And does changing that setting make a difference?
Hyuck Jun Ko 20 Reputation points

2026-09-28T10:02:16.6533333+00:00

The host is Windows Server 2022 Datacenter, build 20348.5622. The existing disabled production task reads back as Task XML version 1.4, with TaskDefinition.Settings.Compatibility = 4 (TASK_COMPATIBILITY_V2_2). Its saved XML and effective UseUnifiedSchedulingEngine value are both true.

A separate isolated disabled diagnostic task reads back as XML version 1.3, with Compatibility = 3 (TASK_COMPATIBILITY_V2_1). It also retained true. These are different tasks, so this is not a controlled test in which I changed only the compatibility setting on one task. I have not enabled or run the production task.

Would you expect a particular “Configure for” compatibility value to retain UseUnifiedSchedulingEngine=false on this Server 2022 build? Also, what isolated test would you recommend to verify actual daily PT5M/PT2H launches before enabling the production collector task?
RLWA32 52,931 Reputation points

2026-09-28T10:11:53.2133333+00:00

Would you expect a particular “Configure for” compatibility value to retain UseUnifiedSchedulingEngine=false on this Server 2022 build?

@Hyuck Jun Ko I don't have any specific expectations or recommendations. I was just wondering if varying this setting would influence the results of your testing.
Taki Ly (WICLOUD CORPORATION) 5,630 Reputation points Microsoft External Staff Moderator

2026-09-28T10:42:39.3933333+00:00
Hi @Hyuck Jun Ko ,

On your first question: no, I did not test on Windows Server 2022 build 20348.5622 itself, so I cannot claim the result is confirmed for that specific build. What I have is your observation on that build through three registration paths, and my own reproduction on Windows 11 build 26200, which showed the same outcome. The two results are consistent, but they are still only two data points on two different builds. If you need a statement that applies to 20348.5622 specifically, that would have to come from Microsoft Support rather than from me.

Since the compatibility level was raised above, I also tried varying it on my side, in case it is useful. I registered the same task definition (disabled, daily trigger, PT5M repetition for PT2H, UseUnifiedSchedulingEngine=false) six times with Settings.Compatibility set to 1 through 6. In my test, all six read back as UseUnifiedSchedulingEngine=true. Values 1 and 2 also came back as 3 (TASK_COMPATIBILITY_V2_1) after registration, while 3 through 6 were kept as set. So at least on my machine the "Configure for" level did not preserve false, which seems to line up with the two values you reported (3 and 4). I have not tested this on Server 2022, so please treat it as one more observation rather than a rule.

On your second question: I could not find an official Microsoft reference that describes a validation procedure for this, and as far as I can tell there is no "dry run" mode in the Task Scheduler API. What I would do instead is register a separate canary task that mirrors the production task's schedule with a harmless action, and check its actual launches in the Task Scheduler event log before touching the production task. Something like:

Make sure the operational log is enabled: Event Viewer > Applications and Services Logs > Microsoft > Windows > TaskScheduler > Operational > Enable Log (or wevtutil sl Microsoft-Windows-TaskScheduler/Operational /e:true). It is off by default on many systems.

Register a new disabled task in a test folder with the same trigger shape as production: daily CalendarTrigger, Repetition.Interval = PT5M, Repetition.Duration = PT2H, and the same StopAtDurationEnd, MultipleInstancesPolicy, ExecutionTimeLimit, principal and logon type as the production task. Set StartBoundary a few minutes ahead. For the action, use something that leaves a trace, for example cmd.exe /c echo %DATE% %TIME% >> C:\Temp\canary.log.

Enable it and let it run for 20 to 30 minutes.

Compare the timestamps in canary.log against the expected 5-minute cadence, and look at the Operational log for the corresponding events. You should typically see 107 (trigger fired), 100 (task started), 129 (action process created) and 102 (task completed) per run; anything like 101 (launch failure), 111 (terminated) or 322/324 (instance policy) would be worth looking into.

If the cadence and events look right, delete the canary task, enable the production task, and keep an eye on the same events for the first day.

This does not prove anything about which engine is used internally, but it does verify the part that matters for your collector, which is whether the repetition pattern launches as expected on your host.
RLWA32 52,931 Reputation points

2026-09-28T12:05:27.3433333+00:00

@Hyuck Jun Ko I'm using Win10 22H2. The task scheduler type library shows that the ITaskSettings3 interface also contains methods to get/set the task compatibility property and also to use or not use the unified scheduling engine. Maybe that makes a difference since the initial post referred to ITaskSettings2?

1 additional answer

Your answer

Hyuck Jun Ko 20 Reputation points

2026-09-28T09:07:28.69+00:00

Thank you for reproducing this. Is the conclusion that false cannot be retained confirmed specifically for Windows Server 2022 build 20348.5622? Is there an official Microsoft reference or a supported way to validate the behavior of our repeated daily task before enabling it?
RLWA32 52,931 Reputation points

2026-09-28T09:55:18.0533333+00:00

@Hyuck Jun Ko To add some additional background to the issue -- The scheduled task is configured for what version of Windows? And does changing that setting make a difference?
Hyuck Jun Ko 20 Reputation points

2026-09-28T10:02:16.6533333+00:00

The host is Windows Server 2022 Datacenter, build 20348.5622. The existing disabled production task reads back as Task XML version 1.4, with TaskDefinition.Settings.Compatibility = 4 (TASK_COMPATIBILITY_V2_2). Its saved XML and effective UseUnifiedSchedulingEngine value are both true.

A separate isolated disabled diagnostic task reads back as XML version 1.3, with Compatibility = 3 (TASK_COMPATIBILITY_V2_1). It also retained true. These are different tasks, so this is not a controlled test in which I changed only the compatibility setting on one task. I have not enabled or run the production task.

Would you expect a particular “Configure for” compatibility value to retain UseUnifiedSchedulingEngine=false on this Server 2022 build? Also, what isolated test would you recommend to verify actual daily PT5M/PT2H launches before enabling the production collector task?
RLWA32 52,931 Reputation points

2026-09-28T10:11:53.2133333+00:00

Would you expect a particular “Configure for” compatibility value to retain UseUnifiedSchedulingEngine=false on this Server 2022 build?

@Hyuck Jun Ko I don't have any specific expectations or recommendations. I was just wondering if varying this setting would influence the results of your testing.
RLWA32 52,931 Reputation points

2026-09-28T12:05:27.3433333+00:00

@Hyuck Jun Ko I'm using Win10 22H2. The task scheduler type library shows that the ITaskSettings3 interface also contains methods to get/set the task compatibility property and also to use or not use the unified scheduling engine. Maybe that makes a difference since the initial post referred to ITaskSettings2?

Answer 1

Hi Hyuck Jun Ko,

Step you can follow which is given below to solve this problem

I would first avoid changing the production task and test the behavior with a sperate disabled task.

Register a basic task with UseUnifiedScheduleingEngine=false and verify whether it remains false after registration.
Add the CalenderTrigger and test again.
Finally, add the %-minute repetition (PT5M for PT2) and check the XML after registration.
Export the registered task using using Export-ScheduledTask and confirm whether UseUnifiedScheduleingEngine has actually changed to true.
Check Event Viewer -> Micrsoft ->WIndows -> TaskScheduler -> Operational for any registration or compatibility events.
Also verify the server 2022 patch level and reproduce the test on the latest approved build

The key point is that Microsoft documents limitation with the Unified Scheduling Engine, including repetition pattern for Calendar triggers. SO i would first determine whether the value changes only when the repetition is added. if it does, that would point toward a compatibility/ registration issue rather than a general task Scheduler problem.

I would keep the production task disabled until this is confirmed

Thanks