I was recently having a problem provisioning Active Directory users with Skype for Business Online access, basically after a DirSync job had completed none of the user accounts were appearing under the SFB Admin Centre. The AD that was being used previously had Lync Server 2013/SFB 2015 deployed, therefore I thought it might be some kind of Active Directory attribute causing the problem. The first stage was to compare a new user account (which had never accessed Lync on premise) and an existing user account, to see if there were any differences in the msRTCSIP- attributes.
The only one I noticed consistently was the msRTCSIP-DeploymentLocator. This attribute was populated on user account NOT being enabled for SFB Online. The new user account, with full access to SFB Online did not have this attribute set.
For a test I removed the msRTCSIP-DeploymentLocator attribute, then forced and AD replication cycle.
The next step was to run a full sync from the DirSync (or AD Connect) server, to update the Office 365 Azure AD instance with the changes. The following command can be used to force a sync for DirSync;
You can view the progress of the DirSync jobs from the FIM 2010 R2 console, this can be launched using the miisclient.exe from inside the installation folder.
If your problem has been the same as mine, you should see an update under the Active Directory import management agent under FIM. This is basically telling FIM to sync updates from the AD to its own metaverse, before pushing the changes out to Azure AD.
The msRTCSIP-DeploymentLocator attribute is no longer being synced.
This this change, the users from AD were now listed as SFB Online users. This meant they could login to SFB without problem. I tested audio/video calls and everything was fine, I had initially worried about other stale attributes for things like SIP causing problems.