Software

PostPath: The verdict


I have now finished evaluating the PostPath mail and collaboration server platform. In previous blogs we went over the installation process and got both the core PostPath PPSD daemon running along with PPWM; the PostPath Web mail package.

I noted last week that, without an existing Microsoft Exchange server, there is currently no supported way of running PostPath. While having an Exchange server is not vital for a successful installation of PostPath (the installation program can prep the Active Directory Schema) or to its basic operation, the lack of a live Exchange server running in the domain will present problems. The first and most basic issue I ran into while trying to run PostPath without Exchange was that there was no integrated server or user management available. The installation of Exchange not only modifies the Active Directory schema, but also installs Exchange management tools—Exchange ‘System Manager’ and a modified version of ‘Active Directory Users and Computers’. These tools can be installed without a fully-deployed Exchange server, but in order to do this you must already have a valid copy of Exchange (I suspect that there would be licensing implications if one installed the management tools without actually having a licensed copy of Exchange in operation).

While it may be possible to get by without using the Exchange System Manager, I can’t see how it would be possible to administer the server without a modified copy of ‘Active Directory Users and Computers’—creating new users in Active Directory would not necessarily create a new mailbox and there would be no way to manage e-mail addresses and aliases. I could also see no way to carry out Exchange-related tasks, such as mailbox migration, without these administrative tools.

PostPath does not officially support installation in environments without Microsoft Exchange, however, the fact that domain prep tools are included hints that there is an intention to support Exchange-free environments in the future. I’ll be interested to see how the aforementioned management issues will be handled.

I was slightly disappointed to find that not all of the administrative functions of Exchange System Manager could be used to administer the PostPath server. Public Folder management and global address list management can be used, but trying to administer other server functions results in errors. I checked this out with PostPath support and was told that this is normal (because I initially suspected that the errors were due to misconfiguration on my part).

Moving on to general use, I set up six new Active Directory users with their mailboxes located on the PostPath server. Mailbox creation seemed to go smoothly as did mapping the accounts in Outlook 2003. Outlook saw the server as a native Microsoft Exchange server and functionality such as the sharing of contacts, calendars and mailboxes worked without fault. Scheduling meetings using the free/busy function seemed to work properly; delegation of ‘on behalf of’ permissions worked correctly; as did accepting, declining and proposing a new time for meetings. Mail delivery worked as expected.

One issue experienced was related to free/busy scheduling information. Upon shutting down the Microsoft Exchange server running in parallel to PostPath, free/busy scheduling information was no longer available.

A second issue was that I could find no way to manage Public Folders other than via the Exchange System Manager. As mentioned above, this is obtained with a valid copy of Microsoft Exchange and would be available in an environment migration from that platform. I fail to see how the Public Folders would be managed once full migration has been completed and no more Exchange Servers are present on the network (and therefore no instances of Exchange System Manager).

The last issue encountered was a showstopper for me. Due to the impending general release of Microsoft Office 2007, I decided that it would be wise to check that the system functions properly with Outlook 2007. I could see no reason why it should not, having previously tested the program with an Exchange Server without issue. I was horrified to find that as soon as Outlook attempted to connect to the server, all server processes died instantly. At first I thought this must have been a horrible coincidence, but after recreating the problem several times over, I had no choice but to resign myself to fact that Outlook 2007 killed the PostPath PPSD process. I found this quite strange and could find no errors in the log files; the process simply keeled over.

To sum up, I must say I’m quite disappointed. Before evaluating PostPath, I had hoped that I would find a solution to replace Microsoft Exchange: interoperation with Outlook, no need for troublesome connectors and plug-ins; the advantages of filesystem-based storage; and the stability of Linux would be a dream come true for most system administrators. Currently, it seems this is just not possible; if the full set of functionality provided by the combination of Microsoft Exchange and Outlook are required, then I guess it should come as no surprise to find that the only server platform able to offer this is Microsoft Exchange. It will be interesting to revisit PostPath in the future and see how it matures; my concern is that it will always be playing catch-up with Microsoft Exchange.

It would be nice to hear some opinions on this topic: Do you think Microsoft Exchange is a bad thing? Have any readers had success in using the full range of Outlook features (such as shared resources and collaboration) without an Exchange backend? Maybe Outlook should be dumped in favour of a pure Web based system?

1 comments
htumanyan
htumanyan

Hi Justin, On behalf of the PostPath team I would like to thank you for your time and effort dedicated to evaluating our solution. Your comments on various aspects of PostPath installation and operation were extremely helpful. PostPath is sensitive to feedback and does everything possible to distinguish itself from the competition as more accommodating, flexible, and quick to respond. I lead the PostPath Customer Engineering Services organization and our goal to assist customers and beta testers with PostPath infrastructure planning, deployment and customization. Being an engineer, I enjoy dialogue with the technical community and, hopefully, this will also benefit the Tech Republic reader community. [b]Installation without Exchange[/b] There are some improvements being made now to fully enable automated installation in Exchange-free environments. Customers who want to install Exchange-free today, and run into difficulties, are assisted by our customer support team. An improved GA (not Beta) version of the Exchange-free automatic installer will be available shortly. Feedback is always appreciated. [b] User Management without Exchange [/b] Today, we recommend that customers use the Microsoft user-management tools even in an Exchange-free environment (for customers who do not already have a copy, the tools are available for a few hundred dollars). In future, we will have a web-based application that will make those Microsoft tools redundant. [b] Free/Busy [/b] I believe that what you saw was not a PostPath problem but rather known limitation of Exchange Free/Busy and the Public folder mechanism. (see below) I?m sure that you?d encounter exactly the same behavior in an environment with two Exchange servers. With appropriate reconfiguration, the problem should resolve (just as it would in all-Microsoft environment). Q152959 - How to Remove the First Exchange Server in a Site (http://support.microsoft.com/kb/152959/) Q275171 - How to Reset System Folders on an Exchange 2000 Server (http://support.microsoft.com/kb/275171/EN-US/) Q284200 - Schedule+ Free/Busy System Folder Is Missing (http://support.microsoft.com/kb/284200) [b] Outlook 2007 [/b] PostPath is very serious about testing interoperability with various MAPI clients and a thorough QA process using a number of various clients is part of our normal release procedure. This includes various Outlook versions (2000, 2002/XP, 2003 and 2007), Blackberry Enterprise Server (3.6 and 4.0) to name just a few. Though the currently released PostPath version 2.1 had been tested and was confirmed to work with then available flavor of Outlook 2007, the currently distributed version of Outlook 2007 contains a patch with a bug, released shortly after PostPath 2.1 was shipped. The bug (malformed request) causes issues with both Exchange and PostPath. Unfortunately, the issue is very visible with PostPath as you saw. A beta patch to the PostPath Server has been prepared and is being tested now. The patched PostPath Server is able to operate with the bugged version of Outlook without generating errors ? which is more than Exchange itself can do. Normally, PostPath Server is more robust in the face of buggy client behaviors than Exchange. With the addition of this patch, that normal situation will also apply in the case of Outlook 2007. Please, don?t hesitate to contact PostPath support organization or me personally with any issues related to PostPath collaboration solution or surrounding infrastructure (Exchange, Active Directory etc.) As I implied earlier, quick response and great flexibility are important parts of our value propositions. Sincerely yours, Hovhannes Tumanyan

Editor's Picks