|< Day Day Up >|
Browsers that support the XML, XSL, DHTML, and HTTP-DAV protocols have the largest available OWA feature set. All Microsoft browsers since IE5 (including IE5 for UNIX) support these protocols, and you will probably have these browsers in place on many desktops purely because they are part of the operating system. Any desktop that runs Windows XP automatically has IE6, for example. Note that IE6 is required if you want to run OWA in some languages (Hebrew or Arabic, for example). Check with Microsoft to determine the latest status on language support if you are unsure whether you need IE6 in your own environment. There have been many security attacks against IE, and the best advice is to use the most up-to-date version and keep a close eye out for any updates that Microsoft releases.
If you do not use the latest version of IE, possibly because you have made a decision to use browser technology from another company (such as Opera or the Netscape browser), you will find that basic messaging and calendaring functionality work quite well on all downstream browsers. You do not have to replace every browser just to take advantage of the extra stability and performance delivered by OWA. Indeed, even downstream browsers benefit from some of the architectural changes that Microsoft
Over time, Microsoft has used different terms to describe the various types of browsers that OWA can support. The original terms were rich and reach, with rich meaning that the browser is capable of supporting the full OWA feature set. Reach indicates that the browser cannot support all of the OWA features for some reason, usually protocol support. If you look at the OWA logon screen that allows users to select the type of client they want to use, you see that Microsoft uses premium and basic to describe the client types. These terms reflect the way that ASPs price OWA connectivity to users, so they are reasonably logical. Note that the support of feature segmentation makes it easier for ASPs to differentiate service delivery, even if you connect with an advanced browser.
Figure 5.3: Outlook Web Access and IE6 (Exchange 2000).
While the words have changed, they mean the same thing. The concept of a reach browser means that even basic browsers can connect to Exchange to read and send messages, but you will only get limited functionality in browsers that cannot support extended protocols such as rich DHTML behaviors and XML-HTTP. Even relatively recent browsers such as IE4 fall into the reach category, because they do not support the extended protocol set. All current versions of Netscape Navigator fall into the same category. In one way, you can think of the feature set for the reach client as the
was the first "rich-level" browser, meaning that the browser is capable of processing many user interface operations without reference to the server. Figure 5.3 shows the kind of environment you can expect when you combine IE6 with OWA from Exchange 2000, while Figure 5.4
Figure 5.4: Outlook Web Access and IE6 (Exchange 2003).
The goal for OWA is to create a user interface that is as close as possible to the full-function Outlook client, and this is possible only with rich browsers. Each release builds on the last to move toward the goal, and Microsoft is very close to it with Exchange 2003, which boasts a more attractive and streamlined user interface. Aside from the new user interface, Microsoft learned from its experience with Exchange 2000 and tweaked
OWA makes use of IE "behaviors" to build part of the user interface. Behaviors are a way of making DHTML pages easier to build by separating the code that implements the user interface from the data. The separation of code and data makes HTML pages more manageable and the user interface more predictable. The code that defines behaviors is typically shipped in an .htc file. A number of .htc files used by OWA are located in the \exchsrvr\exchweb\controls directory. Examples include features such as "drop- menu" (which defines how to respond to the right mouse button when it is clicked by displaying a drop-down menu), and you can find the hierarchical tree control to display folders in a mailbox or public folder hierarchy in the same directory.
IE uses behaviors to extend the functionality of an HTML element by adding new attributes,
Because their main function is to display data
The set of features supported by rich browsers includes:
Point-and-click selection of objects from a scrollable list.
Drag and drop from one folder to another. Unlike Outlook, you cannot drag and drop files from the Windows Explorer to an OWA 2000 message to add an attachment to a message or drag a file and drop it into a folder to copy it to the folder, but you can with OWA 2003 after you install the S/MIME control. In addition, you cannot drag and drop an item from the Inbox to the Contacts folder and expect to create a new contact, since this functionality is not yet available.  Drag-and-drop support does include resizing calendar appointments to fit a time slot.
As with Outlook, OWA supports grouped views such as "
Sort folders by different attributes, such as date, author, subject, and so on.
View the first
Calendar and contact items can now be stored in other folders, including public folders. This offers some interesting possibilities for group calendars or group contact folders. Personal contacts are now used to validate email addresses.
A rich text editor is available to generate HTML content. However, unlike Outlook, you cannot call Word for Windows and use it to edit the content of messages.
Figure 5.5: Setting up a Blocked Senders list with OWA.
You can set server-side rules (but only when connected to an Exchange 2003 server).
OWA supports the server-side processing of junk mail, but it does not download messages and review content to detect spam in the same way as Outlook 2003 does. However, you cannot import or export the Blocked or Safe Sender lists as you can with Outlook. Exchange holds these lists as mailbox properties on the server. The maximum
OWA includes a
OWA supports the CTRL/K keystroke to resolve the
New message (or post for public folders): Ctrl+N
Reply to selected message: Ctrl+R
Reply all to selected message: Ctrl+Shift+R
Forward selected message: Ctrl+Shift+F
Mark selected messages as read: Ctrl+Q
Mark selected messages as unread: Ctrl+U
OWA supports spell checking from Exchange 2003 onward. This feature imposes a certain load on the server because OWA must upload the message text and check it on the server, but this is
In addition, if you run IE6 (SP2 or later) and connect to an Exchange 2003 server, data passed between the client and server can be compressed using the GZip compression algorithm.
If you run IE6 on Windows 2000 or Windows XP workstations, you can also create, read, and sign S/MIME encoded messages using a control that you have to download to the browser.  The control is specific to a PC, so you must download the control to every PC where you use OWA and plan to sign messages or encrypt messages. OWA signs and encrypts messages according to the S/MIME V3 standard, but it can also read S/ MIME V2 encrypted messages. Options to control whether OWA signs and/or encrypts messages by default are available along with the other OWA options, and you can opt to sign or encrypt a message on an individual basis in much the same way as with Outlook. However, OWA does support S/MIME encoded read receipts. Figure 5.6 illustrates some of the OWA encryption and signing features in action. The top screen shows a signed and encrypted message, which you can recognize by the presence of the padlock (encrypted) and rosette (signature) on the right-hand side. The bottom screen shows the GAL properties for one of the recipients, where we can see that AD holds a valid digital ID (certificate) for this user.
Figure 5.6: Signed and encrypted OWA email.
Before you can start using message encryption with OWA, you have to deploy a public-key infrastructure. You can use the Windows Certificate Server to issue certificates to users or use those issued by other certification authorities such as Verisign. In either case, you have to arrange for users to get the certificates and perform administrative operations such as key revocation through other tools, because OWA only makes use of certificates; it includes no functionality to control, manage, or
You may decide not to download the S/MIME control on the basis that you do not want to send or encrypt messages, but, in fact, the control also enables more sophisticated message handling. For example, after you load the control, you can:
Click on the attachment icon in the toolbar and attach files without going through the normal two-step attach and post dialog.
Drag and drop messages from one folder to another. However, if you drag a message to the calendar folder, OWA does not populate the necessary attributes to create a new appointment and you cannot see the item in the calendar views.
Drag and drop messages onto new messages.
Drag and drop files from Windows Explorer to a message to become an attachment. If you make a mistake, you can right-click on an attachment to remove it.
Use all of the fonts installed on a PC istead of the default five.
On the surface, you may find it hard to understand why OWA links the S/MIME control to additional message handling functionality, but it has to do with security. With the control added, OWA deems you to have a more secure browser, so it allows you to work with local files more easily and the PC can compose the message rather than dispatching
HKLM\System\CurrentControlSet\Services\MSExchange\OWA\ AlwaysSign HKLM\System\CurrentControlSet\Services\MSExchange\OWA\ AlwaysEncrypt
Set these DWORD values to 1 to force signing and encryption. The default is 0, which allows users to choose. It is unwise to force these settings unless you are sure that users have the S/MIME control installed and understand how to use digital signatures and message encryption. For example, they need to know that they can sign messages addressed to
It is great to know that IE supports all the protocols necessary to implement the full OWA feature set, but Microsoft cannot expect everyone to upgrade to the latest version of IE overnight. It is a nice dream, but it will not happen. Backward compatibility is necessary, yet the challenge exists to upgrade and improve the performance of reach browsers when they connect to Exchange without using any of the new protocols. OWA does this by reducing the amount of data downloaded from the server, cleaning up the script code in the ASP pages, simplifying the user interface to use a smaller number of frames, and taking advantage of the additional performance delivered by the new architecture.
Almost all of the basic messaging functionality available to rich browsers is available to reach browsers, but there are some major differences in the user interface. For example, OWA provides references to objects as hot links, so you have to select an item and then double-click it before activating the item. Rich browsers use the same point-and-click, scrollable, multi- select model used by Win32 clients. Figure 5.7 provides a good view of the user interface of a reach browser connected to Exchange 2003. A quick comparison with the rich interface shown in Figure 5.4 demonstrates the difference between the two interfaces. You can see the effect immediately, since the user interface is much flatter and the advanced features such as the reading pane are not available. In addition, extended features such as spell checking and S/MIME support are only available to rich browsers.
Figure 5.7: IE6 runs the reach interface (Exchange 2003).
However, the difference is only truly obvious when you attempt to use the reach interface after using the rich interface for a while. It is an unfair comparison, because there is no way that the reach interface can approach the usability of an interface that Microsoft has worked on for many years. Today's rich browser client is streamlined and attractive, whereas the reach client is
There are instances when you may want to opt selectively to use the reach interface-for example, when you connect across a slow link and want to check email quickly. The Exchange 2003 version of OWA allows you to use the reach client even if you have the latest version of IE installed. However, once you have
Sometimes, you may want to limit the
You can control OWA
The default value is 0, meaning that OWA decides if a browser can support the rich client. Set the value to 1 to force Exchange to offer down-level support only. You do not need to restart the Store or IIS to make the change effective, since it kicks in the
OWA spell checking works as an ISAPI extension
that links to the relevant language library found in the same folder. When a client requests Exchange to spell check a message, it uses a POST verb to send the text to the ISAPI extension. Exchange checks the text against its dictionaries and generates an XML document that contains all possible corrections. Exchange then sends the XML document down to the client, which displays the text and corrections to the user through the interface shown in Figure 5.8. After the user has selected whatever corrections he or she wants to accept, OWA makes the amended text into the message body. This mechanism is effective, but it limits you to checking the entire text of a message rather than being able to check selected areas. As with Outlook, users can select options to control how to perform spell checking (language, ignore uppercase words, ignore words with
Figure 5.8: OWA spell checking.
It is conceivable that spell checking could affect overall server performance, but only if the server is already experiencing performance problems and is literally "on the edge" and unable to accept any further load. If this happens, you can
Table 5.1 describes the available values.
The maximum size (in KB) of a document that an OWA client can send to Exchange for spell checking. If a user sends a larger document, Exchange returns an error.
The maximum number of errors that Exchange will generate in a document, after which spell checking ceases. If too many errors exist in a document, Exchange spell checks until it meets the limit set, then returns the document to the user and notes that it is only partially checked.
The maximum number of unique errors that Exchange will generate in a document, after which spell checking ceases. The same error can exist multiple times, in which case it counts against MaxSpellErrors. In this case, Exchange looks for unique errors and counts each instance once. After a document exceeds the limit, Exchange returns it to the user and notes that it is only partially checked.
DWORD value set to 1 if you want to prevent users from spell checking messages before sending. The default allows users to use this feature.
The maximum number of spell checking operations that Exchange will accept from OWA clients at one time. If the server exceeds this limit, OWA clients that subsequently attempt to check a document see a dialog saying that the spell check server is busy and they should try again later.
OWA clients use subscriptions to enable notifications for new mail and the calendar. When OWA initializes, it uses the SUBSCRIBE method to the URL for whatever folders the user has enabled reminders for (through OWA Options-see Figure 5.9). If you want email notifications, you take out a subscription for the Inbox folder, but if you want calendar notifications, a subscription is taken out for the Calendar folder.
Figure 5.9: OWA subscriptions.
The subscription specifies the type of reminder that the user wants. For example, a simplified form of the HTTP message sent to the server to enable new mail notification for my account is:
SUBSCRIBE/Exchange/TRedmond/Inbox HTTP/1.1 Notification-Type: pragma/<http://schemas.microsoft.com/ exchange/newmail> Host: Server-
The request asks for a subscription on the Inbox folder that
POLL /Exchange/TRedmond/Inbox Subscription-Id: 1099 Host: Server-name
The response is a stream of XML data that contains reminder information. New mail notifications are straightforward-a simple indication that new mail has arrived. Calendar notifications include information about the meetings or appointments and may include multiple reminders. OWA uses this data to show the user the calendar reminder dialog shown in Figure 5.9.
By default, OWA checks for new mail every 2 minutes and checks for new calendar reminders every 15 minutes. You can set different default intervals on the server by updating the system registry at the following key:
Change the values (in minutes) of NewMailNotificationInterval (new mail) and ReminderPollingInterval (calendar) to whatever settings you
Disabling the ability for users to instruct the browsers to remember their passwords
Enabling a session inactivity timer, so that users must reauthenticate
Causing the logout button to return users to the logon screen and disabling their ability to use the browser "back" button to return to their mailbox without reauthentication
Allowing users to select between the rich and reach client interfaces during the OWA logon procedure
Forcing an SSL connection-forms authentication only works on
Figure 5.10: Enabling forms- based authentication.
When you configure a system to be a front-end Exchange 2003 server, it means that you want IIS to take any incoming HTTP requests for Exchange and proxy them onward to the back-end server that
Enabling SSL on the front- and back-end Exchange 2003 servers that host the mailboxes you want to access through forms-based authentication
Using ESM to enable the feature for the Exchange virtual server (navigate through the Protocols node to select the HTTP Protocol, and then click on the properties of the Exchange virtual server, as shown in Figure 5.10)
Once again, Exchange has to make a number of changes to its Web application to make forms-based authentication work. It registers a new extension (OWAAUTH.DLL) to handle processing of user credentials, changes the default domain for the virtual directories to "\" to allow users to pass UPNs when they log on, enables the \exchweb\bin\auth virtual directory and sets its default document to be OWALOGON.ASP (Figure 5.11), and enables anonymous access to the directory.
Figure 5.11: OWALOGON.ASP properties.
Once everything is in place, processing works like this:
To access his or her Exchange mailbox, the user enters a URL pointing to the Exchange application on the front-end server-for example, https://front-end/exchange. Note that the filter only traps SSL requests.
The ISAPI filter intercepts the request and attempts to extract the user's logon credentials from a cookie that it looks for in the request.
The user has not yet provided any credentials, so the ISAPI filter forwards the request to the Exchange Web application.
Exchange will not allow the user to access a mailbox without credentials, so it responds with a "401" (unauthorized access to page) error. The ISAPI filter redirects the connection to display the OWA logon page to collect user credentials.
After the user enters his or her credentials, the logon page sends a POST request to the OWAAUTH extension, which creates an encrypted cookie and redirects processing back to the URL that the user originally entered. At this point, IIS needs to be able to interact with a domain controller to validate the credentials that the user entered, so if the front-end server is in a DMZ and the controller is behind a firewall, you need to
The ISAPI filter is now able to extract a cookie, so it attempts to decrypt its content using a set of symmetric keys that Exchange regularly generates. Exchange keeps the current key and the last two previous keys to ensure that we do not encounter a situation where keys become invalid because of a change in a time boundary. If the credentials exist, the ISAPI filter attaches them to the HTTP request and forwards the request to Exchange.
Exchange recognizes the credentials and grants access to the mailbox, and normal OWA processing begins.
To speed matters up, OWA prepopulates a hidden frame by downloading toolbars and other graphics as a user goes through the authentication process, so that it can display its user interface as quickly as possible after authentication occurs.
You can configure the session inactivity timer (in minutes), which controls how often Exchange generates the symmetric keys used to encrypt the cookie contents, by setting the DWORD registry value KeyInterval at:
The maximum value you can set is 1,440, or 24 hours. While you might put in a value such as 20 to
Implementing forms-based authentication secures OWA access for kiosk-style environments but has some problems in intranet access. For example, single sign-on no longer works. In addition, you configure ISAPI filters on a per-virtual server basis, so after you set things up to support forms-based authentication, the effect is to channel all HTTP traffic for the server through the filter and not just the traffic for Exchange.
Even when you use OWA with a rich browser, some features are still missing. Microsoft has been adding new features through service
With Exchange 2000, you cannot set server-side rules through OWA, although the server will
With Exchange 2003, you can use the rich OWA client to work with server-side rules (Figure 5.12) and process S/MIME messages, as well as use other features missing in Exchange 2000, such as auto-signatures, search folders, support for tasks, attachment blocking, and content filtering. Tasks, auto-signatures, and attachment blocking are now also available to reach clients. However, do not expect to recall a message, set up a new public folder or set permissions on a folder, or maintain distribution lists, because those options are still missing from the OWA user interface.
Figure 5.12: Working with rules in OWA 2003.
Providing some mechanism to allow working offline is possibly the hardest problem to crack, at least from a philosophical point of view. Remember that Microsoft designed OWA as a "stateless client," with no need to deposit or keep
Access to the GAL works well, but because OWA uses LDAP instead of MAPI and does not support address list views, the access is less smooth than in Outlook and you cannot browse the GAL to locate a recipient. This is not surprising, because LDAP is a search rather than a browse protocol, so it delivers the results of the searches you execute as discrete operations. MAPI incorporates the concept of cursor locations within a data set, allowing you to browse forward and back from any particular point in the GAL. In addition, OWA does not permit users to update the contents of distribution groups, so you have to pass on this work either to people who use Outlook or to administrators.
Given Microsoft's track record in adding new features with each release of OWA, some of the missing features should appear in the future, but don't hold your
New Exchange 2003 servers do not allow OWA users to change their passwords, but servers upgraded from Exchange 2000 do. The logic here is that system administrators had to perform several steps on Exchange 2000 servers before users could change their passwords, so it was
As with so many things in Exchange, a registry value controls how this feature works. The DWORD value is at the key:
The value is DisablePassword. The default value is 1, meaning that users cannot set passwords. To enable this feature, set the value to 0. The upgrade procedure maintains settings on Exchange 2000 servers during the upgrade to Exchange 2003.
 . IE5 is available on the Sun Solaris and HP-UX platforms. If you connect to Exchange 2000, you can use the rich OWA client, but Exchange 2003 restricts you to the reach client.
 . Some of the reasons why a file can't be dragged and dropped into a folder lie in the way that browsers deal with files. RFC 1836 specifies how a browser uploads files to a server for storages and the mechanism that OWA uses to transmit files to Exchange. Uploading in this manner is designed to be secure rather than support user interface features such as drag and drop and explains why drag-and-drop support in OWA 2003 is linked to the S/MIME control.
 . For example, SecureLogOff for OWA from MessageWare http://www.messageware.com/.
 . Two DLLs are downloaded: EXSMIME.DLL and MIMECTL.DLL.
 . exchweb/bin/spell/owaspell.dll.
|< Day Day Up >|