Adding a “Cloud Only” SIP Domain in a Skype for Business Hybrid World

You know the old saying, when it rains it pours.  Well, I had 4 different inquiries last week alone on this topic.  I thought I knew how it would work, but figured I needed proof.  So naturally, I took to my lab.


Contoso has Skype for Business deployed in a hybrid (split-domain) configuration. 80% of the users are homed On-Prem as they use Enterprise Voice. 20% do not use Enterprise Voice, and these users are homed online. Contoso uses the SIP namespace for all users, both On-Prem and Online.

A very common scenario in today’s hybrid world.


There becomes a need to introduce a new SIP namespace ( The desire is to home these users 100% Online.

The natural thought process would be to simply add the validated domain to the O365 tenant, and enable the new users for Skype for Business Online using the new SIP namespace. Meaning, create the new users in AD with a UPN matching, let AADC sync the user to O365, then license the user for Skype for Business.

This would also include creating all the necessary DNS records and pointing them to O365. The rational thought here being this is a SfB Online ONLY SIP Namespace. No On-Prem users will use this namespace. So, let’s setup it up as such.


Once this has been setup, we see our first issue.  Users created in SfB Online using the new SIP domain ( cannot see presence or IM with users On-Prem (

Test Users:

User Location SIP Domain SIP Address
Alice Wonderland On-Prem
Peter Parker Online
Jack Bauer Online
Jeremy Silber Federated User Hidden to protect the innocent Hidden to protect the innocent

Symptoms: (Screenshots Below per Scenario)

  1. On-Prem to Online:
    • Alice Wonderland ( – Homed On-Prem) can see presence and initiate IMs with Jack Bauer ( – Homed Online)
    • Jack Bauer ( – Homed Online) can receive IM’s from Alice Wonderland ( – Homed On-Prem) and reply to IM’s, but presence for Alice is not available.
      Image 1      clip_image004[10]
  2. Online to OnPrem:
    • Jack Bauer ( – Homed Online) can sign-in to SfB using the new SIP namespace
    • Jack Bauer ( – Homed Online) can see presence and initiate IM’s with users homed online within the same tenant (both SIP domains) and vice-versa.
    • Jack Bauer ( – Homed Online) can see presence and initiate IM’s with federated domains and vice-versa
    • Jack Bauer ( – Homed Online), CANNOT see presence or initiate IM’s with Alice Wonderland ( – Homed On-Prem)
  3. Online to Online:
    • Peter Parker ( – Homed Online) can see presence and IM with everyone.


From within Snooper, we can see a “504 Server Time-out” error, when Jack Bauer tries to initiate an IM with Alice Wonderland.



Naturally, my first troubleshooting step is to Google the error. “Cannot route From and To domains in this combination”;cause=”Possible server configuration issue”;summary=”The domain of the message that corresponds to local deployment (internal) is not shared with remote peer.” Which doesn’t return anything of value. Hence my writing this article.

In previous conversations with Microsoft, they have stated something to the effect of all Online SIP Namespaces must also be valid On-Prem SIP Domains. Meaning both and should be added as valid SIP domains in the Topology Builder of my On-Prem SfB Deployment. While the error message is kind of vague and cryptic, it sounds plausible that this could be the issue.


To test this theory, I figured that I would need to add as an “Additional supported SIP Domain” within the topology builder.

I wanted to test each stage individually to see when exactly this would start working.

  1. Add as supported SIP Domain. Publish Topology : No change
  2. Update internal Front End Certificates: No Change
  3. Restart Front End Service and Access Edge Service after successful replication: No Change
  4. Update Access Edge Certificate: Success

Updating the Access Edge Server certificate to include “” is the step that made this start working.

This made me think, do I really need added as a valid SIP domain in the On-Prem topology, or does it only want the certificate? So, I removed from the topology builder, but left the certificate in place on the Edge server. What do you know, it still worked! Presence was still available and IM continued to work.

To double check, I added the old certificate without the SAN entry.  Again IM/P broke.  I then re-added the new cert with the SAN entry and voila, again IM/P started working.

Updating the Access Edge certificate to include a SAN entry for the new SIP namespace ( works, without having to update the entire Lync/SfB Topology.   Albeit, what works…isn’t always supported.

DNS CNAME and SRV records for point to SfB Online.  Which is exactly what I wanted.


From a support perspective, Microsoft states (Although I’m still looking for an official statement), that any SIP domain used in SfB Online, must also be a valid SIP domain in the Lync/SfB On-Prem topology.  Which makes sense.  If you update the topology builder to include the new SIP namespace, and re-run the certificate wizard on the Edge servers as you’re supposed to, the new SIP namespace will automatically be included as a new SAN entry.  As this is an expected outcome of adding the new SIP namespace to the topology, this is what Microsoft tested, and therefore supports.

While it’s always my recommendation to stay in a supported scenario, it does seem plausible to just update the Edge server certificates with the new SIP SAN entry, without updating the entire topology.  I’d also bet that updating the certificate really is the only step necessary.   Of course, I will admit that I did not test all functionality. Only IM/P in this scenario with a single Edge server.  Further testing may prove other workloads don’t work as expected.

UPDATE 4/5/2017 – In reading through the new SOF material, specifically “3 – Design-Cloud PBX, PSTN Conferencing and Client – Design and Migration Document”, I came across the Hybrid Deployment Prerequisite section, Table 38.

Table 38 – Hybrid Deployment prerequisites
Question Answer Comments
SIP domain(s) in the on-premises Lync Server
or Skype for Business Server deployment
Verify the list of SIP domain(s) matches the list of Office 365 tenant’s validated domain(s) for Skype for Business Online.

If not, plan and document the effort to ensure SIP domain(s) between on-premises and the cloud are in- sync as there are impacts to certificates and DNS records.

Office 365 tenant’s validated domain(s)
enabled/planned for Skype for Business Online
Verify the list of Office 365 tenant’s validated domain(s) for Skype for Business Online matches the list of on-premises SIP domain(s).

If not, plan and document the effort to ensure Office 365 tenant’s validated domain(s) for Skype for Business Online are in-sync with on-premises SIP domain(s) as there are impacts to external DNS configuration to verify domain ownership.

Details of on-premises Edge server’s Access
Edge certificate (issuer, subject name,
subject alternative name(s), etc.)
Verify the certificate is issued by a public Certificate Authority (CA), or a CA listed in the list of Unified Communications certificate partners.
Verify the list of subject alternative name(s) contains access edge FQDN(s) for all SIP domain(s) intended for the hybrid relationship. 

If not, plan and document the effort to reissue the certificate to include subject alternative name(s) to support all SIP domain(s) in the hybrid relationship.

While not entirely the same use case, there is also a reference to this in the “Plan for Skype for Business Cloud Connector Edition” documentation  “You will need to add for every SIP domain and the name of the access Edge pools per domain”.

Further, in discussing this with a colleague at Microsoft, it would seem that there is logic in CCE that requires a SAN entry for “” on the Access Edge Pool certificate for every SIP domain in the environment.  This is used as part of the authentication/validation check that permits communication from SfB Online to CCE.  It would seem this same logic is used for authentication/validation in a Hybrid deployment as we can see here.


Next…In certain scenarios, unsupported ones of course, I can see where adding the SIP namespace On-Prem would not be possible.  Let’s take the scenario where we have an acquisition.  2 separate Active Directory Forests, with the assumption they will stay separate for some time.  We can’t share the SIP Namespace between 2 On-Prem Lync/SfB deployments.  Plus, we want to start moving workloads to the cloud.  Well, Azure AD Connect can be setup to sync both forests to the same O365 tenant (Supported).  Exchange Hybrid can be configured in both forests to sync to the same O365 tenant (Supported).  Why wouldn’t we want Lync/SfB setup in hybrid with the same O365 tenant as well (unsupported).  I know dual-Hybrid in Lync/SfB is not supported, but now I’m curious if we can make it work.  Can we use the same workaround used here, to trick SfB Online into working in this unsupported configuration?  We’re out of time for today though, so that will have to wait for another post.  Stay Tuned!

4 Replies to “Adding a “Cloud Only” SIP Domain in a Skype for Business Hybrid World

  1. Hi Jeremy and thanks very mutch for this post.
    I am in the sami situation, i have 2 sip domain on premises and 20 online and I can’t make the hybrid for the reason you wrote here.
    Do you think that something will change in the future?
    Wich SAN should I add into the certificate? for all domains? Are you sure I can let DNS points to the cloud?

    Thanks in advance.

    1. Hi Joe,

      I’m unaware of any changes coming that would lead me to believe this will change.

      You will need to include “” for all 20 online only domains to your OnPrem Edge certificate. This is the cert that is installed on the Access Edge.

      For any SIP namespace that resides entirely in the cloud (aka all users are homed online, which sounds like 20), you can continue pointing DNS to the cloud. For any SIP namespace that has users homed OnPrem (sounds like 2), DNS will need to point to the OnPrem Edge.



  2. Hey Jeremy,

    Great post! This just helped us figure out our exact issue.

    We have been happily running in a split scenario for some time (almost a year) when all of a sudden it stopped working. Ironically it happened just as we were making some other changes so it became quite the red herring in our search for solutions.

    @Joe above, the only thing we had to do was add in the proper SAN to our cert. Once that happened the federation started working almost instantly.

    Long story short, looks like there are some rolling updates happening so this might become a pretty popular article!

    Thanks for helping the community out!


  3. Thanks Jeremy and Ben
    I get a new certificate with all the san of the online domains on my edge and everything works for now.


Leave a Reply

Your email address will not be published. Required fields are marked *