Although I think that Microsoft has done a pretty decent job creating the Exchange 2007 version of OWA, the fact remains that the default OWA configuration may not suit every organization, or even every user within an organization. There are a number of possible reasons why an administrator may need to customize the OWA experience, but they may not always want for these customizations to be applied globally to every user. Fortunately, Exchange 2007 makes it possible to customize the end user OWA experience; to a degree anyway.
Unfortunately, it’s impossible to completely customize OWA on a user by user basis. OWA is a Web application that rides on top of IIS. This means that like any other Web application, the same code is used by all of the users who access it. What this means is that any changes that you make to OWA are generally going to apply to everyone (with certain exceptions). Of course that raises the question of what to do if you have users with varying needs.
Running Multiple OWA Instances
As I explained, OWA is just a Web application running on top of IIS. When run in a default configuration, IIS is a completely independent server application. What this means is that IIS is not aware of other instances of IIS that may be running on other servers on your network (clusters excluded). Therefore, if you want to assign different users different OWA configurations, then the first step toward doing so is to deploy multiple client access servers, each of which can be equipped with a different OWA configuration. You would then simply provide your users with the URL that corresponds to the client access server that you want them to use.
Why Use Multiple Client Access Servers?
OK, that’s how you can host multiple OWA configurations, but you might be wondering why you would want to. Well, there are a lot of different reasons for doing so. For example, some hosting companies provide users with access to their Inbox as a part of the base rate, but only offer calendar access to those who pay an additional premium. Even in the corporate world though, I have heard of some organizations trying to conserve server resources by only allowing users access to a minimal set of OWA features. In this type of environment though, you could use a second client access server to provide a more comprehensive feature set to the administrative staff and to any VIPs within your company who may require access beyond what you are providing to everyone else.
At this point you are probably wondering what types of customizations you can make to OWA. Exchange allows you to use a technique called segmentation to enable or disable various features. Segmentation was possible in some of the earlier Exchange Server releases too, but only through obscure registry hacks or by using ADSI Edit. Exchange 2007 actually lets you perform segmentation through the GUI.
Figure A Right click on the OWA (Default Web Site) listing, and choose the Properties command from the resulting shortcut menu.
At this point, you should see the OWA (Default Web Site) Properties sheet. You can control segmentation through the Segmentation tab, shown in Figure B.
Figure B You can control segmentation through the properties sheet’s Segmentation tab.
As you can see in the figure, the Segmentation tab lists all of the various features that are available through OWA. You can enable or disable the individual features by selecting them, and then clicking the Enable or the Disable button located just above the list of features.
In this article, I have explained that there are sometimes situations in which you may need to disable certain OWA features. I then went on to show you how to accomplish this through a process called segmentation.
Got a question? Post it on our Exchange Server Forums!