5.5 OWA administration

 < Day Day Up > 



From the sections we have just gone through, it is obvious that you can tweak the way OWA works through many registry settings. OWA administration is not as graphic an experience as running ESM to change settings for an Exchange server. Instead, we have to deal with a mixture of registry settings: ESM to view properties of the HTTP virtual server and the Exchange IIS applications, and IIS. The Exchange installation procedure adds a number of applications to support OWA to the IIS default Web site. These applications (Figure 5.15) are:

click to expand
Figure 5.15: Exchange IIS applications.

  • Exchange: The root used to enable browser access to user mailboxes. Exchange also maps the mailbox root to drive M: through ExIFS. On an Exchange 2000 server, you can expand this root with the IIS snap- in to see a list of mailboxes. You cannot use this route to gain access to mailbox contents because the IIS snap-in cannot provide the necessary credentials to authenticate itself to Exchange. Exchange 2003 blocks this route to mailboxes.

  • Exadmin: This root holds the ASP and other files required for Exchange administrative operations.

  • Public: The root for browser access to public folders. The root is mapped to the default Public Folder hierarchy within the organization and on an Exchange 2000 server, you can navigate the public folder hierarchy from this point. In ExIFS terms, this equates to M:\ organization name\Public Folders. Exchange 2003 servers do not reveal any details of public folders here.

  • Exchweb: The code for the Exchange application. You can change access controls on the files through this interface, but Microsoft does not intend this to be the way to develop or customize Web components for use with Exchange.

Exchange 2003 introduces new virtual roots for "OMA" and "Microsoft-Server-Active-Sync" as part of its Exchange Mobile Services initiative. These components used to be part of the Microsoft Mobile Information Server. During the installation process, SETUP registers the Exchange ISAPI application in the IIS metabase, the repository used by IIS to hold configuration data about applications. Properties of the application are also accessible through the ESM. However, because ESM reads its data from the configuration naming context in the AD, a potential gap clearly exists between the two sets of data.

click to expand
Figure 5.16: Viewing Exchange IIS application properties from ESM.

Best practice is always to perform management for the Exchange IIS components through the IIS administration program. This marks a subtle change for Exchange 2003, since Exchange 2000 is happy to change settings through ESM and have a component of the System Attendant process, called DS2MB. perform updates to the IIS metabase behind the scenes by replicating changes made to the AD into the IIS metabase.[8] Some updates are on a demand basis, but DS2MB updates the metabase every 15 minutes by synchronizing changes made to the Exchange configuration in the AD into the metabase. As you can see in Figure 5.16, the Exchange 2003 version of ESM now directs administrators to use the IIS administration program, because it is safer and more reliable to use the one program to perform all updates.

OWA is an IIS application, so you can apply some of the management techniques and tweaks used with other IIS applications to OWA. For example, the OWA application combines many small files that create the user interface on the browser. As with all Web applications, you have icons and other small images together with the behavior files, style sheets, and so on. Each PC maintains a local cache of Web files, and the browser checks the cache first before attempting to download a file from a server. The cache removes files based on the timeout setting defined for the application, or after the size of the files exceeds the space allocated to the cache, or if the user elects to delete the contents of the cache. In the case of OWA, the default timeout setting is one day, meaning that the browser will check a file in the cache and fetch a new copy if the cached version is older than one day. The advantage of a short timeout is that browsers always use up-to-date application files, which is clearly important for an application that does not use compiled code. However, too short a timeout forces the browser to generate extra network traffic to fetch new copies of files that probably have not been updated on the server. The trick is to look for a timeout that provides updated files reasonably quickly after a server update while reducing network traffic to an acceptable level. (See Figure 5.17.)

click to expand
Figure 5.17: Properties of the IIS Exchange application.

Some administrators argued that the default one-day timeout for OWA files used by Exchange 2000 is too short because the application is unlikely to change between service packs. Apart from installing hot fixes, this assertion is true, and you can therefore consider extending the timeout to a more appropriate value. Microsoft changed the default timeout period to 30 days in Exchange 2003 and you can increase it further if you wish. Figure 5.18 shows a timeout of 60 days applied to the \img directory of the exchweb application (the \img directory holds all the images used by OWA). Sixty days is probably an excessively long timeout, but it serves to prove the point that you can apply standard IIS administration techniques to OWA, once you understand the impact of any of the changes you propose to make.

click to expand
Figure 5.18: Changing the content expiration timeout for OWA.

5.5.1 OWA scalability

A long time ago, Microsoft's original development goal for OWA was to support approximately 80 percent of an equivalent MAPI client workload on a server, so a server that is capable of supporting 2,000 active MAPI clients should support 1,600 OWA connections. This has proved to be the case, and, in fact, OWA continues to narrow the gap with MAPI. Exchange 2003 is better than Exchange 2000, and the trend of increased usability with better performance will continue for OWA. In terms of network, testing indicates that OWA requires more bandwidth than MAPI, but the net requirement varies from deployment to deployment. It all comes down to the characteristics of the workload generated by users. How many messages are sent and processed every day, calendar activity, and the size and complexity of messages (attachments, distribution lists, etc.) all influence bandwidth consumption.

Cost comes into the equation too. In the United States, where network costs are typically much cheaper than anywhere else in the world, it is often possible to justify upgrading network links to support OWA on the basis that the cost is offset by the reduced deployment expenses and the reduced number of calls the help desk can expect with OWA instead of Outlook. Elsewhere, the cost of bandwidth can be much higher, and designers seek to connect as many clients as possible across available links. The bottom line is that you need to do some testing to validate the right solution for your own situation. Use the published performance tests as a guideline, but always validate the results or, if you do not have the time or capability to run tests, add 50 percent to the results as a contingency (the "fudge factor") to ensure that you err on the side of caution.

Some people will worry that the URL namespace permits anyone to use OWA if he or she has a mailbox. You might not want this to happen, perhaps because you want people to use an IMAP client or a customized version of Outlook, or you think that OWA will use too much bandwidth on a saturated network link. As we have already seen, you could disable the virtual root for the Exchange ISAPI application, but this will disable all HTTP access to the Store. The best way to disable OWA access is by restricting access on a server or mailbox level by disabling the HTTP protocol.

Every user is different, so your mileage may vary according to workload and the nature of the messages that OWA processes. In particular, calendar manipulation tends to generate heavier system load than processing an Inbox. You can explain this by the fact that the calendar is composed of multiple appointments, all of which the browser must fetch from the server and then format for display in a daily, weekly, or monthly view. Users read messages on an individual basis, and even displaying a page of data from a folder usually only involves retrieving details of 15 to 20 messages. Daily views are the least demanding, because they tend to have only two or three appointments scheduled at most. Logically speaking, a monthly view is composed of a collection of daily views, so it is the most demanding view to build. My calendar for October 2002 contains 52 separate appointments. October was a busy month, because it featured sessions and events at two Exchange conferences (United States and Europe), but it serves to illustrate the point. If the user community (such as management teams) makes heavy use of calendars, you will support less concurrent connections than a user community (such as technical staff), which mainly sends messages.

Data about the number of client connections, the pages they fetched, and the browsers that are used can be retrieved from the IIS logs. It is possible to write a script to parse the data and format it into a report. The Exchange development team does this to ensure that they get the necessary coverage of browsers (Windows, UNIX, Macintosh, Microsoft, and non- Microsoft) during their testing.

click to expand
Figure 5.19: Adding a performance counter for OWA operations.

The IIS logs are stored in WINNT\System32\Logfiles\W3SVC1 with file names of "EX" followed by the date in YYMMDD format. For example, the log file for March 24, 2003, is EX030324.LOG. A typical session starts off with a client connection being recorded with the date and time, the login domain and account, the IP address of the client, and a series of GET commands as data is downloaded to the browser (any missing GIF files or other controls such as dropmenu.htc, which control the behavior of drop-down menus). When it has fully initialized the user interface, OWA then fetches data from the server to fill in folder contents. As the session proceeds, IIS logs the commands that OWA issues as it works with data. You'll see entries for SEARCH commands, where OWA is scanning through a folder; GET commands to download XSL data, where OWA is retrieving information to the browser (only for rich clients) before it is sorted locally; and PROPFIND to locate the properties of an object.

You can retrieve other valuable data by monitoring the performance counters for the "Exchange server HTTP Extension" object, which monitors the number and effect of commands such as PUT and GET, and the "Exchange Store Driver (IIS)" object, which monitors the interaction between browsers and the Store. The "MSExchange Web Mail" counter is also interesting, since it drives down into a level of detail such as:

  • The number of appointments being accepted and declined

  • Resolutions against free and busy information

  • Authentications

  • Folder operations

  • Message operations

As you can see in Figure 5.19, Microsoft has also provided separate instances to track statistics for rich and reach browsers, or the total from both browser families.

[8] . DS2MB runs in a service called MSExchangeMU, where "MU" means metabase update.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net