Previous Page TOC Next Page



— 4 —
Client Components


by Greg Todd

If you have looked at the Microsoft Exchange client software, you have seen that it is an extensive piece of work—there is a lot you can do with it. Microsoft has done a great job of packing in features and functions that users will find useful.

In this chapter, you are going to take a quick tour of the major architectural features of the Microsoft Exchange client software. Fortunately, regardless of which version of the client you use, they generally function the same. And if you use the Windows-based versions—Windows 95, Windows NT, or Windows 3.x—they look practically identical.



The Microsoft Exchange client software supports several different operating systems. Currently, there exists a version for Windows NT, Windows 95, Windows 3.x, and MS-DOS. By the time this book goes to print there should be support for Macintosh. For simplicity, I refer to the MS Exchange client simply as the client, regardless of the operating system version. However, if there is something specific to a particular version of the client I point it out explicitly.

This chapter covers the following items about the Exchange client:

First, you look at the features found in the client. Although this chapter doesn't go into detail about every one listed, it will be a good way to be introduced to the main features available in the client.

Next, you learn general architecture. This section goes over the general structure of the client and looks at how it is put together. This is a high-level, comprehensive look. From there the subject is broken down into subset components of the architecture.

Following the general architecture, you learn about the major components of the client architecture—namely, the modular design of the client, the implementation of MAPI, information services, and profiles.

Finally, the chapter concludes with an overview of Microsoft Schedule+, the integrated scheduling package included with Exchange.

After you read this chapter, you should have a good foundation for understanding the client and its capabilities. And although it is not an exhaustive look at all the client features, it will be something to build upon in Chapter 12, "Configuring Microsoft Exchange Clients."

Overview of Features


Microsoft Exchange is positioned as the successor and replacement for MS Mail. It is a huge step forward in functionality, power, and ease of use. The following are several features that help take that step forward:



Some of these features are covered in this chapter. Others are covered in Chapter 12.

In addition, the client currently provides, or will soon provide, support for the following platforms:



The MS Exchange client—in fact the entire MS Exchange product—represents a radical departure from the MS Mail architecture. MS Mail is based on a file sharing architecture, whereas MS Exchange Server is a client-server architecture. This brings many benefits to Exchange as highlighted throughout this book, including some of the features just mentioned. Certainly MS Mail has some of those features in its Windows-based client, such as rich message content, drag-and-drop support, and electronic forms support. However, many more features exist in the Exchange client such as offline folders, transport and store independence, view formatting, rules-based message processing, and more. Some are a direct result of the client-server architecture. Some are simply new features designed into the client. Regardless, these useful new features make the Exchange client a flexible, powerful environment in which to work.

The idea is to provide a consistent user interface regardless of the operating system you are running. That way you have to learn the general principles of the Exchange client only once, and it will apply across all the platforms.

Architecture


You might have heard the Microsoft Exchange client dubbed the "Universal Inbox." In fact, the Exchange icon in Windows 95 is not labeled Exchange, it is labeled Inbox.

As it turns out, this is an appropriate moniker to assign the client; it really is designed as a means of managing all kinds of information, regardless of the type and source. Most systems provide plain electronic mail storage, but Exchange goes beyond that and literally acts as a universal inbox to contain all kinds of information. E-mail is just one type. In addition, it could hold information such as

Although the client itself does not necessarily store all these types of information, it does provide the means to manage the information. In fact, whether the information is stored locally, on an Exchange Server, or on some other source of information, it can all be managed through the client interface.

To illustrate how this looks from an architectural standpoint, Figures 4.1, 4.2, and 4.3 show how some of the previously listed information might be accessed by the client.

Figure 4.1. In its most common use, the Exchange client provides connectivity to an Exchange Server and provides personal storage and address-book capabilities.

In Figure 4.1 see how the Exchange client provides connectivity to an Exchange server via three main information services, such as the Exchange Private Store Information Service (I.S.). Note there are also two other I.S. entities—Personal Address Book (PAB) and Personal Store (PST)—that are used by the client and are stored on your local hard disk. These are available for storing local copies of messages from outside information sources. See Chapter 12 for more details on these elements.

Figure 4.2. To maintain compatibility with MS Mail 3.x, the Exchange client provides connectivity to MS Mail 3.x post offices and provides personal storage and address book capabilities.

In Figure 4.2 see how things on the server side change to an MS Mail Post Office. Also, the information services on the client side change to provide connectivity to the post office via the LAN Message Store and Remote Message Store I.S. Connectivity to the MS Mail address list is provided by the MS Mail 3.x Address Book I.S. The Spooler and Message Transport I.S. elements are a part of MAPI, which are transparent portions of the client connectivity to the MS Mail post office.

Figure 4.3. Demonstrating the Exchange client's flexibility, connectivity can be provided to a variety of other data sources by implementing the proper information services.

The main thing to glean from these figures is that the client is consistent no matter to which data source it is connected, whether that is an Exchange server, an MS Mail post office, or another source of data.

Also, in the case of connecting to other data sources, there can even be user-interface modifications to customize the client for accessing a particular type of data. For example, if you access voice data you might want play, stop, and pause buttons on the toolbar. You might also want additional information specific to voice data in the menu items or property pages.

One other point about consistency. Notice how the personal address book and personal store are common to every scenario. This implies that you can move data around and put it in a personal (local) storage medium for later use. This is a great feature, especially if you need to archive data or take it with you when you are not connected to the network.

Hopefully I've piqued your interest in how the client works, so let's look a bit deeper into it. To understand how the client can handle messages and data of all types, you should understand a bit more about the features and design.

Modularity


The engineers at Microsoft took a modular approach to solving the problem of providing a storage medium for various—and often dissimilar—types of message data.

Figure 4.4 illustrates the modular design of the client.

Figure 4.4. The Exchange client has a modular architecture that provides for flexible connections to Exchange Server.

The Exchange client has a modular architecture that gives you flexible connections to Exchange Server. Following is a description of the components represented in Figure 4.4:

The really good thing about this design is that it provides extensibility—other vendors besides Microsoft can create their own "bolt-on" software for the client.

Figure 4.5 illustrates the bolt-on nature of the client.

Figure 4.5. Information services, also called service providers, can easily "bolt on" to the Exchange client for access to messaging services like Exchange Server.

With this approach, if you need to access a certain type of information it's just a matter of writing an information service to connect the client to the desired messaging service. In addition, parts of the actual user interface can be extended and customized. The following lists these parts:

For example, the original Exchange client might not have a menu for a specific feature, so you might need to add a new menu item germane to the feature. Likewise, for convenience, the function provided by the new menu item might be handy to have on the toolbar; you can extend the toolbar to included the new function. Similarly, you can add event handlers and property pages where needed.

Microsoft provides a MAPI Software Development Kit (SDK) to provide guidance in accomplishing these extensions.

This design also provides independence from transport, store, and address services. You are relieved from worrying about whether the client is running TCP/IP, NetBEUI, IPX/SPX, or whatever. Also, it does not matter whether the messages or address information are stored locally, on a server, or somewhere else. Likewise, it does not matter where addressing information is obtained—you could use the MS Mail Post Office Address List or the Exchange Directory without worrying about the source. Theoretically these just bolt on as well.

With this design, the client doesn't need to have any knowledge about the destination of its data, be it an Exchange Server or something else. Conversely, any messaging service—whatever it is—does not require any knowledge about sending its data to an Exchange client.

This approach truly enables the client to be applied across information types—a universal inbox.

MAPI


A key component to the modular architecture of the client is MAPI. Basically, you can list three different categories of messaging applications, all of which are supported by MAPI.

You should also know that there are three subsets of the MAPI interface that roughly correspond to the preceding three types of applications.

Look at these in order to give you an idea of what's what.

Messaging-aware applications are the most rudimentary applications. The application's main function is not centered around messaging, but it can perform simple messaging tasks as an added feature. An example of this type of application is Microsoft Word. There might be a Send or a Post to Exchange Folder command on the File menu to provide some basic messaging, but the main purpose of Word is not messaging.

Messaging-enabled applications are slightly more complex. Their general purpose is to provide some sort of messaging functionality to the user. A good example of a messaging-enabled application is Microsoft Mail. The main function of MS Mail is to provide e-mail services, but like messaging-aware applications such as Microsoft Word, MS Mail relies on a messaging information service to perform the work of packaging, storing, retrieving, and sending messages.

Messaging-based applications are the most complex of the three types of applications. They are designed to operate over a network, many times typically in a client/server type of environment. Of course, applications based on Exchange represent a good example of messaging-based applications; the Exchange client itself could even be included in this classification. More general examples, however, are applications built on Exchange such as workflow, fax management, and group collaboration applications.

Information Services


As mentioned before, an information service—sometimes referred to as a service provider, or just provider—is how the connection to an external information source is bolted onto the client. The creator of the information service must follow the guidelines in the Microsoft MAPI SDK to write to MAPI.

MAPI defines interfaces for three basic types of information services, illustrated in Figure 4.6.

Figure 4.6. There are three main types of information services (or providers) in MAPI. An information service can contain any or all of them.

These three information services serve as building blocks for messaging applications or other information services, which can contain any or all of them.

An address book information service, or address book provider, allows access to the database, which contains information on all the users, distribution lists, public folders, and so on contained in the system. In short, this information service provides access to the central directory service.



A special form of the generic address book is the Personal Address Book (PAB). This provides a container for recipient information obtained from other address books. It is good for easy retrieval of common recipients, especially while offline. It can also maintain entries for recipients not in the main address book. These entries are called personal one-off addresses. Note that the PAB is not intended for entries contained in the main address book. If you need access to address entries while you are not connected to the Exchange server, use the Offline Address Book provided with the Exchange client. You can find more information on the Offline Address Book in Chapter 12.

A message store information service (also known as a message store provider) supplies storage, organization, and retrieval facilities for messages in the system. If the message store is MAPI-compliant, it is organized into a hierarchical arrangement of folders, messages, and attachments to make things easier to find and store. You could think of it as the warehouse for your messages. This type is the most common and visible type of information service.

Two good examples of message store information services commonly used in the client are the Microsoft Exchange Server and the Personal Folders information services. Refer back to Figure 4.5 to see how these bolt on to the client. The former provides connectivity, through MAPI, to an Exchange Server; the latter provides connectivity, also through MAPI, to the personal message store (PST) on your local hard drive.

The following is the general hierarchy of a message store provider:

Finally, a message transport information service (also known as a message transport provider) provides message transport services. Working in conjunction with the message spooler, which is the process responsible for actually moving a message, it is the entity that is responsible for transporting a message from the local MAPI message system to the network server. You could think of the message transport provider as a delivery truck for your messages.

Microsoft provides basic versions of these three information services with the MAPI subsystem in Windows. They can be used as is or they can be replaced with enhanced versions created by Microsoft or by other software vendors. Together, they work to form a complete messaging system for the user.

Profiles


It's easy to add new information services using the bolt-on architecture. However, the more services you add, the more difficult it will become to keep track of the services, which one is in use in a particular situation, how it is configured, and so on.

Enter Exchange client profiles. Profiles are an optional service of MAPI employed to keep track of the user configuration of the information services on a client.

If you are familiar with Microsoft Mail, you know that user-specific information is kept in a file called MSMAIL.INI. Items such as the server name and mailbox name are kept there. You can think of a client profile as a service that contains multiple MSMAIL.INI files.

Profiles are what provides one of the client's most flexible options. They are a collection of messaging services that enable a MAPI application, such as the Exchange client, to start all the proper storage, address book, and transport information services required.

For example, a single user can have many profiles on a single workstation. Therefore, if you use a laptop both at work and at home, you can have a profile tailored for the way you use Exchange in both places.

As another example, many users can have their own separate profiles on a single workstation. If a certain client machine is shared by several users, each user can have a personal profile tailored to the specific and varying configuration needs of that person.

Figure 4.7 illustrates how profiles might be used.

Figure 4.7. Profiles provide flexibility in maintaining Exchange client configurations.

Using Figure 4.7 as an example, User 1 has a computer for work and a separate computer for home. The work computer has a profile named Work, which contains work-related information services. Likewise, the home computer has a profile named Home, which contains home-related information services.

User 2 has a single computer for both office use and travel use. So when User 2 is in the office, he selects the Office profile when Exchange starts. Likewise, when he's on the road he selects the Travel profile.

Finally, Users 3, 4, and 5 all share a computer. They have the same information services, but because they don't use identical client settings (they each have different mailboxes, for example) each user can select a personalized profile when Exchange starts. Assuming you have the Exchange client configured properly, when the program starts the user simply selects the profile to be used for that session.

Microsoft Schedule+


Microsoft Schedule+ (pronounced Schedule Plus) version 7.0 is included with Exchange. The software enables users in a group or individuals to manage schedules, calendars, tasks, and communication. It is tightly integrated with the client to provide unified functionality.

Schedule+ can be launched either from the separate icon in the Microsoft Exchange program group or from within the client. It can operate in two modes:

Stand-alone mode is available to any user, regardless of whether the user is network connected or not. In this way it basically becomes a personal calendar and scheduling package for use on a personal system, regardless of network connectivity.

If the Exchange client is not set up with mail, Schedule+ always runs stand-alone. If the client is set up with mail, Schedule+ will prompt the user at startup to select whether to work stand-alone or group-enabled. In stand-alone mode all the features of Schedule+ are available, but the information cannot be shared with other users. In group-enabled mode the same features are available, but all the information can be shared with other users in the workgroup.

Group-enabled mode is available only if the client is connected to one of the following mail systems:


Summary


This chapter gave an overview of the Microsoft Exchange client, its features, its main architectural design, and its components.

First, you looked at the features found in the client. The chapter didn't go into detail about every feature listed, but it was a useful way to get introduced to the main features available in the client.

Next, you learned general client architecture. In this section you went over the general structure of the client and looked at how it is put together. This was a high-level, comprehensive look, a springboard into discussing the various subsets of the architecture.

Following the general architecture, you learned about the major client components, namely its modular design, implementation of MAPI, information services, and profiles.

Finally, the chapter concluded with an overview of Microsoft Schedule+, the integrated scheduling package included with Exchange.

At this point you should have a good foundation for understanding the client and its capabilities. This chapter was not intended as an exhaustive look at all the client features, but it forms a basis to build upon later in Chapter 12.

Now that you have been introduced to the client and the server, it's time to move into a discussion of some administrative concepts that are useful for Exchange. This is the subject of the next chapter. If nothing else, it should help you get a feel for what is ahead for administrators.

Previous Page Page Top TOC Next Page