My company has UNIX, Windows NT-based systems, mainframes, and NetWare-based systems. I need to define one standard for messaging both within and outside the organization. Which messaging protocol should I choose when I upgrade to Exchange 5.5?
Exchange Server 5.5 supports Internet Mail Access Protocol (IMAP), Messaging API (MAPI), and other important Internet protocol standards such as Post Office Protocol 3 (POP3), Simple Mail Transfer Protocol (SMTP), Network News Transfer Protocol (NNTP), Hypertext Transfer Protocol (HTTP), and full browser-based messaging and collaboration via Outlook Web Access. Because IMAP is becoming an Internet messaging standard and an eventual replacement for POP3, it will have a broad base of support from email application vendors on both the client and server for a variety of platforms and operating systems.
Currently, IMAP mail server products are available or in development for Windows NT, Windows 95, DOS, UNIX, Macintosh, NetWare, and OS/2. IMAP mail clients are available for NT Workstation, Win95, Windows 3.1, Windows/CE, DOS, UNIX, OS/2, and Macintosh. If you are considering POP3, consider IMAP. As the heir to POP3's Internet messaging throne, IMAP provides all of POP's features but adds many enhancements, such as remote folder manipulation, multiple folder support, and online performance optimization, in addition to support for other modes of operation (online and offline) discussed previously.
How can I reduce the downtime associated with restoring deleted items?
Before Exchange Server 5.5, administrators had to restore the entire database to recover deleted items such as mail messages. But Exchange Server 5.5 includes Deleted Item Recovery, which keeps deleted items hidden but available to users for a specified time. This feature lets users recover individual items without calling on the administrator and without requiring downtime to completely restore the database.
How can I back up a large data store to one device? My Exchange Server has a 500GB store. I have one 35/70GB DLT device that can hold up to 70GB (but usually less) per tape. At an average backup speed of 8MB per second (for Exchange Server 5.5), the 500GB data store takes about 17 hours to back up and spans four to seven tapes. Restoring can take several days. How can I have adequate disaster recovery within these constraints?
Exchange Server 5.5's virtually unlimited (16TB) increased store capability has created a dilemma for Exchange Server administrators and implementers. First, you must use technologies such as Microsoft Cluster Server (MSCS) for such a large backup. You need a marriage of technologies available from leading software and hardware vendors. Third-party software providers such as Computer Associates' Cheyenne Software, Seagate Software, Legato, and others provide backup products specifically for Exchange Server. These products have features that make backup and restoration of Exchange Server easier and faster. Hardware manufacturers make subsystems for backup, such as DLT arrays and libraries. You use software such as Cheyenne ARCserve to configure the DLT drives in a RAID array. This solution, combined with the ARCserve Exchange Backup Agent, can provide extremely high backup-and-restore throughput for Exchange Server.
For example, in some recent test results with Exchange Server 5.5, ARCserve performed well at about 27GB per hour using one 35/70GB DLT device. Testers added a second 35/70GB DLT device and configured a two-drive tape array (striped set) using Cheyenne's RAID option and achieved 38GB per hour. To back up a 500GB store within 8 hours, you need to achieve more than 60GB per hour. I have seen testers combine these software and hardware technologies (using the Cheyenne Image option) and achieve backup performance results better than 200GB per hour.
However, these technologies still might not address all the requirements of a complex messaging and collaboration environment. The complete solution will require new technologies such as fibre channel, which increases disk and tape device transfer speeds over greater distances. The process will also require improvements in tape and disk media.
My organization is going to deploy Exchange Server 5.5. How many users per server can my hardware support?
It depends. You must first look at your current messaging environment. If you don't have messaging, you'll have to make some educated guesses. Every messaging and collaborative application environment is unique.
If you want to know precise hardware requirements for your user population, you must do some capacity planning and simulations. Any capacity simulation exercise is only as good as the workload characterization. You can run benchmarks forever, but if your simulated workload doesn't match your users' workload, the exercise is virtually useless. Use tools from Microsoft (e.g., the StorStat utility from the Microsoft BackOffice Resource Kit) and third parties to analyze and characterize your messaging environment. If you are a current Exchange user, tools such as StorStat let you look at mailbox characteristics and help define your user profile. User surveys can be another valuable tool.
After you have successfully analyzed your users' workload profile, you can complete some capacity simulation exercises to test different server hardware configurations. Several tools are available. Microsoft offers LoadSim and Inetload. Other tools are Bluecurve's Dynameasure/ Messaging, netFUSION's NTSim, and the old reliable Rational Software's SQA LoadTest (previously Microsoft's MSTest). You need a tool that lets you customize the workload profile to match your user profile.
During capacity simulations with different hardware configurations, you want to gather performance data via NT's Performance Monitor (Perfmon) or another tool. You can use this data to analyze Exchange Server resource utilization and potential system bottlenecks to determine the optimal hardware configuration and user load for your deployment.
Table 1 offers some guidelines for choosing the right hardware platform for your user load for Exchange Server 5.5. Earlier Exchange versions accommodate substantially fewer users per server. The information in the table is based on a Microsoft LoadSim Medium MAPI user profile. LoadSim's user profiles represent the load various users place on Exchange Server in tasks such as reading and sending mail and running and loading attachments. The LoadSim Medium profile reflects users who depend on email in corporate communication and is a practical upper limit for estimating number of users. (For more information about LoadSim, see Greg Todd, "Understanding and Using LoadSim 5.0," parts 1 and 2, Windows NT Magazine, January and February 1998.)
Theoretically, an Exchange server can support many thousands of users. What is a practical limit for the number of users?
Even though a server platform theoretically can support extremely high user loads (e.g., 10,000 to 15,000 users), deploying that many users per server is not necessarily a good idea. Based on current limitations in backup and disaster-recovery technologies (5000 users at 50MB per mailbox means a store of more than 250GB), 5000 users per server is a good maximum. Most Exchange Server deployments I've seen deploy no more than 2500 users per server; typical deployments are around 500 to 1000 users per server.
Contact:Cheyenne * 800-243-9462
Email: [email protected]
Contact:Bluecurve * 800-824-7489
Email: [email protected]
Contact:netFUSION * 301-774-4111
Email: [email protected]
Contact:Rational Software * 800-728-1212
Email: [email protected]