---
os_patching_reboot: true
os_patching_windows_categories:
  - SecurityUpdates
  - CriticalUpdates
  - UpdateRollups
  - DefinitionUpdates
  - Updates
os_patching_reboot_timeout: 600
os_patching_reboot_delay_minutes: 0
os_patching_reboot_message: 'AIM maintenance: operating system patching requires a reboot.'
os_patching_rescan_after_reboot: false

os_patching_reboot_delay_minutes is shared across Windows/Linux so the public setting has one meaning. Linux reboot scheduling is minute-granular. Windows converts the value to seconds; a zero-minute reboot still observes the Windows reboot module's minimum delay. The message is displayed by the native reboot module when AIM actually initiates a reboot.

When automatic reboot is disabled, newly installed updates can legitimately leave reboot_deferred: true while the patch run itself succeeds. A later run that detects the already-pending reboot fails before starting new patch work and tells the operator to reboot manually or enable the reboot option.

Structured result integration

Current reporting behavior and field semantics are specified in scripts/docs/OPERATION_RESULTS.md. Runbook-owned filters normalize only reviewed fields; arbitrary package-manager/module results are not exported.

Windows patch waves

Windows uses the native ansible.windows.win_updates batch/orchestration path for the currently selected categories. AIM calls it with reboot: false, so Windows Update may process all updates in that current wave while AIM retains control over the reviewed reboot message, delay and continuation policy. AIM does not create a per-update install queue.

The default os_patching_rescan_after_reboot: false stops the run after any AIM-performed reboot boundary; a new operator-approved run discovers the next wave. Set it to true only when the operator explicitly wants AIM to start another wave after reboot. A deferred reboot always stops the run.