The account was able to login so I was confident sync and ADFS were working post migration and then I noticed that the presence indicator within Outlook on the Web was green, suggesting it had correctly connected to Skype for Business Online with their credentials which is strange as the desktop client was still unable to connect! The fault reason was: ‘The SIP URI in the claim type requirements of the web ticket request does not match the SIP URI associated with the presented credentials.’Īt this point I checked their Azure AD Connect sync engine to see what information was synchronising and no MSRTCSIP- attributes were being synchronised.Īt this stage I was a little confused, since the portal clearly showed the user had the desired SIP address I decided to try logging into Office 365 with their credentials to make sure there wasn’t any authentication issues and that they could access the mailbox using Outlook on the Web. The server returned a trust fault: ‘The specified request failed’. I then looked at the client logs and whilst I couldn’t see anything in the Messages section I did find a clue in the traces: So I had a look at the desktop client, made sure there weren’t any saved credentials and that the new SIP address was in the sign in field but they still couldn’t sign in. Given they were signing into Skype Online from the same network as other working users I knew (but checked anyway) that the DNS records were correct for autodiscover. I checked their accounts in the Admin Portal and their sign in address was correct and they had been given a license so I then checked the Skype for Business Admin portal and saw the user listed with their new SIP address. Now for the vast majority of users this went successfully and they could sign in, however three users were not able to sign in. During this work they were also changing their SIP address to match their UPN which had a valid domain registered within the tenant.ĭuring their migration process the accounts were disabled in Lync and had their Lync AD attributes (MSRTCSIP-) cleared, they were synchronised to Azure AD and using group license assignment were enabled for Skype for Business Online, so far so good. I recently encountered an issue with a customer who was moving from an on-premise Lync deployment to Skype for Business Online, now usually I would use hybrid and move users over in batches but as they’d hadn’t moved past the pilot stage they had decided to go with a cutover approach and skip deploying Edge servers.

Unable to sign into skype