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!

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

  • Ijaz Ahamed

    Does migrating users from Skype for business on premises to Skype for Business online change their VOIP number that is already setup?

  • Thomas

    We have an older skype4Business install on-prem. We are using Teams as well in island mode. I don’t want to go through the pain of upgrading s4b on-prem, setting up hybrid, migrating users, etc. I don’t care about Skype clients talking to Teams clients, etc. But to enable my audio-conference license in teams, for some reason, I had to disable the s4B setting on my client on-prem. This fixed my ability to audio conference but now I can’t see my TEams user in TEams admin console. I see my user is flagged as interpretedUsertype “HybridOnpremSfBUser” even though I don’t have any hybrid stuff going on. Is there any guidance on moving to Teams in purely island fashion without setting up hybrid? Everything I’ve read suggests setting up hyrbrid. We aren’t using any voice features on either side.

  • Matt Webster

    Hello Curtis, thanks for the concise write-up.

    We are planning to migrate all of our on-premise users to Skype online and completely remove the hybrid as you describe. Do you know if we can repeat this process for another, completely separate, on-premise deployment (ie different SIP domain, AD domain, forest, everything) in the scenario of an acquisition. Microsoft state that you can only have one hybrid setup but I think this means concurrently rather than consecutively. Else if we took over another business we would not be able to use a hybrid to migrate them into the same tenancy.

    Thanks in advance,

    • Hi Matt, that is really good question, and to be honest I hadn’t thought of that scenario. For sure the”one on-premises hybrid deployment” is concurrently – you cannot have more than one at a time. I see no technical reason why it would not work a second time with a different on-premises deployment once the first is fully transitioned online. I will ask around for you though and post back here if I hear otherwise. You will know quickly whether this works or not when you go to configure hybrid a second time.

  • 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=""> <s> <strike> <strong>