The following tools are provided by Microsoft to help create a secure environment. Run the following tools before you install Exchange 2007:

• Microsoft Update
  
• Exchange Best Practices Analyzer
  
• Microsoft Baseline Security Analyzer
  
• Internet Information Services (IIS) Lockdown Tool and URLScan, only for environments in which you are running Windows Server 2003 after you have upgraded from Windows 2000 Server.
  
• Exchange templates for the Security Configuration Wizard (SCW)
  

 Microsoft Update

Microsoft Update is a new service that offers the same downloads as Windows Update—plus the latest updates for other Microsoft programs. It can help keep your computer 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 (or 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 is installed on your computer for any current and past high-priority updates it requires and then download and install them automatically. After that, whenever you connect to the Internet, Windows repeats this update process for any new high-priority updates.

Note:
If you're already using Automatic Updates, Microsoft Update will continue to operate it as you've set it up.

To enable Microsoft Update, see Microsoft Update [ http://go.microsoft.com/fwlink/?linkid=54836 ] . 

The default mode of Microsoft Update requires that each Exchange computer is connected to the Internet to receive automatic updates. If you are running servers that are not 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 Exchange Server computers to contact your internal WSUS server for updates. For more information, see Microsoft Windows Server Update Services 3.0 [ http://go.microsoft.com/fwlink/?LinkId=96605 ] . 

WSUS is not the only Microsoft Update management solution available. For more information about which Microsoft Update management solution best meets your needs, see MBSA, MU, WSUS, Essentials 2007 or SMS 2003? [ http://go.microsoft.com/fwlink/?LinkId=96606 ] .

 Anti-Spam Updates

Exchange 2007 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 for download every two weeks.

Manual updates from Microsoft Update do not 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.

Note:
Forefront Anti-spam Automatic Updates is a premium feature that requires either an Exchange Enterprise client access license (CAL) for each user mailbox, or a Forefront Security for Exchange Server license.

For more information about how to enable Forefront Anti-spam Automatic Updates, see Anti-Spam Updates [ http://technet.microsoft.com/en-us/library/bb124241.aspx ] .

 Microsoft Exchange Best Practices Analyzer

The Exchange Best Practices Analyzer is one of the most effective tools that you can regularly run to help verify that your Exchange environment is secure. The Exchange Best Practices Analyzer automatically examines your Microsoft Exchange deployment and determines whether the configuration is set according to Microsoft best practices. You can install the Exchange Best Practices Analyzer on a client computer that is running Microsoft .NET Framework 1.1. With the appropriate network access, the Exchange Best Practices Analyzer examines all your Active Directory directory service and Exchange servers.

For more information, including best practices, see the "Running Exchange Best Practices Analyzer" section later in this guide and Microsoft Exchange Best Practices Analyzer v2.8 [ http://go.microsoft.com/fwlink/?LinkId=34705 ] .

 Microsoft Baseline Security Analyzer

Microsoft Baseline Security Analyzer (MBSA) is a tool that was designed for the IT professional to help small and medium-sized businesses determine their security state in compliance with Microsoft security recommendations. Improve your security management process by using MBSA to detect common security misconfigurations and missing security updates on your computer systems. 

You can download the MBSA at Microsoft Baseline Security Analyzer [ http://go.microsoft.com/fwlink/?linkid=17809 ] .

 IIS Lockdown Tool and URLScan

By default, IIS version 6.0 and IIS version 7.0, which is installed with Windows Server and Windows Server 2008 respectively, have security-related configuration settings that are similar to those made by the IIS Lockdown Tool. Therefore, you do not have to run the IIS Lockdown Tool on Web servers that are running IIS version 6.0 or IIS version 7.0. However, if you are upgrading from an earlier version of IIS to IIS version 6.0 or IIS version 7.0, we recommend that you run the IIS Lockdown Tool to enhance the security of your Web server. 

We recommend that you do not run URLScan with IIS version 6.0 or IIS version 7.0 because the risk of misconfiguration is much more than the benefit that URLScan provides.

For more information, see How To : Use IISLockdown.exe [ http://go.microsoft.com/fwlink/?LinkId=96607 ] .

 Exchange 2007 Templates for the Security Configuration Wizard

The Security Configuration Wizard (SCW) is a tool that was introduced with Windows Server 2003 Service Pack 1. Use the SCW to minimize the attack surface for servers by disabling Windows functionality that is not required for Exchange 2007 server roles. The SCW automates the security best practice of reducing attack surface for a server. The SCW uses a role-based metaphor to solicit services that are required for the applications on a server. This tool reduces the susceptibility of Windows environments to exploitation of security vulnerabilities.

For more information about how to create Exchange 2007 templates for the SCW, see the section, "Using the Security Configuration Wizard to Secure Windows for Exchange Server Roles," later in this guide.

This section provides best practice recommendations for keeping your Exchange 2007 environment secure.

 Running the Exchange Best Practices Analyzer

As mentioned in the previous section, the Exchange Best Practices Analyzer is one of the most effective tools that you can regularly run to help verify that your Exchange environment is secure.

For most environments, we recommend running the Exchange Best Practices Analyzer at least one time per quarter. However, it is a best practice to run it one time per month on all servers that are running Exchange Server is installed.

Additionally, you should run the Exchange Best Practices Analyzer in the following scenarios:

• Whenever you make significant configuration changes to an Exchange server. For example, you should run it after you add or remove connectors or create an EdgeSync connection to an Edge Transport server.
  
• Immediately after you have installed a new Exchange server role or removed an Exchange server role.
  
• After you install a Windows service pack or Exchange Server service pack.
  
• After you install third-party software on a computer that is running Microsoft Exchange.
  

 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 practice recommendations for the deployment of antivirus software for Exchange 2007 and Microsoft Office Outlook 2007.

You should pay extra attention to two important changes in Exchange 2007 when you select an antivirus software vendor:

• Exchange 2007 is based on a 64-bit architecture.
  
• As described in more detail later in this topic, Exchange 2007 includes new transport agent functionality.
  

These two changes mean that antivirus vendors must provide Exchange 2007–specific software. Antivirus software that is written for earlier versions of Exchange Server is unlikely to operate correctly with Exchange 2007.

To use a defense-in-depth approach, we recommend that you deploy antivirus software that is designed for messaging systems at either the Simple Mail Transfer Protocol (SMTP) gateway or at the Exchange servers that host mailboxes, in addition antivirus software on the user desktop.

You decide what types of antivirus software to use and where the software is deployed by finding the appropriate balance between the cost that you are willing to tolerate and the risk that 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 gateway, general file-level protection at the mail server, and 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 is 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

The most important position for messaging antivirus software is at the first line of defense in your organization. In Exchange 2007, the first line of defense is at the perimeter network on the Edge Transport server.

To better guard against virus outbreaks from inside the organization and to provide as a second line of defense, we also recommend that you run transport-based antivirus software on the Hub Transport servers inside your organization.

In Exchange 2007, agents act on transport events, much like event sinks in earlier versions of Microsoft Exchange. Third-party developers can write customized agents to take advantage of the underlying Exchange MIME-parsing engine for robust transport-level antivirus scanning.

Many third-party software vendors provide Exchange 2007–specific agents that take advantage of the Exchange transport MIME-parsing engine. Contact your antivirus vendor for more information.

In addition, Microsoft Forefront Security for Exchange Server includes a transport antivirus agent for Exchange 2007. For more information about how to install and configure the Forefront Security for Exchange Server antivirus agent, see Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server [ http://go.microsoft.com/fwlink/?LinkId=96630 ] .

Note:
Objects that are not routed through transport, such as items in public folders, Sent Items, and calendar items, which can only be scanned on a Mailbox server, are not protected by transport-only virus scanning.

 Running Antivirus Software on Other Computers in the Organization

You can run file-level virus scanning on the following two classes of computers:

• User desktops
  
• Servers
  

In addition to file-level virus scanning, consider running a Microsoft VSAPI solution on your Exchange Mailbox server.

Desktop Virus Scanning

We strongly recommend that your users run the latest version of Outlook. If you run outdated e-mail clients on the desktop, you take a serious risk because of the object model and attachment-handling behavior in older e-mail clients. By default therefore, Microsoft Office Outlook 2003 and Office Outlook 2007 are the only MAPI clients from which Exchange 2007 accepts connections. For more information about the risks associated with running older versions of e-mail clients, see Taking Steps to Secure Outlook [ http://go.microsoft.com/fwlink/?LinkId=77565 ] .

After you have upgraded to Outlook 2003 or Outlook 2007, verify that you have installed a file-level antivirus software product on all desktop computers. In addition, take the following steps:

• Develop a plan to make sure that antivirus signature files are automatically updated on all desktops.
  
• Make sure that you develop and maintain an end-to-end update management solution in your organization to battle viruses.
  

Server Virus Scanning

Consider adopting a general policy to run file-level scanning on all desktop and server computers in your organization. Therefore, all Exchange Server computers should have some form of file-level antivirus scanning running on them. For each server role, you must perform additional configuration to file-level scanning so that certain directories, file types, and processes are not scanned. For example, we recommend that you never run file-level antivirus software against the Exchange store databases. For specific configuration information, see File-Level Antivirus Scanning on Exchange 2007 [ http://technet.microsoft.com/en-us/library/bb332342.aspx ] .

Mailbox Database Scanning with VSAPI

A Microsoft Virus Scanning API (VSAPI) scanning solution may be an important layer of defense for many organizations. You should consider running a VSAPI antivirus solution if either of the following conditions is true:

• Your organization does not have complete and reliable desktop antivirus scanning products deployed.
  
• Your organization wants the additional protection that store scanning can provide.
  
• Your organization has developed custom applications that have programmatic access to an Exchange database.
  
• Your user community routinely posts messages into 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 is submitted to a database by CDO (Collaboration Data Objects), WebDAV, and Exchange Web services.

In addition, when a virus outbreak does occur, frequently a VSAPI antivirus solution provides the quickest way to remove and eliminate viruses from an infected mail store.

For more specific information about how to run Forefront Security for Exchange Server, which includes a VSAPI scanning engine, see Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server [ http://go.microsoft.com/fwlink/?LinkId=96630 ] .

 Using Exchange Hosted Services

Spam and virus filtering is enhanced 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 them satisfy retention requirements for compliance
  
• Hosted Encryption, which helps them encrypt data to preserve confidentiality
  
• Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations
  

These services integrate with any on-premise Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services [ http://go.microsoft.com/fwlink/?LinkId=73160 ] .

 More Antivirus Information

For a detailed white paper about how MSIT deployed an Exchange 2007 server antivirus solution, see Microsoft Exchange Server 2007 Edge Transport and Messaging Protection [ http://go.microsoft.com/fwlink/?LinkID=86915 ] .

Forefront Security for Exchange Server provides a multiple scanning engine antivirus solution for Exchange Transport server roles and a VSAPI solution for the Exchange Mailbox server. For best practices about an end-to-end antivirus solution, see Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server [ http://go.microsoft.com/fwlink/?LinkId=96630 ] .

 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 across all computers in your organization.

In addition to Microsoft software, make sure that you run the latest updates for all software that is running in your organization.

 Blocking Legacy Outlook Clients

Older versions of Outlook contained vulnerabilities that can potentially increase the spread of viruses. As a best practice, you should allow Exchange 2007 to only accept MAPI connections from the Outlook 2007,, Outlook 2003, and Outlook 2002 clients. By restricting the versions of Outlook clients that can connect to Exchange, you can greatly reduce the risk of virus and other malware attacks. As a best practice, we recommend that you reduce and standardize the software versions that run in your organization.

For more information about how to remove Outlook client access to Exchange 2007, see All versions of Outlook are allowed to access the server [ http://go.microsoft.com/fwlink/?LinkId=96609 ] .

 Running Attachment Filtering

In Exchange 2007, attachment filtering lets you apply filters at the server level to control the attachments that users receive. Attachment filtering is increasingly important in today's environment, where many attachments 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.

Note:
As a best practice, don't remove attachments from digitally signed, encrypted, or rights-protected e-mail messages. If you remove attachments from such messages, you invalidate the digitally signed messages and make encrypted and rights-protected messages unreadable.

 Types of Attachment Filtering in Exchange 2007

You can use the following types of attachment filtering to control attachments that enter or leave your organization:

• 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 is a JPEG image, an executable file, a Microsoft Office Excel 2003 file, or some other file type. Content types are expressed as type/subtype. For example, the JPEG image content type is expressed as image/jpeg.
  To view a complete list of all file name extensions and content types that attachment filtering can filter on, run the following command:
  
  Get-AttachmentFilterEntry | FL

  To run the Get-AttachmentFilterEntry cmdlet on a computer that is joined to a domain, you the account you use must be delegated Exchange View-Only Administrators role.
  To run the Get-AttachmentFilterEntry cmdlet on a computer that has the Edge Transport server role installed, you must log on by using an account that is a member of the local Administrators group on that computer.
  For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations [ http://technet.microsoft.com/en-us/library/aa996881.aspx ] .
  

If an attachment matches one of these filtering criteria, you can configure one of the following actions to be performed on the attachment:

• Block whole message and attachment   An attachment that matches an attachment filter together with its whole e-mail message can be blocked from entering the messaging system. If an attachment and e-mail message are blocked, the sender receives a delivery status notification (DSN) message that states that the message contains an unacceptable attachment file name.
  
• Strip attachment but allow message through   An attachment that matches an attachment filter can be removed whereas the e-mail message and any other attachments that do not match the filter are allowed through. If an attachment is stripped, it is replaced with a text file that explains why the attachment was removed. This action is the default setting.
  
• Silently delete message and attachment   An attachment that matches an attachment filter together with its whole e-mail message can be blocked from entering the messaging system. If an attachment and e-mail message are blocked, neither the sender nor the recipient receives notification.
  

  Caution:
  You cannot retrieve e-mail messages and attachments that are blocked or attachments that are stripped. When you configure attachment filters, make sure that you carefully examine all possible file name matches and verify that legitimate attachments will not be affected by the filter.

For more information, see How to Configure Attachment Filtering [ http://technet.microsoft.com/en-us/library/aa997139.aspx ] .

 File Filtering by Using Forefront Security for Exchange Server

The file filtering functionality that is provided by Forefront Security for Exchange Server includes advanced features that are unavailable in the default Attachment Filter agent that is included with Exchange Server 2007 Standard Edition.

For example, container files, which are files that contain other files, can be scanned for offending file types. Forefront Security for Exchange Server filtering can scan the following container files and act upon embedded files:

• PKZip (.zip)
  
• GNU Zip (.gzip)
  
• Self-extracting ZIP archives
  
• Zip files (.zip)
  
• Java archive (.jar)
  
• TNEF (winmail.dat)
  
• Structured storage (.doc, .xls, .ppt, and more)
  
• MIME (.eml)
  
• SMIME (.eml)
  
• UUEncode (.uue)
  
• Unix tape archive (.tar)
  
• RAR archive (.rar)
  
• MACBinary (.bin)
  

Note:

The default Attachment Filter agent that is included with Exchange 2007 Standard Edition detects file types even if they have been renamed. Attachment filtering also makes sure that compressed Zip and LZH files do not contain blocked attachments by performing a file name extension match against the files in the compressed Zip or LZH file. Forefront Security for Exchange Server file filtering has the additional capability of determining if a blocked attachment has been renamed within a container file.

You can also filter files by file size. Additionally, you can configure Forefront Security for Exchange Server to quarantine filtered files or to send e-mail notifications based on file filter matches.

For more information, see Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server [ http://go.microsoft.com/fwlink/?LinkId=96630 ] .

 Enforcing Strong Passwords in Your Organization

Most users log on to their local computer and to remote computers by using a combination of their user name and a password typed at the keyboard. Although alternative technologies for authentication, such as biometrics, smartcards, and one-time passwords, are available for all popular operating systems, most organizations still rely on traditional passwords and will continue to do this for years to come. Therefore, it is very important that organizations define and enforce password policies for their computers. This includes mandating the use of strong passwords. Strong passwords meet several requirements for complexity that make passwords more difficult for an attacker to determine. Among these requirements are requirements for password length and character categories. By establishing strong password policies for your organization, you can help prevent an attacker from impersonating users and so help prevent the loss, exposure, or corruption of sensitive information.

For more information, see Enforcing Strong Password Usage Throughout Your Organization [ http://go.microsoft.com/fwlink/?LinkId=96610 ] .

 Decoupling Windows Usernames and SMTP Addresses

By default, when you create a mailbox for a user, the resulting SMTP address for that user is username@contoso.com, where username is the Windows user account name.

It is a best practice to create a new SMTP address for users to obfuscate the Windows user names from malicious users.

For example, consider the user Kweku Ako-Adjei, with a Windows user name of KwekuA. To obfuscate the Windows user name, the administrator can create an SMTP address of Kweku.Ako-Adjei@contoso.com.

Using a separate SMTP address is not considered a very strong security measure. However, it does create one more hurdle for malicious users who may try to hack into your organization by using a known username.

For more information about how to add SMTP addresses for existing users, see How to Create an E-Mail Address Policy [ http://technet.microsoft.com/en-us/library/bb124401.aspx ] .

 Managing Client Access Security

The Client Access server role provides access to Microsoft Outlook Web Access, Microsoft Exchange ActiveSync, Outlook Anywhere, Post Office Protocol version 3 (POP3), and Internet Message Access Protocol version 4rev1 (IMAP4). In addition, it supports the Autodiscover service and the Availability service. Each of these protocols and services has unique security needs.

 Managing Authentication

One of the most important security-related tasks that you can perform for the Client Access server role is to configure an authentication method. The Client Access server role is installed with a default self-signed digital certificate. A digital certificate does two things:

• It authenticates that its holder is who or what they claim to be.
  
• It protects data exchanged online from theft or tampering.
  

Although the default, self-signed certificate is supported for Exchange ActiveSync and Outlook Web Access, it is not the most secure method of authentication. In addition, it is not supported for Outlook Anywhere. For additional security, consider configuring your Exchange 2007 Client Access server to use a trusted certificate from either a third-party commercial certification authority (CA) or a trusted Windows Public Key Infrastructure (PKI) CA. You can configure authentication separately for Exchange ActiveSync, Outlook Web Access, Outlook Anywhere, POP3, and IMAP4.

For more information about how to configure authentication, see the following topics:

• Configuring Forms-Based Authentication for Outlook Web Access [ http://technet.microsoft.com/en-us/library/bb123719.aspx ]
  
• Configuring Authentication for POP3 and IMAP4 [ http://technet.microsoft.com/en-us/library/aa997188.aspx ]
  
• Configuring Standard Authentication Methods for Outlook Web Access [ http://technet.microsoft.com/en-us/library/bb125207.aspx ]
  

 Enhancing Secure Communications Between the Client Access Server and Other Servers

After you optimize the security of your communications between clients and the Exchange 2007 server, you must optimize the security of the communications between the Exchange 2007 server and other servers in your organization. By default, HTTP, Exchange ActiveSync, POP3, and IMAP4 communication between the Client Access server and other servers, such as Exchange 2007 servers that have the Mailbox server role installed, domain controllers, and global catalog servers, is encrypted.

For more information about how to manage security for the various components of your Client Access server, see the following topics:

• Managing Outlook Web Access Security [ http://technet.microsoft.com/en-us/library/bb124507.aspx ]
  
• Managing Outlook Anywhere Security [ http://technet.microsoft.com/en-us/library/aa997193.aspx ]
  
• Managing POP3 and IMAP4 Security [ http://technet.microsoft.com/en-us/library/bb123960.aspx ]
  
• Managing Exchange ActiveSync Security [ http://technet.microsoft.com/en-us/library/bb232020.aspx ]
  
• Managing SSL for a Client Access Server [ http://technet.microsoft.com/en-us/library/bb310795.aspx ]
  
• Using ISA Server 2006 with Exchange 2007 [ http://technet.microsoft.com/en-us/library/aa998036.aspx ]
  

Return to top

The following table provides information about ports, authentication, and encryption for data paths between Hub Transport servers and Edge Transport servers, and to and from other Exchange 2007 servers and services.

Transport server data paths

Data path	Required ports	Default authentication	Supported authentication	Encryption supported?	Encrypted by default?
Hub Transport server to Hub Transport server	25/TCP (Secure Sockets Layer [SSL]), 587/TCP (SSL)	Kerberos	Kerberos	Yes (TLS)	Yes
Hub Transport server to Edge Transport server	25/TCP (SSL)	Direct trust	Direct trust	Yes (TLS)	Yes
Edge Transport server to Hub Transport server	25/TCP (SSL)	Direct trust	Direct trust	Yes (TLS)	Yes
Edge Transport server to Edge Transport server	25/TCP (SSL), 389/TCP/UDP, and 80/TCP (certificate authentication)	Anonymous, Certificate	Anonymous, Certificate	Yes (TLS)	No
Mailbox server to Hub Transport server via the Microsoft Exchange Mail Submission Service	135/TCP (RPC)	NTLM. If connecting with a service account (local), Kerberos is used.	NTLM/Kerberos	Yes (RPC encryption)	Yes
Hub Transport to Mailbox server via MAPI	135/TCP (RPC)	NTLM. If connecting with a service account (local), Kerberos is used.	NTLM/Kerberos	Yes (RPC encryption)	Yes
Microsoft Exchange EdgeSync service	50636/TCP (SSL), 50389/TCP (No SSL)	Basic	Basic	Yes (LDAPS)	Yes
Active Directory Application Mode (ADAM) directory service on Edge Transport server	50389/TCP (No SSL)	NTLM/Kerberos	NTLM/Kerberos	No	No
Active Directory directory service access from Hub Transport server	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Yes (Kerberos encryption)	Yes

 Notes on Transport Servers

All traffic between Hub Transport servers is encrypted by using TLS with self-signed certificates that are installed by default by Exchange 2007 Setup.

All traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. The underlying mechanism for authentication and encryption is mutual TLS. Instead of using X.509 validation, Exchange 2007 uses direct trust to authenticate the certificates. Direct trust means that the presence of the certificate in Active Directory or ADAM validates the certificate. Active Directory is considered a trusted storage mechanism. When direct trust is used, it doesn't matter if the certificate is self-signed or signed by a certification authority. When you subscribe an Edge Transport server to the Exchange organization, the Edge Subscription publishes the Edge Transport server certificate in Active Directory for the Hub Transport servers to validate. The Microsoft Exchange EdgeSync service updates ADAM with the set of Hub Transport server certificates for the Edge Transport server to validate.

By default, traffic between Edge Transport servers in different organizations is encrypted. By default, Exchange 2007 Setup creates a self-signed certificate and TLS is enabled. This allows any sending system to encrypt the inbound SMTP session to Microsoft Exchange. Also by default, Exchange 2007 tries TLS for all remote connections.

Authentication methods for traffic between Hub Transport servers and Mailbox servers differ when the Hub Transport server roles and Mailbox server roles are located on the same computer. When mail submission is local, Kerberos authentication is used. When mail submission is remote, NTLM authentication is used.

Exchange 2007 also supports Domain Security. Domain Security refers to the set of functionality in Exchange 2007 and Outlook 2007 that provides a low-cost alternative to S/MIME or other message-level over-the-Internet, security solutions. The purpose of the Domain Security feature set is to provide administrators a way to manage secured message paths between domains over the Internet. After these secured message paths are configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as "Domain Secured" in the Outlook and Outlook Web Access interface. For more information, see Planning for Domain Security [ http://technet.microsoft.com/en-us/library/bb124392.aspx ] .

Many agents may run on the Hub Transport servers and Edge Transport servers. Generally, the anti-spam agents rely on information that is local to the computer that the agents run on. Therefore, very little communication with remote computers is required. The exception is recipient filtering. This requires calls to either ADAM or Active Directory. It is a best practice to run recipient filtering on the Edge Transport server. In this case, the ADAM directory is on the same computer as the Edge Transport server and no remote communication is required. When recipient filtering has been installed and configured on the Hub Transport server, recipient filtering accesses Active Directory.

The Protocol Analysis agent is used by the Sender Reputation feature in Exchange 2007. This agent also makes various connections to outside proxy servers to determine inbound message paths for suspect connections.

All other anti-spam functionality uses data that is collected, stored, and accessed only on the local computer. Frequently, the data, such as safelist aggregation or recipient data for recipient filtering, is pushed to the local ADAM directory by using the Microsoft Exchange EdgeSync service.

Journaling and message classification run on Hub Transport servers and rely on Active Directory data to function.

In the context of the Mailbox server role, whether the authentication is NTLM or Kerberos relies on the user or process context that the Exchange Business Logic layer consumer is running under. In this context, the consumer is any application or process that uses the Exchange Business Logic layer. In many of the "Default Authentication" cells in the "Mailbox Server data paths" table in this section, the authentication is listed as "NTLM/Kerberos."

The Exchange Business Logic layer is used to access and communicate with the Exchange store. The Exchange Business Logic layer is also known as from the Exchange store to communicate with external applications and processes.

If the Exchange Business Logic layer consumer is running as Local System, the authentication method is always Kerberos from the consumer to the Exchange store. Kerberos is used because the consumer must be authenticated by using the computer account Local System and a two-way authenticated trust must exist.

If the Exchange Business Logic layer consumer is not running as Local System, the authentication method is NTLM. For example, when an Administrator runs an Exchange Management Shell cmdlet that uses the Exchange Business Logic layer, NTLM is used.

The RPC traffic is always encrypted.

The following table provides information about ports, authentication, and encryption for data paths to and from Mailbox servers

Mailbox server data paths

Data path	Required ports	Default authentication	Supported authentication	Encryption supported?	Encrypted by default?
Log shipping (Local Continuous Replication and Cluster Continuous Replication)	445/Random port (Seeding)	NTLM/Kerberos	NTLM/Kerberos	Yes (IPsec)	No
Volume shadow copy service (VSS) backup	Local Message Block (SMB)l	NTLM/Kerberos	NTLM/Kerberos	No	No
Legacy Backup/Seeding	Random port	NTLM/Kerberos	NTLM/Kerberos	Yes (IPsec)	No
Clustering	135 /TCP (RPC) See "Notes on Mailbox Servers" after this table.	NTLM/Kerberos	NTLM/Kerberos	Yes (IPsec)	No
MAPI access	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Yes (RPC encryption)	Yes
Mailbox Assistants	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	No	No
Availability Web service (Client Access to Mailbox)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Yes (RPC encryption)	Yes
Active Directory access	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Yes (Kerberos encryption)	Yes
Content indexing	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Yes (RPC encryption)	Yes
Admin remote access (Remote Registry)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Yes (IPsec)	No
Admin remote access (SMB/File)	445/TCP (SMB)	NTLM/Kerberos	NTLM/Kerberos	Yes (IPsec)	No
Recipient Update Service RPC access	135/TCP (RPC)	Kerberos	Kerberos	Yes (RPC encryption)	Yes
Microsoft Exchange Active Directory Topology service access	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Yes (RPC encryption)	Yes
Microsoft Exchange System Attendant service legacy access (Listen to requests)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	No	No
Microsoft Exchange System Attendant service legacy access to Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Yes (Kerberos encryption)	Yes
Microsoft Exchange System Attendant service legacy access (As MAPI client)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Yes (RPC encryption)	Yes
Offline Address Book (OAB) accessing Active Directory	135/TCP (RPC)	Kerberos	Kerberos	Yes (RPC encryption)	Yes
Recipient update to Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Yes (Kerberos encryption)	Yes
DSAccess to Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)	Kerberos	Kerberos	Yes (Kerberos encryption)	Yes
Outlook accessing Offline Address Book (OAB)	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	NTLM/Kerberos	Yes (HTTPS)	No
WebDav	80/TCP, 443/TCP (SSL)	Basic, NTLM, Negotiate	Basic, NTLM, Negotiate	Yes (HTTPS)	Yes

 Notes on Mailbox Servers

For HTTP authentication where "Negotiate" is listed, Kerberos is tried first, and then NTLM.

For intra-node communications, cluster nodes communicate over User Datagram Protocol (UDP) port 3343. Each node in the cluster periodically exchanges sequenced, unicast UDP datagrams with every other node in the cluster. The purpose of this exchange is to determine whether all nodes are running correctly and to monitor the health of network links.

Although WebDav applications or clients can connect to the Mailbox server by using 80/TCP or 443/TCP, in most cases the application or clients connect to the Client Access server. The Client Access server then connects to the Mailbox server over 80/TCP or 443/TCP.

The clustering data path listed in the "Mailbox Server data paths" table in this section uses dynamic RPC (TCP) to communicate cluster status and activity between the different cluster nodes. The cluster service (ClusSvc.exe) also uses UDP/3343 and randomly allocated high TCP ports to communicate between cluster nodes.

Unless noted, client access technologies, such as Office Outlook Web Access, POP3, or IMAP4, are described by the authentication and encryption from the client application to the Client Access server.

The following table provides information about port, authentication, and encryption for data paths between Client Access servers and other servers and clients.

Client Access server data paths

Data path	Required ports	Default authentication	Supported authentication	Encryption supported?	Encrypted by default?
Autodiscover service	80/TCP, 443/TCP (SSL)	Basic/Integrated Windows authentication (Negotiate)	Basic, Digest, NTLM, Negotiate (Kerberos)	Yes (HTTPS)	Yes
Availability service	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	NTLM, Kerberos	Yes (HTTPS)	Yes
Outlook Web Access	80/TCP, 443/TCP (SSL)	Forms Based Authentication	Basic, Digest, Forms Based Authentication, NTLM (v2 only), Kerberos, Certificate	Yes (HTTPS)	Yes, using self-signed certificate
POP3	110/TCP (TLS), 995/TCP (SSL)	Basic, NTLM, Kerberos	Basic, NTLM, Kerberos	Yes (SSL, TLS)	Yes
IMAP4	143/TCP (TLS), 993/TCP (SSL)	Basic, NTLM, Kerberos	Basic, NTLM, Kerberos	Yes (SSL, TLS)	Yes
Outlook Anywhere (formerly known as RPC over HTTP )	80/TCP, 443/TCP (SSL)	Basic	Basic or NTLM	Yes (HTTPS)	Yes
Exchange ActiveSync application	80/TCP, 443/TCP (SSL)	Basic	Basic, Certificate	Yes (HTTPS)	Yes
Client Access server to Unified Messaging server	5060/TCP, 5061/TCP, 5062/TCP, a dynamic port	By IP address	By IP address	Yes (Session Initiation Protocol [SIP] over TLS)	Yes
Client Access server to a Mailbox server that is running an earlier version of Exchange Server	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	Negotiate (Kerberos with fallback to NTLM or optionally Basic,) POP/IMAP plain text	Yes (IPsec)	No
Client Access server to Exchange 2007 Mailbox server	RPC. See "Notes on Client Access Servers" after this table.	Kerberos	NTLM/Kerberos	Yes (RPC encryption)	Yes
Client Access server to Client Access server (Exchange ActiveSync)	80/TCP, 443/TCP (SSL)	Kerberos	Kerberos, Certificate	Yes (HTTPS)	Yes, using self-signed certificate
Client Access server to Client Access server (Outlook Web Access)	80/TCP, 443/TCP (SSL)	Kerberos	Kerberos	Yes (HTTPS)	Yes
WebDAV	80/TCP, 443/TCP (SSL)	HTTP Basic or Outlook Web Access forms-based authentication	Basic, Outlook Web Access forms-based authentication	Yes (HTTPS)	Yes

 Notes on Client Access Servers

The Client Access server communicates to the Mailbox server by using many ports. With some exceptions, those ports are determined by the RPC service and are not fixed.

For HTTP authentication where "Negotiate" is listed, Kerberos is tried first, and then NTLM is tried.

When an Exchange 2007 Client Access server is communicating with a Mailbox server that is running Exchange Server 2003, it is a best practice to use Kerberos and disable NTLM authentication and Basic authentication. Additionally, it is a best practice to configure Outlook Web Access to use forms-based authentication with a trusted certificate. For Exchange ActiveSync clients to communicate through the Exchange 2007 Client Access server to the Exchange 2003 back-end server, Integrated Windows Authentication must be enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 back end server. To use Exchange System Manager on the Exchange 2003 server to manage authentication on an Exchange 2003 virtual directory, download and install the hot fix referenced in Microsoft Knowledge Base article 937301, Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server [ http://support.microsoft.com/default.aspx?kbid=937031 ] . 

For more information, see Managing Client Access Security [ http://technet.microsoft.com/en-us/library/aa998023.aspx ] .

IP gateways only support certificate-based authentication that uses mutual TLS and IP-based authentication for Session Initiation Protocol (SIP)/TCP connections. IP gateways do not support either NTLM or Kerberos authentication. Therefore, when you use IP-based authentication, the connecting IP address or addresses are used to provide authentication mechanism for unencrypted (TCP) connections. When IP-based authentication is used in Unified Messaging, the Unified Messaging server verifies that the IP address is allowed to connect. The IP address is configured on the IP gateway or IP PBX.

The following table provides information about port, authentication, and encryption for data paths between Unified Messaging servers and other servers.

Unified Messaging server data paths

Data path	Required ports	Default authentication	Supported authentication	Encryption supported?	Encrypted by default?
Unified Messaging Fax	5060/TCP, 5061/TCP, 5062/TCP, a dynamic port	By IP address	By IP address	SIP over TLS, but media is not encrypted	Yes for SIP
Unified Messaging Phone interaction (PBX)	5060/TCP, 5061/TCP, 5062/TCP, a dynamic port	By IP address	By IP address	SIP over TLS, but Media is not encrypted	Yes for SIP
Unified Messaging Web Service	80/TCP, 443/TCP (SSL)	Integrated Windows authentication (Negotiate)	Basic, Digest, NTLM, Negotiate (Kerberos)	Yes (SSL)	Yes
Unified Messaging to Hub Transport	25/TCP (SSL)	Kerberos	Kerberos	Yes (TLS)	Yes
Unified Messaging server to Mailbox server	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Yes (RPC encryption)	Yes

 Notes on Unified Messaging Servers

When you create a Unified Messaging (UM) IP gateway object in Active Directory, you must define the IP address of the physical IP gateway or IP PBX (Private Branch eXchange). When you define the IP address on the UM IP Gateway object, the IP address is added to a list of valid IP gateways that the Unified Messaging server is allowed to communicate with. When the UM IP gateway is created, it is associated with a UM dial plan. Associating the UM IP gateway with a dial plan allows the Unified Messaging servers that are associated with the dial plan to use IP-based authentication to communicate with the IP gateway. If the UM IP gateway has not been created or it is not configured to use the correct IP address, authentication fails and the Unified Messaging servers do not accept connections from that IP gateway's IP address.

With the release to manufacturing (RTM) version of Exchange 2007, a Unified Messaging server can communicate on port 5060/TCP, which is unsecured, or on port 5061/TCP, which is secured, but not on both. With Exchange 2007 Service Pack 1 (SP1), a Unified Messaging server listens on port 5060/TCP and on port 5061/TCP at the same time.

For more information, see Understanding Unified Messaging VoIP Security [ http://technet.microsoft.com/en-us/library/bb124092.aspx ] and Understanding Protocols, Ports, and Services in Unified Messaging [ http://technet.microsoft.com/en-us/library/aa998265.aspx ] .

Return to top

Exchange 2007 provides an SCW template for each Exchange 2007 server role. By using this template with the SCW, you can configure the Windows operating system to lock down services and ports that are not needed for each Exchange server role. When you run the SCW, you create a custom security policy for your environment. You can apply the custom policy to all Exchange servers in your organization. You can configure the following functionality by using the SCW:

• Server role   The SCW uses the server role information to enable services and open ports in the local firewall.
  
• Client features   Servers also act as clients to other servers. Select only the client features that are required for your environment.
  
• Administration options   Select the options that are required for your environment, such as backup and error reporting.
  
• Services   Select the services that are required for the server, and set the startup mode for services that are not specified by the policy. Unspecified services are not installed on the selected server and are not listed in the security configuration database. The security policy that you configure might be applied to servers that are running different services than the server where the policy is created. You can select the policy setting that determines the action to perform when an unspecified service is found on a server that this policy is applied to. You can set the action not to change the startup mode of the service or disable the service.
  
• Network security   Select the ports to open for each network interface. Access to ports can be restricted based on the local network interface or based on remote IP addresses and subnets.
  
• Registry settings   Use the registry settings to configure protocols that are used to communicate with other computers.
  
• Audit policy   The audit policy determines which success and failure events are logged and the file system objects that are audited.
  

After you install an Exchange server role, follow these steps to configure a security policy by using the SCW:

1. Install the SCW.
   
2. Register the SCW extension.
   
3. Create a custom security policy and apply the policy to the local server.
   
4. If you have more than one Exchange server in your organization running a given role, you can apply your custom security policy to each Exchange server.
   

The following sections provide procedures for each of the previous steps.

To perform the following procedures, the account you use must be delegated the following:

• Exchange Server Administrator role and local Administrators group for the target server
  

To perform the following procedures on a computer that has the Edge Transport server role installed, you must log on by using an account that is a member of the local Administrators group on that computer.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations [ http://technet.microsoft.com/en-us/library/aa996881.aspx ] .

You must perform this procedure on each Exchange 2007 server to which you want to apply a SCW security policy by using the SCW.

To install the Security Configuration Wizard

1. In Control Panel, click Add or Remove Programs.

2. Click Add/Remove Windows Components to start the Windows Components Wizard.

3. In the Windows Components dialog box, select the Security Configuration Wizard check box, and then click Next.

4. Wait for the installation to complete, and then click Finish.

To open the SCW after you perform this procedure, click Start, point to All Programs, point to Administrative Tools, and then click Security Configuration Wizard.

The Exchange Server role extensions enable you to use the SCW to create a security policy that is specific to the functionality that is required for each Microsoft Exchange server role. The extensions are provided with Exchange 2007 and must be registered before you can create a custom security policy.

You must perform the registration procedure on each Exchange 2007 server to which you want to apply an SCW security policy. Two extension files are required for the various Exchange 2007 server roles. For the Mailbox, Hub Transport, Unified Messaging, and Client Access server roles, register the Exchange2007.xml extension file. For the Edge Transport server role, register the Exchange2007Edge.xml extension file.

To register the Security Configuration Wizard extension on a computer running the Mailbox, Hub Transport, Unified Messaging, or Client Access server role

1. Open a Command Prompt window. Type the following command to use the SCW command-line tool to register the Exchange 2007 extension with the local security configuration database:

   scwcmd register /kbname:Ex2007KB /kbfile:"%programfiles%\Microsoft\Exchange Server\scripts\Exchange2007.xml"

2. To verify that the command has completed successfully, you can view the SCWRegistrar_log.xml file that is located in the %windir%\security\msscw\logs directory.

To register the Security Configuration Wizard extension on a computer running the Edge Transport server role

1. Open a Command Prompt window. Type the following command to use the SCW command-line tool to register the Exchange 2007 extension with the local security configuration database:

   scwcmd register /kbname:Ex2007EdgeKB /kbfile:"%programfiles%\Microsoft\Exchange Server\scripts\ Exchange2007Edge.xml"

2. To verify that the command has completed successfully, you can view the SCWRegistrar_log.xml file that is located in the %windir%\security\msscw\logs directory.

Use this procedure to create a custom security policy for your specific environment. After you create a custom policy, you use the policy to apply the same level of security to each Exchange 2007 server that is running the same server role or roles in your organization.

To use the Security Configuration Wizard to create a custom security policy

1. Click Start, point to All Programs, point to Administrative Tools, and then click Security Configuration Wizard to start the tool. Click Next on the welcome screen.

2. On the Configuration Action page, select Create a new security policy, and then click Next.

3. On the Select Server page, verify that the correct server name appears in the Server (use DNS name, NetBIOS name, or IP address): field. Click Next.

4. On the Processing Security Configuration Database page, wait for the progress bar to complete, and then click Next.

5. On the Role-Based Service Configuration page, click Next.

6. On the Select Server Roles page, select the Exchange 2007 roles that you have installed on the computer, and then click Next.

7. On the Select Client Features page, select each client feature that is required on your Exchange server, and then click Next.

8. On the Select Administration and Other Options page, select each administration feature that is required on your Exchange server, and then click Next.

9. On the Select Additional Services page, select each service that is required to be enabled on the Exchange server, and then click Next.

10. On the Handling Unspecified Services page, select the action to perform when a service that is currently not installed on the local server is found. You can select to take no action by selecting Do not change the startup mode of the service, or you can select to automatically disable the service by selecting Disable the service. Click Next.

11. On the Confirm Service Changes page, review the changes that this policy will make to the current service configuration. Click Next.

12. On the Network Security page, verify that Skip this section is not selected, and then click Next.

13. On the Open Ports and Approve Applications page, if you are running the SCW on an Edge Transport server, you must add two ports for LDAP communication to Active Directory Application Mode (ADAM).

    1. Click Add. On the Add Port or Application page, in the Port number: field, enter 50389. Select the TCP check box, and then click OK.
       
    2. Click Add. On the Add Port or Application page, in the Port number: field, enter 50636. Select the TCP check box, and then click OK.
       

14. (Edge Transport server only) On the Open Ports and Approve Applications page, you must configure the ports for each network adapter.

    1. Select Port 25, and then click Advanced. On the Port Restrictions page, click the Local Interface Restrictions tab. Select Over the following local interfaces:, select both the internal network adapter and external network adapter check boxes, and then click OK.
       
    2. Select Port 50389, and then click Advanced. On the Port Restrictions page, click the Local Interface Restrictions tab. Select Over the following local interfaces:, select only the internal network adapter check box, and then click OK.
       
    3. Select Port 50636, and then click Advanced. On the Port Restrictions page, click the Local Interface Restrictions tab. Select Over the following local interfaces:, select only the internal network adapter check box, and then click OK.
       

    Note:
    You can also configure remote address restrictions for each port.

15. On the Open Ports and Approve Applications page, click Next.

16. On the Confirm Port Configuration page, verify that the incoming port configuration is correct, and then click Next.

17. On the Registry Settings page, select the Skip this section check box, and then click Next.

18. On the Audit Policy page, select the Skip this section check box, and then click Next.

19. On the Internet Information Services (IIS) page, select the Skip this section check box, and then click Next.

20. On the Save Security Policy page, click Next.

21. On the Security Policy File Name page, enter a file name for the security policy and an optional description. Click Next. If a restart of the server is required after the policy is applied, a dialog box will appear. Click OK to close the dialog box.

22. On the Apply Security Policy page, select Apply later or Apply now, and then click Next.

23. On the Completing the Security Configuration Wizard page, click Finish.

After you have created the policy, you can then apply it to multiple computers that are running the same role in your organization.

To use the Security Configuration Wizard to apply an existing policy

1. Click Start, point to All Programs, point to Administrative Tools, and then click Security Configuration Wizard to start the tool. Click Next on the welcome screen.

2. On the Configuration Action page, select Apply an existing security policy. Click Browse, select the XML file for your policy, and then click Open. Click Next.

3. On the Select Server page, verify that the correct server name appears in the Server (use DNS name, NetBIOS name, or IP address): field. Click Next.

4. On the Apply Security Policy page, click View Security Policy if you want to view the policy details, and then click Next.

5. On the Applying Security Policy page, wait until the progress bar indicates Application complete, and then click Next.

6. On the Completing the Security Configuration Wizard page, click Finish.

Return to top

Exchange 2007 includes two registration files for SCW. The general Exchange 2007 registration file is called Exchange2007.xml. It defines the security configuration for all Microsoft Exchange server roles, except the Edge Transport server role. The registration file for the Edge Transport server role is called Exchange2007Edge.xml. It defines the security configuration for Edge Transport servers.

The registration files are installed in the %Programfiles%\Microsoft\Exchange Server\Scripts directory when you install Exchange 2007.

Services that are enabled set the service startup value to either Automatic or Manual.

Ports that are enabled specify executable files (.exe) that are trusted by Windows Firewall to open ports for the specific application.

The Exchange 2007 registration files that are used by the SCW specify the port executables according to their default location. In most cases, the default location is at %Programfiles%\Microsoft\Exchange Server\bin. If you have installed Exchange into a different location, you must edit the <Path> value in the <Port> section of the Exchange 2007 registration files to indicate the correct installed location.

The following services are enabled by the Exchange 2007 registration file (Exchange2007.xml) for the Mailbox server role.

The Microsoft Search (Exchange Server) service and Microsoft Exchange Monitoring are set to start manually. All other services are set to start automatically.

Service short name	Service name
MSExchangeIS	Microsoft Exchange Information Store
MSExchangeADTopology	Microsoft Exchange Active Directory Topology
MSExchangeRepl	Microsoft Exchange Replication Service
MSExchangeMailboxAssistants	Microsoft Exchange Mailbox Assistants
MSExchangeSearch	Microsoft Exchange Search Indexer
MSExchangeServiceHost	Microsoft Exchange Service Host
MSExchangeMonitoring	Microsoft Exchange Monitoring
MSExchangeSA	Microsoft Exchange System Attendant
MSExchangeMailSubmission	Microsoft Exchange Mail Submission Service
msftesql-Exchange	Microsoft Search (Exchange Server)

The following ports are enabled.

Port name	Associated executable file
MSExchangeADTopologyPorts	MSExchangeADTopologyService.exe
MSExchangeISPorts	Store.exe
MSExchangeReplPorts	Microsoft.Exchange.Cluster.ReplayService.exe
MSExchangeMailboxAssistantsPorts	MSExchangeMailboxAssistants.exe
MSExchangeSearchPorts	Microsoft.Exchange.Search.ExSearch.exe
MSExchangeServiceHostPorts	Microsoft.Exchange.ServiceHost.exe
MSExchangeMonitoringPorts	Microsoft.Exchange.Monitoring.exe
MSExchangeSAPorts	Mad.exe
MSExchangeMailSubmissionPorts	MSExchangeMailSubmission.exe
msftesql-ExchangePorts	Msftesql.exe
MSExchangeTransportLogSearchPorts	MSExchangeTransportLogSearch.exe

The services and ports that are enabled on the Mailbox server role and described in the Mailbox Server Role section earlier in this topic are enabled on the clustered mailbox server role.

Additionally, the Microsoft Cluster Service is set to start automatically.

Service short name	Service name
ClusSvc	Microsoft Cluster Service

The following ports are also enabled.

Port name	Associated executable file
ExSetupPorts	ExSetup.exe
clussvcPorts	Clussvc.exe
CluAdminPorts	CluAdmin.exe
resrcmonPorts	Resrcmon.exe
msftefdPorts	Msftefd.exe
powershellPorts	Powershell.exe

The following services are enabled by the Exchange 2007 registration file (Exchange2007.xml) for the Hub Transport server role.

Microsoft Exchange Monitoring is set to start manually. All other services are set to start automatically.

Service short name	Service name
MSExchangeADTopology	Microsoft Exchange Active Directory Topology service
MSExchangeTransport	Microsoft Exchange Transport service
MSExchangeAntispamUpdate	Microsoft Exchange Anti-spam Update service
MSExchangeEdgeSync	Microsoft Exchange EdgeSync service
MSExchangeTransportLogSearch	Microsoft Exchange Transport Log Search service
MSExchangeMonitoring	Microsoft Exchange Monitoring

The following ports are enabled.

Port name	Associated executable file
MSExchangeADTopologyPorts	MSExchangeADTopologyService.exe
MSExchangeTransportPorts	MSExchangeTransport.exe
EdgeTransportPorts	EdgeTransport.exe
MSExchangeAntispamUpdatePorts	Microsoft.Exchange.AntispamUpdateSvc.exe
MSExchangeEdgeSyncPorts	Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportLogSearchPorts	MSExchangeTransportLogSearch.exe
MSExchangeMonitoringPorts	Microsoft.Exchange.Monitoring.exe

The following services are enabled by the registration file for the Edge Transport server role (Exchange2007Edge.xml).

Microsoft Exchange Monitoring and the Microsoft Exchange Transport Log Search service are set to start manually. All other services are set to start automatically.

Service short name	Service name
MSExchangeTransport	Microsoft Exchange Transport service
MSExchangeAntispamUpdate	Microsoft Exchange Anti-spam Update service
ADAM_MSExchange	Microsoft Exchange ADAM
EdgeCredentialSvc	Microsoft Exchange Credential Service
MSExchangeTransportLogSearch	Microsoft Exchange Transport Log Search service
MSExchangeMonitoring	Microsoft Exchange Monitoring

The following ports are enabled.

Port name	Associated executable file
MSExchangeTransportPorts	MSExchangeTransport.exe
EdgeTransportPorts	EdgeTransport.exe
MSExchangeAntispamUpdatePorts	Microsoft.Exchange.AntispamUpdateSvc.exe
ADAM_MSExchangePorts	Dsamain.exe
EdgeCredentialSvcPorts	EdgeCredentialSvc.exe
MSExchangeTransportLogSearchPorts	MSExchangeTransportLogSearch.exe
MSExchangeMonitoringPorts	Microsoft.Exchange.Monitoring.exe

The following services are enabled by the Exchange 2007 registration file (Exchange2007.xml) for the Client Access server role.

Microsoft Exchange Monitoring, the Microsoft Exchange POP3 service, and the Microsoft Exchange IMAP4 service are set to start manually. All other services are set to start automatically.

Service short name	Service name
MSExchangeADTopology	Microsoft Exchange Active Directory Topology service
MSExchangePOP3	Microsoft Exchange POP3 service
MSExchangeIMAP4	Microsoft Exchange IMAP4 service
MSExchangeFDS	Microsoft Exchange File Distribution service
MSExchangeServiceHost	Microsoft Exchange Service Host
MSExchangeMonitoring	Microsoft Exchange Monitoring

The following ports are enabled.

Port name	Associated executable file
MSExchangeADTopologyPorts	MSExchangeADTopologyService.exe
MSExchangePOP3Ports	Microsoft.Exchange.Pop3Service.exe
MSExchangeIMAP4Ports	Microsoft.Exchange.Imap4Service.exe
MSExchangeFDSPorts	MSExchangeFDS.exe
MSExchangeServiceHostPorts	Microsoft.Exchange.ServiceHost.exe
MSExchangeMonitoringPorts	Microsoft.Exchange.Monitoring.exe

The following services are enabled by the Exchange 2007 registration file (Exchange2007.xml) for the Unified Messaging server role.

Microsoft Exchange Monitoring is set to start manually. All other services are set to start automatically.

Service name	Friendly name
MSExchangeADTopology	Microsoft Exchange Active Directory Topology service
MSSpeechService	Microsoft Exchange Speech Engine
MSExchangeUM	Microsoft Exchange Unified Messaging
MSExchangeFDS	Microsoft Exchange File Distribution Service
MSExchangeMonitoring	Microsoft Exchange Monitoring

The following ports are enabled.

Port name	Associated executable file
MSExchangeADTopologyPorts	MSExchangeADTopologyService.exe
MSSPorts	SpeechService.exe
MSExchangeUMPorts	umservice.exe
UMWorkerProcessPorts	UMWorkerProcess.exe
MSExchangeFDSPorts	MSExchangeFDS.exe
MSExchangeMonitoringPorts	Microsoft.Exchange.Monitoring.exe

Return to top

• New Anti-Spam and Antivirus Functionality [ http://technet.microsoft.com/en-us/library/aa996551.aspx ]
  
• New Antivirus and Anti-spam Products for Exchange 2007 [ http://technet.microsoft.com/en-us/library/bb123688.aspx ]
  
• Planning for Anti-Spam and Antivirus Features [ http://technet.microsoft.com/en-us/library/aa995932.aspx ]
  
• Managing Anti-Spam and Antivirus Features [ http://technet.microsoft.com/en-us/library/aa996604.aspx ]
  
• Anti-Spam Cmdlets [ http://technet.microsoft.com/en-us/library/bb124601.aspx ]
  
• Protecting Your Microsoft Exchange Organization with Microsoft Forefront Security for Exchange Server [ http://go.microsoft.com/fwlink/?LinkId=96630 ]
  

• Managing Client Access Security [ http://technet.microsoft.com/en-us/library/aa998023.aspx ]
  
• Configuring ISA Server 2006 for Exchange Client Access [ http://technet.microsoft.com/en-us/library/aa997148.aspx ]
  

 Microsoft Office Outlook Web Access

• Managing Outlook Web Access Security [ http://technet.microsoft.com/en-us/library/bb124507.aspx ]
  
• Configuring Forms-Based Authentication for Outlook Web Access [ http://technet.microsoft.com/en-us/library/bb123719.aspx ]
  
• Configuring Standard Authentication Methods for Outlook Web Access [ http://technet.microsoft.com/en-us/library/bb125207.aspx ]
  
• Using ISA Server 2006 with Outlook Web Access [ http://technet.microsoft.com/en-us/library/aa996545.aspx ]
  

 Outlook Anywhere

• Managing Outlook Anywhere Security [ http://technet.microsoft.com/en-us/library/aa997193.aspx ]
  

 POP3 and IMAP4

• Managing POP3 and IMAP4 Security [ http://technet.microsoft.com/en-us/library/bb123960.aspx ]
  
• Configuring Authentication for POP3 and IMAP4 [ http://technet.microsoft.com/en-us/library/aa997188.aspx ]
  
• Configuring TLS and SSL for POP3 and IMAP4 Access [ http://technet.microsoft.com/en-us/library/aa997149.aspx ]
  

• Configuring Permissions [ http://technet.microsoft.com/en-us/library/aa997244.aspx ]
  
• Required Permissions to Manage Unified Messaging [ http://technet.microsoft.com/en-us/library/bb123516.aspx ]
  
• Required Permissions to Manage Client Access [ http://technet.microsoft.com/en-us/library/bb124319.aspx ]
  
• Setting Administrator Permissions for the Edge Transport Server Role [ http://technet.microsoft.com/en-us/library/aa996854.aspx ]
  
• Managing Transport Servers [ http://technet.microsoft.com/en-us/library/bb124024.aspx ]
  
• Permission Considerations [ http://technet.microsoft.com/en-us/library/aa996881.aspx ]
  
• Planning and Implementing a Split Permissions Model [ http://technet.microsoft.com/en-us/library/bb232100.aspx ]
  
• Unified Messaging Split Permissions Recipient Management [ http://technet.microsoft.com/en-us/library/bb232176.aspx ]
  
• Preparing Legacy Exchange Permissions [ http://technet.microsoft.com/en-us/library/aa997914.aspx ]
  
• Exchange 2007 Permissions: Frequently Asked Questions [ http://technet.microsoft.com/en-us/library/bb310792.aspx ]
  
• Exchange 2007 Server Setup Permissions Reference [ http://technet.microsoft.com/en-us/library/bb310770.aspx ]
  
• Property Sets in Exchange 2007 [ http://technet.microsoft.com/en-us/library/bb310768.aspx ]
  

• Planning for Domain Security [ http://technet.microsoft.com/en-us/library/bb124392.aspx ]
  
• Managing Domain Security [ http://technet.microsoft.com/en-us/library/bb124996.aspx ]
  
• White Paper: Domain Security in Exchange 2007 [ http://go.microsoft.com/fwlink/?linkid=82726 ]
  

Return to top