Skype Online user unable to sign in following hard cutover and SIP address change

By |2017-12-11T11:01:20+00:00April 24th, 2017|Skype|0 Comments

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. During this work they were also changing their SIP address to match their UPN which had a valid domain registered within the tenant.

During 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.

Now for the vast majority of users this went successfully and they could sign in, however three users were not able to sign in. 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. 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.

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. 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:

The server returned a trust fault: ‘The specified request failed’.
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.’

At this point I checked their Azure AD Connect sync engine to see what information was synchronising and no MSRTCSIP- attributes were being synchronised.

At 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 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!

Whilst logged into Outlook on the Web I was able to receive a message from another online user in the same tenant, progress at last! At this point I tried sending a message to a federated contact which was received, the problem was that the federated contact was not able to respond to the message. Now we were getting somewhere, after opening the client logs of the federated client I was able to see the messages coming from the problem user and one thing stood out, the logs showed that the SIP address the federated client was seeing the messages coming from was actually the old SIP address and not the new one that matches the UPN.

So this is strange, the portal shows the correct address which isn’t valid for sign in but the user seemly has a different SIP address when communicating via the web. Now I had to identity where this incorrect address was coming from, so using powershell I first connected to Skype Online and checked the account but couldn’t see any mention of the incorrect address. Next step was to connect to Azure AD (using V2 of the module) and when looking at the users attributes there, one stood out. In Azure AD there was an attribute displayed called SipProxyAddress and this was set to the incorrect address. (NB I wasn’t able to see this attribute in the V1 of the module that I had installed)

So now I wanted to change it to the correct value and see if that made any difference but I couldn’t use the set-azureaduser cmdlet as there was no switch for SipProxyAddress, so had to find an alternative. Fortunately you can use on-premise AD attributes to control the SIP address for online users if you don’t want it to match the default address type of matching the UPN so I changed the MSRTCSIP-PrimaryUserAddress field in the users Active Directory account from blank to the correct address and forced an identity sync.

Once the Sync had completed I once again checked Azure AD and the attribute had updated and the desktop client was able to sign in.

It looks like the users account had been synchronised to AzureAD whilst it still had the Lync attributes set and once removed it had left its mark on the SipProxyAddress attribute which hadn’t reset to null when they stopped synchronising the Lync attributes, now I’m not sure if that is intended behaviour or not but after setting the attribute back to blank and synchronising it remained set at the correct value which does suggest it only gets writen but not reset when the attribute is no longer synchronised.

The moral of this story is don’t always trust what you see in the GUI, use powershell to check attributes and if you’re going to do a hard cut over it’s best to leave the desired SIP address in the MSRTCSIP-PrimaryUserAddress field.

Leave A Comment

like what you see? 

Sign-up to our newsletter and never miss out on the latest blogs, events and tech news from the world of risual
Give it a try, you can unsubscribe anytime.