Microsoft has quietly released what I think is one of the most amazing features to ever hit Teams.

Head to https://admin.teams.microsoft.com and you’ll see a widget that looks like this:

Click on one of the 5 topic areas on the left. Let’s stick with voice. On the right, you see a list of common issues. “Dial pad is missing” comes up All. The. Time. So, click on it.

You’ll see a nice long sidebar menu:

And how awesome is this? There are “Insights”, letting you know what’s required for the dialpad to be visible. There’s also recommended articles for deeper learning. And finally, right up top is a lovely area where you can enter the username or email address for your problem user and Teams will diagnose it for you, letting you know if it’s found something that’s wrong.

Now, this isn’t perfect. For example, the insights list “make sure the user has a calling plan assigned”, and that would only be true for Calling Plan users, and not Direct Routing or Operator Connect users. If you’re not a Calling Plan user, you reaaaaly don’t want a calling plan license assigned. And if you’re a Direct Routing user, you need to make sure you have a Voice Routing Policy assigned, and that needs to be a valid Voice Routing Policy, and not just some random placeholder you’ve created.

However, I still feel that this is an absolute goldmine for organizations and admins new to Teams, and also grizzled veterans like myself. I will absolutely head here first if I have a user with no dialpad, rather than splunk around inside Teams looking to solve the problem on my own – I’m not lazy, I’m efficient!

If you have a large number of physical phones for a Teams deployment, you may have some logistical challenges in getting the phones deployed at cutover time. This could be physical access to a building, not having enough staff, or significant travel time between sites.

Layering users on top of that, you have further complications – the users need to be present in order to logon, especially with 2FA (you ARE using 2FA, right?). From experience, I can tell you that users will not be at their desk when you need them to be, so you will always need to plan to handle these exceptions.

There are a few ways to arrange things to make life as easy as possible.

If you are lucky enough to have free PoE ports so that you can deploy the phones ahead of a cutover, do that. This lets you get the users logged in before the cutover, and still maintain their existing phone. The old phones can be collected after the cutover – this doesn’t require technical staff to do, nor any particular schedule.

If you need to do a phone swap at cutover time, you may be able to pre-configure the user devices. You’ll need an office, room or space for this, at least 1 PC or laptop, and some PoE network capacity. Users can logon to a phone in this area or room, then label the phone so you know where it needs to be deployed later.

Staffing

Not having enough IT staff for a large phone deployment, or for a deployment in distant sites, is a challenge that often needs to be sorted. You’ll need to hire extra support or recruit some non-IT staff from the sites you’re deploying to. They’ll need to know the logon process for the phones, how to factory reset the phones (in case you need to “start again” with one, or if there’s a glitch), and to ensure the right jacks on the back of the phone are used (for the network and PC connections). This help could be all at cutover time, or you could use the phone pre-configuration approach followed by physical deployment, mentioned above.

If those options don’t work, you can help remotely. You may have to try and walk users through the steps over the phone. Have a PDF ready of the steps they’ll need to take, including a picture of the phone showing what keys they’d need to press/hold for a factory reset, what the ports on the bottom of the phone look like, and what the URL is that they’ll need to enter in their browser.  You could take a step up from the phone call and do a Teams meeting with video using a USB webcam, so you can see what they’re seeing and doing rather than trying to have them describe what they see. This same document and set of steps will be helpful for your helpdesk team for the initial deployment efforts, as well as for ongoing support.

And lastly, if it’s possible to have the phones logged in and to remain powered up, you should head to Teams Admin Center and push firmware updates. If this isn’t possible, then do play for firmware updates to be pushed at the end of the business day for the site(s) you’ve deployed.

When you’re configuring Microsoft Teams emergency calling, there are two end-user experiences. One is where Teams automatically establishes where the user is, based on network information that you’ve configured in Teams. The other is where the client depends on the OS location services and/or the user for a physical address.

For Teams to automatically establish your location, there are a number of pieces of network information that are required. The first of these is what Teams calls a “Trusted IP Address”. That’s maybe not the clearest name, but to be fair the name would get pretty huge if it was any more description.

A Trusted IP Address is any of your organizations public IP addresses that are dedicated, typically statically assigned. When a Teams client accesses Teams using one of these public IPs, Teams can trust that your client is inside your network. There are a few key points here:

Dedicated – The address cannot be shared like some cloud security services do, nor can it be dynamic and change at the whim of your ISP. Fixed IP addresses are typical, though we do sometimes see DHCP assigned “fixed” addresses.

Any – Yes any. Configure the entire range in Teams, not just one IP that clients typically use. This saves your bacon should the firewall guys change which IP clients egress from. It also means you’re covered if someone does something weird like plugging a phone into the server VLAN in the server room.

Trusted IP addresses are configured in TAC under Locations, Network Topology, Trusted IPs. If you click add, the dialog looks something like this:

Pretty straight forward! In the description field, put something meaningful to human. This has nothing to do with your location for emergency calling, but something meaningful like I’ve shown above is very helpful once you have more than one Trusted IP range.

If you’re a PowerShell fan, check out New-CsTenantTrustedIPAddress.

Note that your organization may already have assembled a nice list of these addresses in Azure for Named Locations in the MFA/Condition Access settings. You can spot-test if you’ve got an address in your list by having someone in a site browse to https://www.whatismyip.com. If their public IP address isn’t listed as a Trusted IP Address, you should first investigate if it meets the “dedicated” criteria above, then add it to the Trusted IP Address list.

I’ve been asked “If we monitor our dynamic public IP address for changes, can’t we just have a script run to update that in Teams?”. Well yes you could, except there will be a period of time for the IP change to work its way through Teams and down to all of the clients that require it. So, don’t do this. Instead, sites with dynamic public IP addresses will need to use the “work from home” or “External location lookup mode” as it’s more properly called. I’ve already posted a bit about this function, stay tuned for more.

It looks like it’s time to rename something at Microsoft again. Today’s change is Office 365 becoming Microsoft 365, especially around the Business plans that Business Voice packages work with, the first three on the list:

Despite some possibility for confusion with the “Premium” moniker shifting spots, I’m please to see “Basic, Standard, Premium”, which makes far more sense than “Essentials, Premium, Business”.

Remember that you can add Microsoft 365 Business Voice calling plans to any plan that has Teams, with the exception of the F series of licenses for Frontline workers. You can add up to 300 to any organization, then you need to step any additional users up to the fully Cloud PBX and Calling Plans(or Direct Routing)

And finally, Business Voice is coming to the US market as of April 1, 2020.

During one of those long, philosophical conversations with a colleague, we were discussing governance/guidance around the usage of channels vs chats.  That spawned a few other conversations Here’s what we came up with:

First, chats will store documents in the OneDrive for Business of the person sharing the file. Channels will store documents in the SharePoint library for the Team/channel. That could be impactful if you are applying different retention policies on the Team/channel.

One very adamant opinion was that if there is a Team that the post could possibly belong to, it should be posted there so it can be seen by other Team members, whether or not it’s felt that this is something they “need” to see. This was described as “working out loud” in another discussion on private channels.

To the contrary, others felt that only very specific “final” content should be posted to a channel conversation, and that “drafts” or “side discussions” should take place in chats.

A rule of thumb that one person uses, is that if the conversation is private or can be “easily forgotten” about by the organization without any impact, then a chat is fine.

In a discussion, someone felt that chats were useful to make sure that someone responded to an item, and that things would get lost in a channel. While this could happen, it was pointed out that use of @mentions should work to prevent the conversation from getting lost. Others contributed that there were still some misgivings or reluctance to @mention people in Teams (or even Outlook). Finally, it was mentioned that threads in channels provide for a much more scalable multi-conversation experience than multiple chats.

Another person commented that a chat might be used if you think the person you are contacting has the answer to a question, which a channel would be for a multi-person “help me! Who knows XYZ”.

Finally, one person compared the difference to Facebook wall posts vs a Messenger chat.

I love the concept of private channels. Working with Microsoft partners to deploy Teams solutions for customers, it’s a natural fit to have a Team per customer and then project based channels underneath that. Key staff from the customer are usually added as guests. With the release of private channels a few months ago, we can now have an “Internal Only” channel for discussions and drafts. Previously, we’d have to set up a second Team to achieve this same security boundary.

I was curious about what other organizations were using private channels for now that we’re a few months in. I posted on a social media, asked around at user groups, and here’s what I found:

For events, private channels can be used for speakers, or groups of speakers. Organizers or staff with different roles might have their own private channels. Overall though, Team members were able to access non-sensitive areas to promote “working out loud”, which serves as a sort of replacement for hallway conversations.

A managed services organization uses a Team per customer approach, with channels to organize various aspects of services for the customer. A private channel is used for internal conversations and planning.

Another use was to allow guests – from various partners or sub-contractors to interact with the main organization, or possibly each other, without needing to create numerous Teams. This approach does require that nearly every channel would be private, since there is no way to invite guests to just a channel.

Some organizations don’t feel that private channels are ready yet, and disable them. Reasons were around information protection and the ability to properly control their intellectual property. Others had concerns over “SharePoint Sprawl”, as each private channel gets its own site collection. Along these sames lines, one organization did like the lack of ability to “privatize” and “publicize” channels – they felt the lock-in once the channel was created could cause pain down the road if they made the wrong choice.

Others noted that some features, like Planner, are O365 group based and aren’t supported in private channels. Private channels (and “vanilla” channels) don’t have O365 groups, while the Team is O365 group based.

I think it’s fair to say that private channels are useful for many who need an administrative way to separate things. It’s likely also fair to say that private channels currently fall short of what other organizations need in terms of governance and compliance.

A significant decision for any organization looking to deploy Teams voice workloads is whether they will use Calling Plans, Direct Routing, or some combination of the two. I couldn’t find a decent comparison between the options, so I wrote this one.

Calling Plans

Calling plans are where your PSTN calling services are provided by Microsoft. Essentially, Microsoft becomes your telco (telephone company). Currently Calling Plans are only available in less than a dozen major countries, with no plans to roll out service to more.

Direct Routing

Direct Routing is where you connect a certified SBC to Microsoft Teams, and then any service you wish can connect to the SBC. This includes PSTN access from a telco, but can also include other PBXs (I’m looking at you Avaya and Cisco) or analog devices like enterphones/door buzzers and overhead paging.

Mix and Match

A user can be assigned a phone number from Calling Plans or Direct Routing. This is a per-user decision – Kim in cube 123 can be on Calling Plans, while Sam in cube 124 is on Direct Routing.

Note here that we’re talking about the user’s phone number. A user who’s PSTN services are provided by Calling Plans can use Direct Routing to reach an Avaya system or analog devices. Calling Plan users cannot be reached via the Direct Routing trunk. If an Avaya user calls a Calling Plan user, the call must be routed via the PSTN.

Here are some other comparisons:

If your organization is running Skype for Business and you’re trying to establish the easiest method to install Teams for your users, there’s a super easy one.

Head to the Teams Admin Center, Org Wide Settings, and Teams Upgrade. Under App preferences, you’ll see an option to have the Teams app download in the background for SfB users:

Turning this “on” will cause the Teams client to be downloaded to the PCs. This only happens, however, if the Coexistence mode for the user is Teams Only, or since maybe that’s too late, if you’ve enabled “pending upgrade” notifications in the coexistence mode settings:

setting this to “on” places a yellow banner at the top of the Skype for Business client to notify the user that they will be upgraded to Teams soon. (Note that this option isn’t available in my screenshot since my Tenant is already in Teams Only)

The Microsoft Office suite of clients offers integration with the default chat app, historically Skype for Business. This allows a user to interact with other users on that platform from within the office application, typically when co-editing, but largely throughout Outlook in features such as contact cards.

When you’re in a migration scenario, especially if you’re in Islands Mode, you’ll want to have Office pick one client over the other. You do this from within the Teams Client.

Click on your photo in the top right, then settings, then tick the box shown below:

And once you’re done this, make sure you restart Office. You may also need to wait a few minutes for the setting to take effect.

Note that if you switch to Teams-only mode, this setting is asserted for you – no need to manually configure it.

It’s not uncommon to have some combination of Skype for Business, Teams, and other PBXs in an organization, especially during migrations. One of the most challenging aspects in a scenario like this is maintaining call flow inbound from the PSTN, to the correct destination.

The magical way of doing this is to have contiguous blocks of numbers move from one platform to the next. In the real world, this almost never happens. That leaves us with the ugliness of static routing with a ton of rules to match the various number ranges and exceptions to them, or seeking some automated routing method.

One automated method is to have the SBC do a lookup in Active Directory, or some other LDAP directory. The SBC performs a lookup for the called number in a certain field, and can then look in a related field for that same user to understand the destination it should route the call to.

When a user is homed on a Skype for Business server, there phone number (lineURI) is stored in a field called msRTCSIP-LineURI. When an organization has just SfB server and another phone system, this allows for an easy “yes/no” decision. When there are multiple other phone systems, this task gets more challenging, as none of these other phone systems have a field like msRTCSIP-LineURI. This, by the way, includes Teams, which is rather ignorant of AD given that it’s a cloud platform.

There are a couple of solutions to this challenge. The first is for you to administratively populate the phone number and some sort of routing code/PBX identifier into unused fields in AD, AAD, or another LDAP platform. You can (but shouldn’t, yuck!) do this manually. Instead, populate these fields with scripting or another automated process. Now you can perform lookups and routing decisions based on the details that you’ve populated. However, you’ll need to keep these fields up-to-date with any adds/moves/changes to users and their numbers. This could mean that a user won’t receive their calls to the appropriate system until after an update completes.

A quick-and-dirty solution to this problem is to insert a series of alternate routes at the bottom of your routing table, that will try each of your phone systems in sequence, and if they receive a “404 not found”, they’ll roll to the next system:

At first glance, this table seems to duplicate things – why do we need row 5 sending to the Avaya system if row 3 sends to Avaya? We wouldn’t, if row 3 was always able to receive up-to-date, perfectly synchronized lookup data, and there were never any system errors. That’s not reality though, so placing rules 5-7 at the bottom to simply brute-force try all the systems is a nice catch-all.

The “dirty” part of this “quick-and-dirty” solution is that the SBC logs will see the 404 failure each time these rules are used. You’ll need to tune your systems to not throw alarms and freak out due to those, and you’ll need to do a bit of extra work when you’re doing any syslogs or call traces. Of course, a spike in the appearance of 404s in your logs indicates something broken, so don’t ignore them completely.

The noise of all of these 404 entries is also why I’d never recommend only using this type of logic in a production environment. Performance really doesn’t take a hit, but good luck trying to troubleshoot calls when all you can see in your traces is 404s. However, doing pure brute-force can be useful during a rapid migration where LDAP lookup results will never stay in sync. You can also shift the priority of your rules in such a scenario so that the system likely to receive the most calls is at the top of the routing list.