locked
Anyone have an idea on when Lync Mobility and UAG will be supported? RRS feed

  • Question

  • Just wondering if any Microsoft guys monitoring this forum has an ETA on when UAG will support Lync Mobility?

    I've read where a few people have decoupled the IP from UAG and got the internal TMG to do it, but it looks real messy and I would like to stay supported :-)

    Thursday, May 24, 2012 4:32 AM

Answers

All replies

  • This may help?

    http://adfordummiez.com/?p=326

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Thursday, May 24, 2012 11:40 PM
  • This also looks similar to my unsupported approach for OCS: http://blog.msedge.org.uk/2010/10/publishing-ocs-2007-r2-web-components.html

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Thursday, May 24, 2012 11:43 PM
  • This may help?

    http://adfordummiez.com/?p=326

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    I am wearing a happy face right now :-)

    Being a newbie to UAG, is all I have to do for that secondary public IP address, add that to my WAN nic's binding or is there something special through the UAG console I need to do?

    • Marked as answer by Tankster Saturday, May 26, 2012 6:34 AM
    Friday, May 25, 2012 7:47 PM
  • Hopefully last question, when originally created my Lync Trunk for HTTPS, my public host name in creating the trunk is portal.domain.com and is in my SAN certificate.

    When I create the new HTTP trunk for Lyncdiscover, do I still use the portal.domain.com to create the trunk or do I need to come up with yet another name? If I use Lyncdiscover.domain.com as my trunks public hostname and then when I'm creating the application also use lyncdiscover.domain.com, it complains about AAM not allowing the public trunk hostname be the same as the application hostname.

    If I do still use the portal.domain.com as my Trunk hostname, what do I need to do in regards to DNS on the public side besides change the record for lyncdiscover.domain.com ?

    Thank you so much for you help thus far.

    Friday, May 25, 2012 8:19 PM
  • OK, I filled in some blanks and went on a couple of assumptions just to try and from the outside, it appears to work now. I have not tried it on the inside of my network, so we'll see on that one.

    Thank you so much.

    Saturday, May 26, 2012 6:34 AM
  • Just an update, doing a HTTP trunk was leaving me feel a little uneasy, so I began playing with those same settings over a HTTPS trunk. This failed, but when I changed the application port from 4443 back to 8080 like it was in the HTTP trunk, things came up just fine. All ocsconnectivity.com tests come back OK, and life looks good.

    Am I safe to assume that I am secured from the Internet side over 443 with the application talking back to the mobility end via 8080 ?

    Saturday, May 26, 2012 8:25 PM
  • We got UAG and Lync to work together.

    See here for more info: http://adfordummiez.com/?p=326

    Tuesday, May 29, 2012 9:00 PM
  • He has since updated his post to that of a HTTPS trunk instead of the HTTP trunk he had originally. My question to him now is about looping back thru as the Mobility service document references making the lyncdiscover.domain.com in your internal DNS point to the public IP address of the reverse proxy; otherwise in my case, the iPad will complain about certificates since my inside certificate is from my own Ent root CA.
    Tuesday, May 29, 2012 10:49 PM
  • Nevermind, the article he provided in his response to me outlined that the client will try the lyncdiscoverinternal host record first and if it does not find it, will try the lyncdiscover host record last. I thought it just tried the external host record only, so I'm good.
    Wednesday, May 30, 2012 1:07 AM