Recently I was involved in a project where we were moving all Lync users from a Lync 2013 server deployment to the cloud. The Exchange Team was also moving their mailboxes to cloud.
Since deploying SfB Hybrid is a very straight forward process we weren’t excepting any issues. Everything was prepared and Proxy Bypass was configured. We even managed it to move a SfC federation from server to hybrid. This is may be another blog post.
When we tested the first users in SfB Online everything was good except that we had problems adding/removing contacts. This was also true, when we were creating groups and tagging users for status changes.
We got „Cannot add, remove, or move contacts or groups at this time. Please try again later“
After a few Google searches we were sure that this is not related to Exchange Autodicover but we picked up the idea that it can be the „contact list provider“.
First thing we checked for the on-prem users was the contact list provider. This can be done in the client via the „configuration information“. This was set to Lync server. All good. Then we checked if UCS was enabled On-Prem. This was the case at a global level. Not so good.
But this was it. The other steps required (e.g. server to server authentication) to enable UCS were not completed.
Then we discovered that for all of the server users we got the following result („Ready to Migrate“) which confirmed that the contacts of the users were not moved over to exchange but were still on „lync server“. This was a good thing.
Testing the UCS status for a single user is also possible via:
$cred = Get-Credential “AD\garth.fort”
Test-CsUnifiedContactStore -TargetFqdn sfbpool@contoso.com -UserSipAddress sip:garth.fort@contoso.com -UserCredential $cred
For our users this resulted in:
“User has not been migrated. Verify that the user a mailbox in Exchange and that the user has been migrated”
The situation in SfB Online was a bit different. UCS is disabled by default. But the SfB Online users had UCS as the contact list provider for some reason.
We tried moving the SfB users to server and then back to online. For some users this worked. But after a while UCS became active again. We also tried disabling UCS at a user level before moving the users to SfB Online again. But this doesn’t changed anything.
Then we started looking at „Invoke-CsUcsRollback“ but we expected that this wouldn‘t work for user being on Lync server because the integration with exchange was not setup properly. And this was indeed the Case.
“Invoke-CsUcsRollback : Failed to configure the roll back bit on Exchange“
But it turns out that this worked, if you run this against SfB Online for a user being in the cloud and having UCS as the contact list provider.
After a few seconds the client switched to „Skype for Business Server“ as a contact list provider.
We were quite happy that this helped because the remaining options are not so nice:
- „Invoke-CsUcsRollback -Fore“ -> Users will loose their contacts
- Move Exchange Online Mailbox back to On-Prem -> You don’t want to be that guy telling this to project team if they already moved hundreds of mailboxes to the cloud.
What we learned:
- Check the status of the contact list provider before a doing a SfB/Exchange Online migration
- Look at the client and at the server side configuration
- UCS is not supported in the cloud even though Technet states otherwise
- To avoid this problem, try the rollback on-prem before you move the mailbox to Exchange Online
The “why this happened” is not 100% clear. The server situation showed that contact migration to exchange was not completed but it somehow completed after the user was moved to cloud. So doing a rollback for the SfB Online user is the right choice.
Sources: