BACKGROUND
A Common Area Phone (CAP for brevity) is a special-purpose Lync phone setup, that is not associated with a specific user account, therefore with the user-specific set of policies and phone number. A CAP is usually placed in public areas like lobbies, restaurants, public-access meeting rooms, etc., CAPs use a specific contact object which has the usual set of policies (dial plan, voice policy, client policy, conferencing policy, etc.) associated. CAPs are signed in through PIN authentication, then they are usually left alone and will stay signed in permanently.Because CAPs are easily accessible "by design", it is common practice to provide them with a very restrictive voice policy, only allowing specific numbers to be called (e.g. internal company numbers or extensions, help desk, internal security, emergency numbers, etc.).
A CAP may or may not be also configured as a hotdesking phone. This is determined by the EnableHotdesking ($true) parameter in the client policy you assign to the CAP contact object (and not to the user).
When a CAP has hotdesking enabled, a user may "override" the CAP account, sign in to a CAP with own user account, and use Lync Server features and their own user profile settings.
Because user accounts are usually provisioned with additional calling capabilities (mobile phones, international numbers, etc.) through voice policies, security is a concern: if a user steps away from the hotdesk, the phone may be available to others for call capabilities they shouldn't have access to.
To overcome this, Lync client policy provides a mechanism to sign out the hotdesk user from the phone after some inactivity, and sign the CAP account back in. This is governed by the HotDeskingTimeOut parameter in the Lync client policy. The default value is 5 minutes, consistently with the security implications.
REQUIREMENT
My customer works in a higher security environment, so, enhanced restrictions on CAPs were not a concern. No CAPs are accessible by non trusted people. There are several common areas and conference rooms frequently used as hotdesking spaces. Several CAPs are available. Users wish to be able to sign in as hotdesking users on CAPs in the morning, and stay signed in at least until the end of business hours, so I was asked to configure a 12-hour timeout.CONFIGURATION
So, I created a client policy as follows, and assigned to CAP contact objects:New-CsClientPolicy -Identity "CAP-Hotdesk" -EnableHotdesking $True -HotdeskingTimeout 12:00:00
It worth noticing that the HotDeskingTimeout parameters does accept values up to 23:59:59. Theoretically, the object type(System.TimeSpan) even accepts values bigger than 24 hours.
This upper limit is also consistent with some public sources.
It should also be noted that TechNet does not provide any information about the maximum configurable value.
ISSUE
I was reported that all users signed it as hotdesk users on CAPs were kicked out after about 1 hour, and the phone reverted back to the CAP account.TROUBLESHOOTING
First off, I ruled out a bug in firmware. The issue was experienced on several LPE builds, including the latest one at the time of writing (7577.4457).
Phone logs revealed something interesting, when playing around with different HotDeskingTimeout values.
An excerpt when HotDeskingTimeout was set to 4:44:00 (correct):
CLockedScreen::OnEndPointSignedIn:
Signing in as hot desking user. Starting hot desking timer for 284 minutes
An excerpt when HotDeskingTimeout was set to 9:59:00 (correct):
CLockedScreen::OnEndPointSignedIn:
Signing in as hot desking user. Starting hot desking timer for 599 minutes
Now the surprise; an excerpt when HotDeskingTimeout was set to 10:01:00 (wrong):
LockedScreen::OnEndPointSignedIn:
Signing in as hot desking user. Starting hot desking timer for 60 minutes
TAKEAWAY
It appears the highest honoured timeout value is 10 hours (600 minutes). Any value beyond that is either ignored or misinterpreted by the phone, and a fallback value of 60 minutes is used instead.
TOOLS
Pulling out LPE logs is not exactly a straighforward task. I recommend this excellent tool by Andrew Morpeth to streamline the process.
DISCLAIMER
I have only tested on Polycom CX600 phones and cannot confirm if other Common Area Phones would show the same behaviour.
