Greetings tech fans....I was recently trying to move an on-premises Skype for Business account to Skype for Business Online and after authenticating to Office 365 I received an error indicating the account could not be moved followed by this message in Control Panel:
I've recognized this error before being related to the account in the tenant not having a Skype for Business license however in my case I was sure to license it beforehand. After looking at the account in Azure Active Directory I realized the SMTP reply-as address was set to the vanity domain FQDN and not the proper suffix used by Skype for Business. In my case, this was a 'pure Online' user meaning their mailbox and Skype accounts would both be in the cloud even though the AD account itself started life on-premises.
When the account is moved from on-premises to Online, the SIP address must match the SMTP reply-as address for you to successfully move the Skype for Business account in a hybrid deployment.
You might say "why not change your default domain in Office 365 to be your vanity domain?". This would indeed solve the problem as the primary SMTP address would always match the SIP URI however you cannot make a vanity domain the default if it is a federated domain (which mine is).
So ultimately we need to 'prime' the on-premises AD account with the correct reply-as SMTP address for the account to be moved to Online.
You can do this by starting Active Directory Users & Computers and clicking the View tab then choosing Advanced Features. Locate the user you want to modify by navigating the directory tree. Don't search for them as the tab we want to display won't show up if you do it this way. Once you locate the user, click the Attribute Editor tab, scroll down to "proxyAddresses" and add the words "SMTP:firstname.lastname@example.org" (making sure you use capital letters for the word SMTP) substituting your user's primary email address as follows:
Click the Add button then click OK twice to save. Perform a manual sync of AD (optionally wait for the next sync cycle) by logging into your Azure AD Connect server, opening an Admin-mode PowerShell window, and keying in the following:
Start-ADSyncSyncCycle -PolicyType Delta
Wait about five minutes, then check your user's SMTP address in Office 365.
Here is the before screenshot:
Now you can try the move again and it should succeed:
Let me know if you also experience this issue or if you have another workaround.