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
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 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