Call Queues using hybrid or Cloud Connector Edition PSTN numbers

Call Queues provide a simple way to distribute calls between users in Office365, in a similar fashion to the historic Response Groups in Lync/Skype. When they were first introduced by Microsoft you could only assign them service numbers provided by Microsoft, which was ok unless you were unable to port the number to Office365.

Late in 2017 it was announced that it would be possible to access call queues (and Attendants) using SIP addresses, this opened up the opportunity for using on-premises numbers via CCE or Hybrid.

If you’re using directory synchronisation after creating your call queue you’ll receive a warning to tell you that the Active Directory object is missing and are provided with a powershell command to create it. Unfortunately, this powershell command is included in a Skype for Business management tools update so is of no use if you don’t have a Skype Hybrid environment, for example if you’re using Cloud Connector Edition (CCE) appliances you’re unlikely to have the correct powershell module.

The solution, originally highlighted but now removed in the post, is to create the object manually with a upn that matches the sip address and then assign the required attributes, this can be done using the following powershell for Call Queues:

$OU = “ou=,dc=,dc=”
$displayname = “Queue Name”
$lineuri = “tel:+123456789
$guid = [guid]::NewGuid()
$sipaddress = “
$name = “{” + $guid.Guid + “}”
$objurn = “urn:trustedonlineplatformapplication:11cd3e2e-fccb-42ad-ad00-878b93575e07”
$deploc = “”
$cn = “CN=” + $name
$dn = $cn + “,” + $ou
$upn = $sipaddress.replace(“sip:”,””)
New-ADObject -type User -Path $ou -Name $name -DisplayName $displayname
Set-ADObject -Identity $dn -Add @{“msRTCSIP-ApplicationOptions”=256;”msRTCSIP-ArchivingEnabled”=0;”msRTCSIP-DeploymentLocator”=$deploc;”msRTCSIP-OptionFlags”=384;”msRTCSIP-OwnerUrn”=$objurn;”msRTCSIP-PrimaryUserAddress”=$sipaddress;”msRTCSIP-UserEnabled”=$TRUE;”UserPrincipalName”=$upn;”msRTCSIP-Line”=$lineuri}

The process is the same for auto attendants except you require the trusted application to be: “urn:trustedonlineplatformapplication:ce933385-9390-45d1-9512-c8d228074e07”

To route PSTN calls using CCE to a Call Queue requires rewriting the destination sent from the SBC to become the SIP address rather than the E.164 number as is usually expected. Upon making this change I discovered that the CCE mediation server was rejecting the call due to an unknown server error.

The solution suggested in the comments was to add ;ms-skip-rnl at the end of the translated address and sure enough this worked in my case too and inbound calls to the Call queue from the CCE succeeded,  further comments suggest that this isn’t always the case so it is worth lots of testing prior to production.

Migration from Lync hybrid to Skype for business online using own PSTN carrier

I’ve just completed a migration of a customer to Skype for Business Online, that’s right, Skype not Teams. The reason for this is that the customer wanted to retain their existing PSTN connectivity and currently it is only possible with Skype, using your own SIP is currently expected for Teams with a preview due at some point in 2018 but as yet no fixed date.

There are two real choices for PSTN connectivity with Skype for Business Online using your own carrier, maintain a hybrid deployment or use Cloud Connector Edition (CCE). In this case a Sonus Cloud Link appliance containing both a Sonus Session Border Controller (SBC) and CCE was deployed, in the future it will be used to provide SIP straight into Teams.

You might ask, why would they just not port/transfer their numbers over to Office 365 and use Microsoft as their carrier? This particular customer wanted to provide the capability of receiving PSTN calls to all their staff but realised that only a small minority would likely require the ability to make calls, to port all their numbers and use Microsoft as a carrier would require more calling plans than they would actually benefit from. Additionally, by using the CCE they are able to keep the voice traffic off their main internet connection to ensure the best call quality available to them.

Now that the approach and design is taken care of I just want to cover a few points encountered during the switch over.

Firstly, it’s worth noting that using CCE is only possible if there is no on-premises deployment, Microsoft reversed its decision to introduce support for that topology in 2017. Whilst configuring a user to use CCE for telephony Microsoft checks whether they’re a pure online user or part of a Lync/Skype hybrid deployment.

How does it determine this? And how can you check? Well you can use Skype for Business Online powershell to connect and check the attribute interpreteduser, for example:

Get-csonlineuser -identity | select interpreteduser

If the returned value is hybridOnPrem or hybridOnline then Office365 thinks there is a hybrid deployment. Now if there is no hybrid deployment as the users have successfully been migrated, the Lync/Skype deployment has been decommissioned and all relevant hostnames have been changed then how or why does it think there is still a hybrid deployment?

The answer is due to the existence of the msRTC* Active Directory attributes used by on-premises deployments, if a user is synchronised to Office365 with these attributes still populated then it will be automatically assumed a hybrid deployment exists and as the interpreteduser field is a system generated value it cannot be manually changed.

The solution is simple, remove all the msRTC* attributes and resync the user and wait, after Microsoft’s internal replication has taken place, which in my case seemed to be around 5-6hrs, rerunning the command returned a value of DirsyncedPureOnline and the user could be configured for CCE.

This could potentially be one of the reasons why it is suggested to keep the hybrid deployment if using your own carrier, however as not all customers want to maintain complex on-premises deployments I just want to reassure that it can be done.

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


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)


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


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


The app is a small download


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


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


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


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


Now the device goes through the enrollment process


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


We’re then greeted with the Intune application page


On the My Devices tab we can see the enrolled device


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


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


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


Mobile Device Management in Office 365

Managing mobile devices and securing your endpoints is an important task, there are many MDM solutions out there, including Microsoft’s own InTune. But what if you’re a small company? Well if you’re using Office 365 then you can take advantage of the Mobile Device Management for Office 365 feature to provide basic MDM features such as ensuring devices connecting aren’t Jailbroken, have a device password set and allow remote wipe.

In this post I’ll walk through the administrative steps required to get the tenant ready for MDM and how to apply it to users

So, we browse to the Mobile Management section within the Office 365 portal and we are greeted with:


After clicking Let’s get started and once the Microsoft automation tasks have completed and MDM is ready we are greeted with:


First thing is to complete the settings and remove the error

To configure the tenant domain(s) you need to add two new cname records as per



Now, if you’re not going to have Apple devices then you can, as it says skip that configuration.

After clicking on Set up, we have to download the CSR from our account


Next we have to browse to the Apple Portal


Sign in with an Apple Account (ensuring it’s an account that isn’t tied to a specific user so can continue to be used as the certificates will need renewing)


Click on Create a Certificate


Accept the Terms of Use to continue


Use the Choose File button to browse and select the CSR file generated earlier.


Once processed use the download button to download the PEM response file


You can close out the Apple website and upload the PEM file.


Now we have a nice green tick to say we’re set up


Now we need to create polices that can be applied to users, the first step of which is to ensure we have a group in Office 365 that we can apply the policy to


After ensuring our groups are created we can create our Device Management policies.


We give the policy a name


Now you can choose the policy options


Then some additional options


Next, we have the option to just save the policy, but doing so will not apply it or we can apply the policy straight away


Now we can browse to the group(s) we created earlier and add them


Once the group(s) are added we can continue


We are given a summary of the policy


Back in the portal we can see that the policy has been created and that it is being turned on


After a little while we can see that its status has been set to on


Now it is just a case of assigning users to the group and they will get the policy assigned. I hope to cover the client experience in another post

Exchange Hybrid Free/Busy and Proxy issue

I was investigating an issue with a customer’s deployment where their on-premise Exchange users couldn’t see the free/busy information of the pilot users in Office 365.

After looking through the logs on all of their servers I found event id 4002 on one of them:

exchange 4002 tmg error

So, the EWS request was being blocked by an authenticating proxy, in their case TMG.

After a little investigation on the TMG it was identified that their default web filtering policy was restricted to Authenticated Users and as this request was coming as the Exchange server account itself it was being denied.

Now, they already had a policy in place on the TMG with a set of addresses that could by-pass the authentication and go straight out, so simply adding * to this list allowed Exchange to connect to the EWS of Office 365 and get the free/busy information.

Clients were now working as expected and all should have been good, however the Exchange servers should have had direct internet access and shouldn’t have been trying to go through the proxy in the first place. The customer wanted to know why, so I had to get it to work without entering the url in the by-pass list.

I tried disabling the proxy options within my Internet Explorer settings on the Exchange servers and confirmed I was able to get out onto the internet without going through the proxy. Now, why wasn’t the Exchange server itself able to do this?

I set about trying to work out how to run Internet Explorer as the system account, but how do to do this? Well the answer was to use psexec from the sysinternal tools (available from:

I started on the server that had generated the error, the command I needed was:

psexec.exe -is "c:\program files\internet explorer\iexplore.exe"

the switch -is set the program to run as the system and in interactive mode (without the i you’d not see the browser window as I found on first attempt)

Upon opening the Internet Settings in the newly viewable browser window I discovered that there were proxy settings enabled. Disabling these options allowed free/busy to work, interesting!

I ran the same test on the other Exchange servers but none of them had proxy information entered. Strange.

Until I came across:  which talked about how Group Policy settings, if not correctly configured could result in what I was seeing.

So I had a check, all Exchange servers had the same policy applied specifying the Internet Explorer proxy options but it was set to “Authenticated users” only, which shouldn’t include the service and system accounts that Exchange was running under.

But on the server that was reporting this error I did find proxy information located in the registry key: HKEY_USERS\.DEFAULT. \Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections and after I replaced this with the blank key from another server everything worked and Exchange was no longer going through the proxy.

Not having access to their GPO I wasn’t able to confirm its configuration but I suspect it was changed at some point but the server in question had already applied the incorrect settings which are not superseded by the correct configuration.

So the lesson here is, check GPO and the registry for proxy settings and ensure that Exchange servers (and clients) do not go through a proxy when trying to reach Office 365 services and if they must, ensure that it does not require authentication for the Office 365 addresses.

Microsoft does call this out on their Office 365 URL and IP address webpage –

Skype Hybrid – Moving users via Skype Control Panel

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

Moving Skype users 1

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.

Moving Skype users 2

Nice reminder that you need to have licensed the user first in the Office 365 portal, otherwise they won’t be able to sign inMoving Skype users 3

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)Moving Skype users 4

Moving Skype users 5

Moving Skype users 6

Now we get the last confirmation promptMoving Skype users 7


Moving Skype users 8

Here we can see the user has been moved, although still reporting as LyncOnline!Moving Skype users 9

When you try and edit the user in the on-premise control panel you see a similar screen to Lync

Moving Skype users 10

Skype Hybrid – Connecting to Online

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.

skype control panel

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

skype online signin

And then you get confirmation

skype online confirmation

You can change the account you’ve signed into if need be

skype control signed in

Skype online change account

Setting up Skype Hybrid is now possible from the control panel

skype hybrid

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

skype hybrid configured