At a new deployment I saw an issue when some users were enabled for Lync, they could not sign in.
When we investigated the client certificates, I saw this error:
Disable and re-enable the user did not change anything.
Luckily we also had a Survivable Branch Appliance (SBA) in the deployment, so forcely moving the user to the SBA, did change something, so the user was able to login. Hey now things work, but having the user at the SBA was not what we wanted, so we moved the user back to main pool and we were back at the beginning... The user could not sign in.
Luckily we had also a test user with this problem, so production users would work and we could do more investigation for this problem.
I escalated the problem to Microsoft PSS, who is working on it now... Hopefully this post will be updated soon.
Update: The problem was caused by some incorrect routing group IDs, the problem was identified by event id 30057 in the Lync Server eventlog, text is:
msRTCSIP-UserRoutingGroupId attribute for a user is incorrect in Active Directory domain:<AD-domain>
The user with these attributes has DN:<USER-DN>
These incorrect attribute cannot be updated in the database.
Source of replication is: LocalRegistrarReplication.
This is usually caused due to home pool information change in Active Directory using unsupported tools or direct edits to AD. To resolve this condition, move all the affected user back to the original Pool using Move-CsUser and then move the user again to this Pool gracefully using Move-CsUser.
Neither moving the user (who btw originated on this very pool), removing the content of MSRTCSIP-UserRoutingGroupID field of the object nor a full reset of the pool did resolve this issue. So we decided to renew the local databases.
First backup userdata (just in case):
Export-CsUserData -PoolFQDN <fqdn> -FileName <filename>
Then on all FEs:
Install-CsDatabase -LocalDatabases -Clean
After all the servers are back online the error was gone.
The problem was also causing some response groups to stay in offline mode with event id 30058 in the Lync Server eventlog, this was also solved with this action.