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.
UNABLE TO SIGN INTO SKYPE ACCOUNT LICENSE
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.