Newly added IP addresses not selectable for IIS bindings

iis-6iis-7windows-server-2008

A colleague of mine added several IP addresses to a server, but these IPs are not appearing in the list to use with bindings.

This goes for IIS7 web sites and IIS6 FTP sites.

We found this KB article, but I don't have the offending patch installed: http://support.microsoft.com/kb/2551090/en-us

I don't think the server was restarted after the IPs were added as it is a live production server, but I believe IIS (at least from IIS6) was restarted.

What must we do to be able to use these IPs? They are pingable.

UPDATE 1:
I am able to RDP to the new IP addresses without issues.

UPDATE 2:
I was able to make them appear by adding them to the hosts file, but I'd still like to know what the issue is?

Best Answer

Let's come back to old time though this is old post. I recently came a cross this issue and I open services.msc, and then restart IP Helper, and all IP newly added comes up.

Related Solutions

IIS7 theoretical limits

According to David Wang on the Microsoft IIS team, there are no limits to the number of websites supported by IIS (see post here) other than hardware limitations. Although that answer related to IIS6, I have to assume it is the same for IIS7.

IIS6 vs. IIS7 and IIS7.5: handling URLs with plus sign (+) in base (not querystring)

After searching for more combinations of IIS and plus, it appears that IIS7[.5] is set up to reject URLs with a plus sign by default out of some fear of the use of that character; that symbol is still allowed in the querystring, though. The solution is to alter the requestFiltering attribute default on <system><webServer><security><requestFiltering> to allow doubly-encoded characters with a command line call (ultimately modifying your ASP.NET web.config):

%windir%\system32\inetsrv\appcmd set config "Default Web Site" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true

This may be a bit more dangerous than one prefers to be with their web site, but there didn't appear to be a way to be more specific than a blanket allow. The warnings were regarding the mismatching that could occur between using a plus in a URL and its typical translation as a space. It looks like the only other alternative is to stop using plus characters in your URLs at all.

Best Answer

Related Solutions

IIS7 theoretical limits

IIS6 vs. IIS7 and IIS7.5: handling URLs with plus sign (+) in base (not querystring)

Related Topic