After you have installed the GWIA in a cluster, you should consider some long-term management issues.
After installing the GWIA 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 GWIA domain:
In ConsoleOne, browse to and right-click the Domain object, then click .
In the field of the GWIA domain Identification page, provide a cluster-specific description of the GWIA domain, including the secondary IP address of its GroupWise partition.
Click to save the GWIA domain description.
Select the GWIA Domain object to display its contents.
Right-click the MTA object, then click .
In the field 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.
Click to save the MTA description.
Continue with Recording Cluster-Specific Information about the GWIA.
With the contents of the GWIA domain still displayed in ConsoleOne:
Right-click the GWIA object, then click .
Click , then click .
In the field, record the secondary IP address of the GroupWise partition where the GWIA domain is located.
This information appears on the GWIA console, no matter which node in the cluster it is currently running on.
Click to save the GWIA information.
Continue with Knowing What to Expect in an GWIA Failover Situation.
The failover behavior of the MTA for the GWIA domain is the same as for an MTA in a regular domain. See Section 3.6.2, Knowing What to Expect in MTA, POA, and DVA Failover Situations.
Failover of the GWIA itself is more complex. The various clients (POP3, IMAP4, and LDAP) receive an error message that the node is not available. Most of the clients do not attempt to reconnect automatically, so the user must exit the client and restart it to reestablish the connection after the failover process is complete. Fortunately, the GWIA restarts quickly in its failover location so users can reconnect quickly.
As with the MTA, the POA, and the DVA, migration of the GWIA takes longer than failover. In fact, the GWIA can seem especially slow to shut down properly as it finishes its normal processing and stops its threads. For a busy GWIA, you might need to wait several minutes for it to shut down properly.