Loading the MTA

The GroupWise MTA requires certain information before it loads properly. Simply typing GWMTA.NLM from a NetWare server console results in an error message stating that required parameters are missing. There are two ways to provide the required parameters.

When the agent installation program ran on this server, you were prompted for some information. The installer used this information to create a startup file with all the information the MTA needs. The name of this file is the name of the domain, truncated to eight characters, followed by the .MTA extension (for example, CORP.MTA). If the installer ran more than once, the extension of the existing startup file was changed to .MT1, .MT2, and so on (depending on how many times you installed), and the new startup file retains the *.MTA extension. This is helpful if you need to review the original startup file for the MTA; note that it is not overwritten.

To use the startup file, load the MTA with the @ switch as shown here:

NetWare:

LOAD GWMTA @filename.POA

Thus, for the CORP domain, the command would be the following:

LOAD GWMTA @CORP.MTA

Linux:

/opt/novell/groupwise/agents/bin/gwmta @../share/filename.mta

Thus, for the CORP domain, the command would be the following:

/opt/novell/groupwise/agents/bin/gwmta @../share/corp.mta

Loading the MTA with Command-Line Switches

Another way to provide the MTA with the information it needs is to use command-line switches. On the Linux platform the leading slash (/) is replaced by a dash (-). Neither the parameter nor the value strings is case-sensitive for the NetWare or Windows MTA. On the Linux platform, switches and value strings are case-sensitive. A rule of thumb for the Linux MTA is to keep all switches and parameters lowercase. The only exception is the -home switch for the Linux POA. If the path to the post office's home does have any uppercase characters, this should be reflected in the home switch.

Any number of switches can be placed on the command line used to load the MTA, and they can even be used in conjunction with the @ switch described in the preceding section.

The only required switch for the MTA is the home switch, which gives the agent the path to the domain to be served. The syntax is as follows:

LOAD GWMTA /HOME=volume:\path

For a domain residing in the CORP directory on the MAIL volume of a NetWare server, the command line would look like this:

LOAD GWMTA /HOME=mail:\corp

For a domain on a Linux server, the syntax would look something like this:

/opt/novell/groupwise/agents/bin/gwmta home-/mail/corp

Learning the Switches

Almost all the switches the MTA will recognize are listed in the startup file. Any switch found in this file can be entered on the command line used to load the agent.

The section "Notable MTA Commands and Switches," found later in this chapter, includes a switch to turn off the Message Logging feature.

As indicated in Chapter 8, "Configuring the Post Office Agent," startup switches and startup files should be used only when a particular setting cannot be made in ConsoleOne. We recommend you administer the MTA as much as possible through ConsoleOne, as discussed for the POA in Chapter 8.

Configuring the MTA

Each domain object has a child object representing its MTA. Double-clicking this object from the GroupWise view (or selecting Properties when right-clicking the MTA object) opens the window shown in Figure 9.1.

Figure 9.1. The MTA object details property page in ConsoleOne

The rest of this section explores each of the eight property pages available from the GroupWise tab.

The Identification Property Page

The MTA Identification property page is shown in Figure 9.1, and as you can see, there is not much critical and configurable data here. The options include the following:

• Description: The text entered in this field is visible at the top of the agent screen on the server console. It might be useful to enter the phone number or pager number of the administrator responsible for configuring the MTA in this field.

• Platform: This window allows you to select the server platform on which the MTA will run.

The Agent Settings Property Page

As opposed to the available agent settings for the POA, there is little to configure for the agent settings for the MTA (see Figure 9.2).

Figure 9.2. The MTA object Agent Settings property page

From the property page, you control four aspects of MTA operation: scan cycles, database recovery, additional threads, and HTTP monitoring. Explanations of these settings are listed here:

• Scan Cycle: This sets the interval, in seconds, that each normal-priority thread waits before scanning its assigned queues. The queues that the MTA scans are the WPCSIN\2 tHRough WPCSIN\7 subdirectories of the domain directory. Also, if the MTA is linking to a post office via a UNC path, this is the interval between scans of the WPCSIN\2 tHRough WPCSIN\7 subdirectories of the post office directory.

  Tip

  As you can imagine, an MTA with UNC links to multiple post offices could become seriously burdened just with polling directories if this value is set too low. Novell recommends that all post offices be linked with IP addresses to avoid this potential problem.

  
  

• Scan High: This sets the interval, in seconds, that each high-priority thread waits before scanning its assigned queues. The high-priority queues are WPSCIN\0 and WPCSIN\1. Again, if this number is too low and there are lots of post offices linked via UNC, the MTA could be overtaxed just with file-polling.

• Attach Retry: If for some reason the MTA is unable to connect to another server, whether via TCP/IP links or UNC mappings, it will wait for the attach retry interval to expire before attempting another connection. The default value of 600 seconds (5 minutes) is good, because mail won't wait too long in the hold directories between attempts, and the MTA shouldn't bog down with consecutive reconnect attempts.

• Enable Automatic Database Recovery: This is the second aspect of MTA operation you'll control from this tab. If checked, this setting allows the MTA to perform a recover operation on a damaged domain database. If this is not enabled, damage to the domain database will result in the MTA's shutting down.

  If your domain databases are getting damaged regularly (probably through unstable workstations being used for GroupWise administration), you should disable this feature and resolve the problem. This will help prevent certain kinds of record loss.

• Use 2nd High Priority Scanner: Each link the MTA must service is assigned its own threads. There are twoa high-priority routing thread and a normal, or mail, priority routing thread. If there are 10 links to be serviced, there will be 20 threads. Checking this box will spawn a second thread for high-priority routing for each link, which means you'll now have 30 threads (10 mail priority and 20 high priority). This should be used only if you have a significant number of users using the busy search feature and scheduling users off of their post office.

  If you find bottlenecks at an MTA, consider using the queue assignment or link scheduling features described later in this chapter.

• Use 2nd Mail Priority Scanner: Like the preceding setting, this option spawns an additional thread for every link. The additional threads service queues 27. This option allows the MTA to process the 23 queues separately from the 47 queues. The end result is that messages in the 23 directories move more quickly through your MTA. Checking this option is particularly helpful for larger GroupWise systems, which have a lot of administrative changes.

• SNMP Community "Get" String: This field is for Simple Network Management Protocol (SNMP) community strings and is not required, unless you are using a third-party SNMP product.

• HTTP User Name/Password: These set the username and password you intend to use when monitoring your MTA through a Web browser.

Most of the settings on this page are fine-tuning settings. The HTTP username and password are very helpful when monitoring your MTA with a Web browser.

The Network Address Property Page

The information found on the MTA Network Address property page is absolutely critical to proper communication across your GroupWise system. When creating a new domain (and hence a new MTA object), you will want to immediately specify the TCP/IP address and port of the MTA. The SSL portions of this screen are not discussed in this chapter. Chapter 27, "Securing Your GroupWise System via SSL," gives detailed information on how to enable SSL on the MTA.

Warning

If the IP address of the domain file server must be changed, it is critical that the change also be reflected in the MTA object's network address panel. All other domain databases have a copy of this object record and use this information when communicating with this MTA. If the information is inaccurate, other MTAs will be unable to connect with this MTA to transfer messages.

The best way to make changes to IP addresses and ports on a live system is discussed later, in the section "Best Practices."

Utilizing the Network Address page, you can adjust various settings.

To modify the TCP/IP address, follow these steps:

1.	Click the button to the right of the field labeled TCP/IP Address.
2.	Enter the IP address or DNS name of the server on which this MTA runs.

The IPX/SPX address setting is relevant only if you use SNMP software that can access an IPX address.

Enter the message transfer port for this MTA in the Message Transfer Port field. If you are unsure of this value, use the default port, 7100. If there are multiple domains on a single server, each of the MTAs will need a unique port. Perhaps you could use sequential numbering in this case (such as 7100, 7200, 7300, and so on). It's helpful to have the MTAs end in 00 on the port. This way, if the POAs are sequential on the MTP port, they will not conflict with the MTAs. You might also need to renumber ports if there are POAs on this server that are communicating with their MTA via IP.

Tip

If you fill in the DNS address for the MTA, make sure that all the servers that house MTAs in your GroupWise system are configured to query the DNS server. On a NetWare server this means there is a RESOLV.CFG file in the SYS:ETC directory. The RESOLV.CFG file would be configured with at least two lines; for example:

domain worldwidewidgets.com nameserver 138.67.86.51

The HTTP port is used by the MTA and the GroupWise monitor utility. This port tells the MTA which port to listen to for Web-browser monitoring. This GroupWise Monitor utility reads the HTTP port value from the domain database in order to monitor the MTA.

Important

If you enable HTTP monitoring, you will also want to enable the HTTP username and the HTTP password. To do this, go to the Agent Settings property page and fill in the HTTP User Name and HTTP Password fields. If you don't define the HTTP username and password, anyone can access the MTA's HTTP port without being prompted for authentication. Not a good thing to have wide open.

There's not much on this page, but it is essential, particularly for domain-to-domain links, that the information on this page is accurate.

The Log Settings Property Page

The Log Settings property page allows you to control the amount of information captured in the MTA log, as well as the amount of disk space that old logs consume. Let's take a look at the settings on the Log Settings property page:

• Log File Path: By default, this field is blank. MTA logs are put in the MSLOCAL directory under the domain directory. If you choose to keep logs elsewhere, enter the path here. We do not recommend that you put logs on a separate serverperformance might suffer, and if that server goes down, the MTA will not function.

• Logging Level: There are three menu items in this drop-down list:

  • Off: No logging.

  • Normal: The MTA tracks major events in the log, but most of the detail is gone.

  • Verbose: The log contains useful detail. This option is recommended.

• Max Log File Age: This sets the oldest that any log file on disk can be before the MTA deletes it. The default is seven days, which is typically sufficient.

• Max Log Disk Space: This sets the maximum amount of disk space that all the log files can consume. If the logs reach this limit, the oldest log file is deleted. If you choose to set the Max Log File Age option beyond seven days, you will want to raise this limit to make sure that you actually get to keep your oldest logs for the time you specify. Unfortunately, this can be very difficult to estimate.

Note

The MTA automatically cycles to the next log file when the current log file reaches 1024KB (1MB), just as the POA log does.

The log settings of your MTA are not a critical function of the MTA, but having log settings configured correctly sure can help when it comes to troubleshooting.

The Message Log Settings Properties Page

Message logging is an integral part of the search feature of the HTTP monitoring piece on the GroupWise MTA. With message logging enabled, you can search for messages that passed through the MTA. In GroupWise 5x, customers were discouraged from turning on message logging; however, this is no longer the case. The MTA no longer uses a proprietary database, but the message log files are simple text files. The filename is in the format of MMDDMSG.00X, and message log files are located by default in the DOMAIN\MSLOCAL\MSGLOG directory. For example, the first log file on December 14 would be named 1214MSG.001. The MTA will cycle to a new MMDDMSG.00X just as it does with the traditional log files.

One advantage to enabling message logging is that you can hook into a couple of report-gathering features that are available in the GroupWise monitor utility. For example, you can generate reports that will tell you how much data has been transmitted and received between two domains. This is very useful when a company has WAN links involved between the GroupWise agents. GroupWise message logging is not the terrible performance degrader that it was in previous versions of GroupWise 6.0x and below.

Figure 9.3 shows the GroupWise Message Log Settings property page.

Figure 9.3. The MTA Message Log Settings property page

The Scheduled Events Property Page

There is only one kind of scheduled event that a GroupWise 6.5 MTA can run, and that is an eDirectory user synchronization event. The MTA can scan eDirectory for deltas, which are changes to eDirectory user objects that are not correctly reflected in the domain database.

Here's a plausible situation in which eDirectory synchronization is very useful. At WorldWide Widgets, users can change their phone numbers in eDirectory via a Web portal, for example, eGuide. The administrator wants those changes to be pushed down to the GroupWise address book automatically. With eDirectory User Synchronization enabled on the GroupWise MTA, the MTA searches eDirectory for changes to the user objects. Changes to the telephone number are then pushed down from eDirectory to the GroupWise directory store (WPDOMAIN.DBs and WPHOST.DBs).

A GroupWise MTA can be configured to discover eDirectory changes to users who are members of the domain that the MTA is servicing. A GroupWise MTA can also be configured to discover eDirectory changes to users who are not members of the domain that the MTA is servicing. For the GroupWise MTA to log in to eDirectory, its object must have rights to read the attributes of the eDirectory objects you want it to include in the discovery. Let's imagine that at WorldWide Widgets the administrator wants the following scenario:

• The GroupWise MTA for the CORP domain will run eDirectory synchronization for both the CORP domain and the MFG domain.

• The eDirectory synchronization will run once a day.

Here are the configuration steps needed to enable this setup:

1.	Connect to the CORP domain in ConsoleOne.
2.	In ConsoleOne, select Tools, GroupWise System Operations, eDirectory User Synchronization.
3.	Click the Configure Agents button.
4.	Highlight the MTA for the CORP domain and make sure that eDirectory access is enabled, as shown in Figure 9.4. Click the OK button to get back to the eDirectory User Synchronization Configuration window. Figure 9.4. MTA eDirectory access is now enabled
5.	Highlight the row representing the MFG domain, and click the Change Assignment button.
6.	Select the CORP domain's MTA as the MTA that will perform eDirectory user synchronization on the CORP domain's users. Click OK. Now, the eDirectory User Synchronization Configuration window should look similar to the one shown in Figure 9.5. Notice that the CORP domain's MTA is configured to perform eDirectory user synchronization for both the CORP and the MFG domains, as shown in Figure 9.5. Figure 9.5. The eDirectory User Synchronization Configuration window Tip For the GroupWise MTA to be able to access eDirectory, you must make sure that in the startup file of the MTA, you have enabled the /user and /password switches. The user must be someone with the eDirectory rights of Browse, Read, and Compare.
7.	Now go to the MTA object for the CORP domain. Edit the properties of the CORP domain's MTA.
8.	Select the Scheduled Events property page. Edit the existing eDirectory User Synchronization event, or create a new one.
9.	Give the event a name, and then select the Daily trigger. Have the event execute at a time that is outside of business hours. The event is now fully configured, as shown in Figure 9.6. Each day, the CORP MTA will search the eDirectory for changes to user objects that reside on both the CORP and the MFG domains. Figure 9.6. The MTA eDirectory User Synchronization event

Tip

If ever you want to kick off the eDirectory User Synchronization event manually, there's a hidden keystroke on the GroupWise MTA on the NetWare platform for doing so. Press the F4 function key, and you will be asked whether you want to perform eDirectory User Synchronization.

Tip

This scheduled event is enabled by default on the MTA. If you're running the MTA on a Windows server, you might need to disable this event if the NT server does not have access to eDirectory to log in to the tree. Leaving this enabled in this situation can cause problems with the MTA.

The eDirectory Synchronization feature is not necessary for some GroupWise systems, but it can be helpful for systems in which data, such as users' phone numbers, is altered without the use of the GroupWise snap-ins to ConsoleOne.

The Routing Options Property Page

The Routing Options property page enables you to override certain Internet addressing and default routing settings made at the system level. On large systems, this tool is critical to the proper administration of GroupWise Internet addressing, as well as configuration of MTA-to-MTA direct connectivity with other GroupWise systems. Chapter 34, "Creating a GroupWise-to-GroupWise Communication Solution Across the Internet," discusses when to use the settings shown on this page.

The SSL Settings Property Page

Configuring the SSL Settings property page is not discussed in this chapter. Chapter 27 gives detailed information on how to enable SSL on the MTA.