Last week, I talked about the site-consolidation improvements in Exchange Server 2003 Service Pack 1 (SP1). Apropos of that, I wanted to mention that Microsoft has an upcoming Webcast covering site consolidation using SP1. The Webcast will discuss the new tools and processes available for performing cross-site mailbox moves, plus the other required cleanup steps described in the SP1 documentation. Keep an eye on the Microsoft Web site for more information.

This week, I want to tell you about a new tool that Microsoft released at the same time as Exchange 2003 SP1, but that has gotten surprisingly little attention: the Outlook Web Access (OWA) administration tool (OWAAdmin). This tool, which you can install on any Microsoft IIS server that runs version 1.1 of the Microsoft .NET Framework and ASP.NET, lets you remotely administer your OWA servers from anywhere in the organization. Although OWA offers quite a few features, the process of controlling OWA servers has always been a hassle because it depends on the creation of registry keys or values. Every Windows administrator knows how to do that, I know; the problem arises when you want to make configuration changes to multiple machines. Doing so manually is a bother and is even harder when you factor in common security settings that restrict or prevent remote registry access. You can always create your own Administrative Template file and attach it to a Group Policy Object (GPO), but only if you have the proper permissions in Active Directory (AD). Exchange administrators are often dependent on some other person or group to make directory changes.

OWAAdmin solves these problems by providing a nifty Web-based interface (which looks suspiciously like the Windows SharePoint Services interface) that you can use to view and change all the supported OWA 2003 settings, including some that you might not know existed and some that have been notoriously difficult up to now. For example, you can set the timeout period for distribution-group expansion when an OWA user sends an encrypted message to a distribution group, and you can change the number of minutes OWA uses to calculate the length of a work day or work week. Perhaps more usefully, you can easily modify the settings that affect segmentation and the default theme for OWA's appearance. (For more information about those settings, see the Exchange & Outlook Administrator article "Customizing OWA 2000 Access," June 2002, http://www.winnetmag.com/microsoftexchangeoutlook/article/articleid/24778/24778.html or the Windows & .NET Magazine Best Practices for Exchange article "Skinning Exchange 2003 OWA," January 2004, http://www.winnetmag.com/windows/article/articleid/41108/41108.html, respectively. )

Changing settings is a breeze. Install OWAAdmin, then visit https://machinename/owaadmin. If you have only one OWA server, you'll automatically be connected to it; if you have more than one server, you can use a drop-down menu to pick the one you want to work with. After you connect to the server, you can start making changes right away. But be careful--any changes you make are applied as soon as you click OK. The only exception is that changes you make to some subpages (e.g., the form-based authentication subpage) display a note that changes on that page won't take effect until the server is restarted (in most cases, bouncing the w3svc will do the trick).

As always with new tools, a few caveats apply. OWAAdmin requires special handling if you want to run it on a Windows 2000 domain controller (DC--see the Microsoft article "HOWTO: Promote a Member Server Running IIS to a Domain Controller Running IIS," at http://support.microsoft.com/?kbid=300432 , for more information). The tool requires Secure Sockets Layer (SSL), and it works only when installed on a machine that's in the same domain as the machines you're administering. The Installer doesn't check for any of these requirements, so if you have problems after installing the tool, check out those scenarios first.

The really intriguing thing about OWAAdmin is that it makes one wonder what a Web-based tool for administering Exchange itself might look like. Microsoft's competitors have been bragging about their Webcentric interfaces for a while. Even though Exchange System Manager (ESM) offers a good single-seat management solution already, I wonder whether the competition will drive Microsoft toward a Web-based interface for future releases of Exchange. We'll have to wait and see.