KNOWN ISSUE: The Schedule Description in the SWDAdvertisement table is not properly updated

Article:TECH39873  |  Created: 2008-04-28  |  Updated: 2008-04-28  |  Article URL http://www.symantec.com/docs/TECH39873
NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.
Article Type
Technical Solution

Issue



When an advertisement is created manually, it will update the Schedule Description table with some value. For example, if the advertisement is supposed to occur as soon as possible, then the column is updated with "As soon as possible". When creating the advertisement through the Administrator SDK, this column in the table is not updated as expected; so if there are reports written against this information, they will display blank lines.

Environment



Notification Server 6 SP3 R7
Administrator SDK 1.4

Cause



The text "As soon as possible" appears to be a hard coded value. When the Apply button is selected, the trigger type in the schedule XML is being tested for a -1 value and the hard value "As soon as possible" as being set into the database. That's from the Notification Server UI perspective. This has been verified through the profiler and the explicit string is seen.

From a programmatical perspective, what the underlying Software Delivery library is doing is looking at the schedule date and using a dynamic string to set that ScheduleDescription. Passing an invalid value into the schedule XML I can see the following in the ScheduleDescription, "At {STARTTIME} on {RUNONCESTARTDATE}".

This implies that the path to storing the information is different between the Notification Server UI and the underlying Software Delivery library.


Solution



While there isn't a resolution to this issue the following is suggested:

SWDSolnAdvertisementDetails advertisementObject = advManager.CreateAdvertisementEx(
 false,
 name,
 "This is the description of this advertisement",
 SWDWindowsTasksFolderGuid,
 packageGuidString,
 programGuidString,
 AllComputersCollectionGuid,
 "Normal");

advManager.SetAdvertisementExAgentSettings(
 advertisementObject.Guid.ToString(),
 false, true, false, true,
 "10 KBytes/second",
 "1 KBytes/second",
 true, false
 );

advManager.SetAvailabilityRemovalOptions(
 advertisementObject.Guid.ToString(),
 true, "2008-01-01 08:00", false, "2009-01-01", false
 );

string scheduleXML =
@"<clientSchedule allowIndependentExecution='true' allowScheduleRetry='true'>
    <Schedule IndependentExecution='true'>
    <Trigger Type='-1' Description='Trigger type -1: Run as soon as computer is notified (only runs once)'>
    </Trigger>
    <Trigger Type='0' Duration='0' Interval='0' KillAtEnd='0' Disabled='0' Description='Trigger type 0: Run on a schedule'>
    <BeginDate>2008-01-01 01:00:00</BeginDate>
    </Trigger>
    </Schedule>
    </clientSchedule>";

advManager.SetAdvertisementExScheduleScheduleXML(advertisementObject.Guid.ToString(), scheduleXML);

As shown in this code snippet, the scheduleXML is being used to directly set information into the advertisement. The <BeginDate> tag can be set to any (valid date/time) value that could be used as a trigger. So perhaps if the choice were made to use a date format would be defined as unique in the environment then advertisements defined in this way could be properly identified as Administrator SDK created advertisements.

As an additional note, the Administrator SDK method, SetAdvertisementExScheduleRunASAP, will also set information into the Schedule Description but it will always contain the current date. In either case, these methods, SetAdvertisementExScheduleRunASAP and SetAdvertisementExScheduleScheduleXML, must be run last in the advertisement creation.


Supplemental Materials

SourceDEFECT
ValueLB 67776
DescriptionLogged in Littlebuggy (Altiris - Lindon, Plymouth) database

Legacy ID



41487


Article URL http://www.symantec.com/docs/TECH39873


Terms of use for this information are found in Legal Notices