Answered by:
Lync 2010 Client - Can't Connect Externally

Question
-
I am unable to connect my Lync 2010 client from an external non-domain PC. Internal, in the domain works fine.
When I try to connect with auto-config, I get the error "There was a problem verifying the certificate from the server.". A look at the System Log shows that the client is looking for sipinternal.consoltechlab.com as well as sipexternal.consoltechlab.com on the certificate.
When I try to connect with a manual config, setting my external server name/IP address to access.consoltechlab.com, I get the error "Cannot sign in because the server is temporarily available". I have also tried access.consoltechlab.com:443.
Some additional details:
- I have a public SRV record in place for _sip._tls.consoltechlab.com, that points to access.consoltechlab.com.
- There is an "A" record in place for access.consoltechlab.com. It is the IP address of of the external interface of my Edge server.
- My Edge server's external interface is direct on the internet, with no firewall. Just the Windows Firewall, which has the necessary ports open.
- I have exported the root CA cert of my domain as well as the front end server's cert to my home PC.
Any help would be most appreciated. Thanks.Thursday, May 30, 2013 2:06 AM
Answers
-
Hi
So you have three public IPs for three external edge services?
What about the certificate for edge internal interface?
I suggest you install root CA and test the issue on another client machine to test the issue.
Please double check the FQDNs for three edge services to make sure you didn't mistype the character of FQDNs.
Please also refer to Certificate section in the Jeff's blog:
http://blog.schertz.name/2012/07/lync-edge-server-best-practices/
Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.
Kent Huang
TechNet Community Support- Marked as answer by Kent-Huang Tuesday, June 4, 2013 1:42 AM
Friday, May 31, 2013 2:06 AM
All replies
-
Hi,
Do you have a public certificate assigned on edge server external interface ? Is it a internal CA certificate ?
Thanks
Saleesh
If answer is helpful, please hit the green arrow on the left, or mark as answer.
Thursday, May 30, 2013 4:40 AM -
Yes, I have a cert on the Edge external interface, and yes it was issued by an internal CA. The subject name is access.consoltechlab.com. It has SANs of: sip.consoltechlab.com access.consoltechlab.com webconferencing.consoltechlab.com The SIP and ACCESS names both have public DNS records that resolve to the Edge's external NIC. The WEBCONFERENCING name resolves to a secondary IP address on that same NIC.
- Edited by Romual Piecyk Thursday, May 30, 2013 12:32 PM
Thursday, May 30, 2013 12:30 PM -
Hi
Can you check using https://www.testocsconnectivity.com
check if you have any issues.
Whenever you see a helpful reply, click on Vote As Helpful & click on Mark As Answer if a post answers your question.
Thursday, May 30, 2013 12:43 PM -
For the LYNC SERVER REMOTE CONECTIVITY TEST, I have green lights on everything, except the last item - the section labeled "Testing remote connectivity for user rpiecyk@consoltechlab.com to the Microsoft Lync server."
The message is:
Couldn't sign in. Error: Error Message: The certificate chain was issued by an authority that is not trusted. Error Type: TlsFailureException.
Thursday, May 30, 2013 1:54 PM -
Hi
Did you installed the Root Chain CA on Edge server?
Whenever you see a helpful reply, click on Vote As Helpful & click on Mark As Answer if a post answers your question.
Thursday, May 30, 2013 1:59 PM -
Yes, it is installed, to the TRUSTED ROOT CERTIFICATION AUTHORITIES store.Thursday, May 30, 2013 3:23 PM
-
Hi
So you have three public IPs for three external edge services?
What about the certificate for edge internal interface?
I suggest you install root CA and test the issue on another client machine to test the issue.
Please double check the FQDNs for three edge services to make sure you didn't mistype the character of FQDNs.
Please also refer to Certificate section in the Jeff's blog:
http://blog.schertz.name/2012/07/lync-edge-server-best-practices/
Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.
Kent Huang
TechNet Community Support- Marked as answer by Kent-Huang Tuesday, June 4, 2013 1:42 AM
Friday, May 31, 2013 2:06 AM -
This is because your non-domain client does not have a copy of your internal root CA certificate.
Using a 3rd party public certificate provider would negate this issue.
As you are using an internal CA on your Edge external interface, but your client is not on the domain, you will need to import the root CA onto the client machines Trusted Root store. (This would happen automatically if the client was domain based).
Regards
Ben- Edited by Ben Donaldson Wednesday, June 5, 2013 2:04 PM Typotastic
- Proposed as answer by Ben Donaldson Wednesday, June 5, 2013 2:04 PM
Wednesday, June 5, 2013 1:42 PM -
Yes, I have 3 public IPs for the three external services, which I have named access, webconferencing, and avconferencing.consoltechlab.com. All have public DNS records.
The certs on the Edge server were both generated by my internal domain CA. The internal is called edgepool.consoltechlab.com (server name is lab-lyncedge.consoltechlab.com), and has no SANs. The external is called access.consoltechlab.com, and has the SAN's sip, access, and webconferencing. My Lync topology has access.consoltechlab.com as the FQDN of external web services.
I have installed the root CA from my internal domain on my test PCs.
I am able to VPN in to my network, manually configure my client to point to the internal FQDN of my pool, which is FEPOOL.CONSOLTECHLAB.COM, and it connects fine. Auto-config however does not. It will yield back the error "There was a problem verifying the certificate from the server." Then a peak in the event logs show Errors 4 (application log) and 36884 (system log), which indicate the client PC was expecting to see sipexternal.consoltechlab.com and/or sipinternal.consoltechlab.com in the certificate.
Why is my client looking for sipexternal and sipinternal? Are these default names that the Lync client looks for when it can't find the name specified in the SRV record? My internal SRV record is _sipinternaltls._tcp.consoltechlab.com, and it points to port 5061 of sip.consoltechlab.com, which is an additional "A" record that points to the IP address of my front end pool (and the single server that is in that pool at the moment, lab-lyncfe.consoltechlab.com).
When I'm outside the network, with no VPN connection established, and set my client to auto-config, I get the same certificate error and event logs. If I set the client to manual and put in the address access.consoltechlab.com, I get the error "Cannot sign in because the server is temporarily unavailable. If the problem continues, please contact your support team." There is indeed a public DNS address for access.consoltechlab.com.
Monday, June 10, 2013 10:29 PM -
Hey Ben, I have indeed imported the root CA cert into the personal store of my testing PCs. it does work via VPN, when I manually config the connection. Auto-config does not work via VPN or not, and neither does manual without VPN (see my previous response above).
Any ideas, anyone? I'm getting desperate.
Monday, June 10, 2013 10:32 PM -
Figured it out. Wasn't able to resolve the front end pool name from from the Edge server. I had added the front end pool's server name to the Edge server's HOSTS file, but not the pool name. Once I did so, external connectivity was established, and all green lights in the Test Connectivity site.Monday, June 17, 2013 3:01 PM