Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Software Delivery 6.1 Best Practices Guide

Created: 26 Feb 2010 • Updated: 19 Oct 2010 | 9 comments
Language Translations
Joel Smith's picture
+11 11 Votes
Login to vote

In anticipation of the release of Symantec Management 7.0 Best Practices, the previous version of the document, Software Delivery Best Practices, is being published for the Symantec Connect Community. This article provides indepth information and best practices advise when using Software Delivery 6.x.

In the next few weeks a newer, up to the latest version article will be posted named: Software Management 7.0 Best Practices.

The following document provides the best practices when using Software Delivery Solution 6.x for Windows.

Table of Contents

Introduction
Packages and Programs
Default Software Delivery Packages
Software Delivery Packages
    Package Tab
    Programs Tab
    Advanced Tab
    Software Portal Tab
Apply, Cancel, and Update Distribution Point
Advanced Technical Details
    Package-Program Relationships
    Package Codebases
Software Delivery Tasks
Default Software Delivery Task
Software Delivery Tasks
    General Tab
    Advanced Tab
    Status Tab
Advanced Technical Details
    Client Policy XML
Sequential Software Delivery Tasks
Sequential Tasks
    General Tab
    Advanced Tab
    Software Portal Tab
    Status Tab
Sequential Task Requirements
    Software Delivery Subagent
Advanced Technical Details
    Sequential Task Execution Details
Software Delivery Wizards
Limitations to the Wizards:
Software Portal
Configuring the Software Portal
    Portal Configuration: Packages
    Portal Configuration: Sequential Tasks
    Software Portal Configuration Utility
    Software Portal Settings
Requested Software Requiring Approval
Advanced Technical Details
    Collections and Tasks
Package Delivery
Data Purging
How Purging Executes
Data Purging and the Software Portal
Advanced Data Purging Criteria
    Purging Event Data
    Purging unused Collections and Items
Tips and Tricks Appendixes
Appendix I - Resource Manager and Properties Manager
    Resource Manager
    Properties Manager
Appendix II - Deferral Windows
    Tasks: Deferring the Scheduled Execution
    Reboots: Ability to Defer a required reboot
Appendix III - ItemReference
    ItemReference Architecture
Conclusion

Introduction

This document was prepared for version 6.1.1058 (SP3) of Software Delivery Solution for Windows.

This documents provides best practices information to get the most out of Software Delivery. These suggestions and steps will help avoid potential issues. The format includes basic descriptions of all configuration items, underlining processes, and best practices details. Practices details will appear under sections labeled:
**Best Practices**

Emphasized Items will be marked by:
NOTE:

Disclaimer: This document contains no warranties, guarantees, and is provided "as is." Information in this document can be changed without notice, and will be distributed by updating the Knowledgebase Article this document is tied to.

Packages and Programs

It is important to understand the basic concept of Packages and Programs. Any item action launched by Software Delivery Solution uses this relationship of package and program.

Default Software Delivery Packages

The Notification Server has a default Package structure that most solutions use to push agents or other deliverables to the Altiris Agent. The options are limited on these types of packages. Some examples include:

  • Inventory Agent Package
  • Patch Management Solution Packages
  • Carbon Copy Agent

Software Delivery builds off this basic Notification Server Package.

NOTE: It's important to note that the same download mechanisms are used for All Packages across all Solutions.

For more information on how these packages are sent or downloaded to and by the agent, see the Package Delivery section.

Software Delivery Packages

Definition: A Software Delivery Package originates from a single folder on a storage device, including all subfolders and files.

Package Tab

The following is a detailed explanation of Package configuration, including understanding of what underlies each option on the package screen. This view shows a standard Software Delivery Solution Package configuration page:

1.png

  • Name: This field is how this "package" will be named across the Altiris Console, including any Wizards or other selection dialogs.
  • Description: For personal use. Use as desired.
  • Publisher: This label will only be functionally used by the Software Portal.
  • Version: For personal use. Default is 1.0, and this will not change except manually.
  • Package Source: This sets the method the Notification Server will obtain details about the Package. Each option is described below. Note that this does not necessarily provide how the Altiris Agents will access this package.
    • Package does not contain source files-No package source means no download will occur for this package. This is typically used for actions against items that already exist on the destination systems (that is,run a start command for antivirus services).
    • Access package from a local directory on the NS computer-As described, this option uses the local computer on the Notification Server for the package source.
    • Access package from an existing UNC-In the format of \\servername\share, a UNC can be used as the package source.
      NOTE:This UNC will be used by all Altiris Agents in obtaining the package.
    • Access package from a URL-Note the screenshot below. Two fields appear when using this option. Package Location should be the actual URL the package resides in. The Package directory requires a UNC to the same location for snapshot creation purposes. This is required to manage the snapshot of the package.

      2.png

  • Package Location: Defines the actual location of the package. Refer to the definition of a package for how that location will be used.
  • Installers found: This option is only used with PCT Solution (no longer being developed), and used by Software Migration tasks. In common uses this field will not affect anything about the Software Delivery Package.
  • Package files will be deleted from the client computer if unused for: This drop-down controls how long unused packages will remain on the client computers before deletion.
**Best Practices**
Best Practices: The following items should be considered when using this option:
  • Packages will remain if any task is still considered active for that package. These tasks can be any kind of Software Delivery Task (Portal, Sequential, Standard, and so on).
  • Tasks set to Run as soon as the computer is notified will remain "active" if the target computer still resides in the collection.
  • For the Software Portal, Purging should be enabled and set to a relatively low setting.

Programs Tab

The following is a detailed explanation of Programs configuration, including an understanding of what underlies each option on the Programs screen. Multiple Programs can be created for a single "Package." This view shows the first part of a standard Software Delivery Solution Package configuration page:

3.png

  • Name: This is the name of the action item, or Program. This name will be shown in the Software Portal configuration page and all other selectors dealing with the setting up of Package/Program items.
  • Description: For personal use. Use as desired.
  • Applications & Installer: These items are only used with PCT Solution, and limitedly with Migration Tasks. For most use cases these are not used.
  • Command line: The command line run against the working directory. Please see Best Practices for information on how to configure this.
**Best Practices**
The command line controls exactly what occurs on the client. It is important to understand how the Altiris Agent treats this, and some of the caveats of this.
  • TEST IT: Always test your command line to ensure it works correctly. It should never:
  • Have a screen that requires user interaction, that is user prompts for install configuration.
  • Require any user interaction of any kind, that is Informational boxes or warnings that require an OK button to be clicked.
  • Command-line switches must contain appropriate input data to avoid user-input prompts. A quiet or unattended switch should commonly be used.
  • Most Executions without command-lines will require user prompts.
  • If your package contains multiple folders, using the Working Directory field is essential to put the execution in the right place. By default the execution occurs in the root directory of the package.
  • Reboots should not be conducted by the MSI or EXE you are executing. The After running actions should be used for reboots.
  • Working Directory: The two main uses of this field are:
    • Executing a file within a subfolder in the Package.
    • On a "No Source Files" package and the execution occurs from a local location on the target computer, use this to specify the directory on the local client the execution should occur.
  • Success Codes: Place all codes you wish to trigger a "Successful" status. For example, error code 3010 means the installation was successful, but a required reboot did not occur.
  • Failure Codes: This field is unnecessary. All codes not found in the Success codes field will automatically be labeled a "Failure."

Second Section of the Programs Configuration Page

4.png

  • Estimated Disk Space: This field does not change functionality in any way but can be used for size-tracking purposes. Edits to this field are always manual.
  • Estimated Run Time: This field does not affect the execution, but can be used for tracking purposes. All edits to this field are manual.
  • Terminate After: If left blank, or if set to 0, the terminate time will be 360 minutes (6 hours). This is a default Altiris Agent setting added to avoid multiple processes hanging for reoccurring tasks. The value always represents minutes. The Altiris Agent will kill the Main task and any child tasks spawned from the parent when the signified time runs out.
  • After Running: This configuration item only occurs after a successful completion of the Task associated with the Program. See the descriptions of these options below:
    • No action required: Self explanatory.
    • Restart Computer: After the Task receives a return code, the computer will initiate a reboot.
      NOTE: This will occur whether the code was a success or failure. If the execution fails, it will still reboot the system. Note that the deferral option (in minutes, shown in the following screenshot) configuration ties to the Warn option in a Task. Please see the "Warn" explanation section Appendix II.

      5.png

    • Log off user: The configuration looks like the one above, but merely logs the user off instead of rebooting. The deferral options are identical.

Third Section of the Programs Configuration Page

6.png

  • Starting Window: This option only comes into play when the option User Input Required is checked. If unchecked, the execution will not be visible on the logged-on user's desktop.
  • Run with rights: The execution of the task will load a limited user stack for the user specified. System Account works well for most executions, and a specified user can be used with Domain user accounts for specific admin tasks if the System Account has been locked down. The logged on user option uses the user who is logged on, but still loads its own stack for the execution.
  • Program can run: Select the option that best fits the action required. If the install requires a user to be logged on, choose that option, and so on.
    NOTE:Tasks that run when no user is logged on will not show no matter how the execution is configured.
  • User input required: This option is more than what it seems. This option will pipe the execution to the user's desktop, making it visible. It also loads a more robust user stack, so certain installations will benefit from having this option checked if the installs have user-related install items; that is, an MSI install might install to the CURRENT USER registry hive, so it only installs some of the components for the user whose context is being used for execution. By adding the ALLUSERS=1 or similar input command, the MSI can install for all users. However without the User input required option checked, the MSI fails due to the incomplete user stack loaded during execution.
  • Run once for: The two options, Each logged on user, and Specified users or groups will run an install for multiple users. This is only available when the option Run with rights is set to 'Logged on user'.
**Best Practices**
Manipulating the previous five items can make the difference between success and failure for execution. For any complex execution it's highly recommended to use the User input required option. When using this option, if you don't want it visible in any way, be sure to change the Starting Window to "Hidden."
For MSI executions that install User-based items (parts of Microsoft Office fall into this category) should have the ALLUSERS input command utilized. Not all MSI files support this method, which will make it difficult to properly install. The following settings can be used:

7.png

  • This program requires a network connection: If any portion of the program requires Network Resources, check this option to ensure the execution does not occur at a time the network is not available.
  • Minimum connection speed: To be used in conjunction with the previous option should the execution require a specific bandwidth availability on the Network.

Advanced Tab

This tab controls Package Server configuration and provides additional download options.

8.png

  • Agent display name and Agent display description: These two options change how this package shows up in the Altiris Agent UI. If you use the default, the Package name will be used for the Name.
  • Enable verbose reporting of package status events: By disabling this option, this stops the event type AeX SWD Package from being sent to the server. If the server load is heavy on the NS, disabling this type of events can benefit, though all knowledge of the download procedure for this package will not exist at the NS.
  •  NOTE:Use Alternate Download Destination on Client: The default location for downloading SWD Packages is C:\Program Files\Altiris\Altiris Agent\Software Delivery\{<GUID OF PACKAGE>}\cache. This location will always be used for Snapshot management. Note the following:
    • The Altiris Agent will duplicate the package in both the default cache directory and the alternate location.
    • The package is copied over once full received to the cache directory.
    • The alternate location will not be updated until directly before the execution of the Task. This means updates to the package will be received to the cache location, and will not be updated until directly before a scheduled execution by a recopy.
  • Package Destination Location on package servers (leave blank for default): This works differently than the Alternate Destination for the Altiris Agent. The "Managed" package, including share creation and snapshot management, will be the Alternate location and no where else.
  • Assign Package to: These options control how the Client downloads the package. Package Servers will not be addressed in this document.

Software Portal Tab

The Software Portal tab will not be covered in this section. Please see the Software Portal section for details on how this tab interacts with a Software Delivery Package.

Apply, Cancel, and Update Distribution Point

When all changes have been made to the Package dialog desired, Click Apply to save the changes or Cancel to discard changes.

9.png

It is not always necessary to also hit the Update Distribution Point button, but note the following:

  • Definition: The Distribution Point is where the Notification Server obtains the package from.
  • Package Servers and Agents will only pull information for the current version of the distribution point. A reoccurring schedule on the Notification Server that runs every 10 minutes also updates the distribution points of any package that has changed, that is, if you add a file to the package by manually copying it into the package folder, the clients and Package Servers are not going to know about it until the Distribution Point is updated for that package.
  • When the Distribution Point updates, it analyses all the folders and files in the package and constructs a Snapshot, including a hash so the clients or Package Servers will know if the version of the package they have downloaded matches the Distribution Point.
  • Object level-changes will be detected. Files that have changed, or been added will be downloaded again, whole. File level-changes will result in the whole file being downloaded again. If a file has been removed from the package, the Altiris Agent will delete it from its local cache.

Advanced Technical Details

The following Items provide details and information for users who are experienced in the Notification Server architecture.

Package-Program Relationships

A Package and a Program are separate items. They show in the same UI, but a Program has its on Item structure within NS. The Program item contains an ItemReference data class entry with the following values: hint="packagecontainsprogram" type="DependentChild". In this way the Program is tied to the Package. See Appendix 1 for an example of how security interacts between Package and Programs. Also note Appendix III for ItemReference details.

Package Codebases

How the Notification Server publishes a Package's codebases (or download location on the network) affects directly where the clients will download the package from. All these codebases are kept in the database table SWDPackageCodebase. To see a Package's Codebases, run through the following steps:

  1. Find the desired Package in the Notification Server, right-click, and choose Properties.
  2. Copy out the Guid shown under the General tab. (that is,053effa6-130e-45b5-b959-100f9a499f8b).
  3. Open up a Query window into the Altiris Database.
  4. Run the following query (the example below uses the Guid shown above):
    SELECT * FROM SWDPackageCodebase
    WHERE PackageId = '053effa6-130e-45b5-b959-100f9a499f8b'
    
    1. The results contain all the download points for this package. This includes codebases from the Notification Server and all Package Servers this Package has been assigned to.
    2. By default each location will have both an HTTP and FILE delineator at the beginning of the string in the URL column. FILE specifies a UNC location.

NOTE: The Codebases do not automatically update when you change the location for an existing Package. The update requires several items:

  1. Distribution Point Update-This is tied to a schedule in Control Panel > Scheduled Tasks named: NS.Package Distribution Point Update Schedule {29a2b641-222a-43b0-830c-a25c59e93fe4}. You can manually click the Update Distribution Point button in the Package, or run this schedule. You can also wait for the schedule to run automatically within 10 minutes (by default).
  2. Snapshot Creation-As part of the Distribution Point update, a Snapshot is generated and stored on the Notification Server here: Program Files\Altiris\Notification Server\Snapshots\. The name of the file matches the Guid of the Package. Clients, including Package Servers, must download the snapshot before it can download the Package.
  3. Package Servers-If Package Servers exist in the environment, they must go through the standard Package Delivery process with the added step of setting up Distribution Points via UNC and IIS (if available).

Software Delivery Tasks

Standard Tasks are single-package/program tasks to execute a single item action. These are typical a one event Item to execute a particular action.

Default Software Delivery Task

Notification Server has a default Task that most Solutions use to push down software or other items to the Altiris Agent. One example is to execute Inventory Solution Tasks to collect Inventory from the client systems. Another example is the upgrade tasks for any agent or subagent, including the Altiris Agent.

Software Delivery solution extends the functionality of standard Tasks.

Software Delivery Tasks

This screenshot shows a typical Software Delivery Task under the General tab. These can only be created under the Tasks tab, under Tasks, Software Management, Software Delivery, Windows, Software Delivery Tasks.

General Tab

The following items discuss the various fields and how they affect the Task.

10.png

  • Name: This is how the Task will show up in all dialogs and selectors.

    NOTE:To avoid confusion with the Software Portal, don't use "Software Request" in the title as the Portal-generated tasks are named in this way.

  • Description: For personal use. Use as desired.
  • Priority: This is important only when a Task of high priority must be sent out. All Tasks be default have a Normal, or 2 priority. This list supplies the numerical values of the different options:
    • Low = 1
    • Normal = 2
    • High = 3
    • Very High = 4
**Best Practices**
Leave most tasks at Normal. When an important update or task comes up, then manipulate the Priority accordingly. When the Altiris Agent has multiple Tasks, it runs them in order of Priority. Normal operation does not usually include many Tasks, so this is particularly useful in the following scenarios:
  • New Computer jobs-Certain tasks, such as antivirus install, should be marked as higher priority than other software rollouts to ensure when the computer receives the batch of Tasks from the Notification Server once the Altiris Agent is installed that it runs this task first.
  • Patch Rollouts-If using Software Deliver for critical Microsoft Updates, it is recommended to apply a high or very high status to ensure they get executed ASAP.
  • Package Name: Choose the Package to be delivered to the Altiris Agent for the Task. If the Task you wish to run doesn't require delivery of a Package, review the section on Package Source concerning Packages that contain no source files, on page 6.
  • Program name: Select the Program this task will run. Standard Software Delivery Tasks only allow what Program action per Task. For multiple actions, see the Sequential Software Delivery Tasks section.
  • Applies to Collection: This selects the collection which contains a list of computers for the Task to rollout to.
**Best Practices**
Collection Management-The best way to keep packages from lingering on client systems is to create dynamic collections off of Inventory data to determine if the target computers have the software or execution performed, that is, a Task that installs Microsoft World Viewer, and have a collection based off not having the software installed, determined through the Inventory Software Audit details. The collection will then dump the systems that have this task run, and thus have the software installed, and the package will be deleted (if no other tasks reference it) after the selected amount of time has passed.

Section 2 of The Task General Tab

11.png

  • Run-Manual: Manual allows Users to access the Altiris Agent UI and run the Task manually. It also enables them to run it when the Notify option is checked (see the following section on the option for more information). To run a manual task, follow these steps:
  1. Double-click on the Altiris Agent Icon in the System Tray:
  2. If the Icon is hidden, execute the file: C:\Program Files\Altiris\Altiris Agent\AeXAgentActivate.exe.
  3. On the resulting screen it will list Software Delivery Packages available. Highlight the package desired and click the corresponding Application Task (which corresponds to the Program Name) as shown:

    12.png

  • Run-On a schedule: This option Allows the administrator to choose the conditions and time for execution.
  • Run as soon as the computer is notified (only runs once): This options will cause the Task to be run as soon as the client computer receive it. If other, equal or higher priority task are already queued, it will step into the queue behind them.
    NOTE:This option means only once automatically, ever. The Altiris Agent holds the history of this execution in the AeXSWDPolicy.xml file, and even if the computer falls out and back in to the collection, it still will not run this task again unless a schedule is set or if it is run manually via the Altiris Agent UI. Any updates to the Task will not change this.
  • Run on a schedule: Allows the scheduling of the Task based off the client computer's time and time zone.
  • Power up computer (Wake on LAN): This requires an active Altiris Agent on the subnet of the targeted computers for this to commence properly.
  • Immediately notify each computer of task: Enable this task to see a warning. This item will generally only work with small batches (< 200 systems). The Notification Server can only process 100 Configuration Requests at a time, and all systems in the collection for the task will request an update at the same time.
  • User can run this task immediately: See the section on manual running of the task. This options allows the user to run the task as soon as the computer receives it. See the section below concerning the Notify Window.
  • Notify the user when this task is available: This option should not be confused with the option to Warn a user. This displays a notification window that the computer has received a task. First, the user will see a popup window:

    13.png

    14.png

    NOTE:Dismissing the task will not stop the scheduled time, it merely dismisses the notify window. In the same light, the "Remind me again in" setting does not affect when the task executes, but only the Notify window. This is an important clarification as the "Warn User" prompt affects the execution of the task while the "Notify" option does not unless the user chooses to start the task now.

  • Warn the user before running this task: This allows the user to defer the Task. Please see Appendix II for information on how this works.

Section 3 of the Task General Tab

15.png

  • Removal-Remove this task after successful install: This will remove the TAsk and mark the task as completed. The Altiris Agent marks this Task as completed in the AeXSWDPolicy.xml file.
  • Availability-From: This option restricts when the client computers can download and execute the task. Any time before or after the specific time will disqualify the Altiris Agent from download or running it. Some examples:
    • If the Altiris Agent downloads the package but fails to execute before the close of availability, it will not run the task.
    • If a client doesn't know about the task (Client configuration request) until after the availability time, it will not download or try to run the task.
    • NOTE:The option using the server's time only applies to the availability of the task, not the execution. If the availability does not match the time-zone, this can cause a disconnect disallowing clients from running the task altogether.

Advanced Tab

This tab provides a few options for how the Task interacts with the Agent UI and the default Agent Configuration Settings policy for downloading and executing.

16.png

  • Agent display name and Agent display description: These two options change how this Task shows up in the Altiris Agent UI. If you use the default, the Task name will be used for the Name.
  • Enable verbose reporting of task status events: This affects if the Altiris Agent sends AeX SWD Status events to the Notification Server. This does not include Execution status events. A list of these event statuses are:
    • New Job
    • Job Updated
    • Download Complete
    • Job Activated
    • Job Removed
    • New Package
    • Package Removed
    • Package To Be Removed
    • Package Updated
    • Unable to check package
  • Download and Execute Options: The default is to use the Altiris Agent Settings, found under the Altiris Agent Configuration policies. If you choose to override what is set at the Altiris Agent level, choose the option Use the following settings when downloading and running.

Status Tab

This tab had significant issue prior to Software Delivery Solution for Windows 6.1 SP2. In SP2 this tab is now controlled by a Stored Procedure that has optimized the query and eliminated several issues. Consider this a built-in Report for the task, based off of Events (AeX SWD Status, AeX SWD Execution, AeX SWD Package). Corresponding Reports can be found under the Reports tab, under Software Management, Software Delivery, Windows.

Advanced Technical Details

The following Items provide details and information for users who are experienced in the Notification Server architecture.

Client Policy XML

All Tasks appear in the Altiris Agent Client Policy XML file. The file is located here:
C:\Program Files\Altiris\Altiris Agent\Client Policies\<servername>.xml.

  • The file will be named after the Server the Client Policy came from. If this Altiris Agent has been connected to multiple servers, it will have a policy file from each Notification Server it has attached to.
  • Each Software Delivery Task will have an entry in this XML file. Following is an example of a task as it appears in XML format. I've highlighted some points of interest, which are details hereafter:
- <Policy guid="{F8664B82-EB28-4201-B773-82BBDB9E4AB8}" name="Hello World - Sample" version="6.0.6074.0">
- <ClientPolicy agentClsid="Altiris.SWD">
- <SoftPkgs>
- <SoftPkg Name="Sample Package" displayName="" Id="{8661D7F2-039B-4418-9A0A-70A9C7445F9C}" Version="1.0" InternalVersion="1160701201" Originator="NS" Destination="" CleanupAfter="10080" Priority="Normal" StatusEventsEnabled="true">
- <PackageDescription>
- <![CDATA[
Sample Software Delivery Package
 ]]>
 </PackageDescription>
 <JobID StatusEventsEnabled="true">{F8664B82-EB28-4201-B773-82BBDB9E4AB8}</JobID> 
<Title>Hello World - Sample</Title> 
- <Abstract>
- <![CDATA[ 
Launches an application window and shows "Hello World"
 ]]> 
 </Abstract>
 <ValidPeriod after="2006-10-13 00:00:00" afterGMT="false" /> 
 <ExecutionEnvironment ExecutionContext="User" LogonName="" LogonDomain="" LogonPassword="" Interactive="true" AllowUserExecution="true" CanRunWhen="Only when a user is logged on" StartWindow="Normal" ScheduleRetry="true" MinConnectionSpeed="0" RemoveAfterRun="false" UserOptional="false" NotifyUserArrival="false" SuccessCodes="0" FailureCodes="" /> 
 <Recovery snapshot="False" /> 
 <Download useClientDefaults="true" Immediate="true" MinDownloadSpeed="-1" MinExecutionSpeed="-1" multicast="Default" Mode="Always" /> 
- <Implementation PackageSize="122880" EstimatedSize="0" EstimatedDuration="0" KillAfter="360" WorkingDirectory="" Language="" NoSourceFiles="false" NotifyBeforeExecution="false" notifyBeforeRunMaxDefer="0" RunOnceForEachLoggedOnUser="false">
- <CommandLine>
- <![CDATA[ 
"HelloSample.exe"
 ]]> 
 </CommandLine>
 <AfterExecution action="No Action" force="false" maxtime="0" /> 
 <Platforms allowAnyPlatform="true" /> 
 </Implementation>
 <RunOnceForSpecifiedUsers enabled="false" runOnlyForTheseUser="" /> 
 <Schedule IndependentExecution="true" /> 
 </SoftPkgs>
 </ClientPolicy>
 </Policy>
  • The Policy GUID is the GUID of the Task itself.
  • The Softpkg ID provided is the GUID of the Package the Task will use.
  • Note that all the settings within the Task and Program are provided in this XML segment. This is where the Altiris Agent obtains when and how to execute the Task.

Sequential Software Delivery Tasks

Sequential tasks allow a chain of package/program executions.

Sequential Tasks

Sequential tasks allow a chain of package/program executions. While not all options mirror standard Software Delivery Tasks, it is recommended you review that section starting on page 14 for those options that are the same.

General Tab

The following shows the main configuration screen for Sequential Tasks under the General tab. The other options mirror those of a regular Software Delivery Task and will not be covered here.

17.png

  • Execution Order: To add package-programs to the list of executing items, click the blue + to the right of the screen.

    18.png

  • NOTE:Selector dialog: This dialog shows no results by default so a search can be performed. You can search by Package Name or Program Name.
  • SHOW ALL: To show all package and programs, check either option and click 'Search' to see the complete tree under the Package Folder: section.

    19.png

  • Package-Program: Note the relationship of Package to Programs. If you check a package (Blue cube icon) it will select all Programs underneath. To avoid adding unintended Programs, select items by check the Program box (green checkmark clipboard icon).
  • Select all items you wish to execute in the Sequential Task, and then click OK.
**Best Practices**
Important: Modifying the "Execution Order:" items will require the Sequential Task to be assigned a new Task GUID. This means any system that already ran the Sequential Task will run it again.
  • It is highly recommended you carefully plan the construction of the Sequential Task before rolling it out into production so you do not run into problems modifying the Execution Order.
  • Modifications to the actual Package/Programs associated with the Sequential Task will not cause a new Guid to be generated. The actions that cause a new Guid generation are:
  • Changing Execution Order-Using the up and down errors to modify the order in which Programs execute
  • Adding additional Programs-Adding additional Package-Programs to the execution list.
  • Removing Programs-Removing Package-Programs from the execution list.
  • Dependencies-The ability to create dependencies on the previously run Package/Programs hinges off successful completion of the task. If a task fails but the next task is not dependant on that completing successfully, it will subsequently run, continuing the "chain" of Programs.

Advanced Tab

The Advanced tab provides the same Altiris Agent Download and Execute options a regular Software Delivery Task supplies. Please see the corresponding section for more information.

Software Portal Tab

This tab controls what Sequential Tasks show up in the Software Portal. This will be covered under the Software Portal section.

Status Tab

This tab provides a reporting interface similar to a regular Software Delivery Task. If this tab does not fulfill your reporting needs, see the Sequential Reports found under the Reports tab, under Software Management, Software Delivery, Windows.

Sequential Task Requirements

The following items are required for proper execution of Sequential Tasks. Regular Software Delivery Tasks do not require the subagents that Software Delivery Solution Installs.

Software Delivery Subagent

Task Synchronization Agent-This Agent controls all sequencing of a Sequential Task. In other words it dictates all executions of the Task. Without this agent the Task won't even begin to execute. The functions of this Agent include:

  • Initial execution of the first task in a Sequential Task.
  • Tracking all executions, including dependencies.
  • Initiates the execution of the next Program in the task upon completion of the previous program.
  • Sends Inv_Synch_Status messages to the Notification Server indicating progress of the Sequential Task. This includes success and failure messages. Note: This is on top of regular events sent by standard tasks (AeX SWD Execution, etc…)

NOTE:It is essential to have the correct version of the Task Synchronization Agent to what version of Software Delivery Solution you have installed. Below lists versions of the Task Synch Agent in conjunction with the version of Software Delivery Solution:

  • Task Synchronization Agent 6.1.1018 - Software Delivery Solution 6.1.1034 (SP1)
  • Task Synchronization Agent 6.1.1022 - Software Delivery Solution 6.1.1034 (SP1 Hotfix 1)
  • Task Synchronization Agent 6.1.1025 - Software Delivery Solution 6.1.1034 (SP1 Hotfix 2)
  • Task Synchronization Agent 6.1.1028 - Software Delivery Solution 6.1.1048 (SP2)

Issues stem from having a previous version of the Task Synchronization Agent installed on the clients than what version of Software Delivery Solution is installed. A common problem stems from the way the Upgrade Task functions for this agent.

Cause: Both tasks controlling the upgrade of these agents is set to Run once ASAP. If these tasks have run prior for a different upgrade (that is, Software Delivery Solution 6.0 to 6.1, or 6.1 to 6.1 SP1) the Run once ASAP designation will never run again, even if the version changes.

Resolution: Enable a repeating schedule. Since the Collection applying to the task will remove computers once they've successfully run the task this task will not rerun on systems due to the repeating schedule.

Example:

  1. Check the Schedule: option.
  2. Click the link No schedule has been defined (or an existing schedule will be shown if previously defined).
  3. Change the Schedule Task: option to Daily.
  4. Set Start Time to a time that works for your environment.
  5. Click OK.

Now the Agents will upgrade on or anytime after the set schedule.

Advanced Technical Details

The following Items provide details and information for users who are experienced in the Notification Server architecture.

Sequential Task Execution Details

Sequential Tasks have multiple Tasks associated with them. As detailed previously, Sequential Tasks are linked to Package/Programs. The list of items to execute does not link to Tasks, but to the Package/Programs relationships.

The following steps detail how the Task is architected:

  1. A Sequential Task Guid is generated for the entire Task. The task appears as such in the Altiris Agent's Client Policy XML file:
    - <Policy guid="{78939175-0C4A-4A55-A164-60DC888BDDC2}" name="Synchronization Task for Sequential Software Delivery Task : Sequential Task" version="6.0.6074.0">
    - <ClientPolicy agentClsid="Altiris.Synch">
     <Task guid="{28193450-be96-46f7-954b-5ea2762a28f1}" priority="1" ExeName="" /> 
    - <Task guid="{c34568c9-dfc6-4e70-8fcd-11fc7440986c}" priority="2" ExeName="">
     <Dependency guid="{28193450-be96-46f7-954b-5ea2762a28f1}" returncodes="0" /> 
     </Task>
     <TaskCreatedForSWPortal ReportFinalStatusToServer="False" /> 
     <ValidPeriod after="2006-10-25 00:00:00" afterGMT="false" /> 
    - <Schedule ScheduleRetry="false">
    - <Schedule>
     <Trigger Type="-1" Description="As soon as possible" /> 
     </Schedule>
     </Schedule>
     </ClientPolicy>
     </Policy>
    
  2. Note that the Task includes two Task GUIDs, listed as highlighted above. Each Task is generated when the Sequential Task is created and saved. These tasks are not viewable in the console, but have standard entries in the Client Policy XML.
    NOTE: These Tasks very closely resemble standard Software Delivery Solution Tasks in the Database architecture. The Client Policy entries for the sub-tasks look like a standard Task, for example:

    - <Policy guid="{C34568C9-DFC6-4E70-8FCD-11FC7440986C}" name="Software Delivery Task for program : Sequential Task Program #2" version="6.0.6074.0">
    - <ClientPolicy agentClsid="Altiris.SWD">…etc…
    
  3. This main Sequential Task is not executed by the standard AeXSWDAgent.dll, but is managed by the AeXTaskSynchAgent.dll (Task Synchronization subagent). The Task Synch Agent passes the Tasks to the core AeXSWDAgent.dll for execution.
  4. The Task Synch Agent keeps track of where in the Sequential execution list the client is at. This information is stored in the synchronization.xml file located at C:\Program Files\Altiris\Altiris Agent\Task Synchronization\. This file is loaded into memory by the Task Synch Agent, and changes are made at the memory level.
  5. At all status points the synchronization.xml file is written back to the hard disk (that is,Agent shutdown, end of Task within a sequence, after successful completion, and so on).
    **Best Practices**
    When conducting a Reboot in the middle of a Sequential Task the Program configuration option After running the Altiris Agent should: Reboot should execute the Reboot not the execution running (MSI or other Installer initiating the reboot).
    This ensures that the status of the Sequential Task is properly written to the hard disk before the computer shuts down for the reboot. If the Task Synch Agent is unable to write the status down the Task Synch Agent will rerun previous steps according to the last time the Synchronization.xml file was saved.
  6. In the Agent UI you cannot access the Sequential Task, but only the individual Tasks within the Sequence, as shown:

    20.png

  7. Note the Application Tasks section. This is the hidden Task created by the Sequential Task when create and saved. In other words there is no way to kick off a Sequential Task manually.

Software Delivery Wizards

The Wizards make the creation of Packages/Programs and Tasks simpler, but there are some limitations they introduce. This document does not go into detail surrounding the Wizards.

The Wizards basically do the same things you can do manually by creating a Package/Program and Tasks. In some ways it's more restrictive.

**Best Practices**
For administrative purposes do not use the Wizards. They are intended for workers and limit the scope of how you can manage Packages and Tasks. The wizards don't save any significant amount of time as you still have to configure each portion (Package/Program/Task).

Limitations to the Wizards:

  • Unable to specify creation location in the Altiris Console for the Task and Package.
  • Certain Security constraints are disregarded by the Wizard.

Software Portal

The Software Portal allows users to access a web-based portal to launch Software Delivery programs either automatically upon request or based off approval.

Configuring the Software Portal

Configuration occurs on the Notification Server at two levels: Package Configuration and Sequential Task Configuration.

NOTE: Packages and Sequential Tasks take the unusual role of using the same configuration for the Software Portal. Regular Software Delivery Tasks do not interface with the Portal, rather the packages themselves are configured. Sequential Tasks act like Packages in this way.

Portal Configuration: Packages

The basic configuration piece is found on the Package configuration page (Resource Manager) under the tab "Software Portal". The configuration uses security items that tie into the main Notification Server Scope security model. Under the Software Portal tab, you'll find the following screen:

21.png

By default 3 roles will have Install Software rights in the Software Portal:

  • Altiris Administrators security role/group (local group on the Notification Server)
  • NS Application Identity, configured at the time of install for NS
  • Creator of the Package

By clicking Modify you'll enter a standard Notification Server Scope Security dialog, as shown:

22.png

  • NOTE: If you look at the top label, it shows "Sample Program". This is not the Package Name, but the Program Name. The actual security does not apply to the Package, but to the Program. For more information on the Package-Program relationship, see page 12.
**Best Practices**
The Inheritance does not come from the folder structure holding the Package, but a hidden object called SWD Programs. To change default permissions, the SWD Programs object needs to be brought up in the Properties dialog. Using the method described in Appendix I on page 41, you can bring this object up by using this GUID:
  • 1FC86E41-B94F-4769-9457-1CF90A47BC6A
This Guid is the GUID of the SWD Programs folder where all Programs inherit permissions from. By setting what settings you want by default, all newly created Programs will get those permissions.
Caution: You'll have to break inherence if you wish to remove permissions/roles from an individual Program.

Most of the items in the permissions list do not directly correlate to the Software Portal. The two items that configure who can see this item in the Software Portal are the two shown here:

23.png

  • Install Software: This option allows users to directly request and receive software automatically. Any software with this option is considered already "Approved" for the corresponding role/users.
  • Install On Approval: This option requires an admin to approve the request for Software. Further in this section the Approval process is documented.

Portal Configuration: Sequential Tasks

The configuration of Sequential Tasks works the same way as the Package configuration. The dialogs are exactly the same. A few notes on Sequential Tasks and the Software Portal:

  • The inheritance for Sequential Tasks come directly from the Console folder structure, unlike that of the Programs configured on the Package side.
  • Sequential Tasks come bundled, meaning if you have permission to request the Task, all included Packages/Programs will be downloaded to the client system.

Software Portal Configuration Utility

This Utility provides a way to update multiple Packages and or Sequential Tasks at the same time. This can be a real timesaver in the Portal Configuration process.

24.png

Access the utility as shown in the previous screen. You can select one or multiple packages using the standard Windows methods (Shift for a range select and Ctrl for an individual additive/removal select). Click the View/Modify Privileges button to see the configuration screen.

25.png

  • Note that the two sides represent the two security options for the Software Portal.
  • A solid check in the check box indicates permission on all objects selected (meaning for all packages you selected in the previous screen).
  • A grayed check in the check box indicates a user or group has permission on one or more of the packages, but not all.
  • Taking out the check on any user or group will remove that group/user from the permissions.
  • To add new users or groups, click the blue + to the right of the listed groups/users.

Software Portal Settings

A Task exists to provide local systems settings for the general operation of the Software Portal.

26.png

  • Show link for Software Portal in Start Menu: This option creates a Software Portal link under the Altiris Program.
  • Show link for Software Portal in Altiris Agent's context menu: This option is utilized as shown here:

    27.png

  • If none of these options are selected, the Portal can be accessed via the link shown in the URL segment of the task page as shown previously.
  • The option Maximum number of software allowed in a single Software Portal request: was added to avoid the ability to check all packages and request huge amounts of software at once.
**Best Practices**
The policy requires the Software Delivery Solution Agent to be installed. Change the default collection (All 32-bit Windows Computers) to Computers With Software Delivery Agent Installed. This avoids an issue where the Software Portal Settings Task tries to run before the Software Delivery Solution Agent is installed properly.  
If you find Run failed as the status for this task (Package as subsequently shown), you'll want to clone the existing Portal Settings Task after making the before change in the collection. Enable the new once and disable the old. That will resolve the issue.

Requested Software Requiring Approval

When users request software through the portal that requires approval, an incident is created within Alert Manager or Helpdesk (if installed) in order to answer the request. The process is as follows:

  1. When a user requests software that requires approval, an Incident is created. Click on the Incidents tab in the Altiris Console if you do not have Helpdesk installed, or access your Helpdesk console.
  2. Click on Retrieve Incident, as shown.

    28.png

  3. Note the list of virtual workers, or queues. The Asset Management queue contains the Software Portal Requests. Either browse the queue manually or retrieve the oldest incident by double-clicking the queue name.
  4. The Incident will have a link, as shown:

    29.png

  5. Clicking this link launches the Approval Wizard.
  6. NOTE: The following applies to each Incident:
    1. The Incident is created when the first request for a specific Package/Program arrives.
    2. Each subsequent request for the same Package/Program will add to the same incident. In this way the Wizard can be used to address all requests that have come in for that software since the incident was created.
    3. Once the Wizard is launched, no other requests are linked to this incident, but a new incident is created and the process starts over.
  7. To approve software for specific users, check the box next to the name as shown. Note that if you leave the box unchecked, this is considered a rejection of the request for that user.

    31.png

  8. When you click Next, it provides the Task details, very much like a regular Software Delivery Solution Task. See the section on Software Delivery Solution Tasks for more information on page 13.
  9. The options for the Task allow normal delivery control. Note that Portal Requests that do not require approval will use all defaults for the Task, with the run option set to Run as soon as the computer is notified.
  10. The last screen is a Summary. Most of the time the defaults will be left alone and the Wizard can be finished. 

    31.png

  11. Click OK to finish the wizard and complete the process. No further action needs to be taken.

Advanced Technical Details

The following Items provide details and information for users who are experienced in the Notification Server architecture.

Collections and Tasks

The Software Portal Creates hidden Tasks and Collections to manage the distribution of Requested Software to the target system.

Request Versus Deployment-When accessing the Software Portal, the Portal is constructed based off the Logged On User. The available packages are those the user had rights to within the Software Portal. Deployment Software switches the focus from the Logged On User to the Computer from where the request was initiated from.

Items created by a Software Portal Request

  • The Software Delivery Solution Agent (AeXSWDAppReqAgent.dll) contacts the Notification Server to have the items created.
  • A Task with the naming convention: Software Request: <Name of the Program> is created. For example, to bring back every task in the SWDAdvertisement table generated from a Software Portal request, run the following SQL Query:
        
    SELECT * FROM SWDAdvertisement
    WHERE [Name] LIKE 'Software Request%'
    
  • Example Output:
        
    3488C8F5-95F8-4DAD-A310-F5E24703A53D     0      {eebe7a46-90cc-4862-8aa4-86499c85ac18}   Software Request - Test Program…
    3488C8F5-95F8-4DAD-A310-F5E24703A53D     0      {eebe7a46-90cc-4862-8aa4-86499c85ac18}   Software Request - Test Program…
    
  • Single Computer Collection with the naming convention: SWRCollection_%COMPUTERNAME% This collection contains one member: the computer the request came from, as labeled in the Collection [Name].
  • The Single Task has the single created Collection as the target Collection.
  • Once the Server confirms to the Software Delivery Solution Agent (AeXSWDAppReqAgent.dll) this agent will prompt the Altiris Agent to Request and updated Configuration (Client Confix Policy XML file) to obtain the new task and subsequent Package from the Notification Server.

Package Delivery

The package delivery mechanism is mostly controlled by the core Notification Server. This document will only cover the basics of Package Delivery. The following diagram covers the Package Delivery process, including the execution.

Software Delivery Process, Diagram

32.png

Software Delivery Process, Dataflow

After you have created a SWD task, the SWD flow is the same for all packages:

  1. The next time the Altiris Agent checks in based on your configured settings
    1. The GetClientPolicies.aspx page is passed a GUID.
    2. The Notification.server.name.xml file is returned to the Altiris Agent with information includes a task definition, execution instructions, credentials, schedule and command-line parameters.
  2. The SWD Agent [AeXSWDAgent.dll] parses the task definition.
  3. The SWD Agent requests a package location from the Notification Server.
    1. getPackageInfo.aspx page is passed the Computer GUID, the Package GUID, and the IP Address to look up the computer's location and which package server would be assigned for delivery should a package server be so configured.

      *TotalTime-The Agent sends a time value to indicate how long it has been trying to download the package. If the time is greater than the MaxAgentDonloadTryingTimeMins, the NS returns the codebases of the PS on the same site as the NS for that request. Default is set to off. See release notes, 5.2.7 for more information on this feature.

    2. Package.xml returns the snapshot location. If Package Servers are defined, all entries for all assigned package servers applicable to the client will be present.
  4. Package Delivery Agent requests the package snapshot.
    1. getSnapshot.asp is passed the package GUID. When a package servers are defined, the agent performs a speed test [SpeedTestCodebases = 1, by default in CoreSettings.config].
    2. Snapshot.xml returns containing a Hash, list of files in the package and their sized and date/time stamp. Should the package be updated, the hash would change.
  5. Agent evaluates the current task and the package attributes and compares them o the default settings received in the Agent Settings policy. If the prerequisites for multicast are met [enabled, package size, download to agent (not run from server), etc], then the request is passed to the multicast engine. The multicast engine checks for package availability. If there is a current multicast session running, the package is distributed during the current session. If not and the max sessions per physical subnet will not be exceeded a new session is started. If the session fails, the multicast is tried again and again until it reverts to a standard download.
  6. The SWD Agent requests the package from Package Delivery.
    1. The Altiris Agent downloads the package from the Notification Server or the designated Package Server depending on your solution is configured.
    2. The SWD Agent schedules the execution of the package.
  7. The package execution is scheduled.
  8. The package runs.
  9. The SWD Agent sends the execution Status to the Notification Server.
  10. The Status is received and processed through the Event process queue.

Data Purging

This section covers the Software Delivery Solution Data Purging.

SP2 for Software Delivery 6.1 introduces a change to Data Purging. The following view shows the options available in the purge:

33.png

  • NOTE: Note that the Software Delivery Data Purging duplicates some purging options offered by the core Notification Server, except all Software Delivery purging only purges events and items created and managed by the Solution.
    • Example: The option Software Delivery package is based on events sent to the table Evt_AeX_SWD_Package. This table also holds package events for all NS Solutions. The NS Core purging item for Computer Events purges this table, but the Software Delivery purge only affects those events sent on Software Delivery Solution Packages.
  • Maximum Rows directly relates to the rows in the corresponding tables. See the following tables connected to each item:
    • Software Delivery: Evt_AeX_SWD_Execution
    • Software Delivery package: Evt_AeX_SWD_Package
    • Software Delivery status: Evt_AeX_SWD_Status
    • Sequential Tasks run status: Evt_AeX_SWD_Execution

How Purging Executes

The following process details what executes the purge.

  1. After the settings are adjusted per the Data Purging configuration, the actual purging only occurs once a day by default.
  2. You can execute Purge manually by clicking Purge Now under the item you wish to manually purge, as shown here:

    34.png

  3. A schedule exists on the Notification Server that includes Data Purging for Software Delivery Solution. This is found in the Control Panel under Scheduled Tasks.
  4. The Name of the specific Scheduled Tasks that includes Purging appears as: NS.SWMConfigItem.{6ad3cfe0-fe55-4951-95be-897cf7a77b53}.
  5. The default schedule is set to run at 2:00am every day (Notification Server time).
  6. NOTE: Keep in mind that this schedule does more than execute the purge.
  7. To run the schedule manually, right-click and choose Run.
**Best Practices**
Periodically check to ensure Data Purging is functioning correctly. If Purging does not execute properly many various tasks will remain in the database when they should be purged. The following checklist can be used to ensure Purging operates successfully:
  1. Check for the existence of the Schedule labeled NS.SWMConfigItem.{6ad3cfe0-fe55-4951-95be-897cf7a77b53}. If it does not, refer to KB 22118.
  1. Run Purging manually as detailed previously and watch the logviewer.exe for completion details. If errors occur, purging has not been successful during the scheduled time.

Data Purging and the Software Portal

The Software Portal depends on Data Purging to clean up completed Software Portal Requests, whether standard package/program requests or Sequential Tasks.

Advanced Data Purging Criteria

The following details provide the criteria upon which events are purged according to the Data Purging Settings.

Purging Event Data

Each Item is described below, including the parameters of the purging.

  1. AeX_SWD_Execution: The entries from the data table AeX_SWD_Execution are purged.
    • Stored Procedure: spPurgeSWDExeEvents
    • Parameter: ProductGuid /CurrentClassTable /CurrentPurgeData /CurrentPurgeKeepDays /CurrentPurgeMaxRows
    • Key: If that AdvertisementId exist in item table as Guid
  2. AeX_SWD_Package: The entries from the data table Aex_SWD_Package are purged.
    • Stored Procedure: spPurgeSWDPkgEvents
    • Parameter: ProductGuid/ PkgClassGuid /CurrentClassTable /CurrentPurgeData /CurrentPurgeKeepDays /CurrentPurgeMaxRows
    • Key: If that PackageId exist in item table as Guid
  3. AeX_SWD_Status: The entries from the data table Aex_SWD_Status are purged (Here 'New Job' entries won't get deleted as these account for calculating License usage)
    • Stored Procedure: spPurgeSWDStatusEvents
    • Parameter: ProductGuid/ TaskType /CurrentClassTable /CurrentPurgeData /CurrentPurgeKeepDays /CurrentPurgeMaxRows
    • Key: If that PackageId exist in item table as Guid
  4. Inv_Synch_Status: The entries from the data table Inv_Synch_Status are purged.
    • Stored Procedure: spPurgeSynchStatusEvents
    • Parameter: ProductGuid /CurrentClassTable /CurrentPurgeData /CurrentPurgeKeepDays /CurrentPurgeMaxRows
    • Key: If that TaskId exist in item table as Guid

Other Considerations

Older Than: Data will be retained (saved) for the specified days, weeks, and months.

Maximum Rows: Specified number of rows will be retained (saved). It works similar to NS purging maintenance.

Working: The two filters provided work one after the other.

  1. First all data in the table is checked for retention period criteria, where all data which is older then the specified period will get deleted.
  2. Next all the remaining data in the table is checked for maximum rows criteria, if there are more rows then the specified value then all the remaining rows will be deleted. Refer the example below to understand the working.

Examples: There are 20 rows in AeX_SWD_Execution table and the data is older than 2 days.

  • Case 1: Retention period is set as "older than 7 Days" and Maximum Rows is 10.
    • Output: There aren't any rows older than 7 days, but Maximum rows to be retained in table is specified as 10. Hence the remaining 10 rows will be purged.
  • Case2: Retention period set is "older then 2 Days" and Maximum Rows is 20.
    • Output: All 20 rows will be purged as they are older then 2 days.

Purging unused Collections and Items

The following Collections are internal collections created and used internally by Software Delivery Solution, and do not include any collection viewable in the Altiris Console. The Items listed below include Tasks of various types within Software Delivery Solution.

  1. Sequential Software Delivery Tasks: When a sequential task is created with n number of programs in it then total n entries are made in the SWDAdvertisement table. When the task is deleted the entries are not removed. These entries get purged when the date is set appropriately.
    • This also applies to task created when Sequential SWD tasks are created for software portal request.
    • Key: if that AdvertisementId exist in item table as Guid and item name is "'Software Delivery Task for program :%."
    • For unused internal collections: No purging will be done for this.
  2. Software Migration task:
    • For unused internal items: When a Software Migration task is created and then particular items (entries) are made. When that task is deleted the entries still exist in the SWDAdvertisement table. On purging these entries are deleted.
    • Key: If that AdvertisementId exist in item table as Guid and item name is "Software Delivery task to install software :%."
    • For unused internal collections: It is observed that when the task is deleted the collection entries are deleted. So while purging the collection purged would be 0.
    • Key: If that pattern matches with "SWD_RerunCollection, Software Migration Internal Collection For%, Resource_" and hint is "policyappliestocollection, collectionincludescollection."
  3. Software Portal: Condition: When data in SWDSoftwareRequest table has one of the following status "Rejected" OR "ExecutionSuccess" OR "ExecutionFailed" OR "RequestProcessingFailed," entries in all the other tables which are related with this particular entry are now candidates for purging. This condition is must for both "unused internal items" and "unused internal collections"
    • For unused internal items: Request approved software. Observe that two entries are made in the SWDAdvertisement table. One is temporary and the other is with name "Software Request%" and one entry is created in SWDSoftwareRequest table.
      • So when purging is carried out two entries from SWDAdvertisement table, one entry from SWDSoftwareRequest table and one entry from the Item table will get deleted.
      • Stored Procedure: spGetInternalSWRTasks
      • Parameters: Days / ClassGuid (SWRAdvertisementItem) / ProductGuid (SWD) / ItemName (Software Request type)
      • Request a software requiring approval. Observe that if you approve the request then two entries are created. One is temp and the other is with the programID. On purging only the temp entry is deleted.
      • When the above condition is satisfied then the entry from SWDAdvertisement and SWDSoftwareRequest table get deleted when purged.
      • Note: If one clicks on approve on first page of SWP Wizard and goes to next page and closes the wizard, without addressing the request then two entries are made in the SWDAdvertisement. These values won't be used anytime. On purging among these two entries only the temp entry is deleted.
    • For unused internal collections: When software is requested an internal collection is created for the Software request task. On purging these internal collections are purged provided the above condition is satisfied.
      • Key: If that pattern matches with SWRCollection / SWD_RerunCollection / Collection for Software Request type and hint is 'policyappliestocollection', collectionincludescollection').
  4. Application Relationship: Run application inventory task. Get the inventory and now delete an installed application. Run the application inventory task on the same client again. Observe that the application is shown as uninstalled. (This can be seen in the ApplicationInventoryDiff.xml).
    • On purging this uninstalled application information is deleted.
  5. Unused SWD Items: There is no provision to purge the entries in following table in the Purging UI.
    • SWDAdvertisement (for SWD Task, key is: if that AdvertisementId exist in item table as GUID).
    • SWDProgram (key is: If that ProgramId exist in item table as GUID).
    • SWDPackage (key is: If that PackageId exist in item table as GUID).
    • Purging would take place when user clicks on Apply button on purging page. Where in, temporary entries made by the execution of Software Delivery Task, Agent installation will be deleted and PackageServer Items would be deleted (entries with name "pacdumfrpkgsvrcntrl").

Tips and Tricks Appendixes

The following items are referenced throughout this document for common tips and tricks in working with Notification Server and Software Delivery Solution.

Appendix I-Resource Manager and Properties Manager

This details a process that can be used to look up the Resource Manager or Properties Manager of any item by Guid. This allows access to items that may not be visible in the Altiris Console. The following three examples show how this is done.

Resource Manager

The Resource Manager has several types, including Computer Resource, Task Configuration, Package Configuration, etc.

Example 1

The following steps and illustrations show how this is done for a computer resource. The situation is a computer is sending events that throw errors on the Notification Server. The logs include a GUID, but no computer name. Resource Manager on that system will provide details on that computer.

  1. Browse to a Collection.
  2. Right-click on a computer and choose Resource Manager.

    35.png

  3. In the URL, take the GUID you've obtained for a computer or other resource and replace the existing GUID as shown:

    36.png

    37.png

  4. Now you have the Resource Manager for the computer sending the events that generated the error.

Example 2

A particular Task is stopping a Package from being deleted, and you don't recognize the name of the Task. To look up the Resource Manager on the Task, use the following method:

  1. Browse to any Task (Policy) in the console.
  2. Right-click on the Task and choose Open in New Window.
  3. In the URL, take the GUID you've obtained for the unknown Task and replace the existing GUID.
    NOTE: The GUID is contained directly after the ItemGuid= section in the long URL.
  4. You will now have the Task details for the task in question.

Properties Manager

Every Item have references and security applied to them. Any item in the console has a properties option in the right-click menu. If you know the Item's GUID, you can pull up the properties page for that item. The properties page offers valuable information as shown here:

38.png

General Tab

The following items are of particular interest.

  • Guid: Useful for running queries against the Altiris database. The item you right-clicked on and choose Properties for will be represented in the Database as a GUID.
  • Product Name: The installer or product that owns the code for this item.
  • Folder: This represents the location in the Altiris Console this Item resides. Not all items exist in the console. For example a Software Portal Task does not have a place in the console. Every item belongs to a hierarchy, whether a child member or a starting node.
  • Attributes: These are Item attributes for the Item, including: NoDelete, Normal, Hidden, ReadOnly, and so on.

Security Tab

The security tab reveals the Scope-based Security interface for this Item. All Scope-based security items relating to this object can be adjusted in this location. This section will not cover the intricacies of Notification Server Scope-based Security, but will explain how the options here are of particular interest when viewing the properties.

39.png

Note the following when interacting with this page:

  • Inheritance comes from the parent item, and you can see what the parent item is by viewing the Folder: item from the General tab. You can also query the ItemReference table by placing the Guid from the General tab in a query, as shown here:
        
    SELECT * FROM ItemReference WHERE ChildItemGuid = '<Guid>'
    

    Looking at the results, you can find the Guid of the Parent Item under the ParentItemGuid column.

  • Owner tab allows a user to take ownership of an item. If permission problems are keeping an Admin from properly manipulating the item, taking ownership usually provided the needed rights.

Example 3

In the Software Portal, a certain Package has two Programs available, one that installs Adobe Reader and one that uninstalls it. A certain group of users can only see the uninstall program when they log into the Portal. The Software Portal tab for the Package shows the groups as having rights to the Programs. To pull up the security item for the specific Program, the Resource Manager can be used in this method:

  1. Export the Package and look through the XML to find the ItemGuid of the Program.
  2. Browse to the Package in question.
  3. Right-click and choose Properties.
  4. In the URL change the ItemGuid= section to the GUID of the Program in question.
  5. You can now change the security to allow the specific group access to the Program in the Software Portal.

Appendix II-Deferral Windows

This section covers the deferral windows available for Tasks and Reboots. Some of these options are controlled by Software Delivery Solution, and the others the core Altiris Agent.

Tasks: Deferring the Scheduled Execution

On any task you can allow users to defer the execution, avoiding potential loss of work for unsaved documents or projects. This option is set within a Task, as shown here:

40.png

The warning window appears as follows:

41.png

  • This windows allows the user to defer the execution of the task. This is not connected to the option Notify the user, but to the Warn the user option.
  • The list of times available for deferral come from a static list. For example if you choose five hours as the max deferral option, you will only see up to four hours available in the drop-down list. However when the four hours are up you can choose an additional one hour, equaling the five hours you set. The screenshot above shows the available options between five minutes and twelve hours.
  • The Automatic progress bar has a default of 60 seconds. This can be manipulated by modifying the client's Altiris Agent Configuration policy. Note the screenshot below that shows this option:

    42.png

  • The label/text surrounding the option does not accurate describe what this setting does. The heading = Software delivery task notification prior to running. The option labeled: Notify in advance.
  • The list of available options is static.
  • NOTE: Consider this mislabeled! This directly affects how much time the progress bar for "Starting automatically in" has before execution begins.

Reboots: Ability to Defer a required reboot

Reboots can cause a user to lose unsaved work. The ability to defer the reboot is important, as is understanding how the settings affect how this reboot prompt operates. The reboot deferral acts in much the same way the Task deferral does. The option for Reboot referral is found within the Program configuration. See the sections on Programs, as shown here:

43.png

  • See the Task execution deferral window preceding for how the reboot window works.
  • NOTE: The progress bar before an automatic reboot keys off the exact same settings as the Task progress bar. This means what you set for Tasks also affects the prompt for a reboot.
  • The automatic progress bar maxes at 60 minutes.

Appendix III - ItemReference

This section details the significance of the ItemReference table in relation to Software Delivery Solution for Windows. Every Package, Task, Collection, or Item has a Guid associated with it. Using this GUID, all applicable Reference items can be queried against the ItemReference table.

ItemReference Architecture

This table contains the following columns, used to map relationships between items:

  • ParentItemGuid-In the hierarchal structure this Guid represents the Parent.
  • ChildItemGuid-In the hierarchal structure this Guid represents the Child to the Guid in the ParentItemGuid column.
  • Hint-This provides what type of relationship this row represents.
  • ReferenceType
  • CreatedDate-Date the Row appeared.
  • ModifiedDate-The last time this row was modified.

The following is a list of Hints, or relationship types within the table commonly used by Software Delivery Solution. Note that most Solutions create their own 'types'.

  • folderchilditem-The ParentItemGuid is the Folder the ChildItemGuid object resides in, whether hidden or shown in the Altiris Console.
  • installercontainsapplication-Used with Application Inventory.
  • notification policy uses report-If a Notification Policy is linked to a Report, this Item reference does the linking.
  • npmessagefilter-Used with Notification Policies.
  • npmessagesubscriber-Used with Notification Policies.
  • packagecontainsprogram-All Programs are linked to their Parent Package by these rows.
  • policyappliestocollection-All Collections assigned to a Task are linked by these rows.
  • sequentialswditem uses active synchronization item-If a secondary Sequential Task is created where an included item already exists in another Sequential Task, this item links the new task with the existing item, avoiding duplicates.
  • shortcut-Used for Shortcuts created within the Altiris Console.
  • softwarerequestcreatedswdtask-Tasks created by the Software Portal contain this item.
  • softwarerequestforprogram-Ties the Portal-created task to the Package/Program requested.
  • swdadvertisement uses swdpackage-Links a Task to a Package.
  • swdadvertisement uses swdprogram-Links a Task to a Program.
  • swritem uses advertisement item-Ties the hidden Task within a Software Portal Settings Task to the parent Task.
  • swritem uses program item-Ties the hidden Program used by the Software Portal Settings Task to the Task.

The following examples show what types of relationships exist for the specified item:

Software Delivery Package/Program:

Querying the Guid of a Package in the ChildItemGuid column:

SELECT * FROM ItemReference
WHERE ChildItemGuid = '053effa6-130e-45b5-b959-100f9a499f8b'

This object represents what "Folder" this Package Resides in for the Notification Server. By querying the ParentItemGuid we find that this is the console location: Resources tab, Resources, Software Management, Software Delivery, Windows.

Querying the Guid of a Package in the ParentItemGuid column:

SELECT * FROM ItemReference
WHERE ParentItemGuid = '053effa6-130e-45b5-b959-100f9a499f8b'

This object represents the Package's relationship to a corresponding Program. If this package had two programs associated with it, two rows would have resulted with the hint packagecontainsprogram.

Software Delivery Task:

Querying the Guid of a Task in the ChildItemGuid column:

SELECT * FROM ItemReference
WHERE ChildItemGuid = 'f8664b82-eb28-4201-b773-82bbdb9e4ab8'

This object represents what 'Folder' this Task resides in for the Notification Server.

Querying the Guid of a Task in the ParentItemGuid column:

SELECT * FROM ItemReference
WHERE ParentItemGuid = 'f8664b82-eb28-4201-b773-82bbdb9e4ab8' 

These examples demonstrate the function and importance of the ItemReference Table.

Conclusion

I believe 6.x will still be used for some time. Making this document available on Symantec Connect will help inform the community of this Best Practices Resource.

Comments 9 CommentsJump to latest comment

KSchroeder's picture

Excellent work again Joel, very informative!  I wish we had this document when we first started with Altiris 5 years ago! :)

Thanks,
Kyle
Symantec Trusted Advisor

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.

0
Login to vote
fogginj's picture

Is it possible to have a button to save the document as a PDF file?

0
Login to vote
KSchroeder's picture

fogginj,
Just download a PDF printer (such at CutePDF), click the "Print" icon below the main article, then print to the PDF printer.

Thanks,
Kyle
Symantec Trusted Advisor

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.

0
Login to vote
bigi's picture

I don't see a print button at the end of this article to print.  Am I missing something?

0
Login to vote
ohzone - CherylPeterson's picture

There's a small icon at the bottom of the article next to "email this page" that looks like a printer - that's the "print" button

Good luck!

Cheryl

Endpoint Management,
Endpoint Virtualization
Managing Mobility
Community Manager
www.twitter.com/EMnV_symc
Need Altiris help? IRC chat #Altiris

0
Login to vote
bigi's picture

Thanks for this info; certainly could have used it when we first started using Altiris.  However, it is most helpful now as well.

0
Login to vote
Seamless's picture

Very good article, thanks for putting it together.

Some parts of the console make no sense to me. Perhaps someone can provide the technical explanation:

Starting window Normal or Hidden: if I run an msiexec with /qn then there is no user interface. If I run it without then there is. How does Starting Window affect this? Similarly if I run a setup.exe /silent (assuming it has a silent mode) then there is no interface. I don't follow how Starting Window can affect the execution of an msi or an exe that is configured to be either silent or not silent.

"User Input Required" seems to equate to Interactive=true. If an installation is not silent, it will require user input. If an installation is silent, there will be no interface to provide input. So I don't know what this setting can mean.

So it seems to me that the way the program runs will be controlled by the command line, and the settings here can't make any difference. There may have been some legacy reason for the settings, but not now. Any comments on that?

0
Login to vote
KSchroeder's picture

Hi Seamless,

A bit (OK a year) after the fact...but I understand your confusion.  The Hidden/Normal/Minimized option really is more generic.  Sure you can run your command line in a hidden way (at least as far as MSIExec is concerned, no progress bar, etc), but if it were to throw an error or dialog, that window would also not be displayed unless you have it set to Normal (or Min/Maximized).  If it is hidden and /qn, and there is a dialog, it will be invisible to the end user of the machine and will probably timeout the job at the end of your maximum run time setting for the Program.

What I've found with User Input Required is a few things...if there is something you want displayed, and that box is NOT checked, then the user won't see it.  Also you get "weird" results sometimes if the box is not checked.  If you set it to Yes, then it impacts the way in which the package can run (i.e. "Only when no user is logged on").  My "best practice" is to set UIR to Yes always.

You're right; I think a lot of these options are legacy from when you might want to run a .bat file to install something, but hide the window (or run it minimized) to keep the user from closing it before the task finished.

Thanks,
Kyle
Symantec Trusted Advisor

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.

0
Login to vote
KSchroeder's picture

Hi Joel,

To confirm, if you uncheck Verbose Package Status on the Package Advanced tab, NO data will be show up in Inv_AeX_SWD_Package_Summary or Evt_AeX_SWD_Package tables? I can understand not wanting to receive all the Start events, but there will be NO record at all that the machine downloaded the package? I'm working on a report to track package downloads by site (to justify the need for package servers) and some of the numbers seem a bit low, and just trying to figure out if it is a configuration problem on some of our packages or truly just lower utlization that I had expected.

Thanks!
Kyle

Thanks,
Kyle
Symantec Trusted Advisor

For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.

0
Login to vote