Tips for Transitioning from Skype for Business Hybrid to Pure Online

As Office 365 adoption grows, more Skype for Business (SfB) hybrid deployments are being transitioned to pure online after all of the users have been migrated to online. While some steps in this final transition process are well documented, such as the decommissioning of the SfB on-premises servers, other steps are poorly documented.

This post provides some details on one step of the transition to pure online that isn’t well documented: removing the SfB user attributes (e.g. msRTC*) in on-premises AD from users after hybrid mode has been changed to pure online. This post assumes that the hybrid environment has AD directory synchronization configured (e.g. on-prem AD was synchronized to Azure AD).

Why do we Care about SfB On-Premises AD Attributes after all Users are Migrated and Hybrid is Switched to Pure Online?

This is a good question, and there is no official documentation. However, two reputable sources reference deleting these on-premises AD user attributes after migration (or a when doing a full cut-over), but without much explanation:

As stated in the first article mentioned above, the recommended method to clear those on-premises AD user attributes is to use the Disable-CsUser (e.g. Get-CsUser -Identity| Disable-CsUser -Verbose). In field experience this sometimes does not fully clear the msRTC attributes, and in at least one deployment I have seen it leave behind the msRTCSIP-DeploymentLocator attribute.

So why do we need to clear these attributes? After doing some research, it seems the risk of not clearing those user attribute on-premises is that some SfBO features – specifically voice features using Cloud Connector Edition (CCE) – will use those msRTC* attributes to determine where the user resides (on-prem or online). Specially after the switch to pure online is completed (e.g. DNS records point to online, etc…), CCE will see those synchronized Azure AD attributes, or the InterpretedUserType attribute set as “HybridOnline”, and conclude that the user voice services are still serviced by SfB on-premises, and attempt to direct the calling services to on-premises. The calling features will fail because the SfB on-premises is no longer operational.

What is this InterpretedUserType attribute?

This is another good question with little documentation. The InterpretedUserType attribute has two values which reflect whether a user is in hybrid mode (value = “HybridOnline”), or pure online (value = “PureOnline” or “DirSyncedPureOnline”).

From what I can tell, SfBO sets this value based on the presence of the msRTC* user attributes in the underlying Azure AD user object. Meaning, if the user object has those msRTC* attributes, InterpretedUserType is set to “HybridOnline”.

If the remaining msRTC* attributes are cleared in AD on-premises and synchronized into Azure AD, it appears SfBO will see those blanked attributes and change InterpretedUserType to “PureOnline” or “DirSyncedPureOnline”. Any features such as voice features in CCE will then know to properly use SfBO.

If you have any thoughts on manually manipulating this value, it cannot be set manually with PowerShell.

Should I Remove the Remaining SfB/Lync User Attributes from On-Premises AD?

This step is documented in the two reputable Microsoft sources above, and is recommended. My initial concern with doing this is that it would break integration of some existing on-premises applications or clients; specifically Outlook integration with the Skype for Business or Lync client.

This integration is purely client based integration as there is no server-side API’s used per se. Meaning when a user see’s the SfB presence for another user in Outlook, it is the Outlook client is retrieving that from the SfB or Lync client running on the same desktop. It is actually the Skype for Business Outlook Add-In, and not Outlook itself.

A good write-up on this integration is available here: Skype for Business and Outlook : Presence information on Outlook – how to get it ? Answer is here (with “the Ugly, the Bad and the Good” illustration scenarios)

Although this is client-side integration, I have read forum references stating that Skype for Business Outlook Add-In uses the SIP address to establish the link, so if we clear that attribute won’t the integration break? The next section explains that.

Note: the reverse integration – the Skype for Business client integration with Exchange  is a bit different. This is not pure client-to-client integration. It uses an API, Exchange Web Services (EWS), to retrieve free/busy, store conversation history, and other information. The bigger dependency here is that the SIP address used in the SfB client matches the email address.

ProxyAddresses vs msRTCSIP-PrimaryUserAddress Attribute

Back to the question of possibly breaking Outlook or Outlook Web App integration if we delete or blank the msRTCSIP-PrimaryUserAddress attribute.

The Outlook client (via the Skype for Business Outlook Add-In) will use the SIP address in the list of email addresses in the ProxyAddresses attribute to establish the link to the SfB client for integration.

Generally the answer is that we should populate the users proxyAddresses attribute with the SIP address. I use the word ‘generally’ because there are many sources (such as this one) which refer to Outlook needed the SIP address in the proxyAddresses but I have seen Exchange integration (Outlook 2016) work without either (with Exchange on-premises and SfBO). It likely depends on the hybrid configuration and clients used.

When using Exchange Online, the Outlook Web App does need the SIP value in the proxyAddresses attribute, so my recommendation is to populate it with the SIP address and fully remove the msRTCSIP-PrimaryUserAddress as part of completing the move to pure online.

Another Reason to Populate the SIP Address Value in the ProxyAddresses Attribute

When a user object is synchronized to Office 365 their UserPrincipalName (UPN) is used to provision the identity and service addresses for Exchange and Skype for Business Online.

In some enterprises, this UPN does not match the users email or SIP address, which breaks the golden rule for smoothly integrating Exchange and SfB integration. That is, the user’s SIP address should match their primary e-mail address.

One way around this problem, is to set the msRTCSIP-PrimaryUserAddress attribute in the associated on-premises AD user object to be the same as the email address. However, in this case, where we have just completely the transition to pure online, and deleted this attribute, this can’t be used.

As fellow MVP Mark Vale documented here, a way around that is to populate the ProxyAddresses value with the properly formatted SIP address and let dirsync populate it in Azure AD. SfBO will then use this value as the SIP address, which will match the email address, and not the UPN.

I hope that helps in your journey to pure online!

Be Sociable, Share!

2 comments to Tips for Transitioning from Skype for Business Hybrid to Pure Online

  • Kevin Joust

    good article instead of blanking the attributes can i just uninstall the skype on prem AD schema?

    • Hi,
      I would first blank those attributes using Disable-CsUser as documented in the FastTrack article. Carry-out the remaining steps to go pure online, decommission the on-premises environment, and then after a period of time when you are satisfied everything is working ok on-line, then remove the on-premises AD SfB schema. If you need to roll-back for any reason, re-installing that schema wouldn’t be fun :-)

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>