Announcing new capabilities in Auto Attendant and Call Queue.


(Edited on November 1, 2017 at 12:45 by Francois Doremieux)


Today we are announcing the General Availability of three new capabilities of Auto Attendant and Call Queue:

  • Auto Attendant and Call Queue with hybrid topologies and/or hybrid voice: until now, Auto Attendant and Call Queue were only supported in pure online topologies. This new capability enables using Auto Attendant and Call Queue in hybrid (split domain) topologies and in hybrid voice topologies (using CCE or OPCH); and routing calls from Auto Attendant and Call Queue to Skype for Business users within the tenant regardless of where they are homed (i.e. pure online, hybrid or pure on-prem).
  • Inbound SIP routing into Auto Attendant and Call Queue: until now, Auto Attendants and Call Queues could only be accessed (routed inbound to) via a PSTN Service Number. With this new capability they are now accessible via a SIP URI. This also enables nesting multiple Auto Attendants and/or Call Queues using SIP instead of a PSTN Service Number.
  • Proper caller ID in SfB client toast for calls routed via Call Queue (and Auto Attendant): until now, caller ID for calls routed via Call Queue to the SfB client for Windows was not properly rendered (the Call Queue identifying GUID was displayed instead). With this new capability of the Windows client, the toast will appropriately indicate (when known) the caller’s originating phone number or user name, and the Call Queue name. Together with the earlier release this summer of similar capabilities for Mac and mobile clients, and for Auto Attendant, this completes our work on providing proper caller ID for Auto Attendant and Call Queue.

These three new capabilities have been made generally available on October 31, 2017.

In addition, we are providing a heads-up of the upcoming preview of four additional capabilities:

  • Call Queue – Serial Routing
  • Call Queue – Agent opt-in and opt-out
  • Call Queue – Timeout in seconds (instead of minutes)
  • Auto Attendant – Holidays.


For these four new capabilities, look for a more detailed blog in the next week or two. The remainder of the present blog post will provide more details on the three capabilities released today.


Auto Attendant and Call Queue with hybrid topologies and/or hybrid voice.


Auto Attendant and Call Queue, as released in Q1 CY2017, were targeting pure online tenants with pure online users, i.e. where there is no SfB Server on-premises infrastructure in the tenant’s deployment, where all users are homed online and either use Calling Plans (formerly PSTN Calling) for their PSTN connectivity or have no PSTN connectivity.


In other terms, hybrid topologies were not supported, and hybrid voice (CCE or OPCH) was not supported.


With the present release we are expanding the support scope to include:


Outbound routing from Auto Attendant and Call Queue can now be directed at SfB users within the tenant regardless of where they are homed. Specifically, the Auto Attendant targets and Call Queue agents, as well as overflow targets and operators, can be any mix of:

  • Pure online user (homed online, with online PSTN connectivity using Calling Plans)
  • Hybrid voice user (homed online, with on-premises PSTN connectivity using CCE or OPCH)
  • Pure on-premises user (homed on-prem, with on-premises PSTN connectivity via SfB Server and Mediation Server).

In particular, agents for a given Call Queue do not have to all be of the same type; they can be spread across these various types of users, as long as these users are properly licensed.


Inbound SIP routing into Auto Attendant and Call Queue.


Benefits of inbound SIP routing.


Auto Attendant and Call Queue, as released in Q1 CY2017, were only addressable (routed inbound to) using a PSTN Service Number. This presented several limitations, such as limited geographic scope since Microsoft does not offer Service Number in every locale, unnecessarily exposing internal-only Auto Attendant and Call Queue to the PSTN, exhaustion of Service Number, cost, having to port well-known pilot numbers to be used as Service Number, and unnecessary complexity when nesting multiple Auto Attendant and/or Call Queue instances.


With the present release we are enabling inbound routing to Auto Attendant and Call Queue by SIP URI for users of the tenant (federated inbound routing is not supported). Associating a PSTN Service Number to an Auto Attendant or Call Queue is now optional.


Impact of inbound SIP routing.


There are two significant consequences of the enablement of SIP based routing, for which we advise you go back to pre-existing instances of Auto Attendant or Call Queue and revisit them.


First, you may find that your pre-existing Auto Attendant and Call Queue instances now display a warning “Active Directory entry missing” (see picture below). To the extent you are not interested in providing inbound SIP routing to these instances or in nesting them, the warning is of little consequence and the application will continue to function as it was previously. On the other hand, if you are going to nest the instances or route inbound using SIP, you must fix this by opening the instance and saving it again. Note that if you were already in a (until today unsupported) hybrid situation you may have to create the appropriate Disabled User Objects on-premises for this first, please see further down in the present blog.

Fig 1.png


Second and importantly: transfer of calls placed by tenant users to nested Auto Attendant and/or Call Queue instances, when they are nested via PSTN (as was the case prior to inbound SIP routing) may fail during transfer between instances (transfer does not fail for external parties calling into the service). The workaround is to use SIP routing between the multiple instances instead of PSTN routing. After completing the step above (opening and resaving each instance of Auto Attendant and Call Queue), reopen the nested Auto Attendant and/or Call Queue instances, make sure you use SIP routing between them, and save. See for example:

 Fig 2.pngFig 3.png

Please also note a known current, unrelated issue for existing Call Queue and Auto Attendant where changing or removing the telephone number (tel URI) may not succeed; the workaround is to recreate the instance.


Note: the below warning may continue to be displayed in some tenants. Please ignore. We are working to remove it.



Requirements and setting up inbound SIP routing.


There are three main cases; they differ slightly in terms of the process and requirements.

  • Online only topologies with Calling Plans (formerly PSTN Calling) and/or CCE, without on-premises AD (pure AAD)
  • Online only topologies with Calling Plans (formerly PSTN Calling) and/or CCE, and on-premises AD (federated AD)
  • Split domain topologies with Skype for Business Server (which will include on-premises AD).


We are going to detail each case below. For all cases:

Licensing requirements apply across all types of users. For example, Call Queue agents and operators have to be Voice Enabled, regardless of whether they are homed online or on-premises.

Outbound routing to users is always done via SIP URI only. There is no outbound routing to users by tel URI or generic PSTN number. At this time, both outbound routing to other, federated tenants and inbound routing from other, federated tenants are not supported.

Please note that we strongly advise only using “vanity” domains for the Auto Attendant or Call Queue, and not the “MOREA” domain (*.onmicrosoft.com).


Online only topologies with Calling Plans (formerly PSTN Calling) and/or with CCE, without on-premises AD (pure AAD).


For online only topologies (no Skype for Business or Exchange Servers) with Calling Plans (formerly PSTN Calling) and/or CCE, without on-prem AD (pure AAD), as a new Auto Attendant or Call Queue instance is created, or as a pre-existing one is saved again, the service will create a Disabled User Object in AAD that represents that instance.

No other step is required to enable inbound SIP routing in this case.

That object is added to the Skype for Business Online Global Address List, which makes it searchable by display name. This makes it easy for any user within the tenant to search for the Auto Attendant or Call Queue by display name, right click and place a “Skype Call” to the service.

 Fig 4.pngFig 5.png



Online only topologies with Calling Plans (formerly PSTN Calling) and/or CCE, and on-premises AD (federated AD).

[Update: manual creation of the Disabled User Object is no longer required or advisable.

We don’t need to have any option to create on-prem user object manually. The online platform commandlet now creates the appropriate objects].


For online only topologies (no Skype for Business or Exchange Servers) with Calling Plans (formerly PSTN Calling) and/or CCE, and on-premises AD (federated AD), in order for Skype for Business Online users to be able to search for and discover the instances of Auto Attendant and Call Queue by name, Disabled User Objects need first to be created in AD on-premises and then synced to AAD (no sync back).

Requirements: a hybrid topology including AAD (Azure Active Directory) Connect in order to sync Auto Attendant and Call Queue objects in order to enable SIP calling to them; and on-premises AD schema extended with Skype for Business attributes.

Creation of the Disabled User Objects can be achieved manually, through a script, or through PowerShell, as described later. However the use of PowerShell may be inconvenient in this case since the customer may not have the appropriate environment to run it. 


Configuration steps:


  1. In the Skype for Business admin center, create a new Call Queue or Auto Attendant.Fig 6.png
  2. Fill in the necessary information, remembering that a Service Number is now optional, and that we advise using a “vanity” domain, not a MOREA domain (*.onmicrosoft.com); click on Save.Fig 7.png
  3. Obtain the relevant information about the Call Queue or Auto Attendant. You will need the Name of the instance, its full SIP URI (which has the format of GUID@contoso.com), and its Service Number if applicable. For Auto Attendant, you can get that information from the admin center by clicking on the just created Auto Attendant:Fig 8.png
    Unfortunately, at this time, for Call Queue the only option to obtain the SIP URI is to run the Remote PowerShell commandlet Get-CsHuntGroup for the tenant (documentation of the commandlet: https://docs.microsoft.com/en-us/powershell/module/skype/Get-CsHuntGroup?view=skype-ps)
  4. In your on-premises environment, create an Active Directory User object with the following properties:
    Full name: same as your Call Queue or Auto Attendant display name.
    User logon name: same as the Primary URI of your Call Queue or Auto Attendant, including the domain name.

    Set the user as disabled account, password never expires.

    Fig 9.png
    Fig 10.png
    If you associated a Service Number to the Call Queue or Auto Attendant, you need to enter that Service Number (prefixed with tel:) in the Telephone number field of the above created user:Fig 11.png

  5. Dirsync the created user – Powershell command: Start-ADSyncSyncCycle; verify that the synchronization is complete and that the synced user shows up in the Office portal (for example).
  6. In the Skype for Business admin center, open the Call Queue or Auto Attendant, click Edit without changing anything, and save. Alternatively, you can use Remote PowerShell and run Get-CsHuntgroup –PrimaryUri “…” or the equivalent Get-CsOrganizationalAutoAttendant; then run Set-CsHuntgroup or Set-CsOrganizationalAutoAttendant which will provision the Call Queue or Auto Attendant for inbound SIP routing.

Split domain topologies with Skype for Business Server.

[Update: manual creation of Disabled User Object is no longer recommended or supported, please use our on-prem commandlet (in server Cumulative Update) for that purpose on-prem and with OPCH.]

Instances of Auto Attendant and Call Queue reside in the cloud and represented by objects in AAD. There is no back-syncing of the objects created in AAD back to the on-premises AD. If nothing else was done, there would be no AD object to represent the application instances; therefore on-premises users would not be able to search for an Auto Attendant or Call Queue and to place a call to them.

In order to expose these instances to on-premises users, it is necessary to create on-premises objects that represent them, and to associate these on-premises objects with the online application instances.

This is achieved by creating a Disabled User Object in AD for each instance of Auto Attendant or Call Queue. Once that object has been created and synced to AAD, the admin can complete the provisioning of the Call Queue or Auto Attendant.

Toward that aim, in May 2017 Cumulative Update 6.0.9319.281 (aka CU5) for Skype for Business Server 2015, we included a commandlet that facilitates creating and configuring the Disabled User Object: New-CsHybridApplicationEndpoint.

Requirements: a Skype for Business Server 2015 topology including federation edge, federation edge next hop and pool for on-premises agents/targets must be Skype for Business Server 2015. If Lync Server 2013 is in the topology, it cannot be used for any of the above roles.


Configuration steps.


When you create or edit an Auto Attendant or Call Queue in the Skype for Business admin center, if we detect that you are in a split domain topology and you haven’t created the on-premises Active Directory objects, you will see detailed warning text including the actual commandlet you need to execute on-premises:

Fig 12.pngFig 13.png

The next step is to copy and paste the New-CsHybridApplicationEndpoint commandlet line to your Skype for Business 2015 CU5 Server Management Shell, edit it to specify the correct Organizational Unit (OU) in Active Directory and execute it. The OU is specified in the format of an Active Directory distinguished name, an example is “OU=Sales,DC=Fabrikam,DC=COM”. You need to have appropriate permissions to create the disabled user object in the select OU.

Please also note that the OU you select needs to be included in the AAD Connect directory synchronization scope. Otherwise it won’t be synchronized to Azure Active Directory.


Edited: we have made a fix service side to add the missing attribute, it is no longer needed to add the missing attribute. 

Please note: the commandlet shipped with Skype for Business Server 2015 CU5 has a bug, where it is not setting all the required AD attributes. While we intend to fix that bug in a future CU, for now as a work-around, you need to add the missing attribute yourself.

One method to do this is shown below. You save the result of the New-CsHybridApplicationEndpoint commandlet in a PowerShell variable and then use that variable afterwards to add the attribute. Alternatively, you can manually add it via ADSIedit.msc.

$obj=New-CsHybridApplicationEndpoint -ApplicationId ce933385-9390-45d1-9512-c8d228074e07 -DisplayName "Org AA 3" -SipAddress sip:oaa_bbf7836be32f4badb9f0d3a6cbffxxx@sfblab.dk -OU <your OU> -LineUri tel:+358xxx

Set-ADObject -Identity $obj.DistinguishedName -Add @{"msRTCSIP-ApplicationOptions"=256}

After executing the commandlet and after the next directory synchronization has happened, the warning will disappear from the Skype for Business admin center.


Alternate approach using a script.


As an alternate to the use of the commandlet and then adding the missing parameter as described above, you may want to use the following script appropriately modified to reflect your tenant’s parameters.



    [Parameter(Mandatory = $true, Position = 1, ValueFromPipeline=$true)]


    # Display Name

    [string] $displayname,


    [Parameter(Mandatory = $false)]

    # Phone Number

    [string] $phonenumber,


    [Parameter(Mandatory = $true)]

    # OU

    [string] $ou,


    [Parameter(Mandatory = $true)]

    # Sip Address

    [string] $sipaddress,


    [Parameter(Mandatory = $true)]

    # Is this an AA or CQ





$guid = [guid]::NewGuid()

$lineuri = "tel:" + $phonenumber

$cqurnguid = "11cd3e2e-fccb-42ad-ad00-878b93575e07"

$aaurnguid = "ce933385-9390-45d1-9512-c8d228074e07"

$deploc = "sipfed.online.lync.com"

$urnprefix = "urn:trustedonlineplatformapplication:"

$cqurn = $urnprefix + $cqurnguid

$aaurn = $urnprefix + $aaurnguid

$name = "{" + $guid.Guid + "}"

$cn = "CN=" + $name

$dn = $cn + "," + $ou

$upn = $sipaddress.replace("sip:","")


Switch ($objtype) {

                 'AA' {$objurn = $aaurn}

                 'CQ' {$objurn = $cqurn}


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;"msRTCSIP-Line"=$lineuri;"UserPrincipalName"=$upn}


Inbound routing in hybrid voice.


Typically Auto Attendant and Call Queue are associated with a well know PSTN number (often called Pilot Number) that has long been published, is remembered by customers and/or users, etc. Customers understandably generally want to keep the same Pilot Number for the Auto Attendant or Call Queue. However Auto Attendant and Call Queue can only use a cloud based Service Number.

One option of course would be to port the Pilot Number to the Microsoft cloud and use it as Service Number. That option exists but may not always be practical or desirable, for example because the Pilot Number is part of a range and cannot be ported individually, or due to limitations in locales where Microsoft can provide Service Numbers.

With inbound SIP routing, we now have an easier option to ensure the Pilot Number forwards, using inbound SIP routing, to the Auto Attendant or Call Queue.

[Update: at this time, the only supported mechanisms for inbound routing of telURI are:

1) Use of Microsoft Service Numbers

2) telURI to telURI forwarding at SBC from Pilot Number to Microsoft Service Number, or carrier side redirect of incoming calls to the Microsoft Service Number.

The best effort, customer sourced workaround of telURI to SIP URI forwarding at SBC has been shown to not work reliably and is not supported.

We are aware of the inconvenience and are looking at providing proper solutions to this over time.]

The preferred option (and only one known to work reliably at this time) is to perform forwarding at the SBC. Sample configuration is provided in the comments area of this blog. Unfortunately, the use of a disabled user object as forwarder (as initially described in this blog) has been shown to be unreliable. Thank you for the feedback you provided on this.

Using an additional Disabled User Object as forwarder.


The method consists in creating an additional, voice enabled Disabled User Object with the Pilot Number as the phone number (tel URI), and to set forwarding (for example with SEFAUtil) to the Auto Attendant or Call Queue (which can optionally be provisioned as pure SIP URI without Service Number). The forwarding will of course be done using SIP routing.


Proper caller ID in SfB client toast for calls routed via Call Queue.


Until now, caller ID for calls routed via Call Queue to the SfB client for Windows was not properly rendered (the Call Queue identifying GUID was displayed instead). With this new capability the toast will appropriately indicate (when known) the caller’s originating phone number or user name, and the Call Queue name. Together with the earlier release this summer of similar capabilities for Auto Attendant and Call Queue for Mac and mobile clients as announced here: https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/What-s-new-for-Auto-Attendants-and-Ca..., this completes our work on providing proper caller ID for Auto Attendant and Call Queue.

With this release, Call Queue agents using the Windows Skype for Business C2R client will see a multi-part Caller ID in the call toast, containing the caller’s number as well as the name of the Call Queue the calls is coming from:

Fig 15.png

Note that if the caller’s name can be determined, it will be displayed also side the caller’s number in the Windows call toast:

Fig 16.png


That’s all for today, folks. Thank you for your constant support and feedback and for using Skype for Business!



Thanks for sharing! I really look forward to test this. Have a lot of customers with this requirement!

Are there any steps necessary to get the Toast to display correctly? Does it need the dummy entry in AD for the Queue ? Testing this morning I'm still getting the call queue URI appear ....



Senior Member

Thanks for sharing! Step by step they are adding essential functionalities to be competitive

Occasional Contributor

@Francois Doremieux - For the improved CallerID functionality, what about 3PIP support for these new features?  Is there a specific version of firmware required in order for IP phones to support this?

Established Member

I am seeing the same thing.  The caller ID is showing but the GUID is showing in the toast instead of the Call Queue name.  Is there anything we need to do on our end to fix this?

Occasional Contributor

Sorry guys, I am not getting this!!


WE are using SfB fully online - where exactly do I need to Powershell into and what commands do I use to do that. once into Powershell what do I run?

Occasional Contributor

I'm also experiencing the same thing as @Dave Tieken and @Steven Collier related to the GUID displaying instead of the call queue name.  It appears that all other features you have mentioned are available so I don't believe its a case of our tenant not being updated.  I also ran SfB updates to ensure I'm on the latest version in the case that it was also tied to a client side update.  @Francois Doremieux let us know please if there is something additional that needs to be done for the name to display over the GUID.

Hi all, if you are not seeing the right behavior, please raise a ticket. You are on latest C2R client?

Occasional Contributor

@Francois Doremieux I'm starting to see these display correctly for some of the call queues now.  I would assume that this might just be a sync delay between the update to the call queue/the user vanity account it creates in O365 and SfB.  So I will give it 24 hours and see if all my call queues begin displaying correctly.  FYI I'm on SfB C2R version 16.0.8625.2055.  Additionally, for the queues that are displaying the name versus the GUID in SfB on my PC the GUID still shows on my BToE connected Polycom VVX phone.  Do you know if this will be updated in the next firmware release to Polycom phones or is that a question that needs to be answered by Polycom?

Occasional Visitor

@Francois Doremieux Add me to the list of people still seeing GUID on inbound calls. Like @Mike Messer I have updated c2r to latest version and verified all other steps were completed.

Established Member

I am now seeing the Call Queue name instead of the GUID.  I have 7 call queues and it gradually switched from GUID to call queue name over that last 30 minutes.

Do these changes fix the significant (~5 second) latency between picking up a call from a Call Queue and when users are able to speak?


Also, it's not entirely clear above what "make sure you use SIP routing between them" means -- there's no option in the Auto Attendants to select SIP routing to a Call Queue. Should we remove PSTN number assignments from Call Queues in order to support SIP routing? (Would this speed up the call latency?)

Occasional Contributor

@Nicholas Semenkovich I can't answer the latency question, but yes to enable SIP just edit the call queue or auto attendant and set the Phone Number to Choose a number and save the record.  Before this update, you would get an error stating it was a required field. That should no longer be the case.  

@Nicholas Semenkovich, as stated by @Mike Messer: that is indeed the case, just make sure that when you use another CQ or AA as your destination (on time out, etc) you do it by selecting the display name of that CQ or AA, never its Service Number.


Also, w/r to media establishment delays, do you have the high (ephemeral) ports open to O365 on your firewall? What clients do you use where you observe these delays? Are they in every call pattern?

@Francois Doremieux w/r media establishment delays: All our phones/clients are behind NAT, but we don't block any ports -- they're free to negotiate on any port they like.


We see these delays (up to ~5 seconds from the time a call is answered) for all calls answered from a Call Queue.

They're experienced on both the softphone / Skype for Business app and on Polycom VVX 501 phones.


There are a lot of threads about this delay:



^^^ This claims it's a well known issue, with a plan to reduce it to less than 2 seconds, with an unclear ETA.

@Nicholas Semenkovich: I am aware that there are reports. Some are definitely tied to configuration. I am personally not seeing the issue in my own tenant. Therefore investigation and verification of all environmental aspects is desirable (for example, if direct UDP media is not an option, we know that setting up relays or tunnels or using TCP will take time in media establishment). But there may be other, product related things as well that can be done. Now that we shipped the hybrid support scope, we may be better able to identify what's going on here.

Occasional Contributor



There is a lot of abbreviated jargon being passed around in this thread and as end users, we are not familiar with the terms. 


We are suffering the significant delays of at least 5 seconds and are finding it very embarrassing with our customers who are having to wait on the line for what seems to them to be an age. 


Can someone please explain in simple terms or provide a link to a procedure providing the details of how to set the system up to avoid these excessive delays. We really need this to be a lot slicker!!



James Lupton



@Francois Doremieux Re: "Now that we shipped the hybrid support scope" -- just to be clear, we aren't a Hybrid user. We're 100% in cloud / Cloud Voice / Cloud PBX / Calling Plan.


We'll play around with Consistent NAT / longer UDP timeouts / possibly enable SIP ALG to see if this helps. (It's not clear that the Polycom VVX Skype for Business phones support UPnP).

Occasional Contributor

That's great! It was a big challenge for the existing CCE customers, to route phone-numbers to call-queues/OrgAA from there existing sip-trunking infrastruture. It looks like that the issue is gone (with some hacks).


What I’ve done:

  1. Incoming call to on-premises SBC
  2. The SBC manipulates the “to” header from “+411234567@sipdomain.ch” to “hg_764055…7ee044ea6@sipdomain.ch”.
  3. SBC routes the call to the mediation server
  4. The mediation server through the edge to the SfB-O platform
  5. The call is established

Of course it need some more testing. However, the first test were sucessful.

@Andreas Reisinger: thank you for this additional methodology. While it's more complex to set up, it's one that works regardless of adding another user object, or a voice license, so that's pretty cool.


Also, I am getting some reports of challenges with the methodology we listed (permanent forwarding to the DUO representing the AA/CQ). Did you try it? 

Senior Member

Hello Francois, thanks for the great post!

I was just testing these new features but was wondering if I was missing something... How can I configure a phone number from my SIP trunk range to work with the Auto Attendant feature? It works calling the AA and CQ from an user account with SFB but I would like to configure an external phone number so it's reachable from outside our company.

I have a pure online tenant with CCE setup.


@Jeroen Woestenberg: your tenant is not a pure online tenant, it is a SfBO hybrid voice tenant with CCE. Also from the blog you have certainly seen that your AD topology comes in play, is it pure AAD or do you also have AD on prem with sync.


That said, one of the options to achieve what you are asking for could be the one mentioned by Andreas above.

Occasional Visitor

It took 23 hours but it's working now. Also, @Francois Doremieux I created a test queue without adding the disabled user to on-premises AD and it is working too. I'm an Online only S4B with AzureAD Connect Syncing on-prem AD.

@Doug Stampley: when you say it's working, what do you mean exactly? The CQ should work, but some of the new features may not.

Occasional Visitor

@Francois Doremieux the CQ works as expected and the inbound Caller's Caller-ID and the CQ Name are displaying correctly without having the disabled user account in on-prem AD. It appears that the step of adding the disabled user account to on-prem AD may not be necessary. I have seen some others say the same thing in another thread.

@Doug Stampley: it is not necessary if you are not going to use SIP routing as detailed in the blog. That said, are you able to search for the CQ/AA as a user and to call it with right click?

Occasional Visitor

@Francois Doremieux Yes, I can search and call both Queues (1 with on-prem disabled account and the other without) by right clicking and selecting "Skype Call".

What domain are your call queues in? if it's not one that's synced then the article sort of says it's not necessary. Seems necessary here, or rather it's not displaying the right name yet, but the disabled account we created has yet to sync to Skype.
Occasional Visitor

Hey Francios,


A handful of commenters, including myself see the GUID still displaying. This is even after deleting and re-creating the call queue. It is starting to seem, just anecdotally, that the GUID issue has not in fact been fixed as expected. Are your engineers actively evaluating that this fix isn't working?

@Evan Lieberman: we are seeing that the GUID issue has been fixed when customers are on the C2R client, follow the steps and wait a little for propagation (including where applicable to the on prem GAL). Kindly double check?

Occasional Contributor

Yes we are still getting the GUID whilst others seem to be getting the Call Queue details showing up.


We have deleted the call queue and set it up again from scratch but it just shows a new GUID and not the CQ details


Its good that the caller ID info is now showing up but we would ideally like to know which number the caller is trying to reach as different called numbers get handled in different ways.


At present we have an Active Directory Issue with the message below being displayed against the call queue. We only operate the online version and therefore don't know where to access the system using PowerShell (as described in the message).




Any Feedback would be appreciated. 



James Lupton


Occasional Visitor

I've allowed for over an hour of propagation. I'll wait for 24 hours (until Monday) and see if it is just really slow to propagate.






Occasional Contributor



We have been over 24 hours and still do not have the CQ details showing up!!




James Lupton

@James Lupton: which of the specific cases spelled out in the blog do you fall under? You have not stated that in your comments.

Occasional Visitor

We are on "Online only topologies with Calling Plans (formerly PSTN Calling) and/or CCE, and on-premises AD (federated AD)."


Our setup is pretty simple. We use the AD sync client to sync our distribution group and our users. Everything else is in O365.

Occasional Contributor

@Francois DoremieuxI am not sure which of these cases apply to us - See my earlier post about "abbreviated jargon".


We are users of Skype For Business through our Office 365 subscriptions

We use the Online Version 

We have PSTN calling added for our users and do not have any on premises PSTN capabilities

We have a domestic calling plan for our users


We had previously reported the issue with Caller ID information not showing up and this now seems to be fixed. 


It has however highlighted that we do not know what calling Queue is managing the call and it appears that some people are getting both the caller ID and the Calling Queue details showing up and others, like us, are only getting the caller ID.


We have checked out outgoing calls (at least to our mobiles and this seems to pass through the outgoing caller ID so we fit into the category of those who have a working caller ID (both in and out) but no calling queue details. 


As it seems that it can be fixed for others, we would like to know how to get our system working correctly.




Occasional Contributor

It looks like our set-up is similar to @Evan Lieberman but our distribution group is set up in groups under Office 365 Admin.


We do have AD on our local file server Windows Server 2016 but this is not linked to our Office 365 accounts and email and skype are not routed through this server (unless this has been done without us knowing).


Based on the message I posted earlier, there seems to be a problem with our Call Queue's registering through the Office 365 AD an we don't know where to powershell into to run the cmdlet (or even if this is possible).


@Evan Lieberman: and you are using the C2R client? If so, please give it some time, it should resolve the GUID. If it does not please open a ticket. Thanks!

To confirm that our environment fits the second case, Skype Online but with AzureAD connect syncing our users. By adding the disabled users above, waiting for the sync, then editing and saving the Call Queue the prompt for Missing AD Entry disappeared. It then still took a long time, to the next day, but the call queues were then displayed with the correct name, and not the GUID. Skype from Office 365 C2R.

Thank you @Steven Collier. That is the expected behavior. It ***may*** be that in some cases there is no need for the Disabled User Object (DUO), but as a general case our testing shows it's a recommended step. Then open and save. And giving it time to replicate. 

Unless of course there is no on-prem AD (pure AAD) in which case there is no place to create that DUO :)


Does that mean the Outgoing Caller ID for users can now be set to any number or does it still have to be a service number?

Occasional Contributor

Can anybody explain how to use our own numbers from SIP Trunk for call queues in the scenarios:


1.) Pure online with AAD and CCE+SIP Trunk

2.) Pure online with local AD + AADConnect and CCE+Sip Trunk.


I would like to point the incoming calls from the SBC directly to the call queue via cce mediation server. I don't get it. Why not allow direct assignment of our trunk numbers to the queue? What is the technical reason not allowing this?


Tried Andreas Reisinger Suggestions too but SBC to CCE Mediation Server signaling is +49XXXXXXXX@mediationserver.domain.local. If i try to modify the to-header and replace +49XXXXXXXX with the name of the call queue (hg_4axxxxxxxxxxxxxxxxxx@mediationserver.domain.local) it will not work like explained by  Andreas Reisinger. Suggestions?



Occasional Contributor

@Thomas Oeser


I would like to point the incoming calls from the SBC directly to the call queue via cce mediation server. I don't get it. Why not allow direct assignment of our trunk numbers to the queue? What is the technical reason not allowing this?

Teams will supporting direct SIP Connections from an compatible SBC into the cloud (without any CCE bits) in the future - SfB doest currently not supporting assigning phone-numbers from OPCH/CCE environments (technical issues...). 


If i try to modify the to-header and replace +49XXXXXXXX with the name of the call queue (hg_4axxxxxxxxxxxxxxxxxx@mediationserver.domain.local)...

The TLD should be the same as the Call-Queue has.


What is the maximum number of  CQ that can be created (I'm not talking about the maximum number of agent per queue) I couldn't find this info in the SD

Occasional Contributor

@Andreas Reisinger, it makes no difference when TLD is changed to the vanity domain the call queue is using.


So hg_4axxxxxxxxxxxxxxxxxx@vanitydomain.com does not work either.


Can you tell me a bit more about your setup. What SBC are you using? 

Occasional Contributor

Sure, I've a audiocodes SBC. As you can see in the screenshot below the call-flow should working fine with an CCE. Compare the Invite from the SBC to the mediation service with your own one. 


I've created a document which describes the configuration on an Audiocodes SBC. 

AudioCodes Configuration



cce_invite.pngCall Flow

Occasional Contributor

@Francois Doremieux I see this evening that serial based routing was enabled for call queues.  This is great, but there is no way to order users within a group so you can't define what user rings, first, second, third, etc.  Members in a group are ordered by username and you are not able to be ordered any other way.  Any thoughts as to if you will have a way to order members of a group so you can define what order it rings users when serial routing is enabled?

@Andreas Reisinger: thank you, this is super cool and indeed works. Do I have your permission to incorporate in the blog proper, so as to make sure people see it? With attribution of course :)


Also we had reports of some challenges in configuring the forwarding to a Disabled User Object. There may be a bug. In the interim I am going to remove that section of the blog until we clarify.


@Francois Doremieux 

Any insight about round robin distribution for Call queue?


After the greeting message in a call queue, if the call times out can we setup a voice notification telling the customer that the call will be redirected to a call center for instance?