After moving a user to a new post office, the archive job is attempting to archive the entire mailbox as if an archive job had never been run on that mailbox. Why is that?
When the user gets moved from one PO to another, the GroupWise digest retention time (a.k.a., "retention flag") gets cleared out of the user database. When Retain runs, most customers (recommended) have the job profile set to have the begin date/time of the archive job to key off of the retention flag. Since that flag had been cleared by GroupWise during the user move, Retain had no date/time to go by so it had to request all items from the mailbox.
Another issue that arises from Retain archiving the entire mailbox again is that any re-processed item that already exists in Retain will get duplicated in the Retain database, causing the mailbox to display duplicate items. This does not result in any increase in disk space in the Retain archive though. Retain keys off of a message/attachment's hash value to determine whether the file is unique and needs to be stored on disk. Since the contents of the messages/attachments do not change during a move, Retain is able to determine that it already has it on disk; however, because the domain and the PO constitute part of the message ID, Retain sees the message as unique and stores its metadata in the Retain database, which causes the duplicate entries in the mailbox. See "Where Data Is Stored in Retain" for a more complete explanation.
To avoid this from happening, an administrator should make note of what the retention flag is set tobefore moving the user; then, once the move is complete - and before running an archive job - refresh the Retain address book (so that it knows of the new PO assignment) and set the retention flag to the value it had prior to the move.
This article was originally published in the GWAVA knowledgebase as article ID 2429.