Microsoft Calling Plans: Policies, Validation, and Common Failures

What This Is

This is Part 2 of the Microsoft Calling Plans deployment walkthrough. Part 1 covered prerequisites, licensing, network readiness, number acquisition, and emergency calling. This article picks up where that left off — voice policies, validation, common failures, migration strategy, and knowing when Calling Plans aren’t the right tool.

If you haven’t completed Part 1, start there: Microsoft Calling Plans: Full Cloud Deployment Walkthrough.

Section 9 — Voice Policies

This is where the deployment becomes genuinely useful to end users — and where a lot of engineers move too fast and leave things misconfigured. Voice policies control how calls behave for every user in the tenant. Get these wrong and you’ll be fielding complaints for weeks.

Caller ID Policies

By default, Teams presents the user’s assigned phone number as their outbound caller ID. In most deployments that’s exactly what you want. Where it gets more complex:

  • Service number as caller ID — organizations that want all outbound calls to present a main line number rather than individual DIDs. Configure this through a Caller ID policy that overrides the user’s assigned number with a service number.
  • Anonymous caller ID — some roles (HR, legal, executive) may need to present as anonymous or blocked. Configurable per user through Caller ID policy.
  • Call queue and auto attendant caller ID — when agents return calls from a call queue, you may want them to present the queue’s number rather than their personal DID.

GUI path: Teams Admin Center → Voice → Caller ID policies → Add policy → Assign to users

PowerShell — create and assign caller ID policy:

New-CsCallingLineIdentity -Identity "MainLinePolicy" -CallingIDSubstitute Service -ServiceNumber +14025550100
Grant-CsCallingLineIdentity -Identity user@domain.com -PolicyName "MainLinePolicy"

Voicemail

Teams voicemail is cloud-hosted through Exchange Online. For Calling Plans deployments there’s no voicemail server to configure — it’s enabled automatically for licensed users. What you do need to configure:

  • Voicemail greeting — users set their own greeting through the Teams client or dial-in. Admins can set a default organizational greeting through voicemail policies.
  • Transcription — enabled by default. Can be disabled at the policy level if the organization has compliance concerns about transcribed voicemail content being stored in Exchange.
  • Call answer rules — how long before voicemail picks up, simultaneous ring behavior, and whether unanswered calls go to voicemail or another number.

PowerShell — configure voicemail policy:

Set-CsOnlineVoicemailPolicy -Identity Global -EnableTranscription $true -MaximumRecordingLength 300

Production note: Voicemail won’t work if the user’s Exchange Online mailbox isn’t provisioned. This catches people in hybrid environments where some users are still on on-premises Exchange. Verify Exchange Online mailbox status for every user before going live.

Call Forwarding and Simultaneous Ring

Users can configure call forwarding themselves through the Teams client. As an admin, you control the boundaries of what they’re allowed to configure through Calling Policy.

Key settings to review per deployment:

  • Allow call forwarding to external numbers — enabled by default, but some organizations restrict this for security or compliance reasons
  • Allow simultaneous ring to external numbers — same consideration as forwarding
  • Busy on busy — whether a second incoming call rings or goes to voicemail when the user is already on a call. Default behavior is to ring — most users prefer busy on busy once they’re aware of it

PowerShell — create a calling policy with restrictions:

New-CsTeamsCallingPolicy -Identity "RestrictedForwarding" -AllowCallForwardingToPhone $false -AllowPrivateCalling $true
Grant-CsTeamsCallingPolicy -Identity user@domain.com -PolicyName "RestrictedForwarding"

Outbound Call Restrictions

Control what numbers users can dial outbound. Common use cases:

  • Block international dialing for users who don’t need it — prevents bill shock on Pay-As-You-Go plans
  • Allow only domestic calls for specific user groups (front desk, shared devices)
  • Block premium rate numbers across the tenant

GUI path: Teams Admin Center → Voice → Outbound calling restrictions → Add policy

International Dialing

If users have Domestic + International Calling Plans, international dialing works out of the box. If they have Domestic only, outbound international calls will fail silently — the call attempts to route and returns a generic error. Make sure the calling plan matches the user’s actual needs before assigning.

For Pay-As-You-Go users who occasionally need international — verify coverage for the specific countries they’re calling. Not all countries are covered under every plan type.

Call Park

Call Park lets a user place a call on hold at a specific extension that any other user can retrieve — useful in environments where calls need to be handed off between staff without a warm transfer.

Call Park is disabled by default. Enable it at the policy level:

PowerShell:

Set-CsTeamsCallParkPolicy -Identity Global -AllowCallPark $true

Assign a call park range that doesn’t conflict with your dial plan’s extension ranges.

Delegation

Call delegation lets users designate other users to make and receive calls on their behalf — the classic executive/assistant scenario. Configure through Teams Admin Center per user, or at scale through PowerShell.

PowerShell — add delegate:

New-CsUserCallingDelegate -Identity executive@domain.com -Delegate assistant@domain.com -MakeCalls $true -ReceiveCalls $true -ManageSettings $true

Production note: Delegation is one of the more complex configurations to troubleshoot when it breaks. Document every delegation relationship at deployment time — when something goes wrong six months later, you’ll want that record.

Section 10 — Testing and Validation

Don’t declare a deployment complete until every item on this list is checked. Testing is not optional — it’s the difference between a deployment that holds up and one that generates a support call on day two.

Deployment Validation Checklist

Inbound PSTN

  • [ ] Call the user’s assigned DID from an external phone
  • [ ] Confirm caller ID presents correctly on the Teams client
  • [ ] Confirm the call rings on all expected devices (desktop, mobile, desk phone)
  • [ ] Confirm call is answered and audio is clear in both directions

Outbound PSTN

  • [ ] Place an outbound call to an external number from Teams desktop
  • [ ] Place an outbound call from Teams mobile app
  • [ ] Confirm outbound caller ID presents correctly to the called party
  • [ ] Confirm audio quality — no echo, clipping, or one-way audio

Voicemail

  • [ ] Let an inbound call go unanswered — confirm it routes to voicemail
  • [ ] Leave a voicemail and confirm it appears in the user’s Teams client and Outlook inbox
  • [ ] Confirm transcription is working if enabled
  • [ ] Confirm voicemail greeting plays correctly

Emergency Calling

  • [ ] Dial your country’s non-emergency test number to confirm emergency call routing is functional (do not dial 911 for testing)
  • [ ] Confirm the correct emergency address is registered for the user
  • [ ] For remote users — confirm they understand their registered address may not reflect their actual location

Mobile Client

  • [ ] Confirm Teams mobile app receives inbound calls
  • [ ] Confirm outbound calls work from mobile
  • [ ] Test on both Wi-Fi and cellular to confirm behavior

Desk Phones

  • [ ] Confirm physical desk phone registers to the user’s Teams account
  • [ ] Confirm inbound and outbound calls work on the physical device
  • [ ] Confirm hold, transfer, and voicemail access work from the physical device

Auto Attendants

  • [ ] Call the auto attendant’s service number from an external phone
  • [ ] Navigate all menu options and confirm routing is correct
  • [ ] Test after-hours routing if configured
  • [ ] Confirm the greeting plays correctly

Call Queues

  • [ ] Call the call queue’s service number from an external phone
  • [ ] Confirm agents are receiving calls in rotation
  • [ ] Let a call overflow and confirm overflow routing works
  • [ ] Test hold music and queue position announcements if configured

Call Transfers

  • [ ] Perform a blind transfer to an internal user
  • [ ] Perform a consultative transfer to an internal user
  • [ ] Transfer to an external PSTN number
  • [ ] Confirm the transferred party hears the correct caller ID

Policies

  • [ ] Confirm caller ID policy is presenting the correct number for each user group
  • [ ] Confirm call forwarding restrictions are working as configured
  • [ ] Confirm outbound call restrictions are applied correctly
  • [ ] Confirm delegation is working for any executive/assistant pairs

Production note: Run this checklist from multiple locations — office, remote, mobile. A test that passes from the office Wi-Fi can still fail for a remote user on a different network path. Test the deployment as users will actually experience it, not as you experience it from the IT desk.

Section 11 — Common Deployment Failures

This section exists because these problems are predictable. If you know what to look for, most of them take minutes to fix. If you don’t, they take hours to diagnose.

User Licensed but Enterprise Voice Disabled

Symptom: User has Teams Phone Standard and a Calling Plan assigned. They can see their number in the Teams client but cannot make or receive PSTN calls.

Cause: Enterprise Voice was never enabled after license assignment. Licensing and Enterprise Voice enablement are two separate steps — the license does not automatically flip the switch.

Fix:

Set-CsPhoneNumberAssignment -Identity user@domain.com -EnterpriseVoiceEnabled $true

Number Assigned Incorrectly

Symptom: User’s number appears in the admin center but calls to that number don’t ring, or the user can’t dial out.

Cause: Number assigned to the wrong object type, number assigned without a location ID, or number assigned before Enterprise Voice was enabled.

Fix: Verify assignment type, location ID, and Enterprise Voice status together:

Get-CsOnlineUser -Identity user@domain.com | Select-Object LineUri, EnterpriseVoiceEnabled, OnlineVoiceRoutingPolicy

Voice Routing Policy Mismatch

Symptom: User can receive calls but cannot make outbound calls, or outbound calls fail to specific number ranges.

Cause: Voice routing policy not assigned or assigned incorrectly. Misconfigured outbound call restriction policies or missing PSTN usage records can produce this behavior.

Fix: Verify the user’s assigned policies:

Get-CsOnlineUser -Identity user@domain.com | Select-Object OnlineVoiceRoutingPolicy, TeamsCallingPolicy

DNS or Network QoS Issues

Symptom: Calls connect but audio quality is poor — choppy, delayed, one-way audio, or frequent drops.

Cause: Network issues masquerading as Teams issues. Most common culprits: firewall blocking UDP and forcing TCP fallback, QoS not implemented, VPN hairpinning for remote users, or inadequate bandwidth on the path to Microsoft.

Fix: Run the Microsoft Network Assessment Tool from the affected location. Check firewall logs for UDP blocks on ports 3478-3481. Verify split tunneling for VPN users. Implement QoS if not already in place.

Firewall Inspection Breaking Media

Symptom: Calls work on some networks but not others. Often reported by remote users or users in branch offices with different firewall policies.

Cause: Deep packet inspection (DPI) on the firewall is intercepting Teams media traffic, adding processing latency to every packet — enough to push jitter above the threshold where it becomes audible.

Fix: Create a bypass rule for Microsoft’s IP ranges and Teams media ports. Teams media should never traverse DPI.

Incomplete Number Port

Symptom: Some numbers in a ported block work, others don’t. Or a number that was supposed to port didn’t transfer on the scheduled date.

Cause: Partial port completion — some DIDs transferred, others didn’t due to carrier-side issues. Or the port date passed but numbers weren’t assigned to users after transfer.

Fix: Check port order status in Teams Admin Center → Voice → Port orders. Contact Microsoft support with the port order ID if numbers transferred but aren’t appearing in the tenant.

Calling Plan Region Mismatch

Symptom: User can’t make calls to specific countries, or Calling Plan options don’t match what was quoted.

Cause: The user’s usage location in Azure AD is set to a different country than where they actually are. Calling Plan availability and number types are tied to usage location.

Fix:

Set-MsolUser -UserPrincipalName user@domain.com -UsageLocation "US"

Section 12 — Migration Strategy

How you sequence a Calling Plans migration matters as much as the technical configuration. A poorly sequenced migration creates more support calls than any misconfiguration.

Pilot Group First

Never migrate the entire organization at once. Start with a pilot group of 5-10 technically tolerant users who understand they’re testing a new system. Get their honest feedback on call quality, voicemail, mobile behavior, and anything that feels different from the old system. Fix what needs fixing before you roll out to the rest of the organization.

Good pilot users:

  • IT staff or technically comfortable employees
  • People who make a moderate volume of calls — enough to test thoroughly but not so many that a problem is catastrophic
  • Users across different physical locations if the deployment is multi-site

Bad pilot users:

  • The CEO
  • The executive assistant who manages the CEO’s calls
  • The receptionist who handles every inbound call for the company
  • Anyone whose phone problems immediately become everyone’s problem

Never migrate the executive assistant workflow first unless you enjoy emergency conference calls at 7am.

Staged Migration by Department or Location

After the pilot group, migrate in logical groups — by department, floor, or location. This approach limits blast radius if something goes wrong, lets you validate configuration at each stage before moving to the next, and gives you a natural rollback boundary if a group has issues.

Keep the old system running in parallel until each group is fully validated on Teams Calling. Cutting the old system before validation is complete is how migrations turn into incidents.

Coexistence Period

During migration, some users will be on the new system and some on the old. Document who is on which system at every stage. Make sure the helpdesk knows the migration status of every user so they can route support calls correctly.

For organizations migrating from an on-premises PBX, ensure internal extension dialing between Teams users and PBX users still works during coexistence. This is often overlooked until the first complaint.

Rollback Plan

Define rollback criteria before you start. If more than a defined percentage of users in a migration group report call quality issues, or if a specific business-critical workflow breaks — what’s the trigger to pause and roll back?

Having that decision pre-made means you don’t have to make it under pressure at 4pm on a migration day.

Executive Users — Last, Not First

Migrate executives after the system is proven stable with lower-risk users. By the time you migrate executives, you should have already resolved every common issue the pilot and departmental groups surfaced. Executive phone problems have executive visibility — don’t give yourself that exposure on an unproven system.

Section 13 — When Calling Plans Are NOT the Right Choice

Calling Plans work well for a specific set of scenarios. Outside those scenarios, they create limitations that can’t be engineered around. Know where the edges are before you commit a customer to this path.

Complex call routing requirements Calling Plans are constrained by what Teams voice routing policies can express natively. If the customer needs routing logic beyond standard auto attendants, call queues, and basic forwarding — Direct Routing is the right tool.

Analog device requirements Calling Plans have no path for analog devices — fax machines, analog door entry systems, overhead paging, elevator phones. These devices need an Analog Telephone Adapter (ATA) connected to a SIP infrastructure. That means Direct Routing or a hybrid approach.

Survivability requirements If the customer needs phones to work during an internet outage, Calling Plans cannot help. Every call requires connectivity to Microsoft’s cloud. Direct Routing with a Survivable Branch Appliance (SBA) is the answer for organizations where continued voice operation during outages is a hard requirement.

Contact center integrations If the customer runs a formal contact center with workforce management, advanced queue analytics, or CRM integration at the telephony layer — evaluate whether that contact center platform supports Calling Plans as the PSTN path. Many enterprise contact center platforms are certified for Direct Routing but not Calling Plans.

International deployments in unsupported countries Microsoft Calling Plans are not available in every country. For multinational organizations where some countries aren’t covered, you’ll need a mixed approach — Calling Plans where available, Operator Connect or Direct Routing everywhere else.

Existing SIP carrier investment If the customer has a carrier contract with significant time remaining, or a SIP infrastructure investment they aren’t ready to retire, Calling Plans requires replacing all of that. Operator Connect or Direct Routing lets them preserve the existing carrier relationship during transition.

When you hit any of these scenarios, the conversation shifts to Operator Connect or Direct Routing. Both are covered in detail in the Operator Connect vs Direct Routing article.

Final Thoughts

A Calling Plans deployment done right isn’t complicated — but it is precise. The technical configuration is straightforward once licensing, network, and numbers are in order from Part 1. Where deployments fall apart is in the details: a policy left at default that should have been scoped, a validation step skipped because the schedule was tight, an executive migrated too early because someone wanted to show progress.

Use the checklist. Run the common failures section as a pre-launch audit before you declare anything done. And when something breaks after go-live — because something always does — the Symptom / Cause / Fix structure in Section 11 is your first stop before you open a ticket.

If you’ve worked through both parts of this walkthrough and Calling Plans turns out not to be the right fit for your customer, the Operator Connect vs Direct Routing decision framework is the logical next read.

Scroll to Top
SystemStackHQ — Footer