During the deployment of a slave CCE appliance when it came to the last step I received an error message: We failed to run Publish-CCAppliance.
I waited around 5 minutes and ran the step again and it completed successfully and the appliance started handling calls, I was unable to see what the Management service was doing or why the automated process wasn’t able to handle it but I’d thought I would share and reassure people that running it again worked.
During a recent Sonus Cloud Link deployment integrating Skype for Business Online with Cisco Call Manager I ran into an issue with certain calls failing. As the customer were piloting the system we were not yet removing users existing Cisco extension but rather forwarding it to their Skype number.
If Cisco users called the Skype number directly it would work but if they called the forwarded extension it would fail, strange.
So first step was to look at the Sonus logs to see if I could spot anything, on the working call everything looked normal
The only difference with the failing call was the addition of the Diversion header entry.
Now I’d found a difference it was time to see if I could change the forwarded calls header to be the same as the working call. Since we were using the Skype Cloud Connector Edition we couldn’t make any changes on the Skype side as they’d be lost following any update.
Luckily we were using a Sonus to route calls between the two, so I created a Message Manipulation Rule under Message Rule Tables
I then created a header rule
Which then had an action of Remove for the header name of Diversion, I didn’t add any conditional access expression.
After creating the rule I added it as an Outbound Message Manipulation entry on the Skype CCE signalling group
After which forwarded calls worked as expected. I’m not sure why the Skype CCE or Skype Cloud PBX did not like the diversion header but the customer was happy with the result.
Having just completed my first highly available Sonus Cloud Link I just thought I would mention an error message I came across when installing the second appliance.
The Sonus Deployer tool showed a very nice red error message saying the Powershell module is not ready
This was also shown in the underlying PowerShell window
I had seen a similar message during the installation of the Skype Online Powershell module when you try to load it without having restarted, however the ASM server had been rebooted and I was able to load Skype for Business Online PowerShell module and connect to the tenant.
If you read all of the notices and guides you will see mention that the length of time it takes to deploy the second appliance is dependent on the connectivity and speed of the first, which led me to check the first appliance.
I then discovered that the Primary appliance actually had been configured as standalone! It was then a case of redeploying the CCE configuration, this time ensuring the HA Master option remained selected and then afterwards the second appliance was able to progress.
Lesson of this story, ensure you get the configuration correct on the Master appliance and make sure it is saved!
The use of regular expressions for dialling and address book normalization have been long been established in the Microsoft Communications product line, but they are not always the easiest rules to construct and then test, especially when doing more advanced manipulation.
Lync 2010 introduced the dialling rule builder in the Control Panel which would construct basic regex rules for you as well as provide a method for testing them (along with the respective powershell commandlets), but the testing of address book normalization has always relied on using Abserver.exe with the -testPhoneNorm switch. Unfortunately, as pointed out by Greig (https://greiginsydney.com/vale-company_phone_number_normalization_rules/) this has been removed in Skype for Business Server 2015 however as he points out there doesn’t seem to be any test-cs commandlet to actually test these rules unlike for voice routing.
Additionally, as blogged by Ken Lesko (http://ucken.blogspot.co.uk/2015/05/skype4b-address-book-normalization.html) the address book normalization rules are now created via powershell rather than saved in the old Company_Phone_Number_Normalization_Rules.txt
So, how do we test these apart from watching the event log and seeing which numbers do not normalize correctly?
Well, I’ve prepared a sample powershell script that will compare a number against all of the normalization rules to see if there is a match, and if there is it will output those details whilst also attempting to apply the transformation so you can see the final normalized number.
Now I’ve only tested this rule against a few simple normalization rules so will be interested in hearing how it works against more complicated rules or if you can refine it but hopefully it provides a little direction on how it could be done.
Write-host "Enter telephone number to check"
$input = read-host
foreach ($rule in $normrules)
$test = [regex]"$testregex"
if ($test.Match($input).Success -eq "true")
$normalizednumber = $input -replace $rule.Pattern,$rule.Translation
Write-host "Priority: "$rule.Priority
Write-host "Name: "$rule.Name
Write-host "Description: "$rule.Description
Write-host "Pattern: "$rule.Pattern
Write-host "Translation: "$rule.Translation
Write-host "Normalized number: " $normalizednumber
Now that Skype for Business server has introduced the ability of migrating Online users I’d thought I’d see how the process works in my lab
Note: As I discovered, the same restrictions regarding management of Domain Admin/Protected group members applies here too, this means you get a nice error message if you try and use the Control Panel to move a Domain Administrator.
First we find our user
After selecting the user, you follow the same procedure as if you are moving a user between pools, in this case you instead select the Move selected users to Skype for Business Online instead
Note: During testing I migrated a user homed on a Lync Pool straight to Skype Online without having to migrate to Skype For Business server first.
Nice reminder that you need to have licensed the user first in the Office 365 portal, otherwise they won’t be able to sign in
If you have not already signed into Office 365 from the Home section of the control panel you will be prompted to sign in before you can move the user(s)
Now we get the last confirmation prompt
Here we can see the user has been moved, although still reporting as LyncOnline!
When you try and edit the user in the on-premise control panel you see a similar screen to Lync
Skype for Business Server has brought in limited connectivity between on-premise hybrid deployments and their Skype Online counterparts via the Skype for Business Control Panel.
Now, on the home screen you have the option to log into Office 365, in Lync integration to Office 365 was via powershell only.
When you click sign in, you get prompted for username and password, which I like as Office 365 admin accounts may not be linked to on-premise accounts for single sign-on
And then you get confirmation
You can change the account you’ve signed into if need be
Setting up Skype Hybrid is now possible from the control panel
Now, my Lync 2013 deployment was already configured for Hybrid so all the checks passed, hopefully I’ll get screenshots from a new hybrid and will be able to update this