15 May 2012
Deploying the Lync Mobility Service
With bits for the Lync mobility service and the Windows Phone client released. The official documentation that comes along with the download is pretty good in this case, and there are already some other blog posts that cover the deployment in detail, which is great to see. While it would have been nice to not have to need an extra server component, it does make sense that you’d need to abstract the SIP stack away from the client, and the way that piece works makes sense. What I don’t understand though is the need for yet another autodiscover service.
For the mobility clients to work, they’ll try to access lyncdiscover.domain.com (or lyncdiscoverinternal from inside your network), which is a new service that returns the location of the Lync server mobility service. Now, why that address couldn’t be inferred from the existing DNS SRV records, I’m not quite sure yet, but the bottom line is that this new service requires new reverse proxy rules and certificate changes. Fortunately, there’s a way to set things up that doesn’t require any changes to the public certificates on the reverse proxy, but it still seems like more work could have been done to make the deployment more streamlined. Of course, given this new service, it’s quite possible that the next release of Lync will do away with the SRV records completely, and just use the discovery service, which seems to resemble the one in Exchange, for everything. Either way, getting mobile clients up and running isn’t really a trivial change.
As for the deployment itself, most of the documentation is relatively clear on how things work. What isn’t explicit is whether or not you need to restart any of the Lync servers at any point (other than to install CU4), however I did notice that after getting to the verification step (running Test-CsMcxP2PIM) on Friday, I was getting authentication failures. I rebooted the front end over the weekend though, and on Monday, the same test worked, so perhaps a restart of the service is required after all. Also, it’s worth noting that you can’t run Test-CsMcxP2PIM using the same account for the sender and receiver (as Ken Lasko and I figured out while we were both trying to deploy the service). Of course, with anything edge related, the hardest piece to get right is all of the firewall and NAT rules that exist between the internal and external networks, and making sure that traffic is allowed where it needs to be. Internal users now need to be able to resolve (and connect to) the external web services address, and if you’re bypassing certificate changes on the reverse proxy, port 80 might have to be opened and allowed through the DMZ on the IP that lyncdiscover is listening on. I piggybacked on the same IP that all the other external web services were listening on, and it also looks like using the exchange autodiscover IP will be a convenient way to get things working quickly.
