Improved Auto Attendants & Call Queues

 In Skype for Business

Today’s update comes from the Skype for Business blog by Francois Doremieux:

The changes detailed in this update are hugely welcomed and go a good way to ensuring the service can be implemented as a mature alternative to alternative telephony solutions and traditional on-prem variants.

Read on for details:

Microsoft have announced 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 from October 31, 2017 and are therefore live now.

 

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 (Cloud Connector Edition or On-Premises PSTN Connectivity ) was not supported.

With the present release Microsoft 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. Microsoft are working to remove it.

WarningAA.jpgWarningCQ.png

 

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).

 

The detail for each case is shown 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 Microsoft 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).

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.

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 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 it is detected 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.

 

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.

[CmdletBinding()]

Param(

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

# 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

[ValidateSet(‘AA’,’CQ’)] [string]$objtype

)

 

$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.

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

 

All in all an excellent blog post from Francois Doremieux (S4B)

 

Recommended Posts

Leave a Comment