Introduction
In the past the messaging administrator was able to manage Outlook Web Access (Outlook Web App name was introduced with Exchange Server 2010) by enabling or disabling settings at the Virtual Directory level by either Exchange Management Console or Exchange Management Shell. Nowadays with Exchange Server 2010 we can still do that but there is a better way to do it using Outlook Web App Mailbox Policy feature. In this article we are going to check this new feature and how we can combine the new feature with the old management method that we have been using since Exchange Server 2007.
Outlook Web App is a key piece of your Client Access infrastructure and it is always important to plan and make sure that all tasks are done properly in your environment. The first thing is to understand how your Client Access environment is set up and we know that each environment is unique but probably your environment will fit in one of these scenarios: a single Client Access Server, a farm of Client Access Servers behind a load balancer, Client Access Servers using Windows Network Load Balancing.
If you have a single server it’s all good as all changes will be done on that server while the changes will be available to all clients. However, if you are using any sort of Load Balancing the environment becomes more robust, resilient and tricky. In this kind of environment we must make sure that all settings are consistent. For example, if you disable the calendar feature using OWA Virtual Directory on just one server, the other one keeps the feature enabled. Probably, your users will notice that the Calendar option is showing up sometimes because the result is based on the server that they are connected to.
In this scenario we are talking about just one simple setting but let’s imagine if we went through several steps such as: OWA Segmentation, SSL Offload, Authentication, Private and Public file access and so forth, then my friends we would be in big trouble especially if we haven’t documented the changes. Bear that in mind when playing with Client Access Servers and make sure that everything that you do is consistent among all Client Access Servers of your scenario but don’t worry too much because Outlook Web App Mailbox Policy will help you out a lot at least on the segmentation, Private and Public file access areas.
Settings that are outside of Outlook Web App Mailbox Policy…
Before moving forward to segmentation and other settings covered by Outlook Web App Mailbox Policy, let’s go over the settings that should be defined at the Server level. These should be consistent among all your Client Access Servers.
Let’s open Exchange Management Console, Server Configuration, Client Access, and then click on the desired server on the right side (Result Panel), and double click on owa (Default Web Site) that will be displayed in the Work Panel (Figure 01).
These are the tabs that you must configure at the Server level: Authentication, Remote File Servers and General (this tab control redirection and proxy, so make sure that the settings fit your environment properly). After changing settings on that page make sure that you run an iisreset /noforce to force a refresh of the settings and we also need to repeat the process on each Client Access Server that belongs to the same site to avoid inconsistency that may affected end-users (for example, if authentication is different then it will generate a lot of help desk calls :)).
Figure 01
Managing Segmentation at Server Level…
Segmentation allows the messaging administrator to manage if a feature is displayed to the user during its Outlook Web App session. This setting can be configured at the server level. In order to enable or disable a feature, we can go to Exchange Management Console, expand Server Configuration, Client Access, click on the desired server on the right side and then double click on owa (Default Web Site), and then go to the Segmentation tab, as shown in Figure 20.
Figure 02
The result will be that the Calendar item will be disabled on all users that log on that server/virtual Directory. By default any changes will take up to 60 minutes to be refreshed or we can force a refresh using iisreset /noforce on the Client Access Server.
The same changes can be done using Exchange Management Shell using Set-OWAVirtualDirectory cmdlet, if the feature calendar has to be disabled, the following cmdlet can be used:
Set-OWAVirtualDirectory –Identity “SERVER\owa (Default Web Site)” –CalendarEnabled $false
Using Outlook Web App Mailbox Policies…
If you have a single server and just want to disable a couple of features for all users, then the server level settings should be fine however some companies have more complex needs. A good example is a company that has administrative and floor plan staff. The floor plan staff will have just basic OWA (no Calendar, no contacts, they want just basic mail) and the administrative staff will have all features. For this kind of situation using just server level settings becomes tricky, and using Outlook Web App Mailbox Policy becomes important because all features are managed through policies and those policies are associated to the users.
Let’s create our first Outlook Web App Mailbox Policy. Open Exchange Management Console, expand Organization Configuration, and then click on Client Access item, by default Exchange 2010 comes with a policy called Default, but let’s create a new one, click on Outlook Web App Mailbox Policies tab and then click on New Outlook Web App Mailbox Policy…
The first page of the wizard contains the Policy name that we will be using and the features that we want to manage, let’s name it Restrict Policy and let’s disable most of the stuff (Calendar, Tasks, Theme Selection and so forth, let’s keep just the basic for mail), and let’s click on New (Figure 03), and then Finish in the following page.
Figure 03
The same can be accomplished using Exchange Management Shell, first the cmdlet New-OWAMailboxPolicy –Name “Policy Name” can be used to create the policy and afterwards the Set-OWAMailboxPolicy can be used to enabled or disable the features.
The result of the new OWA Mailbox Policy can be seen in the Figure 04. An Exchange organization can have as many Outlook Web App Mailbox policies as required, but keep in mind only a single policy is associated to a user.
Figure 04
Besides of the initial wizard during the policy creation, the administrator can also define Public and Private computer file access using the same policy. Just double click the desired policy and do the changes like you used to configure at the server level and after that any user assigned to that policy will receive the same settings defined here. (Figure 05)
Figure 05
In order to configure the users with the new policy, we just need to go to the user properties and then Mailbox Features tab, and double-click on Outlook Web App item. Enable the option Outlook Web App mailbox policy and click on Browse and select the policy that we have just created (Figure 06) and click OK twice.
Figure 06
That’s all to create an Outlook Web App Mailbox Policy, after associating the new policy with the user, as soon as the user logs on the settings will be applied, as shown in Figure 07.
Figure 07
If you don’t want the OWA Mailbox Policy being applied to a user just uncheck the option Outlook Web App mailbox policy (shown previously on figure 06) and the restriction will be removed next time the user logs on Outlook Web App. If there is any server level feature settings configured, then those will be applied because the mailbox doesn’t have any other policy.
Conclusion
In this article we validated how to configure OWA policies at server level and also the new feature of Exchange Server 2010 which simplifies the administration of creating policies that can be easily assigned to users without stopping services or waiting for refresh intervals.
