Slashdot Mirror
When Is Exchange Inappropriate For The Enterprise?
malice95 asks "At my company (approx 1000 users) we currently run Dual Sun Ultra 2's (Solaris) in an HA configuration for our mail system. It runs Sendmail with pop, imap, web-based e-mail, web-based e-mail archives, and approximatly 150 Majordomo mailing lists. The system has been working great for months. Our users use a mix of Netscape, Outlook, and Pine to read their e-mail. Lately there seems to be a small but politically forceful faction in the company that wants us to move to MS Exchange for our entire e-mail system and standardize on MS Outlook for the desktop. I have seen many exchange setups crash and burn at other companies, and become management nightmares. Can you help me come up with opinions/facts/experiences why exchange sucks as an enterprise e-mail solution versus a nice solid Unix solution to present to management?" There are times when standardizing on Outlook and Exchange may be desirable for a company and times when it is not. Is this one of those times, considering that it looks like this company has a perfectly working mail system already in place? Why or why not?
If it aint broke, fix it till it is (broken)
BOSTON SUCKS!
Why change something that works well?
Exchange has the potential to introduce a number of new headaches into a system that works very well. Why change?
If they want to standardize on Outlook for the desktop, go ahead and do that. But that doesn't mean they need to get you to change your entire backend to run Exchange.
The Good
- Unified message storage makes backing up everyone's mail a breeze
- Outlook MAPI clients get instant new message notification without having to check every 10 minutes - A HUGE PLUS. I have yet to see a POP/IMAP solution that does this reliably.
- Connects with pretty much every mail system out there
- Supports Outlook as a MAPI client, and all POP3 and IMAP mail clients running on any OS
- Fairly easy administration and all message system recipients are shown in the "Global Address List"
- Exchange performs quite well on a single processor system with 256MB RAM
- Installation is pretty easy
- Mail server clustering (failover) is supported, although at a cost
- If your users gripe enough, you can enable the web-based messaging at a performance cost
- Messages to multiple receipients are stored only once (with multiple pointers) to reduce information store usage
The BadIn short - I like Exchange for it's features. It definitely has an advantage over sendmail/pop/imap. BUT - The need for a dedicated server (difficult for smaller installations) and astronomical costs make the decision more difficult.
Hope this helps.
LOAD "SIG",8,1
LOADING...
READY.
RUN
HP is an american company. As you know the product is produced in the Pinewood England office. Openmail enjoys far more popularity in the EU/UK area than the US.
You probally did Openmail Internals just like I did.
This boils down to the following. Before outlook came out MS had there crappy exchange and MS mail clients/servers. At that point HP was years ahead of MS. HP released a NT version of Openmail. The word directly from HP was MS hit the fucking ceiling. They told HP that if Openmail wasn't pulled from the NT platform that they'd drop them from the NT VAR/OEM program. They would no longer get advanced releases. This would screw HP because they need to write drivers for NT for the custom hardware they make.
Openmail NT was pulled from the product lineup and is a footnote in history.
HP was really hoping that OS/2 would take a better hold of the market. At one point IBM sold a branded version of Openmail. When OS/2 crapped out that left HP out of the intel platform. And thus could never hold the costs down.
As far as cost reductions I can chip in the following. It was never the software it self that created the high cost for us as a HP Openmail customer. It was the cost of hardware and Unix support. Implimenting UNIX upgrades cost far more than NT service packs. Buying K series servers sucks big time.
This is where Linux comes in. If Linux becomes workable to the high end business customer this opens the door for large scale Intel boxes that would run openmail. Hardware costs would be reduced greatly, and the OS would be free.
That's my $.02
This sort of discussion went down at the University I work at a couple of years ago. That time period is now called by everyone (even the upper level of University management) the Email Wars.
For nearly two solid years, there was a large push by some in upper management to migrate our entire user base (some 80K students, faculty, and staff) to Exchange, regardless of the number of technical staff and managers informing said upper management of the large downsides, not the least of which forcing a client (MS 9X/NT) platform on the faculty.
That being said, we settled down to have a modest Exchange environment with about 5000 users across two campuses, and about 80000 users across two campuses using the freely available and open-source Cyrus IMAP server from CMU.
In the past year, there have been more serious security incidents involving executable content with the Exchange servers, forcing the University to purchase a Sybari license to prevent being overrun with virii. The Sybari stuff is not inexpensive.
My current position with the University is as a senior software/systems engineer. For the most part, I design mail systems. In my professional opinion, unless the features that Exchange gives you (basically calendaring and integration with MSOffice -- everything else, including folder sharing and collaberation are available in more secure products) are worth the amount of time and money that will need to be spent to secure the environment, it would be a bad idea for folks to migrate from an IMAP environment to Exchange.
Exchange in all our tests proved to be less scalable than a UNIX based IMAP solution. More people are required to support fewer users on Exchange. On top of that, individual servers crash often enough that it is not really an event when it happens. Admittedly, an individual Exchange server crashing only affects a couple thousand individual mailboxes, but they crash enough that spreading out load in necessary to maintain the illusion of continuous service. This is not a knock against the people running th Exchange servers. The Exchange admins I work with are bright, talented people. The server software crashes all on their own. Microsoft's own consulting people have not found a flaw in the Exchange system design here. The software just crashes often.
That is the security and performance part of my analysis. Beyond that, Exchange generally does not like working with the outside world. Mail routing can be an issue unless you have a very simple network design. Features in Exchange can be fairly confusing to even experienced users. My personal favorite in that vein forwarding. If a user wants to forward their mail another system (say a personal workstation) Exchange will munge the headers so that the original recipients of the message are not entirely clear. This has led to some embarrassing incidents where people have replied to messages that they thought were to them personally, but were actually to a distribution list. The reply went to the reply-to, which ended up distributing to everyone on the original list.
Even beyond that was the arrogant attitude displayed by Microsoft when bugs were reported. At one point, we discovered a bug that would crash the storage server when accessed via IMAP. Once a check was signed, their interest in working on problems with our existing implementation was gone. I know this should not be unexpected (Reboot, Re-install, Upgrade being the MS Tech Support Mantra), but when Microsoft representatives are in a room with the University officials and actually say words to the effect of, "Who are you to tell us what is wrong with our software", it at least validates the anecdotal opinion of Microsoft.
Much of this may not apply to your situation, but this might. When we did our studies of cost per user of a UNIX based IMAP solution as opposed Exchange, it ended up being an order of magnitude cheaper to use UNIX for the bulk of our email serving.
On a related subject, we dropped Russell Calander Manager. Calander Manager imediately showed conflicts in schedules (vs waiting someone reading mail and replying) With Outlook, those checking the calander at the beginning of shift go to cancelled meetings or miss changed or recently scheduled meetings because there wasn't time to sift thru all the stuff in the inbox. With Outlook you have to open any mail that may contain a schedule event to update your calander. Same thing applies for cancelled meetings. I have found out about meetings after the fact. I have attended cancelled meetings. In Russell Calander Manager, some of the users were confrence rooms, vacations and the like. I could schedule a meeting and include the confrence room as an attendee. I could schedule Easter off and include the apropiate vacation slot as an attendee. It works first come first served. No arguements over who was first. Anyone else later would be get a conflict as the confrence room or vacation slot was unavaliable to attend. This made confrence room use a breeze. If you really needed a room, you could e-mail the person who scheduled the room to negotiate and they could re-schedule freeing up the room so it could attend your meeting. (the room auto accepted the first requester). With Outlook sometimes two groups arrive to use the same room. A person has to read all the mail for the room and reply to it later (not real time by someone not working 24/7). Therefore several people can get unconfirmed dates and times for a room. What a mess.
The truth shall set you free!
What you need to do is find the business reasons that they want to switch. Is there something specific they want to be able to do that exchange allows? If not, then it is stupid to switch. If so, you need to find out
a) what the costs are to implement said functionality with exchange
b) what the costs are to implement said
functionality without exchange
Include all costs - hardware, software, licensing, support, man-hours of work, user training, sysadmin time on installation of outlook on all machines, server maintenance, scalability costs, etc.
The problem with most decisions is that the full costs are hidden. It's your job to bring them to light, and to show what the actual costs are. If they are willing to take those costs for the functionality they want, fine. Its your job to give it to them. However, if they don't know all of the options and their true costs, then that's your fault. If the have the knowledge an make bad decisions, there's nothing you can do.
Engineering and the Ultimate
Once upon a time I was a consultant and had to discuss this issue all the time. Before we give you a counter argument, let's deal with what they are usually _really_ asking for:
-A single address list (OpenLDAP anyone?)
-Consistent look and feel to messages (Make everyone use the same format.)
-Ability to directly use rich content in messages (See above. Pine users will probably take a beating on this one though. Sorry.)
-Group scheduling (There's freeware that can do this. If the company is anti-open source, use the iPlanet calendar. If you use an HTML based scheduler, you can tell them how you're aligning the company for e-biz through the Extranet/Internet/insert buzzword of day here.)
I'm going to venture out on a limb and say that they are probably pro M$ techies or on the business side. If they are on the biz side, they only know what they've experienced and/or heard. M$ eXchange is commonly credited with providing all of that functionality. Now on to the points that you can use to counter this force:
- Cost. I wouldn't make the typical free software
argument at all. Avoid it with PHBs, it's a black hole. Rather I'd talk about the increased administrative costs, the poor ROI on software that gobbles up resources and the cost of outages.
- Reliability. I've been forced to live in several environments where exchange was implemented. Even in the best of them, the mail servers went down on average twice a week. Sendmail in a HA config is great since you can migrate the storage and keep on trucking. Let's not forget the ease of adding upstream MX spoolers in the event of a link problem. Ever use exchange
as a spooler? Ick.
-Complexity. Depending on how much mail your typical user gets/sends/processes, the amount of storage and processing requirements vary wildly for exchange. Odd are you'll have more than two servers (I'm guessing five.) Shared storage and data volumes? Good luck implementing this under NT 4/Exchange 5.5; remember that exchange sticks every message in a database which makes it a major PITA to even consider shared volumes.
-Productivity. It costs time to use outlook. Outlook is slow and difficult to use in comparison to netscape mail or even outlook express. They'll go for the directory argument so be prepared to bring up LDAP.
I hope this helps you out.
You know what to remove for e-mail. Don't you?