Issue:User is unable to login Lync 2013 mobile client.
Error: Can't connect to the server. It may be busy or temporarily unavailable. Please try again.
PA:Once you have latest CU updated on your Lync Server 2013 then mobility gets deployed automatically so no need install additional patch or anything else.
Here are the Troubleshooting steps which use as per below steps or your logic and sequence.
1. Use updated Lync 2013 mobility client on your mobile phone.
2. Type Sign-in address and then Password and Click on “Advance options”
Type: Domain\username and then try Login. Still gets error look down.
If you gets error then something with your Server side which you need to look.
3. Lync 2013 mobile client either inside or outside get login through Reverse Proxy server only.
So you have to look on Reverse Proxy first.
4. First you need to look on external DNS record, i.e. lyncdiscover.sipdomain.com
e.g. lyncdiscover.mydomain.com it should point to reverse proxy IP. (TMG or F5) per environment.
5. If you are using TMG or F5 for reverse proxy then you must look the configuration that how it forwarding request FE pool (FE server address).
6. TMG/ F5 must listen on 443 and 80 port and forward the requests to FE server on 4443 and 8080.
7. This is important steps which you need verify that valid certificate is assigned to your reverse proxy or not. (Create client and server profile in F5 (reverse proxy) and assign the public SSL certificate on it. If you have TMG then assign the public certificate to TMG rule).
Test is simple to verify the certificate: browse the external web service (externally) and the see certificate.
E.g. my web service Eweb-ws-ext.mydomain.com
If you are getting above page then open certificate and see the SAN names. Below name you might see on valid certificate (this is all depend on environment to environment).
a. Lyncdiscover.domain.com
b. External web service address
c. Dialin.domain.com
d. Meet.domain.com
e. Accessedge fqdn
f. Webconf fqdn
If certificate does not have valid name then you need to get new certificate with required name.
8. If DNS record is available and pointed correctly to reverse proxy IP address then, browse the this URL from externally
https:\\lyncdiscover.sipdomain.com, you should get file save prompt like below screen.
9. If you open that file, then you will see below data. E.g. my external web service address, Eweb-ws-ext.mydomain.com
{"AccessLocation":"External","Root":{"Links":[{"href":"https:\/\/Eweb-ws-ext.mydomain.com\/Autodiscover\/AutodiscoverService.svc\/root\/domain","token":"Domain"},{"href":"https:\/\/Eweb-ws-ext.mydomain.com\/Autodiscover\/AutodiscoverService.svc\/root\/user","token":"User"}]}}
If still user is not able to login on Lync then do the below troubleshooting. Look like reverse proxy getting resolve however traffic is not reaching to FE server.
10. You can do the test which will let you know that your external request is coming to you Front End Server and show the traffic.
a. First you have to allow external traffic on your external firewall on 443 and 80 Port. Once it allows then you can test.
b. You can capture the traffic in firewall level where you see the traffic is going from your Reverse proxy to FE server on 4443 port.
If capture not showing traffic then you need to look at Reverse proxy configuration.
11. If you are using TMG or F5 for reverse proxy mechanism then you must look the configuration that how it forwarding request to your FE pool (FE server address).
12. TMG/ F5 must listens traffic on 443 and 80 port and forward that traffic to FE server on 4443 and 8080.
If Reverse proxy shows correct configuration then do below test on your FE server.
13. You can try to login on Lync on mobile and then open the IIS log and find the users SIP URI who is logging from mobile device to Lync server. if you are not seeing any Autodiscover request or your test users SIP URI then do the below troubleshooting.
14. See that internal and external site directory. Like below screen.
15. Check UCMA web directory and see the port number, Internal- 443 and 80 and External must have 4443 and 8080.
16. Also you can test the Autodiscover is getting resolve or not internally on FE server.
17. On FE server- https:\\localhost:4443\autodiscover\autodiscover.svc\root
18. You can capture the traffic on your Front End server using “Network Monitor” or Wire Shark etc. where you can see and narrow down the issue.
You use: below filter in network monitor
a. Tcp.dstport==4443
b. Tcp.port==4443
Using above filter you see the handshake.
If these Front Server test works as expected the then you have to look on your Reverse proxy and firewall rules and capture the TCP traffic on 4443 port.
NOTE:this is generic troubleshooting steps which may vary case to case.
Thank you.
