Few people would disagree that Outlook Web Access (OWA) lacks the functionality of the full-blown Outlook Messaging API (MAPI) client. Exchange 2000 Server's OWA version is certainly a tremendous improvement compared with Exchange Server 5.5's version, but OWA still lacks several key functions of a truly complete messaging client. One such function is the ability to spell check messages before or as users send them. Microsoft claims that it will provide this functionality in the next version of Exchange (code-named Titanium), but that product's release is still some time away. In the meantime, several third-party OWA spell-checking applications, such as AutoSpell's AutoSpell for Outlook Web Access and Messageware's Plus Pack for Outlook Web Access, are available. Although the products include various features (e.g., Plus Pack includes not only spell-checking functionality but also thesaurus functionality), they all work according to the same general principle. A concrete example, however, is much more descriptive than abstract theory, so an examination of AutoSpell's process provides a good overview of the way most third-party OWA spell-checking products work.
Installing the Spell Checker
Deploying the traditional Outlook client means installing hundreds of files on users' desktop systems. Although this task is challenging enough, especially when you don't use an automated deployment tool such as Microsoft Systems Management Server (SMS), your job becomes even more challenging when you must deploy hotfixes and service packs as well. One of the advantages of using OWA as a messaging client is its server-based functionality: Messaging systems administrators need install nothing on users' desktop systems because users access email through a standard Web browser and automatically download on demand any required local files. It comes as no surprise, then, that installing AutoSpell and most other available products is a purely server-based activity.
Because of Exchange 2000's enhanced OWA functionality, I concentrate on using a spell checker with that version, but AutoSpell and the other products support Exchange 5.5 as well. OWA implementation differs greatly across Exchange versions and service packs. For example, Exchange 5.5's OWA version consists of thousands of lines of Active Server Pages (ASP) code, whereas Exchange 2000's OWA works more directly through Microsoft Internet Information Services (IIS) 5.0, a much smaller collection of scripts, and the Web Storage System (WSS). Therefore, spell-checker configuration differs subtly according to each variant of the Exchange configuration.
During AutoSpell installation, the product's installation program prompts you to select the version of Exchange you're using, then makes the appropriate configuration changes. (I'd prefer the installation program to simply determine the version of Exchange that's on the server and save me from this needless intervention.)
The AutoSpell installation program implants the tool in the IIS virtual directory (typically C:\program files\exchsrv\exchweb) that contains the code on which OWA relies. The installation program prompts you to accept the default directory, but if your configuration isn't standard, you can explicitly define the correct path or let the installation program search for it. Following installation, the implantation manifests itself in two ways: The installation program creates an IIS virtual directory called spell within the specified directory and installs a collection of files into a corresponding NTFS folder.
During installation, you can choose to retain backup copies of any files that AutoSpell modifies or replaces. I strongly suggest that you accept this option. AutoSpell replaces and modifies core Exchange 2000 files that provide basic OWA functionality, so unless you retain backup copies, any subsequent uninstallation of AutoSpell won't include a rollback to base OWA functionality.
The installation includes some minor variations depending on the type of Exchange 2000 server configuration on which you install the spell checker. In a conventional setup, the product installs its entire complement of files on the Exchange server. One important file is a modified version of wmtemplates.dll. This file contains all the XML code that AutoSpell uses to display the Spelling button that the program inserts in the OWA browser. This file remains open whenever Exchange is running, so to load the modified file, you must reboot the Exchange server after you install the spell checker. In a front-end/back-end Exchange server environment, AutoSpell installs wmtemplates.dll only on the back-end server and installs all other files on the front-end servers, so you need to reboot only the back-end server. If you subsequently apply a service pack to your Exchange 2000 systems, you'll need to reinstall the spell-checker software on front-end and back-end servers because the service pack upgrade will likely modify wmtemplates.dll.
After you install AutoSpell on your Exchange 2000 server, you need to modify permissions slightly for the spell checker to function correctly. Open the Microsoft Management Console (MMC) Internet Services Manager snap-in, select the Default Web Site, then navigate to the exchweb subfolder. Open the spell folder's Properties dialog box, then modify the folder's permissions to allow the execution of scripts and executables.
How the Spell Checker Works
When a user clicks New in the OWA browser in an out-of-the-box OWA configuration, a blank message window appears and OWA performs several actions according to code in the composenote.htm file (in C:\program files\exchsrv\exchweb\controls). AutoSpell replaces that file with a modified version that contains an additional function, called SpellMessage. Clicking Spelling (which the product adds just above the message-composition window, as Figure 1 shows) executes the modified code, which calls a function in a different, private composenote.htm file (in C:\program files\exchsrv\exchweb\spell). This function opens the AutoSpell window and retrieves the subject line and message text of the message under construction. The private version of composenote.htm then posts the text to startspelling.asp—the AutoSpell window that Figure 2 shows—in which the real meat of the spell-checking activity takes place. Other spell-checking products work basically the same way.
The product uses the same process with appointments. AutoSpell replaces OWA's default composeappt.htm file with a customized version, which calls a private version of composeappt.htm in C:\program files\exchsrv\exchweb\spell. This routine retrieves and posts the subject and text of the appointment to startspelling.asp.
Using the Spell Checker
From a user's point of view, using the spell checker is straightforward: Click Spelling, and the program catches any spelling mistakes in the message text. As Figure 2 shows, AutoSpell offers the typical options: Users can accept a suggested change, ignore the error, or add the selected word to a custom dictionary. The most recent version of AutoSpell lets the user configure the program to check spelling automatically whenever the user clicks Send. This option brings the OWA spell checker's functionality more or less up to par with that of conventional Outlook client spell checking and is standard for most OWA spell-checking products.
An administrator can centrally control default spell-checking behavior and characteristics through the product's Configuration Utility, which you can access from the Start menu under Programs. In addition to controlling the types of situations in which the program will detect errors, as Figure 3 shows, you can select which dictionaries the program will use, as Figure 4 shows. AutoSpell comes with a standard English (U.S.) dictionary but includes support for other language-specific dictionaries that are available from the vendor, as is the case with most other products. You can also configure AutoSpell to use as the primary dictionary any existing standard dictionary (e.g., the Microsoft Office dictionary) that you use within your organization. (Note that you must ensure that any OWA clients that use such a dictionary are correctly licensed.)
AutoSpell supports custom dictionaries, too. As a user checks the spelling in a message, AutoSpell offers an Add option so that the user can add to his or her custom dictionary any words that the product doesn't recognize. This dictionary resides centrally on the Exchange server rather than on the user's client computer. By default, the custom dictionaries reside as *.dic files in the C:\program files\exchsrvr\custom directory. Within that directory, the product creates a subdirectory for each authenticated Windows domain, then uses the user's logon name as the dictionary's filename, as Figure 5 shows.
These custom dictionaries hold any custom words that the user adds, and any private spell-checking configuration settings that override the default systemwide settings (e.g., capitalization errors). In a front-end/back-end server environment, these files reside on the front-end servers, a setup that can be problematic when you have multiple front-end servers and can't be sure that users will always connect to the same one (e.g., when you use a load-balancing solution or round-robin DNS implementation). However, you can easily work around this problem. During AutoSpell installation, you can change the default location of the custom-dictionary files to a common shared drive, or you can use a file-replication utility such as Microsoft Dfs to ensure that the most recent file for each user replicates to the custom-dictionary tree on all front-end servers. Changing the default location is the preferred option; replicating files is less desirable because of latency and conflicts that could arise about which version of a file is the most recent. In large, globally distributed environments, however, replication might be the only option (a shared-drive concept doesn't work too well across continents).
Check Out Your Options
Several functional spell-checking products exist for use with OWA. A quick search for OWA spell checker on Google or any major Web search engine will yield plenty of results. My advice is to look carefully at the functionality and ease of use and administration of the available products according to your environment and specific circumstances. You'll then be able to select the most appropriate tool for your needs. Otherwise, you'll need to rely on your users' keen sense of spelling or wait until Titanium ships.
