Deploying a Sonus Cloud Link CCE

I recently was working on a Sonus v2 Cloud Connector Edition (CCE) working with the new hardware, testing the install, etc. when I ran into a deployment snag. In general, I find the there are a lot of post and blogs about when to use CCE and when you cannot, but few on how to properly deploy CCE let alone the Sonus version.

I decided to show a walk through on the process I used to deploy, why I used the names/options that I did, and the errors and gotchas I ran into.

To start, I am working with a Sonus SBC 1k Cloud Link with the CCE package installed. From a Sonus part number, that would be SBC-1K-SIP-E-CL. The Cloud Link version includes an imbedded Windows 2012 R2 Server with 32 GB of RAM, dual Xeon quad-core 1.7GHz (that’s 8 physical cores. 16 logical), and a 512GB SSD drive. All-in-all, not a bad server and very capable of running the “small” CCE build. That, along with the nicely integrated SBC makes this solution simple…as long as you know the answers to the questions.

Starting off the build of the ASM is not any different from other ASM buildouts – the only difference being the Task option on the Cloud Link version shows Office 365™ Cloud Connector Edition vs. Skype ™for Business Survivable Branch.

Setup CCE      Setup SBA

Selecting the Office 365™ Cloud Connector Edition brings you to the beginning process. The very first thing that needs to be done is getting the ASM an IP. This IP is the IP of the Hyper-V host. It is not meant to be domain joined, and the option is not present. If you really wanted to change the name of the server you could, but even that is not required as again – it is simply the host computer for the VMs.

It is critical that the Remote Desktop enable option is changed to Yes as there are tasks that must be completed from the host server. The server should also be able to be reached from within your network – whatever that means to you. DHCP is an option – I am old school and believe all servers should have a static IP but again, whatever works for you. For me this was my internal server VLAN, internal DNS, internal everything as I wanted to be able to easily manage the server.

ASM Network

After you have configured the IP and RDP, the next step is to create the certificate for the Skype Edge server. This is where you must be careful to enter the correct names. There are references to the deployment requirements on TechNet here Plan for Skype for Business Cloud Connector Edition although to me, Sonus solution hid the configuration too well making things unclear. Specifically, step four is where you configure the settings on the CCE including the site name for the CCE. This site name is also your edge pool name – a name which must be a CN or SAN.

In my case, I thought I would be witty and use as the common name. The CSR request simply stated the edge server public FQDN and left it up to me to complete. The wizard also complained if SIP was not in the name so that had to be there too which was a bit confusing since the DNS name would never point there. In the end, the fields looked like the following:

Cert Config,,

In the SAN list make sure you have your SITE name (exiting or the name you plan to use), SIP, and optionally another name to which you would be tied to the service (although 100% unnecessary). Remember to configure all of the DNS records publicly to make sure things route.

Once the CSR has been created, have it issued by your favorite PUBLIC CA, and make sure your favorite public CA is a mainstream one – one whose roots are part of the base Windows 2012 R2 OS. In my case, I used DigiCert ( – an awesome go-to CA who works flawlessly.

Step 3 is to import (paste) the resultant certificate. The cert should be in DER format and in the case of DigiCert simply select the option on their page to download copy/paste under Download Certificate. That will expose three text blocks, the one you want will be the top block for your certificate where you can simply copy and paste the result.

DigiCert Copy and Paste

X.509 Paste

You are now ready to begin the configuration of your deployment and a critical junction. Incorrect information going forward means clicking Reinitialize on the ASM and starting over. 😊 Below is a summary of the deployment and the options selected.

CCE Network Summary

In this list, there are some key components that we need to complete. It is also important to note that the defaults are there just because but more than likely mean nothing to your deployment. The first thing you need to identify is the CCE Site Name. Again, this will be the pool name of your edge and will need to be in your certificate.

The external network gateway is in relation to the second NIC of the Edge server – no different from the second NIC of a traditional Edge server. This NIC cannot be on the same VLAN as your internal networking but like a traditional Edge, NAT is supported. In my example the external is a 172.x.x.x/24 address, I am using public Level3 DNS, and because it is a private IP I am listing the Edge server External IP.

The internal network is where the internal NICs on the servers will live. There are three switched networks on the servers – Internet, Corpnet, and Management. The Internet switch and NIC live on the Edge server while the Corpnet and Management live on all the other servers. The Management virtual switch is internal only – for server to server communication and the IP scheme is with no default route. The Corpnet is the internal network where the Hyper-V host lives as well as all other internal servers (again, in my network the server VLAN).

Hyper-V Virtual Switches

The information you are entering for the Internal Network is used partially for the configuration – and partially still a mystery. The Gateway is obvious and is the gateway used for the Corpnet NICs however the Internal DNS is not used (the four servers all use the AD server as they should). The four IPs of the VMs themselves are also Corpnet IPs and in my case, were 10.x.x.10, 10.x.x.20., 10.x.x.30, and 10.x.x.40 – but as long as they are unique and valid, they can be whatever you want.

One you have configured and saved the CCE configuration move on to Step 5 – Prepare CCE. In this process the data that was previously entered is saved locally to the Hyper-V host (C:\UX\CCE\CcAppliance) and will be used by the next PowerShell commands.

Assuming no errors and all is ready, RDP to the Hyper-V host. If you have not already, set the Administrator password of the ASM via the web GUI of the Sonus at Settings | Application Solution Module | Change Admin Password. Drop the option down to User Configured, enter and confirm a unique strong password, and click OK. Using \Administrator and the Password you just created, RDP to the ASM address set in step 1 above.

One on the server, start a PowerShell command with elevated admin rights. From within the prompt, start the process by entering Register-CcAppliance. You will need to set admin passwords, recovery passwords, and enter your admin login for your O365 tenant. Assuming you have the correct rights the process will complete creating an appliance in the cloud which you can see using the Skype for Business Online PowerShell command Get-CsHybridPSTNAppliance.

The final stage of the process is the installation and configuration of the VMs. This entire process is completed with the simple command Install-CcAppliance. Using previous configuration entries saved off to the INI and the certificate (also saved off), the nest steps are hands free, it just takes time. This is where I ran into my errors due to the lack of pool name in the edge certificate. During the creation process the Edge sever is started and an error is thrown which appears to be a Cyphers issue:

Event ID 14397 – A configured certificate could not be loaded from the store.


Should you run Get-CsCertificate you will see your public certificate associated with AccessEdgeExternal, DataEdgeExternal, and AudioVideoAuthentication. An internal certificate will also be seen and associated with Internal. All of this appears to be valid and yet the service will not start. The key to finding that it was a pool name issue was manually assigning the certificate to the three external services again using

Set-CsCertificate -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -Thumbprint xxxxxxxxxxxxxxxx -Force

Doing so revealed the error that was not a name on the certificate and that’s when the lightbulb appeared. The fix is to undo everything and start over (unfortunately) which includes Unregister-CsHybridPSTNAppliance, OPTIONALLY Remove-CsHybridPSTNSite, and Reinitialize the ASM in the Sonus GUI.

Once the CCE appliance is configured, make sure to run through the SBC configuration - otherwise there will not be anything to link the calls to. The CCE does not use TLS so an SBC certificate is not required, only basic integration configuration as described on the Sonus site (and identical to any other SBC config).


Update 2/24/2017

Internal DNS on the Internal NIC settings

As mentioned in the comments (thank you Jason) the DNS entry/mystery is solved as the internal DNS added during the CCE Setup page is added as a forwarder. Why not just use root hints - none from what I can see in v1 but future version may rely on knowing the DNS of internal servers.

DNS Forwarders on CCE DC

SIP Domain Name on the Certificate

The addition of the SIP.DOMAIN.COM to the certificate - that mystery was resolved as well (thanks Carolyn). When a CCE user makes a call to the on-premises edge, a check is made against the edge for SIP.domain for the sip domain of the user making the call. This is how the CCE authenticates/permits this call from the CCE online user to the on-premises edge. If you don’t have SIP in the SAN name then the outbound call for the user will fail with the following error:

504  Server time-out

ms-diagnostics:  1017;reason="Cannot route From and To domains in this combination";cause="Possible server configuration issue";summary="The domain of the message that corresponds to remote peer (external) is not shared between local and remote deployments";external-domain="";external-type="domain-type-local";internal-domain="";internal-type="domain-type-local";source="";OriginalPresenceState="0";CurrentPresenceState="0";MeInsideUser="No";ConversationInitiatedBy="0";SourceNetwork="0";RemotePartyCanDoIM="No"

Final Certificate Requirements

In the end I updated my certificate to only include the required DNS names and to lessen the confusion. The certificate in the end has the CN of the site as well as the site and sip as a SAN.,

Microsoft has released July 2014 CU for Lync Phone Edition

We are now officially into the 3rd quarter of 2014 and thus into the third round of patching. I know we did not see patches for Lync Server 2013 in the 2nd quarter, but one can assume the trend will not hold and patches will be coming soon. As a teaser Microsoft has released the Lync Phone Edition (LPE) update for Q3, their links are found below. It is always recommended to remain up-to-date with LPE patches regardless of the fixes included.

In this iteration of LPE a Daylight Savings Time (DST) issue is resolved for Egypt and Morocco…nothing exciting but keeping the phones up-to-date ensures you will not run into any patching issues with the next release. You will also notice the CX700/LG-Nortel 8540 was not included in the update cycle – does it not require the DST fix or is this simply Microsoft stating ever so gently to move off the old phones?

As noted in the comments below, the CX700 has NOT been updated since April but it is now included in the matrix below.





Lync Phone Edition (for Aastra 6721ip and Aastra 6725ip)



MS Download

Lync Phone Edition (for HP 4110 and HP 4120)



MS Download

Lync Phone Edition (for Polycom CX500, Polycom CX600, and Polycom CX3000)



MS Download

Lync Phone Edition (for Polycom CX700/LG-Nortel 8450)



MS Download

Additional Notes: 
Lync Server 2010 build number is 4.0.7577.230
Lync 2010 Client build number is 4.0.7577.4445
Lync Server 2013 build number is 5.0.8308.577
Lync 2013 Client build number is 15.0.4605.1003

Lync Group Chat build number is 4.0.7577. 4409
Lync Group Chat Server build number 4.0.7577.4409
Lync Group Chat Admin build number 4.0.7577.4409

Lync Attendee build number is 4.0.7577.4356
Lync Attendant build number is 4.0.7577.4098
Lync Phone Editions build number is 4.0.7577.4450
Lync Phone Edition (Tanjay) build number is 4.0.7577.4444

Lync 2010 for Windows Phone build number 4.3.8120.0
Lync 2010 for iPhone build number 4.7
Lync 2010 for iPad build number 4.7
Lync 2010 for Android build number 4.0.6509.3001

Lync 2013 for Windows Phone build number 5.4.1087.0
Lync 2013 for iPad build number 5.4
Lync 2013 for iPhone build number 5.4
Lync 2013 for Android build number 5.3.1100

Lync Basic 2013 build number is 15.0.4420.107
Lync VDI 2013 build number is 15.0.4420.1017