Don’t assume—get the facts
Sizing an Exchange Server 2003 system when you're migrating or upgrading isn't a trivial task. Administrators often use sizing calculators (e.g., HP ProLiant Server Sizer for Microsoft Exchange Server 2003) and load-testing tools (e.g., Exchange Server Load Simulator—LoadSim—2003) when designing systems, but sometimes they guess or rely on assumptions when providing input for these tools. (For more information about these tools and their needed inputs, see the sidebar "Tools and Resources for Designing an Exchange 2003 System," page 6.) When I perform an assessment before designing a system, I'm amazed at the lack of good data or insight into answering the root question: How do people use the current Exchange system? To answer this question, you need to determine, at a minimum, the following information:
|
Exploring the Peaks and Valleys
Two important questions you need to answer before you size an Exchange system are how long is your users' typical workday? and what are their peak work hours? This information is important because you'll need to size your system so that the performance will be acceptable during peak demand. A typical workday for most users is 8 or 9 hours long, but many offices have some type of flexible scheduling, so not everyone starts their day at the same time. For example, some people might start their day at 6:00 a.m., whereas others might start at 9:00 a.m. Work-from-home trends have made flexible scheduling more the norm than the exception. A flexible schedule increases the overall length of the workday past the historical 8 hours of the 9-to-5 job.
Another factor to consider is users' distribution across time zones. If your organization has people spread across several time zones and you plan to use centralized servers, you need to account for this fact when determining the length of the workday. For example, if you have users in California and Washington, DC, the minimum workday is 11 to 12 hours long because of the 3-hour time-zone difference. When you factor in flexible work schedules, a more realistic number is having a workday that's 15 to 18 hours long.
Although knowing the length of the workday is important, it's more important to know when you can expect peak loads and how long the load periods last. Most administrators expect loads to be highest first thing in the morning and right after lunch. However, the loads really depend on how your organization does business. To determine the peaks and their durations, you need to monitor your system, which is easily accomplished by using the Windows Performance Monitor tool.
Performance Monitor has four Information Store (IS) counters that I find useful: User Count, Active User Count, Connection Count, and Active Connection Count. The User Count and Active User Count counters tell you the total number of connections on a per-logon basis. The Connection Count and Active Connection Count counters tell you the total number of connections to resources within the IS. The distinction of an active count is that it shows information about activities performed within the last 10 minutes of the sample. The difference between a connection count and a user count is that a single user can have multiple connections, so generally the connection count is higher than the user count because each user often makes several connections to the IS. For example, a user might have three connections—one to access his or her mailbox, one to access the public folder store, and one to access another user's calendar.
Email-enabled applications, such as Research In Motion's BlackBerry Enterprise Server, can also create connections. You need to consider the source of the connections because different sources can create different loads on the system. For example, at HP, we've found that each BlackBerry user creates the same load as 2.21 Outlook users. You need to consider this type of loading factor when calculating the number of users to put on a server.
Figure 1 shows a graph representing the actual system load results from a server in a site. I added the vertical bars so that you can correlate the user and connection counts to the time of day. This server's administrator had assumed that the load was heaviest early in the morning and at lunch time, but as you can see, users in this organization tend to establish connections when they arrive and don't close them until they leave for the day. The users also tend to be fairly consistent with the frequency in which they interact with the mail system throughout the day. For the day this sample was taken, the server hosted 750 users and the peak user count was 660. Samples from other days showed similar results. So, the administrator and I determined that approximately 80 percent of the user population is consistently online at the same time. This information is needed to help determine how many mailboxes a server can support.
When you use Performance Monitor, don't just take samples for a few days or on certain days. Make sure you sample over a long period of time, then aggregate the results. You might find, for example, that Mondays and Fridays have different results than other days of the week. Or you might find that there's higher utilization a certain week each month because of a recurring event. Don't forget to discount atypical periods, such as weeks that contain a holiday. Finally, don't assume every server is used the same throughout an organization. If you have many servers, those individual servers likely support individual business units. Sometimes business units work differently, and you might find that one set of servers sees steady usage, such as the server represented in Figure 1, whereas other servers have very jagged connection graphs with extreme peaks (high utilization) and valleys (low utilization). You should gather data from a large number of servers, if not all of them, to determine what server types and configurations you need. This information will help you determine, for example, whether you should deploy five or six high-end servers for centralized users and two midrange servers for field offices or deploy a series of identically configured midrange servers for all locations.
Do Users Love It or Leave It?
Do the people in your organization use the mail system all day long for a variety of tasks (e.g., communicating, scheduling), or do they hardly use the mail system at all? Most of the sizing tools ask you to determine the number or percentage of users who fall into the heavy-, medium-, and light-usage categories. These classifications help determine how many transaction logs you expect to generate per day, how fast you expect people to hit their mailbox quota, and how often you expect message transports to be used.
Classifying users and determining exactly how they use the mail system each day is difficult. You need to start by using an assessment tool to gather data to help you classify users. You also need to employ other tactics, such as focus groups and surveys, to gather the information.
One assessment tool you can use is StorStat, a Microsoft BackOffice Resource Kit (BORK) 4.5 utility that gathers information about mailbox usage. Although Microsoft initially designed StorStat for Exchange Server 5.5 upgrades, it's still useful today because it uses the Messaging API (MAPI) to access and evaluate items in a mailbox.
StorStat provides statistics such how many folders are in a mailbox, the average message size in the mailbox, and how many messages are sent and received per day. This information is good to have, but you need to be aware that the tool's results can be misleading. The results will be valid for only the items stored in the mailbox at the time the tool was run. For example, suppose you run the tool and it reports that a user's mailbox contains only a few messages and no attachments. You might assume that the user doesn't receive many messages and rarely receives attachments, but in reality, the person might frequently receive messages, some of which have extremely large attachments. The user just happens to immediately save all attachments on the local drive and regularly delete old messages. StorStat didn't measure the attachments and messages because they were no longer in the user's mailbox. For this reason, you need to conduct more in-depth investigations through focus groups and surveys.
Another limitation of StorStat is that, although it lets you summarize the results from a sampling of mailboxes, it provides only a summary of the entire sample set. It doesn't break down the results for further analysis. For example, StorStat provides the average number of messages sent per day over the sample, but it doesn't break down the number of messages sent by the number of people who sent them (e.g., 3 people sent 0 to 10 messages, 23 people sent 10 to 20 messages). I like to use StorStat for gathering general information, but for more detailed usage information, I use other means (e.g., focus groups, surveys) to get a realistic picture.
I've found that the number of messages sent and received, the size of those messages, and the number of messages sent with attachments are good starting metrics for determining how many users fall into the heavy-, medium-, and light-usage categories. As you capture this information, you can use MAPI Messaging Benchmark (MMB) 3—the benchmarking standard for measuring the performance and scalability of computers running Exchange 2003—to start assessing low-, medium-, and high-usage levels. MMB3 is designed to profile medium usage. For example, for the metric of the number of messages sent per day, 55 messages is considered medium usage, 41 messages (roughly 75 percent of medium) is considered light usage, and 69 messages (roughly 125 percent of medium) is considered heavy usage. You need to be aware that MMB3 is designed to compare hardware from different vendors, and the hardware configurations don't usually reflect real-world deployments. So, you should use the numbers only as a starting point.
After the information starts coming in, you might notice certain trends that are indicative of a certain usage category. For example, I've found that people in the heavy-usage category tend to send and receive a lot of mail and keep what they send and receive for a long time. They're involved in or schedule meetings frequently and usually have attachments saved with their appointments. They tend to create many folders to help organize what they keep.
Open It Again, Sam
Another metric considered important when categorizing users into usage levels is how often people open and reopen a message or attachment. If you're using a noncaching client such as Outlook 2000, each time someone reads a message or accesses an attachment, activity is incurred against the IS. When people frequently access items multiple times, they might be using the mail system as a file store. Although using the system for this purpose isn't necessarily bad (I store documents I occasionally need because I can access my mailbox from almost anywhere), it indicates heavy usage.
Repeat access creates heavier loads on the Exchange server. However, if you plan to deploy Microsoft Office Outlook 2003 as your primary client, repeat access isn't as much of a concern as it used to be. Outlook 2003 has a feature called cached mode that creates a complete copy of the mailbox on the local PC. When people read and reread messages, they're accessing the items from the local copy of the mailbox, which reduces the load on the server. If you're not planning to deploy Outlook 2003 or not planning to use cached mode, you need to determine the amount of repeat access so that you can better ascertain how many heavy users a server can support before it becomes overstressed. Unfortunately, gathering this type of information is difficult because you need to directly survey users.
Give Me More, More, More
The amount of storage a person uses can indicate his or her usage level. For example, I've found that people who use little storage space typically tend not to keep messages. They generally don't receive much mail and don't fall into the heavy-usage category.
In an Exchange 2003 or Exchange 2000 environment, you can use the Microsoft Management Console (MMC) Exchange System Manager (ESM) snap-in to determine how much storage space is being used. In an Exchange 5.5 environment, you can use Microsoft Exchange Administrator to make this determination. Both tools report the storage utilization in bytes for each mailbox. The tools also let you export data to a comma-separated value (CSV) file, which you can load into Microsoft Excel or Microsoft Access to analyze. Table 1 provides step-by-step instructions for how to use these tools.
In the past, ensuring that mailboxes had quotas was considered a best practice because you could control the growth of IS files. This practice encouraged people to manage their mailboxes and delete unnecessary items. In many cases, it also encouraged them to move items to personal folder store (PST) files.
Over the years, the cost of disk storage has dropped, Exchange has evolved to support multiple databases, and archiving and secondary-storage utilities have become commonplace. All these factors have created a push to increase mailbox quotas. If you're planning to increase quotas, you need to consider how it might affect not only the mail system but also other parts of the organization. For example, if you're planning to increase quotas because you're going to use Outlook 2003's cached mode, you need to plan on more space being used on PCs' local drives to mirror what's on the server. Depending on your hardware and backup strategy, your backups and restores might take longer and use more media.
Having larger quotas can be advantageous for both users and administrators. Users will likely be happy because they no longer have to save items to PST files, then later search multiple repositories for the data they need. Administrators will likely be happy as well because PST files can create headaches. When users move items to PST files, those files must be stored somewhere—usually on PCs' local drives or network file servers. Local PST files can be a nuisance when administrators need to re-image PCs to resolve a problem or upgrade hardware. If a user has several gigabytes of PST files, an administrator must locate, back up, and restore all those PST files. This task can take hours, and the risk of data loss increases. PST files on network file servers can create hassles, too. Because the PST files are individualized, administrators can't take advantage of single- instance storage. Consider these points as you discuss with users and management your strategy for storage in the new environment.
Get the Facts
Sizing and load-testing tools offer you a formulaic approach to determining your system configuration and server specifications, but you have to input accurate data into these tools. Fortunately, assessment tools such as Performance Monitor and StorStat can provide you with the data you need. However, you also have to supplement the gathered data with feedback from users and management. Having an understanding of how people use mail now, knowing what's possible, and understanding their expectations will help you create a good design. Start with the items I've discussed here and gather good data—don't just assume!
