4.1 MAPI-Messaging Application Protocol

 < Day Day Up > 



Despite not being under active development for many years, MAPI remains the most functional and rich client application programming interface (API). As a platform, MAPI's role within the server has steadily declined since it reached its zenith in Exchange 5.5. The development group now favors either Internet protocols (SMTP, LDAP, HTTP, HTTP-DAV, etc.) or other Microsoft protocols (such as ADSI) whenever possible. In this respect, we have to make a distinction between the on-the-wire protocol used by clients and the API, since they are sometimes intermingled during a discussion about clients. For example, Outlook uses MAPI as the API to manipulate mailbox contents both locally and on the server and generates RPCs to fetch information from the server. RPCs can travel across different network protocols and now, with Exchange 2003 and the necessary Windows supporting infrastructure, you can even wrap RPCs in a layer of HTTP to navigate the Internet. Things can get quite complicated in the blizzard of protocol acronyms.

To return to the beginning, MAPI is Microsoft's Messaging Application Programming Interface, which first appeared in 1993 as part of Microsoft Mail. The implementation in Microsoft Mail was incomplete, as Microsoft had not yet fully fleshed out all the functions and interfaces that deliver the rich functionality available in today's clients. In fact, just enough functions were available to build a basic messaging system, so the version of MAPI in Microsoft Mail is "Simple MAPI," "sMAPI," or "MAPI-0." Simple MAPI is composed of 12 functions, including those necessary to log on to a server and then to create, address, send, and read messages. Extended MAPI or MAPI V1.0 is a far more comprehensive interface designed to meet the needs of many different messaging systems. Microsoft has removed support for Simple MAPI in Exchange 2003 and now the server only supports Extended MAPI.

It is worth emphasizing that there are two distinct versions of MAPI: one for the server and one for the client. It is wrong to assume that Microsoft keeps the two versions in lock step, because this has never happened and is the reason why you see some problems if you install a MAPI client such as Outlook onto an Exchange server. Almost everything works, but Microsoft is quite adamant that this is a bad idea. If you want to log on to the server and run an Exchange client (perhaps to check that email is flowing properly after you apply a service pack), it is better in most cases to use a client such as Outlook Express or Outlook Web Access, which does not require you to install the client-side MAPI components on the server.

While MAPI continues to provide the base platform for Outlook, it has weakened in terms of its predominant position for server-based functionality. There are three reasons for this. First, Internet protocols have become more important to Microsoft, so they do not always look at MAPI as the only solution for a problem. For example, Microsoft uses HTTP-DAV in the Exchange 2003 version of ESM to fetch information about public folders-something that the developers would previously have done with MAPI. On the client side, the Entourage for Macintosh Client has also begun to use HTTP-DAV in conjunction with IMAP4 to provide Exchange-based calendar and scheduling functionality without going anywhere near MAPI. Second, the architecture of Exchange has evolved to accommodate a division of work between front-end and back-end servers, but only when Internet clients are connected. Third, the introduction of other programming interfaces to the Store means that programmers have easier alternatives to MAPI when they need to work with Exchange.

In some respects, Microsoft has simply ignored MAPI, because it has not developed MAPI to any degree since it released Version 1.0. Microsoft has fixed bugs as they appeared, but the original intention for MAPI to be the foundation for Microsoft messaging products has long since disappeared. If you ask any Microsoft developer to assess an API that has no program manager or development resources assigned to it, he or she would tell you that this is "functionally mature technology" or even apply the dreaded "legacy" label. However, while noting that MAPI is now in the category of legacy APIs, it is also true that many independent software vendors (ISVs) continue to use MAPI to build add-on server-based products for Exchange. These companies will move from MAPI, but only after Microsoft provides an equally functional server-based API to replace MAPI.

The strategy of moving rapidly away from a highly functional and stable API such as MAPI to focus on Internet interfaces has some risks, but it is a good example of Microsoft flexibility in action. Microsoft is able to say that Internet protocols provide the foundation of Exchange, while still being able to use its own highly functional but proprietary interface for its own leading client, and it has improved the way that Outlook and Exchange communicate together with the Outlook 2003/Exchange 2003 combination with the introduction of cached Exchange mode. I suspect that Microsoft has half an eye on the future with respect to the next generation of clients and servers. HTTP-DAV seems to offer the best route forward, because it exploits HTTP, generates no requirement to open up new ports in firewalls, is cross-platform out of the box, and is lightweight, but perhaps it can never be quite as functional as MAPI. We see some movement in Outlook 2003 and new Microsoft clients for Macintosh OS X, but it is still early days.

MAPI's glory days are perhaps past, but it is still critical to the overall success of Exchange and will be the most popular client access protocol for years to come, if only because it takes so long for companies to deploy new clients to user desktops.

4.1.1 Outlook

Outlook is the predominant client for Exchange. Tens of millions of people (some estimates go as high as 200 million, with well over half of those connected to Exchange) use Outlook on a daily basis. The size of the Outlook community and its support for multiple protocols has naturally attracted companies to develop servers that compete with Exchange. It is much easier to sell a mail server if you can say that it supports Outlook, because it instantly means that anyone who uses Microsoft Office becomes a potential client. Typically, ISVs build client-side MAPI components to enable Outlook to connect to their email server in exactly the same way as you connect to Exchange. For example, HP builds a MAPI driver to connect Outlook to the HP OfficeServer for OpenVMS server. Connecting to the server is a matter of creating a new MAPI profile that points to the server, ensuring network connectivity (usually over TCP/IP), and connecting. The sole clue that a user may see to indicate that he or she is not connecting to Exchange is the need for multiple passwords, if the email server does not support single sign-on functionality using Windows credentials.

Other examples of integrated email servers that support Outlook include Samsung Contact and Oracle Collaboration Suite, while a number of Linux-based email servers use the Bynari InsightConnector to gain Outlook support. Among these offerings are the SCO Office Mail Server and Xchanger from Backwatcher. The fact that companies compete on the basis that they support Outlook for their email servers is a tribute to Outlook's functionality and the strong foundation provided by MAPI.

4.1.2 Supporting MAPI clients

MAPI clients vary from the original "Capone" client distributed with Exchange 4.0 in 1996 to the latest Outlook client. You can connect even the oldest MAPI client to Exchange 2003 without problems. Simply configure a MAPI profile to point to the name of the Exchange server and start the client, selecting the name of the profile that you have just created. You access the Outlook 2002 option to set up a profile through Tools.E-Mail Accounts, or use the Tools.Services option for all previous MAPI clients.

Figure 4.1 shows the Windows registry editor, REGEDIT.EXE, viewing details of an Exchange profile on a Windows XP Professional desktop. The registry key that points to all the profiles created on a PC is:

click to expand
Figure 4.1: Details of a MAPI profile.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\ CurrentVersion\Windows Messaging Subsystem\Profiles

The information held in a MAPI profile is reasonably complex, because it stores many options describing the services (e.g., the mailbox and directory) that the client uses. In addition, the registry holds some of the profile data in binary format. However, it is worth your while to understand how you can tweak the way that Outlook works through the profile and consider whether you want to deploy a standard profile to restrict user options or enforce specific behavior. While Microsoft does not document all available registry settings in a single place, you can find most described in Knowledge Base articles, so a trawl through the Knowledge Base often unearths an unexpected jewel.

Table 4.1 lists some useful registry settings to illustrate the point. These settings are valid for Outlook 2002 (a specific service pack may be required) and Outlook 2003. To enforce, you create the necessary DWORD value under the root:

Table 4.1: Outlook Registry Settings

Root

Value

Earliest Outlook Version

Meaning

-

NoOutlookFormsDesigner

XP RTM

0 = prevents use of the Outlook forms designer

HKLM**

DisablePst

XP SP2

0 = prevents user from opening PST files

Outlook\Options\

DisableHTTP

XP RTM

0 = prevents user from adding HTTP account (such as hotmail) to Outlook

Outlook\Options\

DisableIMAP

XP SP2

0 = prevents user from adding IMAP account

Outlook\Options\

DisablePOP

XP SP2

0 = prevents user from adding POP3 account

Outlook\Options\Mail\

ReadAsPlain

XP SP1

1 = force all mail to be read as plain text

Outlook\PST\

PSTNullFreeOnClose

XP RTM

1 = Outlook overwrites deleted data in PST and OST files on exit

HKCU\Software\Microsoft\Office\<version>\Outlook 

where "10.0" is the version number for Outlook 2002 and "11.0" is the version number for Outlook 2003. The only exception is "DisablePST," because it goes under the HKLM root.

Inputting these values on an individual PC is simple, but updating a few hundred PCs to attain consistency takes a lot more effort. For years, Microsoft has provided a limited set of tools (PROFGEN and NEWPROF) that you can use to generate profiles automatically, and it is possible to use these tools to create a new profile the first time a user logs on from a PC. Several third party software vendors engineer excellent utilities that make this task much easier. My current favorite is Profile Maker (www.autoprof.com). Outlook 2003 provides a suite of new options in the Office Custom Install Wizard that replaces PROFGEN and NEWPROF and allow you to automate many installation and deployment options. You may still prefer your existing tool set, but the Office Custom Install Wizard deserves your attention. Microsoft's Outlook Resource Kit (ORK) is an invaluable tool for any system administrator who has to support Outlook clients. You can download the ORK from Microsoft and then use it to configure client settings that you apply through group policies, set at either the domain or OU level within Active Directory. You can prevent users from accessing specific commands or stop them from customizing their environments. For example, you can stop users from going anywhere near Visual BASIC for Applications by applying the standard "Disable Access to VBA" template included in the ORK.

4.1.3 Authentication

MAPI clients traditionally authenticate themselves through the NTLM (NT LAN Manager challenge-response) mechanism, using cached credentials if they are available and the user has set the option to use these credentials in the profile. As shown in Figure 4.2, Outlook 2003 clients can perform native-mode Kerberos password authentication when they connect to Exchange 2003 servers. This feature is important in cross-forest deployments, where user accounts exist in one forest while the Exchange servers belong to another forest and you have created cross-forest trust relationships. NTLM works across cross-forest trusts, but it is less efficient than Kerberos, which is also the preferred authentication mechanism for the future.


Figure 4.2: Outlook authentication modes.

It is not a good idea to switch Outlook to use Kerberos authentication unless every Exchange server that the client might connect to runs Windows 2003 and user accounts are all in AD. This includes servers that host public folder replicas and applications. In the meantime, you are safest to continue using NTLM authentication.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net