After you have installed the WebAccess Agent in a cluster, you should consider some long-term management issues.
After installing the WebAccess Agent in your clustered GroupWise system, while the cluster-specific information is fresh in your mind, you should record the cluster-specific information as part of the GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the information in the GroupWise objects if the configuration of your system changes.
To permanently record important cluster-specific information for the WebAccess Agent domain:
In ConsoleOne, browse to and right-click the Domain object, then click.
In the GroupWise partition.field of the WebAccess Agent domain Identification page, provide a cluster-specific description of the WebAccess Agent domain, including the secondary IP address of its
Clickto save the WebAccess Agent domain description.
Select the Internet Agent Domain object to display its contents.
Right-click the MTA object, then click.
In thefield of the MTA Identification page, record the secondary IP address of the GroupWise partition.
This information appears on the MTA console, no matter which node in the cluster it is currently running on.
Clickto save the MTA description.
With the contents of the WebAccess Agent domain still displayed:
Right-click the WebAccess Agent object, then click.
Click, then click .
In the GroupWise partition where the WebAccess Agent domain is located.field, record the secondary IP address of the
This information appears on the WebAccess Agent console, no matter which node in the cluster it is currently running on.
Clickto save the WebAccess Agent information.
The failover behavior of the MTA for the WebAccess Agent domain is the same as for an MTA in a regular domain. See Section 14.6.2, Knowing What to Expect in MTA and POA Failover Situations.
When the WebAccess Agent fails over, the WebAccess client user sees the following message:
Unable to communicate with the GroupWise WebAccess Agent
The user just needs to be patient. When the WebAccess Agent comes up on the next node, the user can continue working without logging in again.
If the POA for the user’s post office fails over, the WebAccess client becomes unresponsive, but there is no error message. Again, the user should be patient until the POA comes up on the next node. Then the user can continue working without logging in again.
As with the MTA and the POA, migration of the WebAccess Agent takes longer than failover. In fact, the WebAccess Agent can seem especially slow to shut down properly as it finishes its normal processing, stops its threads, and stops the Document Viewer Agent. For a busy WebAccess Agent, you might need to wait several minutes for it to shut down properly.