Sonus Cloud Link – We failed to run publish-ccappliance

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.

failedtorun_1

failedtorun_2

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.

Forwarding Cisco Call Manager Call to Skype for Business Cloud Connector fails

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

ciscoforward_1

The only difference with the failing call was the addition of the Diversion header entry.

ciscoforward_2

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

ciscoforward_3

I then created a header rule

ciscoforward_4

Which then had an action of Remove for the header name of Diversion, I didn’t add any conditional access expression.

ciscoforward_5

After creating the rule I added it as an Outbound Message Manipulation entry on the Skype CCE signalling group

ciscoforward_6

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.

Sonus Cloud Link – Powershell module is not ready

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

powershellnotready_1

This was also shown in the underlying PowerShell window

powershellnotready_2

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!

Error upgrading Azure AD Connect on a Domain Controller

Whilst in production and for customers I always recommend installing the Azure AD Connect on a dedicated machine, in my lab however I’m a little constrained with resources so therefore have installed it on the Domain Controller, which up to now has been fine.

Today I decided to upgrade to the latest version (1.1.119.0 as of writing) so I duly downloaded the setup and proceeded with the in place upgrade having successfully done so in the past.

This time it would error out and advise reading the logs, in which I found:

Error 25037.The groups entered do not all exist or cannot be found.

On a standard server the AD Connect will create local security groups to manage access, however since I was using a domain controller this wasn’t possible and nor was I prompted to select custom groups.

So as it is a lab I tried uninstalling it and the supporting components before performing a clean install and lo and behold it installed correctly.

I can only presume the setup process is slightly different during the upgrade and it can’t cope with the domain controllers lack of local security groups.

Please remember, if you are doing this to make a note (or take a backup) of any changes in OU filtering or rule changes from the default prior to uninstalling.

Configuring Office 365 Mobile Device Management on Android

In a previous post I talked about the admin tasks required in setting up Mobile Device Management in Office 365, in this post I look at the end user experience on Android.

During this testing I’m using an Android device running version 5.1.1 and I’m using Microsoft’s Outlook App rather than the built in mail client.

Upon opening the app for the first time I’m presented with the usual login box

mdm-client1

Because I’ve already turned on MFA on my account I get prompted to authorise the app (I strongly encourage everyone to have Multi-Factor Authentication turned on wherever it is available)

mdm-client2

Once authenticated I’m prompted to Enrol my device before I can continue

mdm-client3

After clicking Enrol my browser opens and I’m told I need the Intune app, which is available from the Play store

mdm-client4

The app is a small download

mdm-client5

It needs access to the device and lists its requirements as:

mdm-client6

After installation and opening the app we’re presented with another Sign In prompt.

mdm-client7

After signing in we get the option to enrol the device, it’s still not too late!

mdm-client8

One last confirmation of what we are going to allow it to do.

mdm-client9

Now the device goes through the enrollment process

mdm-client10

We’re prompted to name the certificate that’s installed, I chose to leave mine the default

mdm-client11

We’re then greeted with the Intune application page

mdm-client12

On the My Devices tab we can see the enrolled device

mdm-client13

To check the details and compliance information you can click on the system generated device name to bring it up

mdm-client14

You can change the device name by clicking on the pencil icon to make it something more recognisable.

mdm-client15

From an admin perspective we can now see the device in the portal and are able to wipe if need be.

mdm-client16