Blocking Client Access to Exchange Servers

Administrators occasionally need to prevent users from accessing an Exchange server while the system is running. For example, if you've just installed some new Exchange-related software, you'll probably want to test the software before you make it available to your users. But just how do you keep users away from an Exchange server? By changing a few registry settings, you can limit client access to Exchange 2000 Server and Exchange Server 5.5. Specifically, you can block individual Messaging API (MAPI) clients, groups of MAPI clients, or client IP access. Alternatively, you can selectively grant some clients access and block all other clients. Finally, you can block access while you move mailboxes to another server in Exchange 5.5. As in all cases, any time you access the system registry, make sure you have a backup copy—just in case.

Blocking MAPI Clients
Exchange 2000 (Service Pack 1—SP1—and later) lets an administrator block specific MAPI clients or groups of clients. You can use this feature to "encourage" users to upgrade their email client. For example, to ensure that everyone has applied a service pack or hotfix, you might block access to users' mailboxes until they use an appropriate email client.

MAPI clients vary from the original "Capone" client that Microsoft distributed with Exchange Server 4.0 in 1996 to the latest Outlook XP client. Each client uses a slightly different version of the MAPI client provider to access Exchange, and Microsoft gives each MAPI client provider a different build ID. For example, Figure 1, page 2, shows that the build ID for msmapi.dll, the file that contains the MAPI client provider for Outlook XP, is 10.0.3416. The first piece of this ID represents the major build number. Microsoft sometimes associates this major build number with an internal number to track releases of Microsoft Office. Because Exchange used to ship its own client before Microsoft released Outlook, major build numbers before Office XP relate to versions of Exchange (e.g., 5.0, 4.0) rather than Office.

When a MAPI client connects to Exchange, the client passes MAPI client provider details to the server. You can use Exchange System Manager (ESM) to view this information by examining the users who are currently logged on and connected to a Store database, as Figure 2, page 2, shows. Note that the Client Version ID reported here consists of four sets of numbers rather than the three sets of numbers in the build ID.

The registry setting you use to block client access depends on the MAPI client provider version number, so specifying correct values for the clients you want to block is important. Table 1 lists the Microsoft MAPI clients, the MAPI client provider version numbers that appear when you view the MAPI client's Help/About option, and the adjusted values that you need to enter in the registry to block client access. If you're not sure which adjusted value to use, simply connect a copy of the client that you want to block to Exchange, use ESM to view the MAPI client provider information, note the MAPI client provider version number, and discard the second digit from the left. For example, Figure 2 shows a client connected with MAPI version 5.0.2819.0. If you discard the second digit from the left, the resulting value required to block client access is 5.2819.0. If you look up this value in Table 1, you can see that it belongs to an Outlook 2000 client.

Many Exchange services use MAPI to access the Store, so it's important that you don't block access to MAPI client providers that begin with the number 6. For example, the MAPI client provider version number for Exchange 2000 SP1 is 6.4712.0 and for SP2 is 6.5716.0 (the easiest way to find these values is to view the properties of mapi32.dll in the exchsrvrbin directory). If you block these values, services such as the Exchange System Attendant won't work.

To block MAPI client access to the Store, open the system registry and navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISParametersSystem subkey. From the Edit menu, select New, String Value to create a new REG_SZ value called Disable MAPI Clients, as Figure 3 shows. The new value contains MAPI client provider version numbers for the clients that you want to block. You can either enter a range of numbers to block multiple clients or individual numbers. For example, the value in Figure 3 blocks Exchange 5.0, Exchange 4.0, and Outlook 97 (Office version) client access; a single value of 5.2178.0 would block Outlook 98 client access.

You can place a hyphen (-) before the registry value to block all clients released before the stated value. For example, you can use -5.3143.0 to block access for clients available before Microsoft updated Outlook 2000 with SP2 (i.e., 5.3144.0). Similarly, you can place a hyphen after the registry value to block all clients released later than a specific value. For example, you can use 10.0.3147- to block access for clients available after Outlook XP SP1 (i.e., 10.0.3416).

After you update the registry, you must stop and restart the Information Store service to implement the MAPI client block. After you stop and restart this service, users who don't use an appropriate version of the MAPI client provider won't be able to open their mailbox and will receive an error message, which Figure 4 shows (Outlook Web Access—OWA—users will see the standard HTTP 500 "you cannot access this page" error). Make sure your Help desk staff know how to check MAPI versions and how to verify that users have the correct client software.

Blocking Client IP Access
The Windows registry doesn't include a setting to block HTTP, IMAP4, or POP3 client access to Exchange. However, you can selectively disable access on a user-by-user basis or stop the appropriate virtual server. To block access for a specific user in Windows 2000, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, select Advanced Features from the View menu, right-click the user account that you want to block, then select Properties from the context menu. Select the Exchange Advanced tab, then click the Protocol Settings button to view the Protocols window, which Figure 5 shows. Select the protocol you want to control, then click Settings to disable access for that protocol. If you decide to take the drastic action of stopping a virtual protocol server to block all client access through that protocol, open ESM, select the physical server that hosts the virtual server, click Protocols, select the virtual server (e.g., Default IMAP4 Virtual Server), and click Stop. You can then click Start to let clients connect when you're ready to grant access again.

Selectively Granting Exchange 2000 Access
With Exchange 2000 SP1 and later, you can set the two registry values that Table 2 shows to let only a specific account connect to the server. These values appear in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISParametersSystem registry subkey, as Figure 6 shows. The registry values in Figure 6 prevent anyone from logging on and connecting to the Store except for the account with its legacyExchangeDN attribute set to

/o=Compaq/ou=Ireland/cn=Recipients/cn=TonyRedmond

After setting the appropriate values in the registry, you must stop and restart the Information Store service to begin blocking access to all other clients. The Store reads the registry when the service starts, notes the presence of the values, then verifies whether Active Directory (AD) contains an account whose legacyExchangeDN attribute matches the registry values. The Store can perform this search quickly because AD indexes the legacyExchangeDN attribute, which Exchange 2000 uses to match the address information in old messages and address book entries against AD objects. If the Store finds an AD account containing the matching attribute, the Store begins to block access to all other users. However, if the value for the legacyExchangeDN attribute is null or invalid, the Store operates as usual and all users can access their mailboxes.

You can use the ADSI Edit utility to identify the value of the legacyExchangeDN attribute for a particular user account. Figure 7 shows how ADSI Edit displays the legacyExchangeDN attribute value for a mail-enabled account, which you can find in the Domain Naming Context container. You can either note this value or simply copy it from ADSI Edit into the registry editor.

To remove the selective access, you can either delete the Logon Only As registry setting or change its value to 0. Remember, you must stop and restart the Information Store service to complete the removal process.

Selectively Granting Exchange 5.5 Access
Exchange 5.5 also lets you selectively grant user access but requires setting just one registry value. Once again, you must set the registry value, then stop and restart the Information Store service to complete the process. The Microsoft article "XADM: Limiting Logons to the Information Store" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q146764) provides full details. The registry value that you need to set is Logon Only As of type REG_MULTI_SZ, which is in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeIS registry subkey.

Apart from using one registry value rather than two, a major difference between selectively granting access in Exchange 2000 and Exchange 5.5 is the functionality of the access. Whereas the registry setting for Exchange 2000 lets you grant access to one mailbox at a time, the registry setting for Exchange 5.5 lets you create an entire list of mailboxes that you want to grant access to. This difference exists because the Exchange 2000 registry value is of type REG_SZ (single string), whereas the Exchange 5.5 registry value is of type REG_MULTI_SZ (multiple value string).

Thus, on an Exchange 5.5 server, you can input distinguished names (DNs) for multiple mailboxes that will have access after you block all other users—for example

/o=Compaq/ou=Dublin/cn=recipients/cn=TonyRedmond/o=Compaq/ou=Dublin/cn=recipients/cn=KieranMcCorry

You need to enter the DN for each mailbox on a separate line.

DNs are the key to entries in the Exchange 5.5 Directory Store. When you migrate to Exchange 2000, the value of a mailbox's DN moves into the account's legacyExchangeDN attribute because AD uses globally unique identifiers (GUIDs) as its key for objects. To identify which values to use to selectively grant access in Exchange 5.5 in the registry, start Microsoft Exchange Administrator in raw mode (i.e., run admin.exe with the /r switch) and examine the attributes of the selected accounts. Unlike Exchange 2000, if the registry value is blank, no one will have access to the server.

Moving Mailboxes
For Exchange 5.5, you can block user access while you move mailboxes between servers in the same site. The Microsoft article "XADM: How to Prevent Logons During Move Mailbox" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q218920) describes this process, which consists of limiting access to hidden mailboxes that the System Attendant and Directory Service (DS) use on both servers during the mailbox migration. To block access while moving mailboxes, you need to enter the DNs for the mailboxes that the System Attendant and DS use in the Logon Only As registry value as follows:

/o=OrgName/ou=Site Name/cn=Configuration/cn=Servers/cn=Server1/cn=Microsoft System Attendant/o=OrgName/ou=Site Name/cn=Configuration/cn=Servers/cn=Server2/cn=Microsoft System Attendant/o=OrgName/ou=Site Name/cn=Configuration/cn=Servers/cn=Server1/cn=Microsoft DSA/o=OrgName/ou=Site Name/cn=Configuration/cn=Servers/cn=Server2/cn=Microsoft DSA

You can't use the same technique with Exchange 2000: Because the System Attendant always has access to mailboxes, it can process mailbox moves when other mailboxes are locked out.

Summary
The registry changes I've explained here let administrators apply blocks to Exchange 2000 and Exchange 5.5 servers. To recap, you can implement a block on either an Exchange 2000 or Exchange 5.5 server by performing the following steps:

Remember to try the settings on a test server before you apply them to a production server, and always remember to remove the settings from the registry after they're no longer required. Finally, the registry settings I've discussed apply only to one server, so you'll need to implement these settings on each server on which you want to block access.