Office365 & Microsoft Lync - Server is Temporarily Unavailable

====
I recently ran into a very odd issue with Microsoft Lync 2013 on Office365 - a lot of users in a deployment simply could not login to the service. They always received this error:

Cannot sign in because the server is temporarily unavailable.



I must admit that when I first saw this reported I thought it would be relatively easy to fix. The site in question utilised a Proxy for web access, and had strictly filtered outgoing routing for Internet connectivity. Assumption is a great way to ruin your day isn’t it?

Anyway, what I found was that users within my client’s Active Directory could not authenticate, and produced this issue. However, if I:

• Created a new local user but then logged on to Office365 with the same SIP Account the connectivity worked.
• Created a new Active Directory user but then logged on to Office365 with the same SIP Account the connectivity worked.
• Created a new Active Directory user by copying the faulty account - logged on to Office365 with the same SIP Account worked.

The issue was only experienced when using the user’s ‘proper’ Active Directory account. Something in the profile then? No. Local profiles, no roaming - and provisioning a new, clean profile and even stopping Group Policy applying didn’t resolve the issue.

After further investigation then it became very clear that the issue was with authentication, and only with certain accounts.

Want to know what it was? Spaces in the SAMAccount/UPN, but only for legacy accounts that had been transitioned through from earlier Domain/Active Directory functional levels. How to fix it? Well, simple really - remove the space from the UPN. I would appear that this is passed up as part of the authentication process, and by removing the space from the UPN it allowed the authentication to complete properly.

To qualify, the user was set up like this:



I changed the UPN from ‘Andy Pandy@domain.local’ (note the space) to ‘AndyPandy@domain.local’ and all was well with the world. Note that if I created a new user with the same space in it, everything was also OK, it was only legacy accounts.

You may need to think through the impact of this change. With my client, they always logged on with their SAMAccount name so modifying the UPN wasn’t a big issue. Typically, we try and align the UPN with a user’s email address as it gives the user a simple identity that’s easy for a user to understand, however we hadn’t progressed that far with this particular adoption.

Anyway, you live and learn.

blog comments powered by Disqus