[This is pre-release documentation and subject to change in future releases. This topic's current status is: Milestone-Ready]

Topic Last Modified: 2010-07-15

Before you deploy common area phones, you can configure call control behavior—for example, you may want to allow call transfers from a common area phone in a conference room but not from a common area phone in a lobby. You can also set up phones to block external usage and compromised accounts and configure hot-desk phones, that is, phones on which users can log on to their own user account and, once logged on, use Microsoft Communicator features and their own user profile settings.

To do this:

  1. Create a new contact object for each common area phone. If an active directory object already exists, ensure that this object is not SIP enabled. If the object is SIP enabled, then the command Disable-csUser should be used to remove Communicator attributes, before using the command New-csCommonAreaPhone.”

  2. Create required policies for all common area phone usage scenarios. (This section provides information on creating three most relevant policies on common area phones, but other policies may be relevant to your enterprise.)

Important:
Before you complete the following steps, make sure that all of the required components are in place (see Required Communications Server 2010 (Beta Refresh) Components for Devices) and that you’ve met the requirements described in System and Infrastructure Requirements for Devices.

Step 1: Create and configure a new contact object.

To create a new instance of a common area phone, use the New-CsCommonAreaPhone cmdlet. For example:

New-CSCommonAreaPhone -LineUri "tel:+14255551212" -RegistrarPool "ocs-w14-se.ocspm-topo.net" -OU "OU=PM Users,DC=ocspm-topo,DC=net" -description "Room number 30-1000" -DisplayName "Building 30 Lobby" -DisplayNumber “1 (425) 555-1212”

This cmdlet creates a new contact object in Microsoft Active Directory Domain Services for the specified phone. Like user accounts, these contact objects can be assigned policies and voice plans. As a result, you will be able to maintain control over common area phones even though those phones are not associated with an individual user.

For more information about creating contact objects for common area phones, run Get-Help New- CsCommonAreaPhone –Full | more from the Communications Server Management Shell.

If you are deploying many common area phones, you may want to write a Windows PowerShell script to create multiple new objects at the same time by using a table as an input for batch processing. Include entries for phone number, location, voice policy, client policy, and any other policy and object settings that you want applied.

Note:
For more information about the Shell and individual cmdlets, see the RTCCmdlet.chm.

See Planning to Manage and Troubleshoot Devices for information about monitoring and troubleshooting common area phones.

Step 2: (Optional) Create required policies.

Creating specific policies for common area phones is optional. If you do not create a new policy for a common area phone, the phone will automatically use the policy defined for the site that the phone contact object is homed on. If no site policy exists, the global policy will be used. But if your organization has specific requirements for common area phones, use the Shell cmdlets described below to create the client, voice, and conferencing policies (the three policies most relevant to common area phones) that will apply to the common area phone account being created. Create a policy for each usage scenario. For example, all lobby phones can have “lobby”-specific policies, and phones in executive meeting rooms can have a less restrictive set of policies than phones in regular meeting room phones.

If you create a new policy or want to use an existing per-user policy, you must grant that policy to any contact objects (phones) that you want that policy applied to. To do this, call the Grant- cmdlet of the policy. For example, to grant the client policy that we created earlier in this section to the phone created in Step 1, run the following command:

Grant-CsClientPolicy –Identity "Building 30 Lobby" -PolicyName ADClientPolicy

Note:
For more information about granting client policies, run Get-Help Grant-CsClientPolicy –Full | more, from the Shell.

For information about additional polices, see the RTCCmdlet.chm.

Client Policy

To create a new client policy, use the New-CSClientPolicy cmdlet. For example, to create a policy for common area phones that are used as hot-desk phones, run a command such as the following:

New-CsClientPolicy –Identity HotDeskPhonesPolicy –EnableHotdesking $True –HotdeskingTimeout 1800

This example creates a new client policy with the identity HotDeskPhonesPolicy. We’ve set the EnableHotdesking parameter to True ($True), which allows users to log onto the common area phone using their Communications Server account. We’ve also set the HotdeskingTimeout parameter to 1800, which means that users who log onto the phone to which this policy is applied will be allowed to remain logged on for a maximum of 1,800 minutes.

Note:
Other properties of a client policy that may be most relevant to common area phones include ShowRecentContact, DisableFreeBusyInfo, and AddressBookAvailability.

Voice Policy

To create a new voice policy, use the New-CSVoicePolicy cmdlet. For example:

New-CsVoicePolicy -Identity CAPvoicepolicy –PstnUsages @{add="Internal","Local"} -allowsimulring $False -Allowcallforwarding $False -Name CAPvoicepolicy -EnableDelegation $False -EnableTeamCall $FALSE -EnableCallTransfer $FALSE

This example creates a new voice policy with the Identity CAPvoicepolicy. This new policy sets several properties that would most likely apply to common area phones. It turns off simultaneous ring (-AllowSimulRing $False), so calls to the phone that this policy is applied to cannot simultaneously ring on another phone, such as a mobile phone. It also turns off call forwarding (-AllowCallForwarding $False), call delegation (-EnableDelegation $False), the ability to transfer calls (-EnableCallTransfer $False), and the ability to set up a team of users whose phones will ring when this phone does (-EnableTeamCall $False).

Note:
As shown in the preceding example, the following voice policy settings are recommended for common area phones:

AllowCallForwarding : False

EnableDelegation : False

EnableTeamCall : False

EnableCallTransfer : False



To see a list of all available voice policy properties and their descriptions, run Get-Help New-CsVoicePolicy –Full from the Shell.

Conferencing Policy

To create a new conferencing policy, use the New-CSConferencingPolicy cmdlet. For example:

new-csconferencingpolicy -identity CAPconferencingpolicy -allowIPAudio $false -allowIPvideo $False -EnableFileTransfer $False -EnableP2PFileTransfer $False -EnableDataCollaboration $False

This is an example of a conferencing policy with settings that could be applicable to a common area phone. This example creates a conferencing policy with an Identity CAPconferencingpolicy. This new policy disables the following:

  • The ability to use computer audio in a meetings (-AllowIPAudio $False)

  • The ability to use computer audio in a meetings (-AllowIPAudio $False)

  • The ability to transfer files as part of the conference (-EnableFileTransfer $False)

  • Peer-to-peer file transfers during the conference (-EnableP2PFileTransfer)

  • Peer-to-peer file transfers during the conference (-EnableP2PFileTransfer)

Note:
The following conferencing policy settings are typically set for common area phones, but these and others can be changed depending on enterprise needs:AllowIPAudio : False

AllowIPVideo : False

EnableFileTransfer : False

EnableP2PFileTransfer : False

EnableDataCollaboration : False



To see a list of all available voice policy properties and their descriptions, run Get-Help New-CsConferencingPolicy –Full | more from the Shell.
Note:
After you configure common area phones, provision them by installing them where they will be used and just sign in. If the phone will be used at a hot desk, the phone must be provisioned according to the process described in Setting Up Authentication on the New IP Phones, in the Deployment Guide.