What does HRESULT 0x80045394 (FSRM_E_FILE_MANAGEMENT_JOB_INVALID_CONTINUOUS_CONFIG) mean?

 
Previous Next
FSRM_E_CANNOT_REMOVE_READONLY FSRM_E_LEGACY_SCHEDULE

FSRM_E_FILE_MANAGEMENT_JOB_INVALID_CONTINUOUS_CONFIG

FSRM_E_FILE_MANAGEMENT_JOB_INVALID_CONTINUOUS_CONFIG is the failure HRESULT 0x80045394 (signed decimal -2147200108, unsigned decimal 2147767188). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0x5394.

The continuous file-management job configuration is invalid

This HRESULT rejects a real-time or continuous file-management job whose configuration includes features that require scheduled evaluation. Microsoft documents two restrictions: a continuous job cannot use conditions based on creation, last-modified, or last-accessed time, and it cannot define notifications. The failure is deterministic configuration validation, not a transient service problem.

AllStat records the official condition as: “A continuous file management job cannot have conditions based on the file's last accessed/modified or created times and cannot define any notifications.” The wording should be interpreted at this FSRM stage, not as a generic file-system or COM failure.

Where the failure boundary lies

Continuous processing reacts to file activity in the background. Age conditions depend on time passing even when no file event occurs, and notification periods depend on scheduled future dates. Those semantics belong to scheduled file-management jobs, so adding them to a continuous job creates a contract the engine cannot honor.

Likely causes to separate

  • The job sets Continuous while a condition references File.DateCreated.
  • A last-modified or last-accessed age condition remains after converting a scheduled job to continuous mode.
  • The job includes one or more notification objects while continuous execution is enabled.
  • An import or automation merge combines a continuous flag with legacy scheduled-job conditions.
  • PowerShell or WMI code reuses an existing job object without removing incompatible properties.

Evidence worth preserving

  • Export the complete job definition, including Continuous, Condition, Notification, Schedule, and action fields.
  • Record the exact cmdlet, WMI property update, or import operation that first returns the HRESULT.
  • List every condition property by canonical name rather than relying on localized display labels.
  • Compare the rejected definition with the last committed version to identify which mode or condition changed.

Diagnostic sequence

  • Decide whether policy intent is event-driven continuous processing or age-based scheduled processing.
  • For continuous mode, remove File.DateCreated, File.DateLastModified, and File.DateLastAccessed conditions.
  • Remove notifications from the continuous job; implement reporting or alerting through a separate supported mechanism.
  • If age and notification semantics are required, disable Continuous and provide a suitable schedule.
  • Commit the revised definition and retrieve it again to verify the server stored the intended mode.

Retry and recovery

There is no useful retry until the job definition changes. Split one mixed policy into separate jobs when both immediate classification-based action and age-based expiration are required. Test each job on a limited namespace and ensure the same file cannot receive conflicting actions from both policies.

What this HRESULT does not establish

The code does not mean the schedule object itself is corrupt and does not indicate that continuous classification is disabled globally. It says this file-management job combines unsupported properties.

Difference from nearby FSRM results

FSRM_E_LEGACY_SCHEDULE concerns an old serialized schedule that must be upgraded. This HRESULT concerns a current definition whose continuous-mode semantics are internally incompatible.

Practical scenario

An administrator converts a nightly stale-file job to continuous mode but leaves the “days since last modified” condition and owner notifications. The server rejects the update. The policy is divided into a scheduled expiration job for age checks and a separate continuous classification-based action.

Guidance for software and telemetry

Validate these combinations client-side before submitting the object, but still handle the server HRESULT because imports and concurrent edits can bypass local checks. Error messages should name each forbidden property rather than say only “invalid job.”

Official Microsoft references

Looking for a different code? Search another status or error code.