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.
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.
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.)
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.
- Launch PowerShell and use the Skype for Business Online PowerShell Module to connect using an account which sufficient administrative rights in the desired tenant.
$sfbo = New-CsOnlineSession –UserName ‘email@example.com‘
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.
- Go to the Teams Admin Center, browse to Voice > Calling policies and select Add.
- 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.
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. firstname.lastname@example.org).
- 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.
- In the Microsoft 365 Admin Center browse to Users > All Users, select the new user account (e.g. email@example.com), and then go to the Licenses and Apps section.
- 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. firstname.lastname@example.org)
Grant-CsTeamsIPPhonePolicy -Identity ‘email@example.com’ -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. firstname.lastname@example.org)
Grant-CsTeamsCallingPolicy –Identity ‘email@example.com’ –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. firstname.lastname@example.org)
Grant-CsTeamsCallParkPolicy –Identity ‘email@example.com’ –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 ‘firstname.lastname@example.org’ | fl Teams*Policy
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. email@example.com)
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.
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.
- Select Device Settings > Admin Only and then enter the device’s administrator password.
- From the Admin Only menu select Sign Out and confirm the action.