During a recent engagement, I had ran into an issue updating the firmware version on Lync Phone Edition Devices.
I initially kicked off with checks around DNS, Certificates, Ports and everything checked out but phones would still not update.
Test Devices had been configured correctly (using serial number and one using MAC) – still no joy.
The IIS logs are extremely useful; Jeff Schertz has excellent blog posts on Configuring LPE for Lync and Updating LPE devices which go into reviewing the IIS logs. In summary, it enables you to confirm whether devices are communicating with the device update site running on within the front-end pool, or in our case – NOT.
In my case, I could not see a single HTTP request being made to the front-end pool, which gave me significant direction.
As we are using an Enterprise Edition Pool, web services are, as per best practice, load balanced across front-end servers, which added further complexity. To this end, we simply updated DNS to point the web services to a single Front End Server. This confirmed whether the Kemp loadmasters were causing the issue – they were not.
I checked the status information on the LPE device, which still reported its last update request as 0x5/407.
When troubleshooting LPE devices, it is crucially important to understand the above error codes.
In fact, this is actually two error codes; WinError / HTTP(s) Error respectively;
0x5 = Access Denied
407 = Proxy Authentication Required
A full list of Windows Errors can be found here (MSDN)
A list of HTTP error codes can be found here (W3.org)
Now taking into account the following;
- Not a single request had hit any of my front end servers
- load balancing had been ruled out completed
- The general health of the Lync solution was good!
As well as the above errors, it goes without saying the issue we were experiencing.
To confirm, using the LPE log viewer, which is a great tool put together by Andrew Morpeth (MVP) – I was able to determine that the devices could not authenticate with the customers Web Proxy server!
To resolve the issue, the customer using a McAfee Web Gateway, had to update their Rule Set criteria to ensure the any requests made to the internal Lync web services FQDN bypassed the requirement for authentication.
Once this was in place, devices updated successfully, hope this helps! J