Microsoft, Linux square off in InfoWorld’s Exchange migration challenge

reviews
Feb 11, 200521 mins

In a series of real-world tests, four Linux messaging servers vie to take down Microsoft Exchange. Will they fly high or crash and burn?

See correction at end of review

For IT administrators, the pressure to move away from Microsoft platforms can almost seem palpable, especially at midsize businesses where data dollars are already stretched thin. Microsoft’s products, including the company’s dominant Exchange messaging server, beg to be upgraded 18 to 24 months after purchase. That’s a tough load for some customers to carry. Yet the prospect of shifting platforms can be daunting, as the consequences can be dire and the path to successful migration uncertain.

The benefits are alluring, however: a longer run for your technology dollar and less dependency on additional Microsoft products for full functionality. At least that’s the theory we decided to test. Can a company successfully migrate from Exchange to an entirely different platform, and does the move make sense after everything is said and done? To find out, we developed InfoWorld’s first Exchange migration challenge, sending out a small flock of Linux-based competitors to face Microsoft Exchange Server 2003 Enterprise Edition.

Our scenario starts with a harried IT administrator managing a 500-node network with Windows 2000 Server and Exchange 2000 on the back end and Windows XP Professional facing users and running Microsoft Outlook 2000, XP, and 2003. The object of the test was to swap out the Exchange 2000 server — and that server only — and replace it with a new messaging solution.

Caveats included communication with Active Directory, where required; full mirroring of all core Exchange collaboration features, including shared schedules and contact lists; and a Webmail feature to contend with OWA (Outlook Web Access). Finally, these solutions couldn’t in any way affect end-users’ day-to-day e-mailing experience; users would continue to use Outlook, thus obviating the need for retraining expenses. We also examined the migration from the business view to determine whether the Penguin really makes sense in the long run.

Stepping into the ring were four big-name commercial Linux messaging platforms: Gordano Messaging Server 10.05, Novell’s Suse Linux Openexchange 4.1, Scalix 9.0.1, and Stalker Software’s CommuniGate Pro 4.2. We also invited Microsoft, which responded with surprising enthusiasm, sending full-version copies of Windows 2003 Server and Exchange Server 2003 Enterprise Edition.

By the end, we’d seen more e-mail servers than we ever wanted to, but more important, we discovered some surprising muscle among the Penguin people when pitted against Exchange.

Gordano Messaging Server 10.05

Those of us who’ve suffered through an e-mail server upgrade know that several tedious steps are necessary, especially during the migration process. The GMS (Gordano Messaging Server), however, is looking to change those rules by offering a unique feature that makes it easy to move clients to the new server in real time. Coupled with the rest of its impressive feature set, this made GMS one of the standouts of the review.

We initially tested GMS Version 10.02 running on RHEL (Red Hat Enterprise Linux) 3. We discovered early on that although the overall documentation could use polishing, the administration guide offers a helpful matrix for determining server requirements for environments of various sizes.

Early in the setup process, however, we had difficulty accessing the browser-based admin interface, even though we followed Gordano’s manual to the letter. The company’s technical support team was very helpful, but ultimately, Gordano had to offer us prerelease Version 10.05.

After everything was running, however, migration was surprisingly easy, thanks to GMS’ real-time feature, which migrates a user’s mailbox the first time he or she logs in. After configuring GMS to point to Exchange and adjusting Outlook’s settings appropriately, we logged in and opened the client. E-mail migration took place in the background. The initial log-in was slow during the migration process, but after that, we noticed no other reductions in performance.

We then installed the Gordano Collaboration Server software, which acts as the MAPI connector. This component provides the address-book link, while the previously defined IMAP connection handles e-mail. The installation was simple, and the tool worked as promised. At this time, GMS supports the migration of e-mail items only; calendar and contact entries are not supported. This has been promised for a future release. We were able to maintain our contacts and appointments by copying them to a personal folder prior to the migration and then to the new mailbox when migration was complete. This approach may not be practical for larger migrations.

SMTP messages enable GMS and Exchange to coexist during migration. Scheduling across the two systems uses Outlook’s Internet Free/Busy search, which is configured at the Outlook client. This approach is effective and seems to be the method of choice for most e-mail systems when scheduling with Exchange. And finally, GMS’ Webmail interface proved easy to use and offered users the full suite of e-mail, calendar, and directory functions.

Overall, we very much liked Gordano’s unique approach. Our only point of caution was that the production software was incapable of functioning properly, forcing us to move to a beta version to complete the review. When these bumps are smoothed over, however, GMS is certainly a product worthy of consideration, especially for small and midsize installations.

Microsoft Exchange Server 2003 EnterpriseEdition

A test of Exchange competitors wouldn’t be complete if we didn’t look at the reigning heavyweight as well. So we put Exchange through the same paces, migrating from Exchange 2000 to Exchange 2003. The results were more favorable than we had anticipated

New features in Exchange 2003 include more granular setup permission capabilities, new distribution group features, new internal support for anti-spam, and increased support for third-party anti-virus products. But even as we raised our eyebrows at the feature set, Microsoft revived its Exchange road map, once again bringing that palpable upgrade pressure to bear. Exchange 2003 Enterprise Edition is a wondrously deep product, but expect to pay for it.

We initially assumed that because we were remaining on an Exchange platform and simply upgrading the software version, the migration would be a piece of cake. Although it was certainly easier than moving to another OS platform, there were more surprises than we had expected.

With the existing Exchange 2000 server configured with 500 users, we attempted to install Exchange 2003 on a second machine and follow the migration with that. We then promoted that server to a domain controller after running Microsoft’s ADPrep utility, which prepares Windows 2000 servers for upgrade to Windows 2003 by extending the Active Directory schema, adding new directory objects, updating security descriptors, and making other nifty tweaks.

This brings up an important point: When migrating from Exchange 2000 to Exchange 2003, you may not be moving from a Windows OS to a Linux OS, but with the Exchange upgrade, Microsoft is asking you to move from Windows 2000 to Windows 2003. That’s not to say that you can’t run Exchange 2003 on Windows 2000, but upgrading to 2003 is the only way to get full functionality for features such as Active Directory integration and HTTP-based communication between Outlook and Exchange. Similarly, an upgrade to Office 2003 is also recommended, although if you push a little, you’ll find that versions of Exchange 2003 are shipped with both Outlook 2003 and associated client access licenses included, regardless of what version of Office your users are running.

Being dutiful reviewers, we made a 2000-to-2003 upgrade part of the test. Then we ran the Exchange 2003 deployment wizard, which satisfied the prerequisites for installing Windows ASP.Net, NNTP, and SMTP services. When we restarted the setup utility, however, we received an installation error on Forest Preparation.

That turned out to be a bit of a stumper. But after reading two Microsoft TechNet Knowledge Base articles and performing a separate Web search, we found a helpful article that suggested an environment variable was the culprit. This wasn’t a critical problem, and in the end, it was easy to fix; considering that both OSes and e-mail servers came from the same vendor, however, it was a mite unexpected.

After completing the installation, we attempted to install Exchange 2003 Service Pack 1. Again, even within this single-vendor environment, we found that a hot-fix download was needed. After we added this, the remainder of the installation completed successfully.

The migration of users consisted of pointing and clicking inside Active Directory’s Users and Computers interface. Migrating users either individually or in groups was a breeze. Here, an Exchange-to-Exchange migration really pays off.

Most coexistence functionality tested well. Sending mail and sharing folders between Exchange 2000 and 2003 users was no problem. Free/Busy searches didn’t work initially because there was no replica of the Free/Busy public folder on the new server. After we created that, we were able to share calendar information as well.

The new version of OWA was Exchange 2003’s most impressive aspect. It very closely resembles an Outlook 2003 desktop client in both style and functionality, making it a real alternative to using the full client. The only downside to OWA 2003 is that full functionality is available only when using Internet Explorer. Given IE’s reputation for ongoing security problems, that may not sit well with some customers.

Overall, aside from two marginally well-documented technical hiccups, this migration was far slicker than that of any of the Linux contenders. But frankly, that’s to be expected, considering all the variables that originate from the rainy Northwest. The question is whether a little convenience supersedes the significant price advantage offered by the Linux folks.

Novell Suse Linux Openexchange 4.1

Suse Linux has been a major Penguin player for years, and Novell’s recent acquisition of the operating system offers exciting possibilities. Although Novell didn’t acquire SLOX (Suse Linux Openexchange) outright, it is marketing the product in the United States and will continue to do so for the foreseeable future.

That’s good for Novell, as SLOX — based on the venerable Postfix mail server — proved the easiest to install. An important factor here is that SLOX runs on, not surprisingly, Suse Linux and that Suse/Novell makes this transition as easy as possible by including both the e-mail server and the OS in the same installation routine. Start the server, insert the CDs, and watch the OS and e-mail server install together.

In fact, SLOX will install only if it gets to install its operating system software as well. This is worth remembering before you run out and buy another Linux distribution to run this mail server. Although we liked the simplicity of this scheme for new servers, we can see how some users might wish for the ability to install the server product on either another Linux OS or an existing Suse server.

Because the same vendor is providing the OS and e-mail server, the Web administration tool incorporates both e-mail and OS functions into a single console. The Web console is easy to navigate, but there are areas that could be more intuitive. It handles most system administration functions, yet we found advanced Postfix e-mail functions, such as relay domains, that could not be configured from the GUI. SLOX takes this into account and offers the option to edit the configuration file directly if you’re savvy with Postfix.

SLOX does not include a utility to migrate from Exchange. We asked the company’s technical support department about this; they recommended we purchase a migration tool from Binary Tree called CMT (Common Migration Tool).

CMT installed on our Windows XP workstation. Initial attempts to run it generated the error “unable to log into top level folder.” To resolve this, we had to log in to the workstation as an Exchange administrator, a fact that Binary Tree’s documentation neglected to mention. Also missing were online help files for this section, making this part of the migration something of an adventure.

After we used CMT to extract the data, we moved back to the SLOX server, encountering several problems in the process. The first arose when we tried to import the data using the included SLOXMigration.pl tool. This did not work properly due to a missing Perl module that should have been included with the installation. After a little digging, however, we were able to manually install the module and continue.

Another interesting problem occurred when we manually created users from the Web interface. Each attempt failed the first time and then succeeded the second. We e-mailed SLOX’s technical support staff about this but never received a reply.

Although the iSLOX MAPI connector for Outlook worked well for mailbox items, attempting to view public folders generated a WebDAV error. The Webmail interface proved more usable than the Outlook connection because the public folder problem seemed to be specific to iSLOX.

Another issue with SLOX is that unlike most of the other products we tested, which use either IMAP or a proprietary protocol, SLOX relies on POP3. By default, POP3 downloads messages from the server to the client and then deletes them from the server. Unless this setting is manually changed on the client, messages cannot be opened in Webmail after they’ve been opened in Outlook because they are no longer on the server.

SLOX uses the open source Postfix mail system as its MTA (mail transfer agent), a nice choice instead of relying on something proprietary. Several add-on options such as anti-virus and anti-spam can be configured on Postfix.

On the installation front, SLOX has no peer. After that, however, migration from Exchange proved difficult, and its MAPI connector isn’t the best. But for folks familiar with Suse and willing to learn its quirks, SLOX is a stable platform backed by a vendor known for solid technology.

Scalix 9.0.1

The Scalix messaging solution is definitely not a newcomer. With a sweet price point and all the features you’d expect, there’s a lot to like about Scalix 9.0.1 — although we ran into some problems with its documentation.

We tested Scalix on RHEL 3.0. Because RHEL’s one of the recommended OSes, the documentation came with instructions on which packages to include during the installation.

Only one glitch arose during the initial installation. Per Scalix’s instructions, we downloaded and installed the newest versions of the Java SDK and Apache Tomcat’s application server. The new version of Apache caused the Web interface to fail, although we were able to resolve this issue with a call to Scalix support.

The Web administration tool includes an easy-to-use rules wizard that helped with the initial configuration. A series of tools are included for Exchange-to-Scalix migration, including scripts to create Scalix accounts and to populate directory information. Populating the Scalix directory with Exchange user information is accomplished with a shell script.

The shell scripts were easy to use, except for one initial problem: They appeared to have been created with a Windows text editor. Our initial attempt to run the scripts failed, and we had to run the Linux dos2unix tool to convert the files.

Scalix includes a third-party mailbox migration tool from CompuSven. The tool runs on a Windows workstation and uses an account that has Exchange admin rights in the domain. After we created the user accounts using the shell scripts, we used CompuSven to pull mailbox data from Exchange.

The CompuSven tool worked well, but the documentation left a little to be desired. For example, we ran into problems formatting user names. The fix involved editing an .ini file, but this was not documented, nor could we find an answer using online help. We had to call tech support.

We liked Scalix’s unique approach to coexistence with Exchange during the migration. All user accounts are created in Scalix with an autoforward rule pointing back to Microsoft Exchange. This allows already migrated users to send mail to their Exchange colleagues as if they were already on Scalix. As more users migrate, the autoforwards are simply removed, either manually or with the included shell script.

In our coexistence tests, we found that e-mail and directories functioned smoothly but that appointments did not. Replies to appointments sent between the two systems were not entered into the Scalix calendar.

We used the included MAPI connector to connect our existing Outlook client to our new Scalix mailbox. This was easy to set up, worked well, and should present little challenge to anyone already familiar with Outlook. The Webmail interface was also easy to use.

Scalix has been working hard since our test cycle, revving all the way to Version 9.2, which debuts Feb. 14. The latest version will increase the functionality of the administration console and will smooth out the stumbling blocks in its installation wizard. Finally, you can expect increased support for Free/Busy database searches for schedule sharing.

Scalix is a solid solution for folks needing a straight e-mail server. Its migration and coexistence strategies are excellent, although its Web administration needs to move a little further from the command line. You won’t find fancy add-ons such as IM or SIP support on Scalix, but you will find a robust e-mail server combined with Linux reliability.

Stalker Software CommuniGate Pro 4.2

Possibly the least known of our entrants outside of GMS, Stalker Software’s CommuniGate Pro is an exceptionally mature, robust e-mail server product that competes with Exchange not only on the Linux OS platform but on a couple dozen other OSes as well, including NetWare, Windows, and almost any other flavor of Unix.

In keeping with this challenge’s Linux focus, however, we installed CommuniGate Pro 4.2 on RHEL 3.0. Because the instructions did not specify any customization for the base OS install, we tried a default RHEL server configuration. The CommuniGate installation complained that several required gcc files were missing. Stalker needs to add these instructions to its documentation.

When those tidbits were installed, things looked up. We first encountered a nicely laid-out browser-based administration console. The interface supported most of the functions for administering the system, although we did find it annoying to be forced to re-enter credentials when moving to different sections of the console.

Unlike some of our other entrants, Stalker handles mailbox migration internally, offering a free utility called GCP, downloadable from Stalker’s Web site. Also included is pwdump, which extracts a user’s Windows passwords to be ported into CommuniGate, eliminating the need to create new passwords. This option is a nice convenience for organizations not planning to use Active Directory to maintain SSO (single sign-on), although the password extraction process may violate security policies at some companies or government entities.

Mailbox migration was easy using GCP. It required us to create a domain account with Exchange administrator rights. Furthermore, the tool does not support migration of public folders, but we worked around this by creating a copy of the public folder in a user’s mailbox.

Stalker failed one step of the migration challenge: It lacked a coexistence strategy. The documentation provides no information on how to share a company’s SMTP suffix (for example, user@company.com) across the two systems or how to synchronize directories between CommuniGate Pro and Exchange during the migration. The suggestions offered by Stalker’s technical support did not go very far. Depending on how long your company would need to exist on two e-mail systems, this may be more than a minor inconvenience.

On the upside, the Webmail interface appeared well-designed and easy to navigate. The MAPI plug-in for Outlook worked reasonably well. Free/Busy searches between CommuniGate and Exchange are achieved using Outlook’s built-in Internet Free/Busy Search function.

Stalker’s suggestion for searching for users still on the Exchange server is to define an LDAP directory entry on each workstation’s Outlook setup to point back to the Active Directory server. This is effective but time-consuming, as it must be configured within each user profile on each desktop; although one could probably write a Windows script to push the change out across multiple desktops.

Unlike any of the other products, CommuniGate Pro doesn’t need much in the way of third-party software. Additional plug-ins that support anti-virus and anti-spam functionality are available from Stalker’s Web site, but they require an additional license charge. Stalker is also the only company in this roundup looking to own as many forms of messaging as possible within a single server product. CommuniGate Pro is slated to include IM and SIP support in the near future. Of the competition, only Microsoft offers similar features, yet those are reserved for separate product lines.

Another major difference between Stalker and the other contenders is its licensing scheme. Stalker bases its charges on hourly mail volume rather than on the number of users. This could be trouble if your hourly volume exceeds the license purchased, which can happen for various reasons, such as a major virus or worm outbreak across the Internet.

By the time you read this, a new version of CommuniGate Pro will be available, with increased support for calendaring clients using HTTP, support for Active Directory Kerberos authentication, and a new MAPI connector.

In the end, we were very happy with CommuniGate Pro. This isn’t a Linux-come-lately platform but a polished, robust messaging server. Our only worries are the strange licensing scheme and its need to handle all add-on software internally. Being forced to turn to Stalker for virus and spam protection and for IM and VoIP support can be a lot to ask.

Trade in Exchange?

In the final analysis, we didn’t see enough value in simply upgrading from Exchange to a Linux e-mail server and leaving the project at that. The dichotomy of skills and software resources is simply too much in the long term. The move makes a lot of sense, however, as the first step in a gradual migration of the entire back end to the Linux platform. The messaging server is a large chunk of every network’s back-end resources, but it is self-contained enough to allow IT administrators to get their flippers wet in the Penguin’s waters.

Additionally, we were impressed with our commercial Linux messaging contenders. CommuniGate Pro especially impressed us with its feature depth and product maturity. Scalix is another mature product, although it’s dedicated solely to e-mail and e-mail-based collaboration services rather than the communications hub feature set that seems to be CommuniGate Pro’s future. GMS and SLOX are also both capable solutions, but each has a little more to prove. GMS must polish its real-time migration features a bit, and SLOX must come out from under Novell’s shadow and prove it can stand on its own two feet when Novell returns its full attention to GroupWise.

But with all this, Exchange Server 2003 Enterprise Edition remains an attractive option, especially to those familiar with the platform. Ease of migration and a constant stream of integrations with other Microsoft products make for a seductive data sheet. Although Microsoft’s core support options cost more, the company has an incredibly deep well of support and technical knowledge freely available to customers. That paints a pretty picture for Exchange customers, as long as they can maintain that good mood at the cash register.

Only security and product stability stand out as reasons to examine options other than Microsoft. Unfortunately for IT administrators asked to back up these assertions with hard evidence, there are precious few objective third-party studies that really compare Linux and Windows server products on these fronts. Additionally, the biggest security holes in most midsize networks are Outlook and Internet Explorer — and our test scenario did away with both of these.

So Penguin e-mail vs. Bill’s e-mail remains a tough call. Midsize businesses can expect significant cost savings if they aim at an all-Linux back end after a gradual migration process. Microsoft’s products remain oriented toward large enterprises, so smaller companies with more static messaging requirements can really make use of Linux’s plug-and-forget reputation. You won’t see most of these savings simply by upgrading the e-mail platform, but it’s an excellent place to start.

Correction:

In this review, the version number of Stalker Software CommuniGate Pro was originally incorrect.

InfoWorld Scorecard
Manageability (25.0%)
Value (10.0%)
Setup (15.0%)
Security (25.0%)
Support (10.0%)
Features (15.0%)
Overall Score (100%)
Gordano Messaging Server 10.05 8.0 7.0 8.0 7.0 7.0 8.0 7.6
Microsoft Exchange Server 2003 Enterprise Edition 8.0 5.0 8.0 6.0 7.0 9.0 7.3
Novell Suse Linux Openexchange 4.1 6.0 7.0 9.0 8.0 7.0 8.0 7.6
Scalix 9.0.1 7.0 8.0 8.0 7.0 7.0 7.0 7.3
Stalker Software CommuniGate Pro 4.2 8.0 8.0 6.0 7.0 7.0 8.0 7.4