Anmelden
 
HomeLibraryDownloadsSupportWebcasts & EventsCommunityForenBlogs
Ressourcen für IT-Professionals >
> 
> 
Phone Edition Device Updates

Answered Phone Edition Device Updates

  • Freitag, 29. Juni 2012 15:13
     
     
    Anmelden
    1

    Hoping someone can help with this strange issue we're seeing while trying to pilot Lync EV. I believe we have everything configured correctly, and everything appears to work - phones sign in etc. The only issue is that the devices will not update internally. When external, they pull the updates and everything works as expected. When connected internally, the following occurs:

    The device contacts the Device update service which provides the correct internal and external URLs:

    06/29/2012 09:53:29,user01@domain.com,192.168.15.180,UCPhone,6/29/2012 9:53:23 AM,"0004FXXXXXXX","0004fXXXXXXX","POLYCOM","CX600","Rev-5","ENU",cpe.nbt;4.0.7577.4100;5/25/2012 10:20:18 PM,http://lyncpool01ws.domain.com/RequestHandler/Files/UCPhone/POLYCOM/CX600/Rev-5/ENU/4.0.7577.4066/CPE/CPE.nbt;https://lyncpool01.domain.com/RequestHandlerExt/Files/UCPhone/POLYCOM/CX600/Rev-5/ENU/4.0.7577.4066/CPE/CPE.nbt;4.0.7577.4066;2/18/2012 8:49:56 PM

    The device then apparently attempts to download the update from the external URL (the following is logged in the internel web service log on the FE server - the pool name and external web service URL are the same)

    2012-06-29 14:53:47 192.168.2.91 GET /RequestHandlerExt/Files/UCPhone/POLYCOM/CX600/Rev-5/ENU/4.0.7577.4066/CPE/CPE.nbt - 443 - 192.168.15.180 Microsoft+UCPhone+Device+(lcs_se_w14_main:1131444:2012/05/25:17:05:27) 404 0 2 182

    I'm not sure and couldn't find details on how the LPE devices detect whether they are interal or external, but as everything else works correctly and they contact the internal web service intially to request the update, I assume they are detecting that correctly.

    I'd appreciate any pointers as to where to look next. Thanks.

     

Alle Antworten

  • Freitag, 29. Juni 2012 16:10
    Moderator
     
     
    Anmelden
    1

    What is the Last Update Status code reported on the device as?

    See this article for more assistance with troubleshooting if you haven't already looked at it: http://blog.schertz.name/2012/03/troubleshooting-lync-phone-edition-issues/

    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

     
  • Freitag, 29. Juni 2012 19:59
     
     
    Anmelden
    0

    Thanks Jeff, I did go through your blog post and have used many of your posts throughout the Lync deployment - they are much appreciated and have been invaluable.

    The Last Update Status code is 0x5/404 which I'm assuming is a result of the 404 in the IIS logs for the /RequestHandlerExt/... which doesn't exist on the internal web services virtual directory?

     
  • Montag, 2. Juli 2012 03:24
    Moderator
     
     
    Anmelden
    0

    Hi,

    As Paulkohan describe in the following post, the error 404 was that it could not find the correct directory. Please try to check if RequestHandler and RequestHandlerExt have the correct path to the actual folder.

    http://social.technet.microsoft.com/Forums/en-US/ocsclients/thread/c0724830-390c-419a-8fbb-11db7ddb228e/

    In addition, More information about updating Devices and how it works please check the following link.

    http://technet.microsoft.com/en-us/library/gg398740.aspx

    Hope this useful!

    Regards,

    Kent Huang

    TechNet Community Support ************************************************************************************************************************

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.


     
  • Montag, 2. Juli 2012 13:24
     
     
    Anmelden
    0

    Kent,

    The RequestHandler virtual directory does exist in the internal web services site and the RequestHandlerExt directory exists in the external web services site. The internal web services site does not have a RequestHandlerExt directory. I assume that is correct?

    The problem is that the devices are issuing a GET for /RequestHandlerExt/... on the internal web services - as this directory does not exist, IIS returns the 404.

    The internal and external URLs passed by the device update service appear correct from the logs, it just appears the device is attempting to use the external URL to download the updates (the external web services URL matches the pool name so internally it resolves to one of the front-end servers and thus hits the internal web services)

    Thanks,

    -Tom

     
  • Dienstag, 10. Juli 2012 13:52
     
     
    Anmelden
    0

    Anyone have any suggestions on this or know how the internal / external determination is made by the Lync Phone Edition devices? I'm not sure whether it's just using the wrong URL to download the updates or whether it's not detecting being inside the network correctly.

    Thanks,

    -Tom

     
  • Dienstag, 17. Juli 2012 16:45
     
     
    Anmelden
    0

    I can at least confirm that you're not alone, Tom.  We're experiencing the same issue with internal update requests using the Polycom CX600 Rev-4.  IIS logs show:

    2012-07-17 16:02:16 167.129.57.192 GET /RequestHandlerExt/Files/UCPhone/POLYCOM/CX600/Rev-4/ENU/4.0.7577.4100/CPE/CPE.nbt - 443 - 167.129.57.206 Microsoft+UCPhone+Device+(lcs_se_w14_main:824457:2010/10/21:23:13:00) 404 0 2 2

    There's definitely something odd about a GET for RequestHandlerExt being made on 443 (Internal).

     
  • Montag, 23. Juli 2012 19:37
     
     
    Anmelden
    0

    Thanks Jared,

    Out of curiousity, how is your namespace configured - are you using the same name for external web services as the internal pool name? As we are, I am unsure whether the devices are detecting that they are external when they are actually internal (maybe a missing DNS entry or similar) and are contacting the external web services (which due to the pool name being the same as the external web services, in our case hits the front end servers and internal web services or whether they are just using the external URL when attempting to download the updates.

    I have confirmed that updates work fine externally and even if updated to the latest version, the same behaviour is experienced when attempting a downgrade.

    -Tom

     
  • Dienstag, 24. Juli 2012 17:40
     
     Beantwortet
    Anmelden
    0

    We've managed to solve our problem - it was an oversight on the configuration of our HLB.  We're using an f5 box to balance traffic across our nodes and the f5 profile (f5 calls them iApps) for Lync did not, by default, balance traffic on port 80 to our Front End nodes.

    Reading Jeff's Troubleshooting Guide, I found the logs located at <FE File Share>\1-WebServices-1\DeviceUpdateLogs\Server\Audit\imageUpdates to be quite useful (private info. omitted):

    7/23/2012 00:06:49,<Requester sip id>,<Requester ip address>,UCPhone,7/23/2012 12:06:48 AM,"0004F29659D0","0004f29659d0","POLYCOM","CX600","Rev-4","ENU",cpe.nbt;4.0.7576.0;6/23/2012 12:06:48 AM,http://<FE-FQDN>/RequestHandler/Files/UCPhone/POLYCOM/CX600/Rev-4/ENU/4.0.7577.4100/CPE/CPE.nbt;https://<FE FQDN>/RequestHandlerExt/Files/UCPhone/POLYCOM/CX600/Rev-4/ENU/4.0.7577.4100/CPE/CPE.nbt;4.0.7577.4100;5/25/2012 10:20:18 PM

    This response from the FE node to the Polycom device contains two addresses - the first of which, should be accessible to any internal web browser.  Testing the address in IE, the request failed when made to the pool FQDN, but succeeded when addresed to an individual node within the pool (thereby sidestepping our load balancer).  A few minutes setting up the HLB rules to balance on port 80 and our phones updated without a hitch.

    As you can imagine, there was a very strong urge to smack myself in the head when realizing that the source of this issue was so simple.  Hoping that my resolution somehow helps you find yours!

    • Als Antwort markiert Tom_09 Dienstag, 24. Juli 2012 18:37
    •  
     
  • Dienstag, 24. Juli 2012 18:37
     
     
    Anmelden
    0

    Jared,

    Thanks for the update, that was exactly our problem! We do have 80 configured but it was just a http-https redirect on our F5s and not load balanced back to the FE servers - I'm not sure whether I missed the http in the logs or expected the phones to follow the redirect. I have now setup an iRule on the F5s so the /RequestHandler traffic is sent to a pool with the FE servers and all other traffic is redirected to https and phones are now pulling the update internally.

    I know exactly how you feel and spent too many hours troubleshooting something so simple! Thanks again!

    -Tom

     
  • Dienstag, 26. Februar 2013 18:47
     
     
    Anmelden
    0
    Thanks Jared! This seems to be our problem as well. Can download fine if connecting to the FE but not when going to the load balancer. Now just need to figure out why our port 80 traffic is disabled on the LB.

    M.S.