Inserting a PSTN usage into a Voice Policy

Voice Policies are assigned to users, and they control what a user is permitted to do in terms of voice functionality and calling. The “calling” part is determined by an ordered list of PSTN Usages within the Voice Policy.

Usages in VoicePolicy

The PSTN Usages are evaluated from top to bottom, until a call completes or the end of the list is reached.

If you’re using the Control Panel GUI and have just a few PSTN Usages and Voice Policies, it’s straight forward to edit this list. However, in the land of PowerShell, your only options are to remove a PSTN Usage, or to add one. The add function appends the PSTN Usage to the end of the list of usages, which isn’t ideal given that this is an ordered list.

I recent had to insert a new PSTN Usages into a large number of Voice Policies, and wrote this script to do that.

It’s straight forward to use. Create your new PSTN Usage, then run something like this:

Insert-PSTNUsage -CsVoicePolicy <VoicePolicy> -AddUsage <UsagetoAdd> -Priority <Priority>

where:

-CsVoicePolicy is the Voice Policy that you want to add the PSTN Usage to.

-AddUsage is the PSTN Usage that you want to add to the Voice Policy

-Priority is where the PSTN Usage should be added to the list of existing PSTN Usages. 0 is the start, and if you enter a value larger than the number of existing PSTN Usages, it’ll append to the end.

For example:

Insert-PSTNUsage -CsVoicePolicy VancouverStaff -AddUsage LongDistance -Priority 5 -verbose

This script returns no output to the console unless you use -verbose, in which case it will output the same information that’s also recorded to a log file:

Adding PstnUsage: LongDistance
To CsVoicePolicy: VancouverStaff
At priority: 2
Current Number of Usages: 6
Current Usages: zero One Two Three Four Five
Usages before insertion point: zero One
Usages after insertion point: Two Three Four Five
Restore Command: Set-CsVoicePolicy test -PstnUsages zero,One,Two,Three,Four,Five
Resulting in new usages: zero One LongDistance Two Three Four Five

  • The first three items are simply logging the parameters that you’ve provided.
  • Current Number of Usages is the number of PSTN Usages assigned to the Voice Policy before insertion.
  • Current Usages: a list of PSTN Usages assigned to the Voice Policy before insertion
  • Usages before insertion point and Usage after insertion point: Lists of usages before and after the spot where the new PSTN Usage will be inserted
  • Restore Command: this is a command that you can cut and paste into a PowerShell session to undo the Insert-CsPstnUsage command. The ability to back out your changes is something that I always like! (It might have wrapped in the above output, it’s not wrapped in the log file).
  • Resulting in new usages: this is a Get of the new list of PSTN Usages in the Voice Policy so that you can check your work.

I hope you find this useful, and I welcome your feedback!

 

Main Number Handling – Putting it all Together

A number of months ago, I kicked off what I thought would be a short and simple overview of the various ways you could handle a main number in SfB. As it turns out, there was nothing short about the process! However, now that we’ve covered the various components that you can use to handle calls to main numbers, it’s time to tackle some common main number scenarios that I see in organizations I work with. Along the way, I’ll throw in some tips and tricks from my list of ways to make life easier.

Before we do that, you should hop back to my first post in this series, where I talk about some of the non-technical things you should consider, and how you should approach designing a solution to handle your main numbers. You shouldn’t just rush in and set things up, as some of them take time. It’s also important to ensure that you’re getting the best SfB solution for your users, and not just a clone of what they had previously.

“I find that it’s often the case that SfB has all of the functionality to meet the same goals as users expected from a previous PBX. However, that functionality is often implemented differently.  That’s not because SfB is weird, but rather because it’s a UC system and not a PBX. There are multiple modalities to consider, as well as things like mobility and presence.  Tag for status change alerts is a good replacement for “Camp on” in the PBX world. While it may require you to take the additional step of click “call”, this does give you the opportunity to use a different modality to contact the user once they’re available, such as IM. Of course, you could always choose to IM the user who’s on the phone and thus avoid the entire requirement for Camp on functionality”

The Solutions

The first solution that I’m going to list, will also be the first one that I recommend that you not implement, and that’s to simply use the receptionist’s phone as your main line. If your receptionist goes on a break or vacation, then someone needs to know their password to check voicemails. That’s bad for security, but it also sucks for the privacy of the receptionist’s account. And what greeting gets used – the receptionists, or the organizations? Yuck, better to just move on to the next solution.

The second solution is suitable for small offices. You setup a standalone or “phantom” account for the main number, and leave the receptionist with their own account. We had a look as the good and the bad around this solution here so I won’t rehash that discussion.

Up next, we’ll have a look at options for scaling up to larger offices.

Main Number Handling – Cloud PBX Call Queues

I’ve covered Response Groups in a number of earlier posts. Microsoft has started implementing similar functionality in Skype for Business Online, called Call Queues.

Where Response Groups are quite comprehensive and have “lite” call center functionality, Call Queues aren’t there yet. There are a number of key differences between the two. First up, let’s have an general overview of Call Queues, then we’ll compare them with Response Groups.

General

The purpose of Call Queues is to provide automated call distribution to a group of users, called agents. You can have up to 50 agents assigned to a Call Queue. Agents are assigned to a Call Queue using distribution lists, or mail enabled security groups. The Call Queue can handle 200 simultaneous calls. If you’re handling 200 simultaneous calls, you should evaluate contact center software to see if it offers you additional functionality that you can take advantage of.

As with Cloud PBX Auto Attendants, you can upload a corporate greeting. If you don’t have a favorite application for this, try Audacity. You can also specify a music on hold file, that’ll be played while callers are in the queue waiting for an agent.

When you setup group, you need to allow time for the group to sync from Azure Active Directory to Azure Address Book Service.

Calls are distributed to all of the agents in the groups you configured, to a maximum of 50, or there is a global setting to reduce this count further. If you’re using groups with larger membership, be aware that not everyone will be offered every call. If you want more certainty in who is offered a call, create custom groups.

Overflow

Each Call Queue has an overflow threshold, after which new calls will have some configurable action taken on them rather than the call being added to the queue. This can be 0 to 200, but has a default of 50.  You can select actions of DisconnectwithBusy, Forward, or Voicemail.

There is also a timeout option, so that after a certain amount of time in the Queue, calls are send to another Call Queue, Auto Attendant, Voicemail, or User. You can also just disconnect the caller.

Consider whether you want to use the disconnect options. While the caller will hear a busy tone, you may want to forward the call to voicemail, and play an informational message. I would never recommend a disconnect for the Queue timeout – why would you disconnect someone after they’ve been waiting in the queue for 10 minutes (or however long you configure).

You’ll need a Cloud PBX Service Number to assign to your Call Queue, and you can use both tolled and toll-free. You can use a new service number for setup and testing, and port in your existing number.

The timing of the port may prove awkward if this is your main number. You can setup your Call Queue with a new number, and have your existing main number forwarded to it. When you receive notification that the number has ported, you can edit your Call Queue to use the new number directly.

Your Tenant needs to have E5, or E3 plus Cloud PBX licensing, in order to have Cloud PBX Call Queue available.

If you want your Cloud PBX Call Queue to direct calls to a voicemail box, you should setup a phantom user (a user account with no real human attached to it), and have that mailbox be the target of Queue.

Call Queues allows Online SfB users with a Cloud PBX license to be agents, regardless of what region they’re in. A PSTN Number or PSTN Calling user licenses isn’t required. Agents must be using the SfB 2016 or Lync 2013 desktop clients, or a Cloud PBX-certified IP phone. No Mac or mobile clients are supported according to documentation from March 2017, however I have seen the iOS client in action as a Call Queue agent.

You cannot use SfB on-prem users, Cloud PBX users with have PSTN connectivity through an on-prem connection, either through CCE or a full on-prem pool. You also can’t use on-prem only services like response groups, and you can’t distribute a call to an external PSTN number.

Comparison with Response Groups

Call Queues have some of the functionality of Response Groups, however at this point Response Groups have far more flexibility and functionality.

Call Queues lack IVR capability. If you need this, you can front a Call Queue with a Cloud PBX Auto Attendant. Have the Auto Attendant deliver calls to the Call Queue.

Response Groups have a richer management story. It’s possible to delegate management of a Response Group to a user (like a help desk manager) and relieve IT of the management burden. This isn’t possible with Call Queues.

Response Groups have the concept of Formal and Informal mode. Formal mode requires the user to logon to the Response Group to receive calls. Informal mode is where the user is always “logged on”. Call Queues offer only Informal mode.

For overflow scenarios, Response Groups allow you to act upon the oldest call in the queue or the new call. Call Queues only allow you to act upon the new call.

When it comes to distributing calls to agents, Response Groups offer 5 call routing methods: Attendant, Parallel, Serial, Round Robin, and Longest Idle. At this point, Call Queues offer only Attendant routing.

And lastly, when you’re building a list of agents, Call Queues use only distribution lists or email enabled security groups. Response Groups can use DLs, but also allow you to manually build a list of agents.

Outside of these major differences, the two services are very similar. I would expect that additional Call Queue functionality will be released often. Be sure to check the Office 365 Roadmap to see if a feature you’re interested in is on the way.

You can provide feedback on what features you feel are important with Skype for Business. The Skype Operations Framework academy page has online training for you to learn more.

Main Number Handling – Cloud PBX Auto Attendants

We’ve covered how to setup an Exchange Auto Attendant for your Skype for Business environment. Microsoft has recently released a new offering, the Cloud PBX Auto Attendant.

The two are very similar in their functionality, with some key differences. Firstly, Exchange Auto Attendants ( are an Exchange function, and not a Skype for Business function. Secondly, Exchange Auto Attendants can be in Exchange online or Exchange on-prem, work with SfB users regardless of where they’re homed, and can even integrate with other PBXs.

General

Cloud PBX Auto Attendants, being so new to the world, haven’t yet achieved a similar level of functionality. If you’re reading this blog a number of months after it was written, hit the Cloud PBX Auto Attendant tag to check for a blog covering updates!

When you’re configuring or calling a Cloud PBX Auto Attendant, the “look and feel” is nearly identical to that of Exchange Auto Attendants. You get the same informational, business-hours, and after-hours greetings.

When it comes to scheduling your business hours, Exchange Auto Attendants offer 15 minute granularity, where Cloud PBX Auto Attendants offer 30 minute granularity. You can, however, still set as many open/closed periods as you’d like.

Speech recognition is similar as well, and when you configure a name as a menu option, the Auto Attendant will recognize that name

Directory Search

Directory Search is an area where things differ between the two products. In Cloud PBX Auto Attendant, callers can speak or spell the name of any SfB ONLINE user, and that user can be homed in any of the regions that the tenant has. That user doesn’t need a PSTN Calling license, or a PSTN Calling number. The caller cannot reach a Cloud PBX user who has PSTN connectivity through an on-prem connection, either through CCE or a full on-prem pool, nor can they reach users who are home on-prem.

A feature of both Exchange Auto Attendant and Cloud PBX Auto Attendant is the ability to set a scope, or limit, of who callers can search for. You might want to protect VIPs, or only allow callers to reach sales staff.  If you happen to be part of an organization with more than 50,000 users, you cannot use name recognition to search for a user – but all other speech recognition works.

Operator

With Exchange Auto Attendants, you provide an extension for the operator, and when a caller presses 0, they are transferred to that extension. The “extension” can be any number, so long as you configure Exchange and your PBX/SfB to permit the call.

Cloud PBX Auto Attendant allows Online SfB users with a Cloud PBX license to be operators, regardless of what region they’re in. A PSTN Number or PSTN Calling user licenses isn’t required. You can also send calls directly to voicemail, or to a Cloud PBX Call Queue (the Cloud PBX equivalent of a Response Group).

You cannot use SfB on-prem users, Cloud PBX users with have PSTN connectivity through an on-prem connection, either through CCE or a full on-prem pool. You also can’t use on-prem only services like response groups.

Menu Options

Menu options are straight-forward. Indicate the dialpad button for a caller to press, and then the action to take when that button is pressed. One difference here versus Exchange Auto Attendants is that there is native functionality to transfer the call to a Cloud PBX Call Queue, instead of you having to indicate a phone number or SIP address.

The GUI is a bit different here compared to Exchange Auto Attends. You get buttons arranged in a row, with a list of the options you’ve configured below:

Buttons

Other Bits and Pieces

You’ll need a Cloud PBX Service Number to assign to your Cloud PBX Auto Attendant, and you can use both tolled and toll-free. You can use a new service number for setup and testing, and port in your existing number.

The timing of the port may prove awkward if this is your main number. You can setup your Cloud PBX Auto Attendant with a new number, and have your existing main number forwarded to it. When you receive notification that the number has ported, you can edit your Cloud PBX Auto Attendant to use the new number directly.

Your Tenant needs to have E5, or E3 plus Cloud PBX licensing, in order to have Cloud PBX Auto Attendant available.

If you want your Cloud PBX Auto Attendant to direct calls to a voicemail box, you should setup a phantom user (a user account with no real human attached to it).

Evaluation and Adoption

Your first step in evaluating and (possibly) adopting Cloud PBX Auto Attendants is to document the functionality of your current auto attendant. Then, review the functionality and the limitations mentioned above. If Cloud PBX Auto Attendant can do everything you need, then you’re all set – time to deploy!

If you identify some gaps, you have two choices. One, you can change your requirements to match what’s available now, or two, you can wait. Additional functionality is expected to be released as development occurs.

Be sure to check the Office 365 Roadmap to see if a feature you’re interested in is on the way.

You can also provide feedback on what features you feel are important with Skype for Business.

Learn More

Head to the Skype Operations Framework academy page to learn more!

Main Number Handling – Auto Attendant vs Response Group

I’ve covered Exchange Unified Messaging Auto-Attendants and Skype for Business Response Groups in some depth in previous posts, and I wanted to do a comparison between the two. The two share some overall similarities, with some major difference that will lead you to select one over the other, and minor differences that you’ll want to be aware of.

Microsoft recently released two Skype for Business Online features: Cloud PBX Call Queues and Cloud PBX Auto Attendant. These two SfBO features are roughly analogous to Exchange Auto Attendant and SfB on-premises Response Groups, however to be clear I am not referring to the Cloud PBX functions in this post unless I explicitly mention them.

Main Feature Comparison

In the following table, I state whether functionality is available in Response Group and Auto Attendant scenarios, and in some cases I provide some more clarity and detail beyond a “yes” or “no”.

Feature

Response Group

Auto Attendant

Anonymous call out

Yes, user can call as the Response Group

No

Management delegation

Yes, per Response Group (and associated Queues and Groups)

Not very granular, only to “Exchange UM” RBAC role within Exchange.

User lookup/dial by name (speak or spell)

No

Yes

Schedule

Scheduled to the minute. Two open periods per day, otherwise closed.

Scheduled in 15 minute blocks, any number of blocks may be open or closed.

After-hours and holiday support

Yes

Yes

Calls delivered to

Natively to PC SfB client. Voicemail and other timeout/overflow options available.

To any SfB client, or any phone number reachable by Exchange – including PBX extensions and PSTN numbers.

Honors Team-ring, Delegation, SimRing, Call pickup, mobile clients

No, only rings the user’s PC or desk phone.

Yes

IVR

Yes, multiple choices and levels. Calls delivered to Queue, not directly to an endpoint.

9 choices, one level. Calls delivered to a number, mailbox, and can play a message

Caller can dial 0 to reach operator at anytime

No

Yes

Call queuing

Yes – call is delivered to a queue

No – call is transferred to the number specified

Multiple language support

Yes

Yes

Voice recognition

Yes

Yes

Text-to-speech or recorded greetings

Yes

Yes

Can read location and business hours to caller

No

Yes

Formal agent logon mode (user logs into and out of a queue)

Yes

No

Online or on-prem server based?

On-prem servers only.

(Use Cloud PBX Call Queues for online deployments)

Both. Exchange UM Auto-Attendants have the same functionality on-prem and online.

Can deliver calls to on-prem user

Yes

Yes

Can deliver calls to online user

No, users must be homed on-prem.

Yes

Can assign multiple phone numbers to reach it

No

Yes

Can record greetings via telephone

No

Yes

The details in this table refer to native functionality of the Auto Attendant or Response Group solution. For example, you can only natively assign one Line URI to a Response Group workflow. If you wanted to have multiple numbers to reach a workflow, there are a number of ways outside of Response Group functionality that would permit you to do that.

Final Considerations

An additional consideration that you’ll need to make is the topology of the Exchange and SfB environments. If a call comes in from the PSTN via an SBA in a branch office and has to traverse the WAN to a central office to Exchange and SfB servers, the two solutions are equal. If you are using Exchange Online, calls to your Auto Attendant now have to traverse the Internet to the cloud.

In the not so distant past, I worked with a client in a “PSTN into the SBA” scenario, where calls had to traverse the WAN to reach Response Groups, and the WAN and an underspec’d VPN to a privately hosted Exchange system. That VPN was spec’d for email (and the specs weren’t even generous for that) not voice, so voice, Auto Attendant, and Subscriber Access suffered accordingly.

And finally, make sure you’re supporting REFER, and that your firewalls allow appropriate media flow between all of your clients and servers involved in these scenarios. Appropriate levels of bandwidth and QoS are also a must.

Up next: Cloud PBX Auto Attendants and Call Queues, the Cloud PBX cousins of Exchange Auto Attendants and SfB on-prem Response Groups.

Cool Tool – Find duplicate LineURIs

Every once in a while – and by that, I mean ALL. THE. TIME. – I run into a situation where a number that I’ve been asked to provision as a LineURI for a SfB endpoint is already in use:

Failed

“Filter failed to return unique result” has got to be one of the most frustrating errors that you can receive. At least it doesn’t tell you to contact your system administrator…

Sometimes this is easy to figure out by searching for that number in the User Search section of the Control Panel:

UserSearch

And other times it’s not, because the number is hiding, assigned to one of the following:

  • User LineURI
  • User PrivateLine
  • CsAnalogDevice
  • CsCommonAreaPhone
  • CsExUmContact
  • CsDialInConferencingAccessNumber
  • CsTrustedApplicationEndpoint
  • CsRgsWorkflow
  • CsMeetingRoom LineURI
  • CsMeetingRoom PrivateLine

And you know what you don’t want to do? You don’t to have to dig out PowerShell and search all of these manually. What you need is a script to do this for you, and while there are a couple out there, the one by Lasse Wedø is my favorite.

It’s comprehensive, well-written, has nicely formatted output, and has a tonne of parameters available if you want to do a more complex search. The simplest form of search looks like this:

PS Search

which seems just about right to me. Download the script and give it a try next time you run into duplicate number issues.

Main Number Handling – Auto Attendants

I’ve written quite a bit about SfB Response Groups, so let’s dive into their Exchange cousin, the Auto Attendant – AA for short.

Auto Attendants allow Exchange to answer calls to your organization. You can play greetings, set schedules, allow callers to reach your users by saying or spelling a user’s name or dialing their extension, or you can provide them a list of options that they select by pressing a key.

Creation

To create an Auto Attendant, open the Exchange Admin Center, select UM dial plans, open the dial plan that you want the AA created under, and click the + in the Auto Attendant section.

You’ll need to provide a name, indicate if you want the Auto Attendant active immediately after you create it (you might not if you’re preparing for a future migration), indicate whether you want the AA to respond to voice commands, and provide a phone number to reach the Auto Attendant at. Note that you don’t *have* to provide a phone number, which is handy for lab work and setup before a migration. You will of course need to circle back and provide at least one phone number before anyone from the PSTN can use your AA to reach your organization.

If you’re in a SfB environment, you’ll need to run the New-CsExUmContact command to create a contact object so that your SfB environment knows about the AA endpoint. Non-SfB environments will need to follow different setup steps which I won’t cover here.

Options

Now that your AA is created, you can double-click it to configure additional options.

ConfigMenu

General

Under General, you see the same options as when you created the AA, joined by a few others: setting a language, business name, and business location. Set the name and location accurately, as they can be read to a caller by the Auto Attendant. Here, you can also set a backup Auto-Attendant, that callers can be sent to when voice recognition isn’t working well.

Greetings

Under Greetings, you can set business hours and after-hours greetings. You can also add an informational message, and optionally set this message so that callers cannot skip it. This is useful for things like unexpected closures dues to weather

Business Hours

Under Business Hours, you can set the timezone for the Auto Attendant, and then you can configure your business hours  as granular as 15 minute intervals. Here, you can also specify your Holidays using a start and end date, and specify a Holiday Greeting. Note that the holiday greeting is played from 12:01am to 11:59PM on the day(s) you configure. You can’t have the holiday greeting start at the close of business on the last day of work. You can use the announcement feature for this, or sneak in at the end of the day and reconfigure the holiday greeting to have started that day. Note that after the holiday greeting plays, callers are sent to the after-hours greeting and menu.

Menu Navigation (or not)

I’m going to skip menu navigation for now…

Address Book and Operator Access

Under address book and operator access, you can specify what permissions callers have to reach users, user voicemail without ringing the user, for searching the directory for users,  and for transferring to an operator. Note that “operator extension” here is the operators actual phone number, not what key you want the caller to press.

Dialing Authorization

Under dialing authorization, you can set where users can dial via “outdialing”.

Menu Navigation (for real)

This section is the meat and potatoes of the AA is configuration. There are two sections, business hours and non-business hours. The options within each section are the same:

  • You can upload a record prompt file – if you don’t, the AA will read the options for each entry using text-to-speech.
  • You can enable or disable menu navigation, but you do need to enable menu navigation for your AA to work, so go ahead and enable it.

If you click the + or pencil button, you can created or edit a menu entry. You need to configure the prompt, which will be read by the AA using text-to-speech if you haven’t uploaded a greeting.

Entry Configuration

You can pick when key you want to assign this action to. You can select 1-9 or timeout. 0 is reserved for reaching the operator at the extension programmed earlier.

Menu Navigation Entry

When the key is pressed, you can optionally play an audio file. After then you can select one additional action:

  • None
  • Transfer to an extension (This can be an internal or external number, so long as it is permitted by the dialing authorization rules you configured above)
  • Transfer to another auto-attendant (this is useful if you want different languages, or transfer someone to a different country or group, but please don’t try to build an IVR solution with multiple Auto Attendants)
  • You can leave a voice message for a user, without ringing them. This usually goes to a generic voicemail box
  • You can have the text-to-speech reach your business hours (you entered this carefully under the “general” section)
  • You can have the text-to-speech reach your business location (you entered this carefully under the “general” section)

The business hours and location that are read out are what you entered in the “general” section. If they are pronounced funny with correct spelling, you may need to spell them phonetically so that they sound proper. The text string that you enter is never seen by users, so you don’t need to worry about weird spellings.

If you don’t set a timeout option, callers will be offered the same menu again. I prefer this option, since there is no explicit keypress to repeat the menu choices.

Up next

Response Groups and Auto Attendants share some common features, but differ considerably with others. Up next,  a comparison of Auto Attendant and Response Group capabilities and functionality.