Unexecuted Software Portal Tasks and associated collections are never purged
|Article:TECH32448|||||Created: 2007-07-23|||||Updated: 2008-02-20|||||Article URL http://www.symantec.com/docs/TECH32448|
I have over 660 active Software Portal tasks and associated collections that have never been run on users' computers. Most of these are months old. The purge mechanism does not clean these out. As a consequence, it puts an unnecessary burden on the collection update tasks.
Notification Server 6.0 SP3 R5
First of all, there is a one too many relationship when it comes to the collection. The collection may have many Software Portal tasks assigned to it. Each time a user accesses the Software Portal from a computer and selects software to run, it will not create a new collection if one already exists for this computer, but creates the software tasks and associates them with the collection.
We do not want to delete the collections until all software portal tasks associated with the collection have been deleted first.
Second, the purge process doesn't look at the ItemAtive table at all. It determines if the task has been successfully run by looking at the status data in the evt_aex_swd_execution table to see if there is a value of "command executed". This means the process will only purge these items if and when they execute and return a "command executed" code.
When a software portal request is made two items are created:
- "Software Request - program name", which has a class ID of A99676F7, is the SoftwarePortal. SoftwareRequest.
- "Software Request - program name", which has a class ID of 50f74aa5, is the SoftwarePortal.SWRAdvertisement.
The first item is the parent of the original software program and of the second item. The second item is the parent of the SWRCollection and also of the original software program. The second item is also the child of the Hidden SWD Internal Folder.
Use deleteitems.exe with the following query:
select i3.guid [Software Request ID]
from item i1
join itemreference i2 on i1.guid = i2.childitemguid
join item i3 on i2.parentitemguid = i3.guid
join itemactive i4 on i2.parentitemguid = i4.guid -- If this is missing then the SWD Internal folder is also selected
where i1.name like 'swrcollection%'
and i2.modifieddate < '6-01-2007' -- change this date to the desired expiration date
This process deletes the second item, which is the program (task) in the hidden folder. It also deletes the first item during the deletion process and disassociates the collection from the task which allows the Software Portal process to purge this using the normal process.
A feature request is created to allow the administrator to set an expiration date on these tasks so that they will be purged by the internal process.Warning: Place the query in Notepad* and remove any carraige returns prior to pasting this into the command line with deleteitems.exe. Failing to do so could cause the process to read a concatenated version of the query thus deleting items that you don't intend to. Note on DeleteItems: DeleteItem.exe and DeleteItems.exe are a couple of utilities that can be used to delete items from the Altiris database tables. Normally these files in the zip folder are copied into the Program Files\Altiris\Diagnostics folder on the NS. A CMD window is opened and the path is changed to the location where these files are located. DeleteItem deletes one resource at a time based upon a guid that is entered on the command line. Deleteitems.exe deletes multiple resources at a time based upon a SQL query entered also on the command line. Running these executeables without any command line options will produce the syntax on their usage. Take note on the warning given above regarding deleteitems. Extreme database damage can be caused if the query is not read properly on the command line. Examples:
Deleteitems <sql query>Note: Attached is DeleteSWRPackages.zip file that contains a script that can be used instead of the deleteitems method. Copy this into the Altiris\Diagnostics folder and use the command line "nscript deleteswrpackages.cs". You will need to edit the SQL within the script. The date at the end of the query should be modified at each run time to represent the cut off time for what packages should be deleted.
Article URL http://www.symantec.com/docs/TECH32448