Common Area Phones in Microsoft Teams

April 29, 2020 by · 42 Comments 

The deployment and administrative experience for a Common Area Phone (CAP) across Microsoft’s UC platform has changed over the years as it has matured from an on-premises software release with Lync to hybrid offerings of Skype for Business only to eventually be replaced by the cloud-only Microsoft Teams solution.  Generally the ideal of a common area phone is just that: a phone located in a shared space which only needs to provide the ability to place phones calls to other users and/or phone numbers.  These are not meeting devices.

Thus a core trait of the common area phone scenario is providing basic calling capabilities and not much of anything else.  Essentially the requirement is just for ‘dial tone’ to facilitate placing outbound calls to other users in the same organization, other organizations, PSTN numbers, and/or emergency services.  Common spaces typically don’t have calls coming into them as usually no one would know who is in that space at a given time, less anyone at all.  These are phones which may be located in areas like break rooms, front lobbies, shared spaces, warehouses, factory floors, etc.  They are not tied to a specific person and thus features like contacts, voice mail, or a calendar are not really applicable.  Often the baseline requirement is for a phone that will always be registered so that emergency services can be dialed without issue or delay.  Then depending on the configuration and licensing of the account assigned to the phone various additional features could be made available, like searching for other users or placing non-emergency calls to local or even international numbers.

Throughout the Microsoft UC journey the common area phones have had a very deliberate distinction that there is no mailbox available to them.  This is the main reason that they should not be deployed in a typical conference room as without a mailbox there is no calendar, and without a calendar there is no way to invite that device to a scheduled meeting.  It would still be possible to manually dial into a meeting if the invitation includes an audio conferencing number, but the invite would still not be viewable on the phone itself to see the dial-in information.  In general common area phones should simply not be deployed in a space where users would need to join meetings.  Devices in those spaces should instead use a meeting room account configuration.


Back when IP phones were first introduced with Office Communications Server a common area phone option was not yet available.  No account configuration was provided nor any phone models designed specifically for that use-case.  When Lync Server 2010 was released Microsoft added a special account configuration to allow basic calling features on a phone without the unneeded overhead and licensing costs associated with voice mail or other mailbox-related features included with a regular user account.  This configuration leveraged an Active Directory Contact object which could not utilize traditional authentication methods, nor could they be mailbox-enabled. Thus Microsoft created PIN Authentication for Lync Server to provide a way to sign into a phone using contact objects.  At the same time Polycom also released an IP handset designed specifically for the CAP scenario: the CX500.  This phone was slightly smaller than the standard phone designed for regular users and did not come with the USB-B port required to leverage the ‘Better Together’ pairing capability with a PC which allowed for basic user authentication.  This limitation meant that only PIN Authentication could be used on the phone.

The same capabilities and behavior were included in Lync Server 2013 and Skype for Business Server 2015 so there was no change to how common area phones worked with on-premises deployments.  There was a shift in the device options though as newer phones came to market leveraging Microsoft’s 3rd Party Interoperability Program (3PIP) and there were no longer any models built only for CAP use-cases by any of the partners.  The idea was that all phones in their product families could be signed in using any of the supported authentication models so in essence any phone could be a common area phone or an executive desktop phones.  Typically the lowest-cost handset, like the Polycom VVX200, would be selected to pull CAP duties.

A completely different approach was used for common area phones with Skype for Business Online though.  The method used for on-premises server deployments required a specific DHCP configuration for PIN Authentication to function which meant that common area phones could only be located on internal corporate networks or across site-to-site VPNs.  That authentication model could not apply to the cloud so a new solution was created for Skype for Business Online called Web Sign-In.  This addressed the main benefit of PIN Authentication in that it allowed users to sign into a phone without entering their user credentials (username and password) directly into the phone.  With PIN Authentication a user simply entered their phone number or extension and their PIN directly onto the phone via the keypad.  In contrast the Web Sign-In model a provides a login option on the phone which displays a unique code and instructions to go to a specific website on any other device like their computer or smartphone.  There they would enter their own credentials (if not already signed-in on that workstation) as well as a one-time use code provided on the phone’s screen.

Because capabilities in Skype for Business Online are based on Office 365 licenses more than the actual account configuration itself then Microsoft also added a new Common Area Phone license option which should be assigned to a regular user account; there is no special CAP contact user configuration available in the cloud like there was in the server platform.  This new license provides a more cost-effective option than purchasing the Skype for Business Online Plan 2 standalone license in addition to a Phone System (formerly Cloud PBX) add-on license. It is also much cheaper than using an Enterprise license on a phone which does not need 99% of what an E1 or E3 license includes. Note that there is no Exchange license provided which continues the theme of no mailbox-related capabilities for a CAP account.


With Microsoft Teams the same approach and the exact same Common Area Phone license is used.  Unlike with a Meeting Room license, Intune is not included and would need to be purchased as a separate add-in if these devices would need to also be managed from Microsoft Endpoint Manager.  (An Intune license is not required to manage devices from directly within the Teams Admin Center.)

Based on all of the detail provided thus far then the most important concept to understand here is what actually defines a Common Area Phone in Microsoft Teams?  The answer is multifaceted as it is not just a specific phone model, or user account type, or even the license applied to the account.  Minimally what makes a Common Area Phone is a phone policy assigned to a user account which drives the user experience on the device itself.

To illustrate this primary difference the three possible user experiences the phones can provide today are shown here.

  • The first is the default User mode which provides Calls, Calendar, and Voicemail screens used by regular user accounts.
  • The second is the Meeting mode which limits the phone to the calendar view, yet still allows for placing calls.
  • The third is the Common Area Phone mode which only provides phone calling features.

image      image      image

Note that any user account can be placed into a CAP experience by applying the appropriate policy, but if a user account assigned a Common Area Phone license is left to use either the default user mode or configured with the Meeting mode then the phone will display various errors due to lack of mailbox availability.

Thus, using a Microsoft-supported user account configuration, granting the correct phone policy, assigning a cost-effective license, and optionally limiting calling features are what really makes for a proper Common Area Phone deployment.

The remainder of this article will walk through configuring a Microsoft 365 tenant and then creating single user account to enable the Common Area Phone experience on a native Microsoft Teams phone.  Note that this is applicable to both Desk Phones and Conference Phones.

Tenant Setup

Before setting up a user account the tenant must have available licenses and an IP phone policy configured to enable the CAP phone interface.  The Microsoft 365 Admin Center and Teams Admin Center (commonly referred to as the ‘TAC’) are utilized throughout the configuration steps whenever possible, only reverting to using PowerShell for actions which are not currently available in any online admin center.  All PowerShell cmdlets used in this article are currently included in the Skype for Business Online PowerShell module.  (Nearly all of the steps shown in this article could be performed using PowerShell cmdlets if desired.)

Acquire Licenses

While the Common Area Phone license is ideal here, as explained earlier, it is not a requirement.  Any license(s) which include(s) Microsoft Teams and Phone System are sufficient.

If the Microsoft 365 tenant already includes the desired licensing then skip to the next section to begin configuring a user account.

  • In the Microsoft 365 admin center browse to Billing > Purchase services and then search for ‘Common Area Phone’ which should then appear under the Collaboration and communication section.
  • Select the Common Area Phone plan and then choose from either the Buy or Get free trial (if available) options.


  • Complete the ordering process for whichever option was selected and then go to Billing > Licenses to verify that the new licenses have been applied to the tenant.  (Normally this should apply immediately to the tenant but it can take a few minutes before seeing them listed.)


    Configure Phone Policies

    Simply assigning a Common Area Phone license to a user account will not apply the Common Area Phone experience as licenses only control what online services and features are available to the account.  A custom IP phone policy must be setup in the tenant and then assigned to this user account in order to control the user experience on any phone it signs into.  These policies are currently only configurable via PowerShell and are assigned to user accounts (not to devices) at the global level (by default) or the user level.

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

    First determine if a common area phone sign-in policy has already been created in the tenant.

    • Execute the Get-CsTeamsIPPhonePolicy cmdlet to list any policies currently defined in the tenant.



    The example results above show the default configuration for M365 tenants and is likely what will be seen if this is the first time going through this process.  Over time new parameters may appear in this policy as Microsoft adds more capabilities into Teams.  For example, the Hotdesking parameters seen in the output above did not exist at the time this screenshot was captured for a previous article.

    If a custom user policy with the SignInMode set to CommonAreaPhoneSignIn already exists in the tenant then skip this next step as there would likely be no need to create another policy.  If an appropriate custom policy does not yet exist though then one should be created as it is not advisable to change the existing global policy’s SignInMode parameter.  Doing so would lead to all users in the entire tenant by default being forced into the same limited CAP experience on any Teams IP Phones.

    • Create a new policy using the New-CsTeamsIPPhonePolicy cmdlet which enables the CommonAreaPhoneSignIn behavior.

    New-CsTeamsIPPhonePolicy -Identity ‘CAP’ -Description ‘Common Area Phone User Policy’ -SignInMode CommonAreaPhoneSignIn


    There are additional parameters on this policy which can be customized if desired.  If common area phones are to be placed in spaces where non-employees may have access to them then it might not be ideal for them to be able to search for other users in the environment by name.  Or a phone might need to always be signed in with a specific user and phone number and never as a different user, so the hotdesking option should be hidden.  In Skype for Business some of these options existed and some could be controlled, but typically only at the global level.  With user-based phone policies available in Teams it is now possible to create multiple policies with different parameter configurations for a much more granular level of control.  For example, one policy could be created with CAP and search enabled for phones located in internal office spaces while another with only CAP enabled and with search disabled for phones in unsecure locations.

    As an optional example this step will disable user search by removing the Search icon from the CAP interface.

    • Edit the phone policy created above using the Set-CsTeamsIPPhonePolicy cmdlet to change the default search behavior.

    Set-CsTeamsIPPhonePolicy -Identity ‘CAP’ -SearchOnCommonAreaPhoneMode ‘Disabled’

    Configure Call Park

    A feature available by default to any phone sign-in modes is the ability to retrieve a parked phone call.  Yet in order for that behavior to actually function the Call Park service must first be enabled in the tenant as it is disabled by default.

    • To enable call parking go to the Teams Admin Center, browse to Voice > Call park policies and edit the Global (Org-wide default) policy.


    • Turn on the Allow call park setting and click Save.


    As discussed earlier with the phone policies it may not be desired to change the global default behavior on the call park policy, so a custom policy could be created here instead.  If that route is taken then make sure to assign that policy to the user account in the next section.

    Configure Calling Policies

    Another area worth reviewing is controlling calling policies for common area phone users to prevent unwanted behavior when a phone is not assigned to a specific person.


    • Enter a name for the policy (e.g. CAP), add a description if desired, select the preferred options, and then save the policy.


    Note that the options selected above are simply used as an example and are not necessarily indicative of an exact configuration applicable to a Common Area Phone.

    User Setup

    Now that the tenant has been configured a user account must be created and/or configured.  For the purposes of this article a new user account will be created.  If an existing account in the tenant is to be used instead then make sure that it is a user account and not a resource account.

    If a Common Area Phone license is assigned to a user account which previously was assigned a user license that included Exchange Online (like an Enterprise E1 license) then their mailbox will be automatically disabled, triggering that account to be removed form the Global Address List and preventing access to the mailbox, calendar, etc.  The mailbox is not deleted, it is just disabled.  If the assigned license is reverted back to something which includes Exchange Online then the Exchange configuration will be restored as will access to the mailbox and its previous contents.

    If a Common Area Phone license is assigned to a resource account then the mailbox will not be affected as resource mailboxes are allowed to be mailbox-enabled with no additional Exchange licensing.  While it is technically possible to assign a Common Area Phone license to a resource account this is not supported by Microsoft.  Their guidance is to use a Meeting Room (or an equivalent) license instead if the device requires use of an Exchange Online mailbox.

    Create User Account

    • Create a new user account in the tenant (e.g.


    • Select Common Area Phone license from the Licenses section.


    Under the Apps section select Common Area Phone in the ‘Show apps for:’ menu to confirm which services are currently included in the Common Area Phone license. 


    Assign Phone Number

    Technically this step is optional as PSTN calling is not required for a Common Area Phone to function as it still could be used to only place internal calls to other users and/or numbers within the same organization.  But given that is a fairly limited use-case then most likely PSTN connectivity will be included for a Common Area Phone.

    The two possible options for PSTN connectivity in Microsoft Teams are Direct Routing and Calling Plans.  The configuration steps for these differ but the individual processes are no different than when used to assign numbers to regular user accounts, so proceed to do so with the method which is applicable to the tenant at hand.  As an example this article will use Microsoft Calling Plans in the following steps.

    • Add an available calling plan license (e.g. Microsoft 365 Domestic and International Calling Plan) to the account.


    • In the Teams Admin Center, browse to Voice > Phone Numbers, select the user account, and then click Edit under the Account > General Information section.
    • Assign an available Phone Number and Emergency Location then click Apply.


    Assign User Policies

    Now that the account has been created the next step is to assign the IP phone policy created earlier so that the desired Common Area Phone user experience is provided when this user signs into any phone.  Without performing this step the user would leverage the global IP phone policy configuration which by default uses the standard user experience.  For this user with a Common Area Phone license that would mean that the phone would display the additional calendar and voicemail tabs but with error messages on them.

    • Using PowerShell run the Grant-CsTeamsIPPhonePolicy cmdlet to assign the CAP phone policy to the new CAP account (e.g.

    Grant-CsTeamsIPPhonePolicy -Identity ‘’ -PolicyName ‘CAP’

      If a custom Calling policy was created in the previous section then that should also be applied to the user.

      • Using PowerShell run the Grant-CsTeamsCallingPolicy cmdlet to assign the CAP calling policy to the new CAP account (e.g.

      Grant-CsTeamsCallingPolicy –Identity ‘’ –PolicyName ‘CAP’

        If a custom Call Park policy was created in the previous section then that should also be applied to the user.  (In this article the default Call Park policy was leveraged so this step was omitted in the example configuration.)

        • Using PowerShell run the Grant-CsTeamsCallParkPolicy cmdlet to assign the custom call park policy to the new CAP account (e.g.

        Grant-CsTeamsCallParkPolicy –Identity ‘’ –PolicyName ‘CAP’

        • To confirm the policy assignment(s) use the Get-CsOnlineUser cmdlet to view the account configuration.  (It may take a few minutes before the changes applied above will be reflected.)

        Get-CsOnlineUser -Identity ‘’ | fl Teams*Policy


        Sign In

        Now that the environment and first user account are configured the account can be logged into a Teams phone to see the resulting user experience.  A Poly CCX 500 IP phone was used in the following example.  Be aware that if the previous configuration was just completed then it may be required to wait several minutes before signing into the phone as all of the new policies and settings may still need to completely replicate throughout Microsoft Teams. 

        • Sign into a phone using the configured account (e.g.


          Once the process completes and any welcome screens are dismissed then the primary user interface will be displayed which should reflect the Common Area Phone interface outlined at the beginning of this article.


            If the expected results do not appear then sign out and back into the phone again after additional time has passed.

            Note that the main screen shown above only shows the Call Park button and does not include the magnifying glass icon for the Search feature which was disabled in this example configuration on the IP phone policy currently assigned to this user account. 

            Sign Out

            To prevent a phone from simply being signed out by anyone and thus losing the ability to place calls the Sign Out option is hidden in an area only accessible by administrators.  (This behavior is true for both Common Area Phone and Meeting interfaces.)

            • Tap the Hamburger menu icon in the upper left corner and then select Settings.

            image     image

            • Select Device Settings > Admin Only and then enter the device’s administrator password.

            image     image

            • From the Admin Only menu select Sign Out and confirm the action.

            image     image

            About Jeff Schertz
            Site Administrator


            42 Responses to “Common Area Phones in Microsoft Teams”
            1. Nate says:

              Hi, Jeff. I noticed in your screenshots that you were able to update the CCX 500 to the latest firmware with favorites displayed. How were you able to make this happen? Our CCX 500 phones all show “up to date” in the Team Admin portal, with no information published anywhere on how to force the update. Any help you can provide would be great. Thanks in advance.

              • Jeff Schertz says:

                The CCX firmware supporting these new features it not yet publicly available. It’s under internal testing and will be posted to the Poly support site and Teams Admin Center soon.

            2. Jarrod Beckman says:

              Great article, Jeff.

              I’m assuming that you must use Teams certified phones for any of this to work? A VVX201, for instance, would not work in this case (I’m assuming the 3PIP gateway scenario would not apply)?

              • Jeff Schertz says:

                You can still use the CAP license and user configuration with a Teams account and the VVX will register via SfB Online to leverage the 3PIP gateway. The phone interface will obviously not look anything like the native Teams client and the Teams phone policy will not apply.

            3. Szymon Bochniak says:

              Great article! It is extremely difficult to find any information about detailed aspects of Teams Calling services. Thanks for sharing.

            4. Jeff Brown Tech says:

              Hi Jeff, great article as usual. Are commands like Get-CsIPPhonePolicy & Get-CsUCPhoneConfiguration now legacy commands or only for Skype for Business Online IP phones? Just curious if settings in those policies affect Teams phones. I suspect not but wanted to get your insight.

              • Jeff Schertz says:

                Those are legacy cmdlets applicable only to devices registering to Skype for Business Online; they have no relation to the new Teams phones. So if you put a CCX phone into Skype base profile it’ll be no different than a VVX or Trio and those older cmdlet policies settings will still apply. If the CCX is in Teams base profile though then it’s communicating directly with Teams and only the new CsTeams* policies are applicable.

            5. Robert Denman says:

              Is there anyway to show the phone number on the CAP phones?

            6. James says:

              Great article, thanks for the insights Jeff!

            7. Christian Redgewell says:

              I just wanted to check if MFA is supported when signing in initially? With or without MFA enabled do you still have to sign into these phones once every 90 days or can you extend that token time? You specify that an Intune license is an additional requirement, so they can still be managed with compliance policies in Intune as well?

              • Jeff Schertz says:

                The Intune license is not a requirement so you don’t have to add it if you don’t plan to use Endpoint Manager to manage anything on them. You can use Microsoft’s built-in MFA (like phone call/SMS) but I don’t know if any other MFA platforms are officially supported. I know I’ve seen platforms like Cisco’s Duo or Okta have worked when signing in.

            8. David Graham says:

              Hi Jeff,

              Your article is so good. I logged a premier call to work out and issue with Common Area phones setup, Microsoft do not have any doco, and pointed me at this blog post. I am curious what licence is actually required for the CAP for Intune? Microsoft said I needed to apply an E3 which seems crazy to me. Is there a way to avoid Intune and just manage with Teams?

              We are struggling with Auto enrollment within Intune, and our CCx 400 phones show up in Teams, but not the CCX 500, very weird. Anyway, great post.

              • Jeff Schertz says:

                Thanks. I don’t know why 9 months later this is still not documented by Microsoft.

                The CAP license does not include Intune so you’d have add this separately or use a more expensive license (E1 would be cheaper than an E3, but still overkill).

                Personally though I just ignore Intune altogether for Teams IP phones as it doesn’t really add any value. The Teams Admin Center and PowerShell cmdlets provide all the possible management options. Intune is really for managing personal Android devices and I’ve yet to see a reason for using it with certified Teams devices, other than dealing with unblocking them (if needed).

            9. James says:

              Is there a remote deployment methodology?

              If I have 1,000 common area phones spread over multiple locations having to touch each one in order to provision it, well it’s not a great story,

              • Jeff Schertz says:

                Not currently, all Teams IP phones require local access to the device to perform the sign-in process. I suggest discussing this limitation directly with Microsoft.

            10. Chris Bailey says:

              In my speed dial list in my Teams client I have a PSTN number saved with a name, when I sign into a CCX it shows the number but no name – do you think the phone app will ever mirror the client experience ?

              • Jeff Schertz says:

                I think this may have changed with the new People app included in the latest Teams client version which will be supported on the CCX in the next qualified release targeted for next month.

            11. Andrew says:

              Hey Jeff,

              Just joined my company which uses a few different Trio devices, and your articles have been amazing for gaining some insight to their setup. A question if I may…we are in the process of migrating some Trio 8800’s (latest firmware) over to Teams but are struggling with the best method of account/device setup. All the old hands have left, and documentation here and on the web seems scarce. Essentially, we are setting up the devices with new users (internal account clean-up), assigning it either an E based licence, or a common area phone/meeting room licence plus a calling plan. The devices are in a shared mode, and things appear to function when logged in… the staff though want the devices listed as rooms (i.e. Meeting Room 12), and so bookable with a confirmation email through Outlook etc. What would you suggest is the best method for achieving a shared (Teams) trio phone system, with an accepted/denied calendar setup please? Any help would be greatly appreciated!

              • Jeff Schertz says:

                Use the same account setup approach as you would for a Microsoft Teams Room system by creating a Room mailbox but enabling the user and tweaking the CalendarProcessing settings accordingly.

            12. Shanuj Patel says:

              We purely just want to have an IP phone in the meeting room to make and receive calls, therefore we are looking to assign a CAP license and a calling plan.

              What type of number can be assigned to a CAP device?
              Is it user number or Service number? As we are porting out old numbers in and need to specify during the porting process.

              • Jeff Schertz says:

                You don’t assign numbers to devices, you assign numbers to users and then simply login on the desired device with that user account. Thus, just setup a regular Teams user account, enable it for Enterprise Voice, and then apply a User Sign In mode policy set to CommonAreaPhoneSignIn to that account. When they sign into the phone only the CAP experience will be provided.

            13. John Bamgboye says:

              Great article Jeff. Just wanted to check around dial plans for a Teams common area phone account signed into a VVX. Is the global tenant dial plan picked up by default? Does the VVX dialplan.1.digitmap need to be manually changed to the Tenant SimpleName (something like DefaultTenantDialPlan)?

              Many Thanks

            14. Mike says:


              I setup account and signin on VVX, I can make call in but can’t call out 🙁

            15. Steven Dunker says:

              Been trying to setup CAP for a while and have case open with MSFT but not making a lot of progress. Basically I am not able to assign a number to the user account with CAP license. One thing that is not clear to me in your example you added a domestic calling plan to the account. My other user accounts that just have 365 Biz Voice do not have a calling plan associated with them, I assume that is because it has a Phone System license.


              • Jeff Schertz says:

                The account can be setup no differently than a regular user in your environment other than the sign-in mode. It is not clear to me if your other users have PSTN calling capabilities or not though. A ‘Phone System’ license is not enough for PSTN access as the account also requires either a Microsoft Calling Plan or you need to have Direct Routing setup correctly for the account.

            16. Marc-Andre Drouin says:

              Great article!

              Any suggestions to configure a Common Area Phone or a generic user account as a Intercom system to allow people in a building? I would like to set a phone with a list of “Favorites” that would communicate with specific people in the building. Instead of having a receptionist, the client would come up to the CAP and press on a option within the Favorites list.


            17. Dan says:

              Excellent article, as always. Makes you think why MSFT can’t come up with something like this, so kudos to you Jeff.
              One thing I’m not entirely clear about is with Intune. You mention that Intune is not required for CAP, and I agree. But how can I prevent the device from being enrolled in Intune in the first place. In my environment the device keeps on enrolling itself, which leads to failure due to non-compliance etc. I followed these hints but have had no success so far:
              I was wondering if there is a more elegant way of keeping the device away from Intune.

              • Jeff Schertz says:

                That’s a good question as I can’t get any of my devices to appear in Intune in my own tenant and I have not identified why that is as the tenant is licensed appropriately. So far my experience is that the Microsoft Endpoint Management (MEM) + Intune portion of the Teams Android-based devices is a bit of a mess. In my opinion Microsoft should just omit all certified Teams devices from Intune (other than the Windows-based MTR) as it’s causing more problems than any potential benefit. The Android policies in MEM are really meant for smartphones and there’s nothing in MEM that really makes sense for handling IP handsets.

                • Dan says:

                  That’s interesting, as on my tenant I can’t keep the phones AWAY from Intune. When logging in with a regular user, the phone gets registered as a (non-compliant) Android device, but otherwise works as expected. However, when using the CAP-enabled account I created as per your instructions, it tries to register in Intune for a few minutes and then reverts back to the sign-in screen. I explicitly enabled the CAP-account as an Intune user, but it doesn’t change anything..

            18. Sergio F says:

              Does anyone know if this phones will have a screen lock feature at some point?

              • Jeff Schertz says:

                Phone Lock is currently available on the CCX phones, but it’s only applicable to User Sign-in mode. If you are using a phone with the CAP or Meeting experience then locking is not supported.

            19. ¨Brecht Simons says:

              Anybody has an idea if it’s possible to provision VVX phones with 3PIP via the Poly RPRM?

            20. Genga says:

              It’s great article ! I’m bit unclear, Can CAP accounts be created on-prem AD and synced to cloud ? Also, does Teams support PIN based authentication to login CAP phone ?

            21. Sonny says:

              Hi Jeff, great article as usual! We just configured a bunch of CCX400’s with the CAP license today but I’ve had the realisation that there is no way to save the password on the device. Do you know if there is a way to keep them signed in? I asked Microsoft and they just directed me back to Poly. I’d hate to have to get someone to go around and sign these in every time the token expires, am hoping they are interpreted as a different device if we assign a CAP policy to it.

              • Jeff Schertz says:

                The account credentials are saved but it sounds like you may be hitting the inactivity 90 timeout for Azure AD accounts. This will be fixed in the next Teams phone client release.

            Speak Your Mind

            Tell us what you're thinking...
            and oh, if you want a pic to show with your comment, go get a gravatar!