Exchange Server Pro » Exchange 2007

Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports

Paul Cunningham — Mon, 06 Feb 2012 12:05:54 +0000

One of the Exchange Server administration tasks I perform almost every day is creating mailbox size reports. There are a few different reasons that I create these reports, such as planning a mailbox migration project, responding to a storage capacity alert for a particular database, or providing a specific team of people with a report of their mailbox sizes.

Now it is pretty easy to get the sizes for Exchange mailboxes and to handle the formatting of the Exchange 2010 mailbox statistics so that they are easier to perform calculations on, but it gets a bit boring running those commands day after day.

Even worse, after running the commands to create a CSV report I still had to open that in Excel, remove the unwanted details, use Excel formulas to convert the values from bytes to megabytes, sort them into order, and so on. Again not difficult, just boring after doing it hundreds of times.

So I created a PowerShell script, Get-MailboxReport.ps1, to do all of the heavy lifting for me, and I’m sharing that script with you here.

Download the script file here: Get-MailboxReport.ps1 (downloaded 315 times so far)

Let’s take a look at how the script works. Here if a video to demonstrate:

I’ve included help information within the script itself so you can use Get-Help to discover how to run the script.

[PS] C:\Scripts\demo>Get-Help .\Get-MailboxReport.ps1

NAME
    C:\Scripts\demo\Get-MailboxReport.ps1

SYNOPSIS
    Get-MailboxReport.ps1 - Mailbox report generation script.

SYNTAX
    C:\Scripts\demo\Get-MailboxReport.ps1 [-database ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-file ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-server ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-mailbox ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-all] []

DESCRIPTION
    Generates a report of useful information for
    the specified server, database, mailbox or list of mailboxes.
    Use only one parameter at a time depending on the scope of
    your mailbox report.

RELATED LINKS
    For more script details, a video demo, or to give feedback please go to:

http://exchangeserverpro.com/powershell-script-create-mailbox-size-report-exchange-server-2010

REMARKS
    To see the examples, type: "get-help C:\Scripts\demo\Get-MailboxReport.ps1 -examples".
    For more information, type: "get-help C:\Scripts\demo\Get-MailboxReport.ps1 -detailed".
    For technical information, type: "get-help C:\Scripts\demo\Get-MailboxReport.ps1 -full".

Depending on which parameter you use the output will vary.

If you use the -mailbox parameter to query a single mailbox, then the output will appear in the console window. I don’t really see the need to output a single mailbox’s details to a CSV file.
If you use any of the other parameters, -server, -database, -file, or -all, the output will be written to a CSV file in the same folder you’re running the script from.

Once you’ve generated the CSV report you can open it with Excel and begin to analyze the data.

Download the script file here: Get-MailboxReport.ps1 (downloaded 315 times so far)

Change Log:

6/02/2012 – V1.0 – Initial version

Get more Exchange Server tips at ExchangeServerPro.com

Update Rollup 6 for Exchange 2007 SP3 Released

Paul Cunningham — Fri, 03 Feb 2012 12:36:01 +0000

Microsoft has announced the release of Update Rollup 6 for Exchange Server 2007 Service Pack 3.

From the Microsoft Exchange Team blog:

This update contains a number of customer-reported and internally found issues since the release of RU5. See KB 2608656: Description of Update Rollup 6 for Exchange Server 2007 Service Pack 3′ for more details.

We would like to specifically call out the following fixes which are included in this release:

DST Cadence Release for Dec 2011 – Exchange 2007

22656040 An Exchange Server 2007 Client Access server may respond slowly or stop responding when users try to synchronize the Exchange ActiveSync devices with their mailboxes

2498852 ”0×80041606″ error message when you perform a prefix search by using Outlook in online mode in an Exchange Server 2007 environment

22653334 The reseed process is unsuccessful on the SCR passive node when the circular logging feature is enabled in an Exchange Server 2007 environment

22617784 Journal reports are expired or lost when the Microsoft Exchange Transport service is restarted in an Exchange Server 2007 environment

2289607 The week numbers displayed in OWA do not match the week numbers displayed in Outlook for English users and French users in an Exchange Server 2007 environment

Update Rollup 6 can be downloaded here.

Get more Exchange Server tips at ExchangeServerPro.com

Error: Outlook Was Unable to Recover Some or All of the Items in this Folder

Paul Cunningham — Wed, 14 Dec 2011 10:13:26 +0000

While attempting to restore items from the Outlook recoverable deleted items you may encounter the following error message.

Outlook was unable to recover some or all of the items in this folder. Make sure you have the required permissions to recover items in this folder, and try again. If the problem persists, contact your administrator.

The error may occur when you attempt to recover a folder that contains a large number of sub-folders or mail items in it.

On the Exchange Server you may see a corresponding Application event log entry similar to this:

Log Name:      Application
Source:        MSExchangeIS
Date:          11/14/2011 12:57:59 PM
Event ID:      9646
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      exchangeserver.domain.local
Description:
Mapi session "3bbea118-07e3-4746-b7bf-0e5b65e28314" exceeded the maximum of 500 objects of type "objtFolder".

This can occur due to the default limits configured on the Exchange Server for the number of items that can be opened by a single MAPI session. In the example above the MAPI session was trying to open more than the default 500 allowed objects of type “objtFolder” (in other words, Folders).

The solution is provided by Microsoft in this support article, which refers to Exchange Server 2003 but applies to later versions as well.

Open Regedit and navigate to \\HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
If the key “MaxObjsPerMapiSession” does not already exist, right-click on ParametersSystem and create a new key of that name.
Create a new DWORD value with a name matching the object type in the event log error on your server (eg “objtFolder” in this example)
Set the DWORD value to a decimal value higher than the default. For the case above I first tried 1000, then 10000 when that did not work.
Wait 15-30 minutes for the registry change to take effect, then retry the Outlook operation.

You may find that you need to try gradually increasing the value until you can successfully recover the items in Outlook. You may also find that after you’ve removed one limit that another object type’s limit may also suddenly come into play, so always check your event log for new errors identifying additional object types that you may need to add a registry value for.

After you’ve successfully recovered the Outlook items revert the registry keys to their default values (listed in the Microsoft support article above) to prevent issues with server resources in the future.

Get more Exchange Server tips at ExchangeServerPro.com

Using Test-Mailflow with Exchange 2003 Servers

Paul Cunningham — Sun, 04 Dec 2011 12:32:49 +0000

One of the challenges of managing a large Exchange Server environment is that you often need to support multiple versions of Exchange.

That means that often when you write a PowerShell script you need to account for servers running different versions and adjust accordingly. It can turn a simple scripting exercise into a big task.

Recently I was looking at ways to include our Exchange 2003 servers in some monitoring scripts that are already running for Exchange 2007/2010 servers. I wanted to perform a mail flow test for the Exchange 2003 servers, because that is a test that (if successful) very quickly confirms a lot of the elements involved in email availability are in fact healthy (ie the server is up, reachable, accepting SMTP connections, processing mail queues, the Information Store is running, and more).

For Exchange 2007/2010 the Test-Mailflow cmdlet can be used for these. You can build it into a health check script if you want to. But if you try to run it against an Exchange 2003 server you’ll get an error like this:

[PS] C:\>Test-Mailflow -Identity EX2007SERVER -TargetMailboxServer EX2003SERVER

Test-Mailflow : "EX2003SERVER" is running a previous version of Exchange and does not support this task.
At line:1 char:14
+ Test-Mailflow <<<<  -Identity EX2007SERVER -TargetMailboxServer EX2003SERVER
    + CategoryInfo          : InvalidArgument: (:) [Test-Mailflow], OperationOnOldServerException
    + FullyQualifiedErrorId : 642F2C5C,Microsoft.Exchange.Monitoring.TestMailFlow

However, if the Exchange 2003 server is in the same organization you can use a different parameter with Test-Mailflow to achieve the same result. All you need is an email address for one of the mailboxes on the Exchange 2003 server. You might want to create a mailbox on each of your Exchange 2003 servers (or even each of the databases on those servers) specifically for this purpose.

Then you simply run the Test-Mailflow cmdlet with the -TargetEmailAddress parameter instead of the -TargetMailboxServer parameter.

[PS] C:\>Test-Mailflow -Identity EX2007SERVER -TargetEmailAddress EX2003SERVER_test@domain.com

TestMailflowResult         MessageLatencyTime          IsRemoteTest
------------------         ------------------          ------------
Success                    00:00:19.5014893            True

As you can see this is a nice, simple way to test your Exchange 2003 server health using PowerShell.

Get more Exchange Server tips at ExchangeServerPro.com

Should You Defrag Exchange Server Mailbox Databases?

Paul Cunningham — Mon, 14 Nov 2011 11:52:24 +0000

In a recent article I demonstrated how to defrag an Exchange 2010 mailbox database. Since publishing that post a discussion has been ongoing in the comments about some of the pros and cons of defragging databases, as well as the implications for databases in an Exchange 2010 DAG (because my article specifically said not to follow the instructions for DAGs).

So, first things first…

Should Database Defragmentation be Regular Maintenance?

For the answer to that question I’m going to refer to the most authoritative source on Exchange Server – Scott Schnoll, Principal Technical Writer at Microsoft.

What was I doing when he tweeted that to me? I was defragging some mailbox databases

But was I doing that as part of regular maintenance? No I wasn’t, and neither should you In my case I was defragging some databases in a site where we have more than 200 mailbox databases. If I defragged 3-4 of those per week each database would still only get defragged once a year.

Of course I’d prefer that I never had to defrag them at all. For one thing it means working on a Friday night. Regular defrags would also probably suggest we’re not managing our capacity properly. But there are other reasons not to as well.

Reasons Not to Defrag Mailbox Databases

So why shouldn’t you defrag a mailbox database? Well let’s consider what is involved in a defrag.

First the database is dismounted. Then the offline defrag occurs, which in effect writes a brand new database file of the data within the database, excluding the white space. Then the database is remounted again and, ideally, a backup is taken immediately.

So you can already see three pretty good reasons not to defrag databases.

It requires an outage (at best this is an inconvenience for the business, at worst it may impact SLAs)
There is the risk of corruption as the new database file is written
It complicates your backup/recovery scenarios for periods before and after the defrag

Reasons to Defrag Mailbox Databases

But despite those reasons sometimes we have to be realistic about these things, and a defrag is necessary. Often in my case there are considerations such as:

No additional storage available to create a new database to migrate the mailboxes to (or only available at significant cost)
Migrations would take several days of minor outages for groups of users, instead of one single outage for all users on that database
There are active alerts for low free space on the storage for that database that need to be cleared

So in some cases a defrag is the best (or only) course of action.

What about Exchange Server 2010 DAGs?

So why did I say in my previous article not to follow that procedure for mailbox databases on servers in a DAG?

The main reason is that it breaks the resilience of the DAG for that mailbox database. When you defrag a mailbox database you also then need to reseed it to all of the other mailbox servers that host a copy of that database. So for that period of time between the database being defragged, and the reseed completing, your database is not protected by the continuous replication of the DAG.

The second reason is that moving mailboxes within an Exchange 2010 environment can be performed almost as a no-outage scenario for the end user. In previous versions of Exchange Server if you moved mailboxes instead of defragging databases the end users still experience an outage either way. However in Exchange Server 2010 the client experience is much better thanks to online mailbox moves.

One commenter actually contacted Microsoft Support to see if there was a way to run the defrags on passive mailbox database copies. To my surprise Microsoft actually did have a process for this, but as you can see it is quite complex and in my opinion is more effort and risk than it is really worth.

What do you think?

What do you think about defragging mailbox databases? Is it something you do regularly? Or do you avoid it in favour of other methods of achieving the same outcome?

Leave a comment below with your thoughts.

Update – two good discussions going on about this in the Exchange Server Pros and MSExchange.org groups on LinkedIn.

Get more Exchange Server tips at ExchangeServerPro.com

Using Test-ServiceHealth for Exchange Server Health Checks

Paul Cunningham — Tue, 18 Oct 2011 12:04:32 +0000

Exchange Server 2010 (and 2007 for that matter) ships with a useful PowerShell cmdlet called Test-ServiceHealth.

As the name suggests, Test-ServiceHealth checks the state of the services that should be running on the Exchange server. One of the best things about this cmdlet is that it checks the services depending on the Exchange server roles that are installed.

So for example, for a Hub Transport server only those services relating to the Hub Transport role will be checked. While for a “typical” Exchange 2010 server the services for the Hub Transport, Client Access, and Mailbox server roles will be checked.

Here is an example of the Test-ServiceHealth results.

[PS] C:\>Test-ServiceHealth br-ex2010-mb

Role                    : Mailbox Server Role
RequiredServicesRunning : True
ServicesRunning         : {IISAdmin, MSExchangeADTopology, MSExchangeIS, MSExchangeMailboxAssistants, MSExchangeMailSub
                          mission, MSExchangeRepl, MSExchangeRPC, MSExchangeSA, MSExchangeSearch, MSExchangeServiceHost
                          , MSExchangeThrottling, MSExchangeTransportLogSearch, W3Svc, WinRM}
ServicesNotRunning      : {}

Role                    : Client Access Server Role
RequiredServicesRunning : True
ServicesRunning         : {IISAdmin, MSExchangeAB, MSExchangeADTopology, MSExchangeFBA, MSExchangeFDS, MSExchangeMailbo
                          xReplication, MSExchangeProtectedServiceHost, MSExchangeRPC, MSExchangeServiceHost, W3Svc, Wi
                          nRM}
ServicesNotRunning      : {}

Role                    : Hub Transport Server Role
RequiredServicesRunning : True
ServicesRunning         : {IISAdmin, MSExchangeADTopology, MSExchangeEdgeSync, MSExchangeServiceHost, MSExchangeTranspo
                          rt, MSExchangeTransportLogSearch, W3Svc, WinRM}
ServicesNotRunning      : {}

As you can see that is a lot of useful information. But whenever possible I like to see just the minimum relevant information for my servers. In the case of Test-ServiceHealth the RequiredServicesRunning result is the thing I am most interested in.

So in this case I could run the following command to see just that information:

[PS] C:\>Test-ServiceHealth br-ex2010-mb | ft Role,RequiredServicesRunning -auto

Role                      RequiredServicesRunning
----                      -----------------------
Mailbox Server Role                          True
Client Access Server Role                    True
Hub Transport Server Role                    True

Much better.

Now suppose I wanted to run that for all of my Exchange servers. I could do that with the following command:

[PS] C:\>Get-ExchangeServer | Test-ServiceHealth | ft Role,RequiredServicesRunning -auto

Role                      RequiredServicesRunning
----                      -----------------------
Client Access Server Role                    True
Hub Transport Server Role                    True
Client Access Server Role                    True
Hub Transport Server Role                    True
Mailbox Server Role                         False
Mailbox Server Role                          True
Client Access Server Role                    True
Hub Transport Server Role                    True
Mailbox Server Role                          True
Client Access Server Role                    True
Hub Transport Server Role                    True

Interesting, especially the one that failed the test for the Mailbox server role. But in that output I can’t tell which server failed.

Let’s try this instead:

[PS] C:\>$servers = Get-ExchangeServer
[PS] C:\>foreach ($server in $servers) {
>> Write-Host "Checking" $server.name
>> Test-ServiceHealth $server | ft Role,RequiredServicesRunning -auto
>> }
>>

Now we get output that is a little more useful, and tells me which server failed the test.

Checking HO-EX2010-CAHT1

Role                      RequiredServicesRunning
----                      -----------------------
Client Access Server Role                    True
Hub Transport Server Role                    True

Checking HO-EX2010-CAHT2

Role                      RequiredServicesRunning
----                      -----------------------
Client Access Server Role                    True
Hub Transport Server Role                    True

Checking HO-EX2010-MB1

Role                RequiredServicesRunning
----                -----------------------
Mailbox Server Role                   False

Checking HO-EX2010-MB2

Role                RequiredServicesRunning
----                -----------------------
Mailbox Server Role                    True

Checking BR-EX2010-CAHT

Role                      RequiredServicesRunning
----                      -----------------------
Client Access Server Role                    True
Hub Transport Server Role                    True

Checking BR-EX2010-MB

Role                      RequiredServicesRunning
----                      -----------------------
Mailbox Server Role                          True
Client Access Server Role                    True
Hub Transport Server Role                    True

But it still isn’t quite enough, so let’s wrap this up into a handy script that will do the following:

Run Test-SystemHealth for all of the Exchange servers in the organization
Tell me which servers passed the test
Tell me which servers failed the test, and why

Here is the script code that will perform those steps.

#Get the list of Exchange servers in the organization
$servers = Get-ExchangeServer

#Loop through each server
ForEach ($server in $servers)
{
	Write-Host -ForegroundColor White "---------- Testing" $server

	#Initialize an array object for the Test-ServiceHealth results
	[array]$servicehealth = @()

	#Run Test-ServiceHealth
	$servicehealth = Test-ServiceHealth $server

	#Output the results
	ForEach($serverrole in $servicehealth)
	{
		If ($serverrole.RequiredServicesRunning -eq $true)
		{
			Write-Host $serverrole.Role -NoNewline; Write-Host -ForegroundColor Green "Pass"
		}
		Else
		{
			Write-Host $serverrole.Role -nonewline; Write-Host -ForegroundColor Red "Fail"
			[array]$notrunning = @()
			$notrunning = $serverrole.ServicesNotRunning
			ForEach ($svc in $notrunning)
			{
				$alertservices += $svc
			}
			Write-Host $serverrole.Role "Services not running:"
			ForEach ($al in $alertservices)
				{
					Write-Host -ForegroundColor Red `t$al
				}
		}
	}
}

The output from running the script will look something like this.

You can now see at a glance which servers have passed the test, which ones failed, and which services aren’t running for the servers that failed.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 FAQ: How to Minimise Downtime During Mailbox Migration from Exchange 2007

Paul Cunningham — Tue, 27 Sep 2011 11:00:15 +0000

Q: How can the mailbox migration from Exchange 2007 to Exchange 2010 be done with the minimum down time possible? Do users have to be offline during mailbox migration?

Exchange Server 2010 introduced the concept of online mailbox moves. An online mailbox move is a move operation during which the end user is able to connect to their mailbox for almost the entire move, except for the very end.

Online mailbox moves are only available when moving a mailbox from Exchange 2007 SP2 to Exchange 2010, or from Exchange 2010 to Exchange 2010.

The benefit of online mailbox moves is the minimal end user impact during the move. There are a lot of different scenarios in which the end user experiences an online move depending on the specific scenario and the method the user is connecting with at the time. You can read the full list of scenarios here.

For migrating from Exchange 2007 to Exchange 2010 online mailbox moves can be used to minimise the downtime for end users.

During an online mailbox move from Exchange 2007 SP2 to Exchange 2010 the end user is not locked out of the mailbox for the full duration of the move. Instead, the Exchange server performs the move and then only at the final stage does the end user get locked out for the move request to be completed.

This can dramatically shorten the amount of time that the user mailbox, particular larger mailboxes, is unavailable during the migration.

Mailbox move requests are initiated using the Exchange 2010 management tools. Launch the Exchange Management Console and navigate to Recipient Configuration/Mailbox.

You can hold the CTRL key to select multiple mailboxes to move if you want to.

In the Actions pane click on New Local Move Request.

Click the Browse button to choose a target mailbox database.

Select the mailbox database to move the pilot group to and then click OK. Click Next to continue.

On the Move Settings dialog you’ll notice the option to suspend moves when they are ready to complete. This option allows you to more precisely manage the timeframe in which the user is unable to access their mailbox, thanks to how the online mailbox moves work.

If you choose to suspend the move when it is ready for completion you can begin the mailbox move request at any time, and then have it sit in a suspended state until you are ready for it to be completed.

For this example I will check the box to suspend the moves to demonstrate this process. However if you wish to have the move requests continue to completion on their own do not check the box.

Review the list of mailboxes that will be moved and then click New to create the move requests.

Click Finish to close the wizard.

The move requests are created and will be processed by an Exchange 2010 Client Access server. While the mailbox is being moved the end user can continue to access it and send/receive email.

You can view the status of the move requests in the Exchange Management Console under Recipient Configuration/Move Request.

Right-click a move request and choose Properties to see the status of that move request.

When the move request is in this suspended state the user can still continue to access their mailbox on the original server. You can then notify them of the time you will be completing the move request, at which point they will be locked out of the mailbox and will need to restart Outlook afterwards.

When you are ready simply right-click on the move request and choose Complete Move Request. You can also hold the CTRL key to select multiple move requests and complete them all at once.

Again you can monitor the status of the move requests in the Exchange Management Console.

If the end users are still connected with Outlook they will see a message similar to this, and will need to restart Outlook to connect to their mailbox on the Exchange 2010 server.

When the user restarts Outlook they’ll be connected to their mailbox in the new location.

As you can see using online mailbox moves in conjunction with suspending mailbox move requests allows you to perform a mailbox migration from Exchange 2007 to Exchange 2010 with minimal user downtime.

Get more Exchange Server tips at ExchangeServerPro.com

The Exchange Server 2007 to 2010 Migration Guide is Available Now

Paul Cunningham — Mon, 26 Sep 2011 12:01:40 +0000

I’m pleased to announced the release of the Exchange Server 2007 to 2010 Migration Guide.

Exchange Server 2010 is a big evolutionary step from previous versions of Exchange. I’ve delivered successful Exchange 2010 migration projects involving thousands of mailboxes. And I’ve been called in to bring customers’ migration projects back from the brink of disaster too.

The Exchange Server 2007 to 2010 Migration Guide brings together my knowledge and experience in Exchange Server migrations so that you can avoid disaster and celebrate a successful project outcome.

In the Exchange Server 2007 to 2010 Migration Guide you get:

The migration guide itself, a 250+ page PDF with detailed, step by step instructions that take you through the entire process of migrating to Exchange Server 2010
A planning worksheet to record the important information you need from your existing environment for a successful migration project
A testing worksheet so you know that your new Exchange 2010 servers are working correctly before you put them into production
BONUS: Guide to Exchange Server 2010 Backup and Recovery, to help you protect your servers from data loss

Here’s what Exchange Server expert Steve Goodman wrote in his review of the Exchange Server 2007 to 2010 Migration Guide:

From a brief read, I can tell this is a book based on real world experience. It covers the kind of things I get asked time and time again and see people stuck with on forums. There are more comprehensive volumes out there on Exchange, covering a lot more topics in a lot more detail, but where I think this book stands out is it’s the guide a lot of small to medium business admins tackling an Exchange migration themselves need to get the job done without much (or even any) help.

Click here to find out more and get your copy of the Exchange Server 2007 to 2010 Migration Guide.

Get more Exchange Server tips at ExchangeServerPro.com

Microsoft Releases Update Rollup 5 for Exchange Server 2007 SP3

Paul Cunningham — Sun, 25 Sep 2011 09:58:33 +0000

Microsoft has announced the release of Update Rollup 5 for Exchange Server 2007 SP3.

Earlier today the Exchange CXP team released Update Rollup 5 for Exchange Server 2007 SP3 to the Download Center.

This update contains a number of customer-reported and internally found issues since the release of RU4. See ‘KB 2602324: Description of Update Rollup 5 for Exchange Server 2007 Service Pack 3‘ for more details.

We would like to specifically call out the following fixes which are included in this release:

DST: New updates for August DST – Exchange 2007

2536695 ”Some items cannot be deleted” error message when you try to delete or modify an email message in a public folder in an Exchange Server 2007 environment

2292150 A deleted hyperlink remains in the HTML source of an email message if you create the email message by using OWA in an Exchange Server 2007 environment (article not yet live)

General Notes:

For DST Changes: http://www.microsoft.com/time

Update Rollup 6 for Exchange Server 2007 Service Pack 3 is currently scheduled to release in April 2012. This will be in rhythm with next DST changes.

Download the update here.

Get more Exchange Server tips at ExchangeServerPro.com

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

Paul Cunningham — Sat, 24 Sep 2011 12:43:57 +0000

One of the types of Accepted Domains you can add to an Exchange Server 2007 or 2010 organization is an Internal Relay domain.

For Internal Relay domains the Exchange servers behave like this:

If I have a local recipient within the organization with the SMTP address that the email is addressed to then deliver it to that mailbox. Otherwise, send it outside the organization.

Internal Relay domains are commonly used in shared SMTP namespace scenarios, where two separate mail systems both use the same domain name for email. If you want to know more about this scenario read How to Share an Email Domain Between Two Mail Systems.

The steps for setting up an Internal Relay domain are usually:

Add the domain name to the Accepted Domains for the organization
Create a Send Connector to route the non-local recipients in that domain to another external mail system

However the fact is that it will work just fine if you only do step 1, and let your main Send Connector for the “*” namespace (ie, all external domains) handle the routing outwards from the organization (either via smart host or DNS).

That is, unless you are using Edge Transport servers.

If you are using Edge Transport servers, have configured an Internal Relay domain, and have not configured a specific Send Connector for that namespace, you may see non-delivery messages when internal senders try to send to external recipients of that namespace.

This happens because an infinite loop is created between the Hub Transport and Edge Transport servers.

The Hub Transport is correctly routing emails for non-local recipients in the Internal Relay domain name out of the organization via the Edge Transport servers.
However the Edge Transport servers recognize the Internal Relay domain as being local to the organization, and therefore route the email back into the Hub Transport server (as they would if they’d received an email sent from an external sender and addressed to a recipient of that domain name).

Under those conditions you may see non-delivery reports for emails sent to non-local recipients of the Internal Relay domain.

In the diagnostic information will be the reason, an infinite loop.

#554 5.4.6 Hop count exceeded – possible mail loop ##

You will also see the loop in action in the message headers provided with the NDR.

The solution for this problem is to configure a Send Connector for the organization that is specifically for that Internal Relay domain name, that is a lower cost than the default Send Connector.

On an Exchange 2010 server in your organization (not the Edge Transport server) open the Exchange Management Console and navigate to Organization Configuration/Hub Transport. Select the New Send Connector task in the Actions pane of the console.

Give the Send Connector a name and click Next to continue.

Add the SMTP address space for the Internal Relay domain. Choose a cost that is lower than the default Send Connector that EdgeSync creates, which is a cost of 100 by default. Click Next to continue.

You can choose to route via DNS or a smart host, whichever suits your specific scenario. DNS is probably going to be fine if the MX records for that domain already point to where you want the mail to be routed to. Otherwise a smart host may be required. Click Next to continue.

Set the source server depending on which server you want to send out the emails to that domain. For Internal Relay domains the source server for the Send Connector must be a Hub Transport server, not an Edge Transport server, in order to achieve the desired email routing for all scenarios. This means that the Hub Transport server you choose must be able to make SMTP connections through your firewall to wherever it needs to route the email for the Internal Relay domain.

Finally, click New to complete the wizard and create the new Send Connector.

With the Send Connector in place you should see the correct routing behaviour in each scenario. Outside senders who send to a non-local recipient in the Internal Relay domain will be correctly routed into the Exchange organization first, and then back out the Send Connector from the Hub Transport server. Meanwhile email sent to local recipients of the Internal Relay domain will be delivered locally.

Email sent from internal senders to non-local recipients of the Internal Relay domain will be correctly routed out the Send Connector as well, while email sent to local recipients of the Internal Relay domain will be delivered locally as expected.

This configuration achieves the desired message delivery without infinite loop conditions.

Bottom line is, if you are using Internal Relay domains and also Edge Transport servers you must configure a Send Connector for handling non-local recipients in that domain, or else you will create an infinite loop condition.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » Exchange 2007

Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports

Related posts:

Update Rollup 6 for Exchange 2007 SP3 Released

Related posts:

Error: Outlook Was Unable to Recover Some or All of the Items in this Folder

Related posts:

Using Test-Mailflow with Exchange 2003 Servers

Related posts:

Should You Defrag Exchange Server Mailbox Databases?

Should Database Defragmentation be Regular Maintenance?

Reasons Not to Defrag Mailbox Databases

Reasons to Defrag Mailbox Databases

What about Exchange Server 2010 DAGs?

What do you think?

Related posts:

Using Test-ServiceHealth for Exchange Server Health Checks

Related posts:

Exchange 2010 FAQ: How to Minimise Downtime During Mailbox Migration from Exchange 2007

Related posts:

The Exchange Server 2007 to 2010 Migration Guide is Available Now

Related posts:

Microsoft Releases Update Rollup 5 for Exchange Server 2007 SP3

Related posts:

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

Related posts: