Environment
Novell GroupWise 8
Novell GroupWise 2012
3rd Party Operating Systems and Products
Situation
Companies are running a 3rd party product that does message retention and backup. The backup flag on the GroupWise system is not set however the Retention flag is being set by the 3rd party product. Users are unable to delete any messages or empty their trash folder
Resolution
Running the GroupWise Timestamp utility to manually change one of the timestamps, usually corrects the problem. The logic from the code is to:
-
get the user's backup time (NGW_DATE_BACKUP_TIME)
-
get the users' retention time (NGW_DATE_LAST_DIGEST_RETENTION_TIME)
-
get the user's digest modification time (NGW_DATE_LAST_DIGEST_MODIFIED_TIME)
It has been found that the NGW_DATE_LAST_DIGEST_MODIFIED_TIME field was being updated with the current date every time the backup/retention job was run. By clearing this date manually, users were able to delete their messages and purge their trash. We do not provide any software that sets or clears this value outside of the manual running of the Timestamp utility. This value must be set by the 3rd party software / vendor.
Note to 3rd party retention implementers:
You own these timestamps and there is no provision for sharing them or having your own set. Therefore, off of the account object, you should consider all three values/calls to be a trio:
-
put_LastModifiedRetentionDate
-
put_LastretentionDate
-
put_LastBackupDate
Set the values that you want honored in all three. an item will not purge if it has a delivery/create time that is newer than either of the values placed into:
-
put_LastRetentionDate
-
put_LastBackupDate
If an item is modified significantly (personal note added, subject overridden, etc) then it will also not purge until the date of that modification is older than the value in put_LastModifiedRetentionDate.
This gives three distinct behaviors that the 3rd party vendor can choose:
-
To place 0 into put_LastModifiedRetentionDate and never care about significant modifications
-
Place the same time into both put_LastMOdifiedRetentionDate and put_LastRetentionDate and set the code to retain the time a second time
-
Have a special "dredge" or "sweep" for significantly modified items and have two independently set times and enforced times.
Note to Customers - until the 3rd party vendor implements this, the timestamp utility can be used to display, set and clear the modified retention timestamp. Details about this can be found in tid 7005274
Additional Information
In GroupWise there are three separate timestamps: backup, retention and retentionModified. If the Smart Purge option is enabled, the code will prevent an item from being purged if one or multiples of the timestamps are set and the item does not pass the time limit. If retention is enabled, it will prevent an item from being purged if the retention or the retentionModified timestamps are set and the item does not pass the time limit test.
In the GroupWise client: If a user tries to purge an item and the smart purge is enabled, the code will compare the backup timestamp with the delivered / created time of the time. If the time is after (later) than the timestamp, the item will not be purged. If a user tries to purge and item where the retention option is enabled, the code will compare the retention and retentionModified timestamps with the delivered / created time of the time. If the time is after (later) than the timestamp(s), the item will not be purged.