Microsoft Phone Numbers – What You Need To Know

I’ll be honest, until recently I haven’t really used calling plans with Microsoft Teams for Enterprise Voice. All my previous customers have been using a mixture on Direct Routing and Direct Routing as a Service, so calling plans where never really on my radar. But now I have a global customer who has jumped on the calling plan band wagon and going all-in in every country they can with Microsoft. Good on them! But it has thrown up a number of nuances with how Microsoft provide and manage your phone numbers that you need to be aware of.

This isn’t a bashing post about Microsoft, let’s get that crystal clear right now. Telephony is complicated especially at a global scale and Microsoft do well to provide you with a nice UX where you can just pay your money and get a phone number at a few clicks of a button. In reality, telephony is riddled with regulatory compliance and other red-tape on a country by country basis. It’s one of the main reasons calling plan expansion has stagnated in the past. Having to incorporate local compliance into a standardised platform I can only imagine is a nightmare for Microsoft. By and large they do a great job, but there are some cases where things spill over to the tenant side and ourselves as admins / implementers. Microsoft Docs does a good job of giving you the basics, but not everything is documented and this can lead to you scratching your head. This post I will go through what I have found on this journey. It might not be a complete thesis, it is only what i have encountered to date.

Getting Phone Numbers

This sounds simple right? You go to the Teams Admin Center, click on phone numbers, press Add, tell Microsoft where and how many numbers you need and away you go.. In most cases this is true, but in some countries the only way to acquire new phone numbers is to place an offline order with PSTN service desk using a standardised form. Here starts the complexity…

The form itself is generic, no matter what country you select you are always given the US standard form to complete

You complete the form and send it to the Service Desk for ordering. What will happen in some cases, Germany, Italy, Norway, Spain for instance the ones I have experienced so far is that PSTN Service Desk will ask you for more information upon submission, usually 2-5 days after you send your original order. The additional information will invariably be either a data consent form or requiring you to send them your Tax ID or Business Registration Number for your entity within that country. This is where the local compliance starts to come back to you. So, you end up responding and then 2-3 days after that your order will either be accepted or declined.

Really, Microsoft could fix this process by offering customised order forms for each country with all the required information they need on one form so that we can collect it and submit at once. Right now, it takes 7-10 days of back and to with additional information and email exchanges to get an order in.

After you have your order accepted, it can take anything from 3 days to 3 weeks to get the numbers fulfilled and available in the tenant. Unfortunately you are not given any proactive updates, so its really hard to plan enablements and migrations. In reality the delay for waiting for numbers is driven by the upstream telecoms provider in that country. Microsoft could do better with the initial documentation request to speed up the overall process in my opinion.

The 3 Variants

A subscriber number is a subscriber number right? Well, there are actually 3 variants of subscriber numbers that are not labelled or documented anywhere in the Teams Admin Center, and only 2 variants are documented in PowerShell. The variants are:

1. Microsoft Pooled Inventory Numbers – These numbers can be automatically acquired through the Teams Admin Center or PowerShell. Microsoft already own them and are available for acquisition.
2. Manual Numbers – These are requested by completing the order form directly with Microsoft PSTN Service Desk.
3. Ported In Numbers – Numbers which you previously owned with another telecoms provider and chosen to port to Microsoft

In the Teams Admin Center there is no way to determine numbers you have acquired through any of the above methods. In PowerShell, you can determine between Manual Numbers and the other 2 variants by looking at the “IsManagedByServiceDesk” flag on the number object is set to TRUE, then this number has come from a manual order.

For ported in numbers it seems to be hit and miss as to whether the PortedInOrderStatus flag is set to complete. I have ported ranges that say complete and also where this flag is null.

So why is this a problem I hear you ask?

It’s all to do with your total number allocation as calculated by the number of Calling Plans you own on the tenant. It is documented on Microsoft Docs that for every Calling Plan purchased you multiply by 1.1 and add 10 e.g 10 CP licenses equals 10 x 1.1 +10 = 21 numbers.

This calculation is only applicable to numbers that have been acquired using the Microsoft Pooled Inventory. Ported In Numbers and Managed By Service Desk Numbers are not counted in this calculation.

The issue presents itself when you are trying to secure enough numbers in each city / country to cover your migrations before you have a solid dataset to work from. For instance, you might have a site in Chicago that have e.g. 300 users. At the moment of project planning and knowing that in the case you might have to place manual orders you try and get ahead of the game and acquiring 300 Chicago numbers. Depending on availability, this maybe all pooled inventory or a mixture of pool and manual ordering. You do this for the first 3 or 4 sites you have planned and already you have a bunch of numbers in your tenant. Then you come to qualifying your dataset and you find that only a fraction of users in the site require a Teams voice number.

Whilst this is going on, simultaneously you are planning your next batch of sites which may include porting numbers and a whole bunch of manual and inventory acquisitions. At some point you are going to hit critical mass where the calculation says “No more numbers, please release some”.

No problem you’re thinking, i’ll just release unused numbers and voilla I am back in the game!

Not so fast.. Here’s the kicker

Numbers that have been acquired through the PSTN Service Desk can in some cases be released by Teams Admin Center or PowerShell. I say some, because in Germany for instance, regulatory compliance means you cannot simply give back individual numbers to Microsoft within the range you ordered manually. You have to keep them, or give back the entire range. The Remove-CsOnlineTelephoneNumber command will appear to work, but the numbers are not removed from your tenant.

Furthermore, if you release numbers that have the managed by service desk flag set to true, even though you release inventory, they do not count towards the pooled inventory calculation in the tenant. This means if you need more numbers in the USA for instance, you can’t use the auto order function in TAC, you have to do a manual order.

This is the same for ported in numbers too. if you release them, it doesn’t give you any more availability in the auto inventory.

This is where the hit and miss issue on the PortedInOrderStatus flag is a big issue for me. Even though this may not be set, if you release a number from a ported in range that has this set to NULL, Microsoft still know its a ported number and you don’t get the credit back to order new numbers. Furthermore, it is very hard to distinguish within TAC or PowerShell what numbers were ported and what numbers came from pooled inventory unless you have a record of your purchase history to hand.

So when you hit your limit and decide to get numbers where portedinstatus is null and not assigned and then remove them, you can and will nuke numbers you’ve owned for years as well as Microsoft inventory numbers and what you get back will be a fraction of what you’ve released.

Calling Plan Nuances

Not specifically linked to phone numbers, but to calling plans themselves is calling destinations when you have a calling plan is not always what it seems. During my time with this customer I have come across only two instances of this happening, but it does not mean that the issue isn’t wider than this.

Issue one was a user with a domestic calling plan in Canada. Everything seemed to be working fine except calling outbound to his cell phone. When called, they got a system message telling them that they are not permitted to make the call. After some testing it seemed that there was a general issue dialling outbound to numbers belonging to a specific Canadian Mobile Operator. This has been resolved.

Another issue was a user with an international calling plan based in Italy. International outbound worked as far as they could tell until they tried to dial UK mobile numbers beginning with 074*. When attempted it would just fail without a system message. This only happened when the user location was Italy. Other countries worked fine. This issue was resolved and turned out to be a regex routing issue on Microsoft back-end. Again solved.

With the complexity of global dial plans these nuances are not surprising and you get them with other providers not just Microsoft. A support ticket to Microsoft will solve these issues and is something that just goes with being a telecoms engineer.

My Advice

Ok this post has been about what is wrong with calling plans, but I don’t mean it in a way that I think calling plans should be avoided, or Microsoft are ****. I wanted to set out the challenges I have faced in a relatively young service that is still learning at the same time as trying to give businesses a platform to continue to operate in a pandemic. If people from Microsoft are reading this post, I hope they take onboard some points to refine their service responses for the future.

But for now, you can take steps now to ensure that you have all the tools in your arsenal to make up for the shortcomings so that they do not affect your project timelines.

Here are my tips for getting along with calling plan numbers during a large scale migration that will help you keep on track

1. First, get all your site addressing information to hand at the start of your project. You’ll need Business Entity Name for each country you operate in, street address and Tax ID or Business Registration Number in that country. Put this into an excel document and store it in your project folder.
2. When you submit your orders to Microsoft Service Desk include alongside the number order form the information from point one, even if the form does not require it.
3. Never submit more than one order per email. Don’t think it is smart to bunch them all up and send them at once to service desk. Its harder to track and some orders are simply missed. One order form per email.
4. If you don’t hear back from Service Desk in 72 hours, send a chaser email
5. When acquiring numbers from the inventory automatically, once acquired, run Get-CsOnlineTelephoneNumber command filtering on the number range you have just acquired and export it to CSV. Add it to a master sheet and label them as acquired inventory.
6. When manual orders have been fulfilled, you will be told the number range allocated. Add this to your master sheet and label them as service desk managed.
7. When porting, submit one LOA per email its easier to track, but porting is another beast in itself, so for this post, add the ranges you are porting to your master sheet and label them as ported.

When it comes to having to release numbers to acquire more, refer to your master sheet and filter on the inventoried numbers. Use this sublist to determine unused numbers and then release them. This will make sure your release is more effective if you need to acquire more in another area / country through the pooled inventory method.