Enabling and disabling MAPI and/or non-Cached access per user in Exchange 2003 SP2

Exchange Server 2003 Service Pack 2 (SP2) adds functionality to allow the administrator to completely turn off MAPI access for a given user or grant access to a user whose Outlook is configured for cached mode but deny access otherwise. This functionality is expected to be valuable to providers of hosting services that for example want their end users to connect to Exchange with Outlook Web Access but not with Outlook (via regular MAPI connection or RPC over HTTP). 

The ProtocolSettings attribute on the user object in the Active Directory stores client access settings. This attribute is a multi-valued string property, where each string applies to a different protocol. MAPI access can be restricted by manually adding the following string to the ProtocolSettings attribute using a tool such as ADSIEdit:

 

MAPI§<Bool1>§<Bool2>§§§§§§

 

The eight § separators define exactly nine fields. The meanings of the fields are as follows:

 

MAPI	Specifies that this string contains settings that apply to the MAPI protocol
Bool1	0 to block all MAPI access; 1 to determine MAPI access based on Bool2.
Bool2	0 for “no effect”; 1 to deny access to non-cached mode Outlook clients
Remaining 6 fields	Currently not used

 

If there is no MAPI string in ProtocolSettings, all MAPI clients are allowed.

 

Some examples of this:

 

MAPI§0§<Bool2>§§§§§§- this would block ANY client MAPI access to the mailbox (cached or not), no matter what the value of “Bool2” was.

 

MAPI§1§0§§§§§§- this would not block anything, because the value “Bool2” is set to “0”. MAPI access is allowed for online and cached clients.

 

MAPI§1§1§§§§§§- this would block any “online” (non-cached) MAPI access. Outlook clients accessing the server using cached mode would be able to connect to the mailbox.

 

If the MAPI string does not have the eight separators and conforms to the expected data types, the behavior is undefined.

 

The access restrictions specified above do NOT apply in the following cases:

- the client is an Exchange component (for example, mailbox moves would still work correctly regardless of the MAPI access settings for the mailboxes)

- the client is doing delegate access to the mailbox

 

Delays in ProtocolSettings becoming effective can be caused by:

 

1. As with others mailbox properties stored in the DS, ProtocolSettings are cached in the MBICache (default TTL = 2hrs) and in DSAccess (default TTL = 15 min). These caches may delay the time it takes for a change in the ProtocolSettings to become effective.

 

In order to read more about the Information Store cache, please see the following article:

 

179065 XADM: Changes to Primary Windows NT Account on Mailbox Do Not Take Effect

http://support.microsoft.com/?id=179065

 

2. The access check is performed at connection time. If a user is connected and the setting is changed to deny access, the change won’t take effect until the client disconnects (which may take place several days later).

 

3. In the case above, since Outlook typically uses more than one connection, if one connection drops while the others stay on, there may be unexpected behavior when Outlook tries to re-establish the dropped connection. This client has will be denied access and all it takes to find out what is happening is to restart Outlook.

 

One additional thing to mention is that is the following registry key is set:

 

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Disable MAPI Clients

 

is set to block certain client versions server-wide, specific users could be affected (blocked) either by the above registry setting or the per-user MAPI ProtocolSettings.