As part of my job at Nectar Corp, I'm always looking at ways to get call detail information from various Microsoft-based UC telephony components. It's easy to get a wealth of detail from an on-prem deployment of Skype for Business, using either direct access to the SfB monitoring databases (for historical info) or via the Skype for Business SDN dialog listeners (for realtime call data). As mentioned in my recent blog post, the same cannot be said for Office 365 UC workloads such as SfB Online and Teams.
Nectar has a tool that relies on knowing when a call starts and stops in realtime so we can gather information from various network components as the call is happening. Nectar uses the SfB SDN interface for this realtime info. Since both SfBO and Teams lack ANY sort of call data API, we have to resort to other methods to learn about realtime calls.
A Nectar customer has deployed several Skype for Business Cloud Connector Edition (CCE) instances to provide on-prem PSTN call routing for SfB Online users. CCE is the precursor of Teams Direct Routing, and it does essentially the same thing but in a WAAAAAAY more complex manner. It consists of several pre-packaged VMs running a vastly slimmed down Skype for Business environment.
We were in discussions with the customer to see if there was any way we could get realtime call info from the CCE instances, by installing the Microsoft SDN Dialog Listener on any of the CCE VMs. Nobody seemed to know for certain, so I elected to setup a CCE instance of my own to run some tests. The question I was trying to answer was:
Nectar has a tool that relies on knowing when a call starts and stops in realtime so we can gather information from various network components as the call is happening. Nectar uses the SfB SDN interface for this realtime info. Since both SfBO and Teams lack ANY sort of call data API, we have to resort to other methods to learn about realtime calls.
A Nectar customer has deployed several Skype for Business Cloud Connector Edition (CCE) instances to provide on-prem PSTN call routing for SfB Online users. CCE is the precursor of Teams Direct Routing, and it does essentially the same thing but in a WAAAAAAY more complex manner. It consists of several pre-packaged VMs running a vastly slimmed down Skype for Business environment.
We were in discussions with the customer to see if there was any way we could get realtime call info from the CCE instances, by installing the Microsoft SDN Dialog Listener on any of the CCE VMs. Nobody seemed to know for certain, so I elected to setup a CCE instance of my own to run some tests. The question I was trying to answer was:
Can you get call data out of a CCE instance using the MS SDN Listener service???
TL;DR: No.I had built myself a fancy new work PC at home that I figured would be ideal for this test. I put in 32GB of RAM so I could spin up VMs as needed for my tests, and this would be an excellent test OR SO I THOUGHT!
My first hurdle was that I needed a virtual machine host that would host the VMs required for CCE. In other words, I needed to run VMs from within a VM.
Just like the movie, except much more boring. |
...OR SO I THOUGHT (AGAIN). I ran into issues right off the bat when installing the CCE components, where most of the CCE PowerShell commands were available. Thanks to a workaround from Shawn Harry, I was soon off to the races and installing CCE.
...BUT NO! FOILED AGAIN!!! There are a number of steps to deploy a CCE instance, most of which require running various CCE PowerShell commands. One of these commands performed a hardware check to make sure the Hyper-V host had enough resources to run the required VMs. I was rudely informed that my super-awesome, brand-new workstation PC did not have enough memory, processor cores or disk space to run CCE.
Keanu is sad, and so am I |
The big red, failure message that PowerShell spit out at me helpfully included the path to the script that did the hardware check:
C:\Program Files\WindowsPowerShell\Modules\CloudConnector\Internal\MtCommon.ps1
A quick review of that script, and a few edits to the $logicalProcessorsCount, TotalPhysicalMemory, FreePhysicalMemory, and FreeDiskSize variables and the script was convinced that I had a super-server with 999999999999 MB of memory, diskspace and processor cores.
With a few more tweaks here and there, I was finally able to get a full Skype for Business Cloud Connector Edition instance running in my modest home lab. Since the CCE environment consists of several standard Windows VMs, I was able to login to them and attempt to install the SDN Listener on what I hoped would be possible candidates: the CMS or the Mediation VM.
Neither of those were running as a full front-end server, but I still held out hope. The CMS VM was running the Centralized Logging Service Agent, File Transfer Agent and Master/Replica Replicator Agents. The Mediation VM was running the Centralized Logging Service Agent, Mediation service and Replica Replicator Agents.
I attempted to install the SDN Listener on both those VMs and got the following message:
And there you go. The answer to a question that nobody else was looking for. No, you can't run SDN on any CCE VM role.
Hope you're happy @ucomsgeek.
With a few more tweaks here and there, I was finally able to get a full Skype for Business Cloud Connector Edition instance running in my modest home lab. Since the CCE environment consists of several standard Windows VMs, I was able to login to them and attempt to install the SDN Listener on what I hoped would be possible candidates: the CMS or the Mediation VM.
Neither of those were running as a full front-end server, but I still held out hope. The CMS VM was running the Centralized Logging Service Agent, File Transfer Agent and Master/Replica Replicator Agents. The Mediation VM was running the Centralized Logging Service Agent, Mediation service and Replica Replicator Agents.
I attempted to install the SDN Listener on both those VMs and got the following message:
And there you go. The answer to a question that nobody else was looking for. No, you can't run SDN on any CCE VM role.
Hope you're happy @ucomsgeek.