Overview
Microsoft Office Outlook 2003, a MAPI client, includes many powerful features and will likely be the primary Exchange client used in most organizations. In this chapter, you will learn about the installation and configuration of various Microsoft Exchange client programs. We discuss how to configure and take advantage of Outlook 2003, and we examine several important Internet protocols that can be used to access Exchange Server. Outlook Web Access provides a way for standard web browsers to access Exchange information. We also cover the POP3 and IMAP4 message retrieval protocols.
Specifically, this chapter covers the following topics:
- Client platforms for Microsoft Exchange
- The MAPI architecture
- Microsoft Outlook
- Virtual servers
- Outlook Web Access
- POP3 clients
- IMAP4 clients
- NNTP clients
Client Platforms for Microsoft Exchange
The very first order of business is to define what is meant by clients for Microsoft Exchange. The best way to do that is to compare and contrast an Exchange client with an Exchange correspondent (this term is the authors’). An Exchange client application has the ability to access an Exchange mailbox as the owner of that mailbox, whereas an Exchange correspondent has only the ability to send and receive mail to and from an Exchange user. If an Exchange mailbox were a physical mailbox at the post office, a client would have the key for accessing their mailbox, while a correspondent would only be able to send mail to that mailbox or receive mail sent from it.
An example of a client application is Microsoft Outlook 2003. An example of a correspondent might be a user on the Internet. This latter functionality is enabled through Microsoft Exchange connectors or gateways. Applications that can only correspond with Exchange are also referred to as foreign mail clients. The users of foreign mail applications are defined as contacts within the Active Directory, as you learned in Chapter 5, “Creating and Managing Exchange Recipients.” This allows Exchange users to address mail to the foreign mail users (Exchange interoperability with foreign systems is covered in Chapter 13, “Connecting with Other Messaging Systems”).
There are two main Exchange client application architectures:
MAPI (Messaging Application Programming Interface) MAPI is the Microsoft API used for messaging functions. Microsoft Outlook 2003 is a MAPI client, although it does not come bundled with Exchange Server 2003 as in previous versions of Exchange.
Following are examples of MAPI client applications that can still be used with Microsoft Exchange Server but are not necessarily supported:
- Microsoft Exchange Client (the version that shipped with previous versions of Exchange Server)
- Microsoft Schedule+ 7.5 (this product has been replaced by the Outlook Calendar function)
- Microsoft Outlook 97 version 8.03 (there are also versions of this product for Microsoft Windows 3.x, Windows 95, Windows NT, and Apple Macintosh)
Internet protocols Some Internet protocols can also be used by clients to access Microsoft Exchange. Examples are as follows:
Post Office Protocol version 3 (POP3) Retrieves mail from the Inbox folder of a mailbox on a remote server.
Internet Message Access Protocol version 4 (IMAP4) Retrieves mail from a mailbox on a remote server. Access includes personal and public folders, as well as the Inbox folder.
Hypertext Transfer Protocol (HTTP) Handles data transfer between World Wide Web servers and browsers.
Lightweight Directory Access Protocol (LDAP) Provides access to directory information. Clients and servers use LDAP to retrieve information from Active Directory. In previous versions of Exchange Server, clients used LDAP to access directories managed by Exchange.
Network News Transfer Protocol (NNTP) Transfers data between newsgroup servers and between newsgroup servers and newsgroup reader programs.
Figure 7.1 illustrates foreign mail users communicating with Exchange, and Figure 7.2 illustrates various types of Exchange clients communicating with Exchange.
Figure 7.2: Exchange clientsMAPI Architecture
Many messaging systems are divided into a client side and a server side. The client side provides an interface to users and permits them to read, save, create, and send mail. The server-side programs carry out the client requests. For example, if a client issues a read request for a certain message, the server responds by transmitting the message to the client. The client software is sometimes referred to as the front end to the server software, which can be referred to as the back end. The front-end programs can be thought of as consumers and the back-end programs as producers.
| Note |
|
Historically, messaging systems have been implemented using “closed” application programming interfaces (APIs). An API is a collection of instructions, also called function calls or services. When a user wants to read a message stored on the server, the client program issues the relevant API function call to the system interface, and the server responds accordingly.
The problem with the closed API model is that each model is proprietary, and thus each vendor has its own APIs. When someone wrote a client program to be used with one of these proprietary systems, it worked with only that system. With this architecture, multiple client programs were needed to connect to multiple messaging systems (see Figure 7.3).
Microsoft decided to remedy this situation by creating a standard messaging architecture known as MAPI. MAPI provides a way for client messaging applications to communicate with multiple messaging systems (see Figure 7.4). Although MAPI is an acronym for Messaging Application Programming Interface, it is much more than an API. It is an architecture that specifies components, how they should act, and how they should interface with each other.
Figure 7.5 illustrates the basic architecture of MAPI. The top layer, the client application layer, includes client applications that enable users to perform messaging activities. These client applications are the front-end programs that request services from the back-end server programs. Client applications can include different messaging services (such as e-mail, fax, voicemail, and paging), as long as they are written to the MAPI specification. The concept of having messages from multiple sources delivered to one place is referred to as the universal inbox.
Previously, a single client program could not communicate with more than one server program, because the server programs all used different APIs. The MAPI architecture eliminates this limitation by providing a single layer through which the client programs and the server programs can communicate. This is the second layer and is called the MAPI subsystem (see Figure 7.6). The MAPI subsystem is referred to as middleware because it acts as a broker between two other layers.
Server programs can still use their own APIs on the back end. But the vendors of these programs must write a type of client component, called a service provider, that will interface their back-end system with the MAPI subsystem. Service providers constitute the third layer in the MAPI architecture (see Figure 7.7). Client software communicates with the MAPI subsystem, which communicates with a service provider, which communicates with the back-end message server. This is how a single client application, using multiple service providers, communicates with multiple back-end message servers.
The next sections provide additional details on the MAPI architecture.
Client Application Layer
Client applications that need to perform messaging functions can have those functions implemented through the use of MAPI function calls. Examples of these calls are MAPIReadMail, MAPISaveMail, and MAPISendMail. When these instructions are executed in a client application, they initiate an action in the MAPI subsystem, which then interfaces with service providers, which interface with a server messaging system, such as Microsoft Exchange Server or CompuServe Mail.
MAPI encompasses three major API sets:
Simple MAPI This is a set of 12 straightforward messaging functions, such as reading (MAPIReadMail) and sending (MAPISendMail) messages. It is included in messaging-aware applications such as Microsoft Word.
Common Mail Call (CMC) This is a set of 10 messaging functions similar to Simple MAPI. CMC is geared for cross-platform, operating system–independent development. CMC was developed by the X.400 Application Programming Interface Association (XAPIA).
MAPI 1.x (also called Extended MAPI) This is the newer, more powerful MAPI standard. It includes the abilities of Simple MAPI but adds many other instructions for complex messaging functions, such as custom forms as the CDO Library API.
See Figure 7.8 for a depiction of these three APIs in the MAPI architecture.
These three API sets allow developers to create client messaging applications that fall into two broad categories:
Messaging-aware applications These are applications such as Microsoft Word that have some messaging functions included, such as a Send option on the File menu. Messaging is not essential to these applications. Simple MAPI or CMC is most conveniently used as the messaging API.
Messaging-based or messaging-enabled applications These are applications such as Microsoft Outlook that require messaging functionality. The comprehensive function call set of Extended MAPI is normally required to implement these applications.
MAPI Subsystem
The second layer of the MAPI architecture is the MAPI subsystem (see Figure 7.9). This component is shared by all applications that require its services and is therefore considered a subsystem of the operating system. Microsoft includes the MAPI subsystem with the 32-bit Windows 98, Me, NT, 2000, XP, and Server 2003 operating systems, and the file MAPI32.DLL is the primary function library for these operating systems. The MAPI subsystem for 16-bit Windows 3.x is loaded with the installation of the Exchange client, and the file MAPI.DLL is the primary function library.
| Note |
|
The MAPI subsystem provides a single interface for client applications. Communication with all MAPI-compliant server messaging systems is facilitated by interfacing with the MAPI sub-system. It is the middleware, or broker, in the messaging environment. The subsystem manages memory, administers profiles, routes client requests to the relevant service provider, and returns results from servers via service providers.
The MAPI subsystem also presents a single, virtual address book and a single, virtual storage area to the user. As you will learn in the next section, multiple service providers can create multiple address books and multiple message stores. The MAPI subsystem presents all of these through a unified interface. Consequently, even though both an e-mail program and a fax program are being used, the user can view all addresses in one virtual address book. Because all data can be kept in the same virtual storage area, users can organize information based upon logical categories (e.g., all communication from Jane) rather than by application (e.g., e-mail directory, fax directory, etc.).
MAPI Service Providers
The MAPI architecture’s third layer contains components called service providers. These replaceable components (manifested as DLL files) communicate with the messaging system back end. There are three main types of service providers:
- Address book providers
- Message store providers
- Message transport providers
The following three sections discuss these service providers.
| Note |
|
Address Book Providers
An address book provider is a component that interacts with a database of message recipients. Some of these providers create their own address databases, called personal address books (PABs); others can access address books on a server. Address book providers can be written for many kinds of back-end systems, and because they all interface with the MAPI subsystem, a user can still have a single, virtual address book.
The following are three examples of address book providers:
Global Address List (GAL) This provider enables a client application to view an Exchange server’s Global Address List (GAL). The GAL is a database of all the recipients in an Exchange organization, such as mailboxes, distribution lists, custom recipients, and public folders. The file extension of this address book is usually .gal.
Personal Address Book This provider, also called the Local Address Book, enables the creation of a customized address book. Users can include frequently used e-mail addresses, as well as custom recipients and distribution lists that the user creates. Message recipients are not the only type of information that can be stored. Phone and fax numbers, postal addresses, and other information can be stored here. This address book can be stored on the user’s machine or on a server. The file extension of this address book is usually .pab.
Offline Address Book (OAB) This address book provider permits an Exchange server’s GAL to be downloaded to a user’s machine. This can be useful when working offline. The file extension of this local database is usually .oab.
See Figure 7.10 for a depiction of the address book providers in the MAPI architecture.
Message Store Providers
Message store providers are components that manage a database of messages. This entails client message storage, organization, and submission for sending and retrieving messages and attachments. Storage is organized in a hierarchical tree of folders. Views can be created to allow the user to see messages based on certain criteria, such as subject or date. Searches can also be conducted to retrieve specific information.
Message store providers can use server-based storage or client-based storage. Following are four examples of message store providers (see Figure 7.11):
Private folders This provider enables client access to an assigned mailbox on an Exchange server (i.e., the home server of the mailbox). The term private folders is another name for what are more commonly referred to as mailboxes. They are called “private” because, more often than not, they are associated with a single user (even though several users can be given permission to use a single mailbox). All private folders are stored on an Exchange server in the Private Information Store, which is managed by the Information Store service. The advantages of this type of storage are compression, security, and centralized backup.
Public folders Public folders are the groupware component of Exchange Server. This provider allows a client to access the hierarchical tree of public folder storage to which everyone in the Exchange organization has access. Public folders are stored on Exchange servers in the Public Information Store, which is managed by the Information Store service.
Personal folders (PST, Personal Store) A personal folder store is a file-based storage container independent of the Exchange Server back end. The file that is composed of a set of personal folders has the .pst extension. A PST file can be stored on the user’s local machine or on a shared directory on a network server. As with private folders, a user can create a hierarchical tree of folders within a personal folder store. In previous versions of Outlook, you were limited to 2 GB in size for PST files and the PST files themselves were stored in the American National Standards Institute (ANSI) format. Outlook 2003 now uses the Unicode format by default, thus allowing for PST files that can grow to 20 GB and beyond in size. Versions of Outlook previous to Outlook 2003 cannot use these new, larger PST files, however.
Personal folder stores can be assigned a password for protection. Personal folders can also be designated as the location to where incoming mail messages are moved. Although all mail is always first sent to private folders on an Exchange server, users can configure their private folders to route messages to their personal folders. Because of storage technologies used in the Private Information Store, information moved from that location to a personal folder would take up more space in the personal folder. Note also that moving information to personal folders may make backing up more complicated than if everything were stored on a server. Of course, personal folders can also be stored on a server that is included in regular backups.
| Note |
|
Offline folders (OST, Offline Store) If mailbox storage is left in the default location (the Private Information Store) and offline access to that data is also needed, the user can utilize offline folders. An offline folder is a local copy of the user’s private folders in the Private Information Store. The mailbox on the server remains the master copy. Offline folders have the .ost file extension.
Message Transport Providers
Message transport providers manage the physical transportation of messages between a MAPI client and a back-end system (see Figure 7.12). Like gateway components, they take a MAPI message, translate it to the format of the back-end system, and send it. They do the reverse for incoming messages. Message transport providers work with any of the Microsoft-supported network protocols, such as TCP/IP, IPX/SPX, and NetBEUI.
The following are examples of back-end systems that have message transport providers:
Message Spooler
The message spooler (also referred to as the MAPI spooler) is an independent process that manages the flow of messages between the message store and the transport providers. It is like a queue where incoming and outgoing messages are sent and from there are routed to the necessary providers. When a message is marked for sending, a message store provider will send it to the message spooler. The message spooler then selects, based on the destination address, a message transport provider that can send the message to the relevant messaging system.
Messaging Profiles
A messaging profile is a collection of configuration parameters for MAPI operations. The first time a user starts a MAPI-based application, the Profile Wizard runs and prompts for various operational parameters related to messaging. For example, the user is prompted to choose the information services to be used, such as Microsoft Exchange Server, Microsoft Fax, Internet Mail, and others. Information services are collections of the various providers described earlier. The user is also prompted to configure his personal address book information service. Other information in the profile relates to message handling, such as saving sent mail or generating a delivery receipt. When the MAPI subsystem starts, it reads this profile to see which services to load and how to operate (see Figure 7.13).
A user can have several profiles for one particular machine. For example, a user’s computer might be a laptop that is used both at the office and on the road. When the user is at the office, the user profile connects the user to an Exchange server at the office. When the user is traveling, a different profile connects the laptop to the Internet. Multiple profiles for a particular machine are also useful when several people use the same machine.
Common Features of MAPI-Based Applications
Many common features are found in MAPI-based applications, including the following:
Universal Inbox Information from multiple sources (e.g., Exchange Server, Internet, etc.) and of varying types (e.g., e-mail, faxes, documents, and voicemail) is delivered to a single Inbox folder.
Single address book A standard user interface to the address book is provided. Information from all the address books configured in the current profile is consolidated in one place.
Hierarchical storage Messages and other items can be organized into a user-customizable hierarchical tree of folders. Four special folders are always present in the default store. They are the Inbox, Deleted Items, Sent Items, and Outbox folders.
Custom views Information stored in folders can be sorted and viewed using many types of criteria, such as author, date, keyword, or type of content.
Rich-text formatting Users can create message content that uses the rich-text format, which includes underlining, italic, bolding, bullet points, colors, fonts, different character sizes, and letter strikethrough.
0 comments
Post a Comment