Prior to ITMS 8.8, administrators found it difficult to differentiate between multiple instances of the same task run within an Automation Policy (as well from a Job). Additionally, non-standard return codes from third-party scripts or applications often caused successful tasks to be incorrectly reported as failures. The absence of a cleanup utility for expired schedules also led to unnecessary database bloat and potential Windows Task Scheduler overhead on the Symantec Management Platform Server (SMP Server or Notification Server (NS)).
See what is new section for our ITMS 8.8 Release Notes
Avoiding possible confusion about meaning of "Automation Policies":
When we refer to "Automation Policies" in the context of the new ITMS 8.8 features (like Custom Naming of Task Instances), we are referring to the concept of a complex, multi-step workflow defined within the Jobs and Tasks section, which is formally represented in the console as a Client Job.
| Terminology Used | Console Object | Purpose/Context |
| Automation Policy (In this KB Context) | Client Job | A general term for a sequential workflow that executes multiple steps (tasks) on client computers, often involving conditional logic or specific step orders. We use this term conceptually to describe the complex task management scenario that the new 8.8 features address. |
| Client Job | Client Job (Direct Menu Option) | The specific object created under Manage > Jobs and Tasks that allows you to sequence multiple tasks (like Run Script, Copy File, Install Software) with conditional logic. |
| Automation Policy (TechDocs Definition) | Automation Policy (Specific Menu Option) | A different, distinct type of policy (found under Manage > Automation Policies) used primarily for Data Management, Compliance, or Ticket Integration. This policy type often focuses on server-side actions triggered by events or data criteria, rather than client-side task sequencing. |
In summary, in the context of the ITMS 8.8 features you referenced: The features—especially Custom Naming of Task Instances and Override Default Success Return Code—are designed for tasks sequenced inside a Client Job (which is what we were generally referring to as a multi-step "Automation Policy" in this KB). The ability to name a task instance is added when you use the New button inside a Client Job editor to add the task.
Your technical understanding of a formal Automation Policy (found under the Manage > Automation Policies node, which is used for data management and compliance) is completely correct.
ITMS 8.8
These issues were caused by limitations in previous ITMS versions' task framework:
Ambiguous Task Names (Automation Policies): The system did not provide an option to override the default task name when adding an instance to an Automation Policy, making it impossible to distinguish between them in the Job/Task history.
Inflexible Task Success Criteria: The Task Server defaulted to assuming a return code of 0 meant success. Many applications or scripts return non-zero codes (e.g., 3010 for reboot required) that are technically "successes" but were flagged as failures by ITMS.
Static File Copy Paths: The built-in Copy File/Folder task lacked the flexibility of script tokens, requiring complex, separate Run Script steps to handle dynamic paths (like targeting a specific user's desktop).
Scheduled Task Accumulation: Task schedules were retained in the CMDB and Windows Task Scheduler even after their last scheduled run, leading to unnecessary database size and potential performance drag on the NS.
ITMS 8.8 introduced (refer to Release Notes) several key features to resolve these challenges, making task management and troubleshooting simpler:
Custom Naming of Task Instances: Allows unique names for identical tasks inside a job, improving history tracking.
Token Support for Copy File/Folder: Enables dynamic pathing for file transfers, removing the need for pre-copy scripting.
Override Default Success Return Code: Provides the ability to define custom success codes, ensuring accurate job reporting.
Clean up Task Schedules Task: A new maintenance task to automatically remove old, expired task schedules, improving overall performance.
Here is the step-by-step guidance on how to use and validate the new Task Management features in ITMS 8.8.
This feature helps when a single Job or Automation Policy runs the same task multiple times with different parameters.
Create a New Client Job (Automation Policy Equivalent):
On the SMP Console, navigate to Manage > Jobs and Tasks.
Right-click a folder (e.g., "Test") and select New > Client Job.
Add a Task:
Open the newly created Client Job (e.g., "New Client Job 1").
In the Jobs / Tasks pane, click the New button above the flow diagram.
Select the task you want to add from the tree (e.g., Run Script).
Apply Custom Name:
Click on the task instance added to the job flow.
In the task configuration pane, locate the Name field (this is the editable title at the top of the task configuration).
Override the default name with a descriptive name, such as "Pre-Execution Check" or "Post-Deployment Cleanup."
(Insert screenshot of Client Job task instance with custom name override here)
Validation:
Run the Client Job on a test client.
Navigate to Manage > Jobs and Tasks and view the History of the job under the Task Status section.
Confirm that the Task Name column now shows your custom, unique names instead of the generic task title, simplifying status analysis.
This enhancement allows for dynamic path substitution using standard ITMS tokens, eliminating the need for script wrappers to handle user-specific file locations.
Create the Copy Task:
On the SMP Console, navigate to Manage > Jobs and Tasks.
Right-click a folder (e.g., "Test") and select New > Task.
In the Create New Task dialog, select Client Tasks > Deployment and click Copy File.
Use Tokens in Path:
In the Destination Path field, click the Token icon ($) and select a token, such as %USER_PROFILE_DIRECTORY% or %TEMP%.
Example: To copy a file to the currently logged-in user's desktop, the path might be: %USER_PROFILE_DIRECTORY%\Desktop\MyFile.txt.
Validation:
Run the task on a test client with a logged-in user.
Paths to Logs: The task execution log (found in the History of the task) will show the exact, expanded path used on the client.
Confirm the file was successfully copied to the dynamic destination specified by the token.
This is critical for applications that use non-zero return codes for successful states (like requesting a reboot).
Configure the Task:
Open any task that runs a program, install package, or script (e.g., Run Script or Install Software).
Access Advanced Settings:
Click on the Advanced tab of the task.
Click on the Task options tab (this is usually the default sub-tab).
Override the Code:
Check the box next to The task is succeeded if its return code is:
Enter the custom success return code (e.g., enter 3010 for a successful install requiring a reboot). You can enter multiple codes separated by a comma (e.g., 0, 1641, 3010).
Validation:
Run the task on a client that is expected to return the custom success code (e.g., the 3010).
View the Job/Task History.
Confirm that the task's final status is reported as Succeeded instead of Failed or Completed with Error.
This server maintenance task keeps the CMDB and Notification Server's Windows Task Scheduler clean by removing outdated schedules.
Locate the Cleanup Task:
On the SMP Console, navigate to Settings > All Settings.
In the left pane, expand Notification Server > Task Settings.
Click Clean up Task Schedules.
Configure the Cleanup:
You will see two main options:
Disable expired schedules with no occurrence during last: Disables the task schedule in the CMDB and removes the entry from the NS's Windows Task Scheduler (by default: 3 Days).
Delete expired schedules with no occurrence during last: Permanently removes the task schedule from the CMDB and the Windows Task Scheduler (by default: 1 week).
Set a timeframe (e.g., during last 90 days).
Tip: Start with the Disable option and a shorter timeframe until you are comfortable with the process, then move to Delete.
Run the Task:
Click Save changes.
Click Run Now or configure a scheduled execution (e.g., weekly).
Validation (Logs):
Path to Logs: Check the Notification Server log files in C:\ProgramData\Symantec\SMP\Logs\ for entries from the Clean up Task Schedules server task, confirming the number of schedules that were disabled or deleted.