Microsoft Exchange Server Survival Guide

Microsoft Exchange Server Survival Guide

by Pete McPhedran

Hardcover(BK&CD ROM)

$41.76 $49.99 Save 16% Current price is $41.76, Original price is $49.99. You Save 16%.

Overview

Readers will learn the difference between Exchange and other groupware, such as Lotus Notes and everything about the Exchange Server, including troubleshooting, development, and how to interact with other BackOffice components.
  • Includes everything operators need to run an Exchange server
  • Teaches how to prepare, plan, and install the Exchange server
  • Explores ways to migrate from other mail apps, such as Microsoft Mail and cc:Mail

Product Details

ISBN-13: 9780672308901
Publisher: Sams
Publication date: 09/28/1996
Edition description: BK&CD ROM
Pages: 840
Product dimensions: 7.35(w) x 9.05(h) x 2.04(d)

Read an Excerpt






Microsoft Exchange Server Survival Guide -- Ch 3 -- Server Components


[Figures are not included in this sample chapter]


Microsoft Exchange Server Survival Guide






- 3 -

Server Components



by Wesley H. Peace III


Microsoft Exchange Server is the next generation in LAN-based electronic mail.
Microsoft is the first of the mainstream electronic mail providers to offer mail
that is based on a client/server model. Popular electronic mail programs such as
ccMail and MS Mail are based on a shared file system structure rather than a database.


Although Lotus Notes is popular in the groupware arena, it has not been considered
a leader in electronic messaging; this, however, is starting to change as they merge
their Notes mail product with ccMail functionality


Exchange Server supports the two popular electronic mail addressing protocols,
SMTP (which is used across the Internet) and X.400, in addition to the native Microsoft
format used by Microsoft mail.


Exchange was first released as two products, The Exchange client that shipped
with Windows 95, and the Exchange Server. This has caused considerable confusion
when someone is speaking about Exchange. However, Exchange as a product is the Exchange
Server and its supporting Exchange client, which is not the same as the Windows 95
version.







NOTE: To resolve some of the confusion, Microsoft has renamed the messaging
delivered with its operating system products, and specifically the Windows 95 Exchange
client, Windows Messaging.




The Exchange Server and client provide a true client/server messaging strategy
which is key to Microsoft's messaging strategy.


Earlier Microsoft e-mail applications have been based on a shared file structure.
Microsoft Mail, one of the most popular e-mail applications on the market today,
is based on a series of shared files and directories located on a hard disk. Although
the simplicity and network operating system independence of the implementation made
the program popular, the implementation is based on a passive file structure. All
interaction and movement of mail is controlled by the client. It is a single post
office solution that does not support delivery of mail outside of its post office.
To deliver mail outside of the post office requires the addition of an external process,
typically running on a separate machine. Large MS Mail (and ccMail) installations
have not only the post offices, but machines running support applications such as
External and Dispatch to keep the post offices and directories synchronized.


Exchange, as previously mentioned, has been designed around a client/server architecture.
The Exchange server has been implemented as a series of NT multithreaded applications
accessing a client/server fault-tolerant database. The database logs transactions
to assist in database recovery in the case of system failure.


In prior LAN-based mail systems, MS-DOS based gateways and message transfer agents
(MTA) that moved messages between post offices have been required to support multiple
servers/post offices. This is not a requirement with Exchange. Exchange is scaleable
and has been designed to take advantage of NT Server architecture and to run the
MTA processes as services. Using this connector architecture, Exchange can support
communications between organizations, servers, and sites from a single platform.
This feature minimizes the hardware requirements as well as the points of failure
in an implementation and greatly increases the scaleability of the Exchange product.

Architecture Overview (Client/Server)


The Microsoft Exchange architecture is centered around industry standard protocols
and a client/server database. Exchange has been in development for more than two
years and represents the collective effort of not just the Microsoft Exchange team,
but hundreds of beta testers. Extensive feedback from these testers has given Microsoft
a product that in many ways was designed for the industry by the industry.


Before the release of Exchange, Microsoft's primary electronic mail product was
based on a flat, shared file structure in which the client sent and received mail.


This architecture moves all processes into the Exchange Server and eliminates
the need for additional hardware components to process mail. Exchange implements
the electronic messaging architectural components defined by CCITT, User Agent (UA),
Message Transfer Agent (MTA), and Information Store (IS) to build a high-performance,
extendible multi-threaded application. Because industry standard protocols are used,
connectivity to other compliant electronic mail systems is much more easily implemented.


Exchange has changed this to a client/server architecture based an X.500-compliant
directory structure and support for X.400 addressing. Messaging between the Exchange
servers and client is handled by remote procedure calls (RPC). When the server is
operating in an NT domain, it uses NT security to validate access to the user's mailbox.
This minimizes the need for the user to remember multiple passwords. RPCs enable
Exchange to function over most popular protocols such as NWLINK (IPX/SPX), TCP/IP,
and NetBEUI.


Because of its architecture, the Exchange Server is one of the first messaging
solutions available in the LAN environment that offers scaleability and extensibility
for most user environments.


Exchange is designed to take advantage of industry standard protocols. Exchange
conforms to the 1984 and 1988 X.400 specification, which is an ISO standard for electronic
mail addressing. It is integral to Exchange and is used for all internal addressing;
it is also supported externally. The X.400 protocol model is composed of three components:
the message transfer agent (MTA), the user agent (UA), and the message store (see
Figure 3.1).


Figure 3.1. Basic X.400 messaging architecture.


The Microsoft Exchange Server architecture supports all of these components. The
Exchange Server can support multiple MTAs, such as an internal MTA to communicate
within the server and to support daily use of the server, X.400, MS Mail, and SMTP
MTAs, to name a few. The Exchange message store is composed of two distinct units,
the public store and the private store. The user agent part of the model is represented
by the MAPI clients used to access the information/message store. A new concept to
Microsoft messaging is Exchange's capability to support any MAPI-compliant client
supporting the published API set. A number of vendors such as Lotus and Crystal Computer
Services, Inc. have announced products capable of accessing the Exchange information
store.


Exchange also uses X.500 internally, the ISO standard for directory services.
Internal objects conform to an X.500-like directory specifications. It is not fully
compliant because support for the X.500 directory access and directory systems protocols
is not implemented. Microsoft recognizes the importance of these protocols and has
promised compliance in future releases. In the meantime, you can obtain support for
lightweight directory access protocol (LDAP), a subset of DAP, from third-party providers.







NOTE: The X.500 directory protocols are an emerging component in the Internet
community. There is currently no centralized method to obtain a electronic mail ID
of a user; the directory protocols are supposed to serve as a central repository
for directory information. Disparate systems can access directory information through
the directory access protocols. It is expected that these directories will not only
house information on individuals, but on objects within an organization as well.




Although they are not critical for the implementation of Exchange Server, Microsoft
is actively working on incorporating X.500 directory services into its products.
Future versions of NT will be based on these directory services.




Exchange adheres to an organizational structure based around a central administration
model. The largest administrative unit in this model is the organization, which includes
all servers in the messaging infrastructure, both local and remote. Typically, this
organization equates to the company or organization name.


Servers in an organization are grouped by sites. A site is a group of servers
that share the same directory information and communicate over high-speed, permanent
and synchronous connections. Directory changes and updates in a site are automatically
replicated to all servers; thus permitting the sharing of a single organizational
directory based on a merger of all the sites directory information.


You do administration tasks for the Exchange organization from a single interface
(see Figure 3.2), the Exchange Administration program, which is installed with the
Exchange Server.


Figure 3.2. The Exchange administrative interface.

Exchange Server


Microsoft distributes both the server and client software on a set of two CDs.
Two versions of the product are available: the Enterprise Edition with all the connectors
and the Standard Edition, which contains no connectors. You can also purchase connectors
separately.


Before Exchange, connecting electronic mail systems that ran different protocols
required a gateway. The Exchange server uses a connector. A connector is an
Exchange product developed by Microsoft that supports not only the gateway function,
but routing as well.


The Microsoft Exchange Server uses a database with transaction logging to manage
messaging. The user agent also supports multiple information services, one of which
is the Exchange Server. When the client is used in conjunction with the Exchange
Server, users connect to the information store to send and receive mail. This client-to-server
communication is handled by remote procedure calls (RPC), which permit connectivity
possible over all protocol.


You must install the Exchange Server in a Microsoft Windows NT domain. After it
is installed, it is integrated into User Manager for Domains (see Figure 3.3), which
can now create the Exchange mailbox as new accounts are created. In an NT domain,
Exchange is designed to use the NT security to validate logins. This permits the
user to log in once to the NT domain, and allow the token generated by the NT login
process to be used to access the Exchange server.


Figure 3.3. New User Manager for Domains Exchange.







NOTE: The Exchange Server takes advantage of the underlying NT domain architecture
for user authentication. A single password can be used to access both the NT domain
and the Exchange Server. This integration with the NT domain alleviates the need
to provide a separate password to access a users mailbox; but requires that the Exchange
Server be installed in an NT domain.









NOTE: some, this single login feature appears to be a problem, but the Exchange
server actually uses the NT security model to ensure that the correct user is accessing
the mailbox.



If more than one user uses a workstation, you can configure the client to prompt
for the user name, password, and domain. To do this, select Tools | Services,
and then Microsoft Exchange Server. Click Properties and the Advanced tab. Uncheck
the Use network security during logon box.



Integrating with Exchange is not a problem because it becomes impossible to "spoof"
Exchange and open up someone else's mail. Because authentication occurs "under
the covers," a rogue user cannot get his hands on it to defeat security. When
a mailbox is created, it is tied to an NT domain account. Only that individual (or
someone he has explicitly assigned permissions to) can now access that mailbox.




Conversely, the Exchange administrator can create the NT domain accounts when
he or she creates the Exchange user. This method is typically used to add a single
user (see Figure 3.4) but groups of users can be added using the import option.


Figure 3.4. Adding an NT account via the Exchange.

Server Components


Although Exchange must be installed on NT servers, this does not preclude the
use of Exchange in a Novell NetWare environment. When installed in this environment,
the Exchange server must support IPX/SPX and gateway services for NetWare.


Exchange Server is comprised of a series of NT services, databases, and log files,
which can be divided into core and optional components. Each of the core components
are installed and configured during the installation process. All core components
are configured to start automatically. These components provide the primary messaging
services; message transfer, delivery, and storage, as well as the Exchange directory
services. Optional components are also NT services. They provide connectivity and
support for communications between multiple Exchange servers and other electronic
mail systems. Security services are also considered an optional component.


The following are the Exchange services:


  • Directory



  • Information store



  • Message transfer agent (MTA)



  • System attendant



  • Directory synchronization



  • Key management



  • Connectors




You use the Microsoft Exchange Administrator, installed on the Exchange server
or an NT workstation, to configure each of these services (see Figure 3.5).


Figure 3.5. Exchange Server services.


Each of these Exchange Server services is discussed in the following sections.


The default location for the administrator program is in the Exchange executable
directory \EXCHSRVR\BIN. When started, the Administrator program presents a graphical
view into the Exchange organization (see Figure 3.6).


Figure 3.6. The Exchange Administrator structure.








NOTE: The Exchange Administration program is the only Exchange component that
does not require NT Server to run. The current version will run on NT workstation,
but will not run on either Windows 95 or Windows for WorkGroups. Installing this
component on an NT workstation enables the Exchange server organization to be managed
from a designated administrative console.





The format of the display is hierarchical, showing all objects, users, and resources
in the organization. The display is split into two areas. The directory objects are
on the left. They represent all components in the organization. The container area
is on the right. This area displays the current selected object. To view detailed
information about an object in the container area, highlight each object. You can
view the properties of each object from the File menu or select the object and press
Alt + Enter. The interface itself resembles the Windows 95 Explorer.

Directory


A key element of the Exchange architecture is the directory. It maintains all
information about the organization's resources and users. It also supports mailboxes,
custom recipients, public and private folders, distribution lists, servers, connectors,
and any other add-ons to the Exchange server. Other components of the server use
the directory to complete their jobs. The server supports OSI protocols for internal
messaging. A native X.400 address is created for all new objects that are added to
the database. Internally, Exchange stores the definitions for these objects in an
X.500-like structure. When users are created, three addresses are created: an X.400,
an MS Mail, and an SMTP.







NOTE: To change the default root component of the Exchange, select
Site Addressing from Site Configuration and edit the site addressing property for
each address.



Changing the default Site Addressing can effectively hide the existence of the Exchange
servers and support a uniform addressing organization address for the entire organization.
This is normally done with UNIX Sendmail and the sendmail.cf file, but with Exchange,
the process becomes simple.



Changing the default site addressing offers a way to secure the Exchange server and
NT user accounts from intruders and create user-friendly names for the recipients.





Microsoft Exchange uses objects to describe the structure of the organization.
All items in the Exchange hierarchy are considered objects. This includes recipients,
distribution lists, servers, and the messaging infrastructure itself.


The directory also supports special objects called containers. A container
is an object that contains other objects and containers. The objects or recipients
within the organization are addressable and maintain entries in the directory database.
If there are multiple sites within the organization, the information about these
recipients is replicated to the directory database on each server. This is how the
global address list (GAL) is built.


The Exchange directory is comprised of two key elements: the directory database
and the directory service. The database engine is based on a highly optimized version
of the Access database engine, the blue-jet engine. This information store is located
by default in \EXCHSRVR\DSADATA\DIR.EDB.







CAUTION: Although Microsoft uses an Access database structure, you cannot
use Access to manipulate or view these tables. Using Access can destroy your Exchange
site. If you want to view this information, use Crystal Report Writer for Exchange
or a tool designed specifically to access the database.




The directory service (DS) is a Windows NT service that manages information in
the directory database and handles requests from users, services, and applications.


Users and administrators can access and manipulate directory services. The Exchange
administrator is responsible for creating, deleting, and changing directory objects
as well as for populating the address book. When a new object (recipient) is added
to the server, an entry is created in the server address book. This, in turn, is
propagated to the site and then to the global address book (GAL), where it is available
to all users in the organization. It is the responsibility of the DS to manage this
process and to ensure that the integrity of the directory and its structure is maintained.


Users access the directory through the Exchange server address book. Although
users cannot modify the address book, they can create custom subsets of entries of
the address book as well as create new entries in their own personal address book
(PAB). Exchange service processes can manipulate the database as well as third-party
applications such as Crystal Report Writer for Exchange Server.


An access control list controls access to Exchange Server directory objects. The
objects are assigned permissions when roles are established in the Administrator
program for each user or service. To view the dialog box that displays the roles,
select Tools | Options. Then select the Permissions tab from the Administrator menu
and check Display rights for roles on Permission Page.


After roles have been defined, the roles for directory services are displayed
in the Directory Service dialog box (see Figure 3.7). You do not always need to add
permissions to every object within the Exchange architecture because permissions
can be inherited from objects higher up in the hierarchy.


Figure 3.7. Directory services permissions display.


Objects within the Exchange X.500 directory structure are divided into distinct
groups with distinct properties such as organization, site, and configuration (see
Figure 3.8). This grouping permits permissions to be set based upon the group characteristics.
Just as with the NT server permissions, permissions are propagated downward in the
tree. This concept is known as inheritance. Because of inheritance, you must
consider the consequences of changing a role when you set permissions. You need to
understand the following rules before setting permissions in your organization:


  • Organization objectóWhen you set permissions at this level, it enables
    you to change the displayed organization name only. These permissions are not propagated
    downward.







NOTE: Although the Exchange Server enables you to change the organization
name, as with NT Server, this does not change the underlying name. The organization
name is tied to each object within the Exchange server. Changing the organization
name effectively invalidates all of the underlying objects. The correct procedure
to follow is to reinstall the Exchange Server.





  • Site objectóUsers with permissions at this level can modify site objects
    and all recipients within the site.



    An organizational administrator who assigns permissions for a user at this level
    can delegate administration. This assigns administrative permissions to the user
    for that site only unless explicitly assigned.



  • Configuration objectóUsers with these permissions can configure routing,
    replication, and other Exchange processes.




Figure 3.8. The Exchange organization structure.


Being able to dynamically assign permissions in Microsoft Exchange closely follows
those same capabilities within NT Server but should not be confused with NT Server.
An Exchange administrator does not have to be an NT Server domain administrator.
However, a person who supports both functions obviously has an administrative advantage.
When assigning permissions to a user, remember that when new accounts are created,
it is the responsibility of either the Exchange or the NT Server domain administrator
to create the accounts. To ensure no problems occur, assign appropriate permissions
ahead of time.

Information Store


The Microsoft Exchange information store connects the server and the client. You
can install either a private information store, a public information store, or both
on the server. The default is for both to be installed on the server. Each has a
16GB storage limit. Use the traffic and usage requirements of the organization to
determine how best to define server utilization.


The information store is also responsible for delivering mail to users on the
same server as the sender, and forwarding mail to the MTA for delivery to users who
are not on the same server.


The Exchange Server information stores are database files. They are based on a
fault-tolerant architecture with transaction logs used to process messages and support
rapid recovery in the case of system failures. Transactions are written to the transaction
logs and kept until the Exchange server is backed up. This permits data in the transaction
logs to be used to reconstruct data.


The concept of single instance store has also been introduced with Exchange
Server. Single instance store is defined as a single copy of a message sent to multiple
recipients and saved only once within the information store. Each user has a pointer
to the location of the message within the database.







NOTE: Because Exchange Server uses single instance store, the entire server
is restored when the default ntbackup utility is used to recover a single mailbox.
This is not a bug, but a result of the benefit of single-instance store. As an alternative,
you can use brick backup to back up individual mailboxes. However, using brick backup
can increase the storage requirements for backup by 50 percent or more. Several vendors
are currently working on brick-backup capability.









NOTE: When you install Exchange Server, the default ntbackup is replaced with
a custom version that is designed to support backing up the Exchange server while
it is in use.




Most features are common between private and public information stores. The most
important ones are discussed next. An overview of the information stores follows.

Common Information Store Features



  • RulesóThese can be used to modify how mail is processed in both the private
    and public store. These rules are stored as properties in the folders. There are
    three classifications of rules: Inbox, Out-of-Office, and Folder Assistant.



    All rules in Exchange are server-based. Even though rules are managed on the client,
    they are executed on the server. This ensures that the rules will execute even if
    the client is not actively logged into the server, as long as 1, there is no need
    to check client permissions or 2, the rules do not reference a .pst file. If this
    is the case, the rules will not execute until the Exchange client user interface
    is active and the client has accessed his mailbox.



    The folder assistant is a special case of rules that applies to public folders. Rules
    placed on public folders permit special processing of messages sent to these objects.




    The out of office assistant is another special case. It provides a mechanism to support
    the execution of rules when a user is out of the office. Although these rules can
    be executed from the Inbox Assistant, they are better managed in the out of office
    assistant.



  • ViewsóThe Exchange client can view the contents of folders in a number
    of formats. The view can be either a folder or a personal view. A view defines the
    fields displayed when the folder is first opened. When a pubic folder is created,
    the owner has the option of using the default view or defining a new view for users
    who access the folder. The view information is stored as properties in the folder.




    A folder's default view is modified from the Exchange client and can only be changed
    by the owner or a user with the necessary permissions.



  • FormsóForms are used to define the format in which data is either displayed
    or created in a folder. Most messages are created using a standard form, but custom
    forms can be created using the Electronic Forms Designer (EFD), which ships with
    Exchange. EFD is a subset of Visual Basic 4.0. It extends the standard forms capability
    of the Exchange client and can be used to create a send custom form and a request
    custom form.



  • FoldersóExchange uses folders to present and store information within
    the information stores. The concept of folders was first introduced in Windows 95
    (to the MS-DOS user, folders are directories.)



  • ReplicationóFolders can be replicated between servers in an Exchange organization.
    The Exchange Administration program controls this feature.



  • PermissionsóEach information store and folder within the information store
    has permissions. The permissions for the information store can only be assigned from
    the Exchange Administration program (see Figure 3.9.)

Figure 3.9. Private information store permissions.


  • AgingóInformation saved to folders on the Exchange server can be managed
    according to its age. For example, an item that is older than a specified number
    of days can be marked for deletion. This can be done for a single folder, for multiple
    folders, or for all folders within a site.



  • Use of ResourcesóThe administrator can view the amount of disk storage
    a folder in an information store is using (see Figure 3.10).

Figure 3.10. Public folder resources.

Private Store


The private information store contains the mailboxes for all users on the server.
Each server that supports mailboxes has at least one private store. When a new user
is added, the user's mailbox is created in the private store. Information about this
new mailbox is passed to the directory service, and the global directory is updated.
Global settings for the private information store such as aging, storage limits,
permissions, and use by mailbox are set from the Private Information Properties page
in the Exchange Administrator (see Figure 3.11)


Figure 3.11. Private information store properties.







NOTE: The personal address book (.PAB) file for each user is not maintained
in the private store as it was with Microsoft Mail. It is completely separate and
can reside in several places.




A default installation of the Exchange Server uses the private store to save messages.
This imposes a 16GB limitation on the size of the information store for all users.
Although this limitation can cause problems in some instances, it is not the only
method of saving messages. Users can also save their messages in personal folders,
.pst files located either on their local hard disks or in a designated area on the
file server. The choice of storage mechanism should be left to the requirements of
each organization.







NOTE: The Exchange Server has a 16GB limit per information store. This places
a 16GB limit on the size of each information store. You can create additional private
information stores on a server, but this is not recommended because administration
can become unwieldy.



You can use private storage (.PST) files to save mail messages and bypass the limitations
of the information store. Because you lose administrative control using .PST files,
it is up to the user to manage and back up the files unless they are saved in home
directories on the server.




In addition to user mailboxes, the private information store also contains other
addressable recipients such as distribution lists and custom recipients. A custom
recipient
is any object with an e-mail address that does not reside within the
Exchange organization.

Public Store

The public store is the other location on the Exchange server in which you can
store information. The primary difference between the public information store and
the private information store is how the data is saved and used. There are more options
available for the public information store than the private. Configurable options,
in addition to those already discussed, include the following:


  • Logons



  • General



  • Replication schedule



  • Folder replication status



  • Age limits



  • Permissions



  • Diagnostic logging



  • Server replication status



  • Instances




Information in the public stores is stored in folders that are shared among users.
The public store supports replication of these folders among Exchange servers.

Message Transfer Agent


The message transfer agent (MTA) is a standard component of an electronic mail
system that handles the routing, conversion, address mapping, and message transfer
between systems. In Exchange, the MTA handles the routing of messages between Exchange
servers, information stores, connectors, and gateways. It is a vital part of the
Exchange architecture.


The Exchange MTA is configured at the server level of the Exchange Administration
program (see Figure 3.12).


Figure 3.12. Exchange MTA configuration.


The Microsoft Exchange Server MTA can also be used to connect to X.400 MTAs that
comply with the ITU (formally CCITT) 1984 and 1988 recommendations. As with other
core components of the Exchange Server, the MTA is implemented as an NT service.


The MTA must have an accurate routing table in order to transfer mail between
systems. Normally, the routing table is rebuilt once a day. This parameter is configurable
and can be done manually from the Message Transfer Agent Property page. It is a good
idea to manually generate this new routing table when changes to any Exchange routing
component are made during business hours. This forces the new routing information
to be propagated to other servers within the site.

System Attendant


The system attendant's role is to support the maintenance of the Exchange server.
Without it, the other Exchange services do not run.


The system attendant checks the directory consistency on each server in the site
and performs updates as required. It also reclaims space from deleted directory objects.
If monitoring tools are created, the system attendant gathers information about the
services being monitored and delivers it to the tools. Additionally, the system attendant
monitors the state of the messaging connections between servers and responds to link
monitor mail. The system attendant can act as an agent for other applications to
support message tracking and accounting.


At preset times each day, the system attendant rebuilds the site routing table
and generates foreign e-mail addresses such as X.400, Internet Mail, and any gateway
for new recipients. Set configuration parameters for the system attendant from its
property page in the Exchange Administrator program. This page is in the container
area of each server in a site (see Figure 3.13).


Figure 3.13. Exchange server System Attendant.


As new users are added to the site, it is the system attendant's responsibility
to create the e-mail addresses.

Directory Synchronization


Directory synchronization is an optional Exchange service installed as an NT Server
service. It is used to synchronize the directories between systems using the Microsoft
Mail DirSync protocols such as Microsoft Mail 3.x and AppleTalk Mail.


The purpose of the directory synchronization protocol is to synchronize the directories
on all post offices in an MS Mail network. Servers participating in this process
can be either directory server post offices or directory requester post offices.
One post office in the organization must be designated as directory server.


The directory server collects the directory address update information from the
servers participating in the directory synchronization process. It compiles them
and issues new global address list (GAL) updates to all requester post offices.


The DirSync process is a scheduled process controlled by the Microsoft Mail Dispatch
and External programs.


The Exchange server can function as either the requester or server but not both.
Organizational requirements determine how it is used.


When directory synchronization is configured, the administrator must specify an
import and export container. The import container stores imported Microsoft Mail
addresses. The export container holds the Microsoft Exchange recipients to export
to Microsoft Mail.







NOTE: You can control what addresses are exported to MS Mail by setting trust
levels for all recipients. The only recipients that are exported are those with trust
levels equal to or lower than the trust level configured in the connector.





Key Management


The key management server is installed as a separate server within the Exchange
server organization. It supports advanced security features such as digital signature
and data encryption. Install this optional Exchange server component to manage security
information used to digitally sign and encrypt messages that are sent between users
within a Microsoft Exchange server organization.


Data encryption is the process of scrambling data to ensure it can be read only
by the person to which it is sent. Both encryption and decryption must be supported.
The key management server provides these advanced security features and supports
the following services:


  • Certifies public signatures and encryption keys



  • Creates both public and private encryption keys



  • Maintains backups of private encryption keys and public keys



  • Generates tokens



  • Maintains the original copy of the revocation list


Connectors


An organization with a single server requires no connectors unless it is connected
to other messaging transports. Connectors are used to transfer messages between sites,
organizations, and foreign systems. The Microsoft Exchange Server offers a number
of connectors to assist in building enterprise class networks, including the following:


  • Microsoft Mail Connector (PC)óIt is used to connect the Exchange server
    to existing Microsoft Mail networks. The MS Mail connector consists of three components:
    the Microsoft Mail connector interchange, the Microsoft Mail Connector post office,
    and the Microsoft Mail connector (PC) MTA.



    The Microsoft Mail interchange is an NT service that is installed with the Microsoft
    Mail connector. Its purpose is to route and transfer messages destined for a Microsoft
    Mail user between the Exchange server and the Microsoft Mail connector post office.
    The interchange also converts the message to and from MS Mail format for delivery.




    The Microsoft Mail connector post office (also, shadow or gateway post office) acts
    as an intermediary between the MS Mail network and the Exchange server. To the MS
    Mail network, it is an external post office.



    The Microsoft Mail connector (PC) MTA connects to and transfers messages between
    the Microsoft Mail connector post office and one or more MS Mail post offices.



    The Microsoft Mail connector combines the functions of the Microsoft External program
    with that of a gateway post office. In most cases, it can perform the functions of
    the MMTA and External programs. It can, in many cases, replace the Microsoft External
    program but it does not support remote Microsoft Mail clients.







NOTE: The shadow post office does not support local mailboxes or MS Mail clients.
To support MS Mail users in an Exchange environment, either use the Exchange client
or install an MS Mail post office.









NOTE: External is not required to talk to LAN-connected MS Mail post offices.
The MS Mail connector performs all functions of the External program. When connecting
to MS Mail post offices over X.25 service, the External program is required to complete
the connection at the distant end.





  • Microsoft Mail Connector (AppleTalk)óThis connector is used to
    support connectivity between the MS Mail for AppleTalk networks and the Exchange
    server. Unlike the Microsoft Mail (PC), the AppleTalk product uses a client/server
    system to store and transfer messages. An MS Mail AppleTalk gateway server is required
    to support this connector, in addition to the Exchange server and the following components:




    Microsoft Mail connector converts Exchange messages to and from MS Mail format and
    transfers messages to the MS Mail post office.



    Microsoft Exchange connection is the gateway program for the MS Mail (AppleTalk).
    It runs on the MS Mail (AppleTalk) server and acts as a hub to route messages to
    and from the Exchange server.



  • Internet Mail Connector(IMC)ópermits the Exchange server to send and receive
    SMTP mail and supports connection to the Internet.



    The IMC supports messages that are sent using both MIME and UUENCODE format. MIME
    supports rich text format (RTF). Configuration parameters are set to control how
    IMC processes outgoing messages.



    You can configure IMC to send mail attachments either UUENCODED or MIME. In addition,
    the IMC can be configured to send RTF data. By default, the server is configured
    to send RTF data only as specified by the Exchange user. This can be modified to
    never send or always send, thus overriding any changes the client might set.



    IMC can be configured to support outgoing traffic, incoming traffic, or both. Exchange
    organization can support more than one IMC. By installing more than one IMC and defining
    a cost for each connector, you can balance the traffic between connectors or specify
    alternate routes.



    IMC does not support smart-hosting but an add-on is included in the Exchange Technical
    Resource kit, IMCEXT.DLL, that allows creation of a rudimentary smart host.



    As with any SMTP host, an entry must be defined in the DNS server database to support
    routing of mail to the IMC. Information on how to do this is in the vendor's DNS
    Server documentation.







NOTE: When you are integrating the Exchange server in an MS Mail environment
that sends to MS Mail users via SMTP, turn MIME encoding off to avoid garbage at
the end of user messages.



The Internet Mail connector complies with IETF RFC 821, 822, 1123, 1521, and 1522.










NOTE: A smarthost mail server typically handles the routing of all messages
within a domain. The concept of a smarthost originated in the UNIX environment where
addressing and manipulation of mail headers is handled by a single server. This minimizes
the requirement to modify multiple servers and centralizes administration of the
domain database. Although it is not required in the Exchange environment, the functionality
is supported.





  • X.400óCan be used to support connectivity to existing X.400 backbones
    as well as between two Exchange sites and public network X.400 systems. The X.400
    connector supports communications with systems that conform to the ITU 1984 and 1988
    recommendations. These recommendations specify the structure and method used to transfer
    messages between X.400 systems.



    As with the other connectors, the X.400 connector is installed as a Windows NT service.
    It transmits messages to remote systems using either TP0/X.25, TP4/CLNP, or TCP/IP.




    Internally, Exchange uses an X.500 directory structure so all internal addressing
    is in X.400 format. This eases the need to establish X.400 addresses when you use
    this connector to communicate between Exchange sites because the addresses are automatically
    created by the system attendant.



    The X.400 connector can function as an X.400-relay MTA, as well as PRMD. PRMD MTA
    supports X.400 backboning and, in effect, bypasses the need to subscribe to a public
    X.400 provider such as MCI and AT&T to transfer messages.



  • Schedule+ Free/BusyóThis connector supports the distribution of Schedule+
    Free/Busy times between Exchange clients. Free/Busy information is readily distributed
    between servers and a user only has to access his home server to obtain this information.




  • SiteóThis connector is used to connect Exchange sites within an organization.
    Site connectors are used to provide the most effective connection between sites.
    They are used when connectivity between sites is over high-speed (128KB or higher),
    reliable LAN or WAN connections.



    Connection between sites is managed via a target server list on each server.
    This list contains the names of all available servers in the remote site. A natural
    fault tolerant condition can be created using the target server list. If an attempt
    to connect to the remote site using one of the servers in the target server list
    fails, the site connector attempts all other servers until a connection is established.




    A site connector can also have a bridgehead server. This is a server designated
    in the local site that handles all communications between the two sites.



  • Dynamic RASóYou use this connector when you are providing connectivity
    between Microsoft Exchange sites with no permanent connection. The Dynamic RAS connector
    provides a low-cost, scheduled method of supporting locations with low volumes of
    message traffic. It uses a dial-up connection to establish connectivity, to send,
    and to receive electronic mail messages.




Connectors are optional. An Exchange site with a single server has little need
for connectors unless they require access to resources outside of the site. After
you add another server or site, you must add a connector to support communications
between the sites.


Microsoft offers the Exchange server in two models: the Standard Edition, which
has no connectors, and the Enterprise Edition, which ships with all connectors. You
can also purchase connectors separately. To determine which model of Exchange to
install, examine the cost trade-offs between buying the Standard Edition with the
required connectors or the Enterprise Edition with all connectors.







NOTE: The Microsoft pricing model requires that when you are configuring a
multiserver organization supporting connectors, the connectors or licenses must be
for each server.





Schedule+



Schedule+ can function as a stand-alone product. However, when it is used with
the Microsoft Exchange Server, it extends the concept of group scheduling. The product
is tightly integrated with the Exchange client and with the Exchange server. It has
a hidden public folder, Schedule+ Free/Busy, that supports replication of user scheduling
among Exchange servers. This facilitates scheduling group meetings and managing static
resources such as conference rooms, audio/visual equipment, and vehicles.


The Exchange Server administrator needs to do very little to support Schedule+.
The Schedule+ Free/Busy Folder is at the organization level of the Exchange hierarchy
in the Folders|System Folders tree (see Figure 3.14).


Figure 3.14. The Organization | Folders | System Folders tree.


To display configurable parameters for Schedule+, highlight the displayed Schedule+
object and select File | Properties from the Administrator menu.


By default, the replication schedule for Schedule+ conforms to the schedule configured
for the information store, every 15 minutes. You can change this from the displayed
property sheet.

Exchange Forms Designer


The Exchange Forms Designer(EFD) is an optional component of the Microsoft Exchange
client. You use EFD to create and manage custom electronic forms. Its purpose is
to improve workgroup productivity by automating the distribution of repetitive information
and paper forms. When used in conjunction with public folders, electronic forms are
an easily implemented method of supporting shared applications such as Help Desk,
Discussion Groups, and Employee documentation.


EFD is a self-contained application based on Microsoft Visual Basic 4.0. It uses
an interface similar to VB4.0 to support the development of custom forms but has
custom object types available to add to the forms. A VB4.0 project file is created
when the application is saved, which enables the forms developer to extend the capabilities
of the generated code with VB4.0. This permits the developer to add functionality
not normally available in EFD by incorporating ActiveX (formally .OCX) code to perform
functions not supported in EFD.


Although EFD is considered a part of Exchange server, it is installed on a client
workstation. The components installed on the client fall into three categories:


Form Design Tools


  • Forms DesigneróThis tool is incorporated into the client user agent and
    launches the EFD Program.



  • Forms Template WizardóThis wizard is started from the Forms Designer menu.
    It is designed to lead the user through the development of the correct interface
    for his form. The default properties for the form are added before beginning the
    designer customization process.



  • Forms TemplatesóThese are a set of predefined templates that can be used
    as the basis for customizing forms applications.




Folder Design Tools


  • Exchange clientóThe client is an integral part of the design process.
    Because EFD is a messaging application, testing and installing the application is
    done from the client.



  • Folder Design Cue CardsóThese cue cards provide a step-by-step guide to
    designing applications with Electronic Forms Design

Sample Applications


The Exchange CDs contain a set of sample applications that describe the use of
public folders and custom applications in Exchange. These sample applications can
be used as guidelines to assist in constructing applications for deployment in the
organization.








CAUTION: Although the sample applications appear complete, they were designed
for demonstration only. Using them in a production environment is not suggested.





These applications can be installed in the user agent and used as examples to
construct production applications.


When the client is installed, the folder design tools are installed. The folder
design tools permit a user to customize any folder he may create, either private
or public.


The folder design tools are installed from a share area on the Exchange server.
The installation process adds the custom edition of Visual Basic 4.0 for Exchange
to the end user's desktop.

Summary


This chapter discussed the components of the Exchange Server and how they interact.


The Exchange Server has been considered among the most complex products Microsoft
has developed. This chapter attempts to shed some light on this complexity by presenting
an overview of each of the components that it includes.


Unlike its predecessor, MS Mail, the Exchange Server is built around both Industry
standard architecture and protocols. The server takes advantage of the strengths
and security of the NT Domain by providing single logon to the domain and the user
mailboxes. The internal services that comprise Exchange server, such as the Private
and Public Information Store and the Directory Service were also discussed.


Connectors, which provide gateway support as well as routing in the Exchange Server
were also reviewed.


The Exchange Server provides a lucrative development environment with its built-in
forms capability.


The information provided in this chapter can be used to provide the basis for
a detailed understanding of the Exchange Server and the capabilities it offers.






© Copyright, Macmillan Computer Publishing. All rights reserved.


Table of Contents






Microsoft Exchange Server Survival Guide -- Table of Contents


Microsoft Exchange Server Survival Guide






Table of Contents:



  • Introduction



  • Chapter 1 - Overview of Exchange and This Guide
  • Chapter 2 - Mail System Concepts
  • Chapter 3 - Server Components
  • Chapter 4 - Client Components
  • Chapter 5 - Administrative Concepts
  • Chapter 6 - System Requirements for Optimal Performance
  • Chapter 7 - Considerations for a Successful Rollout
  • Chapter 8 - Moving from Another Mail System
  • Chapter 9 - Installing Microsoft Exchange Server
  • Chapter 10 - Configuring Basic Server Operations
  • Chapter 11 - Installing Microsoft Exchange Clients
  • Chapter 12 - Configuring Exchange Clients
  • Chapter 13 - Connecting to Other Mail Systems
  • Chapter 14 - Connecting to Other Exchange Sites
  • Chapter 15 - Configuring Directory Replication
  • Chapter 16 - Directory Synchronization with Microsoft Mail
  • Chapter 17 - Exchange Messaging Security with Key Management Server
  • Chapter 18 - Mailboxes and Recipients
  • Chapter 19 - Directories and Distribution Lists
  • Chapter 20 - Maintaining Exchange
  • Chapter 21 - Monitoring and Preventing Problems
  • Chapter 22 - Diagnosing the Cause of a Problem
  • Chapter 23 - The Exchange Forms Designer
  • Chapter 24 - Third-Party Add-On Products



  • Appendix A - Understanding and Using LoadSim
  • Appendix B - Command Reference
  • Appendix C - Glossary





© Copyright, Macmillan Computer Publishing. All rights reserved.


Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews