Exchange 2010 supports the ability to allocate different levels of functionality to OWA users through policies. Although Exchange 2010 includes a default OWA policy, it is not actually applied to mailboxes unless you explicitly select the mailbox and apply the policy to it. Otherwise access to OWA features is controlled by the segmentation properties defined for the OWA virtual directory on each CAS server.
OWA mailbox policies didn’t exist in Exchange 2007, and the only way that you could segment functionality was through the properties of the OWA Web site. The problem with this approach is that any change applies to all mailboxes that connect to that CAS. Using policies allows more granular control because you can apply different policies at the level of an individual mailbox. In addition to their ability to segment features presented through OWA, OWA mailbox policies control some of the user-controllable settings available through ECP.
The easiest way to apply any OWA policy, including the default policy, to a set of mailboxes is with the Set-CASMailbox cmdlet. For example, this command fetches all the
mailboxes that belong to the Exchange Users organizational unit (OU) and pipes them to Set-CASMailbox to apply the default OWA mailbox policy:
Get-Mailbox –OrganizationalUnit ‘Exchange Users’ | Set-CASMailbox -OwaMailboxPolicy ‘Default’
The default OWA policy typically duplicates the default out-of-the-box segmentation properties of the OWA default Web site as installed on a CAS server and permits access to all OWA features, including the premium client. To create a new policy, go to the Organization Configuration section of EMC, select Client Access, then on the Outlook Web App Mailbox Policies tab, and select the New Outlook Web App Mailbox Policy option in the action pane. A wizard then allows you to select which features you want users to access.
In this case, we create a policy to restrict access to the OWA Light version that also selectively disables some OWA features.
Some of policy restriction features depend on other components (text messaging, public folders, and instant messaging), and others require a really good reason before you disable them. For example, it usually doesn’t make much sense to disable the Change Password feature because handling user requests to change their passwords creates extra work for help desks.
A new policy can also be created with EMS. For whatever reason, this is a two-step process. First, you create the new policy with the New-OWAMailboxPolicy cmdlet, and then you use the Set-OWAMailboxPolicy cmdlet to define what features are enabled or disabled by the policy. For example, here’s a policy that allows users to use the premium client while removing some of the more esoteric features:
New-OWAMailboxPolicy -Name ‘Limited OWA features’
Set-OWAMailboxPolicy -Identity ‘Limited OWA features’
-ActiveSyncIntegrationEnabled $True -AllAddressListsEnabled $True
-CalendarEnabled $True -ContactsEnabled $True -JournalEnabled $True
-JunkEmailEnabled $True -RemindersAndNotificationsEnabled $True
-NotesEnabled $True -PremiumClientEnabled $True -SearchFoldersEnabled $False
-SignaturesEnabled $True -SpellCheckerEnabled $True -TasksEnabled $True
-ThemeSelectionEnabled $False -UMIntegrationEnabled $False
-ChangePasswordEnabled $True -RulesEnabled $True -PublicFoldersEnabled $False
-SMimeEnabled $True -RecoverDeletedItemsEnabled $True
-InstantMessagingEnabled $False -TextMessagingEnabled $False
More than just segmentation
Although feature segmentation is the most obvious use of OWA mailbox policies and receives the most attention, you can also control other aspects of how users work with
OWA through these policies. After you create a new OWA mailbox policy, you are able to define rules for file access and download when OWA is run on private and public computers. Click the policy with which you want to work and then select Properties. You can then access the properties that control feature segmentation and two other tabs for Public Computer File Access and Private Computer File Access.
The Direct File Access settings
allow you to control how various file types are opened by users through OWA. The default option for both public and private computers is to allow direct access, meaning that users are able to open files. However, all types of files are not treated equally, as there are some file types that pose a potential risk of infection because they are often used as threat vectors by hackers who wish to infiltrate a computer. Files are therefore grouped into four categories:
● Always Allow: These files are deemed to be innocuous and safe to open on the client computer. The list includes types such as Word documents (.doc and .docx extensions)
and Windows bitmaps (.bmp extension) that you can be reasonably sure will not contain malicious code.
● Always Block: These files pose a significant risk to a computer when they are opened by a user because they contain executable code. These files include types such as
Windows batch files (.bat extension) and Windows command files (.cmd extension).
● Force Save: These are files that users cannot open directly and must save to disk before they can access the content. These types include Windows compiled help files (.chm extension).
● All others (unknown files that are not included in the other lists): The policy states what should be done if an unknown file type is detected. The default is to force a save to disk.
The priority given to action is from top to bottom. In other words, if a file type is on both the Always Block and the Force Save lists, it will be blocked.
If you prefer to have users open a viewer to access files rather than running the native application, you can select the Force WebReady Document Viewing When A Converter Is Available option. The effect is to force OWA to check documents as they are opened to see whether a WebReady converter is available and, if so, to always use the converter to open the file rather than calling the application. The idea is to eliminate any potential risk from macros or other code that could be carried around in the common file formats supported by WebReady, such as Microsoft Word and Microsoft Excel. In truth, the antivirus software that runs on today’s PCs will usually catch any malicious code, so forcing WebReady viewing for OWA when it is run on a private computer could be considered overkill. Next image shows how to access the list of file formats supported by WebReady converters. This list has been augmented over the last few years and supports a reasonably full set of the most common file formats that users will need to open in office environments.
It might be safe to allow users to open documents with applications on private computers, but it’s a different matter on computers that are used for public access. In this scenario, it is reasonably common to block access to attachments to avoid the risk that users might download and leave sensitive files on a computer that can be accessed by an unauthorized individual. You can do this by clearing the option through EMC or by running the Set-OWAMailboxPolicy cmdlet. Settings applied through an OWA mailbox policy override those set through the properties of the OWA virtual directory. For example:
Set-OWAMailboxPolicy –id ‘Restricted Users – OWA Light’
-DirectFileAccessOnPublicComputersEnabled $False
-ForceWebReadyDocumentViewingFirstOnPublicComputers $True
When this policy is applied, users will not be able to open or download and save files on public computers, but they will be able to access the content if a WebReady viewer is available.
Web links that are included in messages are still active. Exchange 2010 includes viewers for Microsoft Office documents (next image), RTF, and PDF files.
Attachment processing
Administrators control how OWA handles attachments by creating a list of attachment types and marking each as blocked, allowed, or “force to save.” Obviously, blocked means that users cannot open or download an attachment of this type to their PC, normally because the file type is likely to contain a virus or some other dangerous content. Allowed means the opposite, as there is a high degree of confidence that these attachments are safe.
OWA performs special processing for attachments marked as force to save. This means that the user has to save the attachment to his local disk before he can view its contents. As OWA downloads the attachment from the server, it checks to see whether it is XML or HTML. In this case, OWA runs some code called Safe HTML to strip out any malicious XML or HTML code. If the attachment is another type, OWA examines the content to see if it actually contains XML or HTML code. This check is performed to ensure that no attachment is ever downloaded that contains malicious code, which could introduce a virus or another dangerous program onto the PC. If hidden XML or HTML code is detected, OWA strips the attachment and replaces it with a text file to tell the user that the attachment was removed.
Applying an OWA mailbox policy
After the new policy is created, to apply it, you switch to Recipient Configuration and select one or more mailboxes and then Properties from the action pane. Click the Mailbox Features tab, select Outlook Web App, and then select Properties. You can then select an Outlook Web App mailbox policy and apply it to the mailbox.
Exchange enforces the new policy the next time that the user logs into her mailbox. If everything works as expected, the user will be presented with a restricted version of OWA Light. Of course, you can also apply an OWA mailbox policy to a mailbox with EMS:
Set-CASMailbox –Identity ‘Andrews, Ben (IT)’ –OWAMailboxPolicy ‘Restricted Users–OWA Light’
Integrating OWA and OCS
One small glitch might creep in with the instant messaging section of the policy. OWA 2010 supports a nice integration with Office Communications Server (OCS), but if you want to create the link between the two products, you have to ensure that the OWA mailbox policy that is applied to mailboxes that want to use OCS specifies “OCS” in the InstantMessagingType attribute. For example:
Set-OWAMailboxPolicy –Identity ‘OCS Integration Enabled’ –InstantMessagingType ‘OCS’ –InstantMessagingEnabled $True
Set-CASMailbox –Identity ‘Akers, Kim’ –OWAMailboxPolicy ‘OCS Integration Enabled’
Filed under: Windows 2008
