How to allow or deny access to 9 features

Outlook Web Access (OWA) 2000 offers several scalability and usability enhancements over OWA 5.5. A big complaint about OWA 5.5 is its performance overhead, so these enhancements are good news for organizations that are migrating to Exchange 2000 Server. However, in moving to OWA 2000, administrators give up the ability to quickly customize OWA's look and feel.

You can use the Exchange store (formerly called the Microsoft Web Storage System—WSS) forms engine to customize many aspects of OWA 2000. (For information about WSS, see Kevin Laahs, "Using Web Storage System Forms," March 2002, InstantDoc ID 23768.) Using the forms registry, you can create forms that let your users store new types of data in the Exchange store. You can also create custom forms that permit or prevent certain user actions.

However, you can't easily use forms to control what users can do with the built-in forms. For example, suppose you administer the Exchange servers for a school district. You want students to have access to the Messaging function only; teachers to have access to the Messaging, Calendar, and Contacts functions; and email administrators to have full access to OWA 2000's functionality. In OWA 5.5, you can easily limit different users' access to certain functions. In OWA 2000, you couldn't limit access until the release of Exchange 2000 Service Pack 2 (SP2).

Enter Segmentation
With Exchange 2000 SP2 and later, you can segment OWA 2000—that is, you can control which users can access which OWA functions. Segmentation gives you fairly fine-grained control over the functions that users can access at the cost of a little head scratching and scripting. You can also apply segmentation to a server. This feature eliminates the need to apply the necessary attribute setting to every user account. Instead, you simply make a registry modification on the target OWA 2000 server, and the setting applies to all users on that server.

Using segmentation, you can enable or disable several OWA 2000 features. Some of these features are new in Exchange 2000 SP2, so they might be unfamiliar to you. Here are the nine customizable features:

  • Calendar. When you enable the Calendar function, users can access their Calendar folders. If you also enable the Calendar reminders option, users can receive reminders of upcoming appointments.
  • Contacts. When the Contacts function is on, users can access their personal Contacts folders.
  • Tasks. When you enable the Tasks function, users can access their Tasks folders. OWA 2000 doesn't support tasks; it just shows a bunch of items in the folder, with no special UI. However, third parties or Microsoft might add task support in the future.
  • Journal. When the Journal function is on, users can access their Journal folders.
  • Notes. When you enable the Notes function, users can see and access their Notes folder. Like tasks and journal items, notes aren't explicitly supported in OWA. However, users can still open this folder and read the notes.
  • Public Folders. Turning the Public Folders function off hides public folders from the OWA interface. OWA 2000 also hides the Public Folders link in the top toolbar (which you see in only downlevel browsers, such as Netscape or Microsoft Internet Explorer—IE—4.0) and the Public Folders link in the folder tree control.
  • Calendar reminders. New with SP2, the Calendar reminders feature lets OWA 2000 display an Outlook-like window that notifies users of pending Calendar appointments. If you want users to see Calendar reminders, you must install SP2 and enable both the Calendar reminders option and the Calendar function.
  • Rich interface. OWA 2000 has always had two interfaces: rich and reach. The rich interface provides the best functionality but requires IE 5.0 or later. The reach interface provides less functionality, but all clients can use it. Previously, IE 5.0 clients had to use the rich interface. With SP2, you can turn off the rich interface for IE 5.0 clients and instead use the reach interface.
  • New mail notification. New mail notification is another new SP2 feature. OWA 2000 displays a small Windows Messenger­type window that informs users when new mail arrives. If you want users to receive the notifications, you must install SP2 and enable both the new mail notification option and the rich interface.

Turning a particular feature off has broad effects. For example, disabling features limits the types of new folders that a user can create. Users can only create new folders of the types that you explicitly enable. For example, for a user to create a Calendar folder, you must enable the Calendar function for that user's mailbox.

How Segmentation Works
To control segmentation, you use bits in a bitmask. Each of the nine customizable features has a bit in the bitmask. When you set a bit to 1, you enable the corresponding feature; when you set the bit to 0, you disable the feature. Because bits in a bitmask correspond to increasing powers of 2, you can calculate each feature's decimal and hexadecimal value, as Table 1 shows. You can enable any combination of features by summing those features' decimal or hex values. The total is the segmentation value.

Currently, when you calculate a segmentation value, you need to include an enabled bit for the Messaging function. Although you can't disable this function in OWA 2000, Microsoft is considering letting you do so in a future version and has set up the bitmask accordingly. As a result, when you calculate a segmentation value, you must include the enabled bit for the Messaging function. As Table 1 shows, you add the decimal or hex value of 1 to your calculation. So, for example, if you want to enable the Calendar and Public Folders functions, the correct decimal segmentation value is 67 (1 + 2 + 64). The correct hex segmentation value is 43 (1 + 2 + 40).

After you calculate the segmentation value, you apply the segmentation to the server or to individual users. (You can't apply the segmentation to security or distribution groups.) When you apply the segmentation to a server, the segmentation applies to all mailboxes on that server. Changing the segmentation at this level requires you to stop and restart the Information Store (IS) service, during which time the server's mailboxes will be unavailable. Applying segmentation to individual users requires you to make a schema change. Although you're changing only one attribute, any change to the schema forces a mass re-replication of all the object attributes in the forest's Global Catalog (GC) servers. Further, schema changes are typically irreversible.

Working with Servers
Applying segmentation to a server is fairly simple. In the registry, you need to create an entry named DefaultMailboxFolderSet under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA subkey. Enter REG_DWORD in the Type column, and enter the segmentation value (in decimal or hex form) in the Data column. After you make this addition, stop and restart the IS service and Microsoft IIS's WWW service.

Working with Individual Users
To apply segmentation to user accounts, you need two files from the SP2 CD-ROM's \support\owaschema directory. Those files are

  • owa-schema.ldf—an LDAP Data Interchange Format (LDIF) file that contains the Active Directory (AD) schema changes
  • owa-schema.vbs—a VBScript file that applies the LDIF file's schema changes to the schema master

To update the AD schema, connect to the schema master. Making this connection requires enterprise administrator and schema administrator permissions. For best performance, run owa-schema.vbs from the command line on the schema master computer. Alternatively, you can use the LDIF Data Exchange (LDIFDE) utility to manually import the schema file. Either way, you must wait for AD replication to complete across all GC machines in your forest before you can apply the segmentation to a user account.

To apply segmentation to a user account, you need to use the Microsoft Management Console (MMC) ADSI Edit snap-in to set the msExchMailboxFolderSet attribute to the segmentation value. For information about how to use the ADSI Edit snap-in for this purpose, see the Microsoft article "XCCC: Outlook Web Access Segmentation" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q311154). If you want to apply the segmentation to numerous users, your best bet is to write a script that will programmatically set the attribute to the segmentation value.

After you apply the segmentation to a user account, you must again wait for replication to complete. Replication might take as long as 15 minutes.

Some Caveats
Before you segment OWA 2000, you need to be aware of three caveats. First, Microsoft includes an interesting warning in the SP2 deployment guide: Turning features off in OWA 2000 doesn't necessarily keep users from accessing them through Outlook or even IMAP clients that use an appropriate connector. For example, turning off access to the Tasks folder in OWA 2000 hides the folder from the user's Inbox in Outlook, but the TaskPad view in the user's Calendar folder in Outlook will still show task items. However, in general, implementations in which segmentation is the most useful don't include Outlook.

Second, when you apply segmentation to a user account, you must enter the segmentation value in decimal form. However, when you apply segmentation to a server, you can enter the segmentation value in decimal or hex form—just make sure that you choose the correct type when you create the DWORD value.

Finally, let's say you like segmentation so much that you decide to apply it to your servers and to individual user accounts. If the settings conflict—for example, if the server has the Calendar function turned off but a user with a mailbox on that server has that function turned on—the user-specific setting will take precedence over the setting you apply to the server.

Divide and Conquer
Segmentation is a handy tool for administrators of any size organization. By implementing segmentation, administrators can prevent users from accessing certain OWA features without spending a lot of time learning how the WSS forms engine works. (My thanks to K.C. Lemson and Rob Long of Microsoft for reviewing an early draft of this article and suggesting ways to improve it.)