In Exchange Server 2010 as with Exchange Server 2007, all e-mail must go through a Hub Transport server before delivery to the mailbox. This is mainly to allow for compliance, but it also provides a means for data recovery.

Transport dumpster is a feature built into Exchange Server 2010 HUB transport role  and designed to minimize data loss during mail delivery to a DAG in a lossy failover scenario. This feature was first introduced in Exchange 2007 for CCR and LCR mailboxes.

The transport dumpster is used for replicated mailbox databases only. It doesn't protect messages sent to public folders, nor does it protect messages sent to recipients on mailbox databases that aren't replicated (not member of a DAG). The transport dumpster queue for a specific mailbox database is located on all Hub Transport servers in the Active Directory sites containing the DAG. The transport dumpster is stored inside the mail.que file. 

Exchange Server Transport Dumpster Settings

There are two settings that control the life span of a message within the transport dumpster. They are:

•MaxDumpsterSizePerDatabase   Defines the size available for each storage group on the Hub Transport server. The recommendation is that this be set to 1.5 times the maximum message size limit within your environment. The default value for this setting is 18 MB.

•MaxDumpsterTime   Defines the length of time that a message remains within the transport dumpster if the dumpster size limit is not reached. The default is seven days.

If either the time or size limit is reached, messages are removed from the transport dumpster by order of first in, first out. we can run the following command to see the current settings:

Get-TransportConfig |fl *Dumpster*

Changes in Exchange 2010

In Exchange 2007, messages were retained in the transport dumpster until the administrator-defined time limit or size limit is reached. In Exchange 2010, the transport dumpster now receives feedback from the replication pipeline to determine which messages have been delivered and replicated. As a message goes through Hub Transport servers on its way to a replicated mailbox database in a DAG, a copy is kept in the transport queue (mail.que) until the replication pipeline has notified the Hub Transport server that the transaction logs representing the message have been successfully replicated to and inspected by all copies of the mailbox database. After the logs have been replicated to and inspected by all database copies, they are truncated from the transport dumpster. This keeps the transport dumpster queue smaller by maintaining only copies of messages whose transactions logs haven't yet been replicated.

The transport dumpster has also been enhanced to account for the changes to the Mailbox server role that enable a single mailbox database to move between Active Directory sites. DAGs can be extended to multiple Active Directory sites, and as a result, a single mailbox database in one Active Directory site can fail over to another Active Directory site. When this occurs, any transport dumpster redelivery requests will be sent to both Active Directory sites: the original site and the new site.

I have been asked recently for the required steps to configure Autodiscover when having Multiple SMTP namespaces, I have started writing few lines then upon checking my favorites I found a great bunch of blogs which explains the two possible solutions in great details, so here we go:

http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/exchange-autodiscover.html

http://blogs.technet.com/b/jmayans/archive/2006/09/07/454716.aspx

http://blogs.msdn.com/b/brad_hughes/archive/2007/12/18/autodiscover-http-redirect-method-using-isa-instead-of-a-second-web-site.aspx

http://www.more2know.nl/2010/05/18/exchange-autodiscover-and-multiple-domains/

background:

http://technet.microsoft.com/en-us/library/bb332063(EXCHG.80).aspx

http://support.microsoft.com/default.aspx?scid=kb;EN-US;940881

I had complaints from some of my customers that moving users to Exchange 2010 SP1 system is slow and taking long time. In RTM Exchange was doing 5 parallel moves at a time due to the following settings:

RTM values:

MaxActiveMovesPerSourceMDB: This property indicates the number of mailboxes that can be moved on the source mailbox database at one time. The default value is 5 concurrent moves.

MaxActiveMovesPerTargetMDB: This property indicates the number of mailbox moves that can be moved on the target mailbox database at one time. The default value is 5 concurrent moves.

SP1 values:

MaxActiveMovesPerSourceMDB: This property indicates the number of mailboxes that can be moved on the source mailbox database at one time. The default value is 5 concurrent moves.

MaxActiveMovesPerTargetMDB: This property indicates the number of mailbox moves that can be moved on the target mailbox database at one time. The default value is 2 concurrent moves.

The change in MaxActiveMovesPerTargetMDB in SP1 means that we can only do 2 concurrent connections.

The workaround: check the values in the following file “Exchange Server\V14\Bin\MSExchangeMailboxReplication.exe.config” and you can change MaxActiveMovesPerTargetMDB back to 5 to allow 5 concurrent moves.

Don’t forget to restart the Microsoft Exchange Mailbox Replication service and do this configuration change on all your CAS servers

Version: 6553.0002
Date Released:11/4/2013
Notable Changes:
 

• Fix to handle Read-Only Domain Controllers in Password Sync.
• DirSync can be installed on a Domain Controller (Development purposes).  Documentation on how to deploy can be found here
      

You can check your DirSync version by running the following PowerShell command: 

(GP 'hklm:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft Online Directory Sync').DisplayVersion

The latest version can be downloaded here: Windows Azure Active Directory Sync tool – 64 bit

In Exchange 2010 none of the preloaded role groups have the Mailbox Import Export role, The person performing the import or export must have the appropriate permissions within Exchange. The easiest way to grant this permission is by adding  Mailbox Import Export role to a role group.

To create the role group we need to run the following:

New-RoleGroup "Mailbox Import-Export Management" -Roles "Mailbox Import Export"

This will create a group called “"Mailbox Import-Export Management"”, every user added to this group will have the right to run the import/export cmdlets, adding a user can be done by running the following:

Add-RoleGroupMember "Mailbox Import-Export Management" -Member <user account>

If you try to run the cmdlets and you don't have the correct permissions, you'll receive an error stating that the cmdlet doesn't exist. And by the way , you'll need to restart the Exchange Management Shell after you add the Mailbox Import Export role to the role group.