I recently highlighted 5 Reasons Why Hackers Want to Break into Your Email Server to underscore how enticing a target the humble email server is to hackers.  The least damaging repercussions of a hacked email server range from the loss of bandwidth to being leveraged for the distribution of spam; meanwhile, the leaking of company secrets, extortion are some of the more serious consequences that could result.

To help email administrators along this vein, I’ve compiled a short list of excellent resources to help them better secure and protect the Microsoft Exchange servers under their charge.

Exchange 2010 Security Guide

Written by the Microsoft team, I consider the Exchange 2010 Security Guide to be a requisite read for Exchange Administrators.  While a little dated, a large part of the comprehensive article covers ‘evergreen’ best practices on topics such as security patching and enforcing of passwords.  As such, I consider this a great place to get started.  Other important aspects that are covered include suggestions to decouple Windows usernames with SMTP addresses, as well as how to create a new Exchange Server role with the Security Configuration Wizard.  [Exchange 2010 Security Guide]

Securing Exchange 2010 with Forefront TMG

The Forefront Threat Management Gateway (TMG) by Microsoft helps businesses protect themselves from Web-based threats using an integrated solution that is configured and monitored from a single management interface.  To help those not already familiar with Forefront, Alexander Weiß of 4sysops has written a couple of comprehensive articles on how it can be used to protect an Exchange Server deployment, specifically focusing on the use of preauthentication and protecting the Web interface of an Exchange Server.  [Part 1 and Part 2]

Exchange Server’s Client Access: Securing Your Servers

Rather than taking a generic approach to the topic of security for Exchange Server, Ken St. Cyr of Windows IT Pro focuses instead on three tips in order to “greatly increase” the base security of an Exchange deployment.  To help administrators understand what they are doing, he elaborates at length on the use of digital certificates, the need to harden the underlying server OS and the advantages offered by a reverse proxy.  As a solution architect at Microsoft with more than 10 years of industry experience, Ken St. Cyr has an impressive list of credentials to his name, which includes being the author of Exchange Server 2010 Administration Instant Reference (Sybex). [Exchange Server's Client Access: Securing Your Servers]

Configuring Security for IIS 7

Exchange Server aside, there is also a need to protect the underlying IIS or Internet Information Server web server.  The reason is due to the fact that Exchange makes use of IIS for Outlook Web App (OWA), a feature which is enabled by just about every company these days.  Hosted on the official IIS web site, this guide is essentially a compilation of separate articles by team members on various aspects of securing IIS.  Personally, I feel that even the content page is a goldmine on how to secure the latest version of IIS.  [Configuring Security for IIS 7]

Know of any other good resources on how to secure Exchange Server 2010?  Feel free to chip in below, or if you have any comments pertaining to any of the above resources.

Securing Your Microsoft Exchange 2010 Server

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In his blog post, “Exchange Server Front and Back Ends”, John Bostock discussed the security design of running Exchange servers in a Front End/Back End configuration within a DMZ. Both server roles are divided such that requests from clients are handled by the front end server which then proxies the requests to an alternate server functioning as the back end server. The back end server then services the requests.

A front end/back end server configuration was useful for performance reasons when Exchange 2003 was around but most organizations have already moved to an Exchange 2010 server environment. If your company has not migrated to Exchange 2010 then there are some considerations that must be evaluated with regards to how to migrate away from the earlier front end / back end scenarios.

Some earlier mail server environments included the use of clusters where two servers functioned as the front end servers and two servers operated on the back end servicing the client requests. A configuration such as this may have supported anywhere from five-thousand to ten-thousand mailboxes depending on the server workloads. The servers would most likely have been configured with multiple CPUs, lots of RAM and striped RAID disk storage.

Moving to an Exchange Server 2010 configuration will include many steps. Included among those steps will be the conversion of the traditional front end / back end server roles into the Exchange Server 2010 CAS-MX (Client Access Service) model. The CAS-MX model still provides the same functionality as the earlier front end / back server model.

The Client Access server role was introduced in Exchange 2007 and was further enhanced with the introduction of the RPC Client Access Service with Exchange Server 2010. The RPC Client Access service moved the responsibility of processing the client requests – previously handled by the back end servers – to client access servers in the middle tier. Also moved to the middle tier were directory accesses from domain controllers / global catalog servers.

The steps involved when migrating from Exchange Server 2003 to Exchange Server 2010 include:

1. Get into Exchange Native Mode.
2. Upgrade all Exchange 2003 Servers to Exchange Server 2003 Service Pack 2.
3. Take the AD forest and domains to at least Windows Server 2003 Functional levels.
4. For each AD site that includes Exchange Server, perform an upgrade to Windows Server 2003 SP3 or greater on at least one Global Catalog domain controller in an AD Site that will house Exchange Server.
5. Configure a Windows Server 2008 (RTM or R2) x64 edition for the first Exchange 2010 server.
6. Install Active Directory LDIFDE tools on the new Exchange 2010 server. This will support a schema upgrade.
7. Install any necessary prerequisites (WWW for CAS server role).
8. Run setup on the Exchange 2010 server, upgrade the schema, and prepare the forest and domains.
9. Install CAS server role servers.
10. Transfer OWA, ActiveSync, and Outlook Anywhere traffic to new CAS servers.
11. Install Hub Transport role.
12. Transfer inbound and outbound mail traffic to the Hub Transport servers.
13. Install Mailbox servers and configure Databases.
14. Create public folder replicas on Exchange 2010 servers using pfmigrate.wsf script, AddReplicatoPFRecursive.ps1, or Exchange 2010 Public Folder tool.
15. Move mailboxes to Exchange Server 2010.
16. Rehome the Offline Address Book (OAB) generation server to Exchange Server 2010.
17. Rehome Public Folder Hierarchy on new Exchange Server 2010 Admin Group.
18. Transfer all Public Folder Replicas to Exchange Server 2010 Public folder store(s).
19. Delete Public and Private Information Stores from Exchange 2003 server(s).
20. Delete Routing Group Connectors to Exchange Server 2003.
21. Delete Recipient Update Service agreements using ADSIEdit.
22. Uninstall all Exchange 2003 servers.

It is advisable to maintain all previous front end and back end roles until after all mailboxes have been migrated. Up until the time that all mailboxes have been completely migrated there will still be some users who access their email via Outlook Web Access. These OWA users will still be reliant on the front end / back end server roles until after their mailboxes have been migrated.  Later, those same users will access their email via the client access server machines.

Also, the migration will be a lot easier if the older Exchange 2003 servers are kept running for two to three weeks after the migration. This will allow enough time for the users’ profiles to be updated with information pointing the client software to the new 2010 servers.

Migrating Front End / Back End Servers to Exchange 2010

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In Robert Gillies blog, Robert’s Rules of Exchange: Namespace Planning, he discusses the importance of namespace planning and how to plan for namespaces. A fictitious environment is used in which three namespaces are outlined: a main namespace for client access, an auto discover namespace and, for legacy redirects, a legacy namespace.

An example of needed namespaces could consist of namespaces for Outlook, Exchange ActiveSync (EAS), Offline Address Book (OAB) downloads, and the Availability Service (as well as for all other Exchange Web Services clients). Robert points out that if a company is not upgrading from Exchange 2003 or 2007, then they will not need the legacy namespace.

With regard to the availability service, when planning for a reliable available environment namespace configuration is very important. The datacenters that will be used for Exchange server must both be in an Active-Active configuration. Specifically, the namespaces used for the Database Availability Group (DAG) solution at each datacenter must both be active and their namespaces reachable. Each datacenter must be able to support an active load. Each server used in the model must have sufficient resources available to support their respective workloads.

Sometimes the High Availability wizard of the Failover Cluster Manager is used to create a Distributed File System (DFS) namespace for a Windows Server 2008 cluster. Unfortunately the DGFS namespace may have a failed status after creating the DFS namespace. There are delays related to the Domain Name System (DNS) registration and replication which can impact the online status. Sometimes those delays can take up to fifteen seconds. However this is a one time occurrence when a new namespace is created and DFS attempts to come up.

If administrators are running Windows Server 2003 R2 and they wish to implement the Distributed File System then the DFS Management snap-in is used. The DFS Management snap-in enables management of the DFS namespace and DFS replication in the Microsoft Management Console (MMC). DFS namespace and DFS replication are two technologies that, when used together, can simplify fault-tolerant access to files, load sharing and wide area network replication.

DFS Namespaces when configured for availability can facilitate client failover from one server to another. This can happen if a server fails or has been removed from a namespace and the clients then try to access another server based on a referral. Clients will continue to access the newly referred server up until client failback occurs. However, if the clients are restarted of the client’s referral cache is cleared then connections to the referred server will discontinue. Normal client failback will occur when clients have the appropriate client failback hotfix installed and client failback has been configured. Once the preferred server has been restored then the failback process will reconnect the clients to their preferred, local server as specified per configuration settings.

Once a namespace had been created and deployed it can then have its availability increased by adding namespace servers to a domain-based namespace. Folder targets could then be added and replicated using DFS replication.

Site resilient configurations for Exchange Server 2010 required much planning in how an administrator lays out their namespace design. Each datacenter in a site resilient architecture is considered to be active to ensure successful switchovers between datacenters. Therefore unique namespaces must be created and deployed for each datacenter. Various Exchange Server 2010 service must be supported such as: Outlook, Outlook Web App, Outlook Anywhere, Exchange ActiveSync, Exchange Web Services, RPC Client Access, Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and Simple Mail Transfer Protocol (SMTP).

It is also imperative that the namespace for Autodiscover also be hosted by one of the datacenters. This architecture will facilitate single database switchovers from the primary datacenter to the secondary datacenter. Always include in your schedule to run test switchovers a couple of times a year to verify working switchover configurations.

These configurations should also include split DNS for the Exchange hostnames that will be used by the clients. This practice can help to protect the IP addresses of your DNS servers while using the same hostname for the internal facing DNS servers and the external facing DNS servers. An additional benefit of split DNS is that the number of hostnames used for the DNS servers is kept to a minimum.

Another aspect to availability of Exchange server and namespaces is that of the Client Access Server (CAS) role. If Exchange server is deployed across multiple datacenters then a unique namespace should be created and deployed for each datacenter. Examples could be something like “mailserver.primary.company.com” and “mailserver.secondary.company.com”. I’ll discuss CAS availability in a future blog.

Namespace Planning for Site Resiliency

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Some Exchange Server 2007 and Exchange Server 2010 roles require Internet Information Services (IIS) to function.   On these servers Exchange will install a series of IIS virtual directories.  In this post I will describe the Exchange Server virtual directories and their purpose.

/owa – This is the directory for OWA (Outlook Web Access on Exchange 2007, and now called Outlook Web App on Exchange 2010), which is the web browser version of Outlook that is usually accessed by remote workers.  The /owa directory is for access to Exchange 2007 or 2010 mailboxes.

/Public – This is the directory used by OWA users when accessing any Public Folders in the organization.

/Exchweb – This directory is used for OWA access for Exchange 2003 or 2000 users but is not usually accessed directly by the end user.  The OWA session will automatically refer the connect to this virtual directory when necessary.

/Exchange – This directory is again used for OWA access.  When an Exchange 2003 or 2000 mailbox user access the /Exchange virtual directory they are proxied to their mailbox.  For Exchange 2007 or 2010 mailbox users they are redirected to the /owa directory for their mailbox access.

This is useful during the transition from legacy Exchange versions to 2007 or 2010, because users can continue to connect to the /Exchange directory and the result will always be that they connect to their mailbox, as long as the server does not run the Mailbox Server role.  In other words, the /Exchange directory only works for legacy mailbox users if the server is a dedicated Client Access Server (though it can also contain the Hub Transport Server role without a problem)./Exadmin – this directory is for administrative purposes only.  Normal users cannot access this directory.

/Microsoft-Server-ActiveSync – this directory is for ActiveSync clients to connect to mailboxes.  These are typically mobile phones or smart phones that have an ActiveSync-compatible email application.

/OAB – this directory publishes the Offline Address Book for clients running Outlook 2007 and above.  Earlier versions of Outlook download the OAB from Public Folders instead.

/Autodiscover – this directory publishes Autodiscover information.  Clients running Outlook 2007 and above, and some ActiveSync clients, can query Autodiscover for a user’s mailbox configuration and automatically set up the mail profile without the end user needing to enter details such as server names.

/EWS – this directory publishes Exchange Web Services, a new programming API that makes Exchange data available to third party applications.

/Rpc and /RpcWithCert – these directories are for Outlook Anywhere, which was formerly known as RPC-over-HTTPS.  As the name suggests, this allowed Outlook clients to make an RPC connection to the Exchange server over an SSL encrypted tunnel from anywhere, making it possible for staff on the road to continue using Outlook without interruption.

/UnifiedMessaging – this directory allows access to Unified Messaging Web Services.  Unified Messaging is Exchange Server’s telephony integration, with features such as voicemail, auto attendants, and Outlook Voice Access.  This virtual directory allows the integration of Outlook and OWA with Unified Messaging for features such as voice mailbox PIN resets and playing voicemail messages within OWA.

/PowerShell – this directory, appearing only in Exchange 2010, allows remote management sessions from the Exchange Management Shell.

/ecp – this directory, again new to Exchange 2010, publishes a self-service control panel for administrators and users.  A broad range of administrative tasks can be delegated to power users and made accessible through the Exchange Control Panel, such as creating new distribution groups and managing SMTP addresses for mailbox users.  Normal users can also access self-service options such as updating their personal information.

Overview of Exchange Server Virtual Directories

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

When planning an Exchange Server 2007 project with customers the question of Public Folders always comes up.  One of the scenarios in which Public Folders are discussed is by customers who do not currently use Public Folders, and who want to know whether they need to use them with Exchange Server 2007.

The question relates to the topic of Free/Busy information, which is the data from mailbox users’ calendars that lets others see their availability when trying to schedule meetings in Outlook.

Exchange 2003 stores Free/Busy information in the Public Folder database for all mailbox users, whereas Exchange Server 2007 introduced a new feature called the Availability Service to replace that functionality.  The Availability Service runs on the Client Access Server role.

The Availability Service does not store Free/Busy data, rather it retrieves it on request directly from the mailbox in question.  This is in contrast to Exchange 2003 which stored the data in a special Public Folder.  The data was published to the Public Folder by the Outlook client itself, and so it was not always completely up to date.

Some of the advantages of the Availability Service over the Public Folder publishing method are:

• Makes Free/Busy data sharing available in a more granular fashion for end users (e.g., can choose to just show whether they are free or not, or also show details of the meetings they have planned, etc)
• Simplifies cross-Forest sharing of Free/Busy data by making it directly accessible between organizations, instead of the legacy method of synchronizing Free/Busy data with the Inter-Org Replication Tool
• Exposes Free/Busy data via Exchange Web Services so that it can be accessed by other programs via APIs

The main dependency of the Availability Service is that it can only be accessed by Outlook 2007 and later clients.  Outlook 2003 and earlier have no ability to query the Availability Service.  This leads to some confusion for customers, especially during a migration project when both Exchange 2003 and 2007 co-exist in the organization.Consider an organization that is in the process of migrating to Exchange Server 2007 and so has mailbox users on both 2003 and 2007 mailbox servers.  Access to Free/Busy data will be achieved in the following ways:

• Regardless of the Outlook version, any Exchange 2003 mailbox user will publish Free/Busy data to the Public Folders
• Regardless of the server version, any Outlook 2003 or earlier client will publish Free/Busy data to the Public Folders, and read Free/Busy data from the Public Folders
• Outlook 2007 clients on Exchange 2007 mailbox servers will query the Availability Service for Free/Busy data
• The Availability Service retrieves Free/Busy data directly from Exchange 2007 mailboxes, and from Public Folders for Exchange 2003 mailboxes

What this usually boils down to for customers, when planning for the stage that they are running only Exchange 2007 servers, are these simple rules:

• If you have any Outlook 2003 or earlier clients, you will still need Public Folders for Free/Busy information
• If all your clients are Outlook 2007 or later, you do not need to retain Public Folders for Free/Busy information

It may seem a trivial issue, but being able to remove Public Folders completely makes the environment that little bit easier to deploy and administer.  At the very least it is one less database to backup on the server.

Exchange Server 2007 Availability Service Explained

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators