Most people who use Outlook will know that individual email messages can be marked with different priorities.  Usually this is used solely as a way to flag the importance of the email to the recipient, and people who receive large volumes of daily email will often use filtered views to bring the highest priority emails to the surface for action.

What a lot of people don’t also realise is that the priority flag on a message can also be used by Exchange Server 2010 to deliver high priority messages before normal or low priority messages.

This capability becomes important in Exchange environments that are very large, complex, or spam geographically diverse areas.  In these types of environments email latency can become noticeable, unlike smaller environments where a few hundred recipients on one or two servers see virtually no delay in sending and receiving email.

When you combine long distance with high volume it is easy to see how important emails might be delayed in an unacceptable way if they are simply processed in a “first in, first out” order. Continue reading Exchange Server 2010 Priority Message Delivery

In Exchange Server terminology and “recipient” is any object in the Active Directory environment that Exchange is able to send email messages to.

Each type of recipient in an Exchange Server environment has a different purpose and set of capabilities relating to its specific type.  Although there are a large number of different recipient types they fall under a few broad categories.

Mailboxes

Mailbox recipients come in several different types for different tasks or purposes.

User – this is the most common type of mailbox that is associated with a user in the same Active Directory forest as the Exchange organization.

Linked Mailbox – this is similar to a regular User mailbox however a Linked Mailbox is associated with a user in a different Active Directory forest to the local forest where the Exchange organization resides.

Linked User – this is similar to the Linked Mailbox only the association between user and mailbox is reversed, with a user in the local forest associated with a mailbox in a remote Exchange organization.

Shared – although each mailbox has a 1:1 association with a user object, a shared mailbox is one that is configured to allow multiple users to access it (for example a Help Desk mailbox).

Resource – resource mailboxes come in two types, Room and Equipment.  Each is most often used with the calendaring features of Exchange to allow booking of meeting rooms or pool equipment.  The main difference between the two is that rooms are typically fixed location whereas equipment is portable.

Legacy – this refers to any mailbox that still resides on an Exchange 2003 server, and only applies during the transitional period from Exchange 2003 to 2010.  Once a mailbox is moved from 2003 to 2010 it becomes either a User or Shared mailbox, depending on who has permissions to access it. Continue reading Exchange Server 2010 Recipient Types

I recently wrote an article that dismissed the use of fake MX records as an email security measure, on the basis that it did more harm than good for preventing spam.

I was reminded this week of an incident in which a customer was confused as to how spam was making it into their email systems.  Actually this has happened on more than one occasion with the same ultimate outcome.

The confusion mostly comes from the client thinking that because there were no MX records in public DNS zones that pointed to their email servers that the spammers and hackers shouldn’t be able to find them.

The fatal flaw in that thinking is that spammers and hackers don’t just use MX records to find places to send email or attack mail servers.  When they really want to find email servers, say to try and locate some open relays that they can exploit, they will use port scans instead.

A “port” in networking terminology is a communications end point that is specific to a process or service running on a computer.  In the case of SMTP, the protocol that email users, the port is TCP 25.

In other words, if you’re running an email server on your network then chances are you firewall has TCP port 25 open and allowing traffic through from the internet to your server.  In many cases the traffic might be filtered first by an intermediary server, but with a lot of environments running their email security software directly on the email server itself, often the SMTP traffic goes straight to that server.

In my customer’s case they had multiple servers in the environment, with a security product running on the internet-facing email server.  When they had merged companies they had ended up with multiple internet connections and firewalls, and kept those running.  They consolidated all of their email to the primary site, removing the MX records that were pointing to the second firewall and then promptly forgot all about it. Continue reading Email Server Security: Port Scans and MX Records

When we talk about “logging” in Exchange Server 2010 it can mean a lot of different things.  Here are eight different types of logging that are performed by Exchange Server 2010 that email administrators need to understand.

Transaction Logging

Mailbox and Public Folder databases comprise two main parts – the database itself, and the transaction logs.

When changes occur in the database they are first written to a transaction log.  When the transaction is fully logged it is then committed to the database at a later time.  A checkpoint file is used to keep track of which logs have been committed to the database and which are not.  If there is a database or server problem, the server uses the checkpoint file to determine how to recover the database.

When a database is successfully backed up the committed transaction logs are removed from disk to reclaim disk space.

These log files are not human readable, but they are very important.  In many Exchange environments it is best practice to separate the database and logs on to distinct storage volumes so that a single storage failure does not destroy both the logs and the database at once.

Message Tracking Logs

Message tracking is an optional feature of Exchange that can keep track of all message activity on Edge Transport, Hub Transport, and Mailbox servers.  A message tracking report for any given email message in the organization can be generated showing all of the actions taken by servers along its delivery path (within the boundaries of the Exchange Organization). Continue reading Exchange Server 2010 Logging

There has been a lot of buzz created about Exchange Server 2010’s new database capabilities.  The terms “RAID-less” and “backup-less” get mentioned in conversations but are often taken out of context, or used with incorrect assumptions.

But why are people so excited about Exchange Server 2010 and talking about throwing out RAID and backups?  There are three main reasons for this.

Three Big Exchange Server 2010 Improvements

Improved Database Performance – the Exchange database schema has been overhauled to deliver much greater efficiency and therefore much better performance in terms of disk I/O.  This overhaul stirred some controversy because it put an end to single instance storage, however the small loss of SIS delivers much greater benefits in performance.

Improved High Availability – Exchange Server 2007 had four different HA/DR options, each one with its own complexities and limitations, and each one administered in a different way.  Exchange Server 2010 simplifies this to one single, vastly more effective high availability model called Database Availability Groups.  This basically involves replicating a database between as many as 16 servers (DAG members) that can seamlessly fail over if any individual server experiences a fault.

Improved Data Retention – In Exchange Server 2010 mailboxes and databases can be much bigger than previous versions, archiving has been built in, and longer retention is feasible making recovery of single items and mailboxes possible over longer periods without having to access backups.

These improvements have led to the idea that an organization can deploy multiple Exchange servers in a DAG using cheaper, slower storage sub-systems, without RAID to replicate the data, and without backing up because emails can be recovered almost indefinitely.

Which is true, but only if Exchange Server 2010 is deployed correctly with enough resources to make this possible. Continue reading Data Protection for Exchange Server 2010

One of the challenges for businesses when they provide email access to their staff is how to let staff use email productively while also managing the risk of information leakage.

Although information leaks can occur over many different mediums, leaks over email remain a serious concern for some businesses.

Fortunately Exchange Server 2010 includes features to help organizations manage the risk of information leaks via email.

Using Message Classifications

Message classifications provide a mechanism by which end users can classify individual email messages.  These classifications are completely customizable and can be used for just about any purpose, even non-security related ones.

Custom classifications can be created by the email administrators and distributed to end users for use within Outlook.  These could include message classifications such as “Confidential” and “Public” to convey the level of security associated with the email content.

One of two approaches could then be taken to enforce their usage.

1. Have email messages created with the most confidential classification by default, requiring the end user to deliberately lower the classification to send external emails.
2. Have email messages created with no classification by default, and require users to choose at least one before sending.

Message classifications can be used in conjunction with Transport Rules for enforcement.  For the two examples above Transport Rules could be created to:

1. Reject messages sent to external recipients that are classified as “Confidential”
2. Reject messages that are sent to external recipients with no classification set

Protecting Customer Information

Another use of Transport Rules is to assess emails based on their content.  If certain text patterns are found within an email message the Transport Rule can reject the message from being sent to an external recipient. Continue reading Preventing Information Leaks with Exchange Server 2010

In Exchange Server the term “Out of Office” refers to the ability of mailbox users to configure a message to be sent automatically as a reply to new messages that informs the sender that they are not available.  Sometimes this is also referred to as a “vacation message”.

In earlier versions of Exchange Server there were two settings for Out of Office – on or off.  However starting with Exchange Server 2007 and continuing with Exchange Server 2010 there are more options available to mailbox users for Out of Office.

Internal vs External

Unlike previous version of Exchange a mailbox user on Exchange Server 2007 or 2010 who is using Outlook 2007 or above can configure two distinct Out of Office messages.  One message is sent to internal senders, and the other is sent to external senders.

The reasoning for this makes a lot of sense – the information that is included in an internal message might be more personal or sensitive than that which can be included in an external message.  Or alternatively, the mailbox user may wish to have only an internal Out of Office reply and send no external message at all. Continue reading Exchange Server 2010 Out of Office

Microsoft provides a lot of written guidance on their Technet site for preparing to migration to Exchange Server 2010.  However a lot of the guidance requires environment-specific inputs to make those planning decisions.

Here are five tools that can help you collect the information you need to plan your migration to Exchange Server 2010.

Exchange Pre-Deployment Analyzer

The ExPDA tool performs a scan of your existing Exchange and Active Directory environments and produces a report that lists all items that require attention prior to deployment.

The items are broken down into critical, warning and informational items.  Critical items are those that will prevent deployment of Exchange Server 2010, while warnings can sometimes be ignored (eg an item that will slightly degrade the Exchange 2010 experience, or a feature that is no longer available in Exchange 2010).  The informational items contain some general information that is useful for planning too.

One of the strengths of this tool is that for each of the critical or warning items it identifies it provides you a link to guidance on how to resolve the issue.

Download the Exchange Pre-Deployment Analyzer from Microsoft here. Continue reading 5 Tools for Planning Exchange Server 2010 Migration

I get asked that question quite a lot, usually by a client who has started discussing an Exchange Server upgrade with us.  Most clients are of the impression that there are no longer any public folders in Exchange Server 2010.

There tends to be some confusion around public folders in Exchange Server 2010 mostly due to rumour, misinterpretation, and a failure to consider all of the different scenarios that the question applies to.

To make things clearer you should understand what public folders were generally used for in legacy (ie Exchange 2003) environments.

Legacy Public Folder Usage

Content – the most basic use of public folders was a shared content repository for objects such as email messages, notes, calendars, and contacts.  For example, a public folder could be used to hold a shared list of external contacts, and used as a source for document mail merges.

Free/Busy Data – the public folders were also used by legacy Outlook clients (2003 and below) to publish a user’s calendar free/busy information, and read the free/busy information of other people in the organization.

Applications – public folders could also be used by applications and accessed via programming APIs.  This was fairly uncommon in my experience.

To answer the question in its simplest form, yes Exchange Server 2010 still has public folders.  However they are not mandatory, and won’t be installed by default.  An administrator can add them at any stage if they are still required.

So which scenarios could still require them?

Exchange Server 2010 Public Folder Usage

Content – Public folders as a content repository have not changed.  Microsoft is not mandating that public folders no longer be used in this way, though they do warn that they are a deprecated feature.

The basic recommendation is that if you currently have content and business processes utilising public folders you can continue to do so, but should begin to plan a move away to an alternative platform such as SharePoint.

But if you have no existing use of public folders for content the recommendation is to not start using them, and instead look straight to SharePoint instead. Continue reading Does Exchange Server 2010 Still Use Public Folders?

Exchange Server 2010 ships with eight very useful Powershell scripts that can be used for managing Public Folders.  The scripts perform tasks relating to Public Folder replicas and permissions that are otherwise not easily manageable through the management console or shell.

Each of the scripts is developed for making recursive changes to public folders.  This means that when you target the script at a particular folder, or the root of the public folder tree, it applies the action to all subfolders of that folder.

These scripts only apply to servers running Exchange 2007 or Exchange 2010, you can not specify a server running older versions of Exchange Server.

Managing Public Folder Replicas

These public folder replica scripts are used to manage which servers hold replica data for the public folders.  When a script does not specify a server to run against it will default to the nearest convenient server for the public folder being targeted.

AddReplicaToPFRecursive.ps1 – this script adds a server to the replica list for a public folder and its subfolders.

For example, to add EXCH02 as a replica for all public folders on server EXCH01 starting at the root folder of \\ you would run this command.

AddReplicaToPFRecursive.ps1 –Server EXCH01
 –TopPublicFolder \\ –ServerToAdd EXCH02

RemoveReplicaFromPFRecursive.ps1 – this script will remove a server from the list of replicas for a folder and its subfolders.  A server must have all of its public folder replicas removed before it can be decommissioned.

For example, to remove EXCH02 as a replica for all public folders on EXCH01 starting at the root folder you would run this command.

RemoveReplicaFromPFRecursive.ps1 –Server EXCH01
 –TopPublicFolder \\ –ServerToRemove EXCH02

ReplaceReplicaOnPFRecursive.ps1 – this script replaces a server in the replica list of the public folders with another server.  This is useful when public folders are already replicated to more than one server, and one of those servers is being replaced. Continue reading 8 Useful Public Folder Management Scripts in Exchange Server 2010