Compatibility Explained

Given enterprises' existing investments in Outlook™ clients, Exchange™-compatible infrastructure, and already-deployed Exchange servers, as well as the potential need to support additional Exchange™-compatible applications in the future, many enterprises now require any alternative email server to be "drop-in" when deployed. In other words, the new server must not require changes to desktops, infrastructure, or Exchange™ servers that are already in place.

PostPath's unique approach to compatibility is to implement Exchange™-compatible network protocols at the PostPath Server™. In that way, desktops, infrastructure and existing Exchange™ servers "talk" to the PostPath Server™ in the same way, using the same protocolsand enabling the same features, as they do to Exchange™, without any need for modification.

The implementation of Exchange™ network protocols is unique, excepting Exchange itself, to the PostPath Server,™ creating a drop-in plug-compatibility that sets the PostPath Server™ apart from all the other non-Microsoft email solutions.

Click here to see a demo with audio commentary of PostPath's compatibility.

Drop-in plug-compatibility has four major components.

1. Client Software Compatibility

Outlook has become the de facto standard on corporate desktops. Users have become accustomed to using Outlook™ features like free-busy, shared tasks, custom forms, custom properties, and delegate access for quite some time. Native access to Outlook™ is the one of the keys to compatibility.

Of course, you can use Outlook™ to connect to any email server using POP3 and SMTP, but this may provide only a very limited subset of the collaborative features that users expect - and you may lose meta-data even for simple email.

To provide more sophisticated interactions with the server, some other Unix/Linux email vendors provide an Outlook™ client-side plug-in. These plugs-ins have to be installed and configured on every desktop, have to be maintained on every desktop (often requiring frequent updating), and in any case provide poor compatibility experience since they rely on intercepting API calls at the client, NOT on server-based protocol compatibility that Exchange™ (and PostPath) provide. Plus, of course, the desktop plug-in does nothing to help with the other things required for drop-in compatibility identified in sections 2, 3 and 4 below.

It is simple to distinguish "native" support from non-native support. If any type of desktop plug-in or connector is required, it is NOT native, and the compatibility experience will likely be comparatively weak. Native compatibility requires using the same protocols as Exchange™.

Prior to PostPath, Exchange was the only email server that gave you native access to Outlook's™ advanced feature set. With PostPath's drop-in compatibility break-through, customers finally have a real choice.

2. Active Directory Compatibility

In the last few years, many enterprises have adopted Active Directory and put substantial effort into setting up their AD environment. Until PostPath, Exchange was the only email server that tied directly to AD for email routing and user management.

The PostPath Server's™ plug-compatibility allows it to tie directly into AD and use unmodified Microsoft Active Directory™ tools for tasks like creating users and moving mailboxes. Any other approach would effectively be asking customers to run a second user management system and keep it in synch with AD - clearly not a desirable solution for any organization, especially larger ones.

3. Other Applications ("Ecosystem") Compatibility

We often refer to this group of applications as the ecosystem. The ecosystem includes applications like Blackberry Exchange Gateway™ or Goodlink™, Sharepoint™, Project™ server, and fax software. Some of these applications are critical. If users rely on Blackberry™ message synchronization (B.E.S.) then it becomes a requirement that cannot be removed.

Since these second and third party ecosystem applications communicate with the PostPath Server™ just as they communicate with Exchange™, the ecosystem works seamlessly, without modification or disruption, with the PostPath Server™.

4. Server-to-Server Compatibility

This is one of the most critical facets of the PostPath Server™ for enabling deployment to be carried out in a practical fashion.

Any new email server must co-exist with all the existing Microsoft Exchange Servers; otherwise the organization will be cut into two pieces, those on the new server and those on the old, and the two pieces will not be able to collaborate effectively. Absent server-to-server compatibility, IT administrators would be under pressure to effect a rapid cut-over to a new server - and email is simply too mission critical for such rapid changes.

However, since the PostPath Server™ does have server-to-server compatibility with Exchange™, users on the new server can still collaborate fully with users on the old system. This allows you to move a relatively small number of users (or even start with just one) to the new system and try out PostPath without cutting PostPath off from the rest of organization. Having proved the system, you can migrate gradually without losing any interoperability. This keeps you from having to make a sudden switch over to the new solution (i.e. no big bang migration). In practice, server-to-server compatibility gives customers who would like to try a superior alternative to Exchange™ a path to upgrade to the new solution at low risk since each step of the migration can be proven out and since each step can be reversed (by migrating users back to the old servers) as easily as it was made if something does not work out.

Low risk migration is a cornerstone of our philosophy on compatibility and is crucial to allowing customers both to try a new system and then to migrate to the new solution at their own pace. Of course, given the PostPath Server's™ compatibility, you can use the Active Directory™ user migration tool to move users, and their data, between Microsoft Exchange™ and the PostPath Server™ without even having to touch the desktop (Active Directory™ automatically redirects the user to the PostPath Server™ the next time that user starts Outlook™).