MailEnable Enterprise Edition supports clustering of servers. Clustering support is important because it allows you to add additional servers to your configuration as demand for resources increases.
MailEnable stores all system data in a shared storage repository. Server specific information is stored in the Windows Registry (such as details about which IP addresses a service is bound to). This means that it is possible to install multiple server nodes and point them at the same storage repository.
There are two basic configurations for clustering MailEnable servers. These are referred to as a "Controller and Slave Cluster" configuration, and a Shared Storage Cluster".
A "Controller and Slave Cluster" involves a single MailEnable server that hosts a large storage array. This server is configured to share its storage for other "Slave" servers to access.
The second model is referred to as a "Shared Storage
Cluster". This cluster has all MailEnable servers configured to access a
shared storage device (eg: NAS/SAN/DAS).
Controller and Slave Cluster Configuration
MailEnable Enterprise and Premium Editions provide a wizard within the MailEnable Management Console that allows you to cluster two or more MailEnable Servers.
Cluster Management can
be found within the MailEnable Management Console under the
properties of the Messaging Manager node. The "Cluster" tab allows you
to configure whether an individual server is a standalone server,
cluster controller or a server that is joined to another cluster
controller. This utility will create the necessary file system share and
modify MailEnable’s configuration depending on the mode selected for the server.
MailEnable services will need to be restarted after making changes to the
A cluster controller is a server which has a hidden share called MAILENABLE$. This share needs to have both the configuration and data paths as a subdirectory, so the server must not have separate paths set for this. For example, in a default installation of MailEnable, this would be C:\Program Files\Mail Enable. By setting the server as a cluster controller, the hidden share will automatically be created.
A cluster member is a server that points its data and configuration storage at another server that is a cluster controller. By enabling a server as a cluster member, the necessary paths are altered and all the MailEnable services are optionally set to run under the IME_ADMIN Windows user account. The IME_ADMIN users on all servers must have the same password. If you do not know the password for IME_ADMIN, then you can use the MEInstaller.exe application (under the Mail Enable\bin directory) to reset this password on any MailEnable cluster nodes.
To remove the server from a cluster, or to prevent a server from being a cluster controller, select the option for the server to be standalone and apply the changes.
To make the changes, select the option that best
describes this server. If the server is member server, ensure that it is
configured to point to the appropriate controlling server before clicking the
Shared Storage Cluster Configuration
A Shared Storage Cluster involves pointing all MailEnable servers at a single storage location. This storage location could be a drive mapped to a SAN, a Shared Storage array or a UNC path to a Network Storage Device.
If the shared storage device is a NAS device, then it will either have its own Network Operating System (Windows or Unix/Samba/NFS) or it can be joined to a security realm or Windows Domain so that you can use accounts to secure directories. It is important that the shared storage allows IME_ADMIN and IME_SYSTEM full control. This typically means configuring these user accounts on the NAS with the same passwords as on all MailEnable member servers.
It is also important that any network paths are mapped via UNC rather than mapping a drive letter within a user session. This is because the drive mapping will not be known by services when they are running under the service control manager (ie: when they are running as services rather than when a user is logged in). A common mistake is to map a drive (for example X:) to a UNC path and then to use that drive when installing MailEnable. In this case, a potential problem is that when MailEnable services run under their system accounts, the X: will not exist.
To install a MailEnable server under this configuration, you should simply run the setup and select the shared storage location when prompted by the installer. You should do the same for any other nodes that you add to the cluster. All nodes added to the cluster will simply set their paths to access the shared storage location.
It is very important that when MailEnable services run, that they are able to access the shared volume. As mentioned earlier, you need to consider that MailEnable services run under windows accounts (IME_ADMIN or IME_SYSTEM), and these accounts will need to access the shared storage.
Important: MailEnable Services will need to run under an account that has the same Windows Account Name and Password as one on the NAS (or if they are in the same domain use a domain account to run the services). A good approach is to use the IME_ADMIN account and make sure that the account and passwords match on both servers.
By load balancing and clustering front-end servers (IIS, SMTP/POP, IMAP) the system can scale out easily from the front-end perspective. Ideally, there would be a single file service (probably network attached storage or a SAN) and point all the MailEnable servers to the same post office/configuration repository. This means that SMTP, POP or MTA servers can be added as required and IP load balancing can be used to provide a clustered IP address.
The Professional Edition of MailEnable experiences latency issues (for login and message routing) where a single implementation or site contains more than 20,000 users. MailEnable Enterprise Edition overcomes this issue by providing Enterprise Database configuration providers (rather than tab delimited files).
The biggest issue with configuring a clustered MailEnable environment (by far) is configuring permissions on shared storage locations, and ensuring that the services running on the members have access to these locations. In order to test whether your cluster is configured correctly, you should use the managment console to create a new mailbox and verify that the mailbox exists when you attempt to access the management console from another server.
Assuming all your cluster members are able to configure mailenable via the MMC, then you should verify that you are able to send and receive messages through MailEnable. If you are not able to do so, then you could run the services in debug mode to verify that the problem is related to the identity that the service under unattended execution. The MailEnable Knowledge Base has details on how to configure services to run in debug mode.
How to configure MailEnable web mail on a different server:Article ME020070