Forum Discussion
burfadmin
Jan 25, 2019Copper Contributor
Hybrid Migration and Target Address Update
I am currently faced with a scenario where the TargetAddress attribute is not being updated on the Active Directory for users that recently been migrated to exchange online In an O365 hybrid exchange...
mderooij
Mar 29, 2019MVP
The Exchange Trusted Subsystem has permissions to update the targetAddress attribute after MRS has finished migration? (and according to move request reports - Get-MoveRequest -IncludeReport - finalization completes succesfully?) Also, do you specify that mail routing domain (<domainname>.mail.onmicrosoft.com) when defining migration batches (or move requests), as that will define which proxy address - with matching domain - gets picked to stamp on targetAddress.
burfadmin
Mar 31, 2019Copper Contributor
Thank you mderooij
I realized that changing the target address to <domainname>.onmicrosoft.com before completing the migration solved the problem. This change was updated on the target address value for all users during the migration thereby solving the problem, although I expected the <domainname>.mail.onmicrosoft.com to be enough for mail routing to office 365, beats me why i still have to change to <domainname>.onmicrosoft.com before they can receive mails.
- mderooijMar 31, 2019MVP
burfadmin The targetAddress should be set by MRS when finalizing the move. What domain you specify with New-MigrationBatch -TargetDeliveryDomain <...> ? That domain determines the address to pick from the proxyaddresses to stamp as targetAddress (and the tenant object should have this proxy address, your on-prem normally should not - did you perhaps add this to the default e-mail address policy on-prem?).
- WordieFeb 13, 2022Copper Contributor
mderooij Thank you for mentioning the -TargetDeliveryDomain switch on the New-MoveRequest command. I had the same problem as OP and this was where I was going wrong.
When running New-MoveRequest I was setting this to our primary SMTP domain and not the @domain.mail.onmicrosoft.com domain. As a result the migrated mailbox was having their RemoteRoutingAddress updated to the primary SMTP domain (this also causes a routing loop until the email header reaches the max size limit for emails.... fun).
Fix was to make sure the -TargetDeliveryDomain switch on the New-MoveRequest command is set to @domain.mail.onmicrosoft.com and not the primary email domain. If you have already migrated a mailbox a manual fix is to update the targetAddress attribute on the user's on-prem AD profile and then run a delta sync with Azure AD connect (run Start-ADSyncSyncCycle -PolicyType Delta on the AD connect server).