Cross-Forest Mailbox Move

Posted on February 4, 2010 by Michel de Rooij

Note: This is part 1; part 2 can be found here.

Currently I’m working with Johan Veldhuis on a project where we’ll be moving mailboxes from Exchange 2003 to Exchange 2010. Accounts and mailboxes will be migrated from forest to forest and to make things more interesting, the account migration is isolated from the mailbox migration. In other words, we start with a single forest after which we’ll create a account/resource forest setup from where we’ll consolidate things again. The account/resource forest setup is not completely by the book as the accounts in the resource forest won’t be disabled. This is because ActiveSync devices will be migrated at a later stage; this means they can use their existing authentication information.

Note: In the remainder of this article the following variables are used:

olddomain.nl is the source forest with Exchange 2003;
newdomain.com is the new forest with Exchange 2010;
Jan Test is our to be migrated test user with User ID jtest;
source.nl is an e-mail domain for which Exchange 2003 is authoritative;
target.com is an e-mail domain for which Exchange 2010 is authoritative.

The starting point of this blog is the situation where both forests olddomain.nl and newdomain.com are up and running. There is a trust between olddomain.nl and newdomain.com, ADMT and the Password Export Server are configured and running properly. This means we can successfully migrate user accounts from olddomain.nl to the new forest newdomain.com; the user’s mailbox will remain on Exchange 2003 in olddomain.nl.

Here is where the first problem was encountered. The Active Directory schemas mismatch, so ADMT will only migrate a basic set of attributes. This means that although newdomain.com has Exchange attributes, these won’t be migrated. Also, to be able to use the mailbox properly from their newdomain.com account, we need to add mailbox permissions for the newdomain.com account. For this purpose we created a post-migration script which adds Full Mailbox Access and External Account permissions to the mailbox for the newdomain.com account. After that we have reached an intermediary state, with accounts in newdomain.com and resources (mailboxes) in olddomain.nl; Users will log on using an account from the newdomain.com account forest and access their mailbox in the olddomain.nl resource forest.

The next phase will be migrating Exchange 2003 mailboxes from olddomain.nl to Exchange 2010 mailboxes in newdomain.com. Microsoft provides a nice TechNet article (633491) on how to prepare mailboxes for cross-forest mailbox move requests. The article also links to a (sample) PowerShell script, part of ILM 2007 SP1, located here. The script, Prepare-MoveRequest.ps1, should prepare the target forest for mailbox move request. Unfortunately, we couldn’t get it working properly.

First, the script complained it couldn’t find the specified Identity in the target forest. This was odd; the account is present, it was created by ADMT. Diving into the code it looks for the identity in various attributes:

filterParm = “(& (objectClass=user)” +
”   ( (| (mailnickname=$escapedIdentity)” +
”        (cn=$escapedIdentity)” +
”        (proxyAddresses=SMTP:$escapedIdentity)” +
”        (proxyAddresses=smtp:$escapedIdentity)” +
”        (proxyAddresses=X500:$escapedIdentity)” +
”        (proxyAddresses=x500:$escapedIdentity)” +
”        (objectGUID=$escapedIdentity)” +
”        (displayname=$escapedIdentity))))”

$srcObject = findADObject $srcdc $filterParm

No matter what we tried, no match. Odd. Also, the script contains code which creates objects when it determines it needs to and there’s no switch to turn this behaviour off. That switch would be nice, because the last thing we want is to end up with hundreds of mail-enabled user objects when there are already user account objects present. Since we had little time to debug and fix the script, we decided to prepare the target account in newdomain.com ourselves. I took a script from one of my earlier projects (VB), which I created for similar merger / split scenarios in the past, and checked it against the information in the TechNet article mentioned earlier. In the end we had a script which transforms users into mail-enabled users as follows:

Copy the following atributes from the account in olddomain.nl to the account in newdomain.com: mail, mailNickname, msExchMailboxGuid, proxyAddresses;
Adds the LegacyExchangeDN attribute from olddomain.nl account as an X500 address to the account in newdomain.com;
Sets msExchRecipientDisplayType to -2147483642;
Sets msExchRecipientTypeDetails to 128;
Sets targetAddress in newdomain.com to the value of mail attribute in the olddomain.nl;
Adds a constructed e-mail address (e-mail account olddomain.nl + @ + new e-mail domain, e.g. j.test@target.com) to the proxyAddresses in newdomain.com;
Sets legacyExchangeDN on the new account in newdomain.com to “/o=<ORG>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=<CN>”, where <CN> is the cn of the account.

This is more or less the same as the Prepare-MoveRequest.ps1 should do, but this one worked like expected. Note that the last three actions are important for getting the move request to work. The targetAddress should be set properly, because new-moveRequest will set the target Address of the olddomain.nl account to the primary SMTP address of the newdomain.com account. LegacyExchangeDN and the proxyAddress should be added because new-moveRequest uses these for lookup and matching (I assume, because we will also will specify the identity itself). The proxyAddress e-mail address for which Exchange 2010 in newdomain.com is authoritative will be promoted to primary SMTP e-mail address.

Now, after preparing the newdomain.com account and transforming it into a mail-enabled user, we can use new-moveRequest to transfer the mailbox from Exchange 2003 to Exchange 2010:

$cred = get-credential
new-moverequest -identity <userid> -RemoteLegacy -TargetDatabase “<Mailbox Database Name>” -RemoteGlobalCatalog dc.olddomain.nl -RemoteCredential $cred -TargetDeliveryDomain <target.com>

An explanation:

We need to specify RemoteLegacy because the source forest isn’t Exchange 2010;
TargetDatabase identifies the target database;
Using RemoteGlobalCatalog we specify a GC from the remote forest;
With RemoteCredential, in combination with get-credential, is used to prompt for credentials and use them in the cmdlet;
TargetDeliveryDomain specifies the external e-mail domain that is used to set the targetAddress in the source forest, so normally this should be an e-mail domain for which the source forest isn’t and the target forest is authoritative.

Presto! This is what the objects look like after performing the new-moverequest:

olddomain.nl
cn=Jan Test
mail=jtest@target.com
legacyExchangeDN=/o=<ORG>/ou=First Administrative Group/cn=Recipients/cn=jtest88083336
mailNickname=jtest
proxyAddresses=X500:/o=<ORG>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Jan Test; smtp:J.Test@source.nl; SMTP:jtest@target.com; X400:c=NL;a= ;p=<org>;o=Exchange;s=Test;g=Jan;;
targetAddress=SMTP:jtest@target.com

newdomain.com
cn=Jan Test
mail=jtest@target.com
legacyExchangeDN=/o=<ORG>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Jan Test;
mailNickname=jtest
proxyAddresses=smtp:jtest@newdomain.com ;SMTP:jtest@target.com;X400:C=NL;A= ;P=<org>;O=Exchange;S=Test;G=Jan ;smtp:J.Test@source.nl ;smtp:J.Test@target,com ;X500:/o=<ORG>/ou=First Administrative Group/cn=Recipients/cn=jtest88083336
targetAddress=SMTP:jtest@target.com

Notice that new-moveRequest adds a random number “88083336” to legacyExchangeDN in olddomain.nl and to X500 in newdomain.com. This is to promote the newdomain.com account for legacyExchangeDN usage and enables mailflow from the old olddomain.nl to newdomain.com when replying on old e-mail.

Update: Also worth noting is we an additional challenge because the source domain name equaled their e-mail namespace, which they want to keep using during and after the migration. Therefor we had to introduce a bogus local namespace for which the Exchange 2003 becomes authoritative and 2010 is not. We can use recipient policies to stamp this address to mail-enabled objects and by creating a connector from Exchange 2010 to Exchange 2003 using this namespace, we can route e-mail from migrated users to non-migrated users.

I hope this information is useful. For more information on new-moveRequest for cross-forest moves, check here. When you have questions, post them in the comments below or send me an e-mail.

Exchange 2010 Mailbox Role Calculator 3.5

Posted on January 31, 2010 by Michel de Rooij

The Microsoft Exchange Team released an update of the Exchange 2010 Mailbox Server Role Requirements Calculator. The new version is 3.5 and it includes the following features/improvements since 3.2:

Version 3.5
Improved the text on the input tab with regards to the number of database copy instances you would like for both HA and lagged copies. Also fixes an issue where in a high availability architecture the calculator may size the solution based on activating more database copies during a second server failure event than the total number of database copies deployed on the server.

Version 3.4
Corrects a memory and CPU utilization issue where you deploy a site resilient architecture with multiple mailbox servers and a single database copy in the primary datacenter. Specifically, the calculator would determine the active database copy configuration after a single server failure and then size the CPU and memory requirements. However, since there is only a single database copy in the primary datacenter, the solution cannot survive with all copies hosted in the primary datacenter. Therefore, the copies need to be activated in the secondary datacenter. Version 3.4 corrects this scenario by ensuring there are at least 2 database copies in the primary datacenter in order to calculate the active database count after a single server failure.

You can download the calculator here.

Exchange 2010 & Outlook 2003 Notifications

Posted on January 27, 2010 by Michel de Rooij

Update (13 apr 2011): Rollup 3 for Exchange 2010 SP1 contains UDP support. To enable it, apply RU3 and set HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem\EnablePushNotifications to 1 (REG_DWORD). More information in support article kb2009942.

New e-mail notifications from Exchange to Outlook, we receive them all the time. Most of us never look at the technique, because in most cases this works so there’s no need. But what if it doesn’t or you are experiencing delays? With Exchange 2010 this situation is more likely to occur than with earlier versions of Exchange, because many people are still using Outlook 2003 or earlier clients. To understand why this happens, you need to understand how these notifications work (or should I say worked).

Note: To improve readability, you should read “Outlook 2003 or earlier versions in online mode” when it reads “Outlook 2003” from here on, unless states otherwise.

When Outlook 2003 connects to Exchange, it tries to register itself to receive notifications. If registration is successful, Outlook 2003 tells Exchange on what port it expects (UDP) packages to arrive, and it by default this is in the port range 1024-65535. When sending notifications, the Exchange server will also open a dynamic port in this range and connect to the registered client port. After receiving the notification, Outlook 2003 will retrieve the message, will display it in the appropriate folder, make a sound, show a systray icon, change your cursor, etc. When the registration for new mail notifications fails, Outlook 2003 will use a polling mechanism the check for changes.

Now, with Exchange 2010 this behavior has changed because Exchange 2010 does not send these kind of notifications to Outlook 2003 (i.e. UDP notifications were removed). Therefor, Outlook 2003 will revert to polling, which by default is set to 1 minute. This means in worst case users will be notified of new e-mail after approximately 1 minute, where (sort of) real-time feedback is expected. To make things worse in terms of user experience, this also means delays in visible feedback on any folder updates, e.g. e-mail seems to stay in outbox, deleted items not being deleted, moved items not being moved, etc.

The related knowledge base article (kb2009942) mentions two solutions. One solution is a mere pretext and explains increasing the polling frequency. To do so, it requires applying Exchange 2010 Rollup 1 on the CAS server and configuring the following registry key on that CAS server:

HKLM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem\Maximum Polling Freqeuency (DWORD, range 5000-120000)

The reason for performing this step on the CAS server is that Exchange 2010 will determine the polling frequency, not the client. The setting will work immediately, but clients need to reconnect in order for the new value to become effective. Note that setting this value lower than 5000 has no effect because Outlook 2003’s minimum poll rate is 5000.

Another solution is to enable cached mode for Outlook 2003 clients. This will not solve the delay in receiving new e-mail notifications, but it will solve the most annoying issue, being the delay in visual feedback. In cached mode users won’t notice the delay because they’re working with a local copy of their mailbox. Any changes (sends, deletes, moves) will happen in the local cached file (OST), and Outlook will update their Exchange mailbox in the background.

The article fails to mention the third solution: upgrade! The reason Outlook 2007 doesn’t have this issue is that Outlook 2007 (and later) support a third method: asynchronous (push notification). And as you’ve probably guessed, Exchange 2010 (and Exchange 2007) supports this method as well.

Dell Exchange 2010 Advisor Tools

Posted on January 27, 2010 by Michel de Rooij

Dell has released an updated set of advisor tools for Exchange 2010. The tools can be used for rough sizing of servers and storage and utilizes Dell’s Equalogic, PowerVault, EMC and PowerEdge components. Unfortunately, and contrary to the HP Sizing Tools for Exchange 2010, the Dell Advisor can only be used online, so solutions can’t be saved or re-used. To be honest, the tool is more like a linear Wizard. It only supports single-site solutions, but it supports Database Availability Groups (DAG), DAS or or SAN-based storage, high availability and client options, but in a very limited fashion (i.e. Yes/No type of questions).

You can start the Dell Exchange 2010 Advisor by clicking here.

Note that for those involved with OCS, Dell also released the Unified Communications Advisor Tool for OCS 2007 R2.

Exchange 2010 Webcasts

Posted on January 26, 2010 by Michel de Rooij

For those interested, Microsoft is having three Webcasts on Exchange 2010 this late February / March:

The Performance/Scalability & Availability sessions are level 300; the Outlook Web App and Transport sessions are level 200. This means sufficient depth for those starting with Exchange 2010 as well as those with an Exchange background who want to get an update. Note that the Performance and Scalability session will be presented by Netapp’s John Fullbright, so I assume it will contain information on Netapp’s proposition as well.