Home

Hybrid Migration and Target Address Update

%3CLINGO-SUB%20id%3D%22lingo-sub-325508%22%20slang%3D%22en-US%22%3EHybrid%20Migration%20and%20Target%20Address%20Update%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-325508%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20currently%20faced%20with%20a%20scenario%20where%20the%20TargetAddress%20attribute%20is%20not%20being%20updated%20on%20the%20Active%20Directory%20for%20users%20that%20recently%20been%20migrated%20to%20exchange%20online%20In%20an%20O365%20hybrid%20exchange%20configuration.%20I%20manually%20had%20to%20change%20the%20TargetAddress%20attribute%20to%20the%20%3CDOMAINNAME%3E.mail.onmicrosoft.com%20for%20a%20small%20set%20of%20pilot%20users%20during%20the%20testing%20phase%20to%20enabled%20the%20exchange%20online%20users%20receive%20their%20email%20perfectly.%20Now%20I%20have%20to%20migrate%20a%20larger%20set%20of%20users%20%5B%20about%20200%20%5D%20and%20i%20don't%20want%20to%20manually%20have%20to%20update%20the%20TargetAddress%20attribute%20for%20each%20user%20as%20this%20is%20laborious%20and%20inefficient%2C%20so%20now%20I'm%20thinking%20back%20to%20my%20hybrid%20configuration%20and%20wondering%20if%20I%20missed%20anything%20and%20I%20cannot%20seem%20to%20wrap%20my%20mind%20around%20it.%26nbsp%3B%3C%2FDOMAINNAME%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI've%20have%20stumbled%20upon%20a%20link%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fexchange%2Fmailbox-migration%2Fassign-permissions-for-migration%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EAssign%20Exchange%20permissions%20to%20migrate%20mailboxes%20to%20Office%20365%3C%2FA%3E%26nbsp%3Bindicating%20that%20the%20administrator%20needs%20to%20have%20writeback%20permissions%20under%20the%20stage%20migration%20even%20although%20my%20scenario%20is%20a%20remote%20move%20migration%20which%20is%20even%20more%20confusing.%20I%20am%20stuck%20between%20writing%20a%20shell%20script%20to%20automate%20the%20migration%20%26amp%3B%20updating%20of%20the%20TargetAddress%20attribute%20and%20manually%20updating%20the%20TargetAddress%20attribute.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIf%20anyone%20knows%20what%20i'm%20not%20doing%20correctly%20kindly%20point%20me%20in%20the%20right%20direction%20as%20I%20am%20on%20a%20deadline%20please.%3C%2FP%3E%3CP%3EThank%20you%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-325508%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EExchange%20Online%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EHybrid%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-391404%22%20slang%3D%22en-US%22%3ERe%3A%20Hybrid%20Migration%20and%20Target%20Address%20Update%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-391404%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F271875%22%20target%3D%22_blank%22%3E%40burfadmin%3C%2FA%3E%20The%20targetAddress%20should%20be%20set%20by%20MRS%20when%20finalizing%20the%20move.%20What%20domain%20you%20specify%20with%20New-MigrationBatch%20-TargetDeliveryDomain%26nbsp%3B%20%26lt%3B...%26gt%3B%20%3F%26nbsp%3B%20That%20domain%20determines%20the%20address%20to%20pick%20from%20the%20proxyaddresses%20to%20stamp%20as%20targetAddress%20(and%20the%20tenant%20object%20should%20have%20this%20proxy%20address%2C%20your%20on-prem%20normally%20should%20not%20-%20did%20you%20perhaps%20add%20this%20to%20the%20default%20e-mail%20address%20policy%20on-prem%3F).%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-391372%22%20slang%3D%22en-US%22%3ERe%3A%20Hybrid%20Migration%20and%20Target%20Address%20Update%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-391372%22%20slang%3D%22en-US%22%3E%3CP%3EThank%20you%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F1978%22%20target%3D%22_blank%22%3E%40Michel%20de%20Rooij%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20realized%20that%20changing%20the%20target%20address%20to%20%3CDOMAINNAME%3E.onmicrosoft.com%20before%20completing%20the%20migration%20solved%20the%20problem.%20This%20change%20was%20updated%20on%20the%20target%20address%20value%20for%20all%20users%20during%20the%20migration%20thereby%20solving%20the%20problem%2C%20although%20I%20expected%20the%26nbsp%3B%3CDOMAINNAME%3E.mail.onmicrosoft.com%20to%20be%20enough%20for%20mail%20routing%20to%20office%20365%2C%20beats%20me%20why%20i%20still%20have%20to%20change%20to%26nbsp%3B%3CDOMAINNAME%3E.onmicrosoft.com%20before%20they%20can%20receive%20mails.%3C%2FDOMAINNAME%3E%3C%2FDOMAINNAME%3E%3C%2FDOMAINNAME%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-391189%22%20slang%3D%22en-US%22%3ERe%3A%20Hybrid%20Migration%20and%20Target%20Address%20Update%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-391189%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20Exchange%20Trusted%20Subsystem%20has%20permissions%20to%20update%20the%20targetAddress%20attribute%20after%20MRS%20has%20finished%20migration%3F%20(and%20according%20to%20move%20request%20reports%20-%20Get-MoveRequest%20-IncludeReport%20-%20finalization%20completes%20succesfully%3F)%20Also%2C%20do%20you%20specify%20that%20mail%20routing%20domain%20(%3CDOMAINNAME%3E.mail.onmicrosoft.com)%20when%20defining%20migration%20batches%20(or%20move%20requests)%2C%20as%20that%20will%20define%20which%20proxy%20address%20-%20with%20matching%20domain%20-%20gets%20picked%20to%20stamp%20on%20targetAddress.%3C%2FDOMAINNAME%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E
burfadmin
New Contributor

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

3 Replies

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.

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.

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

Related Conversations