none
Mobility Installation - Cannot set ports

    Question

  • Hey there - Currently trying to get mobility installed on Lync internal server while we are in a merged environment.  We are still merged and in a testing phase.  The OCS2007 edge is still being used for SIP logins, etc. until we make the full edge swing.  I wanted to get mobility working before we start moving the entire business.  I have been following the guides - but run into issues when setting the web listener ports.  Any ideas?

    So it seems as though that is more a failure than a warning... because the following Enable-CsTopology command notices no changes and the port is not in fact open.

    Do I need to swing completely to the Lync edge before doing mobility?

    Wednesday, February 15, 2012 7:20 PM

Answers

  • My certs are GoDaddy.  I actually solved this problem yesterday afternoon, with help from the experts at Microsoft "tier 3" support.  The engineer had me to packet captures on our F5 units for both an iPhone and a WP7 connection.  The former fails, the latter succeeds.  He compared the packet captures and found that the iPhone tries to initiate a TLS v1.2 connection, and the F5 closes the connection.  The WP7 initiates a TLS v1.0 connection, and communication continues.  With that information, I found this F5 KB article: https://support.f5.com/kb/en-us/solutions/public/13000/000/sol13037.html?sr=19939546.  This article identifies a TLS bug in specific firmware versions when using TLS v1.1 or v1.2.  The solution is to upgrade to at least BIG-IP v10.2.2 HF1.  I was on the release version of 10.2.2.  I updated to 10.2.2 HF4, and iPhones and iPads could suddenly connect fine.

    • Proposed as answer by Ed051042 Thursday, March 08, 2012 1:53 PM
    • Marked as answer by Sipple3131 Tuesday, March 13, 2012 7:28 PM
    Thursday, March 08, 2012 1:53 PM

All replies

  • What is the result when you do Netstat -an?  Is something listening on those ports?
    Thursday, February 16, 2012 4:40 PM
  • Hi Jay - good to hear from you again.

    I was able to get a bit further.  Currently with the Netstat I see things listening on 5087 but not 5086.  We have been able to connect an Android externally but not internally.  iDevices won't connect either way.

    The external and internal  https://lyncdiscover.domain.com/autodiscover/autodiscover.svc/ links are working properly and we've also done this: Lync Control Panel -> security - Web Service -> change Windows authentication to "Negotiate".  The testing scripts run through successfully.

    With my iPhone it fails instantly if I have it on autodiscover claiming it cant find server (yes, it is in DNS).  If I input the server names myself it sits and spins indefinitely.  I have even installed our internal CA root cert on my phone.

    Thursday, February 16, 2012 4:49 PM
  • Hopefully I am helping a bit.

    The netstat shows that command ran succesfully.  Have you prepared everything for the push notifications needed for the mac?  Do you have port 5061 open outbound from the edge server?  What happens when you run this command?



    Test-CsMcxP2PIM -TargetFqdn <FQDN of Front End pool>
    -SenderSipAddress sip:<SIP address of test user 1> -SenderCredential
    <test user 1 credentials> -ReceiverSipAddress sip:<SIP address of test
    user 2> -ReceiverCredential <test user 2 credentials> –v<o:p></o:p>

    Internally your dns record for lyncdiscover must point to the same external IP address as what is being used.

    Check this document out.  Make sure you put in everything for push notifications.

    http://www.microsoft.com/download/en/confirmation.aspx?id=28355

    Thursday, February 16, 2012 5:01 PM
  • that test runs through correctly.  Yes 5061 is open outbound from edge.  So let me clarify two things:

    1- Push needs to be setup just for iDevices to log in?  I have no set up anything for push yet.

    2- I do not have lyncdiscover set up for the external IP because there is no route to it from inside our network.  Are you saying put it there anyways?  I could put lyncdiscover and put in the DMZ address which it would be able to get to.

    Thursday, February 16, 2012 5:07 PM
  • I believe the iphone only works on push.  I just know that we setup push and everything worked fine.  As for the lyncdiscover it is a bit weird.  The client always wants to talk with lyncdiscover on 443 but it really only works on 4443 so it has to go back through the proxy.  It is weird I know.
    Thursday, February 16, 2012 5:45 PM
  • Lync should be better known as the never ending project.  All the federation commands are in - but this is what happens why I try to test/verify:


    Thursday, February 16, 2012 8:16 PM
  • I'm going to skip internal and just try to get external working.

    So I changed my external lyncdiscover.domain.com to point directly to the F5 web services reverse-proxy which routes to the web services on my Lync front end.

    External DNS= lyncdiscover -> https://websvcs.domain.com/Autodiscover/AutodiscoverService.svc/root

    Android works... iPhones do not.  Here are the errors from my iPhone log... they are the same whether I do autodiscover or not. 

    2012-02-16 18:46:50.290 Lync[1569:5007] ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpConnection.cpp/900:Request Type = UcwaAutoDiscoveryRequest Error domain = kCFErrorDomainCFNetwork code = 0x2 ErrorDescription = The operation couldn‚Äôt be completed. (kCFErrorDomainCFNetwork error 2.) ErrorFailureReason =  ErrorRecoverySuggestion =  
    2012-02-16 18:46:50.291 Lync[1569:5007] ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpConnection.cpp/829:GetAddrInfo returned has error 0x69ab80
    2012-02-16 18:46:50.296 Lync[1569:707] INFO APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/293:Req. event received: responseErrorCode=E2-2-1
    2012-02-16 18:46:50.302 Lync[1569:707] ERROR APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryGetUserUrlOperation.cpp/322:Request failed.  Error - E2-2-1
    2012-02-16 18:46:50.303 Lync[1569:707] INFO APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/702:Response received for req. <unknown>: E2-2-1 (RemoteNetworkTemporaryError); Done with req.; Stopping resend timer
    2012-02-16 18:46:50.306 Lync[1569:5007] ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpConnection.cpp/900:Request Type = UcwaAutoDiscoveryRequest Error domain = kCFErrorDomainCFNetwork code = 0x2 ErrorDescription = The operation couldn‚Äôt be completed. (kCFErrorDomainCFNetwork error 2.) ErrorFailureReason =  ErrorRecoverySuggestion =  
    2012-02-16 18:46:50.308 Lync[1569:5007] ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpConnection.cpp/829:GetAddrInfo returned has error 0x69ab80
    2012-02-16 18:46:50.312 Lync[1569:707] INFO APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/293:Req. event received: responseErrorCode=E2-2-1
    2012-02-16 18:46:50.317 Lync[1569:707] INFO APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/702:Response received for req. <unknown>: E2-2-1 (RemoteNetworkTemporaryError); Done with req.; Stopping resend timer
    2012-02-16 18:46:50.568 Lync[1569:5007] ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpConnection.cpp/900:Request Type = UcwaAutoDiscoveryRequest Error domain = kCFErrorDomainCFNetwork code = 0x2 ErrorDescription = The operation couldn‚Äôt be completed. (kCFErrorDomainCFNetwork error 2.) ErrorFailureReason =  ErrorRecoverySuggestion =  
    2012-02-16 18:46:50.569 Lync[1569:5007] ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpConnection.cpp/829:GetAddrInfo returned has error 0x69ab80
    2012-02-16 18:46:50.575 Lync[1569:707] INFO APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/293:Req. event received: responseErrorCode=E2-2-1
    2012-02-16 18:46:50.580 Lync[1569:707] ERROR APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryGetUserUrlOperation.cpp/322:Request failed.  Error - E2-2-1
    2012-02-16 18:46:50.582 Lync[1569:707] INFO APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/702:Response received for req. <unknown>: E2-2-1 (RemoteNetworkTemporaryError); Done with req.; Stopping resend timer
    2012-02-16 18:46:50.583 Lync[1569:5007] ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpConnection.cpp/900:Request Type = UcwaAutoDiscoveryRequest Error domain = kCFErrorDomainCFNetwork code = 0x2 ErrorDescription = The operation couldn‚Äôt be completed. (kCFErrorDomainCFNetwork error 2.) ErrorFailureReason =  ErrorRecoverySuggestion =  
    2012-02-16 18:46:50.586 Lync[1569:5007] ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpConnection.cpp/829:GetAddrInfo returned has error 0x69ab80
    2012-02-16 18:46:50.591 Lync[1569:707] INFO APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/293:Req. event received: responseErrorCode=E2-2-1
    2012-02-16 18:46:50.596 Lync[1569:707] INFO APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CTransportRequestRetrialQueue.cpp/702:Response received for req. <unknown>: E2-2-1 (RemoteNetworkTemporaryError); Done with req.; Stopping resend timer
    2012-02-16 18:46:50.602 Lync[1569:707] ERROR APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryServiceRetrialWrapper.cpp/348:Auto-discovery failed. Analysing the failure
    2012-02-16 18:46:50.605 Lync[1569:707] ERROR APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../objectModel/private/CAlertReporter.cpp/52:Alert received! Type 16384, level 0, error E3-6-2, context ''
    2012-02-16 18:46:50.607 Lync[1569:707] INFO UI /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/ui/utilities/CMUIUtil.mm/968:Mapped error message is 'Can’t connect to the server.  It might be unavailable.  Also please check your network connection, sign-in address and server addresses.'
    2012-02-16 18:46:50.608 Lync[1569:707] INFO UI /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/ui/alert/CMAlertViewController.mm/350:alert received type 16384, error 587595778, error string Can’t connect to the server.  It might be unavailable.  Also please check your network connection, sign-in address and server addresses.


    Friday, February 17, 2012 12:57 AM
  • The mobility documents only states Lync Edge or OCS 2007 R2 edge to be configured for push notification, so OCS 2007 Edge would be unsupported

    To login from iphone, I dont think you need to make push notifications working. Push notification is required for iphone and win7 phones as the application is suspended when its in the background

    The internal DNS server should only have the lyncdiscoverinternal record and the public DNS should have the lyncdisocver record

    Whether the user is using internal WIFI or is external using GPRS, the user is always returned the external web serivces url, this is the reason the internal DNS server should have the public IP address of the external webservice url for internal users and the internal users are hairpinned from the internal network to the public IP of your reverse proxy and then to port 4443 of the Lync FE server

    Can you describe the environment, do you have a pool of Lync server or a single std edition server.

    The internal and external webservice url should be different.

    The reverse proxy should be configured to listen for the external webservice url on port 443 and proxy the request  to the internal webservices url which ususally point to the pool or std editon lync server on port 4443

    If you would like to test mobility for internally only run the following command.

    Set-CsMcxConfiguration –ExposedWebUrl Internal

    This will return the internalwebservice url to the phone and then the phone would get the IP of the internalwebservice url from internal DNS which would directly resolve to the Lync FE server and the request would hit port 443 of the FE, and check if you can login. Make sure that if you are using internal certificates on the Lync server, email the root CA and install it on the phone.

    You can also try manual sign in Now to test externally run the following command

    Set-CsMcxConfiguration –ExposedWebUrl external

    The phone connected internally or externally will be provided the external webservice url and will try to resolve the IP to the public IP and conenct to the public IP on port 443 which is usually the reverse proxy and the reverse proxy will proxy the request to port 4443 of the FE server.

    Also try configuring the phone manually If you have pool of FE servers make sure the HLB is configured as per the mobility requirements

    The logs indicate a connectivity issue.

    Tuesday, February 21, 2012 5:16 AM
  • HI,

    I suggest you make sure lync Phone can log in internal network first. The following article is about lync mobility deployment, please read and verify if something wrong with configuration:

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


    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.

    Tuesday, February 21, 2012 5:39 AM
  • Thanks guys.  I've been through the config multiple times.  We cannot route from the internal back through the reverse proxy... so I think we will just scrap the internal connectivity for now.  Like I said... Android works so I know we're close.  Internally - If I take off autodiscover on iPhone and point it right at my front-end it just sits and spins and never connects.

    If I leave things on autodiscover (and try to connect over 3G) it throws a cert error almost instantly.  We're also having federation issues so I have a feeling the issues are connected.  May have to resort to paying for Microsoft support.  :-(

    Tuesday, February 21, 2012 2:53 PM
  • If you are having federation issues there is more than likely a problem with your certificate.  Who issued the cert?

    Please remember to click “Mark as Answer” if this resolved the issue.

    Tuesday, February 21, 2012 3:51 PM
  • Our public certs go through Thawte.  I'm assuming their root is trusted by Microsoft... but I haven't been able to confirm or deny this.
    Tuesday, February 21, 2012 3:52 PM
  • Thawte certs are supported UC certificates.  Do you have the correct dns record for _sipfederationtls._tcp.company.com pointing to the name being used on the certificate?  I do not think the issues are related but there does appear to be a certificate issue.  Mobility runs mainly through your reverse proxy.  Are they using the same cert with different SANs?

    Please remember to click “Mark as Answer” if this resolved the issue.

    Tuesday, February 21, 2012 4:01 PM
  • good to hear Thawte should work.  I have checked the dns record and confirmed it exists with the SRVlookup tool.  It points to lync.domain.com which is most certainly in our cert.  We are using the same cert on the RP which has everything we should need in the SANs.  iPhones still giving cert errors no matter what.  I'm really at a loss at this point.
    Tuesday, February 21, 2012 6:06 PM
  • Well we were finally able to get on internally by using the UPN format for the username.  No idea why it is like this and not in Netbios format.  The odd thing is it wasn't erroring that there was a credential issue but that it couldn't reach the server at all!  WRONG!

    So we know the servers are working properly and the outside/public cert issue is something related to our F5.  It's very weird to me that the Androids work and the iPhones don't.

    All federation tests complete successfully... makes me wonder if they really haven't completed their end (PIC Provisioning team) despite sending us the "all-clear" email.  I'd love to chat with someone from Microsoft about it - but everything is paid!  grrrr


    • Edited by Sipple3131 Tuesday, February 21, 2012 10:35 PM
    • Proposed as answer by Ed051042 Thursday, March 08, 2012 2:12 PM
    • Unproposed as answer by Ed051042 Thursday, March 08, 2012 2:12 PM
    Tuesday, February 21, 2012 10:34 PM
  • @sipple3131 Did you ever find a solution?  I'm experiencing the exact same problem with F5 + Lync mobility + iOS.
    Wednesday, March 07, 2012 7:08 PM
  • I replied to your post over at F5 DevCentral Link 

    I think this is more of a F5 problem than a Microsoft problem.  It's really odd even though my iPhone isn't connecting externally I get push notifications of missed convos.  Of course I can't reply to them without logging in, though.  Kinda crazy!

    Are you using Thawte certs too Ed?

    Thursday, March 08, 2012 1:48 PM
  • My certs are GoDaddy.  I actually solved this problem yesterday afternoon, with help from the experts at Microsoft "tier 3" support.  The engineer had me to packet captures on our F5 units for both an iPhone and a WP7 connection.  The former fails, the latter succeeds.  He compared the packet captures and found that the iPhone tries to initiate a TLS v1.2 connection, and the F5 closes the connection.  The WP7 initiates a TLS v1.0 connection, and communication continues.  With that information, I found this F5 KB article: https://support.f5.com/kb/en-us/solutions/public/13000/000/sol13037.html?sr=19939546.  This article identifies a TLS bug in specific firmware versions when using TLS v1.1 or v1.2.  The solution is to upgrade to at least BIG-IP v10.2.2 HF1.  I was on the release version of 10.2.2.  I updated to 10.2.2 HF4, and iPhones and iPads could suddenly connect fine.

    • Proposed as answer by Ed051042 Thursday, March 08, 2012 1:53 PM
    • Marked as answer by Sipple3131 Tuesday, March 13, 2012 7:28 PM
    Thursday, March 08, 2012 1:53 PM
  • Ed, did you have a case open with F5 at all that we could have our F5 rep reference?
    Thursday, March 08, 2012 2:24 PM
  • No I just had a case with Microsoft (#112022048453413).  We were able to figure out this solution without involving F5.
    Thursday, March 08, 2012 2:28 PM
  • Interestingly enough... mobility works like a champ now after the F5 update.  I can't believe they didn't have that as basic prerequisite for this installation.  However, now my Lync Web App comes up with "The meeting link you are using to join is not valid. Please check the link and try again".  Works fine with attendee.

    Web App logging says: 

    "errorID=28032, reason=The web ticket is invalid."

    "Web Ticket failed @ State AcquiringTicket with Error Code CredentialInvalid"

    Works fine internally or VPNd.  The web ticket service is available via https://pool.domain.com/webticket/webticketservice.svc internally and externally.  It prompts for user/pass.

    Tuesday, March 13, 2012 7:57 PM