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.

Priority Queuing is enabled on Hub Transport servers and is performed on a server by server basis.  By default it is disabled, so the administrator is able to choose which servers have priority queuing enabled and can do so only where necessary in the organization.

In addition to turning the feature on or off the administrator can also configure a size limit for email messages to be treated according to their set priority.  For example, a size limit of 512Kb would mean that any emails larger than that which are flagged as High priority will be downgraded to Normal priority.  This is something to be considered carefully by the administrator depending on the nature of the business – if the highest priority emails often contain attachments (eg contract bids and tenders) then a low size threshold would negate the benefit of priority queuing).

The server can also be configured with different delay notification thresholds for each priority.  Obviously a high priority message that is delayed for more than 30 minutes warrants a notification, whereas a normal message can withstand a longer delay without notifying the sender.

When priority queuing has been enabled it opens up the possibility that some email users will abuse it by unnecessarily setting High priority flags on messages that do not specifically warrant it.  There are two ways to control who can use priority queuing in the organization:

• Per-Mailbox – each mailbox has a setting to downgrade any High priority messages to Normal priority automatically.  By default this is disabled, and so when priority queuing is enabled in Hub Transport servers anyone can make use of it.  This per-mailbox setting could be turned on for all users with a script or template used at time of mailbox creation.  Alternatively it could be set only on users identified as regular abusers of the feature.
• Transport Rules – another approach would be to use a Transport Rule to detect any messages set as High priority, and if they are not sent by approved users of the feature take action such as reject the message.  This is probably a bit heavy handed and would deny the users the ability to use priority flags to signal the importance of a message to other users in their inboxes.

Although useful within the organization priority queuing is of no benefit once the email leaves the organization and is sent to an external party.  Any delays or problems experienced outside of the organization could still impact the timely delivery of high priority emails.  So while it I useful for several scenarios it is not a 100% solution to all high priority message delivery.

Exchange Server 2010 Priority Message Delivery

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

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.

Groups

Exchange Server 2010 no longer supports Global or Domain Local groups, unless they were already mail-enabled in Exchange 2003 prior to deploying Exchange 2010.  All mail-enabled groups in Exchange 2010 must be Universal groups.

Dynamic – a dynamic group is one in which the membership is not statically assigned, rather it is based on a query that is assessed at the time messages are sent to the group.  For example, a dynamic group may be one for all users that exist on a specific database, which can change frequently in some organizations.

Distribution – a distribution group is a Universal Group that is mail-enabled, but cannot be used for purposes other than email.

Security – a security group is a Universal Group that is mail-enabled, and can be used for both sending email to a group of recipients as well as assigning permissions to other objects and resources.

Other

Aside from mailboxes and groups there are a few other types of recipients.

Public Folders – a public folder can be mail-enabled and receive email messages.

Contact – contacts are usually created as a way of providing centralized access to a list of email addresses of external parties that do not have accounts in the Active Directory forest.

Mail User – a mail user is similar to a contact in the receiving mailbox is external to the Exchange organization, however the user object itself exists within the Active Directory.

As you can see even though it may appear that there is a complex array of recipient types in Exchange Server 2010, each serves a specific purposes and when deployed correctly they are useful and efficient ways to manage your email environment.

Exchange Server 2010 Recipient Types

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

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.

Later they redeployed a second email server at the secondary site as it outgrew the first one, re-using the IP address of the server that had originally been there.  Spam became a problem for them a few weeks later.

Their first mistake was only removing the MX records and leaving the firewall port open.  The second mistake was also common to a lot of environments that I see.  The server was configured to allow relaying to anyone.  The thinking at the time was that the server was accessible to internal devices only, so allowing to relay anything was easier than limiting relay to specific IP addresses.

Because they had reused the original mail server IP for that site, it now sat exposed to the internet, configured as an open relay.

The lessons for email administrators are clear:

• Understand that MX records are not the only way that attackers seek out email servers
• Don’t configure your servers as open relays, even when you think they are internal only
• Always be aware of what firewall rules are configured for your email server IP addresses

Email Server Security: Port Scans and MX Records

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

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).

Message tracking is typically used to troubleshoot email delivery problems, and for generating statistics on email traffic volumes.

Transport Agent Logs

Each of the anti-spam agents that can run on Edge Transport and Hub Transport servers generate their own log file of actions performed on messages.  These log files can be used for reporting on anti-spam performance, for which Exchange ships with several sample PowerShell scripts to parse the log file data.

Connectivity Logging

Connectivity logging occurs on Edge Transport and Hub Transport servers, and is used to track the delivery of outbound email messages to mailbox servers, smart hosts, or external domains.

Unlike message tracking logs the connectivity log only tracks activity for a message on that specific server, not every server within the Exchange Organization.

Protocol Logging

When an SMTP communication occurs between two servers all of the parts of the conversation are recorded in the protocol log.  Protocol logging can be enabled on any Send Connector or Receive Connector and used to troubleshoot mail delivery problems.

Similar to connectivity logging the log file only captures the SMTP conversation relative to that server.

IIS Logs

The Client Access Server role uses an instance of IIS to host the various web services such as OWA and ActiveSync.  This IIS website can perform its own logging which is useful for troubleshooting the HTTP and HTTPS connections between remote users and the Client Access Server.

Diagnostic Logging

Practically every service, agent, or component of Exchange is capable of writing diagnostic information to the Application Event Log on the server.  Some information is logged by default but during troubleshooting the administrator can configure diagnostic logging on specific components to get more log details to help find the problem.

Setup Logs

The final log type I will mention is the setup logs.  These log files are written during initial install of the Exchange server, or when any role is added or removed to an existing server, or when a server is installed with an update or service pack.

The setup logs contain a record of every action taken by the installer and are useful for verifying successful install of Exchange roles or updates.

Exchange Server 2010 Logging

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

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.

Going RAID-Less for Exchange Server 2010

RAID-less mailbox servers is not recommended if you have not deployed at least three DAG members, so that there are at least three copies of each database.

Other server roles would naturally be protected by RAID for their operating system volumes, although you could go RAID-less for these as well provided there are more than one of each role deployed in a redundant configuration.

Going Backup-Less for Exchange Server 2010

A backup-less Exchange Server 2010 environment is more complex than some people seem to assume.  For a backup-less environment to be feasible you must:

• Have at least three DAG members across two physical locations
• Have at least one lagged database copy (this is a copy that “lags” behind at a set interval before committing replication data to the database)
• Have circular logging enabled for all of the databases
• Have your archive and retention settings fully implemented and optimized to prevent permanent deletion of data
• Have your Role-Based Access Control fully locked down to prevent inexperienced administrators from destroying the DAG itself through error or malicious intent
• Not be using Public Folders (which are not protected by DAGs)

Obviously that all becomes complex in its own right, not to mention potentially very expensive.  Multiple physical locations means more datacentre costs, and the number of DAG members increases the number of expensive Enterprise Edition licenses required for Windows Server 2008.

Even with all of the complexities understood and the expenses affordable for an organization, there still remains some risk of complete loss of email data through a disaster.  With that in mind it is more feasible that a less complex DAG deployment can simply be used to reduce the frequency of backups, rather than eliminate them entirely.

In summary, RAID-less Exchange servers may become common over time, but the idea of backup-less Exchange is unlikely to gain any real traction in production deployments.

Data Protection for Exchange Server 2010

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

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.

This is useful for organizations where email might be inadvertently used to transmit a credit card number or social security number, such as through human error or a system bug that failed to strip it out of an automatic message like an invoice.

Moderating Sensitive Mailboxes

The third option is to use moderation rules on sensitive mailboxes if certain conditions are met.  Again this makes use of Transport Rules which can send messages that are addressed to or from specified recipients to a moderation queue for approval.

One example of this would be a group of scientists working on confidential R&D under a specific manager.  The Transport Rule can send all emails from senders who have that manager to a moderation queue where the manager can check them for sensitive content.

Combinations of these three options could also be used.  For example, all staff under the R&D Manager that send messages to external recipients get moderated by the manager.

In summary, when sensitive information leaks are a risk and those scenarios can be clearly identified it is possible to make use of Exchange Server 2010 to reduce those risks.

Preventing Information Leaks with Exchange Server 2010

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

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.

Internal messages have three settings:

• Enabling/disabling the message
• Configuring an optional start/finish time for the Out of Office period
• The Out of Office message itself

External messages also have three settings:

• Enabling/disabling the message
• Whether to reply only to senders in the user’s Contacts list
• The Out of Office message itself

Managing Out of Office Settings

Mailbox users on Exchange 2003 or earlier (for example in an Exchange organization that is part of the way through migrating to 2007/2010) only have the single, legacy Out of Office message available to them.

Mailbox users on Exchange 2007/2010 who use Outlook versions prior to Office 2007 are not able to configure the internal and external replies using Outlook, and must instead use Outlook Web Access.

Mailbox users on Exchange 2007/2010 who use Outlook 2007 or later are able to configure the internal and external replies using Outlook, and can also use Outlook Web Access.

The administrator is also able to manage an Exchange 2010 mailbox user’s Out of Office replies using either the Exchange Management Shell or the Exchange Control Panel.

For example, this mailbox user has automatic replies configured.

[PS] C:\>Get-MailboxAutoReplyConfiguration alan.reid

Identity       : exchangeserverpro.local/Users/Alan.Reid
AutoReplyState : Enabled

The administrator can disable the Out of Office setting if required.

[PS] C:\>Set-MailboxAutoReplyConfiguration alan.reid
 -AutoReplyState Disabled

Restricting Out of Office Messages

In some businesses the security policy is to not allow Out of Office messages to be sent outside of the organization.  However this policy may also need to be relaxed for certain trusted partners.

This managed in the Exchange Organization settings for Remote Domains.  By default a single * (asterisk) Remote Domain is configured which permits Out of Office messages.  If the above security policy was in place this can be set to allow no Out of Office messages.

[PS] C:\>Get-RemoteDomain | fl name,*oof*

Name           : Default
AllowedOOFType : None

To permit Out of Office messages for a trusted partner the partner’s domain name is configured as a Remote Domain, and configured to permit external Out of Office messages (this will be enabled by default when the Remote Domain is created).

In summary, Exchange Server 2010 permits total control and flexibility of Out of Office messages for both the mailbox users and the administrators.

Exchange Server 2010 Out of Office

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

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.

Exchange Server Profile Analyzer

The EPA tool performs a scan of either a single database or the entire organization to create an aggregated report of mailbox statistical information.

Some of the useful information that is produced includes totals and averages for the size and number of mailboxes in the organization, number of email items in mailboxes and sub-folders of mailboxes, and the average sizes of email attachments.

All of this information is useful for capacity planning, as well as when planning for the mailbox migration schedule which is heavily impacted by mailbox item counts and sizes.

Download the Exchange Server Profile Analyzer from Microsoft here.

Performance Monitor

The built-in Performance Monitor tool for Windows lets you collect performance data for every element of the Exchange servers and use it for capacity planning of the new Exchange 2010 servers.

You can use performance data to calculate such data as the current IOPS per mailbox, email traffic volumes, and any unusual performance burdens being created by the usage patterns within the organization.

To make collection of performance data easier there are the Perfwiz XML templates available from Microsoft.

Mailbox Server Requirements Calculator

The most complicated server role in an Exchange Server 2010 environment to calculate the sizing for is the Mailbox Server role, particularly when it comes to storage.

Fortunately Microsoft provides the Mailbox Server Requirements Calculator, which is a complex Excel spread sheet that takes a series of data inputs and recommends a storage configuration to deploy.

I sometimes find the recommendations a little excessive but that is usually due to hasty data collection using other tools leading to overestimation of such things as email usage profiles for users.

When the appropriate amount of time is dedicates to the collection of all of the input requirements for this calculator the output is usually very reliable.

Download the Mailbox Server Requirements Calculator from Microsoft here.

Log Parser

The final tool on this list is Log Parser, a powerful tool for querying text-based log files such as those that are generated by IIS and Message Tracking on Exchange servers.

Although it has a bit of a learning curve there are plenty of query samples available online to make basic usage easy to grasp.

Two handy users of Log Parser when planning an Exchange 2010 migration are querying the Message Tracking logs to determine the volumes of email being sent and received daily by each server, and querying the SMTP virtual server logs for a list of distinct IP addresses that are using the server to for SMTP relay.

Download the Log Parser 2.2 tool from Microsoft here.

5 Tools for Planning Exchange Server 2010 Migration

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

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.

Free/Busy Data – For organizations that still use Outlook 2003 or below the public folder database is still required for free/busy data.  For Outlook 2007 and above it has been replaced with the Availability Service, and so public folders are not required.

Applications – application public folders are not compatible with Exchange Server 2010.  If you have these sorts of public folders in your organization you will either need to leave a legacy server in your organization, or migrate the application away to another platform.

Downsides of Exchange Server 2010 Public Folders

Even though they are still available and functional there are some downsides to using public folders with Exchange Server 2010.

Firstly, Microsoft has not provided particularly rich management tools for public folders in the Exchange Management Console.  Originally in Exchange Server 2007 there was no console tools at all, but they were added into the Toolbox in Service Pack 1.

Little has changed in Exchange Server 2010, with the Toolbox still maintaining a basic public folder management console.  The most powerful and flexible public folder administration is performed from the Exchange management Shell instead, which can be a steep learning curve for administrators.

Secondly, public folders can’t make use of the excellent high availability features of Exchange Server 2010.  They can’t be included in a Database Availability Group, and must instead rely on standard public folder replication for redundancy and availability.

Ultimately my recommendation to our clients is to only retain public folders when absolutely necessary, and to look at moving away from them within the lifecycle of their Exchange Server 2010 deployment.

Does Exchange Server 2010 Still Use Public Folders?

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

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.

For example, to replace EXCH02 with EXCH03 as a replica for the \Branch folder and all subfolders you would run this command.

ReplaceReplicaOnPFRecursive.ps1 –TopPublicFolder \\Branch
 –ServerToAdd EXCH03 –ServerToRemove EXCH02

MoveAllReplicas.ps1 – this script replaces all of the replicas on one server with the new server specified.  You do not need to target a particular parent folder with this script, it will check the entire public folder tree when making the replacements.  This is useful when you want to move all of the replicas from one server to another at once, whereas the ReplaceReplicaOnPFRecursive.ps1 script allows it to be done in a staged manner.

For example, to move all replicas from EXCH01 to EXCH02 you would run this command.

MoveAllReplicas.ps1 –Server EXCH01 –NewServer EXCH02

Managing Public Folder Client Permissions

These scripts are used to manage the client (or end-user) permissions to 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.

AddUserstoPFRecursive.ps1 – this script grants the specified user permission to a public folder and its subfolders.  You can grant permissions to a user or to a group, as long as they are mail-enabled.

For example, to add John Smith as a Reviewer of the “\Branch” folder and subfolders you would run this command.

AddUsersToPFRecursive.ps1 –TopPublicFolder \\Branch
 –User “johnsmith” –Permissions Reviewer

RemoveUserFromPFRecursive.ps1 – this script revokes the specified user permission to a public folder and its subfolders.

For example, to remove John Smith from the “\\Branch” folder and subfolders you would run this command.

RemoveUserFromPFRecursive.ps1 –TopPublicFolder \\Branch
 –User “johnsmith”

ReplaceUserPermissionOnPFRecursive.ps1 – this script will replace a specified user’s existing permissions on a public folder and all subfolders with a new set of permissions.  This is useful when you want to raise or lower the permissions that a user currently has to a set of public folders.

For example, to change John Smith from being a Reviewer of the \\Branch folder and all subfolders to being a Publishing Editor you would run this command.

ReplaceUserPermissionOnPFRecursive.ps1 –TopPublicFolder
 \\Branch –User “johnsmith” –Permissions PublishingEditor

ReplaceUserWithUserOnPFRecursive.ps1 – this script replaces an existing user’s permissions to a public folder and all subfolders with another user.  This is useful if there has been a staff change and you wish to grant the same access to a new user that the previous user had.

For example, to replace John Smith with Peter Brown as the Publish Editor of the \\Branch public folder and all subfolders you would run this command.

ReplaceUserWithUserOnPFRecursive.ps1 –TopPublicFolder \\Branch
 –UserOld “johnsmith” –UserNew “peterbrown”

8 Useful Public Folder Management Scripts in Exchange Server 2010

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

The Outlook Personal Folders file (PST) had its day.  It was once the ultimate or perhaps only solution to reducing the cost of storing old emails within the Exchange server database.

Those days are largely gone.  Exchange servers can scale up to much larger database sizes than they could 10 years ago.  Disk and tape storage is cheap, and emails themselves are getting larger and larger.  And enterprise email archiving is efficient, cost effective, and even comes built in to the latest version of Exchange Server.

The benefits of the PST format are now close to nil, while all of the problems remain.  PST files are single-user access only, can’t be indexed or easily searched, are sensitive to corruption when they get larger or are being accessed over networks, and consume more space due to their general inefficiency.

But many organizations have a lot of archived emails still stored in PST files.  Moving to a new Exchange server doesn’t magically solve that problem.  The question is what should you do about all those PST files?

Do Nothing

The least effort, but also least effective solution is to simply do nothing.  Draw a line in the sand and leave all those PST archives as is, but begin archiving to a proper email archiving solution from this point forward.

A serious downside of this is that you can’t reclaim all that wasted disk space that the PSTs are using up.

Import to Exchange Server

The tools to import PST files into mailboxes have been around for a long time.  The upside of this option is that it gets the data back into a server database where it can then be archived off to a proper email archiving solution.

The downside is that you risk bloating your Exchange databases in the process.  You might also make a mess of people’s inboxes if the imports are not directed to the right mailbox folders.

Import to Email Archives

Any good enterprise email archiving solution includes tools for importing PST files into the archive database.  The advantage of this option is that the data goes straight into the archives, is indexed and searchable, and doesn’t negatively impact the Exchange Server in the process.

PST Discovery

In either of the import scenarios above one of the big challenges is discovering all of the PST files on the network and correctly matching them up to mailbox users.  This is relatively easy when PST files are in a standard location such as the user home drive, but more complicated if they are stored in shared folders on the network or on PCs.

Discovery is also problematic on PCs because they can be offline at any time of the day, unlike servers which tend to run 24×7.  Custom scripts and third party file system analysis tools can assist with this, but the process will still be labour intensive.

Unfortunately the end users are not likely to be too much help identifying and locating their own PST files, as it’s not a concept they all fully understand.

Preventing PSTs from Returning

At some stage when the PST import challenge has been met the administrator will want to implement measures to prevent PST files returning to the network.  Fortunately this is fairly simple with Group Policy settings for Outlook, and File Server Resource Manager tools for Windows servers that can be used to implement file screening.

Though there is some effort involved to do it right, ridding the network of PST files is beneficial in the long term.

What to do With Those PST Files

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

The worst possible time to define your uptime and availability requirements for an Exchange environment is when that environment is unavailable.  No email administrator wants to hear “We need this working within 2 hours” when they are looking at a dead server that is going to take all night to recover.

Uptime and availability should be defined within an SLA, or Service Level Agreement.  An Exchange Server SLA should exist in all organizations, even those that provide their own internal IT services.  The SLA is between the IT supplier or IT department and the rest of the business, and clearly defines what is an acceptable downtime or outage of the Exchange environment.

Why Are SLAs So Important?

The existence of an SLA supports many facets of the design and operation of the Exchange Server environment.

Budget – When a business defines their service level requirements they are making a commitment to providing the funds necessary to deliver those service levels.  An SLA is one of the best pieces of leverage the IT department has to secure those funds and implement an appropriate Exchange system.  Without the backing of an SLA the IT department may struggle to get approval for Enterprise server licensing, multiple servers for clustering, and other high availability components.

Server and Network Design – Exchange Server environments are designed to meet defined SLAs.  Certain uptime expectations can only be met with the right server design.  A business that is willing to go a day without email would not need the same infrastructure deployed as a bank that can’t go more than 15 minutes without email.  Clustering, redundancy, site-to-site failover, are all design points that would be included or excluded based on the SLA.

Third Party Warranty – In very resilient environments, such as those with clustered servers, this is less of an issue.  But for an environment with SLAs for single points of failure, the right warranty response times need to be in place for SLAs to be met.  A 4 hour return to service target will not always work if it is paired with a 4 hour vendor response time, because the vendor meets their target simply by showing up on site within 4 hours.  After they then spend time fixing or replacing failed components, the IT team then has to potentially deal with other software and data recovery processes.

Backups – The backup system will be heavily influenced by the SLAs that are in place.  If the backup system cannot restore all of the required data within the SLA timeframe then of course the SLA cannot be guaranteed.

Staffing – The SLA will define the service levels for different times of day, and this will impact staffing levels.  If 8×5 support is all that is required, then that is a different staff level and rostering schedule than 24×7 support would be.

It all starts with the SLA.  Sometimes an organization has trouble defining their requirements before an actual outage occurs.  For those without any SLA at the moment my suggestions would be:

1. Analyze your current infrastructure and make an estimate as to how long a recovery would take under a variety of failure scenarios (e.g. single mailbox, single database, single server)
2. Identify the business processes that email supports and is involved in
3. Survey a sample of staff from various departments and teams, ensuring that each tier of employee is well represented in the survey

From that exercise you will gain an understanding of your business needs, technical capabilities, and the gaps that exist between them, and you can then begin work to formalise them as SLAs and implement changes in the environment to close those gaps.

Exchange Server SLAs, and Why You Need One

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

On more than one occasion I have worked with a customer whose email archiving strategy could be stated like this.

“When people stop working for us we never, ever delete their mailbox.”

As you might guess from the title of this post, that is not really “email archiving”.  You could call it “email keeping”, but I would put it as “creates more problems than it solves”.

If your email archiving strategy is to have no strategy at all, and that’s a deliberate decision by your organization, then consider some of the problems that you are creating.

• Every mailbox you keep adds to the size of the database, which therefore consumes more disk space, and more backup media
• Larger databases take longer to back up, and longer to recover if there is a problem
• Every mailbox you keep is an active mailbox that can potentially continue to receive emails, increasing your storage needs at a rate faster than necessary
• Every mailbox you keep is also an active user account, leaving a potential attack vector for hackers or disgruntled former staff
• When the time comes to migrate to a new email server, the amount of data to move is that much larger
• Keeping emails in mailboxes on an Exchange server (prior to Exchange 2010 which relatively few organizations have moved to yet) does not make them easily auditable

Email Archiving Solutions

A proper email archiving strategy can be conceived and executed with the right archiving solution.  Here are some of the ways that email archiving can be implemented.

• 100% of inbound/outbound email is journaled and archived at the time of transit for historical record.  This can be done to meet legal or regulatory compliance requirements if necessary.
• Email items that exceed a certain age threshold are removed from mailboxes into the archive store.  This is one method for keeping mailbox sizes down.
• Mailboxes that reach a certain “watermark” or size also have their oldest items removed to the archive store, even if they are not yet old enough.  This also helps keep overall mailbox sizes down.
• Mailboxes for inactive users are sent to the archive store and removed from the server entirely.  This allows email for former staff to remain accessible without impacting the email server.
• The archive store is in one or two centralized locations, which consolidates email archives down to as few main data centers as possible regardless of the number of actual email servers in operation.
• The archive store is end user-accessible, secure, and searchable for easy access to archive items for both users and auditors.

The cost to implement these types of solutions is often less than the ongoing costs of maintaining all of that data within the production email servers.  And instead of creating problems, a genuine email archiving strategy creates solutions and improves the email environment for everyone.

When Email Archiving Isn’t Really Email Archiving

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

Email is one of the most heavily used communications method which makes your Exchange servers critical to your business.

The health and performance of your Exchange servers should be a top priority, and this means that you must monitor the server performance as part of your routine so that problems can be discovered early and resolved before they begin to make a serious impact.

Here are 5 performance counters to monitor on your Exchange servers today.

1. % Processor Time

This counter shows the amount of time that the CPU is processing a task.  This counter should typically be below 75%, although it may run higher during heavy workloads such as backups.  If the processor time is consistently high you will want to look into which processes are utilizing the CPU the most.

2. Processor Queue Length

When instructions are sent to the CPU they go into a queue to be scheduled for execution.  This counter shows the length of that queue, and should ideally be no higher than 5 for each processor in the server.

When this counter is above the ideal threshold along with a high % Processor Time it indicates that the server workload is too high for the CPU resources available.

3. Memory Available MBytes

This counter shows the amount of memory that is not in use and is available for new tasks or processes, and should be at least 100Mb at all times.

If it drops below that threshold then the server memory is inadequate for the workload, and excessive disk utilization may result due to heavy pagefile use to compensate for the memory shortfall.

4. Memory Pool Paged Bytes

There is no threshold to watch for on this counter; however, it should be monitored for any increases over time which indicates a memory leak may be occurring.

5. Physical Disk Average Disk Queue

This counter should be monitored for each individual volume on the server, not for the total amount.  In general a disk queue of 2 or less is acceptable.  A higher disk queue, especially if it is sustained for a lengthy period, indicates that disk I/O is exceeding the performance capabilities of the disks themselves.

This can be normal during heavy disk operations such as backups, but should always be investigated to verify the cause.  When a high disk queue is noticed the first step is to break down whether it is being caused by read or write operations by inspecting the Disk Read Queue and Disk Write Queue.

A Basic Performance Snapshot

These 5 performance counters give you a very basic snapshot of your Exchange server performance. This is very useful even when no one is reporting any problems with the server, because it is important to have performance benchmarks during “good” times to compare to the times when a problem is reported.

If any of the counters indicate a problem in that area then you can start more comprehensive monitoring of related counters to narrow down the root cause of the issue so that it can be resolved.

5 Performance Counters to Monitor on Your Exchange Servers

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

Microsoft Office 2010 has reached the RTM (release to manufacturing) milestone, which means that it is now code complete and ready for release to the market.  This latest version of Office will become generally available next month.

Office 2010 includes Microsoft Outlook 2010, which sports a refreshed user interface and a range of new features to improve usability and productivity for email users, particularly in business environments.

The Ribbon

First introduced in other Office 2007 applications the Ribbon interface is now also included with Outlook 2010.

The 2010 version of the Ribbon is an improvement over the controversial 2007 implementations, with customizable tabs to make your most commonly used tasks and options more accessible.

Included in the Ribbon are Quick Steps, which are a series of buttons that you can configure to perform custom actions that you frequently take, such as creating a button to start a new email message for your team, or a button to archive an entire conversation in one click.

Conversation Management

Outlook 2010 has new views for combining and collapsing conversations so that they do not clutter up your inbox and their message sequence is not scattered among other inbox items.  You can also see your own sent items in the conversation which avoids the need to hop into the Sent Items folder to find your own messages.

As well as making it easier to follow ongoing conversations the new Ignore Conversation option lets you opt out of all further emails in that conversation, so that you can remove yourself from ongoing group emails without having to ask the senders to exclude you.  One of the best outcomes of this new feature will be a reduction in complaints from people caught up in “Reply All” email threads that they don’t want to be a part of.

And when you are replying to a message Outlook will now warn you if you are not replying to the most recent email in the conversation.

Multiple Mailboxes

While previous versions of Outlook allowed you to connect to multiple mailboxes in the same organization, Outlook 2010 now supports connections to multiple mailboxes across different organizations.

This is especially useful for administrators, consultants and road workers who need to access multiple email systems at different times during the day, and makes identity management less complicated without having to worry about “Send As” configurations for different mailboxes.

Large Mailbox Support

Exchange Server 2010 has had a database architecture overhaul to permit much larger mailboxes and databases.  Fortunately Outlook 2010 has also received an overhaul to its offline cache file so that it can handle these much larger mailboxes.  Where the previous version of Office could support up to around 2Gb cache files without risking corruption, Outlook 2010 can safely support up to 20Gb cache files.

Mail Tips

For Exchange Server 2010 environments running Outlook 2010 one of the best new features for reducing unnecessary email traffic is Mail Tips, particularly in larger organizations.

Mail Tips are a series of prompts and warnings that appear in Outlook 2010 to let the user know when they are about to take a potentially undesirable action.  For example, Mail Tips can warn a person when they are about to Reply All to an email that they were originally BCC’ed on, thereby revealing that they received the original email.

It can also warn of simple mistakes such as composing an email that would exceed size limits, or sending an email to a mix of internal and external recipients (e.g. risk of information leakage).

Because these warnings appear before the email is actually sent, in large companies Mail Tips can be useful for warning about:

• Sending to too large a distribution group
• Recipients who are currently Out of Office
• Automatic responses such as “this mailbox is not monitored”
• Sending to a moderated distribution group
• Sending to recipient you do not have permission to send to

Though Office 2010 does come with other great new features you can see from just these five that it will be a big improvement for email users.

5 Killer New Features of Outlook 2010

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

Email is not just for people.  It is also used by other services, applications and devices for a multitude of communication scenarios.

Some examples of this are applications that send email reports to users, such as enterprise backup software; devices that offer email capabilities, such as scan-to-email; and applications that receive and parse email messages, such as job ticketing systems.

With these types of requirements it is very common for an Exchange Server environment to host a lot of non-user mailboxes.  In larger environments this can present some challenges.  Each mailbox requires a corresponding user account, which presents some security risks.

And if not tracked and managed properly the number of mailboxes can grow and result in mailboxes that no one knows about or understands the actual purpose for.  This type of mismanagement will crop up at key times such as when migrating to a new Exchange Server, which makes planning and risk management difficult for the project team.

With all of that in mind here are some tips for maintaining a well managed Exchange Server environment for service and application mailboxes.

Only Use a Mailbox When Necessary

This may seem an obvious statement, but a mailbox is usually only required to receive email, not to send it.  For devices and applications that simply need to send out messages over SMTP there is usually no need to create them a dedicated mailbox.

For Meeting Rooms and Equipment Use Those Mailbox Types

Exchange Server 2007 and 2010 come with a dedicated mailbox type for room and equipment facilities.  Using the correct mailbox type ensures that the room or equipment is shown correctly in address lists and calendar appointments.

For more information about these mailbox types check out this three part series on managing Exchange resource mailboxes.

Secure the Mailboxes

When you do create mailboxes for non-user access always set a very strong password, and disable the user object in Active Directory.  When you use the special Room and Equipment mailbox types the account is automatically disabled for you.

The exception to this rule is for applications that need to authenticate with Exchange to function.  This is usually the case with backup products that need an active logon and mailbox to be able to backup the mailbox databases.

Use Descriptive Names and Notes

Two years from now when someone asks “What is this EUK-DRJ-VAR mailbox for?” and there is no one around who knows it is going to cause some headaches and potentially some service downtime if the mailbox is moved or modified.

Always give non-user mailboxes a clear, descriptive name that provides lots of clues as to what it is for.  Each mailbox also has a “Notes” field that can be filled out with as much detail as you like about the purpose of the mailbox.

Keep a Database or Register

Aside from descriptive naming and notes it is wise to keep a separate register of non-user mailboxes for reference over time.  This can provide the maximum detail about the mailboxes and avoid situations in the future where valuable time is wasted investigating mystery mailboxes.

Using just these few simple tips for creating and managing service and application mailboxes will ensure that administrative effort is minimised, services and applications aren’t interrupted unnecessarily, and changes such as migration projects don’t suffer delays.

How to Manage Service and Application Mailboxes in Exchange

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

Ten years ago we measured mailbox sizes in megabytes.  A 20mb mailbox was adequate.  A 100mb mailbox was a luxury.

Today we measure mailbox sizes in gigabytes.  A single message in today’s email communications could easily consume the entire mailbox quota of a decade ago.  We’re sending more email, bigger email, and keeping it longer.

Email server products such as Microsoft Exchange Server have responded to this growth in storage needs with support for more processing power, more efficient database schemas, and improved performance on storage hardware.

In fact, most of the storage performance gains of the last 4 years have been in the efficiency of the Exchange Server product itself, not in the performance capabilities of storage hardware.  Hard disks are getting bigger, but they aren’t getting faster.

As we become more reliant in the ability to retain and access email data quickly it is no surprise that we are storing more and more of it in our mailboxes.  This increase in email storage reveals some new bottlenecks in IT systems – the ability to adequately back the data up.

Backup Challenges

Backups are experiencing similar growing pains to disk storage.  Tape speeds and capacities increase through new generations of the technologies, but when disk speeds and network speeds don’t increase with them there is only so much throughput that you can achieve.  Eventually many larger enterprises reach a stage in which a nightly, full backup of the Exchange system is not possible within the backup window.

Three key technologies have surfaced to help enterprises manage these growth issues with email storage:

• Archiving
• Synthetic Backups
• De-Duplication

Archiving

Email archiving usually involves moving older, less frequently accessed data from the primary storage to a secondary storage system.  The secondary storage system may be built in to the email server, such as Exchange Server 2010’s archiving feature, or it might come in the form of a third party product that integrates with Exchange.

The benefit of archiving in reducing backup load is that once the data is stored in the archive it can be subject to different backup schedules than primary email storage.  While daily full backups of the primary storage might be a requirement, the archive stores may only require weekly or even monthly backups depending on the archive policies in place.

Meanwhile, good email archive systems still provide fast access to archived email items when required by end users.

Synthetic Backups

A synthetic backup combines the efficiency of an incremental backup (in which only data that has changed since the last backup is backed up) with the restorability of a full backup, by combining data from the incremental backup with existing data in the backup system from earlier backups to form a new, full backup.

In other words, if a file is already stored in the backup system and hasn’t changed, the backup system doesn’t need to copy it from the server again, it simply uses its existing local copy to “stitch together” a complete backup of the server.  Because not all data on a server is likely to change every day, the backup takes far less time than a full backup would, but achieves the same end result.

These synthetic backups can then be duplicated on to removable storage such as tape media to send offsite for longer term storage.

De-Duplication

Data de-duplication for backups means that multiple copies of the same data are not required to be backed up individually.  This is particularly effective in email systems, for example when 100 people all received the same email attachment only one copy of that email attachment needs to be backed up.

This reduces the amount of backup storage needed, but also the amount of backup traffic generated.  When the de-duplication occurs at the backup client itself there is less data required to be transmitted to the backup server, reducing overall backup times, yet still achieving a full backup.

Thanks to these three technologies of archiving, synthetic backups, and de-duplication the growing email storage needs of enterprises can be delivered while still achieving a reliable and effective backup regime.

3 Technologies for Improving Backup Efficiency for Growing Exchange Environments

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

We are conducting our lives and our businesses in an increasingly mobile world.  We need access to our critical business information from multiple locations and using multiple devices.

These needs often clash with the requirement to keep our data secure.  Exchange Servers are kept behind corporate firewalls which restrict who can access them and how they can connect to their mailboxes.

Secure mobile access to mailboxes on Exchange Servers is typically achieved through one or more of these methods:

• Virtual Private Network (VPN)
• Outlook Anywhere
• Outlook Web App (OWA)
• ActiveSync

Virtual Private Networks

A VPN is a secure communications tunnel established between two endpoints.  These endpoints can be two devices such as routers or firewalls, or can be between a client device such as a laptop and a firewall.

Mobile workers use VPNs to establish LAN-like network access to their corporate network.  This usually means that once connected to the VPN they have access to the same network resources they would be able to access when connected to the LAN from within the business premises.  In more security conscious environments this access is sometimes limited to just the few resources they need, but in a practical sense operates just as if they were on the LAN.

Using VPNs for access to Exchange Server makes sense when there are other needs for VPN access as well, such as access to application servers, file servers, or intranet sites.  Rather than each resource having its own independent access method, the VPN provides an “all in one” access solution.

However sometimes VPNs are not practical.  It is not uncommon for a mobile worker to find they are unable to establish a VPN tunnel because of restrictions on the foreign network they are currently working on.  This is mostly the case for IPSEC and PPTP VPN tunnels.  SSL VPN tunnels usually have no such problems because the SSL/HTTPS port is usually permitted out through firewalls.

Outlook Anywhere

Outlook Anywhere was formerly known as RPC-over-HTTPS, which accurately describes how it works.

The Outlook connection to a mailbox server over RPC is tunnelled through an SSL/HTTPS connection so that it can traverse firewalls, as well as to secure the communications over untrusted networks.

Outlook Anywhere is a good solution for secure access to email alone, but provides no access to other resources on the network that the mobile worker might need.

Outlook Web App

Outlook Web App (OWA), known as Outlook Web Access prior to Exchange Server 2010, provides a web-based interface to Exchange Server mailboxes over an SSL/HTTPS connection.  Because access is available via a web browser this makes it accessible for mobile workers who do not have access to the full Outlook software, such as on a home computer or an internet kiosk.

OWA communications are secured over SSL/HTTPS, however when using untrusted computers such as internet kiosks there is the risk of key loggers or other malicious software being used to compromise account passwords.

Because of this risk it is common to use multi-factor authentication with at least one of those being a biometric or a one-time password generated by a token, so that even if the username and password combination are compromised the account cannot be accessed without the additional authentication item.

ActiveSync

ActiveSync is the name of Microsoft’s technology for connecting devices such as smartphones to Exchange Server mailboxes.

The connection is once again secured over SSL/HTTPS and can be subject to numerous restrictions and security policies designed to mitigate the risk of loss due to theft or loss of the smartphone device (which is fairly high risk given their size and general lack of security features).

Those are the four most common secure remote access methods for Exchange Server mailboxes.  I’ve left out some other access methods such as POP and IMAP. Although these can be used securely they are not very common and don’t provide a full functionality experience with Exchange Server.  For most real world scenarios some or all of the above four methods are the solution for secure remote access.

4 Ways to Access Exchange Server Mailboxes through Firewalls

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

SearchExchange has written an article on the best and worst practices for email archiving in Exchange Server.  It is a detailed post and I agree with it, however it highlights some best practices that Exchange Server does not do very well on its own without additional systems in place.

PST Files

Outlook PST files are big disk space consumers and are not subject to inspection and retention by archiving systems.  Exchange Server itself cannot prevent the creation of PST files.  This requires the use of other systems such as Group Policy restrictions and file server storage policies.

For environments where PST files have been allowed to proliferate, Exchange Server offers very little in the way of tools to efficiently import the data into archives.  Fortunately there are third party email archive applications that do offer these tools for bulk processing of PST archives.

Separate Archival and DR Storage

The built in archiving available in Exchange Server 2010 does not separate active mailbox data from archive mailbox data.  Both types of data are stored in the same database, subject to the same backup and recovery process.

The best practice is to store and backup archive information on less expensive, high volume storage, and retain it separately (though it can be sent to the same offsite location as the active data).

During a recovery situation the active data can then be restored first as a priority, and archive data restored separately later when normal services have been resumed, because archive data is usually a much lower priority for restore in a DR situation.

Centralize Email Storage

Although Exchange Server environments are typically consolidated into fewer physical locations these days compared to previous years, in larger environments they are still often distributed into regional locations.

Archive information is best kept as centralized as possible, in one primary location with an additional offsite backup copy.  Again the archive features of Exchange Server 2010 limit this capability, because archive data is stored in the same location as the active mailbox.

Third party archiving systems that extract email data from Exchange Server and store it in separate databases are much more capable of the desired centralization.

Maintain Older Readable Versions of Archival Data

The Exchange Server database format has changed several times as the product has iterated through its version history.  Older versions of Exchange Server did not have database portability, which is the feature by which a foreign database can be mounted and read by a different Exchange Server than it was originally connected to.

Restoring very old Exchange data can often mean building a replica of the original Active Directory and Exchange environments in an isolated lab, a situation in which virtualization comes in very handy instead of trying to retain and rely on very old hardware platforms for this task.  Even so it is time consuming and cumbersome to retrieve the data.

On the other hand most third party archive systems store archives in a format independent of Exchange Server database developments, and that data is preserved and retrievable throughout any upgrades of the archiving product itself.

As good as Exchange Server is it is clear that adhering to best practices for email archiving will require organizations to look beyond Exchange at third party products that can integrate and offer more flexibility and reliability over time.

Email Archiving Best Practices that Exchange Server Doesn’t Do Well

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

The concept of message size limits in email systems dates back to the earliest years when email first became available.  In those days network speeds and server processing power were both much smaller than today’s modern computer networks.  Large emails could saturate the available bandwidth on network connections or overload a server to the point it would crash.

The concept carried forward into modern environments as email became an often overused method of transferring files between parties.  It was not unusual for Exchange Server environments to have multiple configurations in place that queued large email delivery for outside of business hours so that regular daytime email traffic was not slowed down.

Current versions of Exchange Server (2007 and 2010) removed that particular capability, in a nod towards modern networks having bandwidth and server resources far in excess of even just 5 years ago.

So does this mean the concept of message size limits is no longer important?  I helped a customer this week with a problem that demonstrates it is still very important.

The customer’s Exchange server had experienced a crash of the Transport services, which could not start and stay running for longer than a few moments before they would stop again.  The servers logs told me that the Transport services were exceeding their maximum threshold for resource utilisation and were then being stopped as a result.

On closer inspection I noticed that the Exchange servers had no message size limits configured on them.  There was one limit of 200mb specified on the hardware appliance that accepted incoming internet email, but otherwise no limits configured on internal or outgoing email.

My next step was to apply some generous, but still sensible, message size limits on the server.  The next time the Transport services started I was then able to inspect the queue and saw the message that had caused the original crash – a message with a 250mb file attachment.  With the new limits in place this message was rejected by the Transport service instead of trying to process it, and the server was able to be recovered to normal operations.

Exchange Server 2007 and 2010 offer multiple ways to configure message size limits, each of which is appropriate for different scenarios.

The first settings are the Organization limits, which apply to all Transport servers in the organization.  Because of its broad application this setting must be carefully planned so that it suits most usage scenarios in the environment, though it is possible to set more granular exceptions.

Each Transport server can also be configured with its own server-specific limits.  This is more often used on Edge Transport servers which by their nature are individually configured.

Active Directory Site links, which are the connections over which Exchange routes inter-site email, can also have their own message size limits applied.  This is useful if low bandwidth satellite sites exist that need to be restricted to much small sizes to prevent bandwidth saturation.

Each Transport server also has a series of Receive Connectors on it that can be subject to individual limits.  One possible usage scenario here would be scan-to-email devices that need to be permitted to send larger files than would normally be allowed to be sent by regular email users.

Outgoing email size restrictions can also be applied to Send Connectors to allow granular control over which size messages are allowed to go out from the network.  This is useful for when specific partner companies need to be sent larger files than normally allowed out of the network.

Finally it is possible to configure message size limits on a per-group and per-mailbox basis.  For example, the All Staff group can be limited to much smaller attachment sizes than normal so as to encourage more efficient methods of distributing files to staff.  Or specific users might need to be able to receive larger than normal file attachments from an important business application.

Because of the risks that oversized email messages still carry for Exchange Server environments, as I experienced this week, and the complexity of configuration options available in Exchange 2007 and 2010, it is important that size limits be carefully considered and planned for your Exchange server environment.

Are Message Size Limits Still Important in Exchange Server?

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