If you would like to read the next part in this article series please go to Drilldown of the new OWA Direct File Access Feature in Exchange Server 2007: Part 2 (Client-side).
In this two part article series I’ll take you through the new OWA direct file access feature in Exchange Server 2007, a feature which allows users to access documents and document libraries on a centralized or personal SharePoint site or Windows data store (aka UNC file share) from within an OWA session.
Introduction
How many times have you or one of your users been on the move or attended a conference, and suddenly needed to access a document or some other file type located on an internal non-exposed SharePoint site or UNC file share on your corporate network, without having the option of establishing a VPN connection? I guess the answer is: Too many times! This is where the new OWA direct file access feature comes into the picture. Because with this feature you and/or your users can access documents as well as many other file types directly from within an OWA session. The Client Access Server (CAS), which is the server role that has replaced the front-end server we know from Exchange 2002/3, simply proxies the documents from the SharePoint or file share server on the user’s behalf, so that you don’t need to expose the stores on the Internet directly. Not only can they access these documents, but they can also send them to another person as an attachment, without ever downloading the file(s) to their local machine.
It’s important to understand the OWA direct file access feature only supports read access to documents, but nothing stops you from saving the document to disk for further editing.
In part one of this two part articles series, I’ll take you through the configuration options on the server-side, in part two I’ll show you how this feature works in the OWA 2007 client.
Note:
The OWA direct file access feature is only supported when using the OWA 2007 Premium client.
Configuring the OWA Direct File Access Feature
When installing Exchange Server 2007, the OWA direct file access feature is enabled by default, but if you enable forms-based authentication (FBA) on the respective OWA virtual directory, it only works when the user selects Private computer on the FBA logon page. If a user selects Public computer on the logon page, the OWA document access feature will be disabled, at least by default. If you, after installing the Exchange 2007 bits, want to change the default configuration settings, there are several knobs and features you can adjust on afterwards. In order to do so you need to open the Exchange Management Console, then navigate down to the Server Configuration node and select Client Access (see Figure 1).
Note:
Although the feature can be configured both from within the Exchange Management Console (EMC) as well as from the Exchange Management Shell (EMS), we’ll concentrate on the configuration options within the EMC in this article.
Figure 1: Client Access Server in the Exchange Management Console
Now select the server, on which the Client Access server role has been installed, in the Result Pane. Click the OWA (Default Web Site) virtual directory in the Result Pane then select Properties in the Action Pane (or simply right-click the vdir and select Properties in the context menu).
Note:
You can configure the OWA direct file access options per virtual directory, so if you for example, host multiple companies with each, with their OWA path configured, you can enable/disable OWA direct file access features per company.
Click the Private Computer File Access tab and you’ll see a screen similar to the one shown in Figure 2 below.
Figure 2: Private Computer File Access under the OWA (Default Web Site) Property Page
Here we can enable/disable the direct file access feature as well as customize it further. As expected the Direct File Access feature is enabled, now click the Customize button. This brings us to the screen shown in Figure 3.
Figure 3: Direct File Access Settings
When you have enabled the direct file access feature you can specify which types of files users can access without saving them first. You can do this by clicking the Allow button under Always Allow, which brings us to the screen in Figure 4 below.
Figure 4: Allowed File Types
As you can see you simply type the extension of the file type you want to allow, and enter the MIME types of the files that are allowed. Now click OK to exit the Allow list window.
Note:
The Allow list overrides the Block list and the Force Save list, so be wise when you add/remove file types from the Allow list.
The Block list and the Force Save list which also are accessed from the screen back in Figure 3 are identical to the Allow list, so I won’t show a screenshot of those here, just mention that the Block list, as the name implies, is used to specify any file types your users should not be allowed to access via OWA. The Force Save list is used to specify file types your users must save to disk before they can be opened. The last feature in Figure 3, which is called Unknown Files, is used to specify how unknown file types that haven’t been specified in the Allow list, Block list or Force Save list should be handled. You can select between Force Save, Allow and Block as shown in Figure 5.
Figure 5: Specify how Unknown File Types should be handled
Click OK to get back to the Private Computer File Access tab (Figure 2).
Besides the option of enabling/disabling the direct file access feature completely, there’s also a WebReady Document Viewing feature to be found here. When this feature is enabled, which is the case by default, the file types specified (see Figure 6) can be viewed in Internet Explorer, instead of opening the actual file type application such a Word, Excel, PowerPoint and PDF.
Figure 6: WebReady Document Viewing Settings
In part two of this article series, I’ll show you a Word file opened within Internet Explorer instead of Word using the WebReady Document Viewer feature.
As you can see in Figure 2, you can also force WebReady Document Viewing, before OWA tries to open the file in the respective application.
Note:
The WebReady Document Viewing feature is especially useful, if you’re for example accessing the OWA from an Internet Kiosk.
As can be seen back in Figure 2 there’s also the option of enabling/disabling access to either Windows File Share or Windows SharePoint Services under the Private Computer File Access tab.
Now click OK, then the Remote File Servers tab. As you can see in Figure 7 below, we also have the option of specifying the host names of servers from which the clients are allowed/denied access. Here it’s worth noting that the Block list takes precedence over the Allow list.
Figure 7: Remote File Servers tab under the OWA (Default Web Site) Property tab
In addition you can specify how to access files from remote file servers that are not in the Block list or Allow list, here you can choose between Allow and Block.
The very last configuration option there is to cover is related to which domain suffixes should be treated as internal Web Sites. This is done by clicking the Configure button and then entering the domain suffix for sites whose FQDN names should be treated as internal (see Figure 8).
Figure 8: Internal Domain Suffix List for sites whose FQDN name are treated as internal
You can now close the Property windows and exit the Exchange Management Console, as this was all there was to show you on the server-side.
In part two of this article series, I’ll show you how this OWA direct files access feature works in the OWA 2007 Premium client. Until then have a nice one!
If you would like to read the next part in this article series please go to Drilldown of the new OWA Direct File Access Feature in Exchange Server 2007: Part 2 (Client-side).
