When I'm creating or reviewing a company's Exchange Server design, I try to make sure that the plan adheres to four key architectural principles: simplicity, integration, cost, and efficiency. Simplicity means ensuring that the design contains everything your business needs and nothing that it doesn't. Integration means finding a compromise between the enterprise view and the point view. Cost means that the design takes into consideration the total cost of ownership (TCO) over time. And efficiency means that the finished design will make your life easier. I've found 10 steps that are invaluable in creating a design that helps meet those four requirements. Here are the first four.
#1: Document the Business Expectations
Understanding and documenting your business's messaging requirements is the first task on your plate. Notice that I don't say deciding these requirements. That's because decisions such as mailbox size, retention, recovery, and maintenance windows are best made by the business units that comprise your company. This isn't to say that the IT department doesn't have a say in those decisions, but your primary role should be to explain your messaging technologies' advantages and disadvantages in a nonbiased manner so that the business leaders can make an informed decision. By doing so, you help increase the likelihood that your Exchange architecture will be well aligned with your company's overall business objectives. Consider mailbox-recovery time. Your company's business leaders might decide that one group of users requires an extremely fast recovery time, whereas other users can live with longer recovery times. Knowing this might affect your design and perhaps would lead you to install one mailbox-server configuration for the first set of users and another mailbox-server configuration for the remaining users (depending on their classification).
The key to success is to meet with the leaders of the lines of business within your company. Document their requirements, and ask for elaboration of the key principles. When creating a detailed Exchange design, I first list the business requirements, then reference those requirements throughout the design document. That way, I can give an immediate response to anyone who asks why I've designed a certain aspect of the organization in a certain way. I typically add my own comments, from a technical perspective, regarding the cost and effort necessary to implement each requirement. Doing so up front can help decision makers evaluate the practicality of requirements such as Email must be up 100 percent of the time, and recovery must be within 5 minutes. Framing your input within this type of business view is important when you're presenting a design project to executive management for sponsorship. Finally, circulate the requirements for feedback, approval, and sign-off.
#2: Document the Existing Infrastructure
How can you decide the best way to get to where you want to go unless you first know where you are? Designing a successful Exchange solution requires that you know your current messaging infrastructure. This advice might seem like simple common sense, but I'm continually surprised by how many companies lack any sort of formal documentation about their messaging organization. (A bunch of cool schematics made with colored markers on a white board in the Exchange administrator's cubicle doesn't count.)
Microsoft provides many free tools that can help with this task. Using a common application such as Microsoft Office Visio 2003 to document the logical, physical, and technical views of your current messaging environment is a step in the right direction. If your budget allows, an extensive array of third-party products can provide automated documentation. For the more budget-conscious, Microsoft offers free utilities such as the Exchange Server Topology Diagramming Tool (ExMap—http://www.microsoft.com/technet/prodtechnol/ exchange/downloads/2000/exmap.mspx), which can automatically generate a Visio diagram of your site topology; the ExchDump tool (exchdump.exe—http://tinyurl.com/2cp4o) provides both HTML and XML output files of every aspect of an Exchange server.
Another approach to documenting the technical performance of your Exchange server is to leverage Performance Monitor, then save the results to a file. To document the general health of the server, monitor the four main subsystems (i.e., CPU, Network, Memory, and Disk) that make up the server. Select all counters in each performance object. When capturing performance counters for general information, a good sample time is 4 hours during normal production hours, with a sample interval time of 15 to 30 seconds. To keep performance-file size small, select the Text File (Comma Delimited) option on the Log Files tab when scheduling or running Performance Monitor. (Text files are much smaller than binary file types and compress extremely well. In my experience, Performance Monitor produces very small comma-separated value—CSV—files of less than 10MB on average.) I suggest you use Task Scheduler to schedule regular Performance Monitor runs and archive those files to create a performance history log for each server. This information is a great resource when redesigning (or troubleshooting) your Exchange environment. If you want in-depth realtime information that's easy to read and browse, a product such as Quest Software's Quest MessageStats can provide a deeper level of real-time Exchange reporting.
Don't make the common mistake of involving only the Exchange administrator or group in this documentation process. Seek the input and review of your cohorts in other disciplines such as Active Directory (AD), network, DNS, firewall, and security—and don't forget the Help desk! You'd be amazed how many Exchange designs are born in a vacuum. This is also a good time to have your company's business units review their current service level agreements (SLAs); requirements can change, and the technical team is often the last to know.
#3: Run an AD Health Check
The next item to consider is your company's AD architecture. An Exchange Server 2003 or Exchange 2000 Server infrastructure requires AD for key items such as user authentication, administration of Exchange mailbox and mail-enabled objects, storage and replication of directory information, the Global Address List (GAL—including Distribution Groups— DGs), and storage of your Exchange configuration settings. If AD isn't healthy, your Exchange organization can grind to a halt.
Exchange makes heavy use of both AD domain controllers (DCs) and Global Catalog (GC) servers for such tasks as email address lookups and message routing. Often, AD is installed before Exchange is designed, primarily for account authentication and authorization rather than for supporting Exchange. Thus, AD might not be sized properly to support the additional demands of Exchange. Furthermore, different versions of Outlook have different AD requirements. Outlook versions earlier than Outlook 2000 receive GC information via the Exchange server, whereas newer versions are redirected directly to a GC server. Understanding how the various versions of Outlook in your infrastructure interact with AD will help you appropriately size and place Exchange and AD services. For example, if your environment is still using older versions of Outlook, consider installing the maximum amount of memory (i.e., 4GB) in your Exchange mailbox servers to provide plenty of memory for the increased demand that those Outlook versions impose. Communicate with the AD team and make sure they understand and approve any AD adjustments that will be necessary before you finalize your Exchange design.
#4: Size Up Your Hardware
Now, you're ready to take a look at your hardware. When it comes to configuring hardware for Exchange, the memory and disk subsystems are of primary importance.
As far as memory is concerned, you should plan to add the maximum amount of memory—4GB—to all your Exchange servers, if possible. Exchange 2003 and earlier are bound by a 4GB memory limit, and because memory is relatively cheap, installing the maximum amount allowable makes sense. The more memory Exchange has available, the better the server's performance; Exchange will be able to cache more directory information and thus reduce the load placed on DCs and GC servers. Memory is most important for Exchange servers that perform dedicated routing, such as Exchange front-end or bridgehead servers. Increased memory also improves performance for servers that handle Secure Sockets Layer (SSL) or proxy functions, such as Microsoft Outlook Web Access (OWA) servers. For Exchange back-end servers, additional memory lets functions such as DSAccess and store.exe run more efficiently.