How sign-in addresses and user IDs are managed in Lync Online

Because of a recent change in the way that Session Initial Protocol (SIP) addresses are provisioned in Microsoft Office 365, it is no longer necessary to update a user’s SIP address after the user's Office 365 sign-in address (user ID) is changed. Previously, when a user’s Office user ID was changed, the IT administrator would have to update the user's SIP address to match the new Office 365 sign-in address. This old behavior would frequently prevent users from signing in to Lync Online for Office 365.

After the user ID of a Lync Online user is updated, there are some actions that the user must perform to make sure that the service continues to work without any interruptions. These actions are as follows:

• Reschedule Lync Online meetings
  Because of the way that the Lync Online service generates meeting URLs, any meetings that were scheduled by using the old Lync Online SIP address must be rescheduled. If these meetings are not rescheduled, meeting participants may receive an error message when they try to join any Lync Online conferences that are scheduled by that user.
  
  Note Rescheduling Lync Online meetings is only necessary if the user name part of the user ID was changed.
• Communicate changes to external contacts in Lync Online contact lists
  External contacts (and this includes other federated Lync organizations), Windows Live users, and MSN users must be notified about the change to the user’s SIP address. Until external contacts remove and update the old contact, the contact object for the user is displayed as either Presence Unknown or Offline.

The reason for this change in behavior is because many users were confused that their Office 365 user ID can be very different from their Lync Online sign-in address (the SIP address). Although some companies may want a configuration that uses disjointed sign-in addresses for Lync Online and Office 365, it is currently an unsupported configuration. Support will advise the IT administrator to use a supported configuration.

This change is implemented through a Source of Authority (SOA) flag on the msRTCSIP-PrimaryUserAddress attribute in Active Directory Domain Services (AD DS). The SOA flag tells the service where the update came from and if it originated from an authoritative source. Consider the following example scenarios:

• An Office 365 tenant who does not use directory synchronization can only make updates in the cloud. Therefore, the only authoritative source is the Office 365 cloud.
• An Office 365 tenant has an on-premises AD DS and changes the user ID in the on-premises environment. These changes are synchronized to the cloud through directory synchronization. In this scenario, the on-premises AD DS is the authoritative source. If any other service tries to change the SIP address, the change would be denied because the source of authority is set to the on-premises AD DS.