*** This issue has been fixed in CU5 ***
I was recently working with a customer who had just deployed a number of Polycom CX600′s as Lync 2010 Common Area Phones across several branch offices in conference rooms and lobbies. The initial deployment went smoothly and the Common Area Phones were working as expected.
The next Monday morning, I received a call from the customer saying that all of the Common Area Phones were offline, showing the message “Signing in… Cannot sign in. There may be a problem with the server or with your network connection. Please check your network connection. Retrying.”
Over the weekend, the network admin had applied Windows Updates and the Lync Front End Server had been offline. The only way we could get the phones to come back online was to power cycle the Common Area Phones by pulling the Power over Ethernet cable out and plugging it back in. Once the phones booted back up, they signed in automatically. This was more than a little alarming, but we chalked it up to anomaly…
A few days later, the customer alerted me that they had found the phones offline again. This time, the WAN to the datacenter had been offline for several hours overnight. The customer was not happy and I was especially concerned. After all, companies rely on working phones in common areas for lots of reasons, including 911 access to emergency services!
I started testing this behavior in the lab and found that after losing connectivity to the Front End Registrar, the Common Area Phone would stop attempting to reconnect to the Front End after a certain period of time; approximately 30 minutes or less.
To simulate a WAN down scenario, I disconnected the Common Area Phone switch uplink to the core lab switch where the Lync Front End Server was connected. After a minute or so, the phone went offline. After about 30 minutes, I reconnected the switch uplink and let the phone sit overnight. When I came in the next morning, it was still offline, showing the same message as seen by my customer.
I opened a case with Microsoft Support and after several hours on the phone, I was told that this was a known issue related to Hotdesking. The Microsoft Support Engineer had me disable Hotdesking in the Lync Client Policy. Hotdesking was enabled in the Global Client Policy in my lab and in my customer’s environment.
PS C:\> Set-CsClientPolicy -EnableHotdesking $false -Identity Global PS C:\> PS C:\> Get-CsClientPolicy Identity : Global ... EnableHotdesking : False ...
I confirmed that disabling Hotdesking did indeed change the behavior of Common Area Phones. Once the policy was disabled, I was unable to reproduce the symptoms and the phones would reliably come back online after being disconnected from the Front End Registrar.
I was also told by Microsoft Support that there is no scheduled resolution for this issue at this time. The work-around is to plan on having a Backup Registrar for every location where Common Area Phones will be deployed or to disable the Hotdesking feature.