As mentioned in the preceding section, before GroupWise 7 your GroupWise system had no way to automatically redirect the outgoing SMTP messages from one GWIA to another when the primary GWIA was unavailable. And the reason was pretty simple: The MTA that was forwarding these messages to the GWIA simply dropped the messages in a directory to be picked up by the GWIA and could therefore not easily see that a GWIA was not functioning anymore. This could also mean that on your MTA console screen all gateways seemed to be in an "open" state, though one of them was actually down. But that has all changed with GroupWise 7. The MTA can now communicate with the GWIA over IP via MTP (message transfer protocol), much like the MTA and the POA already use. And as soon as the MTA detects that the GWIA is not available, it can redirect the outgoing SMTP message stream to an auxiliary GWIA, if created and so defined. This great new functionality is a welcome addition to the preceding section and really finishes everything off. Let's take a closer look at this. First we assume that you've already created an additional domain on a separate server. You also have installed the MTA and GWIA software on this box and have configured all the necessary details, as described in Chapter 10 and the preceding section in this chapter. For this example, we assume that the internal server name is WWWFS2, the external hostname is mx2.wwwidgets.com with IP number 137.65.55.212, and all the necessary DNS entries as described in the previous sections have been created. If not, there is no use to read on; you need the additional domain properly configured to be able to use this successfully, so be sure to take a look at these earlier sections first. The next step you need to take is to make sure that all of your GWIAs communicate with their MTAs via TCP/IP using MTP (message transfer protocol). This is very important, because this is the only way a MTA can properly detect whether a GWIA is running. If you use the older direct access mode, in which the MTA writes files to a subdirectory to be read by the GWIA or vice versa, there is no way the MTA can see whether the GWIA is still running properly. Checking to Make Sure That MTA and GWIA are Using MTPWe assume that you've upgraded all of your GroupWise domains, post offices, and the corresponding agents and gateways to GroupWise 7. If not, at least the domains where your GWIAs reside need to be on GroupWise 7. You can easily check this:
Note In some cases we've noticed that ConsoleOne does not show the correct property screen for the network address of your GWIA, even if you upgraded the GroupWise 7 GWIA code. In most cases this has been the case with GWIAs that have been upgraded from previous versions. In the domain database and thus in ConsoleOne, for whatever reason, the version of the GWIA is still on version 6 or 6.5. All you need to do is to make sure that the GWIA is indeed using GroupWise 7 code and then change the version in ConsoleOne to version 7. After you close the GWIA object and reopen it, you should be able to see the correct version as version 7.
In Figure 32.4 you can se e the details for the closed GWIA, including the Hold directory. In the old days, all the MTA could do was drop all outgoing message files temporarily in this holding directory, but when you finish the tasks in this section, the GroupWise 7 MTA should be able to find an alternative outbound route to the Internet. Figure 32.4. The MTA showing the details of a closed connection to the GWIA, including the Hold directory where all delayed message files will be stored if no alternative GWIA is configuredConfiguring Your Domain to Use an Alternative GWIANow that you've checked all the prerequisites in the preceding section, you can enable the option to use an alternative GWIA with the following steps:
And that's all. You can easily test your setup by bringing your primary outbound GWIA down, after which all outgoing messages should be transferred via the alternative outbound GWIA. Note A few remarks: First of all, note that you can (currently) specify only one alternative GWIA. If this GWIA is also not available, your MTA will have to store all messages in the Hold queues. Second, your MTA will communicate to the alternative GWIA via IP, so make sure that the MTA from your domain is indeed allowed to communicate with this GWIA. Check the firewall and correct the settings if necessary. Third, the MTA will not transfer any already stored and older messages from a Hold directory to the alternative GWIA. If for whatever reason there are messages in the Hold directory for the primary GWIA, these will be processed only if your primary GWIA comes back online (or you should manually move them to the correct location). |