Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I recently have been trying to set up SSL in SharePoint 2013. It has been working just fine using a wildcard cert, host headers, and binding to All Unassigned. However, I now have a need for another cert in the mix, so I can't have two different certs on All Unassigned and need to instead bind to IP Addresses.

The trouble is that every SharePoint web app generates a 404 if it's IIS site is assigned to an IP address. Works fine All Unassigned, always 404 when on an IP.

I tested creating a plain IIS site without SharePoint. Works fine in all cases, no 404 for either All Unassigned and binding to an IP.

I tested shutting down a SharePoint IIS and using it's host name on the plain IIS site, so I know it's not a DNS issue... the host name works just fine and routes properly to the proper IIS site, "All Unassigned" or bound to an IP address.

I tested this all without SSL as well. SSL isn't the culprit either. The same exact behavior happens to just the SharePoint sites configured for regular HTTP. Works All Unassigned, always 404s when bound to an IP address.

When the 404 happens, the SharePoint ULS logs show:

Reached maximum number of failed machines based on ping results for this routing group
Mapping URI https://myhostname to https://myserversname

Since the ULS logs show "anything", I know the request is making it through IIS and into SharePoint, thus this must be a SharePoint issue.

I'm stumped. Haven't found any mention of this issue anywhere after spending hours hitting search engines, trying here, Stack Overflow, etc. I even tried reproducing this in one of my development SharePoint 2013 virtual machines, but everything worked as exptected. No 404s when messing with IP Address bindings. I just recently did this same thing to a clients SharePoint 2010 server, and again, everything worked just as expected. All IP address bound IIS sites fully accessible. It only seems to be this one particular SharePoint 2013 installation on this one particular server.

Hoping someone has some insight into the issue. I have yet to find any documented case of this happening. I've been messing with the hostnames in DNS, IIS bindings on this server, IIS bindings on other servers, creating test sites using the same hostnames and IP bindings, etc. for days now, and in every case the issue does not happen on any other server but this one specific installation of SharePoint.

Thanks.

share|improve this question
    
In Server 2012 you can use multiple certs against the same IP address, this works for most Browsers except for IE on XP. It may be worth looking into. –  Peter Hahndorf Feb 10 '13 at 17:01
    
Even if I could use multiple certs against the same IP, it still doesn't solve my problem. HTTPS can be taken completely out of the equation yet the problem still exists. If I bind any of those SharePoint sites to an IP address instead of "All Unassigned" in IIS, HTTP or HTTPS doesn't matter, the sites generate nothing but 404s. They are only working with "All Unassigned". But a regular non-SharePoint IIS site on that same server does work fine with an IP Address assignment. –  DiggyJohn Feb 11 '13 at 0:08
add comment

1 Answer

up vote 0 down vote accepted

Well I got around the issue. Disabling the Request Management service in Central Admin allowed everything to work as expected. I can now bind any of my sites to their own IP addresses just fine without 404s.

I guess while this answer does solve my immediate issue, it doesn't answer what's wrong with the Request Management service that was causing this. Or simply I just don't understand what the Request Management service is actually for, and it never should have been turned on in the first place. And sure enough, the Request Management service is also off on my other SharePoint 2013 environments were everything was working as expected.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.