lyncdiscover: A Web exception occurred because an HTTP 404

Hello everyone.. So i'm pretty new to lync and I'm trying to deploy in my company.   Currently i have it working internally just fine, however, the external part im having all sorts of issues.    i've followed some troubleshooting steps but i cant seem to be getting anywhere... so i was wondering if anyone could help.  

currently i have a FE server and an Edge server.   When i try the remote connection test i get the following error at the end.

Testing HTTP authentication methods for URL https://lyncdiscover.domain.org/Autodiscover/AutodiscoverService.svc/root/user.

HTTP authentication test failed.

Additional Details
  A Web exception occurred because an HTTP 404 - NotFound response was received from Unknown.HTTP Response Headers:
Content-Length: 1541
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET,ARR/2.5,ASP.NET
Date: Thu, 31 Jul 2014 19:33:03 GMT Elapsed Time: 170 ms.


I tried going to https://lyncdiscover.domain.org   and i get the following error:
server error  in "/" application

The resources canno be found.

description:   http 404. the resource you are looking for  (or one of its dependecies( could have been removed, had its name changed or is temporary unavailable ... etc

Requested URL: /autodiscover/autodiscoverservice.svc/root

my browser is validating he certificate as the https is green.    I dont know if it could be an issue with the RP? or just the site.  I'm using the IISARR as my reverse proxy and followed the steps on hte link below to set it up

http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx

I checked the mobility config adn the exposedwebURL is set to external.    

Thanks in advance for any help! 



  • Edited by Red Fury Thursday, July 31, 2014 7:55 PM
July 31st, 2014 7:54pm

Hi greg, thanks for the input.   I am not able to browse to http://ServerFQDN.domain.corp:8080/Autodiscover/AutodiscoverService.svc/root .. i get the same error.  The interesting thing is that internally the mobility is also not working now after i created a new topology..  Also, i went to the FE server's IIS and i dont see the "autodiscover" site in it.     could that be the issue? 


here's the error for :http://ServerFQDN.domain.corp:8080/Autodiscover/AutodiscoverService.svc/root

The resource cannot be found.

Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable.  Please review the following URL and make sure that it is spelled correctly.



Requested URL: /Autodiscover/AutodiscoverService.svc/root

---------------------------------------------------------------------------------------------------

Update!  I re-published the topology and then ran the setup or remove components wizard and then the MCX and Autodiscover site showed up on the FE IIS..  then tried going to  https://lyncdiscover.domain.org i get a file download with the following message in it:

{"Root":{"Links":[{"href":"https:\/\/fqdn.domain.local\/Autodiscover\/AutodiscoverService.svc\/root?sipuri=","token":"Redirect"}]}}

After that i tried connecting internally and the mobile .. got prompted to install the cert and then the client just kept cycling trying to connect to the server a few times and then it said that the server was not found..  

I went ahead and re-did the server webfarm on the reverse proxy because it was resolving my lyncdiscover site but not the webservice / webticket site ..    instead of creating one webfarm for each site i created just one for all of them called "lync" with all the same setting as shown in the article but with the following in the pattern section: (*) instead of just *

 under conditions pattern i entered:

(webservice.domain.org|lyncdiscover.domain.org|lync.domain.org/meet|lync.domain.org/dialin)

this pattern works for me because i published the dialin and meet as that, i assume that if had done the meet.domain.org i wouldve had to do the pattern differently. 

Aside from that, i also noticed that my IISARR server was not resolving the sites to the DMZ ip's so i added them to the host file. ea:      

192.168.1.10 lyncdiscover.domain.org and 192.168.1.20 webservice.domain.org 

 did a "iisreset" and then tested the webservice website and came back ok with the xml language.      Tried logging in with a mobile device and ding ding ding!!  im in business!!!

Thanks all of you for the help and your time.  greg and andrew specially.

As for the connectivity test issue, my firewall was translating 443 to 4443 to the edge server.. obviously the edge server uses 4443 to replicate to the FE using the internal cert.. I removed the port translation and the connectivity test came back successful with the right public cert.








  • Marked as answer by Red Fury Tuesday, August 19, 2014 10:32 PM
  • Edited by Red Fury Wednesday, August 20, 2014 8:01 PM
  • Unmarked as answer by Red Fury Friday, August 22, 2014 9:00 PM
Free Windows Admin Tool Kit Click here and download it now
August 4th, 2014 4:53pm

Andrew, yes .. i did all the DNS entries as you recommended on your page.   When i browse from the phone to the lyncdiscover i dont get any errors..  when i do it externally, it shows the webservice.domain.org discovery and i connect to our wifi it shows the FE fqdn.

This is what i get from the remote connectivity, i assume that this issue might be related to the edge server. the cert has the lync-access.domain.org as SAN which is the external edge pool

Testing remote connectivity for user eborjas@eldercarealliance.org to the Microsoft Lync server. it almost look like the cert is not binded to port 443.. I assume that it should be binded to 4443, but im not sure how to bind the cert to the port without IIS in the edge server.
  Specified remote connectivity test(s) to Microsoft Lync server failed. See details below for specific failure reasons.
 
Additional Details
  Elapsed Time: 6253 ms.
 
Test Steps
 
Attempting to resolve the host name lync-access.domain.org in DNS.
  The host name resolved successfully.
 
Additional Details
  IP addresses returned: 72.18.240.222 Elapsed Time: 200 ms.
Testing TCP port 443 on host lync-access.domain.org to ensure it's listening and open.
  The port was opened successfully.
 
Additional Details
  Elapsed Time: 168 ms.
Testing the SSL certificate to make sure it's valid.
  The SSL certificate failed one or more certificate validation checks.
 
Additional Details
  Elapsed Time: 5575 ms.
 
Test Steps
 
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server lync-access.eldercarealliance.org on port 443.
  The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate.
 
Additional Details
  The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.

Elapsed Time: 5532 ms.



  • Edited by Red Fury Tuesday, August 05, 2014 9:05 PM
August 5th, 2014 9:04pm

Greg, thank you for the reply. I'm not having issues with the RP..  Currently i do have the lyncdiscover pointing to the reverse proxy.. I am not having issues with the lyncdiscover at the moment..  currently PC's area able to login remotely without any issues, only Phone are the ones not bieing able to connect.      I do have a SAN cert on the reverse proxy with all the requirements listed on the kb u referenced to.  I am using that same public cert on the edge server.. you are saying that i should use a different one? 

The lync-access.elder.org contains the following SANs:

lync-access.domain.org

lyncdiscover.domain.org

lync.domain.com    ( im using the meet and dialin as "lync.domain.org/meet, lync.domain.org/dialin" ) to save $ on the cert and keep it at 5 SANs)

The issue that i'm having is with the edge server, Should i create a farm to point point that to the edge server in the RP?

the xx.18.240.222 address points to the edge server with the pool name lync-access.domain.org ..  the lyncdiscover, lync.domain and webservice all point to the reverse proxy which is a different IP .. 50.xx.xx.xx.  

This is what i get when i run the "get-csservice -webserver | fl autodiscover*


AutodiscoverServiceExternalUri : https://webservice.domain.org/Autod
                                 iscover/AutodiscoverService.svc/root
AutodiscoverServiceInternalUri : https://fefdn/Autodiscover/Autodisc
                                 overService.svc/root

Those are the correct sites.

Thanks for your help!!



  • Edited by Red Fury Wednesday, August 06, 2014 8:31 PM update
Free Windows Admin Tool Kit Click here and download it now
August 6th, 2014 3:21pm

Hello greg..  So, i did the check and the port is listening..  but i'm not sure why it keeps picking up the internal edge cert instead of the public cert. i have my firewall translating 443 to 4443 for the edge server.. and  I have a IISARR doing reverse proxy for the FE server ..  I'm assuming at this point could be a routing issue ..  Do you know if there is a way to check to which port the certs are binded to without IIS ?    I did a netsh http show sslcert and it got me the internal cert binded to 4443


SSL Certificate bindings:
-------------------------

    IP:port                 : 0.0.0.0:4443
    Certificate Hash        : xxxxxxxxxxxxxxxxxxxxdf948e6078a0338a74
    Application ID          : {00000000-0000-0000-0000-000000000000}
    Certificate Store Name  : (null)
    Verify Client Certificate Revocation    : Disabled
    Verify Revocation Using Cached Client Certificate Only    : Disabled
    Usage Check    : Disabled
    Revocation Freshness Time : 0
    URL Retrieval Timeout   : 0
    Ctl Identifier          : (null)
    Ctl Store Name          : (null)
    DS Mapper Usage    : Disabled
    Negotiate Client Certificate    : Enabled

  • Edited by Red Fury Tuesday, August 12, 2014 5:43 PM
August 12th, 2014 4:52pm

PAul, when i ping lync-access.doamin.org from the reverse proxy server it does resolve to the internal IP ..  i'm pretty sure i have a the external interface on the DMZ with the gateway and the internal interface without a gateway..  

So, you are saying that i should take a 2nd look at the DMZ and make sure that is segregated from the internal network?    in my internal DNS, should lync-access(sip.domain.org)  be resolving the the DMZ ip or to the public IP? 


  • Edited by Red Fury Tuesday, August 12, 2014 9:09 PM
Free Windows Admin Tool Kit Click here and download it now
August 12th, 2014 8:54pm

I went ahead and disabled one interface at the time.. i ping lync-access .. when the external was disabled it came back with unable to find the host ... when i disabled the internal and enabled the external i was able to resolve to the external public IP..  is that what i should be getting?
  • Edited by Red Fury Wednesday, August 13, 2014 3:28 PM
August 12th, 2014 9:14pm

Andrew, to summarize, i basically uninstalled the mobility from the server.. placed a new mobility msi file in the lync setup folder within the program data path.. re-ran the setup or remove server components from the deployment wizard and that re-installed the MCX and Autodiscover sites within IIS in the FE.     that solved the first issue that was getting me the 404 error within the lyncdiscover.domain.org page. 

problem #2 -  After that the issue was with the webticket or webservice.. the reverse proxy wasnt forwarding through correctly the webticket.   I ended up re-doing the reverse proxy farm with the following settings:

"instead of creating one webfarm for each site i created just one for all of them called "lync" with all the same setting as shown in the article but with the following in the pattern section: (*) instead of just *

 under conditions pattern i entered:

(webservice.domain.org|lyncdiscover.domain.org|lync.domain.org/meet|lync.domain.org/dialin)

tested by going to the webservice url:  https://webservice.domain.org/WebTicket/WebTicketService.svc/mex.  I did this test internal and external and got the xml language page which confirmed the webticket as being good.. right after that test was successful i was able to get a mobile device and connected without issues internally and externally

problem #3 - Remote connectivity issue - I had my firewall translating port 443 to 4443 on the edge server which is why it was pulling the internal instead of the external one.   Once i remove the port translation the remote connectivity test came back successful. 

  • Marked as answer by Red Fury Friday, August 22, 2014 6:17 PM
Free Windows Admin Tool Kit Click here and download it now
August 22nd, 2014 6:14pm

im having this same issues.

clients from the outside cannot logon with the mobile app.

from the inside i can browse to the FE server with no issue and get the file like mentioned above. 

from the ms lync autodiscover tester EVERYTHING is ok except the http authentication, i get this error 

Testing HTTP authentication methods for URL https://lyncdiscover.EXTERNAL.com/Autodiscover/AutodiscoverService.svc/root/user.
  HTTP authentication test failed.
 
Additional Details
 
A Web exception occurred because an HTTP 404 - NotFound response was received from Unknown.
HTTP Response Headers:
X-MS-Server-Fqdn: lyncedge.INTERNAL.com
Connection: close
Content-Length: 64
Content-Type: text/plain
Server: RTC/5.0
Elapsed Time: 272 ms.

currently the lync.EXTERNAL.com is natted to the 2013 Edge server, ports 443 and 80.

any thoughts?

  • Edited by OldSchoola Wednesday, June 03, 2015 8:53 PM
June 3rd, 2015 8:53pm

not sure what you mean.

1. do i need a reverseproxy server? or can i just use the edge for mobility?

currently i dont have an RP. the lyncdiscover.external.com is natted to an ip on my lync edge box(which i have configured for sip.external.com, webconf.external.com, av.external.com also natted to on 3 diff ips on that edge box)

2. do you know of a diagram or list of requirements and ports for this to work? i.e. 1 rp, 1edge

3. what kind of certificate needs to be configured on the internal FE server? i currently have an internally issued cert assigned as the default cert for
Server
web services internal
web services external 

note that our domain names are internal.com for inside and external.com for outside.

  • Edited by OldSchoola Thursday, June 04, 2015 12:20 PM
Free Windows Admin Tool Kit Click here and download it now
June 4th, 2015 12:16pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics