Retain Worker Configuration Setup
The Retain Worker is a slightly confusing concept because we use the same words for more than one thing.
When we are talking about the Worker it is generally dependant on the context of what we are talking about and that is not always obvious.
- There is the Retain Worker which you install with the Retain installer which I will label the Worker Agent
- There is the Retain Worker which you create in the Retain Web Console which I will label the Worker Web Object
- You link them together with the bootstrap
- You link the Retain System to the Email System with the data in the Module Configuration
Contents |
Worker Agent
When you install Retain you have the option of choosing to install a Worker. This installs the Worker Agent software on the server. You can install just the worker, given that there is a Retain Server somewhere for it to connect to.
The worker agent can be installed on:
- the Retain server itself
- the email server
- a dedicated worker server
Retain Server Worker
Installing the worker on the Retain server makes for a simple, self-contained setup. It does have the disadvantage of having to transport all messages from the email server even if the message has already been archived in Retain. This is the most common setup.
Email Server Worker
Installing the worker on the email server will save on network bandwidth since the worker will only transmit messages that have not been archived already.
Dedicated Worker Server
Installing the worker on a dedicated worker server is something that is done if there is a need for many additional workers. For example, they have many email servers, and the customer does not want to install workers on the email servers themselves. This does have the additional advantage of making upgrades easier.
Worker Web Object
Once you have configured a module you will be able to configure a worker. How to Create a Retain Worker
What you are doing here is entering the data needed for the Worker to connect to the Retain Server, which you will transfer to the Worker Agent with the bootstrap.
Name
Give the worker a good name. One that makes it obvious that it does and where it is.
If it is a remote worker, which is what we call a worker that is on another server, provide the location in the name. There are few things more difficult than trying to find a worker on another server when the sysadmin does not know where it is. Often it is on the email server, but if there are many of them determining which one is a slow process.
On my test system, I often have many workers local and remote connected to different email systems, so I need to be able to find them easily. So I give them names like:
- Worker0 GW local
- Worker1 EX local
- Worker GW remote TestPO1
- Worker3 GoogApp remote WorkerServer2
Polling
The default is fine, though if you end up going into the logs often it is good to set the Poll for 60 min so the log isn't cluttered with configuration information.
Logging
Make sure this is set to Diagnostic. Nothing is more annoying than to have to ask a customer to rerun the job because the log did not contain enough information since it was in Normal or Error Only mode.
Connection
This is the important part. This is how the Worker and especially a remote worker on a separate server knows how to connect to the Retain server.
Module specific
For Groupwise, you can set the location of the POA if it is different from the one in the module, useful if there are multiple post offices.
For Exchange, you can set the AD site if that is different from the mail server.
Status
Gives you information about the worker
Bootstrap
Which only appears after the worker is saved.
You need to save the bootstrap file (RetainWorker2.cfg by default but you can rename it if you want) and then go to the worker web console (http://[worker server host]/RetainWorker for the first worker or http://[worker server host]:48080/RetainWorkerN for any other workers) upload the bootstrap and log into the worker web console.
Multiple Workers
The larger or more complex the email system the more workers you are likely to need.
The goal of any archiving system is to archive the day's new data in less than a day. Sometimes in large systems, this is not possible, then we split up the work with multiple workers running in parallel. The limits on multiple workers are more the network bandwidth and disk IO on the server than anything else. Each worker requires about 1GB of RAM.
Additional workers can be placed on the Retain Server, on each of the email servers or on their own server or servers.
How to deploy workers depends on the network topology. If an organization has many branch offices each with their own email server it makes sense to add a worker to each of those servers or on a server at that branch. The worker generates a hash and sends the hash to the Retain server if the hash exists the worker can drop the message body part that matches and just send the headers since it already exists and moves on to the next message. This saves network bandwidth.
KnowledgeBase Articles
- How to Create a Retain Worker [1]
- Installing Multiple Workers On the Same Server (Linux) [2]
- Installing Multiple Workers On the Same Server (Windows) [3]
- Tool for Creating Additional Workers on Windows [4]
Return to Retain Training
