Older GroupWise mailboxes were not meant to scale to sizes typical of what is seen today. It's quite possible, in this day and age, to have more mail than the original indexes could handle, which is 64K items per folder. If a mailbox exceeds that limit queries performed against it will return inconsistent and incomplete results, perhaps resulting in errors such as: found error when accessing quick msg. an unknown error occurred.
When an account exhibits this behavior it's worth running a GWcheck to review the indexes for corruption and to verify whether the account has a very large number of emails, exceeding the limits specified above (bear in mind that in GroupWise the Inbox & Sent Items are actually stored in the same folder). If so, then it is necessary to change the archive job's normal filtering process by manually editing the policy in eDirectory. Specifying 'BruteForce', as described below, will instruct the job to bypass the GroupWise indexes and directly read the messages from the store in a sequential fashion. Naturally, this will take more time (since the job must read every message in the mailbox to match it against the policy) but it will result in a much more comprehensive run and it won't be derailed by misbehaving GroupWise indexes.
The Brute Force approach does not work on SOAP API. The system must be set to use the Object API for archiving.
After setting the API:
- Using an LDAP browser, connect to the eDirectory hosting the Netmail Archive containers and find the policy you are using on your job (should be under ou=GWOpenProfiles)
- Edit the maType attribute to be BruteForce (NB: case sensitive)
- Ensure that the changes are saved, and the policy is selected on the job
- Run the job