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 10: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 tried going to  http://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"}]}}

if i go to https://lyncdiscover.domain.org/ i get prompted to download the file but it gives me an error that the file cannot be downloaded because the site is unavailable or cannot be found

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.. could it be a DNS issue at this point?






  • Edited by Red Fury 15 hours 10 minutes ago
Free Windows Admin Tool Kit Click here and download it now
August 4th, 2014 12:57pm

Nice! You beat me to it, that was going to be my next suggestion ;) In Lync whenever you make changes to things that effect web services you need to run the setup again. If you have multiple Front End servers you will need to do this on all of them. By running setup you will have created or updated the virtual web directories. You should see the autodiscover one now. Here's what mine looks like:

August 4th, 2014 3:28pm

Regarding you next issue, the autodiscover process appears to be working correctly. Do you get any certificate errors in a web browser when browsing to HTTPS? If you have only tried on a mobile device please compare to desktop/server.

You could have a DNS or firewall issue. Where does your internal and external web services FQDN resolve to? Have a read through the following posts and make sure you have configured accordingly:

Mobility DNS records - http://www.lync.geek.nz/2014/02/lync-mobility-dns-records.html

LyncDiscover URL's - http://www.lync.geek.nz/2014/01/lync-discover-urls-summary.html

Free Windows Admin Tool Kit Click here and download it now
August 4th, 2014 3:41pm

Red,

In the future, as a tip, run "enable-cscomputer" - that, also, should do what the setup does in the wizard.

Also, if you are trying to log into Lync via a mobile device using the Internal IIS site- you  need to ensure that your entire trust CA string is trusted by the device including teh signing CA/intermediate (if applicable).   Internal certs screw mobile clients up so badly that I only use the "autodiscoverinternal FQDN" in my initial testing.  Then, I only use the autodiscover FQDN that has the publically signed cert.   So, be aware that your mobile client will have a hard time connecting internally without you really working to get the certs lined up.  

For android, email yourself the cer files individually ... install them from the mail client.

August 4th, 2014 5:20pm

As far as I understand Enable-CsComputer is not enough in this scenario because things need to be installed.
Free Windows Admin Tool Kit Click here and download it now
August 4th, 2014 5:44pm

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 tried going to  http://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"}]}}

if i go to https://lyncdiscover.domain.org/ i get prompted to download the file but it gives me an error that the file cannot be downloaded because the site is unavailable or cannot be found

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.. could it be a DNS issue at this point?






  • Edited by Red Fury Monday, August 04, 2014 7:43 PM
August 4th, 2014 7:53pm

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 14 hours 56 minutes ago
Free Windows Admin Tool Kit Click here and download it now
August 4th, 2014 7:53pm

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
August 4th, 2014 7:53pm

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 13 hours 55 minutes ago
Free Windows Admin Tool Kit Click here and download it now
August 4th, 2014 7:53pm

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
August 4th, 2014 7:53pm

Ok.. so here the update.  the Lync Autodiscover Web Service Remote Connectivity Test was successful, however i still cant connect with a mobile device internal or externally.      is it because i have to install the cert in the phone before i try?  

Also, i did a lync server remote connectivity and that one does not go through.. it tests to see if port 443 is listening on the edge (access.domina.org)   and succesfully show that the port is listening but then it fails at validating the certificate, which im possitive is good ..  it authenticates fine in autodiscover web service test. 

Again, thanks everyone for the help.


Free Windows Admin Tool Kit Click here and download it now
August 5th, 2014 11:07pm

In both scenarios (internal and external) try browsing to the lyncdiscover URL on the phone and see if you get any certificate errors. For external if that checks out OK and you use the same certificate on the Edge server I think we can rule certificates out. I assume that Windows Lync clients can connect externally to the Edge without issue?

Can you post the error you get back from the remote connectivity test?

For internally connected did you have a read of those blog posts? Have you configured as per those recommendations?

 
August 5th, 2014 11:13pm

Hi Red,

does this fail only for Mobile devices and not desktop client?

does your Lyncdiscover.domain.com point to your External Edge ip?

Is your certificate from godaddy defined in Edge,Lync and your ARR setup?

WHat is SAN name defined in your cert and what is common name of your cert?

Free Windows Admin Tool Kit Click here and download it now
August 5th, 2014 11:38pm

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 6th, 2014 12:04am

You have a few issues going on right now ...  you have SSL errors on your edge.

Also - to sharpen up the above advise - your lyncdiscover.domain.com DNS does NOT point to your edge ... it points to your reverse proxy - and on that reverse proxy is an SSL cert - separate cert from the edge certificate. The requirements for the cert that is on the reverse proxy are explained at the bottom of http://technet.microsoft.com/en-us/library/jj205381.aspx.

Also - the RP SSL CERT lives on the reverse proxy bound to port 443.  The SSL terminates there.  The reverse proxy redirects port 443 (on RP)  -> 4443 on the FRONT end (external web site).  

Here is the concept - The "lyncdiscover" (and the other ext web services) traffic **between the RP and the FE** is encrypted by your internal certs.  Let's say your RP has 2 NICS - the external NIC has the public cert on it - the internal nic has the "internal certs" on it.  k?  Make sure that your RP has the internal CA certs in trusted ROOT .. etc etc.    But, the public SSL terminates on the RP:443.   I hope that makes sense.  

On the FE , the wizard does all this mess for you. (request, assign, etc)  BUT, on the RP - you need to have the SSL cert manually configured and manually entered.  http://technet.microsoft.com/en-us/library/gg429704.aspx

We've all been where you are on this - so - keep working through it - and keep asking questions.  

lync-access.eldercarealliance.org resolves to 72.18.240.222

 

Server Type: Microsoft-IIS/7.5

 

No SSL certificates were found on lync-access.eldercarealliance.org. Make sure that the name resolves to the correct server and that the SSL port (default is 443) is open on your server's firewall.

Free Windows Admin Tool Kit Click here and download it now
August 6th, 2014 9:53am

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 14 hours 21 minutes ago update
August 6th, 2014 11:24am

Sorry if I muddied the water.

Go over to http://www.sslshopper.com/ssl-checker.html#hostname=lync-access.eldercarealliance.org

There is an error on your edge with the SSL.  You need to get your cert bound to the services - using the wizard on the edge servers.  Import the public cert , and assign it .. follow the wizard.  Until you get that SSL issue on the edge worked out - you're goign to have problems.  

Also, on testocs site ... 

Testing TCP port 443 on host lync-access.eldercarealliance.org to ensure it's listening and open.
  The specified port is either blocked, not listening, or not producing the expected response.

So, check your firewall.  Telnet to port 443 on the external IP.  Are you behind a HLB?  ANy ideas?

Free Windows Admin Tool Kit Click here and download it now
August 6th, 2014 5:24pm

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
August 6th, 2014 6: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
Free Windows Admin Tool Kit Click here and download it now
August 12th, 2014 7: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
August 12th, 2014 11: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 19 hours 26 minutes ago
Free Windows Admin Tool Kit Click here and download it now
August 13th, 2014 12:14am

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 13th, 2014 12:14am

What was the resolution?
Free Windows Admin Tool Kit Click here and download it now
August 21st, 2014 4:15am

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 16 hours 38 minutes ago
August 22nd, 2014 2:18pm

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 9:14pm

Glad you got it sorted and cheers for sharing.
August 23rd, 2014 2:00am

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

Other recent topics Other recent topics