It does not take much to encourage me, and the positive comments I received on the post Inside Exchange 2010: What is the Transport Dumpster? was enough to convince me to take on another Inside Exchange 2010 post. In this post, we are going to take a look at a feature added to Exchange 2010 called Shadow Redundancy.

Shadow Redundancy is related to the Transport Dumpster in that it is a high availability mechanism implemented to prevent data loss if a failure occurs while a message is in transit. Whereas the Transport Dumpster is designed to protect against the failover of a mailbox server that is a part of a database access group, which means that it doesn’t offer anything for mailbox servers that aren’t, Shadow Redundancy can protect against data loss in an Exchange environment that includes only a single Edge Transport server and a Hub Transport/Client Acesss/Mailbox server.

Continue reading Inside Exchange 2010: What is Shadow Redundancy?

In our previous post involving Exchange and SharePoint, we covered how to troubleshoot issues with SharePoint sending outbound email through your Exchange infrastructure. In this post, we’re going to go over how to setup Exchange so that it can send email to SharePoint.

Enabling inbound email to SharePoint is a great way to allow users to email messages and attachments to SharePoint lists and document libraries. Email could originate from internal users or external, and can be used to simplify document submissions, or as a way to start a workflow. If a user creates a meeting and includes a SharePoint calendar in the invite, SharePoint can automatically create a calendar entry.

Continue reading How to Configure Exchange to Support Inbound Email for SharePoint

There are several components within Exchange 2010 that administrators may not come across unless they are troubleshooting very specific issues, or reading level 400 texts. This is the first post in what may become a series on some of the deeper internal workings of Exchange 2010. In this first post, I want to introduce you to the Transport Dumpster.

The Transport Dumpster is just one of the inner components of Exchange that sits quietly and unobtrusively on a Hub Transport server, helping to protect data in the event a server experiences any type of failure that would otherwise lead to a loss. You may not notice it, but you will be glad it is there, and in certain circumstances, you may want to adjust its default settings.

The Transport Dumpster first appeared with Exchange 2007, and is a queue that can be found on every Hub Transport server that resides in an Active Directory Site that contains a DAG. It helps prevent loss of data sent from the Hub Transport Server to a Database Availability Group when something fails that would result in a lost message. There is one Transport Dumpster per replicated database.

Continue reading Inside Exchange 2010: What is the Transport Dumpster?

In his article, “The Hub Transport Role”, John Bostock discusses the Hub Transport server role, what it is used for, when is it required, where it is deployed, etc. He reviews its history when it was known as the Bridgehead Role.

John explains that the Hub Transport Role must be deployed in every Active Directory site where other Exchange Server 2007 roles are already installed. As a best practice, your organization should deploy more than one Hub Transport server per site to provide redundancy. All transport rules settings, journal rule settings and connector configuration information are stored in Active Directory.

More importantly, the Hub Transport server role handles all mail flow inside the organization. Email messages that are sent to the Internet are relayed by the Hub Transport server to the Edge Transport server role. Email messages that are received from the Internet are processed by the Edge Transport server and then they are relayed to the Hub Transport server. The Hub Transport server can be configured to relay Internet messages directly or to utilize a third-party smart host in the even an Edge Transport server is not available. An administrator can also install and configure the Edge Transport server agents on the Hub Transport server as a means of anti-spam and viruses protection for their organization.

Continue reading Explaining the Hub Transport Server Role

Like all servers, email servers are subject to heavy loads and when that happens the servers can slow down to a crawl. And if administrators are not monitoring the performance then they’ll be sure to find out about the slower performance issues from their users.

Email servers can slow down for many reasons such as increased traffic flow or attacks on the server. Sometime it is a result of increased spam messages. Administrators can use the Queue Viewer graphical user interface to view information about messages and various queues such as the delivery queue. Additionally the command line interface for Exchange server can also be used to pull out information. Actions such as modifying the status of queues and messages can be performed individually or in bulk. One or more objects can be selected to perform these actions on.

In Exchange server, queues are used to hold messages before further processing can occur. There are five queues that exist only on Hub Transport servers or Edge Transport servers. Each of these queues is used in the processing of email messages which flow through the server. The processing queues include the following:

• Mailbox delivery queue
• Poison message queue
• Remote delivery queue
• Submission queue
• Unreachable queue

The transport server processes the messages contained in the queues. And access to the message queues is performed by the Exchange Server using the Extensible Storage Engine (ESE) low-level APIs.

Continue reading Troubleshooting Message Queues

Exchange Server 2010 has similar capabilities to Exchange Server 2007 when it comes to adding disclaimers to emails sent by end users.

However two improvements have been made in Exchange Server 2010 – the ability to use HTML to format the text, and the ability to insert Active Directory attributes into the text.

These new capabilities make it very easy to add a standardised email signature and disclaimer to all emails sent in the organization.

For this to work the desired Active Directory attributes need to be populated on the user account objects.  Attributes that would commonly be used in email signatures include the person’s name, job title, phone number, and street address.

You can view and edit these attributes in the properties of the mailbox or user account.

When the user accounts are populated with the necessary attributes you can proceed with the creation of the Transport Rule that will add the signature and disclaimer. Continue reading How to Add Automatic Email Signatures and Disclaimers with Exchange 2010

Most Exchange Server environments will grow beyond their original sizing.  Sometimes this growth has been accounted for in the design, and sometimes it is not.  In either case the question to ask as the user base increases is whether to scale up or scale out.

What do each of those terms mean?  An example of scaling up would be increasing the capacity of a server to handle higher loads.  An example of scaling out would be adding new servers to spread the higher load across more hosts.

Each approach has its pros and cons in the context of the different Exchange Server roles.  In this post I’ll discuss the Exchange Server 2007 Transport server roles and the different scaling considerations that they have.

Edge Transport/Hub Transport Servers

The role of the Edge Transport server is to route incoming and outgoing internet email while applying security and compliance rules to messages.  The role of the Hub Transport is basically the same though it is also responsible for routing emails between internal mailboxes as well.

The Transport Server workload relies primarily on fast CPUs to assess and process each email message against these rules, and fast disks for reading and writing messages to the transport queue.

Processor Scaling

Scaling up with more CPU cores to handle higher workloads is appropriate; however, there is a practical limit of 4 CPU cores per Edge Transport server and 8 cores per Hub Transport server.  This is an obvious “scale out” threshold for this server role – if the server is already at the maximum number of cores and CPU is showing signs of a performance bottleneck then it is time to look at scaling out to more Transport servers.

Disk Scaling

Disk performance is slightly different.  Each Transport server has a transport queue, which is a location on the disk in which emails are read and written in a database.  Emails are only temporarily stored in this queue, and large capacity disks are quite cheap and common in servers these days, so disk space is not likely to be a problem for the volume hosting the transport queue. Continue reading Scaling Up vs Scaling Out Exchange Server 2007 Roles Part 1 – Transport Servers

Exchange Server 2007 introduced new terminology for describing the domain names that it will accept email for, and what it will do with that email.  This is referred to in Exchange Server 2007 as Accepted Domains.

In Microsoft’s own words, “an accepted domain is any Simple Mail Transfer Protocol (SMTP) namespace for which a Microsoft Exchange organization sends or receives e-mail.”

Accepted Domains fall into one of 3 categories – Authoritative, Internal Relay, and External Relay.  Any given namespace that is an Accepted Domain can be only one of those three types.

Authoritative Domains

Authoritative Domains are those for which an Exchange organization hosts mailboxes that have email addresses that use that domain.

For example, a company named Contoso Pty Ltd may own the domain name contoso.com and use email addresses of name@contoso.com.  The Exchange organization would be configured to consider contoso.com an Authoritative Domain.

An organization can have more than one Authoritative Domain configured.  Using Contoso Pty Ltd as an example again, they may have a second brand name of Contoso Services and use the contososervices.com domain name in marketing materials.  In this case the Exchange organization would be configured with both contoso.com and contososervices.com as Authoritative Domains.

Internal Relay Domains

Internal Relay domains are those for which an Exchange organization hosts some, but not all of the mailboxes that use that domain.  This scenario is sometimes also referred to as a “shared SMTP namespace”.

Internal Relay domains are common when two companies have merged but are yet to consolidate their Exchange environment into a single organization.  When they have a need for consistent email addressing across both Exchange environments Internal Relay domains are the solution. Continue reading Understanding Exchange Server Accepted Domains

A few months ago I wrote about the challenges that email administrators face when asked to protect email distribution groups from spam and other unwanted emails.

I presented three options for protecting lists, each of which carried pros and cons.  Ultimately the best defense against spam to distribution lists is effective anti-spam filtering.

However anti-spam protection does not deal with mail that is not necessarily spam, but may be unwanted.  For example, a company’s “All Staff” email list may be available for use by anyone within certain guidelines, and the company wants each email checked first before they are sent to everyone to make sure inappropriate usage does not occur.

Exchange Server 2010 solves this problem for customers with a new feature called Moderated Transport.  Moderated Transport, or Email Moderation as most people will probably refer to it, is the capability to set certain recipients (either mailboxes or distribution groups) as a “moderated recipient” and designate one or more moderators who is responsible for deciding whether emails are delivered to that recipient or not. Continue reading Protecting Distribution Groups with Exchange Server 2010 Email Moderation

Let’s be clear about this before we go any further – yes you could use these techniques to spy on your staff, and yes at face value it may seem as though these techniques serve no purpose other than to spy on staff.  But the reality is that what I’m about to describe can be used quite legitimately within a business for purposes other than outright spying.

There are two features of Exchange Server 2007 that can be used for this – Journaling and Transport Rules.

Exchange Server 2007 Journaling

The best way to think of Journaling is that it is a way to make a copy of emails that match certain sender or recipient conditions.  Typically this is done for regulatory compliance purposes, such as a legal requirement to retain copies of all email received by a government department for Freedom of Information purposes.

When an email is “journaled” it is simply copied to another mailbox.  Basic Journaling will copy all emails sent to and from recipients on a mailbox database to a specified journal mailbox, whereas Premium Journaling allows some more granular control such as per-recipient journaling rules, but the concept remains essentially the same.

A genuine application of Premium Journaling might be to journal all emails sent to or from a customer service email address so that all such communications are kept on record.

Exchange Server 2007 Transport Rules

Transport Rules can be used to achieve the same outcome as Journaling however they have a lot more features available and offer much more granularity.  For example you can use Transport Rules to add disclaimers to emails in Exchange, or block confidential emails.

You can also use Transport Rules as a kind of internal email filtering for inappropriate content.  This would be useful for policing acceptable usage policies.  By configuring a Transport Rule that detects certain words and blind copies any such email to a HR mailbox for inspection an organization might detect and avoid harassment issues within the organization. Continue reading How to Spy on Your Staff with Exchange Server 2007