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]

Continue reading Securing Your Microsoft Exchange 2010 Server

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.

Continue reading Migrating Front End / Back End Servers to Exchange 2010

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.

Continue reading Namespace Planning for Site Resiliency

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). Continue reading Overview of Exchange Server Virtual Directories

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. Continue reading Exchange Server 2007 Availability Service Explained