Forum Discussion
LPE Device Support
rovert506 Thanks for the update, my lab is in Azure and minus a Consolidated Edge so testing will be tricky. I'm hoping Rahul Gupta or someone within Microsoft will update the TechNet documentation or this post in order to reflect the viability of using Lync Phone Edition in terms of TLS 1.0 with Skype for Business Server 2019, many others will be in the same boat as Vitaliy Taryanik and some clarity around this would be advantageous.
Barry Byrne & Vitaliy Taryanik
I was finally able to smoke test this in my lab. As expected, if you install S4B 2019 Server onto Win Server 2016, LPE devices work out of the box* without any changes. They can register, take calls, participate in conferences...the normal stuff. There is no change to SCHANNEL configuration by the S4B 2019 installer, which means the OS will support any protocol version down to TLS 1.0.
Now, if you go and manually change SCHANNEL configuration on the server to exclude TLS 1.0, the LPE device cannot establish a secure connection and remains offline but under default settings they should "work" without issue. Even so, LPE devices are long in the tooth and are going to die on the vine anyway. I wouldn't advise taking too many chances with these things...
*Note: Even though most items "work", firmware update functionality does *not* appear to work in my testing. The LPE device I had was running version 4.0.7577.4387. Under that revision, I could not - despite my best attempts - get the LPE device to successfully update to the latest version of 4.0.7577.4531 when the phone was homed on the S4B 2019 pool. I've rehomed the test account to a S4B 2015 pool and am running through firmware update tests there to see if anything changes under the new device firmware.
ucupdates-r2 is only required under certain circumstances, namely when an LPE device is deployed but never signed-in with a user account. Under that scenario, the device takes the DNS Domain Name from DHCP and appends the ucupdates-r2 hostname in an attempt to access device update services so that it could be updated without a user account being logged in.
If you actually sign-in with a user account, the device strictly uses the Internal/External Web Services URL of the pool the user account is homed on. ucupdates-r2 is not deployed on either my 2019 or 2015 pools (or certs). Device update works just fine on the 2015 pool under current configuration.
Either way...I think you're in a good place to go to 2015 first and worry about 2019 later.
Trevor, for your LPE update issue, take a look at the SAN on your FE's certificate to make sure it has the entry of ucupdates-r2.your-domain-name.
Also, thanks for looking into the LPE's on S4B 2019. I've decided to migrate to S4B 2015 to play it safe until all of the cx600 devices have been replaced (going with Audiocodes HD445) then proceed with 2019. Im sure it'll be a bit more stable by then :)
Sadly, no change. The LPE device exhibits a 400 HTTP error code when attempting to connect:
2018-12-11 19:30:58 W3SVC1 BNA-IIS-ARR001 192.168.2.80 POST /RequestHandler/ucdevice.upx X-ARR-CACHE-HIT=0&SERVER-ROUTED=BNA-S4B-FE003.CORP.UCVNEXT.ORG&X-ARR-LOG-ID=b149ae50-823e-4c24-aa8a-eaf33df09c35&SERVER-STATUS=200 443 - 192.168.5.104 HTTP/1.1 Microsoft+UCPhone+Device+(lcs_se_w14_main:1776881:2017/04/25:00:13:13) - - bna-fepool02-intweb.ucvnext.org 200 0 0 826 250 1036
2018-12-11 19:31:00 W3SVC1 BNA-IIS-ARR001 192.168.2.80 POST /RequestHandler/ucdevice.upx X-ARR-CACHE-HIT=0&SERVER-ROUTED=BNA-S4B-FE003.CORP.UCVNEXT.ORG&X-ARR-LOG-ID=9beb2d99-2b3b-4343-8f89-9ff66c404e95&SERVER-STATUS=400 443 - 192.168.5.104 HTTP/1.1 Microsoft+UCPhone+Device+(lcs_se_w14_main:1776881:2017/04/25:00:13:13) ARRAffinity=19eebf5fdcb8bd65c335fcd1dba6e2c4bbfa72e42c919d4d37fc35898afbfa0c - bna-fepool02-intweb.ucvnext.org 400 0 0 538 896 114I'll need to do some more digging on this because this feels like a bug or potentially a mis-configuration on my part. I've got several Audiocodes 3PIP phones that can connect successfully to the Device Update service on the 2019 pool though, so I'm not sure it's a bad config. Plus, this HLB handles both the 2015 and 2019 pools, and updates most definitely work under the 2015 pool:
2018-12-11 19:34:41 W3SVC1 BNA-IIS-ARR001 192.168.2.80 POST /RequestHandler/ucdevice.upx X-ARR-CACHE-HIT=0&SERVER-ROUTED=BNA-S4B-FE003.CORP.UCVNEXT.ORG&X-ARR-LOG-ID=dabbb1e5-4e9a-4048-aa0a-562b2c15be02&SERVER-STATUS=200 443 - 192.168.5.102 HTTP/1.1 AUDC/3.1.2.89+AUDC-IPPhone-405HD_UC_3.1.2.89 - - bna-fepool02-intweb.ucvnext.org 200 0 0 711 919 99
2018-12-11 19:33:58 W3SVC1 BNA-IIS-ARR001 192.168.2.80 POST /RequestHandler/ucdevice.upx X-ARR-CACHE-HIT=0&SERVER-ROUTED=BNA-S4B-FE004.CORP.UCVNEXT.ORG&X-ARR-LOG-ID=15c5c93d-b00e-44f1-86c9-b4885d1ac872&SERVER-STATUS=200 443 - 192.168.5.104 HTTP/1.1 Microsoft+UCPhone+Device+(lcs_se_w14_main:1776881:2017/04/25:00:13:13) - - bna-fepool01-intweb.ucvnext.org 200 0 0 794 250 15
2018-12-11 19:33:58 W3SVC1 BNA-IIS-ARR001 192.168.2.80 POST /RequestHandler/ucdevice.upx X-ARR-CACHE-HIT=0&SERVER-ROUTED=BNA-S4B-FE004.CORP.UCVNEXT.ORG&X-ARR-LOG-ID=b6b62bb1-76e5-4ed4-9f5d-fae97abe5ee7&SERVER-STATUS=200 443 - 192.168.5.104 HTTP/1.1 Microsoft+UCPhone+Device+(lcs_se_w14_main:1776881:2017/04/25:00:13:13) ARRAffinity=6b14c56ae9d6a870aedd200b5b358f7673accee31e936f53d1308415e9a5f6fe - bna-fepool01-intweb.ucvnext.org 200 0 0 594 896 225
