none
Issue with Lync 2013 mobility - HTTP 406 on https://lyncdiscover.company.com

    Question

  • Hello all,

     

    Working on deploying a two server Lync 2013 environment.  A single server EE pool with a single server consolidated edge with NAT.   The Reverse Proxy solution is not TMG, but Port Address translation.  The issue is presenting with mobility.  Testing with iOS client, I am seeing this in the logs:

    HttpHeader:X-MS-WebTicketURL https://lyncweb.company.com/WebTicket/WebTicketService.svc

    <title>401 - Unauthorized: Access is denied due to invalid credentials.</title>

     

    Externally, I have lyncdiscover.company.com and lyncweb.company.com as A records, pointing to the Reverse Proxy IP, which directs to the "External" web site (HTTPS/4443)

     

    I have been following the technet guide here:

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

    As well Jeff Schertz's guide for Lync 2010 here:

    http://blog.schertz.name/2011/12/deploying-the-lync-2010-mobility-service/

    I have also reviewed the Deep Dive in Lync 2010 mobility here:

    http://blogs.technet.com/b/nexthop/archive/2012/04/25/lync-server-2010-mobility-deep-dive-autodiscover-service.aspx

     

    The biggest part where the instructions from Jeff's blog are not working is he states you can test client connectivity by opening https://lyncdiscover.company.com in a browser and be prompted to download the redirection file.  When I attempt this, I am given a HTTP 406 error.  From the IIS logs, it looks like this:

    2012-12-11 22:28:56 192.168.2.113 GET / - 4443 - 72.122.19.119 Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+6.2;+WOW64;+Trident/6.0) 406 0 0 146

     

    So I began trying to use the test cmdlets to get more information

     

    Results of Test-CsMcxP2PIM:

    Target Fqdn   : lync-ee.fed15.org

    Target Uri    : https:// lync-ee.fed15.org:443/CertProv/CertProvisioningSer

                    vice.svc

    Result        : Failure

    Latency       : 00:00:00

    Error Message : No response received for Web-Ticket service.

                    Inner Exception:The HTTP request is unauthorized with client

                    authentication scheme 'Ntlm'. The authentication header

                    received from the server was 'Negotiate,NTLM'.

                    Inner Exception:The remote server returned an error: (401)

                    Unauthorized.

    Diagnosis     :

                    Inner Diagnosis:X-MS-Server-Fqdn : LYNC-EE.fed15.org

                    Cache-Control : private

                    Content-Type : text/html; charset=utf-8

                    Server : Microsoft-IIS/7.5

                    WWW-Authenticate : Negotiate,NTLM

                    X-Powered-By : ASP.NET

                    X-Content-Type-Options : nosniff

                    Date : Tue, 11 Dec 2012 00:13:04 GMT

                    Content-Length : 6639

     

    In the IIS logs, I see hits to:

    /CertProv/CertProvisioningService.svc/WebTicket_Proof

     

    Failing with a 500 error.

     

    In IIS, the external site’s Auth provider is negotiate;NTLM, and the CertProv virtual directory is NTLM only.  So then I thought mobility may require Kerberos authentication in place.. so I enabled Kerberos and the issue is persisting.

     

    The testocsconnectivity site tests this successfully:

    Attempting to test Auto-Discover Web Service URL https://lyncdiscover.company.com:443/Autodiscover/AutodiscoverService.svc/root.

             Auto-Discover Web Service URL is successfully tested.

    Test Steps

             

    Attempting to Resolve the host name lyncdiscover.company.com in DNS.

             Host successfully Resolved

    Additional Details

             IP(s) returned: 11.22.33.44

    Testing TCP Port 443 on host lyncdiscover.company.com to ensure it is listening/open.

             The port was opened successfully.

    Testing SSLCertificate for validity.

             The certificate passed all validation requirements.validation checks.

    Additional Details

             Subject: CN=lyncweb.company.com, OU=IT Department, O=Company, L=Houston, S=Texas, C=US, Issuer CN=GeoTrust SSL CA, O="GeoTrust, Inc.", C=US

    Testing Http Authentication Methods for URL https://lyncdiscover.company.com:443/Autodiscover/AutodiscoverService.svc/root/user

             Http Authentication Methods are correct

    Additional Details

             Found as expected Web Ticket URL and confirmed no anonymous access allowed.

    Testing Http Content for URL https://lyncdiscover.company.com:443/Autodiscover/AutodiscoverService.svc/root/domain has McxService.svc

             Http Content is verified

    Additional Details

             Found as expected McxService.svc and confirmed no anonymous access allowed.

     

    Then, I found this in the Lync Application event log - and while it does not seem related, it is important to note that the SIP URI in place here (company.com) is NOT configured for Exchange autodiscover at this time.  (this also impacts Lync->EWS calendar for presence updates)  This seems related - but is it my root cause?

     

    Storage Service had an EWS Autodiscovery failure.

     

    StoreWebException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=Chris.Lehr@company.com, Autodiscover Uri=https://autodiscover.company.com/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL>, WebExceptionStatus=NameResolutionFailure ---> System.Net.WebException: The remote name could not be resolved: 'autodiscover.company.com'

       at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)

       at System.Net.HttpWebRequest.GetRequestStream()

       at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverRequest.InternalExecute()

       --- End of inner exception stack trace ---

       at Microsoft.Rtc.Internal.Storage.Exchange.ExchangeContext.SendGetUserSettingsRequest(StoreContext ctx, String smtpAddress)

       at Microsoft.Rtc.Internal.Storage.Exchange.ExchangeContext.GetUserEwsSettings(StoreContext ctx, String smtpAddress, CacheMode cacheMode)

     

    Cause: Autodiscovery Uri was not correctly configured or unreachable, that there is a problem with the Proxy, or other errors.

    Resolution:

    Check event details.  Check autodiscovery Uri is properly configured and reachable. Check that proxy setting is properly configured and reachable.  Validate Lync to Exchange Autodiscovery configuration by following the trouble shooting guide. If problem persists, notify your organization's support team with the event details.

     

    Any and all help is appreciated  :)


    • Edited by chrislehr Wednesday, December 12, 2012 12:08 AM
    Tuesday, December 11, 2012 11:24 PM

All replies

  • Hi,

    Can you take a look at the following article : http://social.technet.microsoft.com/Forums/en-US/ocsmobility/thread/f16c4a95-df04-4ec7-95a0-4acd94bed9ee

    Maybe it can help troubleshooting your problem...

    Regards,


    Adrian TUPPER - ABC Systemes - http://thelyncexperience.blog.com/ If answer is helpful, please hit the green arrow on the left, or mark as answer Thank you



    Wednesday, December 12, 2012 11:02 AM
  • Hi,

    Can you take a look at the following article : http://social.technet.microsoft.com/Forums/en-US/ocsmobility/thread/f16c4a95-df04-4ec7-95a0-4acd94bed9ee

    Maybe it can help troubleshooting your problem...

    Regards,


    Adrian TUPPER - ABC Systemes - http://thelyncexperience.blog.com/ If answer is helpful, please hit the green arrow on the left, or mark as answer Thank you




    reviewed that one yesterday as well. i think im further along than he is since the OCS connectivity tester succeeds for me when running the lync mobile autodiscover test.
    Wednesday, December 12, 2012 2:06 PM
  • Hi,

    Is the IOS client up to date ?

    When you said that you activated NTLM on the IIS service, have you enabled it manually or through the Control Panel ? Go to your CSCP then Security

    Regards,


    Adrian TUPPER - ABC Systemes - http://thelyncexperience.blog.com/ If answer is helpful, please hit the green arrow on the left, or mark as answer Thank you

    Wednesday, December 12, 2012 3:26 PM
  • Hi,

    Is the IOS client up to date ?

    When you said that you activated NTLM on the IIS service, have you enabled it manually or through the Control Panel ? Go to your CSCP then Security

    Regards,


    Adrian TUPPER - ABC Systemes - http://thelyncexperience.blog.com/ If answer is helpful, please hit the green arrow on the left, or mark as answer Thank you

    Yes, IOS Lync client is patched.

    NTLM enabled in the CSCP, I was read-only while reviewing settings using IIS manager.

    Wednesday, December 12, 2012 3:28 PM
  • Hi,

    Do you have any luck now? Please have a check if you can download the Lyncdiscover file in the external network with IE9. If not, maybe still something wrong configuration with your mobility deployment.


    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. This can be beneficial to other community members reading the thread.

    Sean Xiao
    TechNet Community Support

    Monday, December 17, 2012 6:55 AM
    Moderator
  • Hi,

    Do you have any luck now? Please have a check if you can download the Lyncdiscover file in the external network with IE9. If not, maybe still something wrong configuration with your mobility deployment.


    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. This can be beneficial to other community members reading the thread.

    Sean Xiao
    TechNet Community Support

    Good point.   Both internally and externally, if I go to the respective lyncdiscover URL, I get a blank web page.  No content is displayed.  No prompt for a file download.  This is part of what is making me think something is wrong.  The Internal URL especially, since there is less to be wrong there (no firewall, no cert trust issues (internally signed CA, etc)

    Can't find much on troubleshooting Lync mobility online yet.  I think I am opening a case this week to get this resolved.

    Monday, December 17, 2012 3:13 PM
  • Hi,

    I unfortunately don’t have a solution yet, but I’m experiencing a very similar issue. Here is my setup:

    - One Lync 2013 Standard Edition Server on Windows 2012 Standard.

    - One Lync 2013 Edge Server on Windows 2012 Standard.

    - A non TMG firewall.

    - sip.mydomain.com is translated to the Edge server's external adapter (on TCP ports 443, 5061 + audio/video). Lync clients External access and federation with other organizations work fine.

    - lyncdiscover.mydomain.com:443 is translated to port 4443 of my Standard Edition Server.

    Just like you, whenever I go to https://LyncStandardEditionServer as well as https://LyncStandardEditionServer:4443 (or https://lyncdiscover.mydomain.com externally) no autodiscover file is proposed and I obtain error 406.

    Lync Mobile doesn’t work from the outside but it does from the inside (with record lyncdiscoverinternal.mydomain.internal)

    And Lync Mobile Connectivity test does run successfully…

    Tuesday, December 18, 2012 10:50 PM
  • Hi,

    I unfortunately don’t have a solution yet, but I’m experiencing a very similar issue. Here is my setup:

    - One Lync 2013 Standard Edition Server on Windows 2012 Standard.

    - One Lync 2013 Edge Server on Windows 2012 Standard.

    - A non TMG firewall.

    - sip.mydomain.com is translated to the Edge server's external adapter (on TCP ports 443, 5061 + audio/video). Lync clients External access and federation with other organizations work fine.

    - lyncdiscover.mydomain.com:443 is translated to port 4443 of my Standard Edition Server.

    Just like you, whenever I go to https://LyncStandardEditionServer as well as https://LyncStandardEditionServer:4443 (or https://lyncdiscover.mydomain.com externally) no autodiscover file is proposed and I obtain error 406.

    Lync Mobile doesn’t work from the outside but it does from the inside (with record lyncdiscoverinternal.mydomain.internal)

    And Lync Mobile Connectivity test does run successfully…

    When you do https://lyncdiscoverinternal.company.com do you get a autodiscover file prompt to download?
    Tuesday, December 18, 2012 11:06 PM
  • I have the same issue 

    Windows 2008 R2 SP1 + Front End Lync 2013 Std Edition

    Reverse Proxy TMG 2010

    When I do https://lyncdiscoverinternal.company.com and https://lyncdiscover.company.com in IE 9 I receive blank page - HTTP 406 only.

    Publish rule meet dialin works fine

    review all - DNS, Certificates, rules...

    https://internalFQDNFrontEnd.company.com/Mcx/McxService.svc - HTTP Error 401.0

    https://ExternalFQDNFrontEnd.company.com/Mcx/McxService.svc - HTTP Error 401.0



    • Edited by ЮА Wednesday, December 19, 2012 10:53 PM
    Wednesday, December 19, 2012 10:48 PM
  • I have the same problem. is it bug?

    Friday, December 21, 2012 9:08 PM
  • Anyone found a solution?
    Friday, December 28, 2012 6:13 AM
  • is it a bug? I have the same problem.


    Saturday, December 29, 2012 7:50 PM
  • i have the same problem,but lync for moblie login successful!

    so, it's normal


    ===godoha===


    Friday, January 04, 2013 6:27 AM
  • so you don't have autodiscover.svc file and lync mobile clients are login with aotodiscovery with no problem?
    Friday, January 04, 2013 12:33 PM
  • Have same issue!

    MCSE:S, MCSE:M, MCITP, MCTS, CCNA, CCDA Infrastructure expert

    Friday, January 04, 2013 5:31 PM
  • for everyone who is thinking that it's problem.

    as godoha told us his mobile client were conected.

    my mobile clients also can connect to mobility service, so there must not be autodiscover.svc file.

    this is not bug, it must be as it is.

    if test-CsMcxP2PIM is ok, everything is ok.
    so in lync 2013 we cannot check autodisocvery working with opening http://lyncdisocver.<sipdomain>

    :)


    Saturday, January 05, 2013 6:58 PM
  • Hi,

    I've the same issue. My investigation are:

    https://www.testexchangeconnectivity.com says everything is OK.

    IE9 says 406 on https://lyncdiscover.domain.com/Autodiscover/AutodiscoverService.svc/root

    IE9 says 401 on https://lyncdiscover.domain.com/Autodiscover/AutodiscoverService.svc/root/user

    IE9 says 406 on https://lyncdiscover.domain.com/Autodiscover/AutodiscoverService.svc/root/domain

    My setup is Lync Server Standart 2013 FrontEnd on Windows Server 2012.

    P.S.

    I've Lync Server 2010 pool in my eviroment and when user is in that pool and set manualy autodiscover url to old server's webservices my symbian client has connected.

    Can be the problem with interoperability between Lync Client for symbian(Belle) and new Lync Server 2013 WebServices?

    Edit: iOS, Android and Windows phones works without problems!

    • Edited by Angel Dabov Monday, January 07, 2013 10:45 AM
    Monday, January 07, 2013 10:08 AM
  • anybody with feedback? having the exact same issue. I have tried with IOS and Android. from both the internal and external network. My mobile devices won't register, neither will the windows 8 version of lync client (uses the same autodiscover method as the mobile).
    Thursday, January 10, 2013 6:53 PM
  • anybody with feedback? having the exact same issue. I have tried with IOS and Android. from both the internal and external network. My mobile devices won't register, neither will the windows 8 version of lync client (uses the same autodiscover method as the mobile).

    Hi devo,

    What kind of device don't able to connect ?

    In my situation the problem persist only with Symbian (Belle,Anna). iOS Android and WP works very well...

    Regards

    Wednesday, January 16, 2013 5:48 AM
  • I have similar symptom; Lync FE 2013 Standard on Server 2012, Lync 2010 pool with Lync 2010 Edge.

    Android & iPhone can connect internal & external
    Windows desktop client can connect internal & external
    Windows 8 app can connect external, not internal (spinning bees forever)
    Windows Phone can't connect at all

    Monday, January 21, 2013 3:46 PM
  • Hi,
    I have the same issue but only with iOS when externally, others mobile OS work fine both internally and externally.
    Windows 2008 R2 SP1 + Front End Lync 2013 EE Edition
    Reverse Proxy NGINX

    Anyone found a solution?
    Monday, January 28, 2013 3:30 PM
  • We too are seeing this on a 

     - Single Standard Edition running Autodiscover
     - Single Edge Server
     - NAT or Apache Reverse Proxy or Squid Reverse Proxy proxying 443 on lyncdiscover.corp.company.name -> StandardEdition:443

    Both remote connectivity analyser for Lync Server Remote Connectivity Test and Lync Mobile Auto-Discover Web Service Remote Connectivity Test are passing 100% fine and I can log in using desktop client fine, as well as Xavy on ipad/iphone, but the official iOS app fails on both iPad and iPhone with invalid email address,( n.b. my domain login, corp\user, is specified in the app, but it is worth noting my upn, alanc@corp.company.local doesn't match my SIP login, alanc@companyname.net, I've seen references to this having to match, but i can't really see how or why this would have to be the case  - lots of of companies have a .local / .home domain and I don;t want to have to pay a SSL provider to provide loads of .local SAN names on my certs). 

    2013-02-01 16:36:44.393 Lync[197:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/492:MetaData retrieval for url https://lync.company.name/autodiscover/autodiscoverservice.svc/root/user completed with status 570556421
    2013-02-01 16:36:44.394 Lync[197:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/521:Deleting 2 pended Meta data requests for url https://lync.company.name/autodiscover/autodiscoverservice.svc/root/user
    2013-02-01 16:36:44.395 Lync[197:907] ERROR TRANSPORT /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/562:Unable to get the meta data for server url https://lync.company.name/autodiscover/autodiscoverservice.svc/root/user
    2013-02-01 16:36:44.395 Lync[197:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/581:Failing request to the request manager
    2013-02-01 16:36:44.396 Lync[197:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestManager/private/CRequestManager.cpp/100:Failing secure request UcwaAutoDiscoveryRequest with status 570556421
    2013-02-01 16:36:44.397 Lync[197:907] ERROR TRANSPORT /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/562:Unable to get the meta data for server url https://lync.company.name/autodiscover/autodiscoverservice.svc/root/user
    2013-02-01 16:36:44.398 Lync[197:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/581:Failing request to the request manager
    2013-02-01 16:36:44.398 Lync[197:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestManager/private/CRequestManager.cpp/100:Failing secure request UcwaAutoDiscoveryRequest with status 570556421
    2013-02-01 16:36:44.399 Lync[197:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../transportManager/private/CTransportManager.cpp/624:Notifying response of request(UcwaAutoDiscoveryRequest) with status = 0x22020005
    2013-02-01 16:36:44.400 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/293:Req. event received: responseErrorCode=E2-2-5
    2013-02-01 16:36:44.400 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/870:No more req. timing out
    2013-02-01 16:36:44.401 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryService.cpp/973:Received autodiscovery response with status 570556421
    2013-02-01 16:36:44.402 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryService.cpp/931:Raising Autodiscovery event with status 570556421 for eventType 0
    2013-02-01 16:36:44.403 Lync[197:907] ERROR APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryServiceRetrialWrapper.cpp/348:Auto-discovery failed. Analysing the failure
    2013-02-01 16:36:44.403 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryServiceRetrialWrapper.cpp/505:Scheduled retrial timer. Timer 0
    2013-02-01 16:36:44.404 Lync[197:907] ERROR APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../objectModel/private/CAlertReporter.cpp/52:Alert received! Type 16384, level 0, error E2-2-5, context ''
    2013-02-01 16:36:44.405 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/utilities/CMUIUtil.mm/968:Mapped error message is 'Can’t connect to the server. It may be busy or temporarily unavailable. Please try again.'
    2013-02-01 16:36:44.406 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/alert/CMAlertViewController.mm/350:alert received type 16384, error 570556421, error string Can’t connect to the server. It may be busy or temporarily unavailable. Please try again.
    2013-02-01 16:36:44.407 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1088:handling floating views
    2013-02-01 16:36:44.408 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1108:desired view is alert
    2013-02-01 16:36:44.409 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1263:reposition floating views
    2013-02-01 16:36:44.410 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/702:Response received for req. <unknown>: E2-2-5 (RemoteNetworkTemporaryError); Done with req.; Stopping resend timer
    2013-02-01 16:36:46.774 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CLogonSession.cpp/452:Called signOut() in state 1
    2013-02-01 16:36:46.775 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1088:handling floating views
    2013-02-01 16:36:46.776 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1108:desired view is alert
    2013-02-01 16:36:46.777 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1263:reposition floating views
    2013-02-01 16:36:46.777 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1088:handling floating views
    2013-02-01 16:36:46.778 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1108:desired view is alert
    2013-02-01 16:36:46.779 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1263:reposition floating views
    2013-02-01 16:36:46.780 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1088:handling floating views
    2013-02-01 16:36:46.780 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1108:desired view is alert
    2013-02-01 16:36:46.781 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1263:reposition floating views
    2013-02-01 16:36:46.782 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryServiceRetrialWrapper.cpp/531:Timer cancelled. OnResume = 0
    2013-02-01 16:36:46.782 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1088:handling floating views
    2013-02-01 16:36:46.783 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CLogonSession.cpp/822:CLogonSession canceling all requests
    2013-02-01 16:36:46.784 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CLogonSession.cpp/845:CLogonSession::setNewActualState() state=0
    2013-02-01 16:36:46.785 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/374:UpdateViews
    2013-02-01 16:36:46.785 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/440:ActualState = IsSignedOut DesiredState = BeSignedOut DataAvailable = 0 Showing UI = CredentialTableViewController
    2013-02-01 16:36:46.788 Lync[197:907] INFO UI /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/ui/CMAppDelegate.mm/1088:handling floating views
    2013-02-01 16:36:46.790 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryServiceRetrialWrapper.cpp/531:Timer cancelled. OnResume = 0
    2013-02-01 16:36:46.800 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../objectModel/private/CPersistableObjectBase.cpp/156:Storing 1 out-of-sync Object Models took 4ms
    2013-02-01 16:36:50.398 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CMcxDataSynchronizer.cpp/1151:Mode 1 scheduled to timeout in 30.000000s
    2013-02-01 16:36:50.400 Lync[197:907] INFO APPLICATION /Users/comobuildadmin/icomo/private/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CMcxDataSynchronizer.cpp/1011:No SendUpdate schedule action. timerStarted=0, timerNeedsToRun=0, channelState=0, timerAction=0
    2013-02-01 16:36:52.735 Lync[197:907]  is not a valid email address.


      


    Friday, February 01, 2013 4:42 PM
  • We too are seeing this on a 

     - Single Standard Edition running Autodiscover
     - Single Edge Server
     - NAT or Apache Reverse Proxy or Squid Reverse Proxy proxying 443 on lyncdiscover.corp.company.name -> StandardEdition:443

    Both remote connectivity analyser for Lync Server Remote Connectivity Test and Lync Mobile Auto-Discover Web Service Remote Connectivity Test are passing 100% fine and I can log in using desktop client fine, as well as Xavy on ipad/iphone, but the official iOS app fails on both iPad and iPhone with invalid email address,( n.b. my domain login, corp\user, is specified in the app, but it is worth noting my upn, alanc@corp.company.local doesn't match my SIP login, alanc@companyname.net, I've seen references to this having to match, but i can't really see how or why this would have to be the case  - lots of of companies have a .local / .home domain and I don;t want to have to pay a SSL provider to provide loads of .local SAN names on my certs). 

    <snip>

    2013-02-01 16:36:52.735 Lync[197:907]  is not a valid email address.  

    This might be a hint.  Just curious, but for your SIP domain - is Exchange autodiscover working and in place?   This particular customer has Exchange, but their SIP URI is their "new" domain, and their Exchange autodiscover has not yet been configured for the new domain. 

    Seeing your email error made me take it into consideration, but can anyone confirm if that is the same situation for any of you?

    Friday, February 01, 2013 4:49 PM
  • Hi All,

    I think I've got to the bottom of this:

    Current set up:

     - Std Ed FE Pool with a fdqn of fe1.companyname.local
     - Edge Pool with a fqdn of fe1.companyname.local

    FE and Edge pools are on publics IPs firewalled, sat in a DMZ

    I've set up a TMG Reverse Proxy to proxy my simple x.companyname.com URLs and lyncdiscover.company.com through to the .local web services.

    Lyncdiscovery web service is definitely serving off the External website rather than the Internal website, verified by turning the sites off individually and verifying lyndiscover.company.com only works when the External site is running.

    This all works fine for everything else - Desktop Client, web clients, even Xavy on iPad work externally, lync still refuses to login.

    From the iPhone debug logs, I can see the lyncdiscovery service is telling the iPad to use the .local FQDN of the Standard Edition FE pool to get a webticket.

    On the external network the Ipad client is connecting from, I set up a local DNS server with a zone for the .local domain and put an A record in for fe1.companyname.local and the iPad client could then log in.

    I can't see anywhere to override the webticket URL - can anyone advise if this can be configured at all? I'm keen to avoid a lot of work to reconfigure the FQDN of the Standard pool to be an externally resolvable one (this would involve building new pools and moving CMC etc).

    Surely there's a way to override?

    2013-02-02 17:52:35.839 Lync[1383:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/icomo_ipad/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/492:MetaData retrieval for url https://fe1.companyname.local/webticket/webticketservice.svc completed with status 570556421
    2013-02-02 17:52:35.840 Lync[1383:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/icomo_ipad/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/521:Deleting 1 pended Meta data requests for url https://fe1.companyname.local/webticket/webticketservice.svc
    2013-02-02 17:52:35.842 Lync[1383:907] ERROR TRANSPORT /Users/comobuildadmin/icomo/private/icomo_ipad/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/562:Unable to get the meta data for server url https://fe1.companyname.local/webticket/webticketservice.svc
    2013-02-02 17:52:35.843 Lync[1383:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/icomo_ipad/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/569:Failing request to the the webTicket session
    2013-02-02 17:52:35.844 Lync[1383:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/icomo_ipad/src/dev/CoMo/transport/_buildIos/../webTicket/private/CWebTicketSession.cpp/1022:Raising WebTicketEvent for https://fe1.companyname.local/autodiscover/autodiscoverservice.svc/root and https://fe1.companyname.local/webticket/webticketservice.svc with status 570556421
    2013-02-02 17:52:35.845 Lync[1383:907] INFO TRANSPORT /Users/comobuildadmin/icomo/private/icomo_ipad/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/605:Web-Ticket retrieval for url https://fe1.companyname.local/autodiscover/autodiscoverservice.svc/root completed with status 570556421
    2013-02-02 17:52:35.846 Lync[1383:907] ERROR TRANSPORT /Users/comobuildadmin/icomo/private/icomo_ipad/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/671:Failing the original request as we weren't able to get thewebticket


    Saturday, February 02, 2013 7:21 PM
  • Doing some more troubleshooting on a different installation (Lync 2013 + UAG -- not straightforward!) we find that as this thread has shown, https://lyncdiscover.sipdomain.com/autodiscover/autodiscoverservice.svc/root and any combination don't work (error 406) which seems to be a new 'feature' in Lync 2013.

    However https://lyncexternalurl.sipdomain.com/webticket/webticketservice.svc does seem to 'work' OK -- it should prompt for authentication. (On this site, it does for iPhone & Windows desktop but not for Android.)

    Friday, February 08, 2013 12:43 PM
  • This is a known issue and is slated to be resolved in the next cumulative update for Lync Server 2013.  This only impacts accessing the directory manually with a browser.

    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    Wednesday, February 13, 2013 2:48 PM
    Moderator
  • Could this be related to the issue with Lync client for Symbian(Belle).

    P.S.

    When this update will be released and what are other fixes?

    Regards,

    Angel

    Thursday, February 14, 2013 7:10 AM
  • Microsoft has not yet released details on the timing and contents of the first CU package for Server 2013. (The client CU was released earlier this week though).


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    Thursday, February 14, 2013 3:35 PM
    Moderator
  • Hello,

    I've applied the CU1 but the issue with 406 and Symbian Belle clients still exist.

    Regards.

    Sunday, March 03, 2013 4:54 PM