Issue with Presence and IM on Federation when having a side-by-side tenant and Skype for Business on premises deployment

Recently there have been quite a few reports by customers who have issues with Presence and IM while Federating with other organizations. One of the most common scenarios, related to this phenomenon, is tied up with tenants being part of the communication path between the two organizations.

Usually, there is a tendency to ignore the presence of an Office 365 tenant, when it is an important piece of the puzzle. When a given organization has a side by side tenant and Skype for Business on Premises deployment with a certain form of Federation, which are not set to Hybrid, it should raise a flag.

Most often, in terms of user experience, the presence state of the Callee (Destination user) might be “Presence Unknown” / “Offline”, and instant messages cannot be delivered at all.

Why does it happen?

Whenever a Skype for Business Online homed user initiates Presence or IM requests to another user (For example, SUBSCRIBE request to retrieve a user’s presence state), it will go through a certain path, which will hit Skype for Business Online servers first.

If, by any chance, this request will hit an existing Skype for Business Online homed user (The Callee, aka the destination) it will stop there. It might never reach your Edge servers, and therefore your Skype for Business On Premises homed user will not get the message, or your On Premises Front End server will not get the presence SUBSCRIBE request.

There are multiple reasons for having such a situation. The most common ones point to users which are actively enabled for Skype for Business Online, users which were previously enabled but their Skype for Business Online license plans were disabled, and even users which were enabled for Microsoft Teams starting January 2018 (Due to a change related with Skype for Business Interop with Teams).

Hence, this issue applies to those users who have a corresponding and matching account on both Skype for Business on Premises and Skype for Business Online, whereas usually the active account is homed On Premises, and the Skype for Business Online account is not needed yet (If at all).

Below is a diagram which demonstrates the difference between a supported and non-supported scenario:

How do we resolve this issue?

The supported and recommended way to resolve this issue is simply to have a proper Skype for Business Hybrid deployment in place for all federated parties involved. This is required only in case the situation described above applies to at least one of them. An organization that has either Pure Skype for Business Online (No Skype for Business on Premises deployment in place) or Pure Skype for Business On Premises deployment (With no Office 365 tenant that holds the same SIP Domain\s as the On Premises has) does not require setting Hybrid.

For more information on setting Skype for Business Hybrid properly, please refer to Microsoft Docs articles on this topic:

So why going for Skype for Business Hybrid?

  • This is the supported configuration by Microsoft.
  • Having a properly deployed and managed Skype for Business Hybrid deployment will prevent the reoccurrence of this issue in the future. In this scenario, all other tenants will be aware that your tenant is Hybrid and not purely Online. Moreover, if users are managed following the guidelines of Skype for Business Hybrid deployment, confusion will be prevented and for each user there will be a definitive indication of its location (Whether it is homed On Premises or Online).
  • Having Skype for Business Hybrid will grant you the flexibility to decide where to home your Skype for Business users, hence you will be able to enjoy both worlds of Skype for Business Online and On Premises. You can migrate users from on premises to online at your own pace.

How to identify this issue is affecting me?

The most important piece of information is to identify if you and/or your federated partner have a side by side Office 365 tenant and a Skype for Business on premises deployment. As stated, this is the flag raised to go Hybrid, the sooner the better. Since having a Side by Side deployment, as described previously in this document, is not supported, the following golden rule applies:

If it works, it does not necessarily mean it is supported. So, in our case here, the fact that users were not enabled for Skype for Business Online and are not affected by this issue, for whatever reason, does not mean we are in a supported state, and there is a risk this issue would surface.

You can find possible evidence using a few methods, but the best option on the table still stands: Go Hybrid! If you still wish to get a notion about what is going on your tenant, you can use the following methods to retrieve some useful information:

  1. You can use Snooper (Skype for Business Debugging Tools) to analyze the Uccapi logs of a user which had this issue while trying to subscribe for another user’s presence state or to send an IM but failed. The error messages vary from one scenario to another, but they can become useful from time to time. For example, when a user is not actively enabled for Skype for Business Online, but still exists and classified as “Disabled”, the following might appear (Note, there is no single univalent error code, each scenario might have different behavior):

ms-diagnostics: 4049;reason="Target is disabled";processing-cluster="";processing-frontend="";target-user-primary-pool="";source=""

  1. You can use Get-CsOnlineUser or Get-AzureADUser to retrieve a list of users and\or a given user details from your tenant.

One way is to use the Get-CsOnlineUser cmdlet of Skype for Business Online PowerShell to retrieve information about a user which is suspected to be homed online.

If you wish to list all users which are homed on Skype for business online, the following queries can be used:

  1. Get-CsOnlineUser -Filter {HostingProvider -like ""} | Select-Object UserPrincipalName,SipAddress,DisplayName
  2. (Get-CsOnlineUser -Filter {HostingProvider -like ""} | Select-Object UserPrincipalName,SipAddress,DisplayName).count
  3. Get-CsOnlineUser | Select-Object UserPrincipalName,SipAddress,DisplayName
  4. (Get-CsOnlineUser | Select-Object UserPrincipalName,SipAddress,DisplayName).count
  5. Get-CsOnlineUser -Identity username | select HostingProvider, SIPProxyAddress | fl

Also, you can use Azure AD PowerShell Module and run the following cmdlet. A possible result, for example, would be for a user which was never licensed should return an empty result:

Get-AzureADUser -SearchString Username | select SIPProxyAddress

Important Note:

While going Hybrid with Skype for Business, please take into consideration the following:

Once you have set the SharedSipAddressSpace parameter to $True on a given tenant, it will apply to all SIP Domains which are registered and verified under this Office 365 tenant. In other words, when setting a tenant to be Hybrid all other SIP Domain registered under the same tenant are considered hybrid as well. The reason for that is related to the fact the that tenant's SharedSipAddressSpace setting is global for the whole tenant and not exclusive for a single SIP Domain. Each SIP Domain you would like to utilize for Skype for Business under this tenant will have to be deployed as it was Hybrid, on the same single on-premises topology of Skype for Business Server used up to this point.

For more information: