In one environment, administrators observed that some systems restarted outside their expected maintenance window.
The Windows Event Log showed that the Altiris Agent (Symantec Management Agent) initiated an unexpected restart on March 9 2026 at 2:25 AM, even though the legitimate reboot had already occurred during the scheduled software update window on March 7 2026 at 6:30 PM.
Note: The dates and times are used as examples based on the original report of this issue.
ITMS 8.7.x, 8.8.x
Software Management / Managed Delivery Policies
Investigation of agent logs and policy execution history indicated that the reboot was triggered by a Managed Delivery Policy execution that incorrectly became “due” after the Daylight Saving Time (DST) clock change.
Note: Software Management policies may also run outside their original schedule under certain conditions (for example if the Symantec Management Agent service was stopped or the scheduled execution was missed). This behavior is expected product behavior. In this case, however, the execution was related to the DST time adjustment.
| Timestamp | Event |
|---|---|
| 03/07/2026 18:30 | Scheduled reboot executed successfully |
| 03/08/2026 02:00 | Daylight Saving Time change |
| 03/09/2026 02:24:49 | User logon detected |
| 03/09/2026 02:24:59 | Managed Delivery Policy executed |
| 03/09/2026 02:25:18 | Reboot triggered |
Improvements have been implemented to ensure that when a timezone change is detected, the agent adjusts internal scheduling data for Managed Delivery Policies to prevent unintended re-execution.
Additional investigation identified that the behavior is related to how the agent evaluates policy schedules when system timezone changes occur (such as during Daylight Saving Time transitions).
This issue has been targeted for a fix under ITMS 8.8.2 release. Improvements were introduced in the Software Management Framework (SMF) Agent to handle timezone changes more accurately.
Avoid scheduling critical policies shortly "before" the Daylight Saving Time change window.
Policies scheduled "after" the DST change are not affected.
Additionally, if a policy must execute strictly at its scheduled time, configure the schedule to use the Exact execution modifier ("Computer is available at the exact scheduled time" checkbox) in the schedule advanced settings. This ensures the policy will only run at the exact scheduled time and will not execute later if the schedule is missed.
If production systems have strict reboot windows, consider the following safeguards.
On the SMP Console:
Navigate to
Manage > Policies > Software > Managed Delivery
Locate the affected Managed Delivery Policy.
Review the Schedule section.
Verify:
No unexpected additional schedules exist.
Scrollbars in the schedule view do not hide additional triggers.
Check the reboot task configuration.
Navigate to:
Locate the associated task.
Verify the conditions:
| Setting | Expected Value |
|---|---|
| Trigger | Only after patch installation |
| Schedule | Controlled maintenance window |
| Run Conditions | Not triggered by policy reevaluation |
On affected endpoints verify the policy scheduling metadata.
Check the directory:
Each policy has a file:
If the issue reoccurs, collect the following from the affected client machine.
| Data | Location |
|---|---|
| Task execution history | C:\Program Files\Altiris\Altiris Agent\TaskManagement\TaskHistory |
| Software Management data | C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\data |
| Software Delivery policy data | C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\AeXSWDPolicy.xml |
| Client policies | C:\Program Files\Altiris\Altiris Agent\Client Policies |
Also export:
Windows Event Logs
Application
System
After the DST event and policy refresh cycles:
Verify policies only execute during scheduled windows.
Confirm no unexpected entries appear in Agent UI > Task Status tab > Task History
Check Event Viewer for unexpected reboot triggers.
When a timezone change is detected, the SMF Agent performs an internal adjustment of policy scheduling data.
The agent:
Relevant policy data is stored under:
The following log entries may be observed after the fix when a timezone change occurs:
Detected timezone change. About to adjust the policies' schedule check dataAdjusting timezone for Policy {GUID}Schedule checks were adjusted for policy {GUID}Adjusted X policiesPolicy {GUID} is running. Will not adjust schedule check timezone
Schedule checks were adjusted for policy {GUID} ... EXAMPLE POLICY NAME