How Dave Does It: Comparing E-mail Vendors ("The Big Three")
Novell Cool Solutions: Trench
By Dave Muldoon
Digg This -
Posted: 31 Jul 2003
Working with a friend of mine who was tasked with researching a change in e-mail systems at a company he recently began working for, I began keeping track of all of the items needed to be considered in a situation that would be similar. Faced with the challenge of researching what it would take to change from one e-mail system to another, many administrators may struggle with the age-old question; where do I begin? This is where my friend was when he approached me on the topic. Having dealt exclusively with e-mail for such a long time, I was able to point him in the proper place for his research process, which he then provided back to his employer for final review and decision-making. I'm not going to tell you what the decision was. I'll let you make your own conclusion based on the information and direction that I provided him. I'm hoping this same information will provide a logical starting point for this process if you ever end up in this position.
Everything you will read here is based on items that I believe need to be thoroughly understood and considered with regards to changing e-mail systems. There are definitely more items to be considered and dealt with, but many are attributed to specific situations, and by keeping things on a general basis this information can be used by administrators of just about any e-mail system. That being said, this article is on GroupWise Cool Solutions, and has an underlying theme that a switch from GroupWise to another platform is being considered. So, let's get started with good stuff...
NOTE: This article is intended to be a reference point for new administrators who face the task of researching a conversion to a new e-mail system. I've tried to keep this article as general as possible, in regards to our industry today. At this point in time, Exchange is number one in market-share, followed by Notes and a close 3rd is GroupWise - depending on whose reports you read - this particular set of statistics is from Gartner.
Messaging in general:
How many of the GroupWise administrators out there are familiar with things like this:
- Memory leaks
- High CPU utilization
- Client display problems
- Occasional client print problems
- Processor problems on servers
- Directory synchronization problems
- Messages stuck in the queues
Now, what if I told you that this list was gathered from Microsoft's web site, and is related to items fixed in their latest Service Pack for Exchange. Surprised? Maybe some of you are and some aren't. (NOTE: I should mention that I've chosen these items specifically from the list to highlight a point. It's also important to understand that because of the way the Exchange environment integrates with so many other MS applications, a significant number of fixes are done to assist with integration, including MAPI interfaces (MAPI32.DLL)).
So, what's the point of this list? Well, the point I'm trying to make is the grass has weeds on both sides of the fence. The same weeds grow with Notes as well. Do any of these items sound familiar?
- A code changes to eliminate memory leaks
- A code changes to fix multithreading and related issues
– and the list goes on.
So what's driving you and your company to consider a change in enterprise e-mail? That's the biggest question and I can't provide any insight there, as those answers are specific to your place of business. What I can do is begin to break things down into what I call "technical-business-related" aspects. Basically, what I'm going to point out high-level items in the process of changing e-mail systems. Throughout this article, I've tried to use categories that are logical in nature. As you read through this article you will begin to see that many of the specifics within these categories seem to overlap when looking at the impact to a corporation undertaking a change of this nature. You may even come across items that are specific to your situation; which is the intent of this article - to guide you into the proper research and fact gathering for your company. Just as my friend was able to do.
So let's start near the end of the entire change process. We'll assume that all research is done and it's time to implement the system–
I'll start the list of impacts with the obvious. New accounts for everyone! This is something that I'm certain the end users will not have any issues with. End users never want history or previous contacts, etc. - (okay, that's a little too sarcastic), but it's a BIG consideration on the technical side. Do you carry data over to the new system? Do you provide a period where both systems are used? Do you mix and match your decisions based on who it is requesting data (executives, etc.)?
What about the workstation side of things? New client access software has to be rolled out to all workstations throughout the enterprise. If considering Exchange as a replacement system, this client rollout often requires or is the proper time to leverage the installation of other Microsoft Office products for integration purposes. This is a spot where licensing costs can truly tip the scales in the decision making process. Also, don't forget those remote users who rarely get into the office, they'll need to be upgraded as well (unless you plan on putting in a new web access or RAS - remote access system).
So, continuing along the rollout, let's assume that you've now got the workstation clients and other integrated software installed successfully. Don't forget PDAs. They will also need to be managed. This may involve purchasing software for synchronization and deploying that software, (if the current software does not work with the new software suite being deployed). Maybe you even have other hand-held/remote devices such as RIM devices. Startup costs for RIM devices are significant and can add up when changing the e-mail system. Although, based on some digging in this area, you may be able to save on some of the cost if you can leverage the same vendor(s). Regardless, RIM support in this type of changing environment can go as far as the devices needing to be reclaimed internally and new ones deployed.
Okay, so now we'll assume that the client is on the workstation, application integration is working and PDAs and wireless devices are working. It's now time to tackle some of the simple, everyday things like Distribution Lists. In GroupWise, Notes and Exchange distribution list equivalents are native to the application. This means switching to a new e-mail system requires the lists and security principles behind the lists to be configured from scratch in the new environment. The same goes for resources such as conference rooms, projectors, vehicles, etc. What's the plan for resources that already have active calendars? Do you manually enter them or have everything re-sent from the new e-mail platform?
Continuing on with this system that's being implemented, we're going to have to assume that resources and distribution lists are now functional too. So what's next? How about SMTP application integration? This stuff needs to be tracked and any applications that were written to GroupWise GWIAs would need to be changed to point to the new infrastructure. Hopefully when implemented the system was based on DNS (instead of IP addresses). If so, this change to the new e-mail system's SMTP platform should generally involve DNS changes for MX and other A or C-type records that are hosted via internal DNS for application-programming.
Along these same lines, don't forget that mission critical Internet gateway; the external (ISP) sites for Internet mail will need DNS updates as well (MX records). And unless your company has been miraculously left out of the ever-increasing SPAM deluge, you'll need something to assist or to continue to assist with SPAM control. Also, when dealing with Internet e-mail, you'll also have to make sure the anti-virus software/solution that is deployed is compatible with the new e-mail system. Finally (relating to Internet e-mail anyway) if you've got corporate usage policies, filters, etc., those will have to be maintained within the new system. Basically, what I'm getting at is the likelihood that you will have to overhaul the entire "exposed side" of your e-mail system.
Allow me to take you on a tangent for a minute, as SPAM and viruses are a peeve of mine... Factually, e-mail viruses were twice as prevalent in the year 2002 than they were in 2001, with one e-mail in every 200 containing a virus. The virus-scanning company MessageLabs reported that it stopped 9.3 million viruses in 2 billion e-mails this year, which equated to one virus in every 215 e-mails (last year). That compares with 1.8 million viruses stopped in 718 million e-mails in 2001, or one virus in every 398 e-mails. Do you remember the names like Klez, Bugbear, SirCam, etc.? If not that probably means you were able to avoid some serious downtime and support headaches. This is definitely something that needs to be tracked very carefully when making a transition to a new e-mail system.
Now that I've got all of that out of my system, let me go back and touch upon SMTP applications again briefly for those of you who may not be certain what this means. To give you an idea; this type of integration can be used for custom applications such as Web, VB scripts, database driven messages, problem alerting, text or numeric paging, etc. In discussing these types of integration in regards to an e-mail system change, of course, comes testing (testing should always be done to ensure functionality remains the same in the new system) - which may require you to become an expert soon in integrating applications using SMTP.
So let's assume that you've got everything related to messaging up and functioning on a new platform. Don't forget one of the most important items - backups. If you're using an (OFM) Open File Manager in conjunction with your backups, you will need to make sure it supports the new e-mail system environment.
It's also important to note that a new e-mail system may require a new server operating system; Linux, Microsoft, UNIX. That new server OS will have to be stable when supporting a mission critical application like e-mail, so there may be research, development and training time involved to learn the intricacies of the new OS.
Lastly, if your industry falls under the HIPPA, SEC, NASD or other Federal regulations you'll have to deal with compliance issues/strategies during the transition, as well as in the final stages of the system. If the product or process that is being used for compliance is a third-party application, it may require quite a bit of development to merge both e-mail systems together to meet these regulations within that single application. You may also find after further research that a new product or process will be required that could impact your company legally or be cumbersome to the end users reducing productivity.
The cost of change:
Based on the above items, it seems like this process is going to be very involved and quite complex. I've briefly touched on items that can affect the cost of making an e-mail system change, with some of the above items, but now I'll expand on them. Let's start with end users. End users will need training on the new client application and possibly any new SMTP integrated applications - that's obvious right? Well the actual effects of this have a considerable impact on a corporation. There will certainly be a learning curve that will affect the productivity of end users when they search for ways to perform tasks which they already understood in a prior messaging system. Who will they call for help when they need it? Support staff. Surely support staff will require training. More often than not, support staff will require some type of advanced training, as they should have the answers that end users have questions for. That training costs money in two ways; money spent on the course for the support engineer, as well as the loss of productivity at the end-user level while support staff is diminished due to training. I'm not implying the support desk is left unattended. Rather the support desk will be left with existing support staff outnumbered (calls to staff) during training as compared to a "normal time period". Of course, there's always the ability to staff "heavily" during this "training time" - with an associated cost.
Okay, so now the support staff is trained. That's the end of it right? Well, what about you - the administrator? Administrators are supposed to have all of the answers for everything right? And they are supposed to provide advanced end-user support, implement systems, develop and test integrations, assist business units with messaging-related projects and that list goes on and on, as you're all aware. Surely the administrators will require some training, advanced training without a doubt. And let's not forget about development and testing time. This all should be done well before the point of implementation of a new messaging system (and let's not forget the administrator must continue to support the existing platform during all of this - can you say: "I need a v..a..c..a..t..i..o..n?" I'm tired just thinking about all of this!).
Of course there is one more option regarding administrators. It's the most dreadful question, but it needs to be considered. Do the current administrators get replaced with those who already know the incoming system? Current administrators will need training to some level if they are retained - that's an obvious cost as I've mentioned and that training is crucial to the success or failure of an endeavor of this nature if they are being retained.
Well, it's the big day. All of the communications have gone out and all of the meetings have taken place. What's the plan for tying everything together to fit into one nice, neat package where end users and applications are not impacted? In companies where e-mail systems have become mission critical and are leveraged by different divisions and applications is a logistical nightmare. Sure, there are nice gateways that can be leveraged by different vendors to ease the migration, but in reality, that's a lot of traffic into a new system in a small amount of time. That being said, migration-type gateways are generally not supplied by the current e-mail system vendor. They are supplied by the vendor of the e-mail system being changed to, so how much support will the new e-mail system vendor actually have for getting things working in such an environment? There could be some significant issues during that process. What's the contingency plan or "back-out method" if things go less than perfect? Allow me to reiterate again, Internet e-mail can be the "life-blood" for a company. No Internet e-mail can be lost, whether it's sent to either the old system or the new one - who's willing to put a guarantee on that?
Backend functionality, stability and upgrades:
Here's some interesting information regarding the top three e-mail vendors. I'll start with some simple backend functionality like: how do these systems handle a single message being sent to numerous users, all utilizing the same e-mail server? Exchange and GroupWise use the same backend methodology when dealing with multiple messages. One message sent to numerous people utilizing the same server, contains only one item that all users get pointers to. This is not a feature of Lotus Notes. Notes handles this traffic "SMTP-like"; one message per user. Obviously this can tie up a lot of storage space, but disk space isn't all that expensive. It's just something that goes against the bottom line in the accounting office in relation to this conversion (which you'll see near the end of this article).
Now here's one that I've heard at a conference or two and I can't help but think - who's the technical staff? "Well, my boss wants to switch because "brand x" is supposed to be really stable." As far as stability goes, I don't think that any of the players claim to provide specific up-times, at least I haven't found anything worth passing on during my research. I would have to say that Notes seems to have the "built-in-benefit" when it comes to stability, as it does database replication to multiple servers (if you've got them) and the end users are not impacted if a server or database goes up in smoke. Keep in mind, this says nothing about network infrastructure. As for Exchange and GroupWise; both require some type of software and hardware clustering components to handle an outage at the server level.
Something else that shouldn't be overlooked is system upgrades and patches. Upgrades are always a wonderful thing for administrators. I can think of many things that I would rather do on a Saturday afternoon, than apply a patch to all of my servers to resolve a bug, defect, or problem piece of code. There are no big surprises here when it comes to each vendor - they all have problems. Although, from what I've seen, Exchange service pack/version upgrades are somewhat involved as different versions don't seem to interact well with each other. For example, .NET (Windows 2003 server recently renamed by Microsoft) will not allow an earlier version of Exchange to be run on it. That would be similar to saying GroupWise 5x will only run on a NetWare 4x server but if you upgrade to NetWare 5, it's required to upgrade your GroupWise system to GroupWise 6x. (Things do get more complex from that point with a mixed environment allowing the use of .NET domain controllers. But still, if you're running an earlier version it requires a "hot fix" (in Novell terms - FTF) to keep things moving and you still don't get full functionality). Have we seen anything like this with GroupWise? Sort of–what I'm referring to is newer versions of GroupWise cannot access older versions of the same product line.
Each vendor seems to stay away from off publishing "official benchmarks". My interpretation is that no one wants to be proven wrong or draw a line that can be easily used against them by a competitor, if that competitor can achieve even 1% better statistics. Consequently, there's not a whole lot that can be said here– but I'll cover what can be said.
Performance can be measured in many ways. The two most obvious points of measurement (whether useful or not) are; "end-user perception" and server statistics. When talking about these two topics, end-user perception has to be "thrown out of the mix" due to the number of potential pitfalls and general networking specific related to individual environments - aside from personal interpretation of what "slow" actually means. And for vendor comparison sake; Notes being Notes, it really can't be in the same competition here because it's not just e-mail; it's a web server, document management, application development platform and a few other things and by the way; it also does do some messaging tasks that Exchange and GroupWise do. Notes is a little less functional when it comes to the messaging side. For example; in Notes, the option for message retraction (what I like to refer to as "the job saver") is not a function. Rather, it's considered an invasion of privacy to pull back an e-mail from someone else's account. Regardless, overall it works for collaboration in the messaging arena but I'm not going to get into performance in regards to Notes - as it is a dicey topic as you can see.
So, let's talk about Exchange (I'm assuming because you're reading this on GroupWise Cool Solutions you've already got a good understanding of what GroupWise can do, so I shouldn't have to document it). Exchange is generally an SMTP/POP3 and IMAP reliant application. It was built on core protocols (industry standard) that are basic or easy to understand. By using these core protocols with a combination of some pretty slick end-user functionality, Exchange has become almost a standard for e-mail clients where POP3/SMTP are used. It's an undisputed reality that Microsoft has the money to research and develop an intuitive client application. Combining this with it being pre-installed on its workstation operating systems, there is a potential for a tremendous amount of feedback from the user community, to be used for improvements in later releases. All of this functionality must connect to something on the back-end or the usefulness would be purely "point in time" (based on POP3/SMTP protocols). The Exchange backend has some far reaching limits when it comes to databases. I have not found any information related to anyone who has hit the database limit, which can be in the terabytes.
The other side of the Exchange backend (similar to GroupWise) is a dependency on the directory - Microsoft's version of NDS is called Active Directory (AD). This directory has similar correlations to the NDS structure, but there are some key differences in replication and partitioning. I won't get into more detail on the directory differences, as both GroupWise and Exchange require the directory - it's a simple fact that provides a good reference point for this article. What should be understood is that in order to run Windows 2000 server, you will need Active Directory implemented. There are cases where both Active Directory and NDS infrastructure are running together for migration or permanent solutions. If this is to be considered, you'll need something to talk to both directories (there are products out there). (NOTE: Notes does not require a directory in the sense of NDS or AD).
Another important item worth noting when dealing with Exchange, is that it is a product which also relies heavily on DNS. Exchange uses the Windows 2000 site and subnet structure in relation to Domain Controllers (in Novell terms - NDS replica servers and/or DNS/DHCP Servers/services). What this means is that within the proximity of the client access points, it is recommended to have DNS services available to the clients. It is also recommended to be running on the backend servers (which does not pose any significant issues in relation to the Exchange server itself).
Well, lets "pop the hood" and talk about performance. Exchange is considered to be a linear application when discussing processor performance. What this means is that if you increase the processor speed by 50% you should expect to see a 50% gain on the server - sounds pretty basic; right? Keep in mind all of this traffic is SMTP/POP3.
So how many users can be on one Mailbox server? Of course, just with GroupWise and Notes, there is no hard and fast rule here. That being said, a mailbox server designed to support over 100 mailboxes is recommended to have dual Pentium III processors, 2 GB RAM, 72GB of disk for databases, 9 GB for logs (depending on your log file retention requirements this can vary) and 18 GB for the OS.
Client Interface and back-end security:
Notes, Exchange and GroupWise all have a lot of similarities. Here's a brief list (in no specific order):
- Personal Address Book Feature
- Spell Checking Functionality
- Group Creation in address books and system administration
- Converting e-mail to memos, tasks, etc
- SSL capabilities (although in each this is relatively complex to implement)
- IMAP4, LDAP, SMTP/POP3 and NNTP
- Searches capabilities for items within the account
- Reply to sender and reply to all
- Remote access client options
- Web Client functionality
- Ability to launch URL (web page) from mailbox item
- Attachments can be used (attaching and viewing capabilities)
- Utilizing a universal inbox for all mail items
- Sending mail from other applications (MSWord, WordPerfect, etc.)
- Delivery options (priority, include message, CC, BC, To, Subject, etc.)
- Archive feature
- Rules creation
- Proxy (or similar feature)
Notes - Client Interface and back-end security:
I'm going to go through Notes in a little bit more detail because there is a lot that is needed to be understood at the client level and how the system is designed. Notes uses proprietary database authentication, standard protocols, and is encrypted natively. The standard protocols basically make Notes what is called a "send mail system" (GroupWise is considered "store-and-forward"), what this means is there is a reliance on the recipient to manage messages, rather than databases or servers. As mentioned earlier, Notes does more than just messaging. The databases on the Notes servers contain documents, which are added and managed through relational tables. Notes has a complex set of rights that is distributed based on the user, which passes credentials to the server, which then provides access to the databases (this is somewhat like NDS). These rights can be broken down into various categories such as; managers, contributors, authors, editors, designers, readers, etc. Based on this architecture, users need to be added to each developed "application" in relation to rights, for specific access types.
There is still something else that is noteworthy, which is much different than GroupWise relating to end-user access. The Notes system requires a "profile" to be stored on the local workstation. This local profile consists of the desktop.dsk (this is information regarding client settings - font preferences, colors, etc.). This file can become as large as 300MB, and needs to be managed by the user. The local address book (names.nsf) and configuration information is also located on the local workstation. This file is generally somewhat smaller. In the Notes system it is recommended to users that they keep a backup copy of their own profile. This also means that users cannot move from one PC to another without bringing down the profile or creating a new one. Notes administrators also keep copies of these files in case of a disaster.
The final item with Notes is that there is not a Frequent Contacts address book that is automatically kept. The functionality is present, but it must be managed by the end user. For example: when a mail item is received from a new recipient, the address can be manually added to the address book.
Some of the items that I think are a benefit to Notes are things like; the client interface seems to have easier or more intuitive calendar functionality (comparable to Exchange). The client is deployed with pre-built rules (such as out of the office). In addition to the pre-built rules, administrators can build rules and roll them out to all users through the use of a System Agent. And finally, Notes has an "All Documents View" that shows all items within your account, for quick manual searching. To those familiar with GroupWise, this is the equivalent to the CNTRL +F or Find option.
I can also speak personally about my involvement with Notes in relation to the system that I support. The company that I work for has acquired two companies in the past two years that were both running Lotus Notes. What I've seen and heard from the technicians that were administrating these systems is that the Notes product is more suited for developing applications that integrate with e-mail. The conversations center around the fact that for the longest time Notes was the only product on the market that could do this, so many people used it for that reason - not just its e-mail capabilities. When considering or comparing these capabilities with GroupWise, it's definitely worth mentioning that Advansys has bridged that gap. For a few dollars more on top of your GroupWise license, Advansys can give you a lot of flexibility when it comes to the GroupWise client and integrating with other back-end applications (SQL, Etc.).
Exchange- Client Interface and back-end security:
Exchange uses a proprietary database authentication, standard protocols (STMP/POP3). By nature these protocols are not encrypted within the Exchange environment. This is important to understand if you feel that you need security within your internal network environment. Additionally, Exchange is a "send mail system" as mentioned earlier, this means the application is reliant on the recipient to manage messages, rather than databases or servers. Also it's important for me to reiterate that the success of an Exchange implementation hinges upon the DNS and AD deployment. An improperly deployed "base solution" of these products can cause significant problems with the Exchange implementation. The significance of this can't be overstated; in some cases the Exchange implementation can actually dictate the Windows 2000 system design.
Something else that is different with Exchange is the administration tools themselves. They run in a GUI front-end, which is adequately responsive. These operations provide an easy way to handle rights and the Administration required by the Exchange environment. Through these administrative tools, pathways for mail need to be defined which are called "routing groups". A routing group serves the same function as the Link Configuration tool in GroupWise, but a specific group must be created and named to allow SMTP traffic to "pass-thru" to other points in the system. These groups are also given a weighting system to notify the system which route is best (much like MX weighting in DNS or costing on a router). This is generally designed to follow the best-known network links, and backup groups are recommended to route traffic during an outage. This configuration can become somewhat complex to someone unfamiliar with these basics, so plan carefully. A successful implementation, along with the intuitive client, provide something that end users can easily get comfortable with. It's up to you as an administrator to determine if this is an appropriate fit within your organization.
GroupWise - Client Interface and back-end security:
In speaking about GroupWise, I don't think that there is a lot of need to explain what GroupWise does and how it functions, as I'm sure you're familiar with it. I would like to point out that similar to Notes, GroupWise also uses proprietary database authentication, standard protocols (recommended IP only configurations) and is by nature encrypted within the GroupWise environment. The rest I'm going to assume that you know and have personal experience with.
Overall, each system appears to have some nice features, as well as potential pitfalls. So considering a change seems like a questionable option (to me). My reasoning behind this is quite simple; as we're all aware, e-mail has become a core service that everybody takes for granted just like a dial-tone on a phone. Recently e-mail has taken on an important, mission-critical role in government and industry (even more so since 9/11). Decisions to change, convert or other such options should be made with great caution as these types of changes always come with some downtime (even if it is planned). Failures during these changes can potentially impede business and cause customer impact.
In general, when choosing an e-mail system, one of the most important items that you should keep in mind is whether the system that you have selected has a good track record of uptime and is generally immune to viruses or malicious attacks, along with providing features that your company requires. Sure end-user functionality is important, but that functionality won't be there during database damage, data loss or impact from code problems; so it's important that the solution is strong and implemented properly.
I guess the biggest question when considering changing e-mail systems is where does the Return On Investment (ROI) come into play when changing systems. If moving from GroupWise to another e-mail platform is being considered, it's probably a good idea to review Total Cost of Ownership (TCO) within each proposed system. I prefer to compute TCO at the hardware level as it is relatively easy and can be used with each system. Take the total cost of all of your servers related to mail (assuming you have servers dedicated to mail) and divide that cost by the number of users that are maintained on the system. This gives you a cost per user ratio that can be used to compare each mail system based on vendor recommended hardware. This figure is not really all that complex to derive, but is gives enough information to compare systems with. Sure, there are other factors that can be added to this computation such as; downtime, network usage or messages per user, but those cannot be determined from a system that you are unfamiliar with or have no experience with - as you can see it's just not possible.
Regardless of what platform you may be considering, it all comes back to the same question; what is the expected gain from a change? Again, that is all up to you and your company. Hopefully I have provided some facts and details that can be used when considering a change in enterprise e-mail just as they had for my friend.
Some of the reference materials used to write this article can be found at:
Watch for more articles by Dave Muldoon, every couple of weeks, under the resources link on GroupWise Cool Solutions - http://www.novell.com/coolsolutions/gwmag/features/trenches/tr_how_dave_does_it_gw.html.