The Caveats of OPCH

Yeah sorry bout the title… thanks MS for the lovely OPCH acronym BTW 🙂

As Microsoft recently announced the End-date for SKYPE for Business Online, a lot of organisations are now in the process of moving their Onprem SFB Enterprise voice workload to SFBOnline, in order to achieve a more smooth migration to Teams with Direct Routing before getting forced into a big bang scenario.

The process of moving users to CloudPBX in SFBO is well described, in terms of prerequisites and process – having done it many times although I always stumble on some minor things that people (including myself) tend to forget – so I decided to put together a collection of caveats to turn to if “stuff” fails.

Let me allign the process and the documentation.

You have 2 ways of achieving Onprem PSTN connectivity for SFB Online – either, First one is CCE (Cloud Connector Edition) i will not go into that – i have covered CCE in another article here:

Second on is OPCH (OnPremise configured Hybrid)

The full documentation for configuring this is found here:

Now to the issues – this is a work in progress, so i will add more in the future.

Unable to signin through SFB Control Panel

When setting up Hybrid most important step is running the Hybrid Wizard in SFB Control Panel – in many cases The Global admin user has a vanity domain in the UPN – and due to the way autodiscover works this fails, and easyfix is to switch to user. But there is a workaround

First you do a ping to

Then open your hosts file at c:\windows\system32\drivers\etc\hosts with your favorite editor and add the following lines (substituting your IP and SIP domain of course)

#Hybrid workaround for SSO

Unable to connect SFB Online powershell

When you run new-csonlinession it throws “Unable to discover PowerShell endpoint URI” back at you.

Solution is easy – you must add -overrideDiscoveryURL to the command . The admin URL is retrieved from the legacy SFB Portal – and the use it but substitute webdir with admin.


new-csonlinesession -credential $cred -overridediscoveryurl

Unable to Move users in powershell

This one is also related to the way powershell and how autodiscover works.

If you just follow the deployment guide blindly, you probably use the wrong URL

Again you determine you specific admin url from the Legacy portal, and the adding it as a parameter like this:

Here we need to add the parameter


Move-CsUser -Identity -Target -Credential $cred -HostedMigrationOverrideUrl $url

Unable to Dial Out

If users receive the error “Call was not completed or has ended” check the Tracing log with snooper, and look for 403 Forbidden.

If everything else works, you probably need to ad a VoiceRoutingPolicy to the user, containing the relevant PSTN Usages – If the only existing Voicerouting policy Onprem is global and it contains no usages, users are unable to dial-out.

2 options here – i prefer number 2.

First option, You could modify the Global Voiceroutingpolicy to contain the usages –

Second option – create new voice routing policy and assign to the users that are going to be moved to CloudPBX – this will also work for already moved users (after Dirsync has taken place)

To get the current PSTN usages in you onprem SFB run:


To get more detail run this:


Now create a brand new policy and include the relevant usages:

New-CSVoiceRoutingPolicy -Identity HybridVoice -Name Hybrid -PSTNUsages "Local", "Long Distance"

And assign it to the user(s) in question.

grant-csvoiceroutingpolicy -policyname HybridVoice -identity

No Presence for federated partners

Its important to pay attention to the federation settings, if you dont do anything external federation is of by default in most tenants – also its important to reflect any special settings from the onprem federation settings.

The guidelines are:

  • Domain matching must be configured the same for your on-premises deployment and your Office 365 tenant. If partner discovery is enabled on the on-premises deployment, then open federation must be configured for your online tenant. If partner discovery is not enabled, then closed federation must be configured for your online tenant.
  • The Blocked domains list in the on-premises deployment must exactly match the Blocked domains list for your online tenant.
  • The Allowed domains list in the on-premises deployment must exactly match the Allowed domains list for your online tenant.
  • Federation must be enabled for the external communications for the online tenant.

One way Presence

This one is down to the fact that when i hybrid users homed in SFBOnline, needs to know the federation path to get two way presence. This was not a part of the standard DNS requirements for SFB Server 2015 – but is listed in the prereqs documentation for hybrids mentioned at the beginning of this article.

The updated requirements are as follows:

DNS settings

When creating DNS records for hybrid deployments, all Skype for Business external DNS records should point to the on-premises infrastructure. For details on required DNS records, please refer to DNS requirements for Skype for Business Server.

Additionally, you need to ensure that the DNS resolution described in the following table works in your on-premises deployment. (If you already configured federation for on-premises, then you most likely already have these.)

DNS record
Resolvable by
DNS requirement
DNS SRV record for _sipfederationtls._tcp.<> for all supported SIP domains resolving to Access Edge external IP(s)
Edge server(s)
Enable federated communication in a hybrid configuration. The Edge Server needs to know where to route federated traffic for the SIP domain that is split between on premises and online.
Must use strict DNS name matching between the domain in the user name and the SRV record.
DNS A record(s) for Edge Web Conferencing Service FQDN, e.g. resolving to Web Conferencing Edge external IP(s)
Internal corporate network connected users’ computers
Enable online users to present or view content in on-premises hosted meetings. Content includes PowerPoint files, whiteboards, polls, and shared notes.

So basically the fix is to create 2 internal DNS records, resolvable by both clients, and the internal interface of the EDGE server.

1.  Being an  exact copy of the public SRV record for federation. pointing to external access edge FQDN on port 5061

2 DNS A record for the access edge FQDN resolving the PUBLIC IP of the access edge interface.

3 DNS A record(s) for Edge Web Conferencing Service FQDN also resolving external IP Recently however this was added to the online planning documentation.

So i guess this is now to be considered a requirement, although in non splitbrain DNS scenarios you would never know you missed it 🙂

This is a work in progress, more will follow.

Leave a Reply

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