Using Multiple GWIAs for a Redundant SMTP Stream for Outgoing Messages


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 MTP

We 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:

  • In ConsoleOne, go to your domain object and open the properties. On the first page called Identification, you should check the property called Database Version, which should read 7. Be sure to check that this is indeed GroupWise 7 for all domains that contain GWIAs.

  • The next thing you should check is whether the GWIA is indeed configured with the correct properties and whether the MTP port called Message Transfer is configured correctly. In ConsoleOne, open the properties of your GWIA and go to GroupWise, Network Address, as shown in Figure 32.2. In most cases the value for this port will be something like 7102, but it can be any free port. Be sure to check this for all of your GWIAs.

    Figure 32.2. In ConsoleOne, this GWIA is showing a properly configured MTP port; in this case Message Transfer will be via port 7102


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.


  • You need to check only one more thing: Does your MTA indeed communicate with the GWIA via IP? If your GWIA is not running, you can now easily see this on the console screen of your MTA, because your GroupWise 7 MTA will be able to detect that the connection to the GWIA is open or closed and will show that on the main screen. In Figure 32.3 the GWIA was not active and the MTA has marked the connection to one of its gateways as closed. This is a new feature of GroupWise 7.

    Figure 32.3. The MTA has not been able to open the connection to the GWIA, as can be seen in the upper-left corner, in the Gateways section


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 configured


Configuring Your Domain to Use an Alternative GWIA

Now 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:

1.

In ConsoleOne, go to the properties of the domain object that owns the primary outbound GWIA.

2.

Go to the Internet Addressing page; at the bottom you will find a property called Alternate Internet Agent for Outbound SMTP/Mime Messages.

3.

From the drop-down list, select the alternative outbound GWIA, as shown in Figure 32.5. Confirm your choice by clicking OK.

Figure 32.5. Configuring your domain object to use an alternative GWIA if your primary GWIA is not running


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).




NOVELL GroupWise 7 Administrator Solutions Guide
Novell GroupWise 7 Administrator Solutions Guide
ISBN: 0672327880
EAN: 2147483647
Year: 2003
Pages: 320
Authors: Tay Kratzer

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net