Hybrid Migration and Target Address Update

[burfadmin]

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 configuration. I manually had to change the TargetAddress attribute to the <domainname>.mail.onmicrosoft.com for a small set of pilot users during the testing phase to enabled the exchange online users receive their email perfectly. Now I have to migrate a larger set of users [ about 200 ] and i don't want to manually have to update the TargetAddress attribute for each user as this is laborious and inefficient, so now I'm thinking back to my hybrid configuration and wondering if I missed anything and I cannot seem to wrap my mind around it. 

I've have stumbled upon a link

Assign Exchange permissions to migrate mailboxes to Office 365 indicating that the administrator needs to have writeback permissions under the stage migration even although my scenario is a remote move migration which is even more confusing. I am stuck between writing a shell script to automate the migration & updating of the TargetAddress attribute and manually updating the TargetAddress attribute. 

If anyone knows what i'm not doing correctly kindly point me in the right direction as I am on a deadline please.

Thank you

[#2]

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.

[#3]

Thank you @Michel de Rooij 

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.

[#4]

@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?).

[#5]

@Michel de Rooij 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).