test

Message Archiving Using the Sun Compliance and Content Management Solution

Setting Up An Operational Deployment

Setting up operational archiving consists of two primary steps. In the first step you define what messages are to be archived using the imexpire command. The second step involves specifying what to do with the messages in the message store after archiving has occurred. That is, should the messages be replaced with a stub or not. This is specified using the imarchive command.

ProcedureConfiguring the Messaging Server

  1. Make sure the Archive Server has been installed and configured as per the AXS-One Server Manual.

  2. Make sure that the Archive and Messaging Server system users belong to the same UNIX group.

    The AXS-One UNIX system user name is axsadm. The Messaging Server UNIX system name is typically mailsrv. Both need to be in the same UNIX group. See Creating UNIX System Users and Groups in Sun Java System Messaging Server 6.3 Administration Guide for details on how to do this.

  3. Set up a shared directory for messaging archival.

    The staging directory can be a local or NFS mounted drive.

  4. Ensure that the message store configutil parameters are correctly set.

    store.archive.operational - Enables operational archiving. Set to ON.

    store.msghash.enable - Enables message hash indexing. Must be set to ON for operational archiving.

    store.archive.path - This is the staging folder, the directory shared by the Archive Server and Messaging Server to pass messaging files for archiving. This is the directory defined in the earlier step.

    store.archive.reportdir - This is the directory used by the Archive Server to pass archiving reports back to Messaging Server. These reports are used by the imarchive command to determine when it can replace the message content on an email with a URL stub. This directory is also specified on the AXS-One side and this parameter must match that value.

    store.archive.retrieveserver - This is the fully qualified name of the Archive Retrieval Server that passes archived message text to Messaging Server or AXS-One client. This is the web server on which SunJesRetrieveEML.asp is enabled.

    store.archive.retrievetimeout - Specifies how many seconds to wait for the archive server to return a message before timing out. Default is 30.

  5. If stubbing is required, set MESSAGE_HASH_FIELDS to * in option.dat file

    Example: MESSAGE_HASH_FIELDS=*

  6. Specify the message archive policy.

    Operational archiving can archive messages by folder, user, domain, number of messages in mailbox, age of messages and so on. Use the imexpire interface (see To Set the Automatic Message Removal (Expire and Purge) Feature in Sun Java System Messaging Server 6.3 Administration Guide to define the messages to be archived. The action attribute of the expire rules should be set to archive as follows:

    action: archive

  7. Use imarchive to specify what to do with archived messages in the message store.

    After the AXS-One server archives an email message, it sends a confirmation message to the archive report directory with the document ID. At this point, the email message is safety archived and the email message on the message store can be replaced with a stub by running imarchive.

    Be sure to run imarchive after AXS-One has processed all the messages. If imarchive is run before the messages are processed, those messages could get expired again. There are a couple of ways to ensure that this won't happen. The first is to run imarchive before imexpire. For example:


    # /bin/sh
imarchive -s
imexpire

    The other way is to simply make sure enough time has passed between running imarchive and imexpire. Use local.schedule.taskname for this (see To Schedule Automatic Tasks in Sun Java System Messaging Server 6.3 Administration Guide). In the example below, imexpire is run daily at 1:00am and imarchive is run daily at 3:00am, replacing message text with stubs:


    configutil -o local.schedule.expire -v "0 1 * * * /opt/SUNWmsgsr/sbin/imexpire"
configutil -o local.schedule.archive -v "0 3 * * * /opt/SUNWmsgsr/sbin/imarchive -s"

ProcedureTesting Your Operational Archiving Deployment

  1. Set up the shared directories and the configutil variables as described in the previous section.

  2. Create a simple test imexpire rule file with archive as the action.

    Example:


    test.folderpattern: user/*
  test.messagesize: 1
  test.action: archive

  3. Run imexpired –d -f rule_file -utestuser and observe the output in stdout.

  4. Verify if the staging directory contains *.info, *.body.txt, and *.eml files.

    If these files exist on the staging directory, then the system is working on the messaging side.

  5. Invoke the AXS-One extractor command to process the files in the staging area.

  6. Check the report files under the report directory.

  7. Run imarchive -v -s

  8. Validate the stubbed messages with a mail client.

ProcedureAdministering, Maintaining and Monitoring Your Compliance Archiving Deployment

  1. See the AXS-One documentation.

ProcedureTroubleshooting Your Operational Archiving Deployment

  1. Make sure that the Archive and Messaging Server system users belong to the same UNIX group.

  2. Verify that the imexpire is properly configured to capture the message stream you wish to archive.

  3. Verify that the configutil parameters are set correctly.

  4. Check to see if there are any error messages in the default log file.

    Logging must be enabled (see Enabling MTA Logging in Sun Java System Messaging Server 6.3 Administration Guide).

  5. Verify that the staging directory and report directory have rwx permissions to the mail server user (example, mailsrv) and the AXS-One user (example, axsadm).

  6. Verify that the imarchive command is configured properly.