Sign in
 
HomeOnline20132010Interop ProgramsLibraryForumsGalleryLync Blogs
TechCenter >
> 
> 
Lync mobile handing out internal URL instead of external

Answered Lync mobile handing out internal URL instead of external

  • Monday, April 30, 2012 10:33 PM
     
     
    Sign In to Vote
    0

    hello,

    tyring to get Lync Mobile working for my android.  i believe everything is setup corretly as far as DNS and certs. However if i go to https://externalwebservices.mydomain.com/mcx/mcxservcie.svc from external i do get the service page, but the URL it returns for the svcutil.exe uses the internal FQDN of the server (https://servername.mydomain.local:4443/Mcx/McxService.svc/mex?wsdl and not the webservices FQDN

    i get a similar result when going to the webticket service page.

    our sign in address uses the internal AD domain which is of course not availabe externally, i have my doman\username configured and also have the https://externalwebservcies.mydomain.com/Autodiscover/AutodiscoverService.svc/Root configured for both internal and external servers in the android client (we are not configuring internal access for mobile devices)

    looking at the logs can also see that the webticket decode included the FQDN of the internal server name ( INFO TRANSPORT:HttpHeader:X-MS-Server-Fqdn servername.mydomain.local) and not the webservices URL. 

    Any ideas?  I can't believe the internal FQDN of the FE pool would need to be the webservices FQDN.

    Any help would be appreciated.

     

All Replies

  • Wednesday, May 02, 2012 4:23 AM
    Moderator
     
     Answered
    Sign In to Vote
    0

    Hi,

    I suggest referring to the following tips to check the issue:

    1. Use https://www.testocsconnectivity.com/ to validate external web service Autodiscover
    2. Try to open https://lyncdiscover.<domain>, you should receive a prompt to open or save the lyncdiscover_contoso.com file. The URL identified in the lyncdiscover_<domain> file must be the external web services URL for the Lync Server 2010 Front End Server. If the internal web services URL is identified, the web publishing rule is incorrect and is bridging the connection to port 443 instead of port 4443 for the Lync external web services.

    3. Run Get-CsMCXconfiguration |fl and make sure ExposedWebUrl is set to External.

    Regards,
    Kent

     
  • Thursday, May 03, 2012 8:00 AM
     
     
    Sign In to Vote
    0

    You can also read this document to better understand the discovery mechanism : http://blogs.technet.com/b/nexthop/archive/2012/04/25/lync-server-2010-mobility-deep-dive-autodiscover-service.aspx

    Some of the webservices will be run by the webservers that will contact internal servers...

    Rgds

    JMF

     
  • Thursday, May 03, 2012 10:47 AM
     
     Answered
    Sign In to Vote
    0

    First off you need to check MCX config as Kent-Huang stated. And also make sure that your TMG rules is setup correctly.

    If you still can not access make sure that your external web URL is not lyncdiscover and that it is not the same as internal web service URL.

    Did you run MCXstandalone manually or did you trigger it through the bootstrapper?.


     
  • Monday, May 07, 2012 6:36 PM
     
     
    Sign In to Vote
    0
    make sure you are not redirecting the port from 4443 to 443 on your ISA/TMG server, 443 denotes internal services.
     
  • Monday, May 07, 2012 6:46 PM
     
     
    Sign In to Vote
    0

    443 need to be redirected to 4443. As TMG will answer on 443 so a redirect have to be configured.

     
  • Tuesday, May 08, 2012 8:07 AM
     
     Answered
    Sign In to Vote
    0

    IN the logs , it's normal that you get the internal FQDN  of the server in the INFO transport. Because the server that respond is the  internal server and it's name doesn't change if the connection is done on the external URL or Internal URL. As I see the redirection is done on port 4443 so it also OK. Can uyou check in your reverse proxy if you send the original header ?

    Rgds

    JMF

     
  • Tuesday, May 08, 2012 2:30 PM
     
     
    Sign In to Vote
    0

    pretty sure i am not putting my creds into some random website but thanks for the offer.

    I actrually figured it out before i got back here to view your replies, thank you all for your input.  I believe the issue was the ExposedWebRUri, even though I was sure i had set this before.  Thanks

     
  • Tuesday, May 08, 2012 2:38 PM
     
     
    Sign In to Vote
    0
    that site isnt random, its run by microsoft for testing autodiscover for exchange and lync/ocs.  They do specify you use a test mailbox/user (some exchange tests even fail if the mailbox has any items in it). Its legit and great for testing :)