By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Exchange Server 2010 comes with a fair amount of self-testing functionality baked directly into the product. As with Exchange Server 2007, you can access them through cmdlets that have the prefix Test-. Here’s a look at a few basic test-centric cmdlets that you’ll want to run right after deploying Exchange Server 2010.
• Test-ServiceHealth: Determines if all the services that Exchange Server requires are up and running. This cmdlet also prints a report of the results.
• Test-SystemHealth: Performs several whole-system tests to determine if your server is configured according to best-practices guidelines.
• Test-ReplicationHealth: Determines if the mailbox servers in a given database availability group are replicating correctly with each other. You can also use Test-MRSHealth to check the health of the Mailbox Replication service.
• Test-WebServicesConnectivity: Checks that Exchange Web Services are functioning properly. Test-OwaConnectivity and Test-ActiveSyncConnectivity do the same thing for Outlook Web App and ActiveSync connectivity.
• Test-Mailflow: Checks whether or not mail can be sent to and from the system mailbox.
Keep a Well-Stocked Toolbox
So, what’s available to test your Exchange Server 2010 deployment outside of the box? Microsoft has published a variety of testing components for Exchange, and these tools are a good place to start.
One of the most widely used tools for testing Exchange Server deployments is the Exchange Load Generator (ELG), which is available in both 32- and 64-bit versions. This program simulates user activity on a given Exchange server. Since different users might generate different loads—because of the size of their mailboxes or other user-specific configurations—this is a good way to determine if a given user’s activity or a user group is causing a performance bottleneck.
However, the ELG has some major caveats. First, you need to have client management tools installed on the machine generating the load, not on the server itself, and you shouldn’t use it in a production network environment. Lastly, you should not run the ELG using your normal admin credentials for Exchange; use a reduced-privileges account as an additional security measure.
Microsoft recently revised the Exchange Load Generator tool and reissued it as Exchange Load Generator 2010. As the name implies, is the company specifically designed this version to test Exchange Server 2010 installations, so you can’t use it on older Exchange versions. If you have a heterogeneous environment (Exchange 2010 and earlier versions), you’ll need to obtain both versions of ELG and use the appropriate one where needed. ELG 2010 is currently labeled as a beta version, but the final version is not expected to change much.
The Exchange Server Stress and Performance (ESP) tool is also very useful. Although it sounds like a clone of the ELG, it has slightly different functions. The ESP tool simulates large numbers of client sessions and includes support for a wide variety of protocols that Exchange uses. You can run ESP from a single client, but it’s best to run it from multiple clients in different network segments for the most realistic testing results. The ELG is also available in both 32-bit and 64-bit versions. With this tool, however, you use the version that’s most suited to the client machine that you’re running on—not the server.
If you’re unsure about the I/O capacity of the desk hardware for the system on which you’re installing Exchange Server 2010, the Microsoft Exchange Server Jetstress tool can help. Jetstress simulates the type of I/O load that the Exchange database produces when multiple users access it. Currently, there are three versions—two for Exchange Server 2007 (32-bit and 64-bit) and a 64-bit beta version for Exchange Server 2010. The final version for Exchange 2010 will support earlier versions of Exchange as well.
A common test for Exchange Server is to determine if the system is accessible from the outside. Instead of running this assessment yourself, Microsoft can do some of the work using the Web-based Exchange Remote Connectivity Analyzer. This tool performs a variety of Exchange service tests from Microsoft servers to yours that include ActiveSync connectivity, Exchange Web Services, Office Outlook connectivity and inbound/outbound Internet email verification.
Load-Testing Exchange Server
In addition to testing Exchange Server’s functionality, you have to know whether or not a given Exchange server setup can withstand its intended operational load. Each third-party vendor has different views on how best to do this. Reading vendor white papers can help you parse out the tool that works best for your needs in varying situations.
Storage vendor EMC’s paper on Exchange Server 2010 performance validation and test results examines how its CLARiiON storage product can help server performance. It also contains some helpful advice and capacity-planning strategies, such as how to compute the amount of server resources you need to support a specific number of users as well as which is more important in your organization—I/O throughput or capacity. The dichotomy between those two variables isn’t always well-understood, but it’s a crucial part of putting together an Exchange Server installation; the more redundancy and disks you add to a system, the more throughput, but the cost is that much more disk space.
VMware’s paper on scaling Exchange Server 2007 with VMware virtualization focuses on how Exchange Server runs under VMware, instead of on bare metal. Although this is about Exchange 2007 and not Exchange 2010, it does emphasize the building-block approach to Exchange resources. It also looks at how this approach is easier to implement in a virtualized environment.