Last week I run into the following error message when trying to move an on-premise Skype for Business user to Teams.

Move-CsUser : HostedMigration fault: Error=(201), Description=(Cannot find user in Active Directory with the following SIP URI: “sip:John.Nokes@braintesting.net”)



Normally this error occurs, if the msRTCSIP-PrimaryUserAddress Active Directory attribute was not synchronized to your Azure AD, or if you try to move the user with the Move-CsUser cmdlet and your on-premise SFB Management Shell with a wrong HostedMigrationOverrideUrl.

Details about that you will found in my following post about troubleshooting Skype for Business Hybrid.

Migration from onPremise to Office 365 – Part 7 -Troubleshoot Skype for Business Hybrid


So first I checked if the msRTCSIP-PrimaryUserAddress is synced correct to Office 365 an Skype for Business Online.

Connect-MsolService
Get-MsolUser -UserPrincipalName jnokes@braintesting.de | fl | more

Look’s good.


You can also check, if the msRTCSIP-PrimaryUserAddress attribute is synced correctly to Office 365 from the Azure AD Connect Synchronization Manger as follows.

From the Connectors tab you can check if the attribute is selected for synchronization.

And from the Operations tab, you can select the actual synchronization from your on-premises domain and click on the Updates link, here you can see the newly users synced to office 365.

You can also change some attributes on-premise from an affected user, start a delta synchronization and check what attributes where synced to Office 365.


The second common issue with the HostedMigrationOverrideUrl, can only happen when using the PowerShell cmdlet Move-CsUser from the on-prem SFB Management Shell and using an on-premises account which is synced into Azure AD.


So this isn’t the issue for the error message in my case.


If you are using the Skype for Business Admin Control Panel, you must supply an account that ends in .onmicrosoft.com and therefore the above issue cannot occur.

The hosted migration service is the service in Office 365 that performs user moves. By default, there is no need to specify a value for this parameter, as long as the hosting provider has its AutoDiscover URL properly configured and you are using an admin account the ends in .onmicrosoft.com. If you are using a user account from on-premises that synchronized to the cloud, you must specify this parameter.

Source: https://docs.microsoft.com/en-us/powershell/module/skype/move-csuser

If you are using Move-CsUser in PowerShell, you can either use an account that ends in .onmicrosoft.com, or you can use any on-premises account that is synchronized into Azure AD, provided that you also specify the HostedMigrationOverrideUrl parameter in the cmdlet

To determine the HostedMigrationOverrideUrl please read the following article from Microsoft.

Source: https://docs.microsoft.com/en-us/skypeforbusiness/hybrid/move-users-between-on-premises-and-cloud#required-administrative-credentials



What I also noticed, that when running the following cmdlet, the attribute SipProxyAddress is empty, even we saw further above, that the msRTCSIP-PrimaryUserAddress attribute is synced from on-premise successfully to Office 365.

$credential = Get-Credential
Connect-AzureAD -Credential $credential
Get-AzureADUser -ObjectId <UserPrincipalName> | fl

Get-AzureADUser -ObjectId jnokes@braintesting.de | fl ObjectID,ObjectType,AccountEnabled,DirSyncEnabled,DisplayName,LastDirSyncTime,Mail,SipProxyAddress,UserPrincipalName,Proxyaddresses



I also checked the Interpreted User Type and Hosting Provider from Skype for Business Online and Teams with the following cmdlet for the affected user.

# Connect to Skype for Business Online
$credential = Get-Credential
$sfboSession = New-CsOnlineSession -Credential $credential
Import-PSSession $sfboSession

Get-CsOnlineUser -Identity jnokes@braintesting.de | fl Interpretedusertype, hostingprovider


For users they had an on-premises Skype for Business account, this should return

For users they had their Skype for Business on-premises account moved directly to Teams successfully, this should return

For my affected user jnokes@braintesting.de, it returned a new type I am not seen so far.
AADConnectEnabledOnlineSfBUserWithTeamsLicenseNeedsProvisioningToAD


Under the following page, you will find some more types.

InterpretedUserType
https://www.msxfaq.de/cloud/sfbonline/interpretedusertype.htm



So finally I hadn’t any idea, what the exactly underlying issue was. Often such problems relay in some synchronization issues, where not all data is synced properly in the back end from Office 365.

If you created and synced the account just a few minutes ago, just wait a little bit more, some times it also can take up a few hours or days.

Even you will get sometimes this info directly from the Office 365 WebGUI as follows, that you have to wait a little bit longer as usual.


If you click on Check status, you will forwarded to the following link with the Teams setup status.

Teams‎ setup status
https://admin.microsoft.com/Adminportal/Home?source=applauncher#/teamsprovisioning


You can also check the status of the different services as follows.

Get-MsolUser -UserPrincipalName jnokes@braintesting.de | ft DisplayName, UserPrincipalName, OverallProvisioningStatus

How to tell which Office 365 services have been provisioned
https://docs.microsoft.com/en-us/archive/blogs/cloudpfe/how-to-tell-which-office-365-services-have-been-provisioned

View Microsoft 365 account license and service details with PowerShell
https://docs.microsoft.com/en-us/microsoft-365/enterprise/view-account-license-and-service-details-with-microsoft-365-powershell

(Get-MsolUser -UserPrincipalName jnokes@braintesting.de).Licenses[0].ServiceStatus


Check the validation status
https://support.microsoft.com/en-us/topic/you-see-validation-errors-for-users-in-the-office-365-portal-or-in-the-azure-active-directory-module-for-windows-powershell-5c3bf8f7-de1b-6f51-6623-3c005d1f5900
Get-MsolUser -UserPrincipalName jnokes@braintesting.de | Select Errors, ValidationStatus

The following cmdlet retrieves all the errors on the object of interest:
$errors = (Get-MsolUser -UserPrincipalName “”).Errors

The following cmdlet retrieves all the errors for all users on Azure AD: 
Get-MsolUser -HasErrorsOnly -All | ft DisplayName,UserPrincipalName,@{Name=”Error”;Expression={($_.errors[0].ErrorDetail.objecterrors.errorrecord.ErrorDescription)}} -AutoSize -wrap


In my case, I faced this issue for all newly created and synced users to Office 365. Users with on-premises Skype for Business accounts, but still synchronized a few days or weeks ago to Office 365, can be moved without problems.

So I assumed the configuration from Skype for Business Hybrid have to be correct and it must have to do something with the synchronization from the newly created users.

As the sync to Office 365 for these users was meanwhile also two or three days ago, I opened a ticket at Office 365.

Microsoft then runs a diagnostic check against my tenant and didn’t find any problems. A few hours later, I was trying to move the affected users again and suddenly it works for all users, created and synced two or three days ago and newly immediately created and synced users.

So in the end, if the diagnostic check resolves the problem and kicked in the final complete synchronization in the back end of Office 365, or just the time solved the problem, I cannot evaluate finally.

But one thing always keep in mind regarding Teams, sometimes to set up a new account in Office 365, can take up due to increased demand longer than usual and you can only wait.

If the problem still occurs a few days later or if you cannot wait, you have to open a ticket at Office 365.




Links

Move-CsUser
https://docs.microsoft.com/en-us/powershell/module/skype/move-csuser

InterpretedUserType
https://www.msxfaq.de/cloud/sfbonline/interpretedusertype.htm