I have done a couple of those in the past for different clients – from just a few users to a couple of hundreds of users. My team already has the best practice workbook and we don’t have issues in the process. This weekend I managed to have two different problems with one customer o.O

First issue – SMTP Proxy Address:

User A dropped migration with the error that synced account does not have needed SMTP address. I was pretty sure that I entered it and confirmed that on double check (on-prem AD – both GUI and Powershell (first mistake)).

But when I list that user in O365 it really was missing needed SMTP attribute:

Get-MsolUser -UserPrincipalName UserA@tech-trainer.info | Select-Object ProxyAddresses

I then removed that SMTP from on-prem AD account and initiated AD Sync:

Start-ADSyncSyncCycle -PolicyType Initial

I again copy/pasted (pay attention to this one – second mistake) SMTP from Notepad and again rerun AD sync.

The user again did not have needed record, although AD Sync reported successful update. This is where I started to bang my head against the wall 🙂

After some time I found a Saviour – ldFix Directory Synchronization Error Remediation Tool

It will scan your AD and will inform you if there are some errors.

First set the Base for scanning (this is the synced OU):

Then you can run a query. It will inform you if there are some errors and will propose a change.

When this was done I was able to successfully resync User A and finish the migration.

Mistakes explanation:

  1. Powershell on-prem returned me a list of SMTP addresses that looked fine (with basic font size), but when I took a closer look I found an error – see that strange sign after @:
  2. The error above was produced by copy/paste from different sources (can’t say for sure what was before Notepad as a source of that SMTP string). I just had to type it and all would be just fine 🙂

Remember I said there were 2 issues? Here it goes.

Second issue – “The Subscription for the migration user UserB@tech-trainer.info couldn’t be loaded. The following error was encountered: A subscription wasn’t found for this user.”

Note: In order to run some of the bellow commands you should connect to O365 services.

There are 2 possible scenarios for resolving this:

  1. Run the below command on on-premise Exchange to check the mailboxes GUIDS
    Get-RemoteMailbox UserB | Format-List ExchangeGUID

    You should receive an answer similar to this:

    Run the below command on Exchange Online:

    Get-Mailbox UserB | Format-list ExchangeGuid

    You should receive an answer similar to this:

    If the GUIDS are not matching, you found your problem.
    Resolution is to run the command below and rerun “Complete-Migrationbatch” cmdlet:

    Set-RemoteMailbox UserB -ExchangeGUID 4a502e5e-5064-4f60-b691-845bdaf94113  #Online MailboxGUID
  2. If the “Get-RemoteMailbox” does not return a thing for our user it means that it wasn’t migrated successfully.
    In that case, you have to remove the online mailbox for UserB:

    #In Exchange Online Powershell verify the recipient type. If user mailbox, then you need to remove the mailbox.
    Get-recipient [alias]
    #Go On premise to see what the recipient type is as well. Run the same cmdlet as above.
    #If verified that we have 2 different mailboxes, then we need to purge the cloud mailbox since it is new and has no data. Please be sure that the user is not using OneDrive or Sharepoint.
    #If so this data will need to be backed up prior to deleting the msol account. After deleting the MSOL account the OneDrive and Sharepoint data will be gone.
    #Next Get the External Directory Object ID from the O365 mailbox.
    Get-Mailbox UserB |fl *external*
    #Verify the msoluser account.
    Get-msoluser -objectid [insert external objectID from above]
    #Remove the msol account
    Remove-msoluser -ObjectID [insert objectID from above]
    #Purge the msol user account
    Remove-Msoluser -objectID [insert objectID from above] -removefromrecyclebin #This step is very important to do. If you don't remove it from recycle bin new DirSync will pull the same one.
    #Verify the object is gone.
    Get-msoluser -objectid [inset external objectID from above]
    #Initiate a Dirsync Cycle
    #Go back to the O365 portal, verify a new object has been created.
    #Or you can run 
    Get-msoluser -userprincipalname UserB@tech-trainer.info | fl
    #You will see a new object ID.
    #Next go back in the Exchange Admin Center and migrate the user account.

This time, the second one was mine.

Have another great day in Admins life 🙂

Please follow and like us:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.