If you want large numbers of users -- from 500 and upwards of 1,000 or more -- to use OWA at the same time, then you need to have a plan to scale the setup as your organization grows.
Before you get to the hardware and software, you'll need to consider several factors, including who will use the system, when, from which venues and whether they will be using the system from inside or outside the firewall.
The net result of all this comes down to a simple fact: Scalability and availability are key planning considerations that you have to entertain. I also recommend that you test your setup with a test network that you can exercise to see if it's capable of accepting the amount of traffic that you want it to handle.
One tool you can use to test your setup is Microsoft's Exchange Stress and Performance (ESP), which comes as a part of the Exchange resource kit. It allows you to set up test scenarios to see how well your infrastructure will behave in different scenarios.
The first thing you need to do is determine what the level of participation is likely to be. In a chapter posted on its Web site, Microsoft discusses procedures for handling this chore, with details such as whom you should involve in the process and so forth. But it's clear that you cannot determine what the organization of your OWA infrastructure should be until you determine what the user population you'll be serving is.
Once that's done, though, it's time to think about how the infrastructure should be organized. Microsoft, in its discussion of planning, makes a good case for using the front-end,/back-end (FE/BE) organization, in which a number of front-end servers accept http requests to the Exchange server(s), and the back-end servers provide the Exchange functionality and the data storage necessary to accomplish that.
Using this design makes sense for a number of reasons:
- It spreads the processing load over several servers, allowing for one to fail without killing the entire function;
- It allows the front-end servers to balance the load among the back-end servers, if you also use network load balancing software;
- It means that you can add back-end servers to scale the operation relatively easily;
But there are also disadvantages that you should take into account. For example, introducing a front end/back end server organization will mean:
- More complexity in more servers in the enterprise;
- More complexity in the design and integration of the servers into the network;
- Additional firewall and security requirements.
Nevertheless, you should consider designing with the front end/back end architecture, because the benefits should outweigh the negatives in all but the smallest environments.
David Gabel has been testing and writing about computers for more than 25 years.
Do you have a useful Exchange tip to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.hang
