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: https://www.thomasjuhlolesen.dk/wp-admin/post.php?post=43&action=edit
Second on is OPCH (OnPremise configured Hybrid)
The full documentation for configuring this is found here:https://docs.microsoft.com/da-dk/skypeforbusiness/skype-for-business-hybrid-solutions/plan-your-phone-system-cloud-pbx-solution/enable-users-for-phone-system
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 onmicrosoft.com user. But there is a workaround
First you do a ping to webdir.online.lync.com
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
52.112.192.14 lyncdiscover.SIPDomain.com
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 url.xxx.com to the command . The admin URL is retrieved from the legacy SFB Portal – and the use it but substitute webdir with admin.
Example:
new-csonlinesession -credential $cred -overridediscoveryurl admin0e.online.lync.com
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
$cred=Get-Credential
$url="https://admin0e.online.lync.com/HostedMigration/hostedmigrationService.svc"
Move-CsUser -Identity username@contoso.com -Target sipfed.online.lync.com -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:
get-cspstnusage
To get more detail run this:
(Get-CsPstnUsage).usage
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 username@Sipdomain.com
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.<sipdomain.com> 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. webcon.contoso.com 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. _sipfederationtls._tcp.sipdomain.com 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.
