| Previous | Next |
| SCHED_E_TASK_NOT_UBPM_COMPAT | QUERY_E_FAILED |
SCHED_E_DEPRECATED_FEATURE_USED
The task definition uses a deprecated scheduler feature
SCHED_E_DEPRECATED_FEATURE_USED is the failure HRESULT 0x80041330 (-2147216592 as a signed 32-bit value). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and its facility-specific code is 0x1330. AllStat describes the result as “The task definition uses a deprecated feature.”
Contract boundary
The definition can still be structurally valid XML while relying on a retired feature. Microsoft documents send-email and show-message actions as deprecated in the Windows 8 Task Scheduler changes, so migration must preserve the intended notification behavior through a supported action. In practical terms, this result is returned when task registration or validation recognizes a feature that the target Windows release no longer accepts for the requested scheduler behavior. Preserve it symbolically because a generic COM failure path loses its scheduler-specific recovery decision.
Conditions that produce it
- A task imported from an older system still contains a SendEmail action.
- The definition uses ShowMessage to display an interactive notification.
- An installer emits an old schema fragment copied from a legacy task template.
- Migration software preserves deprecated actions without converting their operational behavior.
- A compatibility setting selects a path where the deprecated feature cannot be registered.
Rank these explanations for it by matching them to the exact method, target and scheduler state observed at failure time.
Telemetry that matters
- Complete Actions collection and task XML from the failing registration request.
- Source operating system and product version that originally created the task.
- The business purpose of each deprecated notification or interaction.
- Security context, network access and secret handling required by any replacement action.
- Target Windows version and registration API used by the installer.
The decisive question for it is not whether Task Scheduler works in general, but which object, service state, compatibility rule or execution instance owned the failed operation. Before reacting to this result, collect evidence rather than restarting services, rewriting task XML or changing security settings.
Investigation workflow
- Identify the exact deprecated node instead of removing unrelated task settings.
- Document what the legacy action was expected to deliver, to whom and under which failures.
- Replace it with an Exec or COM handler action that invokes a maintained notification component when appropriate.
- Move credentials and server configuration out of task XML and into a secure supported store.
- Test both successful notification and failure handling under the task principal on the target Windows version.
Safe remediation
Retry after replacing the deprecated feature and registering a validated definition. Avoid merely deleting the action if notification is part of the operational contract. A replacement script or executable must have explicit ownership, logging, timeout and credential behavior. The owner of the higher-level workflow should define whether this result is terminal, retryable after a state change, or converted into an administrative action.
Avoid the wrong conclusion
This code does not imply that all Task Scheduler 2.0 features are deprecated or that the task action executable is obsolete. It points to a feature in the task definition, and the exact node must be identified from that definition. Logging only the decimal value without task path, method and target computer is insufficient to explain this result.
How to distinguish related results
SCHED_E_TASK_NOT_UBPM_COMPAT can arise from a feature combination rejected by the unified engine. It focuses on a retired feature in the definition itself, such as legacy email or message actions.
Example from operations
A server migration imports a task that emails an operator after backup. Registration reports a deprecated feature. The team replaces SendEmail with an Exec action calling its supported notification service, stores credentials outside XML and verifies alert delivery and retry behavior. A regression test should reproduce it, assert the code-specific evidence, then change only the decisive condition and verify the expected recovery.
Official Microsoft references
- Microsoft: Task Scheduler error and success constants
- Microsoft: Task Scheduler feature changes
- Microsoft: Task Scheduler schema elements
- Microsoft: task definitions and APIs
Looking for a different code? Search another status or error code.