As Microsoft and their certified device partners gear up to bring more native Microsoft Teams IP Phones to the market the management and customization of the device experience is also being expanded upon.  This article introduces the current capabilities of a new PowerShell cmdlet created specifically to manage the user experience of these devices.

For some time the Set-CsIPPhonePolicy cmdlet has been available in the Skype for Business Online PowerShell module, which initially only applied to Lync Phone Edition, but was later also used with 3PIP-qualified devices (like VVX phones).  That cmdlet only controls a single globally-applicable set of parameters though, so it was not possible to create different sets of behaviors which could be applied to different groupings of phones.

With Microsoft Teams a new cmdlet named Set-CsTeamsIPPhonePolicy has been introduced, which is still included in the Skype for Business Online PowerShell module alongside all other Teams platform administrative cmdlets.  At the time of posting this article Microsoft has not yet published any official documentation for this cmdlet, but the functionality is already present in Office 365 tenants.

The most obvious change between the Skype IP Phone functionality and the what now exists for Teams devices is there is also a New-CsTeamsIPPhonePolicy cmdlet which allows the creation of custom policies in addition to the default global policy (which can be modified if desired).  This addresses a long overdue customer request to assign unique parameter values to different categories of phones, be it by location, department, use-case, etc.  Alongside this cmdlet is the requisite Grant-CsTeamsIPPhonePolicy cmdlet which is used to assign custom policies to individual user accounts.

Currently there is a very limited set of parameters available to actually control phone behavior, but the groundwork has been laid to start defining unique policies and then assigning these polices to user accounts to control their IP phone experiences.

Investigating the New Cmdlets

To take a closer look at this new capability launch PowerShell and import the Skype for Business Online module (if installed) as outlined in numerous articles like this.  Then list out the available cmdlets in the imported module that match the ‘TeamsIPPhone’ naming scheme.

  • Launch PowerShell and connect to Skype for Business Online using an account which sufficient administrative rights in the desired tenant.

Import-Module SkypeOnlineConnector
$sfbo = New-CsOnlineSession -UserName
Import-PSSession $sfbo

  • Enter the following command to list all available cmdlets matching the desired string.  Take note that the name of the module is dynamic and will be unique for every imported session, so use the name shown after successfully importing the Skype module (e.g. tmp_iwwu1ido.jpc).

Get-Command -Module tmp_iwwu1ido.jpc | Where-Object {$_.Name -like “*TeamsIPPhone*”}

The results should look like the following:


The five new cmdlets could logically be grouped as:

  • [Get|Set]-CsTeamsIPPhonePolicy – used to review and modify the parameters of an existing global or user policy.
  • [New|Remove]-CsTeamsIPPhonePolicy – used to create and delete user policies.
  • Grant-CsTeamsIPPhonePolicy – used to assign users to a specific user policy which will override the Global policy’s behavior.

Notice that there is no companion cmdlet for the ‘Grant-’ cmdlet.  This is because, like all other Skype and Teams policy-related cmdlets, the process to remove a user from an assigned user policy is simply to run the same cmdlet again, but instead assign the user to a $null policy.  Users can only be assigned to user policies and cannot explicitly be assigned to a global policy; assigning them to a null policy will return them to the default behavior of adhering to the global policy.

The next step into investigating the configuration would be to take a look at the default Global policy.

  • Run the Get-CsTeamsIPPhonePolicy cmdlet to list all defined policies and their current settings.



The default configuration in all Office 365 tenants should simply return a single Global policy with the parameters shown above.  As previously mentioned, the list of configurable parameters in these policies are currently quite limited.  In fact, at the time this article was written there are only two behaviors which can be controlled: the primary client experience via the sign in mode, and the inclusion of the Search function on Common Area Phones.

As best practices typically dictate it is generically recommended to leave the default global parameters as they are and create new user policies to customize any behavior.  Be aware that the only available policy types here are global and user, so if there is a behavior which would be deemed desirable for all users then it would be easier to manage this change at the global level then having to manually add every new user account in the tenant to a specific user policy.  This would likely become more applicable if/when future parameters are added here that make sense to modify at a tenant-wide level, as the available settings are not really good candidates for a tenant-wide change.

Now that some parameter values have been discovered the piece to uncover is what are the possible configuration options for these settings?  A simple way to find that out in PowerShell is to attempt to set a parameter to an obviously invalid value and when the cmdlet fails the error response will return the list of accepted values.

  • Run the Set-CsTeamsIPPhonePolicy cmdlet using a bogus value (e.g. NotARealParameterValue) for the SignInMode parameter

Set-CsTeamsIPPhonePolicy -SignInMode “NotARealParameterValue”


This invalid command has returned a list of possible values for the parameter which includes UserSignIn, CommonAreaPhoneSignIn, and MeetingSignIn.

  • Run the same command as above, but against the SearchOnCommonAreaPhoneMode parameter.

Set-CsTeamsIPPhonePolicy -SearchOnCommonAreaPhoneMode “NotARealParameterValue”


This parameter is a simple ‘on/off’ switch as the only possible values are Enabled or Disabled.

Sign In Mode

What the SignInMode parameter controls is essentially the overall user experience on the Teams device Android client.  There are three different options which provide three unique interfaces targeted at three specific, common use-cases: regular users, shared meeting rooms, and common areas.  The available parameter values are as follows:


The UserSignIn setting provides the full client experience which is typically targeted for regular phone users.  Unless any changes are applied to the tenant using the cmdlets and guidance in this article then all user accounts signing into all Teams IP phones will receive this experience as the default global policy is set to this value.

The latest phone software no longer prompts the user during sign-in to select if they want a Personal or Shared experience (as outlined in a past article).  The account type which is signing into the phone does not matter, so whether it is a user mailbox or room mailbox or if it has been enabled in Skype for Business using the CsMeetingRoom cmdlet set is irrelevant.  Additionally, the type of Office 365 license applied to the account has no effect here either.  Thus, an account configured as a room mailbox and assigned a Common Area Phone license (which is a bad idea for other reasons) will still show the full client experience when signing into a Teams phone in this example tenant based on the fact that only the single global policy exists which is set to UserSignIn mode.  In short, the overall client experience is controlled only by this PowerShell policy, and nothing else.

This mode provides the full client experience which includes the Calls, Calendar, and Voicemail screens, the Search button, the Call Park button, and the New Meeting/New Call buttons, as shown in the following screenshots from a Poly CCX 600 phone.







Note that the screenshots above are using the Dark Theme option, which is not the default appearance. Once a user signs into a phone then they can enable Dark Theme directly from within the client’s Settings menu; this is not a setting which is currently controllable by an administrator.


This setting is meant to be used on phones which are located in conference rooms where the primary use case is joining scheduled meetings.  In order to utilize this mode on a phone a new user policy must be created so that it can be assigned to the user account which will be signed into the phone.

  • Using the New-CsTeamsIPPohnePolicy cmdlet create a new user policy and configure the sign in mode for meeting devices.

New-CsTeamsIPPhonePolicy -Identity “MR” -Description “Meeting Room Phone User Policy” -SignInMode MeetingSignIn


  • Assign the new meeting room policy to the desired user account.

Grant-CsTeamsIPPhonePolicy -PolicyName “MR” -Identity “”

When logging into a Teams phone using this account the interface will default to showing only the Calendar view, and the Dial button if the account is Enterprise Voice enabled with the requisite Phone System licensing.  Some of the available options in the client are hidden from the user, like the Sign Out menu item has been relocated to the Settings > Device Settings > Admin Only menu which is password-protected.  The Search button is still available, but the Call Park button has been removed.

The following screenshots where taken from a Poly Trio 8500 using the account which was added to the Meeting Room policy in the previous steps.  For comparison’s sake images from both the default theme and dark theme are shown below.

image     image


This setting provides to most restrictive user experience intended for phones in common areas which may even be placed in public area.  In order to utilize this mode on a phone another new user policy should be created so that it can be assigned to other user accounts.

  • Using the New-CsTeamsIPPohnePolicy cmdlet create a new user policy and configure the sign in mode for common area devices.

New-CsTeamsIPPhonePolicy -Identity “CAP” -Description “Common Area Phone User Policy” -SignInMode CommonAreaPhoneSignIn –SearchOnCommonAreaPhoneMode Disabled


The SearchOnCommonAreaPhoneMode parameter can be set to either Enabled or Disabled, whichever is preferred.

  • Assign the new common area policy to the desired user account.

Grant-CsTeamsIPPhonePolicy -PolicyName “CAP” -Identity “”

When logging into a Teams phone using this account the only the dial pad will be displayed along with the Call Park button. The Search function can selective be hidden or shown via the other setting in the policy.

image     image

  • To allow the Search function to be used on Common Area Phones simply modify the newly created user policy to enable that feature.

Set-CsTeamsIPPhonePolicy -Identity CAP -SearchOnCommonAreaPhoneMode Enabled

Once the policy change is picked up by the phone it should display the Search button.

image     image

Review Configuration

  • To view the existing policy configuration simply run the Get-CsTeamsIPPhonePolicy cmdlet to list all defined policies and their current parameter values.



  • To quickly check which users have been assigned to a user policy run the following command to list all users in the tenant, showing only the User Principal Name (UPN) and TeamsIPPhonePolicy parameters.  (Users with no value set for the phone policy will adhere to the Global policy.)

Get-CsOnlineUser | ft UserPrincipalName, TeamsIPPhonePolicy


By Jeff Schertz

Site Administrator

43 thoughts on “Managing Microsoft Teams Phone Policies”
  1. Thank you Jeff for the detailed information! One question, when trying to grant the CsTeamsIPPhonePolicy to a room resource it doesn’t seem to take as the phone (Trio 8500) keeps defaulting to “UserSignIn” experience. When running the below nothing shows up for the CsTeamsIPPhonePolicy.

    Get-CsOnlineUser -Filter {DisplayName -eq “Resource Name”} | Select-Object DisplayName, UserPrincipalName, CsTeamsIPPhonePolicy

    1. The object name is “TeamsIPPhonePolicy”, so you need to remove the ‘Cs’ from in front of it in your Select-Object cmdlet. The policy will apply to the account during sign-in regardless of whether it’s configured with a user mailbox or resource mailbox.

  2. So this has answered so many questions about the latest firmware for the Poly Trios. However, after setting this policy on a specific account and restarting the phone, the Shared experience is not what is set. What else has to be done? I’ve waited almost 2 hours since applying the policy but no luck so far.

    1. As with anything in Teams give it at least overnight before you give up. I’ve seen changes replicate quickly, while others take many hours. That being said I just tested on an account after around 2 hours and the Trio is in Meeting sign-in mode as expected.

  3. You’re a life saver, Jeff, thank you.

    I spent two months with Microsoft and Yealink support reps on why our phones weren’t logging in as Common Area or Meeting Room and this post was the solution. Applied the policy, waited about 3 hours, and finally a phone and account that work as intended.

    1. Yes, the Trio should appear under Devices appear in the Teams Admin Center, but this might not be in your tenant yet as the phone management solution is rolling out in Teams.

  4. I can’t find a suitable place to inquire about polycom cx600. Polycom cx600 prompts “Poor network conditions are causing audio quality issues”. Based on what standard is this error prompt thrown?

    1. Jeff this is awesome! thank you! Is there any progress on coming up with better together capabilities for native Teams phones?
      Thanks again!

  5. Is there a way to allow rooms set to use MeetingSignIn to still allow the user to view the meeting comments? We still use Zoom heavily which puts all the dial information in the meeting comments. We’re using Yealink CP960s.

    1. Joel, no. It appears that in the Meeting Room view the calendar items cannot be opened like they can in User mode. It seems that only Teams (Join) and Skype (Call) meetings are actionable on the phone. Hopefully Microsoft addresses this an update as it seems a bit crippling.

  6. Awesome write-up! Just a couple questions tho:
    If you assign the MR policies decribed her to a Room account AFTER its setup, will it apply wautomagically, or does each user need to sign out & sign back in.

    Also, are new MR or CAP per-user policies assigned to specific accounts expected to be visible in the Teams Admin Center (Users -> Select Room Account -> Policies Tab -> Assigned Policies -> Team Policy section)? Or can it only be seen via powershell using Get-CsOnlineUser -Identity | ft UserPrincipalName, TeamsIPPhonePolicy

    1. They changes should automatically apply after some time, but I’ve had to reboot a phone to seemingly expedite it as well. There’s no documentation on the behavior so it appears to fall into the “just wait longer” category. These policies can only be seen/modified via PowerShell; they are not visible in the Teams Admin Center and I don’t know if there are any plans to do so.

  7. Hello Jeff,

    I am running Native mode and it requires Microsoft Intune to work. Does your implementation include Intune, and if not how did you bypass that? Also my only issue seems to be getting the Meeting tab up and running, I can only see the magnifying glass in Shared mode and Calls and voicemail in Personal mode. Any help would be appreciated. Great column by the way.

    1. I’m not sure what you mean by it requires Intune to work. I’ve used the client to sign into tenants without Intune licensing and with user licenses which do not include the Intune app. Are you receiving a specific error?

  8. You have no idea how much this single article has saved dozens of hours of experimenting on my end Jeff, thank you very much.

    I have one question which you may or may not be able to answer – when an ipphonepolicy is set to the UserSignIn Sign In Mode, is there any way to restrict someone from accessing the touchpanel of the phone and deleting meetings that that phone/meeting room has been invited to? Want to avoid having to go to the MeetingSignIn Sign In Mode if possible ….

  9. Jeff, Like others before me, this article has saved so much work and ended a lot of pain trying to figure out why the CCX400 wouldn’t work as a common area phone and remove the Search, Calendar,etc. It was my Poly Team that found this blog and helped me. Something that has happened since programming the Common Area Phone policy is that I have no DialTone (sound)., I pick up the handset, the display comes to life, but not dial tone. I can successfully enter a phone number and hit the dial button and it makes a phone call.. It can also receive calls. Just no dialtone. — And Thoughts? – David

  10. Hi Jeff,

    I’m looking to add a phone book to the CAP phones with internal users and some external company tel numbers. would that be possible?

    I have a Yealink CAP configured now but users do not remember phone numbers anymore. the want a corporate phone book in it

    1. No, the Common Area Phone interface on the Teams phone client does not provide contacts or favorites. You can leave the Search function so users can search the directory, but to have a list of contacts shown the user signed into the phone would need to be reverted to the User sign-in mode. That would not likely be ideal though as the Call history, Calendar and Voicemail tabs would be shown.

  11. This is a great write up. I used it to configure the meeting room policy and applied to my CP960 phones. I can’t seem to figure out how to send the conference phone a meeting invite to reserve time though. Do I need to give it different licensing or is there something in a config?

    1. When using the Meeting Room license you’ll need to leverage the free Exchange Online ‘resource’ mailbox configuration. If the user account had previously been setup as a user mailbox and had a license which included Exchange Online licensing then assigning the Meeting Room license to that account would disable the user mailbox.

  12. Just so you know, this blog post has been my bible recently as I get our Common Area Phones and Meeting Room Phones and User Phones set up in the office. Thank you sir for sharing your wisdom.

  13. Thank you Jeff on a great article. The question that I have and I couldn’t find the answer is regarding CAP and licences. As per MS, when you are getting CAP license, you need calling plan as well ( Unless you are using direct routing). Does that mean if I don’t have calling plan for CAP licences, my users in the common areas won’t be able to receive calls or dial out? CAP license + Calling Plan is pretty much same cost and Business Voice License, so I don’t see the advantage of CAP license. Thank you on your reply.

    1. That is correct, without a calling plan or direct routing then the phone is limited to calling within the Teams ‘world’ and cannot communicate with PSTN. The Business Voice license is not a core license, it’s an add-on license. You’ll still need a core license (like E1, CAP, Meeting Room, etc) for the user account which includes Teams.

  14. Hi,

    I have Poly phone and as soon as I click sing on it gives an error certificate is missing. I understand it requires company portal to be installed or something as per the guide but how to do that one physical poly phone or what is the work around.

    Thank you,
    Nilay Vyas.

  15. Hi Jeff – You are probably aware of this, but last week Microsoft made a change to how TeamsIPPhonePolicies work. As far as I know this change was not communicated, documented or published anywhere. TeamsIpPhonePolicies are now license driven.

    I’m working with a large enterprise that is deploying many common area phones (Poly CCX400s & CCX500s). They use a CAP license but we have been using a TeamsIPPhonePolicy in UserMode so they can see the People and Calls apps, not just the dial pad. A little over a week ago we started receiving feedback from users that their phones were now only showing the dial pad. We reviewed our policies, tested different firmware both via the TAC and on the devices themselves, factory resets, even other manufacturers phones, it didn’t matter.

    We opened up a support case with Microsoft and just yesterday they came back with this “To my knowledge, the accounts pull from the policy by what the license allows. If you have the correct licensing then the policy should be fine.”

    I pinged one of my contacts at Microsoft and they confirmed this change did happen last week. Thanks.

    1. Yep, I’ve been out of the office for a bit but I plan to write up an article explaining this in more detail when I have time. The change actually occurred with Update #2A which was released back on June 10th. Any phones which have had that 2A update pushed to them from the TAC will start exhibiting the new behavior, which is when a Common Area Phone license is assigned to the user that sign-into the Teams phone the CsTeamIPPhonePolicy SignInMode parameter used to define the phone’s user experience (UserSignIn, MeetingSignIn, or CommonAreaPhoneSignIn) is completely ignored.

      Microsoft appears to (a) be making it easier to provide the CAP UI to accounts without administrators needing to create and manage phone policies by simply looking at the license while also (b) limiting the ability for customers to use the cheaper CAP license for anything other than the standard CAP phone experience.

      I’m aware of some customers who have opted for the CAP license + UserSignIn mode as a way to access the People app, even if the Calendar and Voice Mail apps present errors as the CAP license does not include Exchange and mailbox/voicemail features are not supported for CAP licensed-users by Microsoft. Hopefully Microsoft will add some level of contact or Favorite integration in the CAP UI for the basic speed dial capabilities which many desire. Unless that happens though then a user license will need to be applied to the account to regain access to the UserSignIn mode.

      1. Thanks for the additional information Jeff! Yeah, my client falls into that category of using a CAP Lic and UserSign in and now this is causing major pain for end users working across 1400 branch locations. Thanks.

  16. Thank you for your blog and so great information.

    Do you know if it is a current known limitation that added external contacts (PSTN), while visible as speed dials for outgoing calls on the Desk Phones, are not recognised on Teams Desk Phones nor on incoming calls (when ringing) or in call history ? Just the PSTN number shows up. Very annoying ! It shows up correctly on Teams Desktop Client. It does not show up on ip phones (tested on Yealink MP58 and Poly CX700).

    Thank you !

    1. Yes, Microsoft hasn’t added that into the phone client so you’ll only see the PSTN number and not the Contact’s name. I don’t know if/when they plan to address that.

  17. How do i remove meeting room policy from any account ?

    Remove-CsTeamsIPPhonePolicy-PolicyName MeetingRoom -Identity “account name”

    This is not working for me

  18. The -SearchOnCommonAreaPhoneMode feature is flawed, all this policy does is remove the search icon from the top right corner of the display, there are 3 other ways to search the GAL if you have a speed dial, no speed dial and there are 2 ways to search the GAL with the policy set.. so I opened a ticket with Microsoft a few weeks ago, they have just come back and said this is “expected behaviour” for now. I will post another update when my ticket has been resolved and the search is no longer available

  19. Just a heads up to a possible issue which may crop up for others when updating the Teams Phones, possibly only with Yeallink devices.
    If you have Common Area Phone accounts which you have disabled the SearchOnCommonAreaPhoneMode policy within the CSTeamsIPPhonePolicy you will need to enable it for anything using Teams App Version 1449/ and above. If the policy remains disabled the the ability to forward calls with vanish.

    The Digital Dial pad may still be missing though

Leave a Reply

Your email address will not be published. Required fields are marked *