The migration path for Skype for Business users to Teams is a well-trodden path. The procedure for doing so involves running the Move-CsUser command from a Skype for Business server and specifying that you want to move the user online. However, when I tried this from a Skype for Business 2015 pool the other day, I ran into some new errors… I hadn't seen these combination of errors before and it was unclear exactly what the problem was as the commands were correct. Here are some examples of the errors I was seeing:
Errors Included (when using OAuth method):
VERBOSE: CN=Roger
Hybrid,OU=Users-Sync,DC=myteamslab,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 [sipfed.online.lync.com].
VERBOSE:
Moving user [sip:Roger.Hybrid@myteamslab.com] across deployments.
VERBOSE:
Initializing source external move endpoint.
VERBOSE:
Creating target external move endpoint.
VERBOSE:
Validating the hosted migration override URL provided:
[https://adminau1.online.lync.com/HostedMigration/hostedmigrationService.svc].
VERBOSE:
Retrieving AuthorizationServiceUri and ClientId.
Move-CsUser : Hosted Migration Service (https://adminau1.online.lync.com/HostedMigration/HostedMigrationService.svc/OAuth_Bearer) did not return expected status code from request for WWW-Authenticate header.
At
line:1 char:1
+
Move-CsUser -Identity roger.hybrid@myteamslab.com -Target sipfed.onli ...
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (CN=Roger
Hybrid...teamslab,DC=com:OCSADUser) [Move-CsUser], MoveUserException
+ FullyQualifiedErrorId :
MoveError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsUserCmdlet
When moving using credential Auth method:
PS
C:\Users\Administrator.MYTEAMSLAB> Move-CsUser -Identity
roger.hybrid@myteamslab.com -Target sipfed.online.lync.com -MoveToTeams
-Credential $cred -HostedMig
rationOverrideUrl
'https://admin1a.online.lync.com/HostedMigration/hostedmigrationService.svc'
-Verbose -Confirm:$False
VERBOSE:
CN=Roger Hybrid,OU=Users-Sync,DC=myteamslab,DC=com
VERBOSE:
CN=Roger Hybrid,OU=Users-Sync,DC=myteamslab,DC=com
VERBOSE:
Validating parameters for move operation.
VERBOSE:
Calculating new server information for user [sipfed.online.lync.com].
VERBOSE:
Moving user [sip:Roger.Hybrid@myteamslab.com] across deployments.
VERBOSE:
Initializing source external move endpoint.
VERBOSE:
Creating target external move endpoint.
VERBOSE:
Validating the hosted migration override URL provided:
[https://admin1a.online.lync.com/HostedMigration/hostedmigrationService.svc].
VERBOSE:
Retrieving web ticket URL.
VERBOSE:
Retrieving live id token.
Move-CsUser
: The underlying connection was closed: An unexpected error occurred on a send.
At
line:1 char:1
+
Move-CsUser -Identity roger.hybrid@myteamslab.com -Target sipfed.onli ...
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (CN=Roger
Hybrid...teamslab,DC=com:OCSADUser) [Move-CsUser], WebException
+ FullyQualifiedErrorId :
MoveError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsUserCmdlet
From this we have a WWW-Authentication header error and an
underlying connection issue error depending on the type of credentials used. These errors went a long way to telling me
nothing about what was causing this issue. When all else fails, lets have a look at Wireshark and do some packet peeping. The packets don’t lie and they showed that I was receiving a RST back
from Office 365 right after my Client Hello was sent:
This
immediately made me think that there was some kind of client/server negotiation
failing in the TLS connection. So what changed recently with TLS in Office 365?
hhhmmm, how about TLS 1.0 and TLS 1.1 being disabled??
As it turns out that was indeed the issue. My server was relatively old and had not been updated to have TLS 1.0 and 1.1 disabled on it. The next question was what could I do to work around this issue?
A
classic move from PowerShell which I hoped would work in this case is using the
.Net ServicePointManager to control the TLS version used in a PowerShell session.
I tried this using the following command:
[Net.ServicePointManager]::SecurityProtocol =
[Net.SecurityProtocolType]::Tls12
Translation:
Use the Transport Layer Security (TLS) 1.2 security protocol for this
session.
After
this I ran a regular OAuth move and it worked!
$url="https://adminau1.online.lync.com/HostedMigration/hostedmigrationService.svc"
Move-CsUser -Identity
roger.hybrid@myteamslab.com -Target sipfed.online.lync.com -MoveToTeams
-HostedMigrationOverrideUrl $url -UseOAuth -BypassAudioConferencingCheck
–Verbose
PS
C:\Users\Administrator.MYTEAMSLAB> Move-CsUser -Identity
roger.hybrid@myteamslab.com -Target sipfed.online.lync.com -MoveToTeams
-HostedMigrationOverrideUrl
$url -UseOAuth
-BypassAudioConferencingCheck -Verbose
VERBOSE: CN=Roger
Hybrid,OU=Users-Sync,DC=myteamslab,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 [sipfed.online.lync.com].
VERBOSE:
Moving user [sip:Roger.Hybrid@myteamslab.com] across deployments.
VERBOSE:
Initializing source external move endpoint.
VERBOSE:
Creating target external move endpoint.
VERBOSE:
Validating the hosted migration override URL provided:
[https://adminau1.online.lync.com/HostedMigration/hostedmigrationService.svc].
VERBOSE:
Retrieving AuthorizationServiceUri and ClientId.
VERBOSE:
Retrieving OAuth token.
VERBOSE:
Initializing source external move endpoint.
VERBOSE:
Validating user [sip:Roger.Hybrid@myteamslab.com] online, for on premises to
online move.
VERBOSE:
Validating user [sip:Roger.Hybrid@myteamslab.com] locally on premises, for on
premises to online move.
VERBOSE:
Validating read-write permissions on local Active Directory.
VERBOSE:
Invoking begin move for user [sip:Roger.Hybrid@myteamslab.com].
VERBOSE:
Setting resource data for user [sip:Roger.Hybrid@myteamslab.com].
VERBOSE:
Completing move for user [sip:Roger.Hybrid@myteamslab.com].
VERBOSE:
Re-homing user [sip:Roger.Hybrid@myteamslab.com] on the source.
VERBOSE:
Re-homing user [sip:Roger.Hybrid@myteamslab.com] on the target.
There you go. Problem solved!
The Wrap Up
Things are constantly changing in Office 365. Stay on your toes because there can always be something new lurking that can make your migrations fail. Hopefully this helps some of you avoid disaster in your migration! Till next time, keep on migrating.
