Accepted Domains Facts

120
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.

description

Accepted Domains Facts

Transcript of Accepted Domains Facts

  • 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