AAD Connect and SIP Address synchronization

I saw several discussions about the synchronization of the SIP address from on-premises Active Directory to Azure AD using AAD. I saw some complains, that SIP addresses should be synchronized using the proxyAddresses attribute, precisely if the proxyAddresses attribute contains a SIP addresses then AAD Connect synchronizes this to Azure AD and the expectation is that this SIP-proxyAddress should be used as SIP addresses in Azure AD and Teams. Huh. Is this really so?

I think it’s worth to have a look on the description of the messaging schema. I can see there a description for proxyAddresses:

ProxyAddresses

This existing Active Directory multi-valued attribute is part of the base Active Directory schema introduced in Windows 2000. This attribute contains the various X400, X500, and SMTP addresses of the user’s email. In Live Communications Server 2003 and later, the user’s SIP URI is added to this list, using the “sip:” tag. The following applications search the user’s SIP URI from this attribute: Microsoft Office Outlook 2003 messaging and collaboration client Microsoft Office SharePoint Server 2007

https://docs.microsoft.com/en-us/skypeforbusiness/schema-reference/active-directory-schema-extensions-classes-and-attributes/schema-attributes-and-descriptions

Based this we can see, that the SIP addresses is added to this attribute, but this does not seems to be main source for this attribute. Let’s have a look on msRTCSIP-PrimaryUserAddress:

 

msRTCSIP-PrimaryUserAddress

This attribute contains the SIP address of a given user.

https://docs.microsoft.com/en-us/skypeforbusiness/schema-reference/active-directory-schema-extensions-classes-and-attributes/schema-attributes-and-descriptions

 

Summarize, we can conclude that the important attribute what contains the SIP address is: msRTCSIP-PrimaryUserAddress…. hmmm, but this attribute is not present in your AD? Well this is possible, because this is messaging (Office Communication Server, Lync or Skype for Business) related schema extension. You can install the Active Directory schema extension using a Skype for Business Server 2019 installer (trial work as well). You can find a trial version in the eval center:

https://www.microsoft.com/en-us/evalcenter/evaluate-skype-business-server-2019/

The schema extension can be installed without installing the Skype for Business Server 2019, as described here:

Skype for Business Server is tightly integrated with Active Directory Domain Services (AD DS). Before Skype for Business Server can be installed for the first time, Active Directory must be prepared. The section of the Deployment Wizard titled Prepare Active Directory prepares the Active Directory environment for use with Skype for Business Server.

https://docs.microsoft.com/en-us/skypeforbusiness/deploy/install/prepare-active-directory#prepare-active-directory

 

If this schema extension is installed, then AAD Connect detects this and some additional rules will be added to the Sync rule editor: In from AD – User Lync

and Out to AAD – User Lync. Similar rules will be added also for contact and group objects. On this way the SIP address can be managed from on-premises Active Directory.

 

If the messaging schema is not present but the sip addresses is added to the proxyAddresses attribute AAD Connect will this synchronize to Azure AD, but the sip-proxyAddress will be ignored, since there is no authoritative source for the SIP address.

What happens, if a teams license will be assigned?

Nothing special, if the sip address is synchronized with an authoritative source (using: msRTCSIP-PrimaryUserAddress) then this address will be used. If there is no authoritative source for the sip address, then the SIP address will be generated on a basis of the userPrincipalName. If the userPrincipalName is the same as the sip-proxyAddress then this might suggest as the sip-proxyAddress is used, but this is not the case.

I hope this helps to understand how the synchronization of the SIP address is intended to work.

 

Happy Troubleshooting!