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?