Outlook Web Access Security Features (Part 5)

If you would like to read the other parts in this article series please go to:

Introduction

In the penultimate part of this five-part article series we looked at file and data access within OWA and then moved on to cover the WebReady Document Viewing feature. We will complete this article series on OWA 2007 security features by completing our look at the configuration areas of WebReady Document Viewing and then finally moving on to look at the use of web beacons.

Supported Document Types

In Figure 14 from Part Four of this article series, you saw the Public Computer File Access tab displayed. Clicking the Supported button on the Public Computer File Access tab reveals the screen shown in Figure 20 where you can configure the supported document types for WebReady Document Viewing. The original Release To Manufacturing (RTM) version of Exchange 2007 only supported a total of 5 document types but this was increased to 10 with Exchange 2007 Service Pack 1. Microsoft released Exchange 2007 Service Pack 2 in August 2009 and as far as I am aware, Exchange 2007 Service Pack 2 has not added support for any additional document types.


Figure 20: WebReady Document Viewing Supported Document Types

One configuration area in WebReady Document Viewing that can often be forgotten about is the default size limit for attachments opened with this method. By default, attachments greater than 5000KB cannot be opened and attempts to do so produces the error message “The document cannot be converted by the WebReady Document Viewing service because it is larger than the maximum size limit set by the administrator for your organization”. You can see this error in Figure 21.


Figure 21: WebReady Document Viewing Size Error

This limit of 5000KB is actually controlled via the MaxDocumentInputSize registry key entry on the Client Access Server. If this registry key is not set, the default limit of 5000KB still applies so if you wish to alter this value to match your organizational requirements you must create this key. The registry key information is as follows:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\WebReadyDocumentViewing

Name: MaxDocumentInputSize

Type: DWORD

Value: {value in KB}

However, simply setting this registry did not prove to be enough in my test setup as there is another registry key required. The MaxDocumentOutputSize registry key is also required which effectively controls the size of the resulting HTML file generated in the web browser window. These files are placed, by default, into the C:\Windows\Temp\XCCache folder. The MaxDocumentOutputSize registry key also has a default limit of 5000KB. Failure to set this key results in a different and slightly more confusing error message of “The document cannot be opened as a Web page. If the problem continues, contact technical support for your organization”. This is shown in Figure 22.


Figure 22: WebReady Document Viewing Error

The additional registry key that you need to create is as follows:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\WebReadyDocumentViewing

Name: MaxDocumentOutputSize

Type: DWORD

Value: {value in KB}

There are other additional registry keys that are available to control WebReady Document Viewing. There are keys available to control areas such as the number of rows to be displayed per page in Excel, the location of the XCCache folder, the location of the temp folder and so on. I suggest that you review the full list of registry settings here when planning your WebReady Document Viewing configuration. Don’t forget that these registry keys need to be applied to each Client Access Server in your organization that requires the new settings.

Web Beacons

Last and by no means least in this article series on OWA security features is the control of web beacons in email messages. Perhaps one of the most common forms of web beacon usage is when a junk email message contains images that can be downloaded to the local computer. These images are obtained from websites that can be used by the sender of the junk email message to confirm that the target email address that received the junk email is actually a valid email address. The act of verifying that an email address is valid generally serves to increase the amount of junk email that the recipient receives.

Fortunately OWA can detect the content that can be used for web beacons and this content is blocked by default which is obviously in line with Microsoft’s secure-by-default philosophy. You can see the result of web beacons being blocked in Figure 23. You will note that each image is blocked from being shown automatically and that at the top of the email message there is text that informs the user of two key pieces of information. First, the user is informed that some of the content has been blocked to help protect privacy. Second, the user is prompted to re-enable the blocked content if they are sure that they trust the sender of the message. Although this could be regarded as self-explanatory, it is still likely to be worth covering this feature with your users if they are using Outlook Web Access in Exchange 2007 for the first time.


Figure 23: Blocked Content In OWA 2007

To examine the configuration element that is used to control OWA when web beacons are encountered, it is possible to use the Get-OwaVirtualDirectory cmdlet and examine the value of the FilterWebBeaconsAndHtmlForms property as you can see in Figure 24.


Figure 24: Output of Get-OwaVirtualDirectory

In Figure 24, you can see that the default value of the FilterWebBeaconsAndHtmlForms property is set to UserFilterChoice, which as we’ve just discussed blocks web beacons by default but does allow the user to download any blocked content if desired. One of the other two options is ForceFilter, which, like UserFilterChoice, blocks content but this time the user cannot override this control. The last option is DisableFilter, which does not block any web beacons. It should be noted that it is not possible to use the Exchange Management Console to control the configuration of web beacons; like many or the more obscure settings in Exchange 2007, only the Exchange Management Shell can be used to alter the configuration.

Below you can see an example of an Exchange Management Shell cmdlet that is used to alter the web beacon configuration on the /owa virtual directory of the default web site. In this example, the default setting of UserFilterChoice is changed to ForceFilter, thereby fully blocking the web beacon content without user override control.

Set-OwaVirtualDirectory ‘owa (default web site)’ –FilterWebBeacons ForceFilter

To see what effect this has on the users, let us now return to the email first shown in Figure 23 above. In Figure 25 below you can see that the text at the top of the email has now changed to inform the user that the content has been blocked by default. Obviously, this cannot now be modified by the user.


Figure 25: Forced Blocked Content In OWA 2007

Summary

We have now completed all five parts of this article series on OWA security features and have covered a fair number of features. Even if you have already deployed Exchange 2007, you may not yet have taken advantage of some of these features or perhaps been aware of them. Hopefully, if you have read all five parts, you will have a much deeper understanding of the features available and will be able to consider how you might use them within your deployment.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top