Phone System Administrator Accounts

Occasional Contributor

Greetings all,


As I further my evaluation of MS Teams use to augment or replace some or all of our PBX/Call Server functionality, I have questions about whether or not it is possible to limit those who administer it.


We currently have over 100 locations with stand-alone telephone systems that each provide service with over 300 telephones. That may or may not be large in your world, and certainly doesn't fully and accurately describe our enterprise, but I mention it to point out that we currently have hundreds of administrators caring for these systems all over the world. I'll give an example of what I'd like to be able to do, first by setting the scene.


We will likely use direct routing and will want users to dial 9+XXXXXXXXXX to dial off system. North American dialing will be easy to administer, but our overseas locations is where dialing restrictions or class of service will need to be managed closely. For example, I may want someone to have local dialing but not long-distance dialing, common in the PBX world and from what I can tell in MS Teams with the use of direct routing, easy enough to identify a digit string and point that to an SBC. I'm not looking for instructions on that, though if that is not possible please let me know.


1) Can I have a person with limited administrator privileges that only allow them to administer a group of users (the ability to make changes only for persons assigned to one overseas office)? For example, I would want someone to have the ability to change users' ability to call long-distance or local, but only for persons who work at a particular office that the administrator supports.


2) Can I limit the SBCs and administrator can configure calls to route to? For example, I may not want an administrator for users in London to be able to make changes that allow them to make calls off the Paris SBC. I will want those type of calls to be possible, but I may want to limit who can configure that type of routing.


I have a related question. Can a person have more than one CsOnlineVoiceRoutingPolicy assigned to them?


Thank you very much!

4 Replies
Best Response confirmed by ThereseSolimeno (Microsoft)



Re #1 - Not really. There are RBAC roles which provide limited configuration capabilities based on role membership, but as far as I know, a single RBAC role does not support scoping of those permissions to a group of users (such as a remote office location). It's all or none.


Re #2 - Once SBCs are input into Direct Routing they become available to be used globally, but usage in Outbound Routing is not active until someone adds the SBC/Gateway into the proper routing configuration. From what I know, if you have a user that is able to manipulate the Voice Routing configuration via RBAC, that applies to all configuration in Direct Routing. Again, all or none.


Re VoiceRoutingPolicy - No. Users can only be assigned a single VoiceRoutingPolicy. That is why it is important to include all potential PSTN usages and voice routes (including class-of-service restrictions and primary/alternate routes for SBC failover) in that single usage.


Re External Access Prefix (9 prefix) - This is supported. However, do not normalize the number such that the 9 appears in the dialed digits. Configuration should support allowing users to continue that legacy-PBX-trunk-habit, but proper E.164 routing configurations don't include 9+15555555555 as the normalized number the client dials. Proper configurations always stick to E.164-proper for any dialed number (+15555555555) and then you add/subtract digits as required on the Direct Routing trunk via CsTeamsTranslationRules or on your SBCs directly. It's a very common attempted shortcut to not do this, but trust me, it makes voice routing (especially global) so much easier if you stick to proper E.164. This advice has been true for a long time, even all the way back to OCS/Lync/SFB.



@Trevor Miller 


Great point on the 9 + dialing. When you say, "do not normalize" 9 dialing, do you mean we should have the E.164 digit strings explicitly defined but also have a  9 + option to catch those times when users dial that way? Is the expectation that users walking down the street in London or in the office using Teams on their mobile device or workstation should always dial the full E.164 number to call a local business, as in +44 XXXXXXXXXX?


On the VoiceRoutingPolicy, that's good to know. This could lead to thousands of unique VoiceRoutingPolicy configurations that would likely be a heavy lift up front with minimal ongoing maintenance as changes to privileges/restriction come up. Is that your experience? I can see that the naming convention must be important to have established at the beginning and strictly adhered to.


Thank you,




Re Dialing:

Your Dial Plans will have normalization rules that outline dialing habits for each of your locales. Normalization rules can be structured such that you could support if a user dials 9, then 1, then 10 digits for US NANPA. Or perhaps they only dial 1, then 10 digits. Or perhaps they only dial 7 digits where available for local calls. Or maybe they fully dial the E.164 number (after all, most cell phones support this today). What types of dialing habits will depend on country, city, whether you need short-digit extension, etc. Effectively you can support any number of dialing habits but the end result of all those rules should always be an E.164 number. In your example of a London number, no they do not have to dial E.164 - you could have normalization rules set up to allow 020 + 3XXXXXXX and it gets turned into +44 20 3XXXXXXX.


Re VoiceRouting:

Correct. The bulk of your effort is the planning and design of all the different Locales, Class of Services and Various Routes your calls need to take. You can choose to implement this logic directly within Teams (in the form of voice routing policies, pstn usages, and voice routes), or perhaps look at a solution from your Direct Routing SBC vendor. The SBC solutions offer capabilities around AD lookups or advanced dial plan functionality that may negate the need to have the control within Teams Routing configurations.


@Trevor Miller 


Great information that provides clarity to a number of uncertainties.


Thank you very much!