Wednesday 4 March 2015

The real HotDeskingTimeOut for Polycom CX600 Lync phones

I have recently come across an interesting challenge. A customer asked for several Polycom CX600 phones to be provisioned with a Lync Client policy enabling hotdesking and a long hotdesking timeout. I experienced a quite unexpected behaviour, which I though It would worth sharing.


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.

Wednesday 21 January 2015

Lync 2013 DDC - Detailed Design Calculator

Lync DDC is a low-level design calculator for on-premises Lync 2013 deployments. Fill in hostnames, IP and other design elements, and it will calculate DNS records, certificate names, firewall rules and other scripts to help speed-up your deployment. Available at: http://goo.gl/jU1hZR

Sunday 26 October 2014

Migrating with style

Kudos to my customer for cutting such nifty things for floorwalkers :) This is what I call "migrating with style"


Tuesday 14 October 2014

Lync 2013 Cookbook announced

I am very happy to announce my first book authoring effort, in teaming with a mighty bunch of Lync and Exchange guys :-)

I am proud to have contributed with two chapters to this book. The rest is great work by co-authors Fabrizio Volpe (@fabriziovlp), Antonio Vargas (@Vargas_76) and Lasse Nordvik Wedø (@lawedo). The book should be available later this year.



Wednesday 8 October 2014

The user accounts in Outlook and Microsoft Lync do not match. Please make sure you are signed in to both application with the same user name and privileges.


During a recent test before rolling out a mass SIP URI change at a customer's site on Lync 2013, I have come across this issue when trying to schedule a meeting:


Bit of background: current SIP URI and email did not match (both the username and the domain portions were different), and the change was planned with the purpose to match them as per established best practice, so the error left me a bit puzzled for starters.
After some analysis, I found that the client policy assigned to the user had the following parameter set:

DisableEmailComparisonCheck: FALSE

I didn't expect this would break Lync/Outlook interoperability now that SIP URI matched email address, anyway, this is what fixed the issue for me:

Set-CsClientPolicy -Identity Global -DisableEmailComparisonCheck $null