Outlook Web App (OWA) in Exchange Server 2010 is the new name for Outlook Web Access, which has been around for 15 years, ever since Exchange Server 5.0. Since the release of the first version of Exchange Server with OWA, companies and administrators have maintained a desire to make OWA unique, even beyond the supported options. Company customization of OWA ranges from superficial color changes, to full branding, to radical interface changes. The ease of actually accomplishing OWA customization varies greatly, depending on the version of Exchange Server, the available customization tools, and administrators' skill sets. (See also, "OWA Customization in Exchange 2010" and "Bringing OWA to Your Desktop.")
OWA has come a long way from the basic Active Server Pages (ASP) application of Exchange 5.0 and 5.5. Microsoft Exchange Web Services, added in Exchange Server 2007, makes Exchange data accessible from a variety of sources following the Web services API. Exchange Server 2010 with Exchange Web Services has made it easier to develop custom web applications to access Exchange Server data. Exchange 2007 included four user-initiated themes in OWA. In Exchange Server 2010 RTM, OWA customization options weren't yet supported; the old Exchange 2007 theme content was still part of the installation, though not a functional one. It wasn't until Exchange Server 2010 Service Pack 1 (SP1) that Microsoft brought back support for OWA customization. (Exchange Server 2010 SP2, which is the current service pack as of this writing, doesn't add to the OWA customizations that we'll look at in this article.)
In this article, I'll discuss OWA segmentation, which is used to limit the components that users can access through the OWA interface, and customization of the OWA logon and logoff screens.
Microsoft Policy on Customizing OWA
For many of the OWA changes that we'll look at, you must replace existing files with your customized files. For themes, simple Cascading Style Sheets (CSS) changes, and logon- and logoff-screen changes, you're manipulating content at the file level. When Microsoft releases updates to Exchange Server -- whether bug fixes, rollup packages, or service packs -- the company offers no guarantee that your changes won't be overwritten. Nor does it guarantee that code changes in updates won't affect your customization efforts. Therefore, you should maintain a backup of any customization efforts and test Microsoft updates to ensure that your OWA customization still works after they're applied. Microsoft outlines its support policy for OWA customization, for all versions dating back to Exchange 5.5, in the article " Microsoft support policy for the customization of Outlook Web Access for Exchange." In addition, I recommend that you develop and test your customizations, whether comprehensive OWA custom applications or file-level image updates to reflect a branded logon screen, in a lab deployment before putting your work into production.
Segmentation
Segmentation is a fully supported method of customization for OWA. With segmentation, an administrator simply controls which components of OWA are visible to the end user. Many enterprises want their users to have access to the full range of functionality through the OWA client. However, some users might require only a limited set of features to complete their daily duties. For example, I recently worked at a manufacturing plant in which the plant workers needed access to email and contacts, but calendar, tasks, and public folder access was superfluous. Focused OWA access also helps to restrict users from exposing or being exposed to content that might otherwise be considered off limits or confidential. Limiting access to components deemed unnecessary by use or policy is good security practice as well, reducing the risk surface area. Segmentation can also reduce bandwidth use during OWA sessions.
OWA is available by default on any Exchange 2010 server with the Client Access server role installed. No additional configuration is needed to enable segmentation. As of Exchange 2007, segmentation has been readily managed through the Exchange Management Console (EMC). Segmentation is configured through the Client Access server in EMC.
In EMC, navigate to the Client Access server that hosts OWA, then right-click the OWA site and select Properties. The Segmentation tab, which Figure 1 shows, lists the user-level OWA components that can be toggled on and off for users of the Client Access server. (Table 1 lists all the available features.) Select and enable or disable individual features, one at a time.
Figure 1: EMC Segmentation Tab
Exchange Server 2010 introduces OWA mailbox policies. These policies allow administrators to apply segmentation selections to individual users or groups of users, rather than to everyone who connects to OWA on a specific Client Access server. Even though the feature includes "mailbox" in its name, these policies are technically not applied to mailboxes but rather to the web application that's used to access mailbox data. When the Client Access server role is installed, a default OWA mailbox policy is put in place. By default, all the listed, segmentable features are enabled in the default policy.
OWA mailbox policies are created in the EMC at the organization level, as reflected in Figure 2. Select Client Access under the Organization Configuration hub in the EMC; the OWA mailbox policies are listed in the middle pane. To add a new policy, right-click the open area in the middle pane and select New in the context menu, or select the same option directly in the EMC Actions pane. As Figure 2 also shows, the primary function of the OWA mailbox policy is to configure a specific segmentation setup for a user or group, because there's nothing else to configure in the UI. Consider giving the policy a descriptive name, such as the region or department to which it will apply, or including the specific segmentation goal in the name, such as "No Journal." Figure 3 shows the Outlook Web App Properties box, which allows you to apply an existing OWA mailbox policy to a mailbox or mailboxes. OWA mailbox policies can be created or amended by using the Exchange Management Shell (EMS) or the New-OWAMailboxPolicy and Set-OWAMailboxPolicy cmdlets.
Figure 2: OWA Mailbox Policies
Figure 3: Outlook Web App Properties
When you use these cmdlets to create a new OWA mailbox policy or edit an existing policy, you can toggle a list of attributes on or off. These attributes apply directly to the features that are listed in Table 1. The features are enabled by default, so in general, when configuring an OWA mailbox policy in EMS, you would call the attributes you want to toggle and set them to false to disable them. See the Microsoft articles "Set-OwaMailboxPolicy" and " New-OWAMailboxPolicy" or the cmdlet Help for the list of applicable attributes for each cmdlet.
Segmentation can also be configured by using the EMS at the server or user level. Use the Set-CASMailbox cmdlet to apply segmentation as defined in a specific OWA mailbox policy. For example, the following code applies the OWA mailbox policy called North America Staff to the mailbox-enabled user Steve:
Set-CASMailbox -Identity Steve -OwaMailboxPolicy:
"North America Staff"
If the OWA mailbox policy has spaces in its name, then quotation marks are required in EMS. To apply an OWA mailbox policy called Executives to all users belonging to the Active Directory (AD) organizational unit (OU) of the same name, use this code:
Get-CASMailbox -OrganizationalUnit Executives | Set-CASMailbox -OWAMailboxPolicy:Executives
You can also use EMS to retrieve the list of mailbox-enabled users to which you want to apply an OWA mailbox policy, based on common existing attributes (e.g., Title, Location). To do so, use Get-User and pipe output to the Set-CASMailbox command. You can also pull from a text file through EMS, by using the Get-Content command as follows:
Get-Content "c:\files\OWAPolicyList.txt" | Set-CasMailbox -OwaMailboxPolicy "North America Staff"
OWAPolicyList.txt is a plaintext file that lists the email address for the mailboxes, using one address per line, as follows:
[email protected] [email protected] [email protected] [email protected]
Of course, if you're administering Microsoft Office 365 for your company, you'll need to employ EMS to configure segmentation. The Exchange Control Panel (ECP) for Office 365 doesn't provide access to OWA policy administration.
Exchange 2010 SP2 brings back a previously deprecated version of web mail: OWA Mini, formerly known as Outlook Mobile Access (OMA) and last seen in Exchange Server 2003. This renewed OWA Mini functions as a set of forms within OWA. As part of OWA, OWA Mini (for mobile browsers) and OWA Basic (for untested browsers) also adhere to segmentation flags. Users who've been prevented access to basic folders, such as Calendar, can't access those folders through OWA Mini (shown in Figure 4) or OWA Basic.
Segmentation restricts and simplifies the OWA web interface for users. By default, OWA shows the primary Mail, Calendar, Contacts, and Tasks folders in the bottom left of the browser window. As a simple example, I take user Steve Bauer, who initially has no OWA mailbox policy applied and therefore has all available features enabled, and apply an OWA mailbox policy that disables calendar, task, and theme selection. Figures 5 and 6 show the differences in the interface before and after the application of this policy.
Figure 5: OWA Web Interface Before Policy Application
Figure 6: OWA Web Interface After Policy Application
Segmentation can also be applied at the server level, using the Set-VirtualDirectory cmdlet. Like the Set-OWAMailboxPolicy cmdlet, individual features can be toggled on or off. In this case, everyone who connects to a specific server and virtual directory, such as "owa (Default Web Site)," will see the same OWA features. If you're using some form of load balancing for OWA access across multiple Client Access servers, you need to ensure that segmentation configuration changes are applied to all the Client Access servers in your pool. Users might otherwise see different OWA configurations, depending on which Client Access server they connect to through load balancing.
Finally, note that when you create a new OWA mailbox policy or make segmentation changes at the server level, and you want to immediately apply the policy or changes to users, you might need to restart the OWA site. Restarting Microsoft IIS also forces OWA to pick up these changes immediately. This is best done at the command line on the server, using the following command:
iisreset -noforce Logon- and Logoff-Screen Customization
When users access the URL for OWA, the first screen is the logon screen (unless there's a certificate error, of course). In some companies, management might want to customize the logon or logoff screen to assert a brand or to assure users that they're in the correct place. A logon screen adorned with a familiar corporate logo and color scheme can give users confidence that they're on the correct site. Management might also customize the logon screen to incorporate specific information or legal disclaimers. Logon and logoff screens can be customized without affecting the core OWA.
The OWA logon and logoff screens are standalone web forms that use several .gif graphic files and CSS for fonts and formatting. For users who log on to OWA for the first time, there's an additional configuration screen, which is also affected by customization efforts because it shares the same image and CSS files as the logon screen. The initial logon screen is composed of nine .gif files, organized and placed according to logon.css. Other aspects of the logon screen are also rendered according to information in that CSS file, including font type and colors used outside of the .gif image files. These same files are incorporated into the first-time logon configuration screen and the logoff screen. If you're going to change these files, you need to update them only once; the updates will be reflected in all three pages. The default, installed versions of the logon, first-time logon configuration, and logoff screens are shown in Figures 7, 8, and 9.
Figure 7: Default Logon Screen
Figure 8: Default First Time Logon Screen
Figure 9: Default Logoff Screen
The files that are used for the logon and logoff screens are on the Exchange server with the Client Access server role, at \Program
Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\
As I mentioned earlier, you should work through your customizations in a lab environment if possible. Otherwise, consider taking a backup of the original files before you start making changes to OWA files. Thankfully, Microsoft has labeled the .gif files descriptively. Figure 10 shows the distribution of the .gif files in the logon screen; Table 2 lists the image filenames and their sizes (in pixels).
Figure 10: Distribution of GIF Files
The simplest way to customize the logon screen is twofold: Replace the .gif files with ones more befitting of your corporate designs and amend logon.css and owafont.css to complement those files. You certainly aren't limited to this superficial alteration, but it has the most impact with the least effort. The .gif file with the text "Outlook Web App," as seen in Figures 7, 8, and 9, is called lgntopl.gif (a filename standing for logon, top, left) and is the easiest file to work with when you just want to add your logo, without changing the default OWA color scheme. For this article, I took this .gif file and added a fictitious logo for Las Vegas Webmail, integrating the famous Las Vegas sign from the Las Vegas Strip in Nevada, as Figure 11 shows. I kept the .gif file at the set size of 456 ´ 115 pixels, so a straight file replacement on the Client Access server will return the new logo to users who log on to OWA on that Client Access server. If you use a different file size and don't make changes to the CSS file, then the formatting of the graphics will be incoherent. (The location on the page of each graphic is coded into the CSS file, based on pixel location, so if you change the sizes of the .gif files, you need to accommodate that change within the CSS file itself.) Clearly, if you want to make complete custom logon screens beyond manipulating the appearance of the existing graphics, you'll need some knowledge of CSS.
Figure 11: Customized OWA Logon Screen
The text style in the logon screen is also governed by instructions in logon.css. CSS files are simply text files and can be edited by using a text editor or one of the many CSS editors. But these days, all web development applications also handle CSS. Microsoft Expression Web is a great tool for working with CSS files; Microsoft Visual Studio can also serve as an advanced CSS editor, although using it just for that purpose is a bit of overkill. Colors in CSS are defined by hexadecimal color codes: the hash sign (#) followed by a 6-character code. Most CSS editors have color palettes with hex numbers incorporated. Quick resources are available online as well (e.g., VisiBone). Your marketing, graphics, or web-development people likely maintain exact print and web color codes that represent the color scheme for your corporate presence and logos.
Table 3 lists some of the colors that are identified in the logon.css file for the logon screen. For this example, I changed the font color within logon.css from orange to purple and changed the input field background for the username and password from light orange to light gray. I also made the border around the input fields stand out with a more solid blue rather than a thin gray, by changing the color code and incrementing the pixel thickness of the border. To accomplish these changes, I changed fff3c0 to cccccc, ff6c00 to 800080, and a4a4a4 to 000080 within logon.css. (Some intelligent guesswork was needed to determine exactly which elements in the CSS file to apply within the page.) After ensuring that I had a backup of logon.css, I saved the new file to \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\14.2.283.3\Themes\Resources on the Client Access server. I also copied my new lgntopl.gif to the same folder. Figure 12 shows the simple editing that I made to customize the OWA logon screen. Of course, you aren't limited to such simple customizations. With solid knowledge of CSS and graphics work, you can develop your own custom logon and logoff screens that will appear unrecognizable compared with the defaults that OWA renders.
Figure 12: Editing to Customize OWA Logon Screen
You might need users to delete their local browser cache for the customizations to be immediately apparent. (In my on-premises lab installation, I found it unnecessary to restart the website for the changes to be served to clients.) If you use certain proxy applications or perimeter hardware, there might also be a delay before users receive updated content.
Applying Customizations
OWA changes aren't replicated between Client Access servers. If multiple Exchange servers with the Client Access server role installed serve OWA, you'll need to apply any customizations to each of those servers if you want all users to see the same screens. Users will get the OWA screens that are specific to the Client Access server that they access with their browsers. This can work for you or against you. You might want different groups of users to have different OWA experiences, including branded environments.
If you don't want to work at the file level in Exchange Server to make changes to the logon or logoff screens, some third-party companies that specialize in branding offer this service for various customizable software solutions, including OWA 2010. Many make comprehensive changes to the OWA logon screens, to the point that the actual application is unrecognizable. An example of such a provider (with some screen shots of client solutions) is Techstur.com. If you use such a provider, you'll need to address any issues that might arise when new service packs or updates make changes to OWA.
