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;
Start-ADSyncSyncService
-PolicyType
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.