Q134756: PC Gen: MMTA.TXT: Mail 3.5 MMTA for Windows NT
Article: Q134756
Product(s): Microsoft Mail For PC Networks
Version(s): 3.5
Operating System(s):
Keyword(s):
Last Modified: 02-FEB-2002
-------------------------------------------------------------------------------
The information in this article applies to:
- Microsoft Mail for Windows, version 3.5
-------------------------------------------------------------------------------
The following is the MMTA.TXT from the version 3.5 Microsoft Mail for PC
Networks Multitasking MTA for Windows NT Server.
------------------------------------------------------
Microsoft Mail Multitasking MTA version 3.5
README File
------------------------------------------------------
(C) Copyright Microsoft Corporation, 1991-95
This document (MMTA.TXT) contains important information that
supplements the Microsoft Mail Multitasking Message Transfer Agent
Administrator's Guide.
INFORMATION FOR MICROSOFT MAIL ADMINISTRATORS
---------------------------------------------
This section covers the following topics:
1. New features on the MMTA
1.1 Hosted on Windows NT Server version 3.51
1.2 Run as a Windows NT service
1.3 Services can be remotely created and monitored
2. Differences from previous releases
2.1 Drive usage when running as a Windows NT service
2.2 Warning regarding Windows NT File Manager and delivery to
postoffices hosted on Novell NetWare file servers while running as a Windows
NT service 2.3 EXTERNAL.INI and DISPATCH.INI Files
2.4 DrivesNovell .INI Option
2.5 Permanent drive mapping
2.6 Limit of External or Dispatch services per Windows NT computer
2.7 Home postoffice on NetWare servers
2.8 Remote service creation of External and Dispatch services
2.9 Remote monitoring of the External and Dispatch services
2.10 MONITOR.EXE command-line switches
2.11 SCHDIST.EXE will not run as a Windows NT service
3. Eicon WAN services for Windows NT and the MMTA
4. Specific Windows NT notes 4.1 Windows NT event logs
4.2 Notes for Banyan administrators
4.3 Using Performance Monitor
1. New Features of the MMTA
---------------------------
This release of the Microsoft Mail Multitasking Message Transfer Agent
has a number of new features over the previous version. These features
are described in the following subsections.
1.1 Hosted on Windows NT Server Version 3.51
--------------------------------------------
This release requires Windows NT Server version 3.51, build 1057 or
higher.
1.2 Runs as a Windows NT Service
--------------------------------
This release supports the External MTA and Dispatch directory-
synchronization applications running as services under Windows NT.
Note: The user associated with the service must have the Windows NT
"Log on as a Service" privilege. For more details, see "Configuring a
Windows NT Service" in Chapter 2 of the Administrators Guide.
1.3 Services Can Be Created and Monitored Either Locally or Remotely
--------------------------------------------------------------------
The Microsoft Mail Service Manager application created in the Microsoft
Mail program group allows you to create and monitor services on either
the Windows NT Server you have installed to or on a remote LAN/WAN-
connected Windows NT Server.
2. Notes for Administrators
---------------------------
2.1 Drive Usage When Running as a Windows NT Service
----------------------------------------------------
When running as a service under Windows NT, it is recommended that you
do not make drive connections from the File Manager or command prompt in
the range used by MMTA services. Each service that is connecting to
multiple postoffices will use three drives. The first is for the home
postoffice, and the others are for dynamic drives. It is suggested that
you monitor the service, check which drives are being used, and if you
do need to connect to another server, use an unused drive.
2.2 Warning regarding Windows NT File Manager and delivery to postoffices
hosted on Novell NetWare file servers while running as a Windows NT service
When the MMTA is running as a Windows NT service and messages are being
sent or received from a postoffice hosted on a NetWare file server,
selecting the File Manager Window.Refresh option may freeze that MMTA
instance. The MMTA will display an error
Drive is either local, used or greater than LASTDRIVE
. To recover from this, stop and restart the
MMTA instance. It is strongly suggested that this option not be selected
in File Manager when an MMTA service is running.
Note: This will leave a connected drive that cannot be disconnected. The
only way to clear this drive is to reboot Windows NT.
2.3 Executable and .INI Files
-----------------------------
When running as a Windows NT service, all executables and .INI files
must either be local to the computer the service is hosted on or a UNC
path must be given.
Note:. There is a greater reliance in this release on the EXTERNAL.INI
and DISPATCH.INI files. Command-line switches are still available, but
it is suggested you move all commands to the .INI file.
2.4 DrivesNovell .INI Option
----------------------------
The DrivesNovell .INI file option has been removed and all paths to
postoffices must be in the DrivesUNC format. For more details about the
DrivesUNC option, see the "Connecting Postoffices" section in Appendix A
of the MMTA Administrator's Guide.
2.5 Permanent Drive Mapping
---------------------------
When running as a Windows NT service, only the home postoffice is mapped
as a permanent drive. All others will be handled dynamically.
NOTE: Specific drive mappings cannot be specified to either the External
or Dispatch services.
2.6 Limit of External or Dispatch Services per Windows NT Computer
------------------------------------------------------------------
If each service that is created is one which includes LAN/WAN
connections to other postoffices, there is a maximum of 7 concurrent
MMTA services that can be run on each Windows NT server. This is because
each service maps one drive for its home postoffice and two for its
dynamic range. If an eighth service is started, a Windows NT error 2140
will be displayed by the Windows NT service manager.
Note: If a service has the Single Postoffice Service option checked in
the Microsoft Mail Service Manager, that service will only use one drive
mapping.
2.7 Home Postoffice on NetWare Servers
--------------------------------------
A service that is created with the Home Postoffice set to a postoffice
hosted on a NetWare Server will need the service account to have a valid
account with the same name on the NetWare server. The password must also
be the same.
2.8 Remote Service Creation of External and Dispatch Services
-------------------------------------------------------------
When a service is created remotely, the path given to the executables and
.INI file must be able to be reached from the computer where the service
is created. It is suggested that UNC paths be given in that case.
2.9 Remote Monitoring of the External and Dispatch Services
-----------------------------------------------------------
The MMTA now allows for monitoring of the External or Dispatch services
either from the Windows NT computer the service is running on or a
remote Windows NT computer. For more details, see the "External
Configurations for the MS-DOS Workstations" section of Chapter 3 of the
Administrators Guide.
2.10 Monitor from a Command Line
--------------------------------
The Monitor option in the Microsoft Service Manager application is also
able to be called from the command line using the following command:
Monitor [external|dispatch] <\\computer_name> <instance_name>
External|Dispatch - The type of service
\\computer_name - Name of the Windows NT Server running the service
instance_name - Name of the instance that should be monitored
Note: If you want to monitor specific instances regularly, create a
batch file containing the preceding command and place it on your
Windows NT desktop or in the Start folder.
2.11 SCHDIST.EXE Will Not Run as a Windows NT Service
-----------------------------------------------------
SCHDIST.EXE is not supported as a Windows NT service and can only be run
from within a Windows NT command prompt.
3. Eicon WAN Services for Windows NT and the MMTA
-------------------------------------------------
For information about installing the Eicon Gateway software, see the
Eicon documentation and Appendix F, "X.25 Settings for Mail," in the
Microsoft Mail Administrator's Guide. Your Eicon setup must match the
configuration of the line leased from your X.25 carrier. The X.25
service must be running. Values vary by carrier and installation--
confirm all values set by the ECCFG program with your carrier.
Before running the MMTA to use X.25 communications, the Eicon X.25 card
must be installed on the Windows NT computer running the Eicon WAN
Services for Windows NT Version 3, Release 2. For more information about
installing and testing these components, see the documentation that
comes with the Eicon product.
The Multitasking MTA uses a series of translation files to convert the
OS/2 X.25 API calls to Windows NT API calls. This process of converting
APIs is known as "thunking." The X.25 thunk layer relies on 3 DLL files
and the Eicon WAN services for NT service. These .DLL files are:
1. WINNT\SYSTEM32\OS2\DLL\X25.DLL
2. WINNT\SYSTEM32\X25T32.DLL
3. WINNT\SYSTEM32\X25NTM8.DLL
The Microsoft Mail Administrator's Guide provides information about
options that are critical when setting up the Eicon board and software.
For the configuration option Number Of TVCs, a value of 004 is
suggested. The correct value depends on the line installed--a different
value could be appropriate for your configuration.
4. Specific Windows NT Tips
---------------------------
4.1 Windows NT Event Logs
-------------------------
When the MMTA is running in trusted Windows NT domains, the Security
event log will have an entry for every connection the MMTA makes. It is
suggested that you set a limit to the size of the event log.
4.2 Notes for Banyan Administrators
-----------------------------------
The Multitasking MTA cannot service postoffices hosted on Banyan servers
when running as a Windows NT service. These servers can be serviced by
the MMTA in a console. For notes on the syntax for accessing a Banyan
server with a UNC path, see the Release Notice for the Banyan Enterprise
Client for Windows NT Version 5.56 (5) or higher.
4.3 Using Performance Monitor
-----------------------------
Performance Monitor is a graphical tool for measuring the performance of
your own Windows NT-based computer or other Windows NT-based computers
on a network. It is located in the Administrative Tools group of both
the Windows NT Workstation and Windows NT Server products. On each
computer, you can view the behavior of objects such as processors,
memory, cache, threads, and processes. Each of these objects has an
associated set of counters that provide information on such things as
device usage, queue lengths, and delays, as well as information used for
throughput and internal congestion measurements. It provides charting,
alerting, and reporting capabilities that reflect current activity along
with ongoing logging. You can also open log files at a later time for
browsing and charting as if they were reflecting current activity.
This section discusses memory usage and which counters are effective in
detecting memory bottlenecks.
4.3.1 Memory - Pages/sec
------------------------
Pages/sec is the number of pages read from the disk or written to the
disk to resolve memory references to pages that were not in memory at
the time of the reference. As a rule, you can assume that if the average
of this counter is consistently greater than 5, then memory is probably
becoming a bottleneck in the system. Once this counter starts to average
consistently at 10 or above, performance is significantly degraded and
disk thrashing is probably occurring.
4.3.2 Memory - Available Bytes
------------------------------
Available Bytes displays the amount of free physical memory. If this
counter stays consistently below 1 MB on servers and 4 MB on
workstations, paging is occurring and performance is less than optimal.
4.3.2 Memory - Committed Bytes
------------------------------
Committed Bytes displays the size of virtual memory (in bytes) that has
been committed (as opposed to simply reserved). If this counter is
greater than the amount of main memory, it indicates that main memory
may not be large enough to accommodate all functions of all currently
active processes--some paging may be inevitable. However, before making
such an assumption, you should check Memory - Pages/sec and Memory -
Page Faults/sec. If the Memory - Pages/sec is greater than 10 (10 is a
reasonable guideline, but varies with disk hardware) and Memory - Page
Faults/sec is greater than Memory - Cache Faults/sec, then you are
paging too much.
When Memory - Committed bytes approaches the Memory - Commit Limit and
the page file has already reached maximum page file size, there are
simply no more pages available, in main memory or in the page file. The
Memory - Commit Limit is the amount of virtual memory that can be
committed without extending the page file. If this occurs on a server
running Windows NT Server, you may experience 3 errors in the Event Log.
(EVENTVWR.EXE is located in the Administrative Tools group). They are
from the source: SRV.
2020: The server was unable to allocate from the system paged pool
because the pool was empty.
2001: The server was unable to perform an operation due to a shortage
of available resources.
2016: The server was unable to allocate virtual memory.
If this occurs, it is generally related to a memory leak in
another process. To determine the process at fault, you can
monitor each process's Page File bytes or Working Set.
Another condition you may want to be aware of is the following nonpaged
pool error in the server's Event Log:
2019: The server was unable to allocate from the system nonpaged pool
because the pool was empty. Nonpaged pool pages cannot be paged
out to the paging file, but instead remain in main memory as
long as they are allocated. By default, NonPagedPoolSize is
dynamically calculated as follows:
You can monitor the system's nonpaged pool allocation with the
"Memory Pool Non Paged Bytes" counter. If there is a shortage of
nonpaged pool, you may also see the following error on a remote
system or even the local system:
Not enough storage available to process this command. If this
occurs, start looking at each process's nonpaged pool
allocation. This is generally caused by an application
incorrectly making system calls and using up all allocated
nonpaged pool.
4.3.4 Adding More Memory
------------------------
To determine how much memory to add, use the following formula:
Paging File - % Usage - MAX * Page file size = number of bytes used
Add together the bytes used for all page files. This is the amount of
memory that would need to be added to allow all of the applications to
perform their operations with minimum paging. For example, if your page
file is 100 MB and the % Usage MAX is 20%, then you would need 20 MB
additional RAM to have a system that does minimal paging. The reason
this formula only gives you an idea about how much memory to add is that
a) not all page file "in use" code is accessed all of the time; and b)
the formula ignores the requirements for code and mapped files not
backed by the paging file. Therefore, this estimate is neither an upper
bound, nor a lower bound--it is only an "indication." The truth is that
there is no good way to know how much memory to add at this time. A more
accurate way to measure the amount of memory an application would
require is to run the application on a very large machine and measure
the needs under some slight memory pressure. (There is a tool in the
Windows NT Resource Kit, volume 3, Utilities, called Response Probe,
that can aid in this area.)
NOTE: Adding memory without upgrading the secondary cache size sometimes
degrades processor performance. This is because the secondary cache now
has to map the larger memory space, usually resulting in lowered hit
rates in the cache. This slows down processor-bound programs because
they are scattered more widely in memory after memory has been added.
(Secondary cache refers to the physical cache memory chip(s) usually
located on the motherboard, as opposed to within the processor itself.
In the future, processors will be built with secondary cache on the same
substrate as the processor chip, or even within the processor chip
itself.)
Additional query words:
======================================================================
Keywords :
Technology : kbMailSearch kbZNotKeyword3 kbMail350
Version : :3.5
=============================================================================
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright Microsoft Corporation 1986-2002.