In addition to the challenges created by the unified contacts store, my recent Office 365 migration project saw some issues where a user’s Lync/Skype for Business client failed to pick up a change in Exchange Web Services (EWS) as part of the move to Skype for Business Online.

The reason for this is unclear but I’m not the only one who’s experienced it – Richard Brynteson describes exactly the same scenario where, after a migration from an on-premises Exchange mailbox to Exchange Online, the Lync 2013 client is unable to connect to the Exchange server and pull conversation history and meeting information.

If we looked at the configuration information for the Lync client (by Ctrl+right clicking on the Lync taskbar icon), we could see that the client was not autodiscovering the move to Exchange Online and still showed on-premises Exchange details, instead of a blank EWS Internal URL and an entry of https://outlook.office365.com/EWS/Exchange.asmx/WSSecurity for the EWS External URL.

One suggestion given to me to force a new autodiscovery search was to wipe the user’s cached client information (in %appdata%\Local\Microsoft\Office\15.0\Lync\sip_alias@domainname.tld). That sounded a little destructive but Richard’s post suggests removing a single registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync\username@domainname.tld\Autodiscovery.

Even better though is the solution from a comment on Richard’s blog post, from “Chad”:

We’ve resolved this by having users sign out of Lync and then choose “Delete my sign-in info”, then just sign back in and their Lync client now connects to 365. We provide this as post-migration steps to users once we move their mailboxes to 365. Hope that helps and is typically easier than deleting [registry] entries.

That’s a much more user-friendly fix (which worked for me) – and it’s one to add to the project FAQ list.