Securing Access to Your Voicemail

Skype for Business offered a few different ways to access your voicemail messages. As they were stored in your Exchange inbox, you could use Outlook to read speech-to-text transcriptions – assuming the message wasn’t too long, and the quality was good enough. You could also play the message in Outlook or a media player. Voicemail buttons in the Skype for Business client and deskphones dialed your voicemail. Lastly, you could dial in to the Exchange server using a Subscriber Access number. As a part of this dialin, you may have had to enter a PIN to authenticate you.

With Teams, Exchange UM is no longer used and has been replaced by Cloud Voicemail. One of the features that’s not present in Cloud Voicemail is the concept of subscriber access. Honestly I can’t say I miss it, with so many clients available that offer easier access to voicemail messages than mashing buttons to enter extensions and PINs, even if it were available I doubt that I would ever use it.

Along with Subscriber Access not being present in Cloud Voicemail, PIN authentication is also not implemented. This is because all other means of accessing your voicemail already require you to be authenticated.  This can cause some concern about voicemail being access from deskphones, but really there’s no change here in what you need to be doing from a security perspective. If you leave your desk, lock your PC and lock your phone. Yes, that’s two things that need to be locked and unlocked. Hopefully we’ll see a “better together” experience that provides for automatic phone locking and unlocking when the Windows/Mac/Linux system you’re on is locked or unlocked.

If you have a stand-alone phone that needs voicemail, then you’ll need to use the lock function on the phone.

And finally, note that emergency calls are permitted from locked devices.

Conference Entry Tones/Announcements

I was working a customer who wanted help setting up Conference entry tones and announcements. There isn’t actually a lot to setup:


These are found under Meetings > Conference Bridges > Bridge Settings.

The most important thing to understand is that these settings apply to dial-in users, and not those users who join conferences through a Teams client.

The first setting is to turn on or off entry/exit announcements. Typically, this is useful when a large number of people dial in to meetings, or when you want an audio indicator that someone has joined a meeting.

The second setting allows you to select Tones or name announcement. If you select the option for a name, callers are asked to record their name before they join the conference.

The PIN length setting establishes how long a user’s dial-in PIN needs to be. It’s important to note that this isn’t the phone lock/unlock PIN, nor is it a voicemail PIN (Cloud Voicemail at present, does not have PINs)

The last setting is straight forward – send an email to users if any of their dial-in settings change.

An important thing to note, is that the tone/name announcement is played when dialin users join a conference. If someone joins a conference via Teams client, no tone or name announcement is played. When a tone/name is played, all participants hear the tone. This means that if you are the conference organizer and have dialed in, you will only hear tones and announcements for other people who dial in. This can be less than ideal, however there is excellent roster functionality available in all Teams clients, including mobile.

And finally, note that these settings are not configurable on a per-meeting basis. They’re an all-or-none setting.

Update: It was announced in March 2020 that these settings will become configurable on a per-meeting basis!

Basic Calls with the MTR

Microsoft Teams Room Systems, MTRs, are excellent devices for joining Teams meetings. However, you’re not always going to be in a meeting when you need to make or receive a call on an MTR. It doesn’t always make sense to put a regular desk phone in the room or a speakerphone on the table. So what does the experience look like?

Receiving a call

Receiving a call is straightforward. First, you need to have a phone number assigned to the MTR, either through a Calling Plan or Direct Routing. Note that you don’t need to assign a phone number to your MTR if you’ll only use it in meetings. When the number is called, the device rings, and you hit the answer button and the call uses the MTR speakers and Microphone. This probably isn’t desirable if you’re in a meeting, so you can have a look at turning on Busy-on-busy.

Placing a call

Placing a call on an MTR is different than on a regular Teams phone. The major difference is that the call is placed via the audio conference bridge. This has two implications. First, an outbound call will consume minutes from your outbound conference minute pool. Second, the call will appear to be from the conference bridge number and not any DID that you’ve assigned to the MTR.

Teams Admin Roles

Teams, like SfB, has a concept of administrative roles. These roles control what you as an administrator can see and do. This helps secure the environment, and also simplifies things for the administrator. If you’re not in charge of Direct Routing, why even see that in the Teams admin center?

I didn’t understand the first post that tried to explain these roles, and while they’ve improved the explanations and role descriptions, I thought a more thorough explanation might help others out. Here’s what my investigate found.

The four roles and a brief outline of what they do are:

  • Teams Service Administrator. This role manages the Teams service, and also allows the creation and management of O365 Groups, which are a core foundation for Teams
  • Teams Communications Administrator. This role can manage call and meeting functionality within Teams.
  • Teams Communications Support Engineer. This role can manage communication issues within Teams by using advanced tools.
  • Teams Communications Support Specialist. This role can manage communication issues within Teams by using basic tools.

If you’re more of a visual learner, here is what the four roles would see in the Teams Admin Center:

Teams Service Admin…


Teams Communications Administrator


The Teams Communications Support Specialist and Teams Communications Support Engineer see the same thing in the menu:


However they see different things when they drill down into things. Here’s what the Teams Communications Support Specialist sees:


and here’s what the Teams Communication Support Engineer sees:


Note the highlight part, showing that the Engineer role sees more advanced details suitable for their role.

PowerShell tells us a similar story. Here, the Teams Communications Support Specialist has no access to PSTN or voice commands:

PowerShell Spec

While the Teams Service Admin does:


While these four roles don’t provide the same degree of flexibility and granularity (and complexity!) that was available in Skype for Business Server, you should ensure that you follow the principal of least privilege when assigning permissions to your support team.

Call Queues – Who can be an agent

Call Queues are the modern, online version of SfB Response Groups. A call comes in to the organization, and is queued and distributed to “agents” based on a number of factors.

One question that I get often is “who can be an agent in a call queue?”

The short answer is that only users can be agents. This means that Common Area Phones and Meeting Rooms cannot be agents. Well, they can, if you license them as a user. However, if you take advantage of the lower priced CAP or MeetingRoom licenses, then they cannot be agents in a Call Queue.

There are some other restrictions.

If you’re using a Direct Routing number for your Call Queue, your agents must be Teams users. If you use a Calling Plan number, you can use Teams, Skype for Business Online, and Skype for Business Server users.

If you want Teams agents, the agents must be in Teams Only mode. Calls are only handled by Teams apps when a user is in Teams Only.

Bonus: SfB Server Response Groups only offered calls to desktop clients, not mobile. That’s awesome if you assume that everyone who might be an agent is permanently planted in a chair in front of a desk, but that’s not reality! Call Queues allow calls to be offered to users logged on to a number of different devices – including mobiles – check out this doc for details.

(Note: this post has been edited to update it with capabilities made available soon after publication date. While I don’t normally update past blogs with new information, I felt it made sense given the timelines involved.

Updates are coming fast and furious at times from Microsoft. If you have thoughts on revising historical posts (or not!) I’d love to hear from you – hit me up in the comment section or find me on twitter @bumpinthenet)

Cool Tool – What is My Tenant ID

In an organization running O365, every once in a while you’ll need to jump through hoops inside O365 or Powershell to find your tenant ID. While it’s not that terrible, it’s certainly not speedy. If you’re a Microsoft Partner, you often need the Tenant ID for various Microsoft paperwork. It can be a hassle to collect this from your customer, or get credentials setup early enough in the engagement process with them. For you, this is a lifesaver!

The brilliant folks at ShareGate came up with Enter any domain name associated with your tenant – including the


and a few nanoseconds later:


Note that if your browser window is smallish, you may get an add that covers the ID and Copy to clipboard button, so hit maximize.

Cool Tool – UCDialPlans

If you’ve ever had the need to build a Skype for Business (or Teams!) dial plan, or sort out the regex for a number range, is your friend.

All around good Canadian kid Ken Lasko has been running this site for years. Got PRIs and need to route 7 digits to the telco vs 10 when it’s a local call? No problem, that’s just a tick box to let the optimizer know that it needs to dip into telco databases and see what exchanges are in your calling area. Internal extensions, trunk codes (9 for an outside line) and more are available.

Working with Cisco or AudioCodes gear? It can do those, too. There’s just so much stuff here, you have to go check it out (and be sure to donate a few bucks so Ken can keep building the awesomeness):


The site is well laid out and easily navigate by scrolling or the menu at the tab. Check it out, I’m sure you’ll find something useful there.


Cool Tool – Regex101

If you’re doing voice with Teams or Skype for Business, chances are good that you need to do regex. While some regex’s can get awfully complex, there are some basic ones that look like they should be easy, but are deceptively complex. If you’re writing your own regex, you should be testing it with at least these values:

  • The first number in the range
  • One less than the first number in the  range
  • The last number in the range
  • One more than the last number in the range
  • A number somewhere in the middle of the range

Well, that sounds like no fun at all if you have to place 5 test phone calls and check logs to make sure things worked. Sure SfB Server has some testing tools build into the control panel, but what about if you’re working on a Ribbon SBC or Microsoft Phone System?

Enter one of my favourite sites, Pop in your regular expression, enter your test value in the “test string” field, and if it turns green you’ve matched. On the right, you get a breakdown on the various elements in your regex, what each means, and if these individual bits match, and there’s a quick reference too – a great way to learn regex!

Here’s an example. The regex ^(12\d{2})$ is for the range 1200-1299, and I’m testing that 1299 is a match:


Pretty awesome stuff!


Where to put outside interface of an SBC

A frequent topic when I’m discussion SBC configuration for Teams with customers, is where the outside interface of the SBC should be located: the LAN, a DMZ, or “live” on the Internet. All of these options can work, so let’s take a look at the requirements and benefits of each.


Having the external interface of your SBC on your LAN can work, with a few important requirements. First, your physical external interface can’t be on the same subnet/vlan as your internal interface. This’ll cause all kinds of issues with traffic getting to the wrong place. You can have your logical internal and logical external interfaces share the same physical interface. You’ll need to also configure port ranges for signaling and media,  so there is some extra work. I don’t generally see this configuration for Teams, but do see it sometimes for Skype for Business server deployments where SfB is connecting to a PBX, or possible a telco via MPLS. Note that you can’t use one logical interface that is NATd sometimes and not NATd others – the SBC needs to insert your NATd IP into SIP packets, so you either NAT or you don’t, per logical interface. This configuration takes a lot of additional configuration, and it’s easy to mess up. I don’t recommend it if you can avoid it.

The DMZ/an “outside” subnet

This configuration involves having your Internal interface for connections to an existing PBX, and a second physical interface for connecting to Teams. This “outside” interface can be a VLAN or a firewall DMZ, anything that keeps it separate from internal traffic. Generally, the security guys insist on this being a DMZ connection and not a VLAN. You’ll need to setup 1:1 NAT on the firewall, or route public IPs into your environment for the SBC interface.

Another important step that’s regularly missed, is to disable any HTTP/HTTPS inspection, SIP helpers, SIP ALGs (Application Layer Gateways) or anything else that sounds, looks or smells like it wants to try and do something with the traffic. If your connection isn’t working, this is one of the first things that I would check. Fortinet, Cisco, Palo Alto, Juniper, all have these bits that need to be shut off. They simply don’t understand what the traffic is, and break it.

Live on the Internet

GASP! Who would ever connect an SBC live to the Internet? Well, lots of people. This is the simplest configuration that you can do. It doesn’t suffer from latency or HTTP/HTTPS/SIP “helpers”, firewall misconfigurations, or NAT issues. For those that say “it’s not secure”, well it sure is! Remember that an SBC is essentially a SIP firewall. It knows more about, and can do more things for SIP, than any general purpose/next generation firewall. SBCs typically include intrusion detection functions specific to SIP, and have robust host firewalls. Nobody is going to connect to the outside interface of your SBC on SSH, because you wouldn’t have it configured to do that, so there’s no need for a general purpose firewall to block SSH traffic. Okay, I picked on SSH here, but really, any port or protocol that aren’t SIP related.
It’s possible that your SBC will only be talking to a select few IPs (like an MS Teams configuration without Media Bypass), meaning that traffic from ANY other IP is simply dropped. While it’s possible that you’ll need to open things up – say if you turn on Media Bypass – the SBC is still going to inspect that traffic and ensure it’s valid. Again,  it’s a SIP firewall.


While the “Live on the Internet” configuration is a safe configuration with low administrative overhead, many security departments at organizations don’t understand enough about SBCs to understand that they are secure without a general purpose firewall in front of them. Typically this is a hill that I don’t want to die on, so I agree to having the SBC behind a firewall.

As much as possible, I avoid the one-interface solution “on the LAN” It requires more administrative effort, and is more confusion when you’re troubleshooting.