We are having an issue with Lync MX externally.

Lync MX Internally(domain joined) is working fine so is Mobility (external Only-internal not required), Lync 2010/2013 clients are working fine internally and externally.

It is a small deployment 2x FE and 1 x Edge.

When we try logging on from Lync MX externally we get the spinning that never ends. By enabling logging we get :

Direction: outgoing;source="local"Peer: edge.pool.Mydomain.com:57398Message-Type: responseStart-Line: SIP/2.0 401 Unauthorized

Looking further into the logs like the external access edge send the SIP/2.0 401 Unauthorized

We are using public certificates on the FE. And  Certificate Revocation List (CRL) Distribution Point (CDP) for the certificates issued to Lync server points to an HTTP resource instead of an LDAP resource as per :

http://technet.microsoft.com/en-us/library/jj823129.aspx

All servers are on CU7.

Please let me know of any suggestions you may have in further troubleshooting this issue. I believed I have covered all troubleshooting steps available, but might of missed some.

Thanks a lot in advance.

$$begin_record

Trace-Correlation-Id: 4102754091

Instance-Id: 0037822A

Direction: outgoing;source="local"

Peer: edgeFQDN.MyDomain.com:57398

Message-Type: response

Start-Line: SIP/2.0 401 Unauthorized

From: <sip:user@domain.com>;tag=b30bd1e0cf;epid=9a2fefef5c

To: <sip: user@domain.com >;tag=C1DDC329DEAF0304014EBB25D437EA2B

CSeq: 1 REGISTER

Call-ID: 11172a5257a14d85a0c7fd2adf6ed9cd

Date: Tue, 18 Dec 2012 11:52:55 GMT (This timezone is a bit confusing, client and server are in EST -5)

WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="MyFrontEnd.domain.local", version=4

WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname=" MyFrontEnd.domain.local ", version=4, sts-uri="https://ExternalWebServicesFQDN:443/CertProv/CertProvisioningService.svc"

Via: SIP/2.0/TLS 192.x.x.x (internal Edge IP):57398;branch=z9hG4bK3B762A20.E711664720C9EC67;branched=FALSE;ms-received-port=57398;ms-received-cid=608E00

Via: SIP/2.0/TLS 10.x.x.x (Lync MX Client):59982;received=63.131.143.173;ms-received-port=3061;ms-received-cid=866600

Server: RTC/4.0

Content-Length: 0

Message-Body:

$$end_record

Hi,

Is it Lync Server 2010? The Lync MX client requires the LyncDiscover (and LyncDiscoverInternal) DNS records to locate the autodiscover web service, which provides the proper registrar FQDN to the client. Have you tested if your Lync mobility works externally?

Please make sure you have correct DNS CNAME or A record for Lync discover. Please also check if the required the SAN has been included in reverse proxy certificate.

For details:

http://technet.microsoft.com/en-us/library/hh690030.aspx

Hi..

Use the bellow site and let know the output.

expand the test result to see the detail view.

https://www.testexchangeconnectivity.com

BR

Shahan

Hi Shahan,

Thanks for the reply.

Please see below.

 

	Testing connectivity to the Lync Autodiscover Web Service server for a secure connection on port 443 to obtain the root token.
	Connectivity to the Lync Autodiscover Web Service test successful.
	Test Steps Attempting to test Autodiscover Web Service URL https://lyncdiscover.mydomain.com/Autodiscover/AutodiscoverService.svc/root. Autodiscover Web Service URL successfully tested. Test Steps Attempting to resolve the host name lyncdiscover.mydomain.com in DNS. The host name resolved successfully. Additional Details IP addresses returned: 64.27.x.x Testing TCP port 443 on host lyncdiscover.mydomain.com to ensure it's listening and open. The port was opened successfully. Testing the SSL certificate to make sure it's valid. The certificate passed all validation requirements. Test Steps ExRCA is attempting to obtain the SSL certificate from remote server lyncdiscover.mydomain.com on port 443. ExRCA successfully obtained the remote SSL certificate. Additional Details Remote Certificate Subject: CN=MyFrontEndPoolFQDN, OU="MyCompany, Inc.", O="MyCompany, Inc.", L=Jersey City, S=New Jersey, C=US, SERIALNUMBER=xxxxxxxxxxx, Issuer: CN=GeoTrust SSL CA, O="GeoTrust, Inc.", C=US. Validating the certificate name. The certificate name was validated successfully. Additional Details Host name lyncdiscover.mydomain.com was found in the Certificate Subject Alternative Name entry. Testing the certificate date to confirm the certificate is valid. Date validation passed. The certificate hasn't expired. Additional Details The certificate is valid. NotBefore = 4/30/2012 10:20:46 PM, NotAfter = 3/2/2013 3:19:52 AM Testing HTTP authentication methods for URL https://lyncdiscover.mydomain.com/Autodiscover/AutodiscoverService.svc/root/user. HTTP authentication methods successful. Additional Details Web Ticket URL found as expected and confirmed anonymous access isn't allowed. Testing HTTP content for URL https://lyncdiscover.mydomain.com/Autodiscover/AutodiscoverService.svc/root/domain has McxService.svc. Http Content is verified Additional Details Found as expected McxService.svc and confirmed anonymous access not allowed. Kind Regards: Galya

 

Hi Kent,

Yes it is Lync 2010, and yes Mobility is working externally.All DNS entries are present, we have no other issues internally or externally.

We dont have a reverse proxy we use port translation.

Regards:

Galya

Hi Galya,

You have said, external mobility is working. but the tread says not working.

I am reading this correct..! let know..!

Hi Shahan

I am not sure where you are seeing this, but yes I can confirm mobility is working fine , which is clear from the results of  the conectivyty analyser.

Galya

Sorry abt it, my mistake ..was looking at the wrong place..!

 

Hi,

Configure HTTP proxies in the enterprise to allow Lync server related HTTP traffic.  Add exceptions for the Autodiscover, Lync Web App, and WebTicket services, if necessary.

It is recommanded to use a reverse proxy instead of directing port translation.

Have you tried to check the clock or time zone in client computer? Please refer the post lync15 said.

http://social.technet.microsoft.com/Forums/en-US/ocsclients/thread/ea4461a2-237d-4d3a-b28b-a9d3efbd35b8

 

Hi Kent,

I have seen the post you have mentioned and already explored every single suggestion on it.

Reaching is not an issue, as you can see from the very first logs it is reaching the FE and the correct urls, but for some reason the Edge is rejecting the connection from the FE.

Although the Windows Store Lync App client leverages the Lync autodiscovery DNS record and service to sign-in, it does not leverage the Lync mobility service for authentication or sign-in it uses the Lync server registrar services. This is the Lync Edge server if you are connecting remotely.

I know it is recommended to use RP , but it is not compulsory and we have managed to get everything working so far except Lync MX.

And finally, yes I have checked, and triple checked the time sync on both ends server and client.

Another good troubleshooting article I have gone through as well as all the link on it is:

http://blog.insidelync.com/2012/11/basic-tips-for-the-windows-store-lync-app/

Thanks for all the suggestions and I open for more .

Regards:

Galya

We are having the EXACT same issue with the EXACT same error logs and followed everything that was suggested in this thread.... so BUMP...

Did you ever get anywhere on this? I'm seeing the same problem with the edge sending 401 Unauthorized. My problem is with desktop clients as mobile clients seem to work fine.

I'm also running Lync 2013 and not 2010

Hi, any news on this issue ?

BR

Daniel

This is a bit late, but what fixed it for us was going through the setting of our HLB with the manufacturer. Turns out cookie persistence was not "sticky" enough. We have a Kemp LoadMaster and apparently there is a global checkbox that forces the Kemp to check persistence at each transaction. That forced the mobile clients to stick to the same FE and stabilized our mobile environment. Doesn't change the fact that Lync 2010 Mobile is worthless, but off to 2013 I guess.

Later dudes.

• Proposed as answer by Richard Brynteson (dawho9)MVP Thursday, October 03, 2013 12:25 AM

Again a little late but hoping this helps someone.  We had the same issue with SIP/2.0 401 Unauthorized error.... turned out it was a dodgy patch http://support.microsoft.com/kb/931125

To resolve we went to our Lync servers and checked Trusted Root Cert Authorities and there were over 350!  We removed a whole bunch and just left the common ones there like Verisign, etc and then Lync MX instantly started working!

Was surprised at the resolution but had been pulling my hair out for a few days so glad it is fixed!