Why Sun Did a Microsoft Outlook Plugin Versus Proxy??

Many of our Java Enterprise System (JES) customers have been asking for an easier method to deploy Email, Calendar, and Address Book services? Usually these poor administrators are stuck because end-users love Microsoft Outlook.

So, why doesn't Sun make a Exchange "like" Proxy? The answer now is no way. The reason for this answer might surprise you.

Microsoft Outlook and Outlook Web Access (OWA) are Microsoft's flagship MAPI clients. Messages that originate from MAPI clients are encoded into binary large objects (BLOB) and then shipped over using the Transport-Neutral Encapsulation Format (TNEF).

#1 Microsoft Maintains a Proprietary RPC-based Protocol (TNEF) between Outlook and their Exchange Servers. They do not publish and support developers (to our knowledge) using this protocol. Sun tries extremely hard to focus on Open Internet Standards such as SMTP, IMAP and POP protocols.

#2 Should Sun "reverse engineer" this RPC-based Protocol, we cannot give any guarantees that Microsoft will not suddenly change their RPC Protocol from under our customer's feet. This is how Microsoft locks you into their world!! Like a gun to your head.

#3 Even Microsoft's best Exchange Consultants admit that the Microsoft RPC protocol contains too much network overhead. So why would you even want to use it?

#4 Sun's Communications Software Suite out performs Exchange Server in many fronts. We typically have 100's of Millions mailboxes in use by Telecommunications and Service Provider customers. They know the cost of ownership on our platform outshines anything else on the market. Why would you staff so many Exchange administrators when you only need 1 or 2 Sun Mail Admins?

Many customer claim that TNIF's encoding of BLOB message data is more secure than SMTP. This is actually false. Even Microsoft's own Exchange 2000 Server Frequently Asked Questions that by using TLS (SSL) encryption client-to-server and server-to-server, it is good or better than encrypted RPC of Exchange.

The only reason that we work with the Outlook Connector is that this collaboration software has an extremely wide install base in the Enterprise. Recently, we are seeing more and more companies start to move away from the Microsoft Office focus to start to support alternatives such as Mozilla's Thunderbird.

Sun celebrates moves to Open Standards, yet Microsoft still retains the concept of "innovate into locking you in." Given these reasons, Sun has provided the Outlook Connector Plugin to customers as a way to still maintain most of the Outlook Client Application's functionality, but still protect our customers from the dangers of using Microsoft's proprietary protocols. A TNEF Proxy would be a very bad thing indeed.


Special Thanks to Arnaud Quillaud for raising these points.

Recommended Readings:

Escaping Vendor Lock-in: Life After Microsoft Exchange
Technical Note Published in Java Enterprise System 2005Q4 Deployment Examples and Technical Notes Collection

Exchange Server RFC and standards compliance (or lack of) published on Microsoft.com


Jonathan, Like many folks, the employees at the company I work for want the outlook "experience". We did a bake off and decided that we did not want the exchange lockin or price.... JES mail/calendar to the rescue (but not as a subscription, it is way cheaper to just purchase the pieces individually.) To make a long story short, we recently purchased a 1250 user license, and will be replacing our existing groupwise system with the jes stack sometime around Q2/Q3 (need to wait for my new v490's, T2000's and x4200's to show up :-) Having played with the product, and having dealt with the sun app servers and directory servers for the past 4 years..... I have just one request: I want a simple way of deploying the entire mail/calendar/im/web stack in a manner that does not require a set of documentation a foot thick. In prep for this move, we setup a small lab and followed the single host deployment instructions. Talk about a pain in the ass (even more so when we discovered that anything with SSO will not work on x86. Period, end of story. Ok, it will work with Solaris 10 FCS, but you cant apply any patches) While it is nice to see how we will be able to scale this thing out to deal with 1,000,000+ users, it is massive overkill for anybody with less than 10,000 users (suddenly the thought of running 4 exchange servers sounds like a good idea :-( So, is there any chance of seeing a slightly more integrated setup procedure? One that would dump the entire thing onto one host (with the option of a SunCluster and/or VCS agent to deal with failover)? While I like the flexibility that one gets with the current deployment steps,

Posted by John on February 20, 2006 at 12:11 PM PST #

John, You raise some good points. We do need to do better in a couple of areas. If anything, I'd like to give you an update on our progress. #1 (first the easier one) SSO working on x86 I believe you are refering to an Access Manager bug #6367058 . I have good news, I just talked to the engineer, and we have a fix for this issue. The issue relates to a backwards compatability issue in the C AM ADK which Messaging Server uses. Please contact your support to obtain a fix. We expect a patch to be released in 3-4 weeks. #2 Removing Complexity of the Installation of Communications Server We are working hard on simplifying the installation of the Java Enterprise System (JES). We are currently working out two options which will address significatly different parts of installation. First, a template based installer which will allow automation of Sun Communications Software Components. The second, is an EZOffering installation. The First one will be useful in your deployment because, in the planning state of your deployment, you can create a text file template of the installation. This template can be run against the installation to create front-end/back-end boxes as I have in my previous diagrams. The Second one will improve the experience you had in your evaluation. The EZoffering will allow you to download and install much faster than before.

Posted by Jonathan Hawkins, Sun Communications Deployment Architect on February 22, 2006 at 06:39 AM PST #

Post a Comment:
Comments are closed for this entry.

I'll be writing about topics that would interest users and developers of Sun Java Communication Suite.


« July 2016