Reverse O365 SfBO Migration Failure

The Scenario

Existing Office 365 tenant successfully using SfBO. Exchange on-premises.  Azure AD Connect version unknown, but up and functional  PBX with voice mail on-premises. We extended schema and installed SfB on-premises with Edge.  Modified the firewall to specification and attempted to get into hybrid. 

DNS mods we easy. Creating a test user and synching up to O365 went fine.  Enabling the test user for SfB went fine.  Another AAD sync and we were in business.  Moving the test user to O365 (so we could test moving back to on-premises) went just fine. And there the problems began.  Attempts to move the user back to on-premises failed with the following non-help message:

PS C:\Source\scripts> move-csuser -Identity sfb.test3@domain.com -Target domain-sfbfe01.domain.com -Credential $cred –HostedMigrationOverrideUrl https://admin0a.online.lync.com/HostedMigration/hostedmigrationservice.svc -Verbose
VERBOSE: CN=sfb test3,OU=hometown_Users,OU=domain_Users,DC=domain,DC=com

Confirm
Move-CsUser
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): Y
VERBOSE: Validating parameters for move operation.
VERBOSE: Calculating new server information for user [domain-sfbfe01.domain.com].
VERBOSE: Moving user [sip:sfbtest3@domain.com] across deployments.
VERBOSE: Creating source external move endpoint.
VERBOSE: Validating the hosted migration override URL provided:
[https://admin0a.online.lync.com/HostedMigration/hostedmigrationservice.svc].
VERBOSE: Retrieving web ticket URL.
VERBOSE: Retrieving live id token.
VERBOSE: Initializing source external move endpoint.
VERBOSE: Creating target external move endpoint.
VERBOSE: Initializing source external move endpoint.
VERBOSE: Validating user [sip:sfbtest3@domain.com] online, for on premises to online move.
move-csuser : Index was outside the bounds of the array.
At line:1 char:1
+ move-csuser -Identity sfb.test3@domain.com -Target domain-sfbfe01.domain.com -Credenti ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (CN=sfb test3,OU...,DC=domain,DC=com:OCSADUser) [Move-CsUser], IndexOutO
   fRangeException
    + FullyQualifiedErrorId : MoveError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsUserCmdlet

"Index was outside the bounds of the array."

You know how many hits googlepedia produces for that?  None of them helpful.  So we triple-checked our work.  Reviewing the overall picture, it was apparent that there was some issue with the on-premises environment, but everything we looked at came up good.

The Root Cause

The root cause was that Azure AD Connect was installed and configured BEFORE the extending schema for SfB.  As it turns out in the end, Azure AD Connect does not refresh schema very well, if at all, unless you tell it to. 

And even then, maybe not. There is a button inside the missclient (Synchronization Service Manager) that SAYS it will do it.  I mean, it clearly says “refresh schema”

…and the following message sure says it will…

But, guess what, that is not the case.

As you can probably guess, the root issue causing our migration failure was that the AAD Connect had no knowledge of the SfB attributes coming in with the online user.  Now, I would have thought they would have seeing as how we were successful in installing SfB, creating a good on-premises user, and moving that user up into the tenant.  But no.

Interesting side note is that once we twigged onto the schema concept, using the button on AAD connector populated SOME valiues – we could see them.  But still moving back to on-premises failed.

The Fix

It seems that if you run "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe", you get a few options. Specifically, take a look at the third option from the top.

I do not pretend to know the difference between “refresh schema” in one location as opposed to the other, but I do know that running the “refresh directory schema” from this location, followed by a full synch on both connectors resolved our failed user moves.

Keeping your Azure AD Connect up to date might be helpful also and in theory the reinstallation process will trigger a schema refresh.  You can get a clean copy of that installer right here.

Of course, once you know what to look for, there is this also.

YMMV