Read Part 1 here

Domain Configuration File (*.MTA)

When a domain's MTA loads it reads a configuration file called 'domainname.MTA'. This configuration file as several switches in it that if set can increase the performance of the MTA. A majority of the switches in the configuration file are also available via ConsoleOne and the MTA object. Some are not. I will note here that you should always make sure to fill in the attributes in the eDirectory MTA objects. This ensures those attributes are logged into the databases and synchronized with the rest of the GroupWise system. Even if I am using an attribute in an MTA configuration file, if that attribute exists in the eDirectory object, I fill it in. Let's look at a few MTA configuration file switches.

• /home- This switch points to the location of the wpdomain.db for the MTA's parent domain. In the configuration file it sets a default UNC style, however, the MTA will load faster if you use the NetWare style like this: Volume:\DomainDirectory. Notice I leave off the server name, its not needed and it's a clustered environment you never want the server listed because the MTA never knows which server it will load from.

• /tcpinbound- This switch allows you to customize the number of maximum TCP inbound connections an MTA can handle before it goes into a 'wait state' for an available connection. Personally, I do not like to wait nor do I want my MTA's to wait. Since each TCP connection takes approximately 15 to 20k of RAM, I set this high. Between 600 and 800 will work for most environments. If you find you MTA consistently receiving TCP 'wait state' messages, increase the inbound connections slowly. If you have all domains talking directly to all other domains as stated above, in a Mesh topology of sorts, then each domain will hold open a large quantity of connections, ie. 600. Finally, this setting is directly affected by the implementation of the "Use 2nd High Priority Router" and "Use 2nd Mail Priority Router" settings in the MTA eDirectory object. These two settings increase the number of connections as well.

• /tcpport- This switch opens up the TCP Message Transfer Port (MTP) for the MTA. The only time I use this switch in the configuration file is when I have multiple MTA's loading on the same server, even if each MTA is using a different secondary IP address. I prefer to 'guarantee' the MTA will load and listen on the port I designate. I use this switch in clustering the MTA also.

• /httpport- This switch opens up the TCP HTTP port for the MTA. This allows you to monitor the individual MTA simply by pointing a browser to the IP address and HTTP port of the MTA, like so: http://192.168.20.101:3801 . The only time I use this switch in the configuration file is when I have multiple MTA's loading on the same server. I use this switch in clustering the MTA.

1. Best Practice: Use the MTA configuration file to tune and 'guarantee' the domain MTA will load the exact same way each time.

Domain and MTA eDirectory Objects

When GroupWise is installed, the objects appear in eDirectory. Most day to day management of GroupWise is as simple as managing these objects. Where in eDirectory should the GroupWise objects be placed? The answer is it depends. The majority of the time, I recommend a GroupWise Organizational Unit (OU) underneath the Organization (O) in the eDirectory tree. This assumes GroupWise is managed centrally and that the Primary Domains MTA will have eDirectory access to read the users for its 'eDirectory User Sync' process from a ROOT or O eDirectory replica. If GroupWise is managed by container or site administrators, then having the appropriate site-oriented GroupWise objects located in the site container makes sense. However, in the last several years organizations have been centralizing GroupWise into one data center, and clustering it. So, site administrators for GroupWise are slowly fading away.

1. Best Practice: A GroupWise container in eDirectory to hold all GroupWise objects.
   

There is very little that requires additional tuning in the domain eDirectory object. The two items I see most are the Description and Administrator attribute. While these do not directly affect the performance of GroupWise they do ease the management, especially when someone new comes along to manage the GroupWise system.

In the case of the MTA eDirectory object, there are quite a few attributes that should be filled in. The first of which is the Description. This attribute is read by the MTA when it loads on the server and shows the information input on the MTA server screen. I recommend placing the IP address and ports of the MTA as well as the name of the domain it is servicing. See Figures 6 and 7 below.

1. Best Practice: Fill in the Description attributes of the Domain and MTA eDirectory Object

Click to view.

Click to view.

The Agents Setting tab of the MTA object has 2 attributes that can increase the performance of the GroupWise message flow. They are:

• Use 2nd High Priority Scanner -This setting creates a separate 'thread' to process the Priority 0 and 1 message queues, speeding up the delivery of any messages or requests found within these queues.

• Use 2nd Mail Priority Scanner -This setting creates a separate 'thread' to process the Priority 2 and 3 message queues only. This increases the speed for processing administrative and high-priority messages.

1. Best Practice: Enable the 2nd Priority Scanner 'threads' for each MTA
   

Click to view.

The MTA Log Settings tab requires a bit of work. I always recommend stating where the MTA Log files are to be located. This helps new administrators find these log files and it also leaves no doubt as to where they are being written. A tip here, I prefer to create a subdirectory underneath the domain directory called 'LOGS' and I point all MTA and child gateway logs to this directory. Since the MTA and the gateways have different naming conventions for their logs, the logs are not overwritten. Finally, I always recommend Verbose mode. It provides more information and is very handy when trying to troubleshoot issues with an MTA. See Figure 9.

1. Best Practice: Fill in the Log File Path attribute and set Logging Level to Verbose for the MTA eDirectory Object

Click to view.

The last MTA parameter I like to tune is the Scheduled Events. As I stated earlier, I want the Primary domain to handle all eDirectory User Synchronization. Therefore, I do not allow the other MTA's to run a Schedule Event. This makes the Primary domain MTA the single point of failure for eDirectory User Synchronization, but in most organizations this process only runs once a day and only the 'delta' is synchronized. The Primary Domain's MTA scheduled event I set to some off time preferably with backups are not running. See Figure 10.

Click to view.

A tip for you: If you use the GroupWise 6.02 snap-in's against a GroupWise 6.5 database, you will find an 'Interval' setting for MTA Scheduled Events. This 'interval' setting allows you to set an hourly eDirectory User Synchronization schedule, very helpful in large systems with lots of daily changes. See Figure 11.

Click to view.

Setting the Primary domains MTA as THE eDirectory Synchronization MTA also requires you to go into ConsoleOne under Tools| System Operations| eDirectory User Synchronization and 'Change Assignment' for all domains in the GroupWise system. See Figure 12.

Click to view.

1. Best Practice: Enable the Primary domain MTA with an eDirectory User Synchronization Scheduled Event and disable this scheduled event for all secondary domain MTA's

1. Best Practice: Set the Primary domain MTA as the only MTA to do eDirectory User Synchronization for the GroupWise system.

Summary

This brings me to the end of this article. Keep in mind that Best Practices are created every day by finding new and improved ways to make GroupWise run longer and stronger, not to mention faster. With a few domain design changes and a couple parameter adjustments your organizations GroupWise system will become more fault tolerant, have increased stability and be easier to manage.