It indicates that even though the user has been disabled on premise, and enabled for Skype for business online, the entire system (Cloud and on prem) would still be made to believe that the user’s on premise Skype account remains authoritative, thus the misleading message we were receiving as displayed above. Unfortunately, in this situation, only the one that didn’t change mattered the most. One can see that all the other attributes except one was removed. The picture above was from a user that was disabled and synchronized back to the cloud. This would usually be the case when users are migrated with a Hybrid setup or Resynced back to the on premise active directory after users are enabled on Skype for Business online. , which implies that the user has been moved online. SRV, which indicates that the user is homed on premise on a Skype for Business or Lync Server system, andĢ. In my understanding, there are two possible values that this attribute can contain and they are :ġ. From our extensive testing, all MSRTCsip attributes reverted to NULL values when a user was disabled except for “ MSRTCsip-Deploymentlocator.” This attribute indicates where a user is Homed: Skype for Business on onpremise Server or Skype for Business online. This was true to some extent as as shown on above. ![]() Our working assumption was that once the user is disabled or deleted from Skype for Business or Lync Server on Premise, that these attributes would revert to Null values – signifying that the user has been deleted from the Communications system. For Skype for Business or Lync, the AD attributes leveraged starts with “MSRTCsip” as shown in the picture below. This also to Exchange Server and other applications that leverage Active Directory Domain Services Schema and other partitions to function. O365 tenant with E3 licenses, including Skype for Business Online Licenses assigned to users.ĭiagnosis and Solution: When Lync or Skype for business Server is deployed in an environment, certain attributes are added to Microsoft active directory with which the communications software operates. ![]() Lync 2013 deployed with no hybrid and no intentions of Hybrid setup ever.Ĥ. AD accounts synchronized with Azure with MSRTCsip/Lync attributes.ģ. We removed the O365 Licenses from the user, waited for a while and reassigned the licenses to the users, yet the message above remained.ġ. This message was a little misleading because I verified that the users were enabled with Skype for Business Online licenses. ![]() When the user attempts to sign in to Skype for Business online, they get the message below. However, as we eventually discovered, that wasn’t the case. Scenario and Symptoms: Theoretically, disabling Lync or Skype for Business on premise users, then resyncing their AD identities back to Azure AD was supposed to clear the way for users to sign in to the cloud successfully. The customer isn’t looking at setting up Skype for Business Hybrid at all, so the only option is to switch off the users accounts on premise (Deactivate or delete or simply abandon) and redirect users to log in to the Skype for Business online account. After identity synchronization, users were assigned O365 E3 license with Skype for Business plan 2 activated. Customer activates Microsoft Office 365 Cloud tenant, then synchronizes User AD identities to Azure Active Directory in the Cloud – with attributes including MSRTCsip* attributes, needed for Skype for Business online to work, when Users are migrated to Skype online from Lync on premise. Issue: Lync or Skype for Business on Premise users who have been cut over to Skype for Business online are unable to sign-in.īackground: Microsoft Lync Server 2013 have been deployed for years and fully functional on premise.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |