Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2012-03-08
This guide is written for the IT administrator responsible for securing the Microsoft Exchange Server 2010 deployment and is designed to help the IT administrator understand and manage the overall security environment where Exchange is installed.
In the past, for each version of Microsoft Exchange, the Exchange team has published stand-alone security hardening guides with permission and security information. This approach made sense for locking down services and directories after Exchange 2010 Setup ran. However, starting with Microsoft Exchange Server 2007, Exchange Setup enables only those services that are required by the server role that's being installed. Microsoft Exchange is no longer installed and then hardened for security. It's designed to help you be more secure by default.
Therefore, unlike earlier versions of Microsoft Exchange where IT administrators had to perform multiple procedures to lock down their servers that were running Microsoft Exchange, Exchange 2010 requires no lock-down or hardening.
Scope
Exchange 2010 was developed using Microsoft Security Development Lifecycle (SDL) principles. A security review was performed for each feature and component. Carefully chosen default settings ensure a more secure deployment. The scope of this guide is to inform administrators about security-related features and the features that may affect security considerations. This guide links to security-related topics in Exchange 2010 documentation. These topics are listed in Appendix 1: Additional Security-Related Documentation. This guide doesn't cover any steps to harden the Windows Server operating system.
Contents
The Exchange 2010 Security Development Lifecycle
Network Port Usage and Firewall Hardening
Throttling Parameters and Client Throttling Policies
Secure/Multipurpose Internet Mail Extensions (S/MIME)
What's New
Exchange 2010 includes the following new security features:
- Role-Based Access Control Exchange 2010
includes a new role-based access control model that lets your
organization granularly manage permissions assigned to different
stakeholders such as recipient administrators, server
administrators, records and discovery managers, and organization
administrators.
- Throttling Policies Exchange 2010
introduces throttling mechanisms on Mailbox, Client Access, and
Transport servers to protect your organization from denial of
service attacks and reduce the impact of such attacks.
- Federated Delegation Exchange 2010
introduces new federated delegation features that enable you to
allow your users to securely collaborate with users in external
organizations. Using federated delegation, users can share their
calendar and contacts with users in external federated
organizations. Cross-forest collaboration is also made possible,
without the need to set up and manage Active Directory trust
relationships.
- Information Rights Management Exchange
2010 includes new information protection and control features that
enable you to protect sensitive message content at multiple levels
while maintaining your organization's ability to decrypt, search,
and apply messaging policies to protected content.
- No Security Configuration Wizard In
Exchange 2010, Setup makes the configuration changes necessary to
install and enable only those services required for a particular
Exchange server role and to limit communication to only those ports
required for the services and processes running on each server
role. This removes the need for tools such as the Security
Configuration Wizard (SCW) to configure these settings.
The Exchange 2010 Security Development Lifecycle
In early 2002, Microsoft introduced the Trustworthy Computing initiative. Since Trustworthy computing was introduced, the development process at Microsoft and in the Microsoft Exchange team has focused on developing software that helps you become more secure. For more information, see Trustworthy Computing.
In Exchange 2010, Trustworthy Computing was implemented in the following core areas:
- Secure by design Exchange 2010 was
designed and developed in compliance with The Trustworthy Computing Security Development
Lifecycle. The first step in creating a more secure messaging
system was to design threat models and test each feature as it was
designed. Multiple security-related improvements were built into
the coding process and practices. Build-time tools detect buffer
overruns and other potential security threats. No system can
guarantee complete security. However, by including secure design
principles into the whole design process, Exchange 2010 is more
secure than earlier versions have been.
- Secure by default One goal of Exchange
2010 was to develop a system in which most network communications
are encrypted by default. Except for Server Message Block (SMB)
communications and some Unified Messaging (UM) communications, the
goal was met. By using self-signed certificates, the Kerberos
protocol, Secure Sockets Layer (SSL), and other industry standard
encryption techniques, almost all Exchange 2010 data is protected
on the network. In addition, role-based setup makes it possible to
install Exchange 2010 so that only the services, and the
permissions related to those services, are installed with a
specific and appropriate server role. In earlier versions of
Microsoft Exchange, all services for all functionality had to be
installed.
- Anti-spam and antivirus
functionality Exchange 2010 includes a suite
of anti-spam agents that run at the perimeter network on the Edge
Transport server role, and can also be installed on the Hub
Transport server role residing on the internal network. Antivirus
functionality is further improved by the addition of
Microsoft Forefront Protection 2010 for Exchange Server as a
Microsoft solution.
- Secure in deployment As Exchange 2010
was developed, the pre-release version was deployed in the
Microsoft IT production environment. Based on the data from that
deployment, the Microsoft Exchange Server Best Practices
Analyzer has been updated to scan for real-world security
configurations, and pre-deployment and post-deployment best
practices have been documented in the Exchange 2010 Help.
In the past, permission management was documented and delivered after the core documentation was finished. However, we know that permissions management isn't an add-in process. It should be built into the overall planning and deployment of your Exchange 2010 deployment. Therefore, we've streamlined our permission documentation and integrated it into the core documentation to provide seamless context for administrators as they plan for and deploy their administrative model. Exchange 2010 includes a new role-based permissions model that allows you to grant granular permissions to administrators and users to enable them to perform tasks with the minimum permissions required.
- Communications Now that Exchange 2010
is released, the Exchange team is committed to keeping software
up-to-date and you informed. By keeping your system up-to-date with
Microsoft Update, you can make sure that the latest security
updates are installed in your organization. Exchange 2010 also
includes anti-spam updates. In addition, by subscribing to the
Microsoft Technical Security Notifications, you
can keep up with the latest security issues in Exchange 2010.
Getting Secure—Best Practices
Some basic best practices will help you create and maintain a more secure environment. Generally, running analyzer tools periodically and keeping software and antivirus signatures files up to date are the most effective ways to optimize your Exchange 2010 environment for security.
Setup and Installation Recommendations
These best practices will help you create a more secure Exchange 2010 environment:
- Delegate Setup The first Exchange 2010
server you install in your organization requires that the account
you use to run Setup must be a member of the Enterprise
Administrators group. The account you use is added to the
Organization Management role group created by Exchange 2010 Setup.
You can use delegated setup to allow administrators who aren't
members of the Organization Management role group to set up
subsequent servers. For more details, see Provision Exchange 2010
Server and Delegate Setup.
- File system permissions Exchange 2010
Setup assigns the minimum required permissions on the file system
where Exchange binaries and data are stored. You must not make any
changes to the Access Control Lists (ACLs) on the root folders and
the Program Files folder on the file system.
- Install paths We recommend that you
install Exchange 2010 binaries on a non-system drive (a volume
other than where the operating system is installed). Exchange
databases and transaction logs can grow rapidly, and must be
located on non-system volumes sized for capacity and performance.
Many other logs generated by different Exchange components, such as
transport logs, are also stored in the same install path as
Exchange binaries and can grow significantly, depending on the
configuration and your messaging environment. In Exchange 2010, the
maximum size of many log files and the maximum storage space a log
file folder can occupy is configurable, and is set to a default of
250 Megabytes. To prevent a potential system outage because of low
disk space, we recommend that you assess the logging requirements
for each server role and configure the logging options and log file
storage locations to meet your requirements.
- Blocking legacy Outlook clients Based
on your requirements, you can configure Outlook client blocking to
block legacy Outlook client versions. Certain Exchange 2010
features, such as Outlook Protection Rules and Personal Archives,
don't support legacy Outlook clients. For more information about
Outlook client blocking, see Configure Outlook Client
Blocking.
- Decoupling SMTP addresses from
usernames By default, Exchange generates
e-mail addresses and aliases based on the mailbox user's username.
Many organizations create an additional e-mail address policy to
decouple user e-mail addresses from usernames for added security.
For example, if the user Ben Smith's username is bsmith and the
domain is contoso.com, the primary e-mail address generated by the
default e-mail address policy is bsmith@contoso.com. You can create
an additional e-mail address policy to generate e-mail addresses
that don't use the user's alias or username. For example, creating
an e-mail address policy to use the template
%g.%s@domaingenerates e-mail addresses in the format Firstname.Lastname@domain. For the user Ben Smith, the policy will generate the address Ben.Smith@contoso.com. Or, you can decouple e-mail addresses from usernames by specifying an alias that's different from the username when you create or enable a mailbox.
Note:If a user's primary SMTP address doesn't match the UPN on the account, the user can't use their e-mail address to sign in to Microsoft Office Outlook Web App and must provide a username using the DOMAIN\username format. When using Microsoft Outlook, the user must provide the username in DOMAIN\username format if prompted for credentials when Outlook connects to the Autodiscover service.
Microsoft Update
Microsoft Update is a service that offers the same downloads as Microsoft Windows Update—plus the latest updates for other Microsoft programs. It can help you keep your server more secure and performing at its best.
A key feature of Microsoft Update is Windows Automatic Update. This feature automatically installs high-priority updates that are critical to the security and reliability of your computer. Without these security updates, your computer is more vulnerable to attack from cyber-crooks and malicious software (malware).
The most reliable way to receive Microsoft Update is to have the updates delivered automatically to your computer by using Windows Automatic Updates. You can turn on Automatic Updates when you sign up for Microsoft Update.
Windows will then analyze the Microsoft software that's installed on your computer for any current and past high-priority updates it requires and then download and install them automatically. After that, when you connect to the Internet, Windows repeats the update process for any new high-priority updates.
To enable Microsoft Update, see Microsoft Update.
The default mode of Microsoft Update requires that each Exchange server is connected to the Internet to receive automatic updates. If you are running servers that aren't connected to the Internet, you can install Windows Server Update Services (WSUS) to manage the distribution of updates to computers in your organization. You can then configure Microsoft Update on the internal Microsoft Exchange computers to contact your internal WSUS server for updates. For more information, see Microsoft Windows Server Update Services 3.0.
WSUS isn't the only Microsoft Update management solution available. For more information about Microsoft security releases, processes, communications and tools, see the Microsoft Security Update Guide.
Tasks No Longer Required in Exchange 2010
It's no longer necessary to install or run the following tools:
- The URLScan security tool isn't required for IIS 7. In earlier
versions of Microsoft Exchange, it was a common practice to install
IIS tools such as URLScan to secure an IIS installation. Exchange
2010 requires Windows Server 2008, which includes IIS 7. Many of
the security features that were originally available in UrlScan are
now available in the IIS 7 Request Filtering features.
- You no longer need to install the Exchange Best Practices
Analyzer. In earlier versions of Microsoft Exchange, it was a
common practice to install and run the Exchange Best Practices
Analyzer before installation and regularly after that. Exchange
2010 Setup includes the Exchange Best Practices Analyzer components
and runs them during setup. It isn't required to run the Exchange
Best Practices Analyzer before setup.
- You no longer need to use the Security Configuration Wizard
(SCW) or the Exchange templates for SCW. Exchange 2010 Setup
installs only those services required for a given Exchange server
role, and creates Windows Firewall with Advanced Security rules to
open only the ports required for the services and processes for
that server role. It's no longer required to run the Security
Configuration Wizard (SCW) to do this. Unlike Exchange Server 2007,
Exchange 2010 isn't included with SCW templates.
Staying Secure—Best Practices
These best practice recommendations will help you keep your Exchange 2010 environment secure.
Keeping Software up to Date
As mentioned in an earlier section, running Microsoft Update is a best practice. In addition to running Microsoft Update on all servers, it's also very important to keep all client computers up to date and to maintain antivirus updates on all computers in your organization.
In addition to Microsoft software, make sure that you run the latest updates for all software that's running in your organization.
Anti-Spam Updates
Exchange 2010 also uses the Microsoft Update infrastructure to keep the anti-spam filters up-to-date. By default, with manual updates, the administrator must visit Microsoft Update to download and install the content filter updates. The content filter update data is updated and available every two weeks.
Manual updates from Microsoft Update include the Microsoft IP Reputation Service or spam signature data. The Microsoft IP Reputation Service and spam signature data is only available with Forefront Security for Exchange Server anti-spam automatic updates.
For more information about how to enable Forefront anti-spam automatic updates, see Understanding Anti-Spam Updates.
Running Antivirus Software
Viruses, worms, and other malicious content transmitted by e-mail systems are a destructive reality faced by most Microsoft Exchange administrators. Therefore, you must develop a defensive antivirus deployment for all messaging systems. This section provides best practices recommendations for the deployment of antivirus software for Exchange 2010.
You should pay additional attention to two important changes in Exchange 2010 when you select an antivirus software vendor:
- Starting with Exchange Server 2007, Microsoft Exchange is based
on a 64-bit architecture.
- Exchange 2010 includes transport agent functionality.
These two changes mean that antivirus vendors must provide Exchange 2010-specific software. Antivirus software that's written for earlier versions of Exchange is unlikely to operate correctly with Exchange 2010.
To use a defense-in-depth approach, we recommend that you deploy antivirus software that's designed for messaging systems at either the SMTP gateway or at the Exchange servers that host mailboxes, in addition to antivirus software on the user desktop.
You decide what types of antivirus software to use and where the software is deployed by determining the appropriate balance between the cost and risk you are willing to assume. For example, some organizations run antivirus messaging software at the SMTP gateway, file-level antivirus scanning at the Exchange server, and antivirus client software on the user desktop. This approach provides messaging-specific protection at the client. Other organizations may tolerate higher costs and therefore improve security by running antivirus messaging software at the SMTP gateway, file-level antivirus scanning at the Exchange server, and antivirus client software on the user desktop, together with antivirus software that's compatible with Exchange Virus Scanning Application Programming Interface (VSAPI) 2.5 on the Exchange Mailbox server.
Running Antivirus Software on Edge Transport Servers and Hub Transport Servers
Transport-based antivirus software is implemented as or includes transport agents. Transport agents act on transport events, much like event sinks in earlier versions of Microsoft Exchange. For more details, see Understanding Transport Agents.
| Note: |
|---|
| Messages that aren't routed through transport, such as items in public folders, Sent Items, and calendar items, which can only be scanned on a Mailbox server, aren't protected by transport-only virus scanning. |
Third-party developers can write customized transport agents to take advantage of the underlying MIME-parsing engine for robust transport-level antivirus scanning. For a list of Exchange antivirus and anti-spam partners, see Independent Software Vendors.
In addition, Forefront Protection for Exchange Server is an antivirus software package that's tightly integrated with Exchange 2010 and offers additional antivirus protection for your Exchange environment. For more information, see Microsoft Forefront Protection 2010 for Exchange Server.
The most important position for messaging antivirus software is at the first line of defense in your organization. This is the SMTP gateway through which external messages enter your messaging environment. In Exchange 2010, the first line of defense is the Edge Transport server.
If you use a non–Exchange SMTP server or gateway to receive inbound e-mail before Exchange, you should implement sufficient anti-spam and antivirus functionality on the non–Exchange SMTP hosts.
In Exchange 2010, all messages are routed through a Hub Transport server. This includes messages sent or received from outside the Exchange organization and messages sent within the Exchange organization. Messages sent to a mailbox located on the same Mailbox server as the sender. To better guard against virus outbreaks from inside the organization and to provide a second line of defense, we also recommend that you run transport-based antivirus software on Hub Transport servers.
Running Antivirus Software on Mailbox Servers
In addition to virus scanning on transport servers, a Microsoft Exchange Virus Scanning API (VSAPI) scanning solution running on Mailbox servers may be an important layer of defense in many organizations. You should consider running a VSAPI antivirus solution if any of the following conditions is true:
- Your organization doesn't have complete and reliable desktop
antivirus scanning products deployed.
- Your organization wants the additional protection that scanning
mailbox databases can provide.
- Your organization has developed custom applications that have
programmatic access to an Exchange database.
- Your user community regularly posts messages in public
folders.
Antivirus solutions that use Exchange VSAPI run directly within the Exchange information store process. VSAPI solutions are likely the only solutions that can protect against attack vectors that put infected content inside the Exchange information store while bypassing the standard client and transport scanning. For example, VSAPI is the only solution that scans data that's submitted to a database by CDO (Collaboration Data Objects), WebDAV, and Exchange Web Services (EWS). In addition, when a virus outbreak does occur, frequently a VSAPI solution provides the quickest way to remove and eliminate viruses from an infected mail database.
Exchange Server and File System Antivirus
If you deploy file-system antivirus software to protect your Exchange servers, consider the following:
- You must exclude Exchange server directories where the Exchange
mailbox and public folder databases are stored, from file system
antivirus scanners. For details, see File-Level Antivirus
Scanning on Exchange 2010.
- File system antivirus scanners only protect files. To protect
e-mail messages, you should also consider implementing
Exchange-aware antivirus or messaging security products such as
including Microsoft Forefront, or suitable partner or
third-party products. For details about anti-spam and antivirus
protection, see Understanding Anti-Spam
and Antivirus Functionality. For details, see Forefront Protection 2010 for Exchange Server:
Overview.
- You must keep antivirus and anti-spam signatures up-to-date for
effective protection.
- Reports from antivirus and anti-spam software or services
should be reviewed regularly to ensure protection is enabled and
performing as required, detect incidents quickly, and take any
required action.
Using Exchange Hosted Services
Spam and virus filtering is improved by or is also available as a service from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:
- Hosted Filtering, which helps organizations protect themselves
from e-mail-borne malware
- Hosted Archive, which helps organizations satisfy compliance
and retention requirements
- Hosted Encryption, which helps organizations encrypt data to
preserve confidentiality
- Hosted Continuity, which helps organizations preserve access to
e-mail during and after outages
These services integrate with any on-premises Exchange servers that are managed in house. For more information, see Forefront Online Protection for Exchange.
Using Attachment Filtering
In Exchange 2010, attachment filtering lets you apply filters on Edge Transport servers to control the attachments that users receive. Attachment filtering is increasingly important in today's environment where many attachment types contain harmful viruses or unsuitable material that may cause significant damage to the user's computer or to the organization by damaging important documentation or releasing sensitive information to the public.
You can use the following types of attachment filtering to control attachments that enter or leave your organization through an Edge Transport server:
Filtering based on file name or file name extension You can filter attachments by specifying the exact file name or file name extension to be filtered. An example of an exact file name filter is BadFilename.exe. An example of a file name extension filter is *.exe.
Filtering based on file MIME content type You can also filter attachments by specifying the MIME content type to be filtered. MIME content types indicate what the attachment is, whether it's a JPEG image, an executable file, a Microsoft Office Excel 2010 file, or some other file type. Content types are express as type/subtype. For example, the JPEG image content type is express as image/jpeg.
If an attachment matches one of these filtering criteria, you can configure the following actions to be performed on the attachment:
- Block whole message and attachment
- Strip attachment but allow message through
- Silently delete message and attachment
For more details, see Understanding Attachment Filtering.
| Note: |
|---|
| You can't use the Attachment Filter agent to filter attachments based on their content. You can use transport rules to inspect the message and attachment content, and take actions such as deleting or rejecting the message, or IRM-protecting the message and attachments. For details, see Understanding Transport Rules. |
File Filtering Using Forefront Protection for Exchange Server
The file filtering functionality that's provided by Forefront Protection for Exchange Server includes advanced features aren't available in the Attachment Filter agent included with Exchange 2010.
For example, container files, which are files that contain other files, can be scanned for offending file types. Forefront Protection for Exchange Server filtering can scan the following container files and act upon embedded files:
- PKZip (.zip)
- GNU Zip (.gzip)
- Self-extracting compressed file archives (.zip)
- Compressed files (.zip)
- Java archive (.jar)
- TNEF (winmail.dat)
- Structured storage (.doc, .xls, .ppt, and more)
- MIME (.eml0
- SMIME (.eml)
- UUEncode (.uue)
- Unix tape archive (.tar)
- RAR archive (.rar)
- MACBinary (.bin)
| Note: |
|---|
| The Attachment Filter agent included with Exchange 2010 detects file types even if they've been renamed. Attachment filtering also makes sure that compressed Zip and LZH files don't contain blocked attachments by performing a file name extension match against the files in the compressed Zip or LZH file. Forefront Protection for Exchange Server file filtering has the additional capability of determining whether a blocked attachment has been renamed within a container file. |
You can also filter files by file size. Also, you can configure Forefront Protection for Exchange Server to quarantine filtered files or to send e-mail notifications based Exchange on file filter matches.
For more information, see Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server.
Running the Exchange Best Practices Analyzer
The Exchange Best Practices Analyzer is one of the most effective tools that you can run regularly to help verify that your Exchange environment is secure. The Exchange Best Practices Analyzer automatically examines your Microsoft Exchange deployment and determines whether it's configured according to Microsoft best practices. In Exchange 2010, the Exchange Best Practices Analyzer is installed as part of Exchange Setup and can be run from the Tools section of the Exchange Management Console (EMC). With the appropriate network access, the Exchange Best Practices Analyzer examines all your Active Directory Domain Services (AD DS) servers and Exchange servers. The Exchange Best Practices Analyzer includes permissions inheritance checks. Also, it tests for validation of RBAC permissions. This include tests to ensure all users can access the Exchange Control Panel (ECP), all default RBAC roles created by Exchange Setup are configured properly, and there's at least one administrative account present within the Exchange organization.
Network Port Usage and Firewall Hardening
Windows Server 2008 includes Windows Firewall with Advanced Security, a stateful packet inspection firewall that's enabled by default. Windows Firewall with Advanced Security provides the following functionality:
- Filtering of all IP version 4 (IPv4) and IP version 6 (IPv6)
traffic entering or leaving the computer. By default, all incoming
traffic is blocked unless it's a response to a previous outgoing
request from the computer (solicited traffic), or it's specifically
allowed by a rule created to allow that traffic. By default, all
outgoing traffic is allowed, except for service hardening rules
that prevent standard services from communicating in unexpected
ways. You can choose to allow traffic based on port numbers, IPv4
or IPv6 addresses, the path and name of an application, or the name
of a service that's running on the computer, or other criteria.
- Protecting network traffic entering or exiting the computer by
using the IPsec protocol to verify the integrity of the network
traffic, to authenticate the identity of the sending and receiving
computers or users, and to optionally encrypt traffic to provide
confidentiality.
Exchange 2010 is designed to run with the Windows Server Firewall with Advanced Security enabled. Exchange Setup creates the required firewall rules to allow Exchange services and processes to communicate. It creates only the rules required for the services and processes installed on a given server role. For more details about network port usage and firewall rules created for each Exchange 2010 server role, see Exchange Network Port Reference.
On Windows Server 2008 and Windows Server 2008 R2, Windows Firewall with Advanced Security allows you to specify the process or service for which a port is opened. This is more secure because it restricts usage of the port to the process or service specified in the rule. Exchange 2010 Setup creates firewall rules with the process name specified. In some cases, an additional rule that isn't restricted to the process is also created for compatibility purposes. You can disable or remove the rules that aren't restricted to the processes and keep the corresponding rules which are also created by Exchange 2010 Setup and are restricted to processes, if your deployment supports them. Rules that aren't restricted to processes are distinguished by the word (GFW) in the rule name. We recommend that you perform sufficient testing of the rules in your environment before you disable the rules that aren't restricted to a process.
The following table lists the Windows Firewall rules created by Exchange Setup, including the ports opened on each server role.
Windows Firewall rules
| Rule name | Server roles | Port |
|---|---|---|
|
MSExchangeRPCEPMap (GFW) (TCP-In) |
All roles |
RPC-EPMap |
|
MSExchangeRPC (GFW) (TCP-In) |
Client Access, Hub Transport, Mailbox, Unified Messaging |
Dynamic RPC |
|
MSExchange - IMAP4 (GFW) (TCP-In) |
Client Access |
143, 993 (TCP) |
|
MSExchange - POP3 (GFW) (TCP-In) |
Client Access |
110, 995 (TCP) |
|
MSExchange - OWA (GFW) (TCP-In) |
Client Access |
5075, 5076, 5077 (TCP) |
|
MSExchangeMailboxReplication (GFW) (TCP-In) |
Client Access |
808 (TCP) |
|
MSExchangeIS (GFW) (TCP-In) |
Mailbox |
6001, 6002, 6003, 6004 (TCP) |
|
MSExchangeTransportWorker (GFW) (TCP-In) |
Hub Transport |
25, 587 (TCP) |
|
SESWorker (GFW) (TCP-In) |
Unified Messaging |
Any |
|
UMService (GFW) (TCP-In) |
Unified Messaging |
5060, 5061 (TCP) |
|
UMWorkerProcess (GFW) (TCP-In) |
Unified Messaging |
5065, 5066, 5067, 5068 |
 Important: |
|---|
| When modifying the default port used by an Exchange 2010 service, you must also modify the corresponding Windows Firewall with Advanced Security firewall rule to allow communication over the nondefault port you decide to use. Exchange 2010 doesn't change firewall rules when you change default ports used for a service. |
Throttling Parameters and Client Throttling Policies
Exchange 2010 includes throttling parameters on Transport, Client Access Server and Mailbox server roles to control different parameters of connections related to each protocol. Exchange 2010 also includes client throttling policies to control the load on Client Access servers. These throttling parameters and policies help you to control the load and protect Exchange 2010 servers from denial of service attacks targeted at different protocols.
Throttling Parameters on Transport Servers
On Exchange 2010 Transport servers, message throttling parameters are implemented on the server and on Send and Receive connectors to control message processing rates, SMTP connection rates, and SMTP session time-out values. Together, these throttling parameters protect transport servers from being overwhelmed by accepting and delivering lots of messages, providing protection from rogue SMTP clients and denial of service attacks.
You can configure the following throttling policies on Exchange 2010 Transport servers using the Set-TransportServer cmdlet.
Transport server throttling parameters
| Parameter | Description |
|---|---|
|
MaxConcurrentMailboxDeliveries |
The MaxConcurrentMailboxDeliveries parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to deliver messages to mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the delivery of messages to any mailboxes in the Exchange organization. Default 20 deliveries |
|
MaxConcurrentMailboxSubmissions |
The MaxConcurrentMailboxSubmissions parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to accept messages from mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the acceptance of new messages from any mailboxes in the Exchange organization. Default 20 submissions |
|
MaxConnectionRatePerMinute |
The MaxConnectionRatePerMinute parameter specifies the maximum rate at which new inbound connections can be opened to the Hub Transport server or the Edge Transport server. These connections are opened to any Receive connectors that exist on the server. Default 1,200 connections per minute. |
|
MaxOutboundConnections |
The MaxOutboundConnections parameter specifies the maximum number of concurrent outbound connections that the Hub Transport server or Edge Transport server can have open at the same time. The outbound connections occur by using the Send connectors that exist on the server. The value that's specified by the MaxOutboundConnections parameter applies to all Send connectors that exist on the transport server. Default 1,000 connections. If you enter a value of unlimited, no limit is imposed on the number of outbound connections. This value can also be configured using the EMC. |
|
MaxPerDomainOutboundConnections |
The MaxPerDomainOutboundConnections parameter specifies the maximum number of connections that an Internet-facing Hub Transport server or Edge Transport server can have open to any single remote domain. The outbound connections to remote domains occur by using Send connectors that exist on the server. Default 20 connections per domain If you enter a value of unlimited, no limit is imposed on the number of outbound connections per domain. This value can also be configured using the EMC. |
|
PickupDirectoryMaxMessagesPerMinute |
The MaxPerDomainOutboundConnections parameter specifies the rate of message processing for both the Pickup directory and Replay directory. Each directory can independently process message files at the rate that's specified by the PickupDirectoryMaxMessagesPerMinute parameter. Defaults By default, the Pickup directory can process 100 messages per minute, and the Replay directory can process 100 messages per minute at the same time. The Pickup directory and the Replay directory scan for new message files once every 5 seconds, or 12 times per minute. This 5-second polling interval isn't configurable. This means the maximum number of messages that can be processed during each polling interval is the value that you assign to the PickupDirectoryMaxMessagesPerMinute parameter divided by 12 (PickupDirectoryMaxMessagesPerMinute/12). By default, a maximum of just over eight messages can be processed during each 5-second polling interval. |
Throttling Parameters on Send Connectors
The following throttling parameters are available on Send connectors. Use the Send-Connector cmdlet to configure these parameters.
Send connector throttling parameters
| Parameter | Description |
|---|---|
|
ConnectionInactivityTimeOut |
The ConnectionInactivityTimeOut parameter specifies the maximum time that an open SMTP connection with a destination messaging server can remain idle before the connection is closed. Default 10 minutes. |
|
SmtpMaxMessagesPerConnection |
The SmtpMaxMessagesPerConnection parameter specifies the maximum number of messages this Send connector server can send per connection. Default 20 messages |
Throttling Parameters on Receive Connectors
You can configure the following throttling parameters on Receive connectors on Exchange 2010 Transport servers to control connection parameters such as inactivity timeouts, maximum number of connections and the number of SMTP protocol errors allowed during a connection. Use the Set-ReceiveConnector cmdlet to configure these parameters.
Receive connector throttling parameters
| Parameter | Description |
|---|---|
|
ConnectionInactivityTimeOut |
The ConnectionInactivityTimeOut parameter specifies the maximum time that an open SMTP connection with a source messaging server can remain idle before the connection is closed. Default on Hub Transport servers 5 minutes. Default on Edge Transport servers 1 minute. |
|
ConnectionTimeOut |
The ConnectionTimeOut parameter specifies the maximum time that an SMTP connection with a source messaging server can remain open, even if the source messaging server is transmitting data. Default on Hub Transport servers 10 minutes Default on Edge Transport servers 5 minutes. The value specified by the ConnectionTimeout parameter must be larger than the value specified by the ConnectionInactivityTimeout parameter. |
|
MaxInboundConnection |
The MaxInboundConnection parameter specifies the maximum number of inbound SMTP connections that this Receive connector allows at the same time. Default 5,000 |
|
MaxInboundConnectionPercentagePerSource |
The MaxInboundConnectionPercentagePerSource parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. The value is expressed as the percentage of available remaining connections on a Receive connector. The maximum number of connections that are permitted by the Receive connector is defined by the MaxInboundConnection parameter. Default 2 percent |
|
MaxInboundConnectionPerSource |
The MaxInboundConnectionPerSource parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. Default 100 connections |
|
MaxProtocolErrors |
The MaxProtocolErrors parameter specifies the maximum number of SMTP protocol errors that a Receive connector allows before the Receive connector closes the connection with the source messaging server. Default 5 errors |
Throttling Parameters for the POP3 Service
The following throttling parameters are available for the Microsoft Exchange POP3 service on Client Access servers. Use the Set-POPSettings cmdlet to configure these parameters. For details, see Set Connection Limits for POP3.
POP3 service throttling parameters
| Parameter | Description |
|---|---|
|
MaxCommandSize |
The MaxCommandSize parameter specifies the maximum size of a single command. The possible values are from 40 through 1024 bytes. Default 40 bytes. |
|
MaxConnectonFromSingleIP |
The MaxConnectionFromSingleIP parameter specifies the number of connections that the specified server accepts from a single IP address. The possible values are from 1 through 25,000. Default 2,000 connections |
|
MaxConnections |
The MaxConnections parameter specifies the total number of connections that the specified server accepts. This includes authenticated and unauthenticated connections. The possible values are from 1 through 25,000. Default 2,000 connections. |
|
MaxConnectionsPerUser |
The MaxConnectionsPerUser parameter specifies the maximum number of connections that the Client Access server accepts from a particular user. The possible values are from 1 through 25,000. Default 16 connections. |
|
PreAuthenticationConnectionTimeOut |
The PreAuthenticatedConnectionTimeout parameter specifies the time to wait before closing an idle connection that isn't authenticated. The possible values are from 10 through 3,600 seconds. Default 60 seconds. |
Throttling Parameters for the IMAP4 Service
The following throttling parameters are available for the Microsoft Exchange IMAP4 service on Client Access servers. Use the Set-IMAPSettings cmdlet to configure these parameters. For details, see Set Connection Limits for IMAP4.
IMAP4 service throttling parameters
| Parameter | Description |
|---|---|
|
AuthenticationConnectionTimeOut |
The AuthenticatedConnectionTimeout parameter specifies the period of time to wait before closing an idle authenticated connection. The possible values are from 30 through 86400 seconds. Default 1,800 seconds |
|
MaxCommandSize |
The MaxCommandSize parameter specifies the maximum size of a single command. The default size is 40 bytes. The possible values are from 40 through 1024 bytes. Default 40 bytes. |
|
MaxConnectionFromSingleIP |
The MaxConnectionFromSingleIP parameter specifies the number of connections that the specified server accepts from a single IP address. The possible values are from 1 through 25,000. Default 2,000 connections |
|
MaxConnections |
The MaxConnections parameter specifies the total number of connections that the specified server accepts. This includes authenticated and unauthenticated connections. The possible values are from 1 through 25,000. Default 2,000 connections |
|
MaxConnectionsPerUser |
The MaxConnectionsPerUser parameter specifies the maximum number of connections that the Client Access server accepts from a particular user. The possible values are from 1 through 25,000. Default 16 connections. |
|
PreAuthenticatedConnectionTimeOut |
The PreAuthenticatedConnectionTimeout parameter specifies the time to wait before closing an idle connection that isn't authenticated. The possible values are from 10 through 3600 seconds. Default 60 seconds |
Client Throttling Policies
In Exchange 2010, you can use client throttling policies to manage Client Access server performance by controlling parameters such as the number of concurrent connections for each client access protocol, the percentage of time that a client session can use to run LDAP operations, RPC operations, and client access operations. There's a default client throttling policy that's generally sufficient to manage the load placed on Client Access servers. You can modify the default policy parameters or create custom policies that meet the requirements for your deployment.
Throttling policies are available for the following user groups and access methods:
- Anonymous access
- Cross-premises access (CPA)
- Exchange ActiveSync (EAS)
- Exchange Web Services (EWS)
- IMAP
- POP
- Outlook Web App (OWA)
- RPC Client Access (RCA)
The following throttling settings are available in client throttling policies for each of these user groups (Anonymous access and CPA) and access methods (EAS, EWS, IMAP, OWA, POP, and RCA).
Client throttling policy settings
| Throttling setting | Anonymous Access | CPA | EAS | EWS | IMAP | OWA | POP | RCA |
|---|---|---|---|---|---|---|---|---|
|
Max Concurrency |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
|
Percent Time in AD |
Yes |
N. A. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
|
Percent Time in CAS |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
|
Percent Time in Mailbox RPC |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
CPA Cross-Premises Access
EAS Exchange ActiveSync
EWS Exchange Web Services
OWA Outlook Web App
In addition to these throttling settings based on user groups and access methods, the following throttling settings are available in a client throttling policy.
Client throttling policy parameters
| Parameter | Description |
|---|---|
|
CPUStartPercent |
The CPUStartPercent parameter specifies the per-process CPU percentage at which users governed by this policy begin to be backed off. Valid values are from 0 through 100. Use $null to turn off CPU percentage-based throttling for this policy. |
|
EASMaxDeviceDeletesPerMonth |
The EASMaxDeviceDeletesPerMonth parameter specifies a limit to the number of Exchange ActiveSync partnerships that a user can delete per month. By default, each user can delete a maximum of 20 partnerships per calendar month. When the limit is reached, the partnership deletion attempt fails and an error message is displayed to the user. |
|
EASMaxDevices |
The EASMaxDevices parameter specifies a limit to the number of Exchange ActiveSync partnerships that a user can have at one time. By default, each user can create 10 Exchange ActiveSync partnerships with their Exchange account. After users exceed the limit, they must delete one of their existing partnerships before they can create any more new partnerships. An e-mail error message describing the limitation is sent to the user when the limit is exceeded. Also, an event is logged in the Application log when a user exceeds the limit. |
|
EWSFastSearchTimeOutInSeconds |
The EWSFastSearchTimeoutInSeconds parameter specifies the amount of time that searches made using Exchange Web Services continue before they time out. If the search takes more than the time indicated by the policy value, the search stops and an error is returned. The default value of this setting is 60 seconds. |
|
EWSFindCountLimit |
The EWSFindCountLimit parameter specifies the maximum result size of FindItem or FindFolder calls that can exist in memory on the Client Access server at the same time for this user in this current process. If an attempt is made to find more items or folders than your policy limit allows, an error is returned. However, the limit isn't strictly enforced if the call is made within the context of an indexed page view. Specifically, in this scenario, the search results are truncated to include the number of items and folders that fit within the policy limit. You can then continue paging into your results set via further FindItem or FindFolder calls. |
|
EWSMaxSubscriptions |
The EWSMaxSubscriptions parameter specifies the maximum number of active push and pull subscriptions that a user can have on a specific Client Access server at the same time. If a user tries to create more subscriptions than the configured maximum, the subscription fails, and an event is logged in Event Viewer. |
|
ExchangeMaxCmdlets |
The ExchangeMaxCmdlets parameter specifies the number of cmdlets that can be run within a specific time period before their execution is slowed down. The value specified by this parameter should be less than the value specified by the PowerShellMaxCmdlets parameter. The time period used for this limit is specified by the PowerShellMaxCmdletsTimePeriod parameter. We recommend that you set values for both parameters at the same time. |
|
ForwardeeLimit |
The ForwardeeLimit parameter specifies the limits for the number of recipients that can be configured in Inbox Rules when using the forward or redirect action. This parameter doesn't limit the number of messages that can be forwarded or redirected to the recipients that are configured. |
|
MessageRateLimit |
The MessageRateLimit parameter specifies the number of messages per minute that can be submitted to transport. For messages submitted through the Mailbox server role (Outlook Web App, Exchange ActiveSync, or Exchange Web Services), this results in the deferral of messages until the quota for the user is available. Specifically, messages appear in the Outbox or Drafts folder for longer periods of time when users submit messages at a rate greater than the MessageRateLimit parameter. For POP or IMAP clients submitting messages directly to transport using SMTP, clients receive a transient error if they submit at a rate that exceeds the MessageRateLimit parameter. Exchange tries to connect and send the messages at a later time. |
|
PowerShellMaxCmdletQueueDepth |
The PowerShellMaxCmdletQueueDepth parameter specifies the number of operations allowed to be run by the user. This value directly affects the behavior of the PowerShellMaxCmdlets and PowerShellMaxConcurrency parameters. For example, the PowerShellMaxConcurrency parameter consumes at least two operations defined by the PowerShellMaxCmdletQueueDepth parameter but additional operations are also consumed by per cmdlet execution. The number of operations depends on the cmdlets that are run. We recommend that the value for the PowerShellMaxCmdletQueueDepth parameter be at least three times larger than the value of the PowerShellMaxConcurrency parameter. This parameter won't affect Exchange Control Panel operations or Exchange Web Services operations. |
|
PowerShellMaxCmdlets |
The PowerShellMaxCmdlets parameter specifies the number of cmdlets that can be run within a specific time period before their execution is stopped. The value specified by this parameter should be more than the value specified by the ExchangeMaxCmdlets parameter. The time period used for this limit is specified by the PowerShellMaxCmdletsTimePeriod parameter. Both values should be set at the same time. |
|
PowerShellMaxCmdletsTimePeriod |
The PowerShellMaxCmdletsTimePeriod parameter specifies the time period, in seconds, that the throttling policy uses to determine whether the number of cmdlets being run exceeds the limits specified by the PowerShellMaxCmdlets and ExchangeMaxCmdlets parameters. |
|
PowerShellMaxConcurrency |
The PowerShellMaxConcurrency parameter specifies different information depending on context: In the context of Remote PowerShell, the PowerShellMaxConcurrency parameter specifies the maximum number of Remote PowerShell sessions that a Remote PowerShell user can have open at the same time. In the context of Exchange Web Services, the PowerShellMaxConcurrency parameter specifies the number of concurrent cmdlet executions that a user can have at the same time. This parameter value doesn't necessarily correlate to the number of browsers opened by the user |
|
RecipientRateLimit |
The RecipientRateLimit parameter specifies the limits on the number of recipients that a user can address in a 24-hour period. |
For more details about Exchange 2010 throttling policies, see Understanding Client Throttling Policies.
Role-Based Access Control
Role-Based Access Control (RBAC) is the new permissions model in Exchange 2010 that allows you to control, at both broad and granular levels, what administrators and users can do. With RBAC, it's no longer required to modify Access Control Lists (ACLs) on Active Directory objects such as Organizational Units and containers to allow granular delegation of permissions to groups such as helpdesk operators or for functions such as recipient management. Active Directory
For more details, see Understanding Role Based Access Control. For a list of default RBAC management roles included in Exchange 2010, see Built-in Management Roles. For a list of default role groups, see Built-in Role Groups.
Role groups created by Exchange 2010 Setup or by you are created in Active Directory as universal security groups in the Microsoft Exchange Security Groups OU. You can add members to a role group by using the New-RoleGroupMember cmdlet or by using the Exchange Control Panel (ECP). When you add a member to a role group, the user or group is added to the corresponding Active Directory security group. You can use a Restricted Group policy to restrict membership for critical RBAC role groups such as Discovery Management. When you implement a Restricted Group policy, the group membership is monitored by Active Directory domain controllers and any users not included in the policy are automatically removed.
| Important: |
|---|
| If you use Restricted Groups to restrict group membership for RBAC role groups, any changes you make to a role group using Exchange 2010 tools must also be made in the Restricted Group policy in Active Directory. For details, see Group Policy Security Settings. |
Active Directory
Exchange Server stores configuration data in the Configuration partition and recipient data in the Domain partition of Active Directory Domain Services (AD DS). For details about permissions required to set up an Exchange 2010 organization, see Exchange 2010 Deployment Permissions Reference. Communication with Active Directory domain controllers is secured by using Kerberos authentication and encryption.
Exchange 2010 provides a new authorization layer inside Exchange, known as Role Based Access Control (RBAC), instead of relying on applying access control entries (ACEs) for every account that requires the appropriate permissions. In earlier versions of Microsoft Exchange, Exchange Setup relied on ACEs within Active Directory for Exchange administrators to be able to manage objects within the domain partition. Exchange administrators are granted the ability to perform certain operations within a specific scope through RBAC. The Exchange server runs the authorized actions on behalf of the administrator or users by using the permissions granted within Active Directory through the Exchange Windows Permissions and Exchange Trusted Subsystem security groups. For more information on RBAC, see Understanding Role Based Access Control.
In Exchange 2010, /PrepapareDomain doesn't apply any ACEs for the Exchange Windows Permissions universal security group to the AdminSDHolder container in Active Directory. If /PrepareDomain detects any ACEs granted to the Exchange Windows Permissions universal security group, the ACEs are removed. This has the following implications:
- Members of the Exchange Windows Permissions universal
security group can't modify membership of protected security groups
such as Enterprise Admins and Domain Admins. This has the following
implications.
- Members of the Exchange Windows Permissions universal
security group can't force password reset of an account protected
by the AdminSDHolder.
- Members of the Exchange Windows Permissions universal
security group can't alter the permissions of any group or account
protected by the AdminSDHolder.
As a best practice, we recommend that you don't mailbox-enable accounts protected by the AdminSDHolder and do maintain separate accounts for Active Directory administrators: one account for Active Directory administration, and one account for regular day-to-day use, including e-mail. For details, see the following topics:
Exchange Server Accounts
Exchange 2010 Setup creates a new organizational unit (OU) in the root domain called Microsoft Exchange Security Groups. The following table shows the new universal security groups.
Microsoft Exchange security groups
| Security group | Description |
|---|---|
|
Exchange All Hosted Organizations |
This group contains all the Exchange Hosted Organization Mailboxes groups. It's used for applying Password Setting Objects to all hosted mailboxes. This group shouldn't be deleted. |
|
Exchange Servers |
This group contains all the Exchange servers. This group should not be deleted. We strongly discourage making any membership changes to this group. |
|
Exchange Trusted Subsystem |
This group contains Exchange servers Exchange run Exchange cmdlets on behalf of users via Management service. Its members will have permission to read and modify all Exchange configuration, and also user accounts and groups. This group shouldn't be deleted. |
|
Exchange Windows Permissions |
This group contains Exchange servers that run Exchange cmdlets on behalf of users via Management service. Its members will have permission to read and modify all Windows accounts and groups. This group should not be deleted. We strongly discourage making any membership changes to this group, and suggest monitoring group membership. |
|
ExchangeLegacyInterop |
This group is for interoperability with Exchange 2003 servers within the same forest. This group should not be deleted. |
In addition to these security groups, setup also creates the following security groups that correspond to RBAC role groups with the same name.
Security groups that correspond to RBAC role groups
| Security group | RBAC role group |
|---|---|
|
Delegated Setup |
|
|
Discovery Management |
|
|
Help Desk |
|
|
Hygiene Management |
|
|
Organization Management |
|
|
Public Folder Management |
|
|
Recipient Management |
|
|
Records Management |
|
|
Server Management |
|
|
UM Management |
|
|
View-Only Organization Management |
Also, when you create a new role group, Exchange 2010 creates a security group with the same name as the role group. For details, see the following topics:
Users are added or removed from these security groups when you add or remove users from role groups using the Add-RoleGroupMember or Remove-RoleGroupMember cmdlets, or by using the Role Based Access Control (RBAC) User Editor in the ECP.
File system
Exchange 2010 Setup creates directories with minimum permissions required for Exchange 2010 to function. We don't recommend any additional hardening of permissions to the default access control lists (ACLs) on directories created by setup.
Services
Exchange 2010 Setup doesn't disable any Windows services by default. The following table lists services enabled by default on each server role. Only the services required for operation of a particular Exchange 2010 server role are enabled by default.
Services installed by Exchange Setup
| Service name | Service short name | Security context | Description and dependencies | Default startup type | Server roles | Required (R) or optional (O) |
|---|---|---|---|---|---|---|
|
Microsoft Exchange Active Directory Topology |
MSExchangeADTopology |
Local System |
Provides Active Directory topology information to Exchange services. If this service is stopped, most Exchange services cannot start. This service has no dependencies. |
Automatic |
Mailbox, Hub Transport, Client Access, Unified Messaging |
R |
|
Microsoft Exchange ADAM |
ADAM_MSExchange |
Network Service |
Stores configuration data and recipient data on the Edge Transport server. This service represents the named instance of Active Directory Lightweight Directory Service (AD LDS) that's automatically created by Setup during Edge Transport server installation. This service depends on the COM+ Event System service. |
Automatic |
Edge Transport |
R |
|
Microsoft Exchange Address Book |
MSExchangeAB |
Local System |
Manages client address book connections. This service depends on the Microsoft Exchange Active Directory Topology service. |
Automatic |
Client Access |
R |
|
Microsoft Exchange Anti-spam Update |
MSExchangeAntispamUpdate |
Local System |
Provides the Microsoft Forefront Protection 2010 for Exchange Server anti-spam update service. On Hub Transport servers, this service depends on the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service depends on the Microsoft Exchange ADAM service. |
Automatic |
Hub Transport, Edge Transport |
O |
|
Microsoft Exchange Credential Service |
MSExchangeEdgeCredential |
Local System |
Monitors credential changes in AD LDS and installs the changes on the Edge Transport server. This service depends on the Microsoft Exchange ADAM service. |
Automatic |
Edge Transport |
R |
|
Microsoft Exchange EdgeSync |
MSExchangeEdgeSync |
Local System |
Connects to an AD LDS instance on subscribed Edge Transport servers over a secure LDAP channel to synchronize data between a Hub Transport server and an Edge Transport server. This service depends on the Microsoft Exchange Active Directory Topology service. If Edge Subscription isn't configured, this service can be disabled. |
Automatic |
Hub Transport |
O |
|
Microsoft Exchange File Distribution |
MSExchangeFDS |
Local System |
Distributes offline address book (OAB) and custom Unified Messaging prompts. This service depends on the Microsoft Exchange Active Directory Topology and Workstation services. |
Automatic |
Client Access, Unified Messaging |
R |
|
Microsoft Exchange Forms-Based Authentication |
MSExchangeFBA |
Local System |
Provides forms-based authentication to Outlook Web App and the Exchange Control Panel. If this service is stopped, Outlook Web App and the Exchange Control Panel won't authenticate users. This service has no dependencies. |
Automatic |
Client Access |
R |
|
Microsoft Exchange IMAP4 |
MSExchangeIMAP4 |
Network Service |
Provides IMAP4 service to clients. If this service is stopped, clients won't be able to connect to this computer using the IMAP4 protocol. This service depends on the Microsoft Exchange Active Directory Topology service. |
Manual |
Client Access |
O |
|
Microsoft Exchange Information Store |
MSExchangeIS |
Local System |
Manages the Exchange Information Store. This includes mailbox databases and public folder databases. If this service is stopped, mailbox databases and public folder databases on this computer are unavailable. If this service is disabled, any services that explicitly depend on it will fail to start. This service is dependent on the RPC, Server, Windows Event Log, and Workstation services. |
Automatic |
Mailbox |
R |
|
Microsoft Exchange Mail Submission Service |
MSExchangeMailSubmission |
Local System |
Submits messages from the Mailbox server to Exchange 2010 Hub Transport servers. This service depends on the Microsoft Exchange Active Directory Topology service. |
Automatic |
Mailbox |
R |
|
Microsoft Exchange Mailbox Assistants |
MSExchangeMailboxAssistants |
Local System |
Performs background processing of mailboxes in the Exchange store. This service depends on the Microsoft Exchange Active Directory Topology service. |
Automatic |
Mailbox |
R |
|
Microsoft Exchange Mailbox Replication Service |
MSExchangeMailboxReplication |
Local System |
Processes mailbox moves and move requests. This service depends on the Microsoft Exchange Active Directory Topology and Net.Tcp Port Sharing service. |
Automatic |
Client Access |
O |
|
Microsoft Exchange Monitoring |
MSExchangeMonitoring |
Local System |
Allows applications to call the Exchange diagnostic cmdlets. This service has no dependencies. |
Manual |
All |
O |
|
Microsoft Exchange POP3 |
MSExchangePOP3 |
Network Service |
Provides POP3 service to clients. If this service is stopped, clients can't connect to this computer using the POP3 protocol. This service depends on the Microsoft Exchange Active Directory Topology service. |
Manual |
Client Access |
O |
|
Microsoft Exchange Protected Service Host |
MSExchangeProtectedServiceHost |
Local System |
Provides a host for several Exchange services that must be protected from other services. This service depends on the Microsoft Exchange Active Directory Topology service. |
Automatic |
Hub Transport, Client Access |
R |
|
Microsoft Exchange Replication Service |
MSExchangeRepl |
Local System |
Provides replication functionality for mailbox databases on Mailbox servers in a database availability group (DAG). This service depends on the Microsoft Exchange Active Directory Topology service. |
Automatic |
Mailbox |
O |
|
Microsoft Exchange RPC Client Access |
MSExchangeRPC |
Network Service |
Manages client RPC connections for Exchange. This service depends on the Microsoft Exchange Active Directory Topology service. |
Automatic |
Mailbox, Client Access |
O (Mailbox), R (Client Access) |
|
Microsoft Exchange Search Indexer |
MSExchangeSearch |
Local System |
Drives indexing of mailbox content, which improves the performance of content search. This service depends on the Microsoft Exchange Active Directory Topology and Microsoft Search (Exchange Server) services. |
Automatic |
Mailbox |
O |
|
Microsoft Exchange Server Extension for Windows Server Backup |
WSBExchange |
Local System |
Enables Windows Server Backup users to back up and recover application data for Microsoft Exchange. This service has no dependencies. |
Manual |
Mailbox |
O |
|
Microsoft Exchange Service Host |
MSExchangeServiceHost |
Local System |
Provides a host for several Exchange services. On internal server roles, this service depends on the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service depends on the Microsoft Exchange ADAM service. |
Automatic |
All |
R |
|
Microsoft Exchange Speech Engine |
MSSpeechService |
Network Service |
Provides speech processing services for Unified Messaging. This service depends on the Windows Management Instrumentation (WMI) service. |
Automatic |
Unified Messaging |
R |
|
Microsoft Exchange System Attendant |
MSExchangeSA |
Local System |
Forwards directory lookups to a global catalog server for legacy Outlook clients, generates e-mail addresses and OABs, updates free/busy information for legacy clients, and maintains permissions and group memberships for the server. If this service is disabled, any services that explicitly depend on it will fail to start. This service is dependent on the RPC, Server, Windows Event Log, and Workstation services. |
Automatic |
Mailbox |
R |
|
Microsoft Exchange Throttling |
MSExchangeThrottling |
Network Service |
Limits the rate of user operations. This service depends on the Microsoft Exchange Active Directory Topology service. |
Automatic |
Mailbox |
R |
|
Microsoft Exchange Transport |
MSExchangeTransport |
Network Service |
Provides SMTP server and transport stack. On Hub Transport servers, this service depends on the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service depends on the Microsoft Exchange ADAM service. |
Automatic |
Hub Transport, Edge Transport |
R |
|
Microsoft Exchange Transport Log Search |
MSExchangeTransportLogSearch |
Local System |
Provides remote search capability for Microsoft Exchange Transport log files. On Hub Transport servers, this service depends on the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service depends on the Microsoft Exchange ADAM service. |
Automatic |
Hub Transport, Mailbox, Edge Transport |
O |
|
Microsoft Exchange Unified Messaging |
MSExchangeUM |
Local System |
Enables Microsoft Exchange Unified Messaging features. This allows voice and fax messages to be stored in Exchange and gives users telephone access to e-mail, voice mail, calendar, contacts, or an auto attendant. If this service is stopped, Unified Messaging isn't available. This service depends on the Microsoft Exchange Active Directory Topology and the Microsoft Exchange Speech Engine service. |
Automatic |
Unified Messaging |
R |
|
Microsoft Search (Exchange Server) |
msftesql-Exchange |
Local System |
This is a Microsoft Exchange-customized version of Microsoft Search. This service is dependent on the RPC service. |
Manual |
Hub Transport, Mailbox |
O |
Certificates
Exchange 2010 Setup creates self-signed certificates to secure communication over different protocols such as HTTP, SMTP, POP3 and IMAP4. The self-signed certificates created by Setup are valid for five years. This ensures that the self-signed certificates don't have to be renewed for a significant part of an Exchange 2010 deployment and messaging services aren't affected by the expiration of self-signed certificates.
For external client access mechanisms and protocols, such as Outlook Web App, POP3, IMAP4, Outlook Anywhere, and AutoDiscover, we recommend that you:
- Use certificates signed by a commercial certification authority
(CA) that's trusted by clients accessing those services.
- Use the New Exchange Certificate wizard or the New-ExchangeCertificate
cmdlet to create certificate signing requests for commercial CAs.
Certificate requests generated using these tools ensure that all
Exchange certificate requirements are met.
- Consider the certificate requirements for each protocol or
service for which you want to allow external client access.
- On Client Access servers, certificates are used to protect HTTP
traffic (Outlook Anywhere, Outlook Web App, AutoDiscover, Exchange
ActiveSync, and Exchange Web Services) by using Secure Sockets
Layer, and POP3 and IMAP4 traffic by using SSL or Transport Layer
Security (TLS). For details, see Managing SSL for a
Client Access Server.
- On transport servers, certificates are used to protect SMTP
traffic by using TLS. For details, see Understanding TLS
Certificates.
- On Unified Messaging servers, certificates are used to protect
Voice over Internet Protocol (VoIP) traffic. For details, see
Understanding
Unified Messaging VoIP Security.
- For Federation, certificates are used to encrypt SAML tokens
exchanged with the Microsoft Federation Gateway (MFG) and with
federated partner organizations. For details, see Understanding
Federation.
- On Client Access servers, certificates are used to protect HTTP
traffic (Outlook Anywhere, Outlook Web App, AutoDiscover, Exchange
ActiveSync, and Exchange Web Services) by using Secure Sockets
Layer, and POP3 and IMAP4 traffic by using SSL or Transport Layer
Security (TLS). For details, see Managing SSL for a
Client Access Server.
- Monitor certificate validity dates and renew certificates from
CAs in a timely manner to avoid service disruption.
- When storing certificates exported with the associated private
key, protect the exported file by using appropriate access controls
on the folder/file where it's stored. Depending on your
organization's security requirements, consider enabling auditing of
file access for folders where certificate files with private keys
are stored.
NTLM Considerations
The NTLM protocol is significantly less secure than the
Kerberos protocol. In Exchange 2010, the POP3 and IMAP4 protocols
don't support NTLM authentication when SecureLogin is
specified as the LoginType. For details, see Configuring
Authentication for POP3 and IMAP4. Exchange 2010 services that
use Windows Integrated Authentication can use either NTLM or
Kerberos protocols. Kerberos is used for Client Access server
communication to an Exchange 2010 Mailbox server, and between
Client Access servers for Outlook Web App, Exchange ActiveSync, and
Exchange Web Services. For details about services that use NTLM to
authenticate, see Exchange Network Port
Reference.
Dual Factor Authentication
Dual factor authentication mechanisms use another authenticator in addition to the user's logon credentials (username and password), such as randomly generated tokens, or a digital certificate on a smartcard along with a PIN. Many organizations deploy dual factor authentication to allow secure access to the organization's network.
Exchange 2010 doesn't include native support for dual factor authentication. Exchange 2010 uses Internet Information Server (IIS) 7 for client access through HTTP (AutoDiscover, Outlook Web App, Outlook Anywhere, Exchange ActiveSync, and Exchange Web Services). Many dual factor authentication products that integrate with IIS are available from partners and third parties, and work with Exchange client access services such as Outlook Web App. Before deploying dual factor authentication products for Exchange services, we recommend that you test them adequately to ensure they meet your organization's security requirements and provide the functionality you require.
Federation
Exchange 2010 introduces new federation features to enable secure collaboration between federated Exchange organizations. Exchange 2010 organizations can create a federation trust with the Microsoft Federation Gateway, and then establish organization relationships with other federated organizations to share availability information and Calendars. Organizations can also allow users to share their availability information, Calendar and Contacts with users in external federated organizations by using Sharing Policies. For more details about Federation Trusts and Federated Sharing, see Understanding Federation and Understanding Federated Delegation.
After you establish a Federation Trust with MFG, sharing between two federated organizations doesn't occur unless you create an Organization Relationship. By default, however, sharing between your users and users in external federated organizations is enabled by using the Default Sharing Policy assigned to users. The policy allows Calendar sharing with free/busy information only to users in all external federated organizations. If you don't want to allow users to share their calendar and free/busy information with users in all external federated domains, you must disable the Default Sharing Policy or change the domain name specified in the policy to only those domains you want to allow sharing with. You must make this change before you create a Federation Trust with MFG. For more details, see Disable a Sharing Policy and Configure Sharing Policy Properties.
You can disable all Federation features for an organization, including Federated Delegation, by removing the organization's Federation Trust with MFG. For more details, see Remove a Federation Trust.
Secure/Multipurpose Internet Mail Extensions (S/MIME)
Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standard for public key encryption and signing of MIME data which provides authentication, message integrity, nonrepudiation, and data privacy for messaging data. Users can sign or encrypt messages, or both, using S/MIME certificates. For more information about S/MIME, see Understanding S/MIME.
S/MIME is a client-side technology without any interoperability requirements for e-mail servers. From a message transfer perspective, S/MIME signed or encrypted messages are transferred no differently than clear text (not encrypted) messages. Actual rendering of message is done on the client-side after certificate and message validation checks. For Outlook Web App, S/MIME support is provided by using an ActiveX control. Although Outlook Web App supports most popular browsers such as Microsoft Internet Explorer, Mozilla FireFox and Safari, ActiveX controls are an Internet Explorer feature. Outlook Web App users using other browsers can't access S/MIME features and may have to use another e-mail client which supports S/MIME. For more details about S/MIME support in Outlook Web App, see Outlook Web App and S/MIME.
For more details about S/MIME support in Outlook, see Overview of certificates and cryptographic e-mail messaging in Outlook.
Whereas S/MIME offers security benefits to an organization, when you evaluate the technology, you should consider the following:
- S/MIME encrypted messages are opaque to your organization.
Messaging security software such as antivirus and anti-spam can't
inspect message content, including message body and any
attachments.
- Because message content and attachments are encrypted, your
organization's messaging policies, including transport rules, can't
be applied to S/MIME-encrypted messages.
- Modifying S/MIME-signed messages to comply with your
organization's messaging policies, for example to apply a
disclaimer or personalized signature, invalidates the message.
- Encrypted messaging content can't be inspected for any content
violations, and your organization can't protect sensitive
information. This includes any personally identifiable information
(PII), from leaving the organization.
- S/MIME-encrypted messages can't be indexed by Exchange Search
and are therefore not searchable by discovery.
- To meet local regulations or discovery requirements during
litigation, your organization may be required to produce copies of
all encrypted messages that are not encrypted.
Exchange 2010 offers Information Rights Management (IRM) features that allow your organization to apply persistent protection to sensitive messaging content so only specified recipients can access IRM-protected messages. Your organization can also implement controls on how such content is used after it's delivered to recipients. For example, you can prevent messages from being printed, replied to, or forwarded inside or outside the organization. Also, your organization can still decrypt the IRM-protected content for scanning by antivirus and anti-spam software and other transport agents, applying messaging policies using transport rules, and enable archiving and discovery of IRM-protected messages. IRM features are also available in all web browsers supported by Outlook Web App and in Windows Mobile devices. For more details about IRM, see Understanding Information Rights Management.
Server Role Considerations
This section lists security-related considerations for the Exchange 2010 server role.
Mailbox Server Considerations
In Exchange 2010, architectural changes have been made to the Exchange store and connectivity from MAPI clients such as Outlook. MAPI clients connect to the Client Access Server, isolating the Mailbox server from client traffic. Mailbox servers communicate only with Client Access servers that use RPCSec, and with Active Directory Domain Services (AD DS) servers in your organization. Mailbox servers don't require Internet connectivity.
Storage
Storage is a critical component of Mailbox servers. You must plan your Mailbox server storage sub-system to ensure satisfactory performance and adequate storage space is available for your deployment. For more details about planning for Mailbox server storage, see Mailbox Server Storage Design.
After Mailbox server deployment, you should monitor the following the following:
- Availability of storage sub-system.
- Availability of sufficient free disk space on volumes that
contain the mailbox database and transaction logs. A mailbox or
Public Folder database is unmounted when the volume storing the
database or transaction logs for it run out of free disk space.
You can use Microsoft Federation Gateway Systems Center Operations Manager to monitor storage availability and disk free space. For more details, see Systems Center Operations Manager 2007.
When planning for and monitoring storage, if you plan to use the following features, you must consider their storage requirements:
- Journaling When you use journaling to
keep messages for long-term archival, depending on whether you use
standard (per-mailbox database) or premium journaling (journal
rules), messages sent to and from all recipients in a mailbox
database or the recipients specified in a journal rule are
delivered in a journal report to the journaling mailbox or
recipient specified. The result can be a large number of journal
reports delivered to a journaling mailbox. When planning storage
for Mailbox servers, you must consider journaling mailbox sizes.
You can control journaling mailbox sizes by configuring sufficient
mailbox quotas for a journaling mailbox. For more details about
journaling and mailbox quotas, see the following topics:
- Litigation Hold When you place a
mailbox on litigation hold, items deleted by the user by using the
Recover Deleted Items functionality in Outlook and Outlook Web App
and messages deleted by automated processes such as MRM are
retained till litigation hold is removed. In Exchange 2010, the
Recoverable Items warning quota and Recoverable Items quota are set
to 20 GB and 30 GB. For more details, see the following topics:
High Availability
High Availability of Mailbox servers is critical in ensuring messaging service availability. Exchange 2010 includes Database Availability Groups (DAGs) for high availability of Mailbox servers. DAGs can provide availability when your Exchange deployment experiences a failure of the storage sub-system, the server, or network connectivity, or an outage of a whole datacenter. For more details about planning and implementing a highly available Exchange 2010 deployment, see High Availability and Site Resilience.
By default, in Exchange 2010, replication (log shipping) traffic between DAG members located in different Active Directory sites is encrypted. You can encrypt replication traffic between servers in the same Active Directory site by setting the NetworkEncryption property of the DAG to Enabled. Use the Set-DatabaseAvailabilityGroup cmdlet to modify this property for a DAG.
Replication occurs over a single TCP port, by default TCP port 64327. You can modify the port used for replication. For details, see Configure Database Availability Group Properties.
Parameters for high availability
| Parameter | Description |
|---|---|
|
NetworkEncryption |
The NetworkEncryption parameter specifies whether network encryption is enabled. Valid values include:
Default |
|
ReplicationPort |
The ReplicationPort parameter specifies a Transmission Control Protocol (TCP) port for replication (log shipping and seeding) activity. Default If this parameter isn't specified, the default port for replication is TCP 64327. |
Mailbox Permissions and Access
By default, Exchange 2010 doesn't allow administrators to access mailboxes. If your organization uses applications or services that require access to a mailbox, you must assign appropriate mailbox permissions to accounts used by such applications or services. We recommend that you don't configure such applications or services to use administrator credentials.
Although all mailboxes can potentially contain sensitive information valuable to an organization, the following mailboxes deserve special attention from a security perspective, and permissions to access these mailboxes must be controlled and monitored to meet your organization's security requirements.
- Discovery mailboxes Discovery mailboxes
are used by the Exchange 2010 Multi-Mailbox Search feature. This
allows discovery managers who are members of the Discovery
Management role group to search messages in all mailboxes in an
Exchange 2010 organization. Messages returned by a discovery search
are copied to the specified Discovery mailbox. Exchange 2010 Setup
creates a default Discovery Search Mailbox. For more details, see
Understanding
Multi-Mailbox Search.
- Journaling mailboxes When you configure
journaling for a mailbox database or create Journal Rules to
journal messages to and from specified recipients, journal reports
are delivered to the specified journaling mailbox. For more
details, see the following topics:
In addition to protecting these mailboxes, notice that an administrator can use transport rules to inspect message content and also deliver a copy of the message to another recipient, even as a Bcc recipient. The permissions required to manage transport rules are listed in the Transport rules entry in the Messaging Policy and Compliance Permissions topic. We recommend that you use adequate controls to monitor and control the creation and modification of transport rules and that you also regularly audit transport rule actions for all rules.
Client Access Server Considerations
In Exchange 2010, the following clients connect to Client Access servers to access mailboxes:
- Outlook clients using MAPI
- Outlook clients using Outlook Anywhere
- Web browsers using Outlook Web App,
- Mobile devices using Exchange ActiveSync
- POP3 & IMAP4 clients
- Applications that use Exchange Web Services (EWS)
By default, these client access methods are secured by using encrypted data paths. Also by default, Outlook clients connecting to a Client Access server using MAPI use RPC encryption. Outlook Web App, Outlook Anywhere and Exchange ActiveSync access is secured by using Secure Sockets Layer (SSL).
For external client access, you must obtain and install certificates signed by a certification authority (CA) trusted by the client. For more details, see Managing SSL for a Client Access Server.
By default, POP3 and IMAP4 services are disabled on Exchange 2010 Client Access servers. If you enable them, we recommend that you use Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to help secure communication by using these protocols. For more details, see the following topics:
we recommend that you use appropriate firewalls and access controls when you publish Client Access servers for external access. Microsoft Forefront Threat Management Gateway (TMG) 2010 includes publishing wizards to easily and securely publish Exchange 2010 Client Access servers for external access. For more details, see Forefront Threat Management Gateway (TMG) 2010.
| Important: |
|---|
| Locating Client Access servers on perimeter networks isn't supported. |
On Client Access servers, Internet Information Server (IIS) is used to provide HTTP protocol access to services such as Outlook Web App, Exchange ActiveSync, Outlook Anywhere, AutoDiscover, Exchange Control Panel (ECP), Exchange Web Services and Offline Address Book (OAB). Remote PowerShell also uses IIS, And all RPS requests, including requests by the Exchange Management Console (EMC), are logged in IIS logs. IIS logs can grow to consume a large amount of disk space. IIS, a Windows Server component, doesn't include a mechanism to clear older logs based on the size of the directory in which the log files reside. As a best practice, IIS logs should be moved to a non-system volume, so growth of log files doesn't result in the system volume running out of disk space, which can cause a service outage. You should monitor log file growth and implement a mechanism to manually archive or delete logs as required. For details, see Configuring Logging in IIS 7.
Transport Server Considerations
Exchange 2010 offers two transport server roles that are designed for different purposes.
- Edge Transport The Edge Transport
server role is a non-domain joined transport server, usually
located in perimeter networks, that transfers messages between your
Exchange organization and external SMTP hosts. Although designed
for perimeter networks, you can also locate Edge Transport servers
on the internal network and join the server to an Active Directory
domain as a member server.
- Hub Transport The Hub Transport server
role transfers messages within the organization, including messages
between Exchange servers, messages from SMTP clients such as users
using POP3 and IMAP4, and application servers and devices.
By default, in Exchange 2010, SMTP communication is secured using TLS.
SMTP communication between Hub Transport servers Hub Transport servers in an Exchange organization use TLS to help secure SMTP communication within the organization. We recommend that you keep TLS enabled on Hub Transport servers. In Exchange 2010, organizations using non-Exchange devices or appliances to perform TLS encryption can offload TLS from Hub Transport servers to such appliances. For more details, see Disabling TLS Between Active Directory Sites to Support WAN Optimization.
SMTP communication between Hub Transport and Edge Transport servers All traffic between Hub Transport servers and Edge Transport servers is authenticated and encrypted. The underlying mechanism for authentication and encryption is mutual TLS. Instead of using X.509 validation to validate certificates, Exchange 2010 uses direct trust to authenticate certificates. Direct trust means the presence of the certificate in Active Directory or Active Directory Lightweight Directory Services (AD LDS) validates the certificate. Active Directory is considered a trusted storage mechanism. When direct trust is used, it doesn't matter whether the certificate is self-signed or signed by a certification authority (CA).When you subscribe an Edge Transport server to an Active Directory site, the Edge Subscription publishes the Edge Transport server's certificate in Active Directory. Hub Transport servers consider the published certificate valid. The Microsoft EdgeSync service updates AD LDS on Edge Transport servers that have Hub Transport server certificates, which are considered valid by the Edge Transport server.
SMTP communication between Edge Transport servers and external hosts In Exchange 2010, SMTP communication between Edge Transport servers and anonymous external hosts is secured by default using opportunistic TLS. You don't require a certificate issued by a trusted CA and no configuration steps are necessary. Receive Connectors offer TLS negotiation for inbound SMTP connections. Send Connectors also tries TLS negotiation for all outbound SMTP connections. Opportunistic TLS doesn't perform certificate validation, allowing the use of self-signed certificates. For details, see TLS Functionality and Related Terminology in Exchange 2010.
| Note: |
|---|
| By default, Hub Transport servers can't communicate with external SMTP hosts as no Receive Connectors exist on Hub Transport servers that allow anonymous hosts to communicate. You can configure Hub Transport servers to communicate with anonymous hosts. For details, see Configure Internet Mail Flow Directly Through a Hub Transport Server. We don't recommend this topology because it increases security risks by exposing to the Internet the Exchange 2010 server and all roles installed on that server. We recommend that you implement a perimeter network-based SMTP gateway, such as the Edge Transport server, instead. |
SMTP communication between Hub or Edge Transport servers and smart hosts In Exchange 2010, you can configure a Send Connector to route mail for remote domains, including Internet mail, to a SMTP gateway generally residing on the perimeter network. Although it's possible to create a Send Connector to route e-mail to a smart host without using any authentication, we recommend that you use appropriate authentication for such connectors. If you use Basic authentication, we recommend using Basic authentication over TLS. If you select the externally secured option, it's assumed that authentication is performed using a non-Exchange mechanism such as IPsec. When you configure the connector with the address of a smart host, you can use either the smart host's IP address or its fqdn. We recommend using the smarthost's IP address because it offers protection against DNS poisoning, versus the convenience of using the FQDN.
Using Domain Security for SMTP communication with partners In Exchange 2010, you can use Domain Security to help secure message communication paths with partner domains. Domain Security uses mutual TLS to provide session-based encryption and authentication. For mutual TLS authentication, the source and destination hosts verify the connection by performing X.509 certificate validation. Transport servers communicating with partner domains configured for Domain Security require a certificate signed by a trusted third party or an internal certification authority. If using an internal CA, the certificate revocation list (CRL) must be published and reachable by the partner host. For details, see the following topics:
Exchange 2010 uses the default SMTP port (TCP port 25) for SMTP communication. Exchange Setup creates the required firewall rules in Windows Firewall with Advanced Security to allow communication over default ports. If you specify a different port for a connector, Exchange doesn't modify firewall rules or automatically create a new rule to allow communication over the nondefault port. You must manually modify firewall configuration to allow communication over nondefault ports. When you configure a receive connector for a nondefault port, the SMTP clients submitting messages to the connector must also be configured to use the nondefault port.
In Exchange 2010, you can locate the Hub Transport server role on an Exchange 2010 Mailbox server. This includes a Mailbox server that's a member of a Database Availability Group (DAG). We recommend that you don't locate the Hub Transport server role on a Mailbox server, especially in topologies where no Edge Transport servers are deployed, in order to isolate Mailbox servers from the Internet. You can locate Hub Transport server role on Client Access servers. You must follow the sizing guidelines for each server role when collocating server roles on the same server.
When specifying a smart host for a Send Connector on a Hub Transport or an Edge Transport server, we recommend that you use IP addresses instead of the fully qualified domain name (FQDN) of a smart host, to protect from DNS poisoning and spoofing. This also minimizes the effect of any DNS outages on the transport infrastructure. DNS servers used in perimeter networks must be used only for outbound resolution. The perimeter DNS servers may contain records for Hub Transport servers. You can also use Hosts files on Edge Transport servers to avoid creating records for Hub Transport servers on DNS servers located in perimeter networks.
In addition to the steps discussed in this section, you should consider using sufficient message size restrictions on connectors, and message throttling settings on transport servers. For more details, see the following topics:
Unified Messaging Considerations
When planning to deploy Unified Messaging (UM) server role, you must consider the different communication channels used by UM to communicate with IP gateways or IP PBX.
By default, when you create a UM dial plan, it will communicate in an unsecured mode. Also, the Unified Messaging servers associated with the UM dial plan will send and receive data from IP gateways, IP PBXs, and other Exchange 2010 computers by using no encryption. In unsecured mode, both the Real-Time Transport Protocol (RTP) media channel and SIP signaling information won't be encrypted.
You can configure a Unified Messaging server to use mutual TLS to encrypt the SIP and RTP traffic sent and received from other devices and servers. When you add a Unified Messaging server to a UM dial plan and configure the dial plan to use SIP secured mode, only the SIP signaling traffic will be encrypted, and the RTP media channels will still use TCP. TCP isn't encrypted. However, if you add a Unified Messaging server to a UM dial plan and configure the dial plan to use secured mode, both the SIP signaling traffic and the RTP media channels are encrypted. A secure signaling media channel that uses Secure Real-Time Transport Protocol (SRTP) also uses mutual TLS to encrypt the VoIP data.
If the IP gateway or IP PBX you use supports IPsec, you can also use IPsec to help secure the communication between a UM server and the IP gateway or IP PBX.
For more details, see Understanding Unified Messaging VoIP Security.
UM also submits messages such as missed call notifications and voice mail messages to Hub Transport servers. By default, this communication occurs over SMTP using TLS encryption.
You can configure a UM mailbox policy for PIN-less access. This allows a caller to access voice mail without having to enter a PIN, based on the CallerID of the call. Spoofing of CallerID is insignificant. We recommend that you not enable PIN-less access to voice mail. Also, we recommend that you review the default PIN settings and configure them to meet your organization's security requirements. The following settings can be configured for a UM mailbox policy using the Set-UMMailboxPolicy cmdlet.
Parameters to control user PIN for voice mail access
| Parameter | Description |
|---|---|
|
AllowCommonPatterns |
The AllowCommonPatterns parameter specifies whether to allow obvious PINs. Examples of obvious PINs include subsets of the telephone number, sequential numbers, or repeated numbers. If set to $false, sequential and repeated numbers and the suffix of the mailbox extension are rejected. If set to $true, only the suffix of the mailbox extension is rejected. |
|
AllowPinlessVoiceMailAccess |
The AllowPinlessVoiceMailAccess parameter specifies whether users associated with the UM mailbox policy are required to use a PIN to access their voice mail. A PIN is still required to access their e-mail and calendar. Default disabled
( |
|
LogonFailusresBeforePINReset |
The LogonFailuresBeforePINReset parameter specifies the number of sequential unsuccessful logon attempts before the mailbox PIN is automatically reset. To disable this feature, set this parameter to Unlimited. If this parameter isn't set to Unlimited, it must be set to less than the value of the MaxLogonAttempts parameter. The range is from 0 through 999. Default 5 failures. |
|
MaxLogonAttempts |
The MaxLogonAttempts parameter specifies the number of times users can try unsuccessfully to log on, in sequence, before the UM mailboxes are locked. The range is from 1 through 999. Default 15 attempts. |
|
MinPINLength |
The MinPINLength parameter specifies the minimum number of digits required in a PIN for UM-enabled users. The range is from 4 through 24. Default 6 digits |
|
PINHistoryCount |
The PINHistoryCount parameter specifies the number of previous PINs that are remembered and aren't allowed during a PIN reset. This number includes the first time that the PIN was set. The range is from 1 through 20. Default 5 PINs |
|
PINLifetime |
The PINLifetime parameter specifies the number of days until a new password is required. The range is from 1 through 999. If you specify Unlimited, the users' PINs won't expire. Default 60 days |
In Exchange 2010, voice mail messages can be marked as protected. Voice mail messages are protected using Information Rights Management (IRM). You can configure voice mail protection settings by configuring the following parameter in a UM mailbox policy. For more details, see the following topics:
Protected voice mail parameters
| Parameter | Description |
|---|---|
|
ProtectAuthenticatedVoicemail |
The ProtectAuthenticatedVoiceMail parameter specifies whether Unified Messaging servers that answer Outlook Voice Access calls for UM-enabled users associated with the UM mailbox policy create protected voice mail messages. If the value is set to Private, only messages marked as private are protected. If the value is set to All, every voice mail message is protected. Default None (No protection is applied to voice mail messages) |
|
ProtectUnauthenticatedVoiceMail |
The ProtectUnauthenticatedVoiceMail parameter specifies whether the Unified Messaging servers that answer calls for UM-enabled users associated with the UM mailbox policy create protected voice mail messages. This also applies when a message is sent from a UM auto attendant to a UM-enabled user associated with the UM mailbox policy. If the value is set to Private, only messages marked as private are protected. If the value is set to All, every voice mail message is protected. Default None (No protection is applied to voice mail messages) |
|
RequireProtectedPlayOnPhone |
The RequireProtectedPlayOnPhone parameter specifies whether users associated with the UM mailbox policy can only use Play on Phone for protected voice mail messages or whether users can use multimedia software to play the protected message. Default |
| Important: |
|---|
| For UM servers to continue to answer calls, it's critical that they have access to Active Directory. We recommend that you monitor Active Directory availability |
Appendix 1: Additional Security-Related Documentation
This section contains links to additional security-related Exchange documentation.
Anti-Spam and Antivirus Functionality
Certificates
- Understanding TLS
Certificates
- Managing SSL
for a Client Access Server
- Configure
SSL for Exchange ActiveSync
- Configure
SSL for Outlook Anywhere
- Configuring
TLS and SSL for POP3 and IMAP4 Access
- Configure
Outlook Web App Virtual Directories to Use SSL
- Create a New
Exchange Certificate
- Import an
Exchange Certificate
- View
Exchange Certificate Properties
- Assign
Services to a Certificate
Client Authentication and Security
Outlook Web App
- Managing
Outlook Web App Security
- Configure
Outlook Web App Virtual Directories to Use SSL
- Setting Up
Forms-Based Authentication for Outlook Web App
- Setting Up
Standard Authentication Methods for Outlook Web App
- Configure Outlook Web App to Work with Active Directory
Federation Services
- Outlook Web
App and S/MIME
Outlook Anywhere
POP3 and IMAP
Permissions
- Exchange
2010 Deployment Permissions Reference
- Understanding Role Based
Access Control
- Understanding Split
Permissions
- Understanding
Permissions Coexistence with Exchange 2003
- Understanding
Permissions Coexistence with Exchange 2007
- Understanding
Multiple-Forest Permissions
- Feature
Permissions
- Managing
Administrator and Specialist Users
- Managing End
Users
- Management
Roles and Role Entries
- Management
Role Scopes
- Management
Role Assignments
- Managing
Split Permissions
- Permissions
to Manage Mailbox Servers
- Securing
Unified Messaging Servers