Deploying the Lync Mobility service

Last week, the bits for the Lync mobility service were released, and yesterday the Windows Phone client went live in the marketplace.  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 (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. 

This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to Deploying the Lync Mobility service

  1. Steve Forkin says:

    Hi There – I installed all the Mobility updates today and updated the DNS and certificates and

    get a 401 – when running the – Test-CsMcxP2PIM script (see output below) – also did a logging session on the Front End server whilst running this script and get – an AcquireCredentials error

    Any advice you can give me will be very much appreciated


    TL_ERROR(TF_COMPONENT) [0]1928.1B10::12/16/2011-05:20:21.909.0000027a (S4,Microsoft::Rtc::Internal::Sip::SipAuthenticationHelper::AcquireCredentials:AuthHelper.cpp(132))AcquireCredentialsHandle failed error: -2146893044

    TargetUri :
    TargetFqdn :
    Result : Failure
    Latency : 00:00:00
    Error : ERROR – No response received for Web-Ticket service.
    Inner Exception:The HTTP request is unauthorized with client authe
    ntication scheme ‘Ntlm’. The authentication header received from t
    he server was ‘NTLM’.
    Inner Exception:The remote server returned an error: (401) Unauthorized.

  2. chrisbardon says:

    I had exactly the same problem-reboot the front end server and it should be OK.

  3. uni5comms says:

    I have this problem and rebooting does not help. My lyncdiscoverinternal A record points to my Director server. Both Director and SE Front end have been updated with CU4 and installed with McxStandalone.msi. Is there something else I need to do? Any advice is much appreciated.

  4. İzmir says:

    I got the same problem. I noticed that I entered wrong test user password in the commands. When I corrected it worked

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s