Common Area Phone Configuration in Lync
April 16, 2011 by Jeff Schertz · 32 Comments
With the introduction of the new Lync Phone Edition client in Lync Server 2010 there is now a way to support basic telephony functionality without having to login as a regular user to a standalone handset. In Office Communications Server this experience was limited to using an executive-class CX700 (Tanjay) with a dedicated user account signed into the phone. Neither these devices nor the extended communication modalities provided by a full OCS user account were really the best solution for a phone in an unsecured, common area.
In order to support the use of Common Area Phone (aka Hotdesking) the Lync Server environment first needs to be configured to support PIN Authentication for the Aries family of Lync Phone Edition devices (Polycom’s CX500, CX600, CX3000 and Aastra’s 6721ip, 6725ip). This topic is covered in-depth in this previous blog article: Configuring Lync Server for Phone Edition Devices. Once Enterprise Voice enabled Lync user accounts can successfully sign in using PIN Authentication then the steps in this article can be applied.
As my modus operandi revolves around adding content and (hopefully) simplifying topics covered in the TechNet documentation, this article is no exception. While the official Configuring Common Area Phones documentation does already cover a majority of the content there are important items omitted. Some of this information is not clearly explained and is located different chapters of the documentation. If the underlying operation is not already understood by the reader beforehand then it may not be clear what the missing pieces are, thus following the configuration steps verbatim may not produce the desired results.
So this article covers two scenarios: a simple cut-to-the-chase approach to getting a Common Area Phone configured as easily as possible, and a more detailed approach with customized policies. The Lync Server Control Panel cannot be used for the majority of this configuration, so all steps in either scenario will be shown using the PowerShell-based Lync Server Management Shell.
Scenario A: Simple
Making the assumption that a working Lync Server environment is available and PIN Authentication is currently working then this process is very simple. This is for those who don’t care to read or understand how it all works, they just want to get it done and working. The second scenario will be much more verbose so skip to that section for the good stuff.
Enable Hotdesking
By default Hotdesking is turned off in Lync Server 2010. The default Global policies contains Common Area Phone specific settings which will be applied to all devices signed-in using one of these accounts.
- Enter the following string in the command shell to enable hotdesking on the default Global client policy.
Set-CsClientPolicy -Identity Global -EnableHotdesking $TRUE
Create Common Area Phone Account
A Common Area Phone is defined by an Active Directory Contact which is not SIP-enabled through the normal means that a contact would be. This new contact object is created automatically by the New-CommonAreaPhone cmdlet.
- Enter the following string in the command shell using the desired phone number, display name, and description. The RegistrarPool value is the FQDN of the Lync Front-End server or pool. The OU value is were the new contact should be created in AD. (The DisplayNumber format must be able to be normalized by Lync server otherwise the LineURI value will be shown on the phone’s home screen.)
New-CsCommonAreaPhone -LineUri "tel:+13125557521" -RegistrarPool "lync.schertz.local" -OU "OU=Contacts,OU=JDS,DC=schertz,DC=local" -Description "Common Area Phone" -DisplayName "Lobby Phone 1" -DisplayNumber "(312) 555-7521"
Set Device PIN
Just as a normal user must have a PIN defined for authentication so must a Common Area Phone contact. But again this cannot be performed using the Control Panel.
- Enter the following string in the command shell using the desired PIN.
Set-CsClientPin –Identity “Lobby Phone 1” -Pin 123123
Once these three simple steps are completed then sign in to an Aries phone using the extension of the new common area contact. The bare interface will indicate that the majority of normal user features are not available.
Scenario B: Less Simple
As promised this scenario will go into greater detail. The biggest issue with the example process in the TechNet documentation is that although the configuration of various custom (yet optional) polices is covered, there is minimal direction on how to actually assign these polices to the Common Area Phone contacts.
The benefit of defining specific policies allows for a more granular level of control of devices in different user or site populations.
New Client Policy
A new client policy can be used to either define different parameter values than what the default global policy has or to just organizationally separate the Common Area Phones. As mentioned in the previous section it is acceptable to enable hotdesking on the global policy but in larger deployments it is recommended to create multiple policies for different group of devices that all may require unique settings.
- Enter the following string in the command shell to create a new client policy called CommonAreaClient using the desired HotdeskingTimeout value for how long to wait before automatically signing out an inactive Lync user and reverting to the Common Area Phone contact number. (The default value is 5 minutes.)
New-CsClientPolicy -Identity CommonAreaClient -EnableHotdesking $True -HotdeskingTimeout 00:10:00
New Voice Policy
Creating a new voice policy is important when the common area phones should be limited to internal calling or need to have a different level of external dialing then standard Lync users may.
- First identify the currently defined PSTN usages in Lync Server.
Get-CsPSTNUsage
-
Create a new voice policy named CommonAreaVoice which limits usage of only the Internal PSTN usage as also disables all other calling features.
New-CsVoicePolicy -Identity CommonAreaVoice -PstnUsages @{add="Internal"} -AllowSimulRing $FALSE -AllowCallForwarding $FALSE -Name CommonAreaVoice -EnableDelegation $FALSE -EnableTeamCall $FALSE -EnableCallTransfer $FALSE -AllowPSTNReRouting $FALSE -Description "Feature-Restricted Common Area Phone Policy"
Additionally the Voice Policy could be created or modified using the Lync Server Control Panel, under Voice Routing > Voice Policy.
New Conferencing Policy
Although some of the features in the Conferencing Policy do not apply to Lync Phone Edition devices the example documentation recommends that all of these modalities are disabled for common area devices.
- Create a new conferencing policy called CommonAreaConf and disable all of the configurable parameters.
New-CsConferencingPolicy -Identity CommonAreaConf -AllowIPAudio $FALSE -AllowIPVideo $FALSE -EnableFileTransfer $FALSE -EnableP2PFileTransfer $FALSE -EnableDataCollaboration $FALSE
Additionally the Conferencing Policy could be created or modified using the Lync Server Control Panel, under Conferencing > Conferencing Policy.
New PIN Policy
In this example a less restrictive PIN policy is defined then what the global PIN policy has by default. Alternatively a more restrictive PIN policy could be used to force a complex PIN on common area phones to prevent users from signing in as that account on other phones as typically only IT would manage the common devices default account. Either approach has merits in a real-world deployment.
- Create a new PIN policy called CommonAreaPIN which reduces the minimum PIN length to 4 digits and allows for the usage of common patterns.
New-CsPINPolicy -Identity CommonAreaPIN -Description "Common Area Phone
Authentication PIN Policy" -MinPasswordLength 4 -AllowCommonPatterns $TRUE
Create Common Area Account
A Common Area Phone is defined by an Active Directory Contact which is not SIP-enabled through the normal means that a contact would be. This new contact object is created automatically by the New-CommonAreaPhone cmdlet.
- Enter the following string in the command shell using the desired phone number, display name, and description. The RegistrarPool value is the FQDN of the Lync Front-End server or pool. The OU value is were the new contact should be created in AD. (The DisplayNumber format must be able to be normalized by Lync server otherwise the LineURI value will be shown on the phone’s home screen.)
New-CsCommonAreaPhone -LineUri "tel:+13125557521" -RegistrarPool "lync.schertz.local" -OU "OU=Contacts,OU=JDS,DC=schertz,DC=local" -Description "Common Area Phone" -DisplayName "Lobby Phone 1" -DisplayNumber "(312) 555-7521"
The new contact object can be found in Active Directory and a peak at the raw attributes shows that it only contains a subset of the normally populated Lync attributes. Also the SIP URI (msRTCSIP-PrimaryUserAddress) is a dynamically created value that is not utilized by end-users.
Set Device PIN
Just as a normal user must have a PIN defined for authentication so must a Common Area Phone contact. But again this cannot be performed using the Control Panel.
- Enter the following string in the command shell using the desired PIN.
Set-CsClientPin –Identity “Lobby Phone 1” -Pin 123123
Assign Policies
At this point there a number of new policies defined, but none have been assigned to anything yet. The screenshot above shows that there are empty parameters for the four applicable policies. An assumption could be made that the Set-CsCommonAreaPhone cmdlet would be used to define those parameters, but that would be incorrect. Each policy type has its own Grant- cmdlet which is used to assign objects to the policy.
- Enter the following cmdlets individually to assign the new Common Area Phone object to each of the newly created policies.
Grant-CsClientPolicy -PolicyName CommonAreaClient -Identity "Lobby Phone 1”
Grant-CsVoicePolicy -PolicyName CommonAreaVoice -Identity "Lobby Phone 1”
Grant-CsConferencingPolicy -PolicyName CommonAreaConf -Identity "Lobby Phone 1”
Grant-CsPINPolicy -PolicyName CommonAreaPIN -Identity "Lobby Phone 1”
- Use the Get-CsCommonAreaPhone cmdlet to verify that the newly assigned policies have been applied to the contact.
Get-CsCommonAreaPhone –Identity “Lobby Phone 1”
Bulk Actions
Most likely more than a single common area account would be created and thus there is a quick way to assign all Common Area Phone contact objects to the same policy in a single action.
- Use the Get cmdlet to pass the results (all existing Common Area Phone accounts) through the pipe (|) to the desired Grant cmdlet. Run the command for each of the four policy types.
Get-CsCommonAreaPhone -Identity "Lobby Phone 1" | Grant-CsClientPolicy -PolicyName CommonAreaClient
Additionally PointBridge’s Keenan Crockett has a blog article covering how to create a single script for mass account creation and configuration.
Test Authentication
Prior to signing in on a device the process can be tested with the same emulate cmdlet that was covered in the previous blog article on phone configuration.
- Enter the following cmdlet to test the PIN Authentication process from the Lync Server.
Test-CsPhoneBootstrap -PhoneOrExt 7521 -PIN 1234
Sign-In to Device
If the test passes successfully then the same credentials should also work from a phone. The phone will be shown in the Lync address book when searched by name (an Update-CsAddressBook can be trigger to speed up the process).
Site Administrator
Great blog! An off-topic question: In a Lync resource forest topology, can active Lync users exist in the resource forest?
Thanks!
Yes, accounts in the local domain can still be Lync-enabled.
Great! Any potential address book or presence issues between the users from the different forests?
Thanks again!
Very useful article. In this scenario if a user has signed in to the phone can someone still call the common area number? Thinking of meeting rooms where there is a published number for the meeting room, but someone has connected up via USB to a CX3000…
Neil
Neil, when another user signs into the Common Area Phone the common account is automatically signed-out, so calls to tha CAP number will fail with a "user is offline/unavailable" response. You may want to take a look at the SEFAutil Lync Resource Kit tool as there may be a way to setup call-forwarding for the CAP account to be used when it's not actively signed-in. http://blogs.technet.com/b/meacoex/archive/2011/0…
I'm trying to set up a new CX500 common area phone, and I get the following error when I try to auth with the xtn and pin; An account matching this phone number cannot be found. I have checked everything I can think of and done an Test-CsPhoneBootstrap which shows a success with the same xtn/pin combo. Any idea where I should look or what I may have not set up properly?
Can you try running the Test-CsPhoneBootstrap cmdlet from a workstation on the same VLAN as the device? There my still yet be a problem with DHCP where the device is connected but not where the Lync server is (which is why the cmdlet passes successfully now).
How do you run that cmdlet from the local computer? Do you have to install the management shell locally? I tried installing locally but it doesn't recognize the command as valid. The command does pass when I run it on the FE server.
Yes, all of the -Cs* cmdlets are included in the Lync Server Management Shell only. If you want to run these commands from a remote computer then you'll need to install the Administration Tools from the Lync deployment wizard on that remote computer first.
Hi Jeff, first of all, thank you for the great article.
I am also getting the same error in my CX600s David getting. As said, tried running Test-CsPhoneBootStrap from my Win7 32bit system (did remote PowerShell to my FE) and found it is passing. Is it right-way to test using remote session?
Test-CsPhoneBootstrap -PhoneOrExt 677123456 -PIN 12345
RunspaceId : 87180be8-28ee-4bf1-b26c-83307fb53674
TargetUri : https://lync.domain.com:443/CertProv/CertProvisio…
TargetFqdn : lync.domain.com
Result : Success
Latency : 00:00:46.1823828
Error :
Diagnosis :
Thank you. I do not understand why such a simple procedure can't be documented in a similar fashion by TechNet, such that I may not have ripped out most of my hair. You are certainly performing a valuable service.
Jeff: as the AD contact object assigned to the lobby phone is definitely not enabled for UM (it would not make sense to UM-enable it anyway) the call should ring practically "forever" instead of going to any coverage. But in fact, such calls against a lobby phone gets dropped after approx. 20 seconds. The SEFAutil should show something interesting, if I give it a try, as there is no other way to influence call forward settings? Anyway the voice policy disabled call forwarding..
i am using the CX600 phones in a branch senario and need to know if there is a way to make the phone auto sign in and out when the lync client is logged on or off?
Im reading your article as i figured i could set all the phones up as common area phones with the same common area account. then when a users docs there laptop or logs into lync they would sign in over the top of the common area account? then when they log out the user would be auto signed out and the phone would revert to the common area account.
Does this sound feasable or is there a way to make a CX600 or HP4120 to auto sign in and out with the lync client. this currently doesnt happen.
Chris, the LPE devices will automatically sign-in only with the cached credentials, and you can only configure Common Area Phones to auto sign-out a standard Lync account that has been signed-in over the CAP account. See my reply in this TechNet discussion for more details.
Is there a way to link a CommonAreaPhone account to a Exchange UM voice mailbox?
No, as CAP accounts are not user objects but are AD contacts with no Exchange mailbox capabilities.
You state that the RegistrarPool could be should be the "FQDN of the Lync Front-End (or Director) server or pool".
I can't manage to create a new SIP enabled object when pointing it to a Director pool. Powershell errors out:
"Cannot find Registrar pool "ucdir01.fqdn.local" in the service assignment…". Are you certain you can assign the Registrar service of a CAP enabled SIP account to a Director pool? I've only managed to get this working when pointing to an Front-end pool.
I'm testing failover of CAP phones from a primary pool to a secondary pool …. and it's not working. I was wondering whether it was because my devices were registered on an individual FE pool, and not a Director….
James, you are correct as the Director is not a 'home pool' so I've removed the typos. I've tested phone fail-over between primary and backup registrars (two separate SE FE servers) and it does work on both standard and CAP accounts. The primary difference is that if the fail-over takes longer than 10 minutes or so then the devices will CAP accounts fail to reconnect and must be rebooted to force sign-in to the backup registrar.
hi jeff,
when i start
Test-CsPhoneBootstrap -PhoneOrExt 456 -PIN 123123 i get a 401 unauthorized.
"ERROR – No response received for Web-Ticket service. Inner Exception:The HTTP request is unauthorized with client authentication scheme 'Basic'. The authentication header received from the server was 'Basic realm ="Lync01"'. Inner Exception:The remote server returned an error: (401) Unauthorized."
Login on the phone is also not possible.
Thanks for reply!
This is usually an incorrect PIN which causes the authentication failure. Try resetting the PIN again.
Great article, very clear & informative
Hi Jeff,
Followed all instructions and cranted and checked all policies, however cannot sign into any phone with Common Area Account created am getting this failure message when running the Test Authentication:
Packet send successfully
No data received on dhcp port
Disconnecting
TargetUri :
TargetFqdn :
Result : Failure
Latency : 00:00:00
Error : Did not receive any response for the DHCP discovery messsage.
CHECK:
– If you have a functioning CS Registrar in your deployment wi
th EnableDHCP setting turned ON
– OR you have an enterprise DHCP Server that can respond to CS
specific options
Please advise if possible…Great blog
Can you sign in to a phones using a standard Lync account with PIN Authentication? Those errors do not seem to be related to just CAP accounts but the devices ability to use PIN Authentication in general.
Hi, great articte. Thanks for that. Is it possilble to lock the common phone somehow, that users will not be able to login with their own accounts? So the only possibility will be use the phone as it is configured…in other words..no login/logout enabled?
Thank you,
Michal
No, the Common Area Account will allow other Lync accounts to login over it.
Hi Jeff,
I've got a CX700 phone that I want to use as a Common Area Phone. I've followed your great article, but I can't seem to be able to do a pin signin on the CX700 since I updated it's firmware to the Lync Version. Is it possible to do, or should I try to get another version of phone? Also when I log in to my OWA, the common area phone account shows up in my contact list with the dynamically generated sip uri. Is there a way to hide if from the address book entirely, or could I change it to something like 'Lobby_Phone@domain.com" without affecting anything?
Again, thank you for the help, and this article is really awesome.
Jonah, only the Aries firmware supports PIN Authentication so unfortunately you cannot use a Common Area Account with a Tanjay device (CX700).
Hi Jeff,
I too am having the same problem as @_og77; DHCPUtil.exe -emulateclient is sucessfull but Test-CsPhoneBootstrap fails with:
Packet send successfully
No data received on dhcp port
Disconnecting
TargetUri :
TargetFqdn :
Result : Failure
Latency : 00:00:00
Error : Did not receive any response for the DHCP discovery messsage.
CHECK:
– If you have a functioning CS Registrar in your deployment wi
th EnableDHCP setting turned ON
– OR you have an enterprise DHCP Server that can respond to CS
specific options
Hi Jeff,
Thanks for the article. I am able to set up the common area phone (CX500), but on the phone's display the number doesn't display correctly. Instead of +1 (312) 555-7521 it reads 13125557521;phone-context=en… and the edge of the display cuts off the message. I assume this should read phone-context=enterprise. How do I change this and make it look nicer? I have tried resetting the DisplayNumber value, but it doesn't change anything on the phone.
Set the Work Phone field in the account's AD object (user object for Lync user or contact object for Lync CAC account) to the desired number format and it will display that instead of the LineURI.
Hi Jeff,
Thanks for this article. It solved my problem. Now users can hotdesk into my CX500 but when trying to call without hotdesking in, I get a "call unsuccessful. There is more than one contact with the same phone number" message. Even though it successfully resolves the 4 digit extension to the correct user. Any suggestions?
Thank you.
That message indicates that the number you used on the Common Area Account is not unique. I'd perform an LDAP search against AD to see if any attributes for other objects are also assigned the same dial string.