-
1
Accepted Domains Facts
As part of the post installation process, you must configure
accepted domains. Accepted domains identify the SMTP namespaces
domains for which the organization sends or receives e-mail. There
are three types of accepted domains in Exchange 2007:
Type Description
Authoritative
A domain is considered authoritative if your Exchange
organization hosts mailboxes for recipients within the domain.
When you install the first Hub Transport server, the fully
qualified domain name (FQDN) for the forest root domain is
configured as an authoritative accepted domain.
If your external SMTP domain (for example mycompany.com) does
not match the FQDN of the forest root (such as mycompany.local),
you will need to add the external SMTP domain as an authoritative
domain.
Relay
A relay domain is a domain for which a server accepts mail but
is not authoritative. Messages are sent to the SMTP server, then
relayed to the authoritative domain. Allowing relay of mail to all
domains (known as an open relay) is not a good practice, and could
overload your server and result in your server SMTP server being
blacklisted. There are some occasions, however, when relay for
non-authoritative domains is necessary. In Exchange, you would
configure one of two types of relay domains:
An internal relay is an e-mail domain where some or all of the
recipients do not have mailboxes in the Exchange organization.
Internal relay is handled by Hub Transport servers. Examples of
situations that require an internal relay include:
o When your internal system deploys both Exchange and
non-Exchange mail servers. The internal relay allows routing to the
mailboxes on the non-Exchange systems.
o When you have two forests configured with GAL synchronization.
The internal relay allows routing of messages from one forest to
another.
An external relay is an e-mail domain where messages are routed
outside of the Exchange organization and outside of the perimeter
network. Messages are relayed by Edge Transport servers.
You should know the following about creating accepted
domains:
You must be an Exchange Organization Administrator to configure
accepted domains. It is recommended to configure accepted domains
on the Hub Transport server and populate them to the
Edge Transport server using the Edge Subscription process.
To create accepted domains, either use the New Accepted Domain
Wizard in the Exchange Management console, or use the
New-AcceptedDomain cmdlet in the Exchange Management Shell.
Use the -Name parameter to give the accepted domain entry a
name. Use the -DomainName parameter to identify the domain name.
Use the -DomainType parameter to identify the accepted domain type
(Authoritative, InternalRelay, or
ExternalRelay). Use the /MakeDefault option to specify that the
accepted domain is the default domain, meaning that it is
associated with outbound messages that have encapsulated
addresses for non-Exchange e-mail system interoperability.
o You don't have to set this parameter if you don't have to
interoperate with a non-Exchange e-mail system in your
organization.
-
2
o For the first accepted domain that is created in the
organization, the default value is $true. For subsequent accepted
domains, the default value is $false.
o You cannot modify a default accepted domain. If you want to
change the default accepted domain, you must create a new accepted
domain and set it as the default accepted domain in the Exchange
Management Shell using the /MakeDefault $true option.
Infrastructure Preparation Facts
Exchange 2007 uses Active Directory for authentication, storing
configuration data, recipient addressing, and message routing.
Active Directory has three partitions (also referred to as naming
contexts). Each partition holds different kinds of Exchange
data.
Component Description
Schema
The schema defines the rules for how objects are created
(classes) and the properties and bounds for object properties
(attributes). Installing Exchange 2007 extends (modifies) the
Active Directory schema by adding the following:
Classes to create Exchange-specific objects, such as agents and
connectors. Attributes to configure the Exchange-specific objects
as well as additional attributes for
existing objects such as users and groups.
Each domain controller and global catalog server in the forest
holds a replica of the schema.
Configuration partition
The configuration partition stores data that includes
information that includes AD site configuration, Exchange global
settings, transport settings, and mailbox policies. Configuration
information specific to Exchange is stored in a subfolder under the
configuration partition's Services container. It includes the
following:
Address lists Address and display templates Client access
settings Connectors Global settings E-mail address policies System
policies Transport settings
Each domain controller and global catalog server in the forest
holds a replica of the configuration partition.
Domain partition
The domain partition holds all data for individual users,
contacts, and mailboxes. As Exchange runs, it stores and modifies
data in the domain. The domain partition stores the largest amount
of information in a typical deployment.
Each domain controller holds a replica of the domain partition
for the domain for which it is authoritative while each global
catalog server in the forest holds a subset of the information in
every domain partition in the forest.
Before installing Exchange, make sure your Active Directory
structure meets the following requirements:
The domain controller that is the Schema Master must be running
Windows Server 2003 SP1 (or later). In each site where Exchange
Server 2007 will be installed, there must be at least one global
catalog server
running Windows Server 2003 SP1 (or later).
-
3
In each domain where Exchange Server 2007 will be installed,
there must be at least one domain controller that is running
Windows Server 2003 SP1 (or later).
For all domains in the Active Directory forest where Exchange
2007 is installed or where Exchange 2007 recipients exist, Active
Directory must be in Windows 2000 native mode or higher. To place
the domain in Windows native mode, you must remove any NT4 domain
controllers.
If the organization includes a previous version of Exchange, you
cannot have any Exchange 5.5 servers, and the organization must be
running in native mode.
Preparing and installing Exchange makes the following changes in
Active Directory:
Modifies permissions of existing Exchange 2000 or Exchange 2003
environments. Extends the schema to add Exchange classes and
attributes. Creates the Exchange organization. Creates
Exchange-specific objects and groups. Assigns permissions to groups
used by Exchange.
Running the Setup wizard during the Exchange server installation
makes all of the necessary Active Directory modifications as long
as the account you use has the proper permissions. However, in
large organizations, administrators with permissions to install
Exchange servers typically do not have the permissions necessary to
modify the schema or domain configuration. For the most granular
control over the Active Directory preparation process, and to
delegate these tasks to other administrators, run the Exchange
server Setup.com program (with specific switches) in the following
order, waiting for the changes to be propagated through Active
Directory before proceeding to the next step:
1. If you have an existing Exchange 2000 or 2003 configuration,
run Setup /PrepareLegacyExchangePermissions (or Setup /pl) to
modify the existing Exchange 2000 or Exchange 2003 permissions.
o If you are a member of the Enterprise Admins group, all
domains will be modified. o To run this command for a single
domain, include the domain name in the command. You must be
delegated the Exchange Full Administrator role and you must be a
member of the Domain Admins group.
o Run the command on a Windows Server 2003 SP1 (or higher)
server that can contact all other domains in the forest.
2. Run Setup /PrepareSchema (or Setup /ps) to extend the schema.
o You must be a member of the Schema Admins and Enterprise Admins
group to perform this step. o Run the command on a computer in the
same site as the Schema Master.
3. Run Setup /PrepareAD /OrganizationName: Name (or Setup /p
/on: Name) to create the organization, create global Exchange
objects, and prepare the local domain. If the Exchange organization
already exists, omit the /on switch.
o You must be a member of the Enterprise Admins group to perform
this step. o Run the command on a computer in the same domain and
site as the Schema Master and that can
contact all domains in the forest over port 389. 4. Prepare each
additional domain where you will have Exchange 2007 servers or
recipients. Use one of the
following methods to prepare additional domains: o Run Setup
/PrepareDomain (or Setup /pd) on each additional domain. You do not
need to run this
on the domain where you ran /PrepareAD. You must be a member of
the Domain Admins group in the domain to perform this command
if the domain that you are preparing existed before you ran
Setup /PrepareAD. You must be a member of the Exchange Organization
Administrators group and the Domain
Admins group in the domain if it was created after you ran Setup
/PrepareAD. o Run Setup /PrepareAllDomains (or Setup /pad) to
prepare every domain in the forest. You must be
a member of the Enterprise Admins group to run this command.
-
4
Note: The computer that is used to run Setup must have the
Microsoft .NET, Framework 2.0, and the Microsoft Command Shell
installed.
Perhaps the biggest consideration in deciding how to prepare
Active Directory is the permissions required to perform each
specific task. The following table summarizes the permissions
required for each:
Option Required Permissions
/PrepareLegacyExchangePermissions
Enterprise Admins group membership to modify all domains.
Delegated the Exchange Full Administrator role and Domain
Admins group membership to modify a single domain.
/PrepareSchema Schema Admins and Enterprise Admins group
memberships.
/PrepareAD
Enterprise Admins group membership if the schema is already
prepared.
Schema Admins and Enterprise Admins group membership if the
schema has not yet been prepared.
In addition, you must be an Exchange Full Administrator if there
are existing Exchange 2003 servers.
/PrepareDomain
Domain Admins group membership if the domain existed before you
ran /PrepareAD.
Exchange Organization Administrators group membership and Domain
Admins group membership if the domain was created after you ran
/PrepareAD.
/PrepareAllDomains Enterprise Admins group membership.
When you use Setup to prepare Active Directory for Exchange
server installation, be aware of the following special cases:
If you run the Setup wizard with appropriate permissions, the
following actions are performed: legacy permissions are modified,
the schema is extended, the organization is created, and the local
domain is prepared. This is the most efficient way to do the
preparation and the installation if you have all of the necessary
permissions.
Running /PrepareAD modifies legacy permissions and extends the
schema if those steps have not yet been performed (as long as you
are a member of the Schema Admins and Enterprise Admins
groups).
Running /PrepareSchema modifies legacy permissions if that step
has not yet been performed. Running /PrepareAllDomains is the most
efficient way to prepare domains for Exchange installation, but
requires membership in the Enterprise Admins group. Because you
can only create a single organization in a forest, you must create
a second forest to
accommodate two organizations. Run Setup /PrepareAD /on in each
domain to create the organizations. All domains with Exchange 2007
servers or recipients must be prepared. Domains are prepared for
Exchange
if you have run /PrepareAD or /PrepareDomain in the domain, or
if you run /PrepareAllDomains.
In addition to preparing Active Directory, you must have a good
DNS infrastructure prior to Exchange installation. Exchange Server
2007 uses DNS for the following:
An Exchange server contacts DNS to get service locator records
(SRV) to locate Active Directory domain controllers.
An Exchange server contacts DNS servers to retrieve MX (mailbox)
records and to locate SMTP domains. Edge Transport servers must be
configured as follows:
-
5
o The internal interface must be configured to resolve internal
addresses. o The external interface must be configured to resolve
Internet or public DNS names.
An Exchange server uses DNS to resolve hosts names, especially
when locating hosts on the Internet.
Exchange Management Console Facts
The Exchange 2007 Management Console is a graphic interface used
to manage an Exchange environment. It has been simplified from
previous versions of Exchange so it now focuses only on the most
commonly executed tasks. Additional tasks that could traditionally
only be performed in REGEDIT or ADSIEDIT were also added to the
Exchange Management Console to improve ease of use. You should know
the following about the Exchange Management Console:
In Exchange 2003, the information shown in the tree-pane was
dependent on the configuration of your Exchange Server. This pane
is now static in the Exchange 2007 Management Console so no matter
how many servers you have, what options have been chosen, or what
has been installed, the tree-pane will always be the same.
Many tasks can't be performed through the Exchange Management
Console, only through the Exchange Management Shell.
The Exchange Management Console can filter views.
The console tree is organized into nodes and sub-nodes which can
be expanded up to eight or more levels. The nodes in the console
are as follows:
Node Description
Microsoft Exchange node
The Microsoft Exchange node allows you to view the Finalize
Deployment and End-to-End Scenarios tabs. These tabs help you to
complete the required and optional configuration tasks for the
server roles you deployed.
Organization Configuration node
The Organization Configuration node configures global and
system-wide data for all servers and users in the Exchange 2007
organization.
Server Configuration node
The Server Configuration node configures the Exchange 2007
servers and their components such as protocols, databases, and
messaging records management.
Recipient Configuration node The Recipient Configuration node
manages the recipients in the Exchange 2007 organization.
Edge Transport node
The Edge Transport node is visible only from a computer that has
the Edge Transport server role installed and is used to manage your
organization's perimeter network.
Toolbox node
The Toolbox node contains the following tools:
Queue Viewer Exchange Server Best Practices Analyzer Database
Recovery Management Database Troubleshooter Performance Monitor
Performance Troubleshooter Mail Flow Troubleshooter Message
Tracking
-
6
Anti-spam and Antivirus Facts
Exchange 2007 has included multiple anti-spam and antivirus
agents to detect and reduce malware. The anti-spam agents work
cumulatively to reduce the amount of unsolicited e-mail that enters
an organization. The following table describes the various
components in the order in which they are applied.
Filter Description
IP Allow List The IP Allow List is an administrator-defined list
of IP addresses, IP address ranges, or IP address and subnet masks.
If an IP address or IP address range matches an entry on the IP
Allow list, the Connection Filter agent forwards the message to the
Sender Filtering process.
IP Block List
The IP Block List is an administrator-defined list of IP
addresses, IP address ranges, or IP address and subnet masks. If an
IP address or IP address range matches an entry on the IP Block
list, the Connection Filter agent drops the SMTP connection and the
message. You can set an expiration time for each entry on the IP
Block list. When the expiration time is reached, the entry is no
longer blocked.
IP Allow List Providers
IP Allow List provider services (often referred to as IP safe
lists or white lists) compile lists of IP addresses that are not
spam producers. When you configure a list provider, the Connection
Filter agent queries the list provider to see if the IP address is
on the approved list. If the list provider approves an IP address,
the Connection Filter agent forwards the message to the Sender
Filtering process.
IP Block List Providers
IP Block Provider services (often referred to as real-time block
lists or RBLs) compile lists of IP addresses from which spam
originates. The Connection Filter agent queries the IP Block List
provider service to see if the connecting IP address is on the
list. If it is, the Connection Filter agent drops the SMTP
connection and the message.
Sender Filtering
Sender Filtering compares a sender to an administrator-defined
list of senders or sender domains that are not allowed to send
messages to the organization. To block a sender, use one of the
following methods:
To block a single sender, use the format:
[email protected]. To block an entire domain, use the format:
*@.domainname.com. To block an entire domain and all subdomains,
use the format: *@*.domainname.com.
You can configure two different actions for a message from a
blocked sender:
Reject message deletes the message and sends a Non-Delivery
Report (NDR). Stamp message accepts the message, but labels the
message as having come from a
blocked sender.
Recipient Filtering
Recipient Filtering examines the recipient address to make
decisions about accepting or rejecting messages. Recipient
Filtering uses two data sources:
The Recipient Block List identifies specific recipients that are
blocked from receiving messages. Recipient Lookup compares the
recipient address with the list of valid recipients within your
organization. To use Recipient Lookup on an Edge Transport
server: 1. Subscribe the server to an Active Directory site. The
server can then search for
recipient information in the ADAM database. 2. In Recipient
Filtering, select the Block messages sent to recipients not listed
in the
Global Address List option. This compares the recipient address
with valid addresses within your organization.
Note: The Recipient Filter agent only performs lookups for
authoritative domains. An Edge Transport Server that is not
configured as authoritative but accepts and forwards messages for
another domain does not perform recipient lookups. It still blocks
non-authoritative recipients specified in the Recipient
-
7
Block List, though.
When the Recipient Filtering agent processes a recipient, it
will take one of two actions:
If the recipient does not exist in the organization, if it is on
the block list, or if it is prevented from receiving mail from the
Internet, a User unknown message is sent to the sending server.
If the recipient is enabled to receive Internet mail, is a valid
recipient, and is not on the block list, a Recipient OK message is
sent.
The automatic sending of responses to the sending server
regarding recipient status could allow spammers to stage a
directory harvest attack where messages are sent to common
recipients in your organization, looking for valid and active
accounts. To prevent the effectiveness of these attacks, Exchange
includes a feature called tarpitting. Tarpitting delays the return
of the status messages (by default 5 seconds), making automated
processing on the sending system difficult to implement. To
configure the response time, use Exchange Management Console or
Exchange Management Shell to set the TarpitInterval value on the
Receive connector.
Sender ID Filtering
Sender ID is designed to quell spoofing which occurs when a
spammer impersonates a legitimate sender and domain. Sender ID
depends on the IP address of the sending server, which is also
known as the purported responsible address (PRA). Sender ID uses
Sender Policy Framework (SPF) records published on DNS servers to
identify the valid mail senders for a specific domain.
When the Edge Transport server receives an incoming connection,
it queries the sender's domain for an SPF record.
If an SPF record exists, the Edge Transport server determines if
the sending server's IP address is authorized to send e-mail from
that domain.
You can configure the following actions to take if the sender
fails the checks:
Reject the message and send an NDR message to the sending
server. Delete the message and send a fake OK message to the
sending server. This prevents the
sending server from retrying message delivery. Stamp the message
with a Sender ID status and continue delivery. The Sender ID status
is
used by the Content Filtering agent to compute the Spam
Confidence Level (SCL). This is the default action.
Note: If the From: IP address is missing, the Sender ID status
cannot be set. In this case, Exchange continues to process the
message without updating the Sender ID, but the message is not
deleted or rejected.
Content Filtering
Content Filtering uses the Intelligent Message Filter, a
machine-learning technology that evaluates e-mail messages based
its knowledge of both legitimate and spam e-mail characteristics.
The Content Filter evaluates messages, calculates the likelihood of
the message's legitimacy, and assigns the message a Spam Confidence
Level (SCL) of 0-9, with 9 most likely being spam.
You configure the Content Filtering agent to take specific
actions on messages that reach a certain threshold value. If the
SCL is equal to or greater than the threshold value you can:
Quarantine the message on the server. Reject the message with a
rejection notification sent to the originator. Delete the message
without a rejection message being sent to the originator.
Note: The Intelligent Message Filter does not scan messages over
11 MB. Messages over 11 MB pass
-
8
through the Content Filtering agent without being processed.
You can further customize the Content Filter agent in the
following ways:
Allow Phrases are approved words or phrases. They automatically
get an SCL of 0. Block Phrases are unapproved words or phrases and
get an automatic value of 9. You can add SMTP e-mail addresses,
senders, and sender domains as exceptions to which
filtering does not apply. If you have a subscription on the Edge
Transport server, you can configure safelist
aggregation. Safelist aggregation collects the Safe Senders
List, Safe Recipients List, and trusted contacts from individual
Outlook users and aggregates (combines) these lists into a single
exception list to the Content Filtering rules.
Note: You can configure allowed recipients (exceptions) through
the Management Console. The only way to configure allowed senders
is by using the Set-ContentFilteringConfig cmdlet with either the
-BypassedSenderDomains or -BypassedSenders switches.
Sender Reputation
Sender reputation is determined using persisted data about the
IP address of the sending server. From this data, the system
generates a Sender Reputation Level (SRL). SRLs are calculated
using the following statistics:
HELO/EHLO analysis uses the HELO and EHLO commands to retrieve
information about the domain name or IP address of the sending SMTP
server. Spammers frequently forge the HELO/EHLO to use it for
malicious purposes.
Reverse DNS lookup submits the sending server's IP address to
DNS and compares the result with the domain name in the HELO/EHLO
command.
Previously calculated SCL ratings are used to identify servers
that send a high proportion of spam messages.
An open proxy test checks to see if the sending server is
configured as an open SMTP proxy. The Edge Transport server
attempts to connect back to itself from the sending SMTP server. If
the connection is successful, the sending server is identified as
an open proxy.
IP reputation anti-spam updates from Microsoft Updates is also
used to calculate the SRL.
The SRL is a number between 0 and 9 that indicates if a sender
is likely a source of spam. The closer to 9 the assigned SRL is,
the more likely the sender is a source of spam. When you configure
Sender Reputation, you set a threshold and a time duration.
The threshold identifies the SRL block value. For messages at or
above the threshold, the sender is added to the Blocked Senders
list. The action taken on the message depends on the settings for
Sender Filtering.
The duration time identifies how long the sender remains on the
Blocked Senders list.
Note: Sender reputation only takes effect after a sender has
sent 20 or more messages.
Attachment Filtering
Attachment filtering applies filters to e-mail attachments based
on MIME content type, file name, or file extension. Actions taken
by the filter include:
Reject the message and the attachment. In this case, the sender
receives a failure message. Silently delete the message and the
attachment without notifying the sender or recipient. Strip the
attachment but allow the message through. Stripped attachments are
replaced with a
text file that indicates the action take. This is the default
action.
As a best practice, you should avoid stripping attachments from
the following types of messages:
-
9
Digitally signed, as this invalidates the digitally signed
message. Encrypted, as this renders the message unreadable.
Rights-protected, as this renders the message unreadable.
Note: Messages and attachments that have been blocked and
attachments that have been stripped cannot be retrieved.
Antivirus Scanning
Virus scanning is performed by Forefront Security for Exchange
Server. When Forefront Security for Exchange detects an infected
message, it deletes the message, generates a notification, and
sends it to the recipient's mailbox. Exchange Server 2007 ships
with a 120-day trial version of Forefront Security for Exchange
Server. After 120 days, you must license it separately.
Additional antivirus defenses should be deployed to scan all
e-mails within your Exchange organization, both in transit and
those already in the store. Exchange provides support for antivirus
vendors through:
VSAPI which provides a standard method of accessing messages
within an organization. Transport agents which scan messages with
antivirus and anti-spam filters as they pass
through Hub and Edge Transport servers.
As a final step in securing your environment against viruses,
you should ensure that all individual computers have virus
protection running on them.
Outlook Junk E-mail
The Outlook Junk E-mail filter operates on client machines.
Messages are evaluated based on several factors (arrival time,
message content, message structure), including metadata collected
by the anti-spam filters (such as the SCL settings added to
messages). Individual users can customize settings to move messages
to the Junk E-mail folder or delete messages automatically. Users
can also create their own Safe and Blocked Senders lists, which
function in conjunction with the Safe Sender list aggregation.
Filtering Process Facts
As you troubleshoot mail delivery (or failure), it is important
to understand the order in which agents run and what happens when
specific conditions are encountered. Exchange 2007 uses the
following process to apply anti-spam filtering:
1. The Connection Filtering agent is the first agent to run. It
does the following: 1. If the sending server's IP address is on the
IP Allow list, the message is sent to the Sender Filtering
agent. Additional connection filters are not applied. 2. If the
sending server's address is not on the IP Allow list, the agent
checks the IP Block list. If the
sending server's address is on the list, the message is rejected
and no further processing takes place. 3. If the sending server's
address is not on either list, the agent checks the IP Allow List.
If the sending
server's address is on the allow list, the message moves to the
Sender Filtering agent. 4. If the sending server's address is not
on the IP Allow List, the agent checks the Real-Time Block
Lists
(RBLs) of the configured IP Block List providers. If the sending
server's address is on one of the RBLs, the message is
rejected.
2. If the message makes it through the Connection Filtering
agent, the message moves to Sender Filtering. o If the sender is on
the blocked senders list, the message is either rejected (deleted)
or stamped as
having come from a blocked sender. o If the sender is not on the
list, or if the message is stamped, the message moves to Recipient
filtering.
If Sender Filtering does not reject the message, the Recipient
Filter agent checks the Recipient Block List and also compares the
recipient to the list of valid recipients (if so configured).
o If the recipient is blocked or does not exist, Exchange
rejects the message and sends a response to the sending server.
-
10
o If the recipient is not blocked and exists, Exchange sends a
confirmation to the sending server and the message moves to the
next anti-spam agent.
If the message is addressed to multiple recipients, the blocked
or nonexistent recipients are removed and the message moves to the
next anti-spam agent.)
If the message still contains valid recipients, Exchange runs
Sender ID filtering. Depending on the configuration, the system can
reject, delete, or stamp the message and send it to the next
anti-spam agent. Prior to applying Content Filtering, the Content
Filter agent checks the following five conditions:
o The sender's IP address is on the Connection Filtering IP
Allow list. o The message recipient(s) are on the exceptions for
content filtering. o All recipients' mailboxes have the
AntiSpamBypassEnabled parameter set to $True. o All recipients have
the sender on their Outlook Safe Sender lists (updated to the Edge
Transport
server through safelist aggregation). o The sender is a trusted
partner or on the organization's list of senders that are not
filtered.
If any of the above conditions is true, the message is sent to
antivirus processing. If none of the conditions are true, content
filtering is applied, and the messages is assigned an SCL. Based on
the SCL, the following actions can occur:
o The message is deleted. o The message is rejected and a
rejection response is sent to the sending server. o The message is
quarantined.
If no action is taken, the message continues to the next
anti-spam agent.
If connection, sender, recipient, or sender ID filtering has
taken an action, then sender reputation filtering is activated.
o If less than 20 messages have been received from the sender,
the sender reputation filter takes no action.
o If more than 20 messages have been received, the sender
reputation filter assigns the sender an SRL.
If the rating level is at or above the threshold, then the
sender is temporarily placed on the Blocked Sender list, and the
action specified for Sender Filtering is applied to the message. If
the message is allowed, the message moves to the next anti-spam
agent.
If attachment filtering detects a content type that has been
blocked, it takes the configured action. If the attachments are
approved or stripped, the message moves to antivirus scanning.
After virus scanning, the message moves to the client where local
virus scanning is applied, and where the message is subject to the
scrutiny of the Outlook Junk E-mail folder threshold. If the
threshold is met or exceeded, the message is put in the Outlook
user's Junk E-mail folder. If it is not met, it is delivered to the
user's Inbox.
Anti-spam and Antivirus Configuration Facts
Be aware of the following when implementing anti-spam and
antivirus solutions:
Filtering is typically configured on Edge Transport servers.
However, you can also configure filters on Hub Transport
servers.
Filtering is controlled through various agents that run on
transport servers. o The Connection Filter agent applies IP
Block/Allow and IP Block/Allow List provider filters. However,
each feature can be enabled or disabled individually. o Each
remaining filter type has its own agent.
-
11
o By default, all agents are enabled on Edge Transport servers,
but disabled on Hub Transport servers. o To enable a filter agent
or feature, use a cmdlet similar to the following:
Set-ContentFilterConfig -Enabled: $true The specific cmdlet you
use depends on the filter type. For example, use
Set-IPAllowListProvider to enable the IP Allow List feature,
Set-IPBlockListConfig to enable the IP Block List, or
Set-RecipientFilterConfig to enable recipient filtering.
You must configure filtering settings on each Edge Transport
server individually. IP Block and Allow lists identify IP addresses
of servers that are blocked or allowed to send mail. They do
not
identify individual senders by e-mail address. Because IP Block
and IP Allow lists can be difficult to maintain, you should use
allow and block list providers
for connection filtering. o Use IP Allow lists to create
temporary exceptions to block list providers, such as when a sender
has
been incorrectly listed. o Use IP Block lists to temporarily
block senders until they can be added to the provider's list.
Outages or delays at the list provider can cause delays in
processing messages on the Edge Transport server, which in turn can
cause mailflow bottlenecks.
The only way to retrieve stripped attachments or attachments on
rejected or deleted messages is to resend the message. Be sure to
modify the filter settings before resending to allow the attachment
through.
To have messages written to a quarantine mailbox, best practice
dictates that you use the following steps: 1. Create a dedicated
quarantine storage group. 2. Create a dedicated quarantine mailbox
store. 3. Create a mailbox in the quarantine mailbox store. 4.
Delegate rights to the quarantine mailbox to the appropriate
personnel. 5. Create a profile in Outlook to view the messages. 6.
Enable message quarantine and designate the quarantine mailbox in
Content Filtering.
To use Safelist aggregation: o Run Update-SafeList for each
user. This cmdlet pulls Safelist information from the mailbox
and
stores it in Active Directory. Use pipelining to run the cmdlet
for all user mailboxes. For example:
Get-Mailbox | where {$_.RecipientType -eq
[Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox
} | Update-SafeList
The command must be periodically run to pull new information
from the Safe Senders list. To do this, create a script and use the
AT command to schedule the script to run on a schedule.
o Run the content filter agent on the Edge Transport server. o
The Edge Transport server must have an edge subscription to pull
the information from Active
Directory.
Use the following commandlets to configure Receive connectors in
the Exchange Management Shell:
Use Enable-AntispamUpdates to retrieve antispam updates from the
Microsoft Update Server. Use Get-AntispamUpdates to view the status
of antispam updates. Use Add-AttachmentFilterEntry to configure a
filter for a specific file or extension. Use Set-
AttachmentFilterListConfig to modify the action to take when a
matching attachment is found.
Exchange Recovery Methods
The table below compares the various availability and recovery
methods you can use with Exchange 2007.
Method Description
Deleted Item Retention
Deleted item retention allows deleted items to be recovered.
Deleted items only appear deleted to the user. However, a copy of
the item is maintained in the user's mailbox for a specified time
(14 days by default), allowing you to recover the item should that
prove necessary. To recover a message after
-
12
the retention period has passed, you must restore the mailbox
database and extract the required messages from the mailbox.
Deleted Mailbox Retention
Deleted mailbox retention flags a mailbox for deletion but
retains it for 30 days (by default) for recovery. The mailbox is
not available for access by users, but any time prior to the end of
the mailbox retention period, you can reconnect the mailbox to a
user object. You can also purge the mailbox (permanently delete it)
any time after marking it for deletion, or you can simply let the
mailbox retention period expire, at which point the system purges
it.
Server Redundancy
The mailbox server role is the only role that can be installed
in a failover cluster. To reduce the impact of disaster for the
remaining server roles, you should do the following:
For Client Access servers, add a server in each site to improve
access. Use a hardware or software load balancing solution for
server redundancy.
For Hub Transport servers, deploy multiple Hub Transport servers
in each site. Load balancing and failover are performed
automatically by Active Directory sending messages only to active
servers.
For Edge Transport servers, deploy multiple Edge Transport
servers in each site. Use multiple DNS MX (Mail Exchanger) records
for round robin DNS load balancing.
For Unified Messaging servers, deploy multiple Unified Messaging
servers and use round robin DNS.
Replication and Clustering
Exchange 2007 offers three types of replication and clustering
to maintain high availability:
Local Continuous Replication (LCR) provides data redundancy by
maintaining a copy of a storage group on a second set of disks on
the same server.
Single Copy Cluster (SCC) provides service redundancy by using a
single disk subsystem shared by multiple servers.
Cluster Continuous Replication (CCR) provides both service and
data redundancy by replicating data between two servers, each with
its own disk system.
Database Portability
The database portability feature allows you to mount a mailbox
database on any server in the same organization. This feature
derives from the concept that mailbox data, being non-server
specific, should be accessible despite the server on which it
resides. Database portability allows you to reduce the time it
takes you to recover from a disaster. If you must move a mailbox
database, the Outlook 2007 client and the Exchange 2007
Autodiscover feature allow users to connect to the mailboxes in the
new location automatically.
Dial Tone Recovery
Dial tone recovery allows you to create an empty (or dial tone)
database on a server to replace a failed database. This provides a
temporary mailbox users can access for sending and receiving mail
after a disaster. Users don't have access to messages prior to the
disaster until you merge the temporary database with the historical
database, but they do have immediate e-mail service.
Best practice dictates that you always try to recover to the
same server that the failed database is on because it's a simpler
process with fewer steps and a smaller margin of error. Keep in
mind that when you use a dial tone database, you lose the rules,
forms, views, and all other mailbox metadata in addition to the
messages. You can recover this data when you merge the two
databases.
Server Recovery
You can choose one of three recovery options in the event of a
server failure:
Rebuild the server. As long as the Active Directory directory
service is available, you can rebuild the server by performing a
new installation of Windows Server, then install Exchange 2007
using the /m:RecoverServer option. Complete the process by
restoring databases and server-specific configuration settings.
Restore the server. Use a full backup set (backups of System
State data, Exchange binary
-
13
files, data on the hard disks) to restore the server, followed
by a restore of your Exchange databases. This option can only be
performed on the same (or significantly similar) hardware.
Use a standby server. Maintaining standby servers with the
operating system and mission critical software installed allows you
to reduce the time it takes to replace (or rebuild) a damaged
server.
You can take the following additional steps to protect your
Exchange organization:
Perform regular backups at regular intervals, even if you employ
LCR or CCR. Store the log files on a RAID 1 disk, and store the
database files on a RAID 0+1 disk. Use multiple Mailbox servers to
minimize disaster impact even when you're using clustering and
replication.
Backup Types Facts
While Local Continuous Replication (LCR) and Cluster Continuous
Replication (CCR) can provide your system with a level of
protection by offering near-time copies of the running database,
they cannot replace regular database backups. Where LCR and CCR
offer fast recovery options, backups allow you to recover a
database to a past point in time, and protect against complete disk
or system failure or catastrophic failures that affect an entire
location.
The following table identifies the different types of
backups:
Backup Type Description
Full
A full backup:
Backs up the entire database including the log files. Purges the
log files. Reduces the amount of restore time, but requires the
longest amount of time for each backup.
You should know the following about full backups:
When restoring from a full backup, restore only the last full
backup. Most backup strategies combine periodic full backups with
incremental or differential backups
(but never with both at the same time).
Note: Best practice dictates that you perform daily full backups
if you do not run LCR or CCR. If you use a replication strategy,
best practice dictates that you perform weekly full backups.
Copy
A copy backup:
Backs up the entire database including the transaction logs.
Does not delete the log files.
You should perform a copy backup to get a copy of the current
data without interrupting the backup schedule. For example, you
might perform a copy backup before a restore or before you make
significant changes to your system such as installing a service
pack.
Incremental
An incremental backup:
Backs up only the transaction log files since the last time a
full backup or incremental backup was run.
Purges the log files. This means that each incremental backup
only backs up information that
-
14
has been changed since the last full or incremental backup.
You should know the following about incremental backups:
When restoring from an incremental backup, you restore the last
full backup and each incremental backup made since the full
backup.
Combining full with incremental backups gives you the quickest
backup strategy, but takes the longest to restore.
An incremental backup will not back up the .edb files. You
cannot do incremental backups if you use circular logging. Because
the incremental backup deletes the log files each time the backup
is done, this option
minimizes disk space used.
Differential
A differential backup:
Backs up the transaction log files since the last full backup.
Does not delete the log files.
You should know the following about differential backups:
When restoring from a differential backup, you restore the last
full back up and then the last differential backup.
Differential backups take a little longer to back up than
incremental backups, but restoration is faster.
You cannot do differential backups if you use circular
logging.
Note: When using third-party backup tools, the interaction of
the backup software with the log files might differ from the backup
types described here.
A backup strategy identifies the type and the frequency of
backup operations, as well as the operations necessary to restore
data. Acceptable backup strategies are:
Perform full backups every night. Perform a full backup each
week, with incremental backups every other day. Perform a full
backup each week, with differential backups every other day.
Note: Do not mix differential and incremental backups.
When choosing a backup strategy, consider:
The amount of time each day you have to devote to backups
(called the backup window). Because backup operations affect system
performance, most backups are performed at night during periods of
little or no activity. Depending on your system load, you might
find that you have a very short backup window each night, with
longer windows on weekends.
How quickly you need to be able to restore data in the event of
an incident. For example, restoring a full backup is the quickest
recovery method, followed by full with differential backups,
followed by full with incremental backups.
The effect of backup operations on the log files. Depending on
your requirements, you might want backup operations to purge the
log files to conserve disk space.
The amount of data you must recover in a disaster. For example,
if a day's loss of data is unacceptable, best practice dictates
daily backups.
-
15
Any recovery service level agreements (SLAs) in place.
Databases should not exceed a size that can be backed up within
the backup window and that meets SLA and user performance
requirements.
Client Access Server Deployment Facts
As you plan and implement the configuration of Client Access
servers in your network, be aware of the following:
You must have at least one Client Access server in your Exchange
organization, even if you only have internal Outlook users. The
Client Access server is used for features such as Autodiscover and
Availability.
You must have a Client Access server in each site where there
are mailboxes if you use anything but Outlook as the client
application.
If your Client Access server accepts connections for clients
whose mailboxes are on both Exchange 2007 and Exchange 2000/2003
servers, do not install the Mailbox role on the Client Access
server.
To allow clients to retrieve mail from the Internet, you must
allow the Client Access server to be contacted by Internet hosts.
The Client Access server must have a DNS A record.
The Client Access server must be a domain member. For this
reason, it should not be directly exposed to the Internet. Put the
Client Access server behind a firewall to protect it.
Open the necessary firewall ports to allow traffic to the Client
Access server: o Exchange ActiveSync, Outlook Anywhere, and Outlook
Web Access use port 80 for HTTP
connections. o Exchange ActiveSync, Outlook Anywhere, and
Outlook Web Access use port 443 for HTTPS
connections. o POP3 uses port 110. o IMAP4 uses port 143.
After the Client Access server has been installed, run the
Security Configuration Wizard to lock down the server. You will
need to import the Exchange 2007 role definitions before using the
Security Configuration Wizard.
IIS uses SSL to provide secure HTTP communications. By default,
the Client Access server uses a self-signed certificate for
SSL.
Outlook Web Access and ActiveSync can accept the self-signed
certificate. To support Outlook Anywhere, you must get a third
party certificate.
To use SSL with Outlook Anywhere, you must install the RPC over
HTTP component. Use Add/Remove Windows Components to do this.
When requesting a certificate, make sure you include all DNS
names for the server in the certificate. When you import the
certificate, be sure to import it into the computer's certificate
store (not the administrator's
certificate store). After importing the certificate, use the IIS
console to enable SSL on the virtual directories used by the
clients. Certificates can be enabled for use with POP3 and IMAP4 in
addition to Outlook Web Access and Exchange
ActiveSync.
Use the following cmdlets to manage certificates:
Use New-ExchangeCertificate to create a new self-signed
certificate or create a certificate request. You can also use the
Request New Certificate wizard in the IIS console to create a
certificate request.
Use Import-ExchangeCertificate to import the certificate that
you have received from your certification authority into the
machine's certificate store.
Use Get-ExchangeCertificate to view the certificates that are
stored in the local computer store. Use Enable-ExchangeCertificate
to specify which Exchange services will use a particular
certificate.
-
16
Client Access Server Facts
All access that is not done through a MAPI protocol is sent
through a Client Access server. Client Access servers are similar
to Exchange 2000 or Exchange 2003 front-end servers. E-mail clients
using a protocol such as HTTP, POP3, IMAP4, or services such as
Exchange ActiveSync or Outlook Anywhere, connect to a Client Access
server, and the Client Access server handles all communication with
the Mailbox server. The Client Access server uses the following
general process to communicate with the client and the Mailbox
server:
1. The e-mail client initiates a connection to the Client Access
server. 2. The Client Access server contacts a domain controller
and authenticates the user. 3. After authentication, the Client
Access server queries Active Directory to identify the location of
the user's
Mailbox server. 4. The Client Access server communicates with
the Mailbox server using RPC. 5. Data from the user's mailbox is
sent to the Client Access server. 6. The Client Access server
renders the data based on the type of client that has connected,
then sends the data
to the client.
You should be aware of the following regarding how the Client
Access server communication process works:
In most cases, the Client Access server is responsible for
rendering the mailbox data in a format compatible for the e-mail
client. This places a greater load on the Client Access server than
was required for front-end servers in previous Exchange versions.
If you are upgrading an existing Exchange server for use as an
Exchange 2007 Client Access server, it is important that the server
has the proper hardware requirements to be able to support the
increased processing demands.
An Exchange 2007 Client Access server can be configured as a
front-end server for an Exchange 2003 mailbox server. When this is
the case, the Client Access server acts like a front-end server;
mail data rendering occurs on the Exchange 2003 server.
Clients using Outlook Web Access (OWA) use one of the following
URLs to connect to the Client Access server:
o Exchange 2007 servers now use http://servername/OWA. o Clients
retrieving mail on Exchange 2000/2003 servers must use
http://servername/exchange. If
Exchange 2007 clients use this URL, they will be redirected to
the http://servername/OWA URL after authentication.
Communication between the e-mail client and the Client Access
server uses one of the following protocols: o RCP over HTTP or
HTTPS for Outlook Anywhere o HTTP or HTTPS for Outlook Web Access
and ActiveSync o POP3 (port 110) or IMAP (port 143) for other
clients
The Client Access server communicates with the Mailbox server
using one of the following protocols: o RPC for Exchange 2007
Mailbox servers o RPC over HTTP for Exchange 2003 servers
You must have a Client Access server in each Active Directory
site where you have Mailbox servers. The Client Access server
communicates only with Mailbox servers within its own site.
POP3 and IMAP clients use SMTP to send messages. To send mail,
these clients must be able to connect to a Hub Transport or an Edge
Transport server.
o If possible, clients should connect using port 587. This new
port allows for authentication before sending mail, and is used by
many ISP's to control who can send mail.
o Connections can also use port 25. Servers typically connect
using port 25.
Exchange Clients Facts
-
17
An e-mail client is a software application that supports
specific protocols and provides the user with an interface to a
server. Exchange Server 2007 supports the following e-mail
clients:
Client Application Description
Outlook
Microsoft Outlook is a desktop e-mail client application. You
can use Outlook to connect to Exchange servers, or to POP3 or IMAP
servers. Outlook is typically used in a corporate environment to
connect to an Exchange organization. When connecting to an Exchange
server within a firewall, Outlook uses RPC to communicate directly
to the Mailbox server.
Outlook Anywhere
Outlook Anywhere is a feature of Outlook that lets you use
Outlook to connect to Exchange through a firewall.
The client computer running Outlook Anywhere requires Windows XP
SP2 or higher. Outlook Anywhere connects to a Client Access server
using RPC over HTTP. You must manually enable Outlook Anywhere
support on the Client Access server.
Outlook Anywhere on the client lets you use Cache mode. With
Cache mode:
Messages are downloaded to the client computer. Messages are
available even when the client is not connected to the Internet.
You can reply to and compose new messages, even when a connection
to the Exchange
server is not present. When a connection is re-established, new
messages are downloaded and any composed
messages are sent.
Outlook Web Access (OWA)
Outlook Web Access (OWA) is a browser-based method of accessing
your mailbox. The client system only needs a compatible browser to
send and receive e-mail. For example, with OWA you can use a public
kiosk with an Internet connection and a browser to access your
mailbox.
The interface within the browser is similar to the Outlook
interface. Advanced features in OWA that mimic the Outlook
experience are available only with Internet
Explorer 6.0 or higher. When you install a Client Access server,
OWA is installed and enabled by default. Clients access mail using
the URL: http://servername/OWA.
Note: Outlook Web Access no longer provides access to public
folders in Exchange 2007. If you wish for Outlook to continue
having the ability to access public folders, you must maintain an
Exchange 2003 server within your organization.
Exchange ActiveSync
Exchange ActiveSync is a protocol used by Internet-enabled
mobile devices to send and retrieve Exchange data.
ActiveSync synchronizes e-mail messages, calendar items,
contacts, and tasks. With Direct Push, a connection is initiated by
the Exchange server and changes are sent to
the mobile device. This allows for notification of new mail
without the end-user having to initiate a connection with the
server.
With Remote Wipe, if the mobile device is lost or stolen, you
can issue a command remotely and all data on the mobile device will
be deleted.
ActiveSync is installed and enabled by default on the Client
Access server.
POP3/IMAP clients
E-mail clients that use POP3 or IMAP, such as Outlook, Outlook
Express, and Eudora, can connect to a Client Access server.
-
18
Clients communicate with the Client Access server using POP3
(port 110) or IMAP (port 143) for retrieving messages.
Clients use SMTP for sending mail. This means that clients do
not communicate with a Client Access server when sending mail.
When you install a Client Access server, POP3 and IMAP are
installed but disabled. You must enable these services to provide
access to these clients.
Clients must connect to a Client Access server in the same site
where their Mailbox server is located.
Be aware of the following regarding communication between the
e-mail client and the Client Access server:
Outlook clients inside the private network communicate directly
with the Mailbox server using RPC for both sending and receiving
mail. However, the Client Access server is still required for
features such as Autodiscovery and Availability.
All clients (except internal Outlook clients) use the Client
Access server for retrieving mail. POP3 and IMAP clients must
connect to a Hub Transport or Edge Transport server for sending
mail. This
connection uses SMTP over port 25 or 587.
Configuring Client Support
Depending on the client and the connection type, you might need
to perform configuration tasks on both the Client Access server and
the client. The following table describes the configuration tasks
required for each client.
Client Configuration
Outlook
Outlook is used by internal clients to send and retrieve mail.
Outlook uses RPC to communicate directly to the Mailbox server. A
Client Access server is used for the Autodiscover and Availability
services.
Configuring Outlook for internal clients requires no
configuration at the client or the Client Access server:
When you install a Client Access server, Autodiscover is already
configured for internal clients. After installing Outlook on the
client, when you run it for the first time it retrieves
configuration
information from the Autodiscover service and configures itself
for the user automatically.
Outlook Anywhere
Outlook Anywhere is a feature in Outlook that allows for
external access to the user mailbox. Outlook Anywhere communicates
with the Client Access server for mail access. To configure Outlook
Anywhere:
On the client, enable Outlook Anywhere and point it to use the
Client Access server. On the Client Access server, you must enable
Outlook Anywhere and configure an external
host name. The external host name is the DNS name that Outlook
Anywhere uses when connecting to the Client Access server.
o You can perform both tasks in the Management console. o Use
Enable-OutlookAnywhere to perform both tasks at once. Use Set-
OutlookAnywhere to change the external host name.
To use Autodiscover on external clients, you must also set an
external URL for additional virtual directories:
To configure the Offline Address Book, use
Set-OABVirtualDirectory -externalurl
-
19
https://mail.mycompany.com/OAB For Unified Messaging, use
Set-UMVirtualDirectory -externalurl
https://mail.mycompany.com/UnifiedMessaging/Service.asmx For
Exchange Web Services, use Set-WebServicesVirtualDirectory
-externalurl
https://mail.mycompany.com/EWS/Exchange.asmx
Outlook Web Access (OWA)
Outlook Web Access (OWA) provides browser access to e-mail. To
configure OWA:
The client only requires an Internet connection and a Web
browser. Although most browsers are supported, Internet Explorer
6.0 or later is required for certain advanced features or when
using redirection or proxy.
On the server, OWA access is enabled by default. To allow
Internet access, you must configure an external URL for the OWA
virtual directory (such as mail.mycompany.com/owa).
ActiveSync
ActiveSync is used by mobile devices to connect to Exchange
data. To configure ActiveSync:
Connect the client device to a Windows system and use the
Windows Mobile Device Center to configure connection
parameters.
On the server, ActiveSync is enabled by default. You must
configure an external URL for the /Microsoft-Server-ActiveSync
virtual directory (such as
mail.mycompany.com/Microsoft-Server-ActiveSync). You must also
complete the configuration for Autodiscover as noted above.
Note: To disable ActiveSync, use the IIS console to disable the
Web application.
POP3 or MAPI
To configure POP3 or MAPI access:
Configure the client application with: o The IP address or DNS
name of the Client Access server for receiving mail. The Client
Access server must be in the same site as the user's Mailbox
server. o The IP address or DNS name of a transport server for
sending mail. If the client is used
only internally, point it to a Hub Transport server. If it is
used from the Internet, point it to an Edge Transport server. If
possible, configure the client to use port 587.
On the server, you must start the POP3 or MAPI service. In
addition, you should change the service startup action to
Automatic.
o Use the Services MMC snap-in to perform both tasks. o In the
power shell, use Set-PopSettings, Set-ImapSettings, or Set-Service
to change
the service startup type, and Start-Service or Stop-Service to
start or stop the services. (For example, Start-Service -service
msExchangePOP3.)
o From a command prompt, use Net start or Net stop to start or
stop the service (for example Net start MSExchangeIMAP).
On the server, you can also modify the IP address and port
number used for POP3 or IMAP. Use Set-PopSettings or
Set-ImapSettings with the UnencryptedOrTLSBindings and SSLBindings
options to configure the IP address and port. After making these
changes, you must restart the service.
In addition to enabling and configuring access on the Client
Access server, you can control user access using specific client
applications through settings in the user mailbox. By default, all
access methods are enabled for all user mailboxes. Use the
Management console or the following cmdlets to manage client access
on a per-mailbox basis:
Use Set-CASMailbox to enable or disable specific access methods.
Use Get-CASMailbox to view the status of each method for all
users.
-
20
To configure settings for all users, use a command similar to
the following: Get-CASMailbox | Set-CASMailbox -owasenabled
$false.
Use the following cmdlets to manage the Autodiscover
service:
Use New-AutodiscoverVirtualDirectory to create a new
Autodiscover virtual directory if you have multiple domains in your
organization.
Use Remove-AutodiscoverVirtualDirectory to remove an existing
Autodiscover virtual directory. Use New-OutlookProvider to create a
new Autodiscover object within Active Directory. Use
Set-OutlookProvider to configure an existing Autodiscover object
within Active Directory. Use Get-OutlookProvider to query Active
Directory to view the information contained within the current
SCP
object which resides in Active Directory.
Use the following cmdlets to manage the Offline Address
Book:
Use Get-OABVirtualDirectory to return the information available
about the current configuration of an existing Offline Address Book
virtual directory on the Client Access server.
Use New-OABVirtualDirectory to create a new Offline Address Book
virtual directory on the Client Access server.
Use Set-OABVirtualDirectory to configure an Offline Address Book
virtual directory on the Client Access server.
Use Remove-OABVirtualDirectory to remove an existing Offline
Address Book virtual directory on the Client Access server.
Client Services Facts
Exchange server uses the following features to enable and
control client access through various client e-mail
applications:
Feature Description
IIS Virtual Directories
When you install a Client Access server, several virtual
directories are created in IIS. These virtual directories are used
by client applications and services to connect to the Client Access
server. Virtual directories include:
/Autodiscover is used by clients to retrieve information about
servers and services and retrieve user profile settings.
/EWS is used by the Exchange Web Services /Exchweb is used by
Exchange 2000/2003 clients /Exchange is used by Outlook Web Access
clients /Exadmin is used for administrator access to virtual
directories /Microsoft-Server-ActiveSync is used by ActiveSync
clients /OAB is used to access the Offline Address Book /owa is
used by Outlook Web Access to connect to Exchange 2007 servers
/Public is used by Outlook Web Access to access public folders
/UnifiedMessaging is used to support Unified Messaging features
Clients connect to the various services by including the virtual
directory name with the URL. For example, clients using Outlook Web
Access to connect to an Exchange 2003 mailbox use a URL such as
http://mail.mycompany.com/Exchange.
Internal and External URLs
For each virtual directory, you can configure both an internal
and an external URL to connect to the service.
-
21
The internal URL is used for communication within the Exchange
organization. During installation, the internal URL is created
automatically using an internal fully-qualified domain name based
on the servername and the domain, plus the appropriate virtual
directory. By default, internal clients connect automatically using
the preconfigured internal URL.
The external URL is the address that will be used by users to
access their accounts through an e-mail client outside of the
organization (through the Internet). The external URL (for example,
mail.company.com/owa) must be manually configured. To allow
Internet access to mail clients, you must configure the external
URL for the virtual directory on at least one Client Access
server.
Virtual directories exist in IIS. As an Exchange administrator,
you can use the Exchange Management console or the Management Shell
to manage the Exchange virtual directories. Some properties can
also be managed through the IIS console.
Redirection and Proxy
Client applications must be able to communicate with a Client
Access server in the same site where the Mailbox server resides. If
your organization includes multiple sites, you could simply enable
an Internet-facing Client Access server in each site and have
external clients connect to the server at that site.
In some cases, however, you might not want to provide an
Internet-facing Client Access server in each site, or you might
have users who connect to Client Access servers in sites other than
where their mailbox resides. When a Client Access server receives a
connection request from a user whose mailbox is in a remote site,
the following takes place:
If the Client Access server in the site with the mailbox is
configured with an external URL, the client request is redirected
to that Client Access server. The client communicates directly with
the Client Access server in that site.
If the Client Access server in the site with the mailbox is not
configured with an external URL, the first Client Access server
acts as a proxy for the client. Requests are forwarded from the
connecting Client Access server to the Client Access server in the
remote site. The remote Client Access server then contacts the
Mailbox server, and returns responses back to the first Client
Access server. The client remains connected to the first Client
Access server, and that server coordinates all communications with
the remote Client Access server.
Be aware of the following regarding redirection and proxy:
Redirection is only supported for Outlook Web Access (OWA)
clients. Proxying is not supported for POP3 and IMAP clients. POP3
and IMAP clients must connect to
a Client Access server in the same site as their Mailbox server.
ActiveSync clients can use proxying, or they should connect to a
Client Access server in the
same site as their Mailbox server. Both redirection and proxy
requires that Windows Integrated authentication is used. This
means
that the client must be a domain member. If a browser is used,
Internet Explorer 6.0 or higher must be used. For this reason, you
would not use redirection or proxy to allow OWA access from public
computers. If you rely on proxy or redirection, users can only
connect with computers that are domain members.
Autodiscover
In Exchange 2007, the Service Connection Point (SCP) object in
Active Directory contains the information for Exchange in the
organization. When an Outlook or ActiveSync client connects, it
queries Active Directory for the SCP object to retrieve service and
profile settings. When an internal client connects, the following
process takes place:
1. Outlook queries the SCP object in Active Directory.
-
22
2. The Client Access server returns the Autodiscover URL to the
client. 3. The client connects to Autodiscover using HTTPS. 4.
Autodiscover returns the addresses of services and profile
settings.
External clients connect using a slightly different process:
1. The client tries to query Active Directory. Because the
client is external, it can't communicate with Active Directory.
2. The client then tries one of two URLs to contact the
Autodiscover service: o
https://mycompany.com/autodiscover/autodiscover.xml o
https://autodiscover.mycompany.com/autodiscover/autodiscover.xml
3. If a connection is successful, Autodiscover returns the
addresses of services and profile settings.
Note: Both of these Autodiscover URLs use an SSL connection. For
this reason, it is important that you have a trusted third-party
certificate installed on your Client Access server so that those on
an external network can have access to the SSL connection.
Receive Connector Facts
A Receive connector is a logical object that controls the
inbound flow of SMTP messages from e-mail clients and servers, both
internally and from the Internet.
Receive connectors apply to specific servers, and control how
the server listens (and accepts) inbound mail. Receive connectors
for Hub Transport servers are stored in Active Directory beneath
the server object.
Receive connectors for Edge Transport servers are stored in
ADAM. During installation of a Hub Transport server, two Receive
connectors are automatically created: one for
receiving mail from clients, and a second (Default) for
receiving mail from other mail servers. During Edge Transport
server configuration, two Receive connectors are created: one for
receiving mail from the Internet, and a second for receiving mail
from internal mail servers.
Each Receive connector is configured to listen for messages sent
to a specific IP address and port combination from a range of IP
addresses. For each Receive connector on a server, the IP address,
port, and address range combination must be unique.
You can modify the default Receive connectors, or create new
ones to control message processing. For example, create custom
Receive connectors to:
o Assign specific servers to process messages received from
specific clients. o Configure special connectors to apply custom
features to specific source addresses, such as
message sizes, number of recipients, or number of inbound
connections allowed.
To configure Receive connectors, you must have the Exchange
Server Administrator role on a Hub Transport server, or be a member
of the local Administrators group on an Edge Transport server.
Receive connectors have the following properties:
Category Description
General
On the General tab, you can configure:
The connector name. The logging level. The fully qualified
domain name (FQDN). This is the value that will be supplied by the
server
in response to HELO and EHLO queries (requests to get the
attention of a mail server). By
-
23
default, the FQDN is the authoritative domain.
Network
Use the Network tab to configure the IP address, port, and
recipient IP address ranges.
You can configure multiple IP address and port combinations. You
can configure multiple IP address ranges. Use the following
formats:
o a.b.c.d to specify a single IP address. o a.b.c.0/24 to
identify a subnet address and a mask value using the mask bit
count. o a.b.c.0-255.255.255.0 to identify a subnet address and a
mask value.
The combinations of address, port, and recipient ranges must be
unique between all connectors on that server.
For Hub Transport servers, the two default connectors are
configured as follows: o The Client connector is configured to
listen on all assigned (local) IP addresses on
port 587. It will accept mail from all IP addresses
(0.0.0.0-255.255.255.255). o The Default connector is configured to
listen on all assigned IP addresses on port 25,
accepting mail from all IP addresses.
Authentication
Use the Authentication tab to identify the accepted method(s) of
authentication. On a Hub Transport server:
The Client connector accepts TLS, Basic with TLS, and Integrated
Windows authentication. The Default connector accepts TLS, Basic
with TLS, Exchange Server, and Integrated
Windows authentication.
Permission Groups
Permission Groups identify the clients and servers that are
allowed to use the connector. Permission Groups use the user
account or group membership to identify the type of user that is
connecting. Permission Groups have preset permissions. Permission
Groups are:
Anonymous users are unauthenticated users. Users or computers
who authenticate with the Anonymous user account belong to this
Permission Group.
Exchange users are all authenticated users. Exchange servers
include Hub Transport servers, Edge Transport servers,
Externally
Secured servers, and (on Hub Transport servers) other Exchange
Servers. Legacy Exchange Servers are members of the Exchange Legacy
Interop group and include
all Exchange 2000/2003 servers. Partners are identified by the
Partner Server account. Partners are members who belong to
identified domains when using Domain Security for
authentication.
Note: You cannot add or remove Permission Groups, modify how
members are identified, or change the preset permissions.
When you create a new connector, you select a connector type.
Authentication and Permission Group settings are configured based
on the type you choose. After the connector is created, you can
modify and customize all settings. The following table lists each
type:
Connector Type Description
Internet
Select the Internet type to accept mail from anyone on the
Internet or from Internet SMTP servers.
A Receive connector on an Edge Transport is automatically
configured to accept mail from all locations.
-
24
You can create a Receive connector on a Hub Transport server
using this option, but this configuration is not recommended.
This option uses TLS authentication and allows Anonymous
users.
Internal
Choose the Internal type to accept mail from Exchange servers.
Use this connector type when configuring cross-forest connectors or
to receive mail from a third party transfer server.
Both Hub Transport and Edge Transport servers are automatically
configured with a connector with this configuration to accept mail
from other Exchange servers.
During configuration, the port is automatically set to 25. TLS
and Exchange Server authentication is used. Allowed Permission
Groups are Exchange servers and Legacy Exchange Servers.
Client
Choose the Client type to accept e-mail from Exchange clients or
clients using POP3 or IMAP4.
The port is automatically set to 587. TLS, Basic with TLS, and
Integrated Windows authentication is accepted. The Exchange users
Permission Group is allowed.
Partner
Choose the Partner type to accept e-mail from partner
organizations.
TLS with Domain Security is used for authentication. The
Partners Permission Group is allowed. Following the configuration
of the Receive connector, you must use the Set-TransportConfig
cmdlet to identify allowed partner domains.
Custom Choose a Custom type to manually configure authentication
and Permission Groups during creation. Select this type when
configuring Receive connectors on an Edge Transport server to
accept mail from third party transfer servers, external relay
domains, or a Microsoft Exchange Hosted Services server.
Use the following cmdlets to configure Receive connectors:
Use New-ReceiveConnector to create a new Receive connector. Use
Get-ReceiveConnector to view the configuration information for an
existing Receive connector within the
Exchange organization. Use Set-ReceiveConnector to modify an
existing Receive connector. Use Remove-ReceiveConnector to delete
an existing Receive connector. Use Set-TransportConfig to identify
partner domains when using Domain Security.
Foreign Connector Facts
A Foreign connector is a logical object that controls the
sending of messages to non-SMTP mail systems or to fax systems.
Foreign connectors act much like Send connectors. Foreign
connectors use the following properties to control how mail is
sent:
The address space lists destination domains to which the
connector applies. Source servers are identified that can process
mail sent using the Foreign connector. Like Send connectors,
you can identify multiple source servers for availability or
load balancing. The drop directory identifies a file system
location where messages are placed awaiting retrieval by the
non-
mail system. The drop directory must be accessible to all source
servers as well as the foreign messaging server.
-
25
In addition, the Hub Transport server uses the Replay directory
to receive messages from a foreign system. The foreign system
places messages in the Replay directory. The transport server
checks this directory periodically for messages that it needs to
process.
Note: You cannot create Foreign connectors on an Edge Transport
server.
You must use cmdlets to create and manage Foreign connectors. Be
aware of the following regarding the drop directory:
The drop directory location is identified using two values: o
RootDropDirectoryPath is a server-wide value that identifies a
parent path that can store multiple
drop directories. By default, this value will be blank, which is
interpreted by Exchange to be the Exchange installation directory
(by default C:/Program Files/Microsoft/ExchangeServer).
o DropDirectory identifies the drop directory name. This value
can contain an absolute or a relative path. If it is a relative
path, RootDropDirectoryPath and DropDirectory are combined to get
the drop directory location. If it is an absolute path, the drop
directory path will be used (however, the root drop directory must
not be specified).
When you create a new Foreign connector, the DropDirectory name
will be the same as the connector name (unless you explicitly
configure it).
Each Foreign connector uses its own drop directory. The foreign
system must be configured to retrieve messages from the drop
directory. When you create the Foreign connector, the file system
directory will not be created. You must create the
directory before or after defining the Foreign connector. If you
change the drop directory location used by the Foreign connector,
the new directory must exist or be
manually created. You must also manually move any items from the
old directory to the new directory. You can configure a UNC path or
a local path for the root drop directory.
Use the following cmdlets to configure Foreign connectors:
Use New-ForeignConnector to create a Foreign connector. Use
Get-ForeignConnector to view the configuration information for a
Foreign connector. Use Set-ForeignConnector to modify a Foreign
connector, including the DropDirectory path. Use
Remove-ForeignConnector to delete a Foreign connector. Use
Set-TransportServer to set the RootDropDirectoryPath or the Replay
directory for the server.
Send Connector Facts
A Send connector is a logical object that controls the delivery
of mail sent from an Exchange server to another mail server (both
Exchange and non-Exchange servers).
Send connectors apply to all servers in the organization and are
therefore stored in Active Directory beneath the Exchange
organization.
When you install a Hub Transport server, no Send connectors are
created. Instead, implicit Send connectors are automatically
computed as required for internal mail delivery.
When you configure an Edge Transport server for end-to-end mail
flow, two Send connectors are created automatically (if they do not
already exist) to allow sending mail to the Internet and sending
mail to internal mail servers.
Each connector is configured with a list of domain names.
Servers use connectors to identify how to deliver messages to the
listed domains.
In addition to the connector name, logging level, and FQDN, you
can configure the following properties for a Send connector.
-
26
Category Description
Address space
The address space identifies the destination SMTP domains for
which the Send connector will be used. When a server needs to send
mail, the domains in available connectors are examined. The
connector with the best domain match is then used. You can list
individual domains, or use one of the following conventions:
Use * to designate all domains. A Send connector on an Edge
Transport server is created to send mail to Internet hosts with *
as the address space.
Use *.domain.domain to identify all subdomains of the listed
domain.
Using the Management Console, you can only configure the domain
names, and the connector will use SMTP as the transport type. Using
cmdlets you can:
Add a cost to the address space. The cost is used to select a
connector when two connectors equally match the destination
domain.
Set the connector scope so that the connector can only be used
by Hub Transport servers within the same site. By default,
connectors are used by any Hub Transport server in the
organization.
Network
The Network tab identifies where to send message when the
connector is used. Messages are forwarded in one of two ways:
When DNS MX records are used, the transport server queries DNS
to locate an MX record that is authoritative for the destination
domain. The message is then forwarded to the mail server.
When a smart host is used, messages are forwarded to another
mail server for delivery. For example, you might forward all
outbound Internet mail to a mail server located at your ISP.
When using a smart host, you can configure the authentication
that will be used to communicate with the smart host. When using
DNS, you have the option of using Domain Security for
authentication.
Source Server
The Source Server tab identifies transport servers that are
responsible for processing mail sent to the connector. Connectors
use the address space, network, and source server settings as
follows for sending mail:
1. When a transport server receives mail, it checks applicable
Send connectors to find the connector that best matches the
destination domain.
2. Once the appropriate connector is identified, it uses the
list of source servers to locate a transport server that is
responsible for the connector.
3. If the mail server is listed as a source server, or if the
source server is in the same site, the message is forwarded to the
source server. Otherwise, the message is forwarded to a Hub
Transport server in a site with a source server, and then forwarded
again (if necessary) to a source server.
4. The source server uses either DNS to deliver the message to a
mail server that is authoritative for the domain, or it forwards
the message to a listed smart host.
You can list multiple source servers to provide for redundancy
and load balancing. If more than one source server is listed, the
closest source server (using Active Directory sites) will be used.
If multiple source servers are in the same site, message processing
will be shared by all listed servers.
Permissions Send connectors have a limited set of permissions
that control how headers are handled in outgoing mail.
-
27
Permissions identify specific header characteristics. If the
header characteristic is not allowed, the header is stripped from
the message before
forwarding. Send connector permissions can only be set through
cmdlets.
Linked Receive connectors
A linked connector is a Send connector that is linked or
associated with a Receive connector. When a server with a linked
connector uses a Receive connector to accept inbound mail, it will
use the linked Send connector to forward the message without using
any other selection criteria. Linked connectors can only be
configured through cmdlets.
When you create a new Send connector, you choose from the
following types. The connector type automatically configures some
of the network and source server settings.
Connector Type Description
Internet Choosing the Internet type configures * as the address
space. This configuration typically uses Edge Transport servers as
source servers to relay messages to the Internet.
Internal
Choosing the Internal type configures the connector to use a
smart host for message relay.
Hub Transport-to-Hub Transport servers use implicit Send
connectors for sending internal mail. A Send connector using an
Edge Transport server as a source server and Hub Transport
servers as smart hosts routes inbound Internet mail to the
internal organization. Choose the Internal type to configure an
Edge Transport server to relay mail to an Exchange
2003 bridgehead server, or to configure a Hub Transport server
to relay to bridgehead servers in the same forest.
Partner Choosing the Partner type configures the connector to
use DNS lookup with mutual TLS for authentication. The
Set-SendConnector -RequireTLS command enforces that messages are
only sent when a TLS connection has been established.
Custom
Choosing the Custom type lets you change all connector
properties during connector creation. Select this type to:
Manually configure Send connectors with Edge Transport servers
and the Exchange organization.
Configure Send connectors to Hub Transport or bridgehead servers
in other forests. Send mail to a third party transfer agent or an
external relay domain.
Use the following cmdlets to configure Send connectors:
Use New-SendConnector to create a new Send connector. Use
Get-SendConnector to view the configuration information for an
existing Send connector. Use Set-SendConnector to modify an
existing Send connector. Use Remove-SendConnector to delete a Send
connector.
Storage Management Facts
To create a storage group, the account you use must be delegated
as the Exchange Server Administrator role and local Administrators
group for the target server. Use the following commands to manage
storage groups in the Exchange Management Shell:
-
28
Use New-StorageGroup to create a new storage group or a new
recovery storage group on a Mailbox server. Use Get-StorageGroup to
view the information about the storage group that was created. Use
Remove-StorageGroup to delete a storage group. Use Set-StorageGroup
to set a storage group's attributes in Active Directory directory
service. Use -
CircularLoggingEnabled with a value of $true to enable circular
logging (the default value is $false). When using circular logging,
you should only perform full ba