Policy or task runs on wrong machines or outside its schedule

Products

IT Management Suite

Issue/Introduction

A Software Delivery policy, Patch Management policy, or task executes on machines it should not target, runs outside its scheduled maintenance window, or repeats when it should not. In some cases the policy or task no longer exists in the SMP Console after the incident, making the audit trail harder to reconstruct.

This article covers what to collect and where to look to identify whether the cause was a configuration problem, a detection or applicability rule failure, a human change, or a product behavior issue. It applies to Managed Delivery policies, Software Update policies, and Task Server tasks in ITMS 8.x on-premise.

Common scenarios:

software deployed unexpectedly
policy ran outside maintenance window
task targeted wrong servers
who deleted a policy
managed delivery ran without consent
detection rule not working
SWD loop
task repeating after reboot
nextjobindex stuck

Failures covered by this article fall into three categories:

Scenario	Description
Wrong-target failure	The policy ran on machines outside its intended scope. Cause is usually a target filter, applicability rule, or detection rule problem.
Wrong-time failure	The policy ran outside its schedule or restriction window. Cause is usually a schedule misconfiguration, a policy being inadvertently enabled, or the Default Software Update Plug-in (DSUP) being active unexpectedly.
SWD loop after restart	A specific job within a multi-job Managed Delivery policy repeats after every reboot because the nextjobindex value in the client task data does not advance past a given step.

Symptoms

Wrong-target failure

Software installs on machines not in the intended target group.
A policy that has been stable for months begins triggering installs on machines where the software is already installed.
Filters or collections that previously scoped the policy correctly stop doing so.
Detection rules fail to recognize a pre-existing installation, causing repeated install attempts.

Wrong-time failure

A policy or task executes during production hours or outside the defined maintenance window.
Servers reboot during working hours on a policy that should be restricted from doing so.
The policy or task no longer appears in the SMP Console after the incident.

SWD loop after restart

A specific job within a multi-job Managed Delivery policy repeats after every reboot.
nextjobindex in the client-side task data remains on the same value after restart.
Manually setting nextjobindex to the next value and restarting allows the policy to continue.

Environment

IT Management Suite 8.x (on-premise)

Client Management Suite

Software Management Solution

Patch Management Solution

Symantec Management Agent

Resolution

How it works

A policy or task delivery follows this sequence:

The administrator creates or modifies a policy or task on the SMP server.
The SMP pushes the policy to targeted clients as a client policy XML file, stored locally at:

C:\Program Files\Altiris\Altiris Agent\Client Policies\

The Symantec Management Agent (SMA) evaluates the policy's applicability rule (can this software run on this machine?) and detection rule (is this software already installed?).
If both conditions are met—the software is applicable and not yet detected as installed—the agent executes the task.
Execution is recorded in TaskManagement\TaskHistory on the client and reported back to the SMP as an NSE.

Recommendations

Step 1 — Identify which failure scenario applies

Determine whether the issue is a wrong-target failure, a wrong-time failure, or a SWD loop. This determines which artifacts to collect first.

If the policy or task still exists in the SMP Console, check Properties → Audit tab immediately. This tab shows when the item was last modified and by whom. It is unavailable once the item is deleted.

Figure 1 — Policy Properties → Audit tab. Check this immediately while the policy still exists.

Step 2 — Collect reactive investigation artifacts

Collect these artifacts as close to the incident time as possible. Log data can be overwritten by subsequent activity.

Server-side (SMP)

NS logs from the time of the incident:

C:\ProgramData\Symantec\SMP\Logs\

Server-side policy XML:
In the SMP Console, right-click the policy → Export.
For Managed Delivery policies, also right-click each participating software component → Detailed Export. This exports the complete collection of items associated with each software component and is required to reproduce the policy behavior in a test environment. Tasks referenced in the policy are included automatically; do not export them separately.

Figure 2 — Detailed Export options for each software component participating in the policy.

Figure 3 — Detailed Export dialog. Select all applicable options shown.

Client-side (affected machines)

Agent logs from the time of the incident:

C:\ProgramData\Symantec\Symantec Agent\Logs\

Client policy XML (only useful if the policy is still active on the client—it is removed once the policy is retracted):

C:\Program Files\Altiris\Altiris Agent\Client Policies\

Task history folder (collect as a zipped archive):

C:\Program Files\Altiris\Altiris Agent\TaskManagement\TaskHistory\

For Managed Delivery policies — Software Management data folder (zipped; exclude SoftwareCache_v2.xml if it is large):

C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\data\

Client-side active SWD policy file:

C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\AeXSWDPolicy.xml

Note:
AeXSWDPolicy.xml shows the policy the agent is currently acting on. If the policy was deleted server-side but this file still references it, the client may continue executing it until the next agent configuration refresh.

For patch policies — patch install log:

C:\Program Files\Altiris\Altiris Agent\Agents\PatchMgmtAgent\InstallLog.csv

For patch policies where detection rules appear to be failing — patch assessment log:

C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\

{6D417916-467C-46A7-A870-6D86D9345B61}\cache\STPatchAssessment.log

Step 3 — Check policy configuration

Review the following in the SMP Console:

Target definition: Confirm the resource collection or filter used as the policy target. Check for unintended inclusions or missing exclusions.
Applicability rule: Confirm the rule correctly restricts deployment to machines where the software is applicable. A rule that is too broad will match machines outside the intended scope.
Detection rule: Confirm the rule correctly identifies machines where the software is already installed. A detection rule that is too narrow, or that uses a static file path that differs by OS version, will fail to recognize an existing installation and cause repeated install attempts.

Step 4 — Query the database for deleted or modified items

If the policy or task no longer exists in the SMP Console, query Evt_NS_Item_Management to find deletion and modification events:

SELECT *

FROM Evt_NS_Item_Management

WHERE ItemGuid = '########-####-####-####-############'

AND Action = 'Delete'

Note:
Replace the GUID placeholder '########-####-####-####-############'with the actual GUID of the deleted item. The results include the timestamp and the process that performed the deletion. Whether an individual console user is identifiable depends on what was logged at the time of deletion.

To locate the item's GUID across all database tables, see Find all tables that contain a specific GUID (KB 171823).

Step 5 — Diagnose a SWD loop (task repeating after restart)

If a specific job within a multi-job Managed Delivery policy repeats after every reboot, the nextjobindex counter may not be advancing. Follow these steps:

Collect the TaskManagement\TaskHistory folder and the SoftwareManagement\data folder from the affected client (see Step 2).
Collect AeXSWDPolicy.xml from the affected client (see Step 2).
Collect the server-side policy XML and the Detailed Export for each software component in the policy (see Step 2).
Review the TaskHistory entries for the repeating job. Confirm the job is completing and a restart is occurring.
Check whether nextjobindex remains at the same value after restart. If it does, the counter is not advancing.

Workaround:
As a temporary measure, manually set nextjobindex to the correct next value and restart the machine to allow the policy to continue. Confirm the root cause before applying this in production.

Step 6 — Enable auditing to capture future incidents

Enable Item Trackers

Item Trackers provide in-depth auditing of changes made through the SMP Console. See Using Item Trackers to audit/research who made changes in the Management Console (KB 173483) for setup steps, including a Samples.xml file covering patch and software management trackers.

Item Trackers are found at: Settings → Notification Server → Internals → Item Tracking → Item Trackers

Best practice: select IIS Process (w3wp) under Modules in the Tracking Filter to capture changes made by users in the console.
Do not store Item Tracking data on the system drive.

Increase client-side log verbosity

Add the following registry values on affected client machines. Restart the Symantec Management Agent service after making changes.

[HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Event Logging\LogFile]

"Severity"=dword:000000ff ; hex FF = verbose logging

"MaxFiles"=dword:000000c8 ; decimal 200 = number of log files retained

"MaxSize"=dword:000007d0 ; decimal 2000 = size of each log file (KB)

After troubleshooting, revert: set Severity to 7 (hex), and delete MaxFiles and MaxSize.

Increase SMP server log verbosity

Add or confirm the following registry values on the SMP server. Restart the Altiris Services service after making changes.

Note:
Keeping extra logging enabled for a long time on the SMP server adds CPU and memory overhead.

[HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\eXpress\Event Logging\LogFile]

"Severity"=dword:000000ff ; hex FF = verbose logging

"MaxFiles"=dword:0000012c ; decimal 300 = number of log files retained

"MaxSize"=dword:00000bb8 ; decimal 3000 = size of each log file (KB)

After troubleshooting, revert all three keys to their previous values. If they did not previously exist, delete them.

Step 7 — Default Software Update Plug-in policy (DSUP) considerations

If patches were pushed to servers outside their maintenance window and no custom policy appears responsible, check whether the DSUP was inadvertently enabled.

The DSUP is active by default. If it is left enabled between patching cycles, it can push patches to servers that are in scope before their scheduled maintenance period begins. There is no way to determine who enabled the DSUP after the fact unless Item Trackers were configured beforehand.

To prevent recurrence:

Disable the DSUP between patching cycles.
If Windows System Assessment scans are needed while the DSUP is off, set the DSUP installation schedule far in the future so scans run without triggering installs.
Configure Item Trackers on the DSUP (and any DSUP clones) to capture future enable/disable events. See Using Item Trackers to audit/research who made changes in the Management Console (KB 173483).

Verification

Confirm the root cause has been identified when:

You can trace the triggering event to a specific policy state, rule evaluation, or user action in the logs, audit tab, or Evt_NS_Item_Management query results.
The detection or applicability rule, when re-evaluated against the affected machines, produces the expected result.
For SWD loop cases: nextjobindex advances correctly on a test machine after the root cause is addressed.
Item Trackers are in place to capture any recurrence.