The "Maintain trends database record" request is executed as part of a mail file move initiated due to resource balancing initiated by the Activity Trends tool.
Check mail server's access
Carried out on: Home server for the mail file as designated in the Person document.
Carried out: Immediately
Result: Checks for a Connection document between the old and new mail file servers, and sets up the ACLs so that the old and new servers have Manager access. If it is the administration server of the mail file, posts the "Create new mail replica" request. If it is not the administration server for the mail file, posts a "Promote new mail server's access" administration request.
Carried out on: Destination server.
Result: Verifies whether the destination server hosts the hosted organization to which the user belongs. Generated the "Create new mail replica" request.
Carried out on: The administration server of the mail file.
Result: Set up the ACLs so that the old and new mail servers are listed as having Manager access. Posts a "Create new mail file replica" administration request.
Result: Creates a replica copy of the old mail file on the new mail server. If Activity Trends is not running on the source server, posts the "Add new mail file fields" request. If Activity Trends is running on the source servers, posts the "Maintain Trends database record" request on the source server.
This request is generated only when there is an agent of the source server that needs to be signed by the destination server prior to running the agent.
Carried out on: The destination server.
Result: If all access checks succeed, the agent is signed by the destination server and can be run according to normal processing.
Carried out on: The source server for the mail file being moved.
Result: Copies the database record from the source server to the destination server. If appropriate, it retires the database record on the source server.
Carried out on: The administration server for the Domino Directory.
Result: Posts the "Monitor new mail file fields" administration request. Creates two fields, "New mail file" and "New mail server" in the Person document.
Carried out on: The new mail file server.
Carried out: When the router recognizes the new mail server for the mail file.
Result: Verifies that "New" fields are added to the Person document on the new mail server and that the router can route the mail to the server. Posts the "Replace mail file fields" administration request.
Result: New mail server information is added to fields. Removes "New" fields from the Person document. Places "Old Mail File" and "Old Mail Server" fields in the Person document. The server sets a flag in the Person document to update the client.
Push changes to new mail server
Carried out on: The home mail server.
Result: Pushes the last set of changes and mail to the new mail file. Posts the "Get file Information for Deletion" request.
Carried out on: The old mail server.
Carried out: According to the "Interval" setting in the Administration Process section of the Server document.
Result: Gathers the replica ID of the mail file and posts the "Approve file deletion" administration request.
Carried out on: Any server.
Carried out: According to the administrator's discretion.
Result: Posts the "Request file deletion" administration request.
Result: Posts the "Delete mail file" administration request.
Carried out on: The original home mail server.
Result: The old mail file is deleted from the original home mail server.
Carried out: According to the "Interval between purging mail file and deleting when using object store" setting for the Administration Process in the Server document.
Result: The Administration Process deletes the mail file after waiting a period of time. This delay provides time for the Object Collect task to purge any obsolete messages.
Carried out: According to the "Execute once a day requests at" setting for the Administration Process in the Server document.
Result: New mail client update flag field is removed from the Person document.