I was helping a customer look at Enterprise Voice for Office 365 Skype for Business users recently. In Australia, we don’t have PSTN Calling available unfortunately and so a On Premise Enterprise Voice solution is required if you want to host your users in Skype for Business online. Fortunately for my customer they had a Lync Server 2013 Enterprise Voice environment and we could leverage that service for cloud users to make calls.
What I didn’t know a lot about was how Dial Plans work in that scenario. When a user is moved to the cloud, and you want them to retain Enterprise Voice capabilities, you need to enable Hybrid Voice in your on premise Lync / Skype environment and also need to tell Skype for Business Online the same (that you are using Split domain). There is a fair bit of planning information on the deployment process, this link should help to get you started https://technet.microsoft.com/en-us/library/jj205403.aspx.
Anyway, one of the issues we encountered when moving users to the cloud, users who were using Enterprise Voice on premise successfully, was that when they moved to the cloud Dial Plan functionality was no longer working. Dial Plans is one of those nice to have features that helps to massage phone numbers that are typed in the Skype client keypad into a number in the E164 format. For example, if I typed 1234 as a 4 digit extension, a Dial Plan would convert that 4 digit number into a E164 format that is globally routable on the PSTN and makes sense for my organisation i.e. +61212345678. The numbers 1234 cannot be routed on the PSTN but this might be a number format our users are used to typing when calling someone in the organisation. So it is a pretty handy tool.
Some other examples where Dial Plans are handy are handling 13 numbers i.e. 1300 123456 – +611300123456 (notice no spaces), or 134567 to +61134567.
So when a Dial Plan is not working and I type in 1234, the number isn’t massaged at all and in fact my client realises that and so doesn’t let me place the call. I don’t have a matching normalisation rule. So for my customer, this was happening. What we did know was if we typed in a phone number in E164 format into the keypad, the number was successfully able to be routed (so call routing was working from a raw telephony point of view).
So my initial thoughts were, what’s happening are Dial Plans in the cloud not available? Let’s go digging and have a look at my cloud users to see what settings are assigned to them! So using Get-CSOnlineUser I had a look at my test user email@example.com. Izzy had a Dial Plan setting of “AU“. Ok the plot thickens, let’s look at that Dial Plan see what we can determine about it.
So I had a look at Get-CSDialPlan for the AU dial plan to see what it contained. What I found was there is a lot of normalization rules in there, and they look to be largely what I was expecting to see in place in the cloud.
You can expand out the Normalization Rules to have a better look. Do that with the select –ExpandProperty option.
Interestingly the second option (AU Long Distance Dialing Rule) will break calling 000 and will convert to +6100, so something to work on there (thanks Bill).
So looking at the online “AU” dial plan the rules look good, so number manipulation SHOULD be working. While the rules are pretty basic, a number in the format 02 12345678 should be converted to +61212345678. But for some reason, at my customer’s location the Dial Plan was not taking.
So where to now? Lucky a good colleague of mine, Agus, said you need to remember there is a Tenant setting that can be configured to tell Office 365 to use the on premise dial plans. Ahhh, so let’s go check that setting. Now as it turns out, by default we set the UseOnPremDialPlan to $true. This was the case in my customer’s tenant as well. So I now knew that I needed to look at why the On Prem dial plans were not taking.
When I had a look at the Dial Plan setup in my customer I noticed that they had three Dial Plans, the Global Default Dial Plan, a Site targeted Dial Plan and a test User scoped Dial Plan. All the rules were in the Site scoped dial plan and nothing was in the Global Dial Plan. So this was interesting. My customer and their associated User account did not have a User scoped Dial Plan assigned, and all the Dial Plan rules they had setup were located in the Site targeted Dial Plan.
So what we found was as the user who is using CloudPBX, having been hosted in the cloud on Skype for Business Online, now has no understanding of Sites. This of course means that if we put all our rules in a Site scoped dial plan then those NormalizationRules will not be assigned to Office 365 Skype for Business users. So the trick for this scenario was to either update the Global default dial plan or create a new Office 365 Users Dial Plan (Sydney_Users in my lab example) and assign it to my pilot users who were living in the cloud. In our case I went with creating a new User scoped Dial Plan.
I used the cmdlet get-csuser sip:firstname.lastname@example.org | Grant-CsDialPlan -PolicyName “Sydney Users” to assign my test user Izzy the “Sydney Users” dial plan. I then confirmed the DialPlan had been assigned with Get-CSuser.
Once the dial plan had been assigned I then re-signed into Skype for Business. I was then able to have my numbers manipulated as per a normal Dial Plan is expected to work, the difference being my user account was managed by the cloud.
Just for interest I thought I’d check in the UCCAPILOGS what came through. I confirmed that the Sydney Users dial plan rules were being downloaded.
You can see here that I am signing into SfB Online.
So the interesting lesson for me was, that out of the box a tenant is configured to use the OnPrem Dial Plans, and that cloud based users will not understand the concept of sites. So you will need to assign user scoped Dial Plans to them. The other interesting thing I need to explore is if the UseOnPremDialPlan setting was set to False, would the “AU” online Dial Plan worked?
Well I hope this helps and as always, test, test and test.