I installed the Lync Mobility server pieces last night.
When I woke up this morning, the Lync 2010 client was available on the Windows Phone Marketplace so I was able to test my previous nights work. To no surprise, the Lync 2010 mobile client could not connect.
The first error I received when trying to connect with the client was a generic “server unavailable” message. I started by running logging on my TMG reverse proxy. To simplify troubleshooting, I turned off WiFi on the phone. In order to determine my phone’s IP address, I used the System Information app (downloadable from here). You could also get the same information by pointing your phone’s browser to something like http://ipchicken.com. So I fired up the app, turned on logging, and tried to connect with the client. I stopped logging and then searched the TMG logs for the phone’s IP address. I couldn’t find it.
Uh…OK. That probably shouldn’t happen. So I did an nslookup for the DNS CNAME entry I added last night (lyncdiscover.company.com). The nslookup failed. That probably shouldn’t happen either. I hopped onto our public DNS server to verify everything was correct. Of course it wasn’t. I severely typo-ed “lyncdiscover”. I corrected the spelling and then had to wait until the change got pushed out to our other public DNS server
Once the change had replicated, I tried connecting. Once again, I had TMG logging the connection. Once I again, I got an error on the client but this time I could at least see some action in the TMG logs. I reviwed the logs and saw that a packet had been blocked by the “[Enterprise] Default rule” rule. I’ve always found it to be a pain to troubleshoot errors that fall under that default rule but today I had luck. I reviewed the settings for my rule and saw that in the “Public Name” tab I had not added “lyncdiscover.company.com” into the list of permitted web sites. (Note that I also followed this tip before I started testing with the client. You may want to review that setting too.)
Once I did this, I got a different error on the client, something I always consider progress. This time, the error basically stated that I had provided incorrect login credentials. On the client login screen I picked the “More Details” option and under the “User name” value I entered in “domainusername”. My SIP address (firstname.lastname@example.org) is not the same as my user name (which is FirstInitialLastName@company.com). Once I added the info to the “User name” field….I got connected! BAM!
But the client sure wasn’t working very well. If I tried sending a n IM I got an error that it couldn’t be delivered. I got intermittent status update settings of my contacts (sometimes the colorful red/green/yellow, sometimes greyed out). In other words – even though I got connected it still wasn’t working.
I remembered seeing in the Microsoft Lync Server 2010 Mobility Guide that Microsoft recommends you use session persistence on your hardware load balancer, specifically cookie session persistence. Well, I checked into that last night and cookie-persistence wasn’t a setting on our HLB so I just carried on and hoped it would still work. So I returned to the HLB and enabled the only persistence it would let me choose which was SourceIP persistence. Once I set this up, everything works fine and continues to work fine with my Lync client.
There you have it – those were the major issues I had to troubleshoot to get Lync Mobility working. I found the 2010 Mobility Guide to be a really good document and I suggest you read it before installing the server piece. I also used this guide at MSunified.net since it did a really good job of boiling down all of the steps in the Mobility Guide to a straightforward checklist. This blog entry also helped me get a grasp on how the client connects and all of the steps the client goes through.