PostPath: Enterprise-strength open source alternative for Exchange

For enterprise system administrators looking for interoperability with Microsoft Exchange, but not the high costs associated with it, PostPath email and collaboration server could be a smart business investment. Boasting interoperability with Exchange environments for a third of the cost, thanks to its use of the Postfix mail server and many other open source components, PostPath provides drop-in capability and compatibility with Exchange environments without the need for making changes to Outlook on the client side. Being compatible with Exchange means that it can be managed using Microsoft’s Active Directory infrastructure. The latest version, PostPath v3.1.2, adds support for Blackberry Enterprise Server and ActiveSync, allowing you to use mobile devices to access your email.

What makes this interoperability possible is the fact that PostPath developers used the same protocols as Exchange, so no special connectors are required for Exchange clients and PostPath is completely compatible with Exchange management. Organizations with existing Exchange infrastructures that need to expand can add an additional mail server running on PostPath, and Exchange will see it as another Exchange server in the environment. One of the biggest advantages of this approach is cost savings. PostPath itself licenses for $4,000 with 60 free users and a redundant server, and $45 per seat for additional users. With Postpath, you can use less powerful hardware without sacrificing performance — a dual-core system with 2-4GB of memory will suffice. And PostPath runs over free operating systems such as CentOS.

As of now, PostPath supports environments up to Exchange 2007, although Outlook 2007 cannot connect to PostPath when using Remote Procedure Call (RPC) over Hypertext Transfer Protocol (HTTP) connections on Windows Vista clients as described in the troubleshooting guide. You can test PostPath by downloading the 30-day trial with 12 seats.

PostPath requirements

Before you install the software, make sure you have a server with at least a Pentium 4 processor, 1-2GB of RAM, and 100GB of disk space. For production environments with at least 100 users, a dual-core processor, 2-4GB of RAM, and 100GB (depending on mailbox size policy) of disk space are highly recommended. For the operating system, you can use the free CentOS 4.4 32-bit, CentOS 4.5 64-bit, Red Hat Enterprise Linux 4.4/4.5 32- or 64-bit, and SUSE Linux Enterprise Server 10 32- or 64-bit. You can use Outlook Express, Outlook 2003/2007, Eudora, or Thunderbird as clients.

In addition to the hardware and operating system, you must prepare your email infrastructure. First in the list is a properly working Active Directory and Domain Name Server. You must also enable Network Time Protocol and NetBIOS. Although you can install PostPath without Exchange and have it work properly, you still need Exchange installed on the same network to detect PostPath as another Exchange server, controlled by the Exchange management utilities, and integrated with Active Directory. PostPath needs the Exchange extensions to produce one of its primary benefits: management from within Active Directory. You can manage PostPath using its own management software, but it defeats the purpose of interoperability and ease of use within the Active Directory infrastructure. Besides, PostPath is really made as an alternative for an expanding Exchange ecosystem and not as a standalone server. Once everything is in place, you can proceed with PostPath deployment.

Deployment

I installed PostPath under CentOS 4.5 to test it as both a standalone messaging platform and along with a single Exchange 2003 server. After downloading the installer ./postpath-installer.bin, I installed the PostPath Server Daemon (the PostPath engine), PostPath Recipient Update Service (for use when there is no existing Exchange server), PostPath Administration, and PostPath Webmail.

You have to specify several settings throughout the installation process — things like the primary domain name server, Active Directory domain name, NetBIOS name, fully qualified domain name, NetBIOS name of PostPath server, Simple Mail Transfer Protocol domain, and the domain administrative account and password.

During the installation process, for installing a standalone PostPath server only, select the interactive scripts forestprep and domainprep. You only need to select forestprep and domainprep if PostPath is your first email server and Exchange is not yet present. These two scripts let email servers such as PostPath work with the existing Activer Directory environment — so that, for example, users and groups in Active Directory are reflected on the mail server and vice versa. You can read more about forestprep and domainprep at MSExchange.org.

Be mindful that, even though users and groups created on the PostPath server will reflect on Active Directory and vice versa, you can create a mailbox only within the PostPath server console — not within Active Directory. Active Directory also will not show any information about the mailbox of the user or group.

If you have more than one domain, you must wait for the replication process to finish replicating the changes made in the domain Active Directory to ensure that all domains are updated before you make further changes. For example, if you create a user on a domain or change permissions, that change must also replicate or be synchronized, or else there will be inconsistency and the changes you made will not take effect on the other related domains.

After forestprep and domainprep are completed, proceed to configure the PostPath Server Daemon (PPSD) core itself. This will make changes to Active Directory — for instance, allowing PostPath to set access rights. The PPSD will also add PostPath to Active Directory, install Postfix, and configure Postfix, if it is not already installed on the server. There is an option to configure Postfix manually. However, since some of the parameters that you must enter are somewhat confusing to the inexperienced, PostPath recommends that you do it within the PostPath Server Daemon core configuration. If you allow the PostPath Server Daemon to configure Postfix, the details you enter in its configuration — such as the domain name, DNS server, fully qualified domain name of PostPath server and DNS, and machine name, will also be used in the configuration of Postfix.

Next, if Exchange is not installed, configure the PostPath Recipient Update Service — so PostPath can control user attributes within Active Directory. If you only have one domain to configure, with or without Exchange installed in the network, it should take you 15 to 20 minutes to configure. However, if you have more than one domain, you have to consider the replication time — which depends on the number of domains you have and the connection speed with the other domains. If you have a fast connection between the domains, it should take about five minutes to replicate one domain site to another. If Exchange is already installed on the network, you do not need to use forestprep and domainprep — so replication will only happen once during PPSD configuration.

After finishing the PostPath Server Daemon steps, you can configure PostPath Administration and PostPath Webmail, which are straightforward and much faster than configuring the PostPath Server Daemon. For environments with an Exchange server, you can follow most of the same steps as the standalone deployment, leaving out forestprep, domainprep, and PostPath Recipient Update Service configuration. Visit the resource site for PostPath for a complete installation and administration guide.

Post-installation and some issues

After the whole configuration process is complete you can start the PostPath services. First is the PostPath engine. Upon starting the PostPath service, I encounter the following error related to Active Directory: “PPSD [Log:EMERG] DATE TIME :ERROR: Could not load AD configuration Data.” After some checking, I learned that the account object created by PostPath in Active Directory did not have proper permissions. After I fixed the permission issue, the service started successfully.

PostPath Webmail is dependent upon the Tomcat service, and that service started without a hitch. Lastly, I enabled the PostPath Recipient Update Service. I then ran PostPath Administration to manage PostPath, but it warned me that I was not using a Secure Sockets Layer connection for my login. PostPath Administration is integrated in Active Directory, but you can’t make any changes, such as user creation, unless you are using SSL. To resolve the issue, I enabled my certificate services and created an SSL certificate in the Active Directory server. I was then able to make changes and create mailboxes for users using PostPath Administration, which is the only way you can create mailboxes if PostPath is running without any Exchange server.

The scenario is different when Exchange server is installed. With the Exchange extension in place in Active Directory, you can create PostPath mailboxes using Active Directory. PostPath is seen as another Exchange server, so you can also manage the PostPath server using the Exchange Management Console. As such, during the creation of the user mailbox, you have the option to choose the PostPath server as the email server just as with Exchange. After creating some test users, I tried both the PostPath webmail and Outlook 2003 clients using PostPath as the email server. Webmail works just like Outlook Web Access, and Outlook 2003 sees PostPath as another Exchange server that is working properly.

Impressions

In my testing, PostPath worked well as a real alternative to Exchange. Most of the Exchange features, such as public folders and global access list, are well supported. Outlook client functionality like calendar, sharing of contacts, and mailboxes work flawlessly. Scheduling also works as intended, and I saw no problem with mail delivery.

One issue that needs to be addressed is the fact that PostPath does not have any system management utilities that are comparable to those of Exchange. True, PostPath does have an interactive text-based management console that covers most of the tasks handled by the graphical configuration of Exchange. However, for the target enterprise users, the time and work required to configure with a text-based management console would increase exponentially. Also, since PostPath aims to migrate existing Exchange users to a PostPath environment, once migration is complete and there is no need for Exchange, how can you manage server functionalities like public folders with no system management console? Although PostPath Administration can answer some of these concerns, it too would be cumbersome to use in a large environment.

Overall, PostPath seems to be a true low-cost drop-in alternative with most of the Exchange environment features. Although it needs a few additional features and improved support for Vista clients, it is exciting to see how far it can go against a dominant player like Exchange.