Sign-in troubleshooting
=====================
DNS query order
1.lyncdiscoverinternal.<domain> A (host) record for the Autodiscover service on the internal Web services
2.lyncdiscover.<domain> A (host) record for the Autodiscover service on the external Web services
3._sipinternaltls._tcp.<domain> SRV (service locator) record for internal TLS connections
4._sipinternal._tcp.<domain> SRV (service locator) record for internal TCP connections (performed only if TCP is allowed)
5._sip._tls.<domain> SRV (service locator) record for external TLS connections
6.sipinternal.<domain> A (host) record for the Front End pool or Director, resolvable only on the internal network
7.sip.<domain> A (host) record for the Front End pool or Director on the internal network, or the Access Edge service when the client is external
8.sipexternal.<domain> A (host) record for the Access Edge service when the client is external
check if there is manual sign-in config
dial in page
nslookup for autodiscover and SRV, srv will give the edge server name, ping the edge ypu will get the IP, telnet the IP on 443
Endpoint configuration Cache
Client sing-in logs - new feature with Lync 2013 client
uccapi logs (look at the Trace tab) search for 443
Finally look at the services on the edge server
or you can use neststat -ano | find "443" the last column will show the PID you can match the PID in the task manager to locate the .exe running for 443
Edge server will not challenge for Kerberos authentication for external users because Kerberos is used internally only to obtain a Kerberos token
One the client signs in successfully then the inband provisioning takes palace (i.e. client sends out a SERVICE request) via which the client knows about
Contact List
Voicemail URI
associated Dial Plan
You would be able to see the Dial Plan send to the user, In snooper look at the response for the SERVICE request sent
Note - client at frequent interval keeps asking for the SERVICE request to apply any changes that has been made in the Lync environment like dial plan, normalization rules, etc.
Normalization rules takes precedence in the top to bottom order (top = most effective, down = less effective)
If I have got a PSTN number that the Lync users need to dial out to can that PSTN No. be in the vacant No. Range ? NO
If I have a Lync user configured with Line URI can that No. be in the vacent No. Range ? Yes, because reverse number lookup is performed on inbound calls before vacant No. range is checked
======================================================
keep in mind when comparing logs and troubleshooting:
server logs are in GMT
client logs are in local machine's time
======================================================
No comments:
Post a Comment