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.

Given the key role of a Hub Transport server, and the number of messages that could be in transit to a Hub Transport server if it suffers a failure, the potential for data loss might be significant without a way to preserve messages sent to an HT server until it can be confirmed that the messages were received, and this is where Shadow Redundancy comes into play. Shadow redundancy keeps a copy of every message it sends into the Exchange infrastructure until it receives a confirmation that the message was delivered successfully to the next server in the chain. Message delivery can include multiple hops in a larger environment where a message may need to cross multiple Hub Transport servers, and can have multiple paths to the destination mailbox. Shadow Redundancy only needs to keep a copy of a message until the next hop confirms that it has the message committed to its database. Once that confirmation is received, the message can be deleted from the transport database of the sending server. The process will repeat along each hop until the message finally reaches a mailbox server and is committed to the mailbox database. If a Hub Transport server sends a message to another server, and that server has a failure (unplanned, or even something as simple as an administrator shutting it down for maintenance, then when the sending server queries for delivery status, the confirmation cannot be obtained. The sending server will keep the message in a shadow queue so that when the server comes back online, it can resend the message. It will try to deliver the message again at five minute intervals, and will retry three times.

You may see this shadow queue appear and disappear when you are viewing queues on Edge or Hub Transport servers. The higher the volume of mail sent, the more likely you will see this queue appear and disappear as all messages are confirmed as being committed to the transport or mailbox database. The settings for Shadow Redundancy can be viewed, and changed, using the Exchange Management Shell. To view the parameters of Shadow Redundancy, enter this command at the EMS.

Get-TransportConfig | fl Shadow*

…fl is short for Format-List and Shadow* limits the output to parameters whose names start with Shadow.

There are four parameters, and their default values are returned.

ShadowRedundancyEnabled              : True
ShadowHeartbeatTimeoutInterval       : 00:05:00
ShadowHeartbeatRetryCount            : 3
ShadowMessageAutoDiscardInterval     : 2.00:00:00

Shadow Redundancy is enabled by default, and is set to check for delivery confirmations using a 5 minute heartbeat, and to retry 3 times. If it never gets a response, it will automatically delete messages after 2 days. All of these values can be configured, but should not be unless your specific situation is unusual, like a WAN connection that chronically fails. To change the parameters, you can use the Set-TransportConfig command.

If you found this post useful, leave a comment or retweet it and I’ll work on adding a third to the series.

Inside Exchange 2010: What is Shadow Redundancy?

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

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.

The easiest (preferable) way to facilitate inbound email to Exchange is to use your SharePoint site name or a similar subdomain of your email domain. For example, if your email domain is retrohack.com, use sp.retrohack.com as your SharePoint subdomain. In my case, that is also the URL used to access SharePoint, which makes it even easier for users to understand. Users can send emails to list@sp.retrohack.com. Setting up Exchange and SharePoint so that you can send emails in to SharePoint requires four steps. Three of these are done on SharePoint, and only one on Exchange, but since many SharePoint admins will want assistance from their email admins when enabling inbound email to SharePoint, you will want to know all the parts. Here they are:

1. Enable incoming email on SharePoint.
   In SharePoint Central Administration, go to the Operations tab and click on “Incoming Email Settings.” Enable sites to receive email, leave the setting for Automatic mode, leave the setting for SharePoint Directory Management Service to No, add the subdomain you have chosen to the field for E-mail server display address:, and choose whether you want to accept email from any host, or if you want to enter the FQDN or ip.addr of each of your hub transport servers.
2. Install the SMTP service on each of the SharePoint web front ends in your farm (you may only have the one.)
   This is a feature in Windows 2008. If you are not sure how to do this, see this article.
3. Configure your Exchange infrastructure to forward email to your SharePoint infrastructure.
   On your Exchange server, launch the EMC. Browse down to the Organization Configuration and click Hub Transport. Click the action item for “New Send Connector” to launch the wizard. Name the connector, in the Address Space enter the FQDN of your chosen SharePoint email subdomain (sp.retrohack.com in my example above.) On the Network Settings, choose to Route Mail Through the Following Smart Hosts, and enter the FQDN or the ip.addr of the SharePoint WFE on which you installed the SMTP service. Leave the authentication and Source Server settings to default.
4. Enable the document libraries and lists that you want to receive email.
   In SharePoint, browse to the list or document library you want to receive email, click on Settings, Document Library Settings, and configure the settings the way the SharePoint admin wants.

Since the Exchange server will send email to anything@sp.retrohack.com, the SharePoint server will deal with matching the name of the list or library to what is in an incoming email. As the Exchange admin, you can create contacts so that important lists and libraries will appear in the GAL, or work with the SharePoint admin and Active Directory admin to enable the Directory Management Service. This is a way for SharePoint to put contacts into AD directly when a list or library is email enabled, which will then show up in the GAL. That is a topic for another post, which we’ll cover next week.

How to Configure Exchange to Support Inbound Email for SharePoint

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

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.

When a message is sent from a Hub Transport server to a Mailbox server, the messages is stored in the Transport Dumpster queue for the DAG until the Hub Transport server receives a notification that the transaction logs for a particular message have been replicated to all copies of the DAG and inspected by the Mailbox server. Once every DAG member confirms that the message logs have been committed, the message will be purged from the queue, but if a DAG member either does not acknowledge the logs, or reports that the logs failed, the Transport Dumpster can resend the information to the DAG member.

The Transport Dumpster stores messages for a period of time controlled by the MaxDumpsterTime setting, which is seven days by default, or when the maximum size of the queue is reached. The default for that is 18MB, but Microsoft recommends that this is set to 1.5 times the maximum message size limit. Whenever one or the other limit is reached, messages are purged on a first-in, first-out basis. You can view the current settings using the EMS and running the command

Get-TransportConfig | fl *Dumpster*

You can adjust the parameters for the Transport Dumpster by using these commands in the EMS. In these examples, we set the size to 30 megabytes, and the lifetime to 4 days.

Set-TransportConfig -MaxDumpsterSizePerDatabase 30MB

Set-TransportConfig -MaxDumpsterTime 4

You can enter the size specifying MB for megabytes, or you can enter a value in bytes. The time can be entered in EnhanceTimeSpan format, but a simple digit will give you days.

It is important to note that the Transport Dumpster does not protect against data loss during a failure should the message be destined for either a public folder, or for a mailbox database that is not a part of a Database Availability Group. It can only protect replicated mailbox databases.

If you found this post interesting/useful, please leave a comment to let me know, or tweet it if you’d prefer. If there is enough interest, I will continue the series on the inner workings of Exchange.

Inside Exchange 2010: What is the Transport Dumpster?

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

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.

Administrators should be made aware of some of the “gotchas” when the Hub Transport role is setup in an Exchange mixed environment. There are some issues involved if the mixed environment includes Microsoft Windows Server 2000 based clustered systems that host an older version of Exchange virtual server.

In those Exchange mixed environments, the installation of an Exchange 2007 Hub Transport role may fail. The failure can occur if any legacy Exchange cluster server, which is running on a Windows 2000 platform as the target bridgehead server, is selected. If an error message is generated then it may look like the following:

“Cannot find computer object in Active Directory for server ‘virtual server name’ “

This error message occurs as a result of a bridgehead server in the existing cluster being selected using the Mail Flow Settings page in Exchange Server 2007 setup. This procedure is prohibited because the cluster is hosting a legacy Exchange server.

To avoid this problem, a routing group connector should be created in Exchange Server 2007 during the Exchange Server 2007 Setup. A server account should be added to the ExchangeLegacyInterop security group for the connected system in Active Directory. Unfortunately, Windows Server 2000 cluster servers do not have these accounts in the Active Directory directory service. This prevents the server account from being added to the ExchangeLegacyInterop security group. And so the error message, listed above, is generated.

If the Routing Group Connector was manually created using the New-RoutingGroupConnector command then the following error message may be received:

New-RoutingGroupConnector : Active Directory operation failed on <GC Server>.Domain.com. This error is not retriable. Additional information: The name reference is invalid. This may be caused by replication latency between Active Directory domain controllers. Active directory response: 000020B5: AtrErr: DSID-03152392, #1:0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 262b30e2 (msExchTargetBridgeheadServersDN) At line:1 char:26 + New-RoutingGroupConnector <<<< -Name “RGC Name” -SourceTransportServers “2007Source.domain.com” -TargetTransportServers “2003Target.domain.com” -Cost 1 -Bidirectional $true -PublicFolderReferralsEnabled $true VERBOSE: New-RoutingGroupConnector : Ending processing.

An administrator might try to run the New-RoutingGroupConnector command using the -Debug -Verbose switch but will most likely receive the following error message:

VERBOSE: New-RoutingGroupConnector : The properties changed are: “{ TargetRoutingGroup=’CORPHQ’, Cost=’1′, TargetTransportServerVsis={ ’1′ }, ExchangeLegacyDN=’/o=Org/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Connections/cn=RGC Name’, PublicFolderReferralsDisabled=$False, VersionNumber=’7638′, SourceTransportServerVsis={ ’2007Server\1′ }, HomeMTA=’Microsoft MTA’, MinAdminVersion=’-2147453113′, SystemFlags=’Renamable’, Id=’RGC Name’, RawName=’RGC Name’ }”.

VERBOSE: New-RoutingGroupConnector : Saving object “RGC Name” of type “RoutingGroupConnector” and state “New”.

VERBOSE: New-RoutingGroupConnector : Previous operation run on domain controller ‘<GC Name>.domain.com’. Confirm Active Directory operation failed on <GC Name.domain.com. This error is not retriable. Additional information: The name reference is invalid. This may be caused by replication latency between Active Directory domain controllers. Active directory response: 000020B5: AtrErr: DSID-03152392, #1:0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 262b30e2 (msExchTargetBridgeheadServersDN)

An administrator can try to fix this problem by installing the Microsoft Windows 2000 Server Service Pack 3 (SP3) to create a server account in Active Directory. This should correct the problem associated with the clustered virtual server.

Explaining the Hub Transport Server Role

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

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.

Sometimes the queues fill up with many non-delivery reports from the postmaster account. This condition can occur if your computer is the target of a reverse non-delivery report (NDR) attack. This issue can be resolved by creating a recipient filter to prevent Exchange Server 2003 from accepting messages that are sent to recipients who do not exist.

Another problem that can happen is when message flow is slow to the local delivery queue. When this occurs then email messages in the Simple Mail Transfer Protocol (SMTP) queue will get backed up. These email messages that are bound for local delivery end up getting trapped in the SMTP queue. A further undesirable result is that of high disk queue lengths on the Exchange Server’s install drive. This install drive is typically used for the C:\Program Files\Exchsrvr\ directory. These conditions can occur when the information store working folder’s disk drive gets too busy and slows down.

This type of problem can be corrected by pointing the working folder of the information store used for email message conversion to a faster drive. An administrator can follow the steps below:

1. Start – Run – type in “regedit” to start the Registry Editor.
2. Locate the following key in the registry and then select it: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
3. Double-click Working Directory:REG_SZ:Folder_Path in the right hand pane.
4. Type the path of a folder on a faster drive in the String Editor box.
5. Click OK.
6. Close the Registry Editor.

As always, any time you touch the registry you should first make a backup of the registry. This way, if there is a problem for whatever reason; you’ll be able to restore the registry to a known working point.

A similar problem can occur because of a disconnected SMTP mailbox. This can cause messages to be held in the local delivery queue. Administrators might try to dismount and then remount the information store to correct the problem. This action, however, can result in more event error messages being logged in the application log such as the following:

Event Type: Error
Event Source: MSExchangeTransport
Event Category: Exchange Store Driver
Event ID: 326
Date: date
Time: time
User: N/A
Computer: ServerName
Description:
Service Account failed to logon to the store as
/o=organization/ou=First Administrative Group/
cn=Configuration/cn=Connections/cn=SMTP
(ServerName)/cn={CCCF3BE6-219C-4379-985D-851B766EDDC7}.
Error code : 0x80040148. For more information,
click http://search.support.microsoft.com/search/?adv=1.

Event Type: Error
Event Source: MSExchangeTransport
Event Category: Exchange Store Driver
Event ID: 326
Date: date
Time: time
User: N/A
Computer: ServerName
Description:
Service Account failed to logon to the store as
/o=organization/ou=First Administrative Group/
cn=Configuration/cn=Connections/cn=SMTP (ServerName)/
cn={CCCF3BE6-219C-4379-985D-851B766EDDC7}.
Error code : 0x80040158. For more information,
click http://search.support.microsoft.com/search/?adv=1.

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1194
Date: date
Time: time
User: N/A
Computer: ServerName
Description:
Accept clients on external interface SMTP
failed with error 0x80004005. For more information,
click http://search.support.microsoft.com/search/?adv=1.

This problem can be resolved – assuming the Active Directory object for the SMTP mailbox is missing – by creating a new mailGateway object in Active Directory. This newly created object will have a new GUID. The next time the store is mounted the information store will create a new SMTP mailbox object.

Troubleshooting Message Queues

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

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.Open the Exchange Management Console and navigate to Organization Configuration/Hub Transport.  Right-click and start a New Transport Rule.

Give the rule a meaningful name and description and click Next.

Choose the condition “From users that are inside or outside the organization” and make sure it is set to “Inside the organization“.

Choose the action “Append disclaimer text and fallback to action if unable to apply“.

Now click on the blue highlighted “disclaimer text” to configure the signature and disclaimer.  You can use simple HTML tags to format the text, and wrap the Active Directory attribute name in %% tags to insert the attributes automatically.

For example, this is the text that I have used for this demonstration.

Complete the New Transport Rule wizard to finish creating the rule.

You can now test the new rule by sending an email to anyone inside or outside of the organization and seeing the signature and disclaimer text automatically inserted by the Exchange server.

How to Add Automatic Email Signatures and Disclaimers with Exchange 2010

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

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.

On the other hand, disk speed may become a problem in larger Exchange Server environments where email traffic is very high.  Because the transport queue can’t be split across multiple volumes within a single server if disk performance becomes a bottleneck the only option is to scale out to more Transport servers.

Scaling Impacts

Scaling up a Transport server usually won’t affect the configuration requirements for the server.  However scaling out often will require some configuration or architecture changes.  Hub Transport servers have their own load balancing algorithms built-in so not much needs to be done there, but Edge Transport servers will need some attention.

Each Edge Transport server needs to be “subscribed” to the Active Directory Site that hosts the Hub Transport servers it will relay messages with.  This subscription is configured per-server.  Furthermore, there is no common settings location for multiple Edge Transport server, each must be configured individually (although this can be scripted to reduce administrative effort).

Finally, once you scale out to more than one Edge Transport server either multiple public IP addresses and MX records are required, or a load balancing solution needs to be implemented for inbound internet email traffic.

In the next post in this series I will discuss scaling considerations for the Client Access server role.

Scaling Up vs Scaling Out Exchange Server 2007 Roles Part 1 – Transport Servers

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

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.

When an Accepted Domain is configured as Internal Relay it tells the Exchange organization to accept mail for that domain, but if no recipient in that organization has that email address then it looks to the list of Send Connectors to determine where to send it next.

For example, if Contoso Pty Ltd and Northwind Traders formed a new company Contoso Traders with a new domain name of contosotraders.com, then each existing Exchange organization is configured with two items to share the SMTP namespace:

• An Internal Relay domain of contosotraders.com
• A Send Connector for the namespace contosotraders.com that sends email for unknown recipients to the other Exchange organization

External Relay Domains

External Relay domains are those for which an Exchange organization will accept email, but hosts no mailboxes for that domain.  This scenario might occur when one organization is acting as an ISP for other organizations, or offering services such as email content filtering.

External Relay domains are used when one Exchange organization is accepting email from the internet for a non-authoritative domain name, and then forwarding it on to the authoritative Exchange organization.  This is usually performed at the Edge Transport Server to keep email for non-authoritative domains from entering the corporate network.  For this to occur the Edge Transport Server is configured with two items:

• An External Relay domain
• A Send Connector for the namespace that sends the emails to the authoritative Exchange organization

In these scenarios it is also common for the Edge Transport Server to be used as an outbound email relay, or smart host, for the authoritative Exchange organization.

Summary

For most Exchange organizations the Authoritative Domain type is the only one used, however it is important for email administrators to understand the full capabilities of Accepted Domains as explained above.

Understanding Exchange Server Accepted Domains

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

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.Moderated Transport operates in several ways.  Firstly, for users running Outlook 2010 or the Exchange 2010 Outlook Web App (the new name for Outlook Web Access) they will receive an on screen notification that the recipient they are sending to is a moderated recipient.

After the message is sent instead of delivering to the recipient it is instead sent to an arbitration mailbox.  The designated moderators are then each sent a message notifying them of a new email requiring moderation.  If the moderators are running Outlook 2010 or Outlook Web App they will see a clear explanation of what is required of them.  For users running older versions of Outlook they will see the traditional voting buttons instead, which will allow them to perform their moderation duties.

As mentioned earlier there can be multiple moderators assigned to a moderated recipient.  In fact this is wise so that any staff absences or other distractions don’t hold up delivery of messages.  Even though there are multiple moderators only one is required to make a moderation decision.  Once a moderator has approved or rejected a message all other moderators have the moderation request automatically removed from their Inbox to save on clutter and confusion.

There are a few other caveats for email moderation that customers should be aware of.  It is only applied by Exchange Server 2010 Hub Transport servers.  If an organization still has Exchange Server 2007 Hub Transport servers anywhere in the network they will ignore moderation settings and deliver all emails to their recipients.

Any groups that are nested within other groups also need to be considered.  Moderation needs to occur for all moderated groups, even those nested within another moderated group that has already had the message approved.  This is, however, unless an override flag has been configured to allow a parent group’s moderation to apply to all groups nested within it, which is useful to prevent child group moderators from rejecting messages that other parent moderators have already approved.

Finally, email moderation is not intended to completely replace other delivery restriction settings.  Those restrictions can still be applied and will take precedence over moderation settings.

Moderated Transport is a very useful new feature of Exchange Server 2010 that many organizations will be able to benefit from immediately.

Protecting Distribution Groups with Exchange Server 2010 Email Moderation

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

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.Similar rules could be configured to detect certain words that refer to trade secrets or confidential information to try and detect anyone discussing those topics with outside parties.

Less ethical uses might include use of Transport Rules to find out who is emailing recruitment firms looking for a new job, or who is discussing romance, religion, or other private matters.

The Email Administrator’s Dilemna

Although the title of this post was designed to be slightly tongue in cheek, the reality is that email administrators can be put into some tough situations by the availability of these features.

Just about any email server product has had the ability to tell from log files who emailed who and at what time, but usually doesn’t include any of the actual email content (sometimes the subject line is logged).  This is for two main reasons – firstly we really don’t care what is in the email itself, we’re only interested in whether or not it got delivered, and secondly logging all of the email content would take up a lot of disk space.

Journaling has been a feature of Exchange Server prior to the 2007 version, but Transport Rules are new to Exchange 2007.  These features can mean a few tricky situations for email administrators to be aware of.

Firstly there are the legal considerations, such as whether the availability of the feature compels you to employ it to protect staff, for example from email harassment.  Another legal consideration is whether the use of these features will result in email administrators being dragged into any legal matters that might spawn from email communications.  From personal experience this is a very real possibility.

Secondly there are the ethical considerations.  If you as the email administrator are directed by a superior to configure a Transport Rule that would effectively spy on an individual within the organization you might be enabling harassment or bullying to take place, which could land you in some hot water if you go along with it.  Again from personal experience this can happen, but usually if the request is from HR or an Internal Audit department it is clearly okay.

So there you have it, two useful and powerful features of Exchange Server 2007 that can be used for a variety of good and evil purposes.  Make sure you understand each feature, its capabilities and limitations, and always consider the legal and ethical implications of the actions you take with them.

How to Spy on Your Staff with Exchange Server 2007

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

Exchange Server 2007 provides the capability to append a text disclaimer to any email message.  This capability is provided by the Transport Rules feature of the Hub Transport Server.  Email disclaimers are required by some businesses to notify recipients of such matters as copyright, confidentiality, or liability of a sent email.

Transport Rules are configured to perform certain actions on any email message that matches the criteria of the rule.  For example a Transport Rule can be configured to blind copy all emails sent to a certain person to another person.   For email disclaimers the Transport Rule is simply configured to append the text disclaimer to any message sent to an external recipient by using these steps.Open the Exchange Management Console and navigate to Organization Configuration and then Hub Transport.

Click on New Transport Rule in the Actions pane of the management console.  Give the new rule a name such as “Outbound Email Disclaimer” and click Next.

Set the conditions to be “Sent from users Inside the organization” and “Sent to users Outside the organization”, then click Next.

Select the action “Append disclaimer…”.

Click on the blue underlined “disclaimer text” and configure the disclaimer message that you want appended to each outgoing email.  You can also modify the font, color, size etc using the other blue underlined settings.  Click Next when you are satisfied with the configuration of the message.

Configure any exception criteria for the disclaimer.  For example you may want to not apply the disclaimer for outbound messages sent to a public mailing list.

Click Next when you are finished with the exceptions, and then click New to create the Transport Rule.  Click Finish to complete the wizard.

The text disclaimer will now appear at the end of each outbound email message.

You can change the disclaimer or the conditions it applies to simply by re-running the wizard for that Transport Rule.

How to Configure Email Disclaimers in Exchange Server 2007

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

In Part 1 of this series I discussed backup and recovery for each of the Exchange Server 2007 server roles and associated systems such as Active Directory.  In Part 2 I then described the process of backing up and recovering a Mailbox Server from the loss of a mailbox database.  In this part of the series I will demonstrate backup and recovery of the Hub Transport Server and Edge Transport Server roles.

Backing up Transport Servers

Unlike Mailbox Servers, the Hub Transport and Edge Transport roles do not require any special Exchange-aware backup software.  All of the necessary data for recovering a Transport server is contained within:

• Active Directory (for Hub Transport servers, but not Edge Transport servers)
• The Active Directory Application Mode (ADAM) database (for Edge Transport servers)
• The server’s file system
• The server’s System State

Hub Transport servers can be backed up using the built in Backup utility in Windows Server.  At the very least the backup should include the System State and the C:\Program Files\Microsoft\Exchange Server\TransportRoles location of the file system (and all sub directories).

Edge Transport servers are backed up in the same way as Hub Transport servers except for the Exchange Server configuration.  Because this is stored in ADAM it must first be cloned using the Export-EdgeConfig.ps1 script located in C:\Program Files\Microsoft\Exchange Server\Scripts.  Execute the script with the name of the file you wish to export to. Note this is a single command run on one line in the Exchange Management Shell.

export-edgeconfig.ps1 c:\edgeconfig.xml
 -key "abcdefghijklmnop"

It is recommended to either include this config file in your Edge Transport backups or use a path that is a shared folder on a remote server.

Recovering Hub Transport Servers

In this scenario the EXCHHUB server has been lost due to hardware failure.  Spare server hardware has been used to reinstall Windows Server 2003 along with the Exchange Server 2007 pre-requisites.  The newly built server has the same name and IP address of EXCHHUB.  Now we can begin the recovery of the Hub Transport server.
First, remove any Edge Subscriptions that existed for the Hub Transport server being recovered.  If you skip this step you may receive a certificate error during the recovery install.

In a command prompt run the following command from the location of the Exchange setup files.

setup /m:RecoverServer /DoNotStartTransport

This runs setup in recovery mode along with an additional instruction to not start the Transport services straight away.  This is so we can restore our mail queue databases and log files from the most recent backup before the server is put back into operation.

Recovering Edge Transport Servers

In this scenario the EXCHEDGE server has been lost due to hardware failure.  As with the Hub Transport server a new server and operating system has been installed with the same name and IP address.

To recover the Edge Transport server we will use the ImportEdgeConfig.ps1 script that ships with Exchange Server 2007.  First we run the script against the exported Edge config file from earlier to validate its contents. Note, this command is all one line.

ImportEdgeConfig.ps1 -cloneConfigData c:\edgeconfig.xml
 -isImport $false -CloneConfigAnswer c:\configanswer.xml
 -key "abcdefghijklmnop"

Validation succeeded for ConnectivityLogPath element of
 type DirectoryPath
Validation succeeded for MessageTrackingLogPath element of
 type DirectoryPath
Validation succeeded for PickupDirectoryPath element of
 type DirectoryPath
Validation succeeded for PipelineTracingPath element of
 type DirectoryPath
Validation succeeded for ReceiveProtocolLogPath element
 of type DirectoryPath
Validation succeeded for ReplayDirectoryPath element of
 type DirectoryPath
Validation succeeded for RoutingTableLogPath element of
 type DirectoryPath
Validation succeeded for RootDropDirectoryPath element of
 type NullableDirectoryPath
Validation succeeded for SendProtocolLogPath element of
 type DirectoryPath
Validation succeeded for SourceIPAddress element of
 type IPAddress
Validation succeeded for SourceIPAddress element of
 type IPAddress
Validation succeeded for Bindings element of type Bindings
Validation succeeded for Fqdn element of type FQDN
Answer File is successfully created: c:\configanswer.xml

Note that the key is the same one used when the Edge config was exported earlier.  If any validation steps were unsuccessful open the answer file in a text editor and adjust the settings that it lists as invalid.

Once the config has been validated it can be imported with the same command but modifying the -isImport parameter to $true. Note again this is a single command.

ImportEdgeConfig.ps1 -cloneConfigData c:\edgeconfig.xml
 -isImport $true -cloneConfigAnswer C:\configanswer.xml
 -key "abcdefghijklmnop"

Importing Edge configuration information Succeeded.

Now that the Edge Transport server configuration has been restored you can re-create the Edge subscription between the Edge Transport and Hub Transport servers.

How to Back Up and Restore Client Access Servers

In the final part of this series I will demonstrate the process of backing up Client Access servers and then recovering them from failure.

Exchange Server 2007 Backup and Recovery Part 3 – Transport Servers

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