Share via

A Not So Common Root Cause for 503 Service Unavailable


So a co-worker of mine was setting up IIS 7.0 on a new Windows 7 machine, and when they were browsing to https://localhost they were getting a 503 Service Unavailable error as shown here:

503 Service Unavailable


This seemed pretty trivial so I went through the following checklist.

  1. Is W3SVC started?      Yes

  2. Is the Default Web Site started?   Yes

  3. Is the Application Pool Disabled?  No

  4. Is the Application Pool Started?   Yes

  5. Is the w3wp.exe process for the application running?  No

  6. Are their any WAS or W3SVC Events in the Application or System Event logs?  No

  7. Are their any entries in the IIS Log for the web site?  No

  8. Are their any entries in the HTTP error logs?   Yes

    2010-02-17 17:28:47 ::1%0 49991 ::1%0 80 HTTP/1.1 GET / 503 - N/A -

So what could be going on here? After a bit of troubleshooting I was able to find a event in the event log that led me in the correct direction. Here is a summary of the event:

Log Name:      System
Source:        Microsoft-Windows-HttpEvent
Date:          2/17/2010 9:26:44 AM
Event ID:      15007
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Reservation for namespace identified by URL prefix https://+:80/ was successfully added.
Event Xml:
<Event xmlns=">
    <Provider Name="Microsoft-Windows-HttpEvent" Guid="{7b6bc78c-898b-4170-bbf8-1a469ea43fc5}" EventSourceName="HTTP" />
    <EventID Qualifiers="16384">15007</EventID>
    <TimeCreated SystemTime="2010-02-17T17:26:44.064479100Z" />
    <Correlation />
    <Execution ProcessID="4" ThreadID="44" />
    <Security />
    <Data Name="DeviceObject">\Device\Http\ReqQueue</Data>
    <Data Name="Url">https://+:80/</Data>

The key part of this event is that it mentions the namespace https://+:80/ was successfully added. What exactly does this mean? I am not going to go into detail in this blog, but this blog explains why URL reservations are typically used.  In our case we first need to list all of the registered URLs via the following command, run from an Administrative command prompt.

netsh http show urlacl

Reserved URL            : https://+:80/
        User: NT SERVICE\Machine
            Listen: Yes
            Delegate: No
            SDDL: D:(A;;GX;;;S-1-5-21-2127521184-1604012920-1887927527-67210)

Root Cause & Solution

We can see that the URL is reserved. The "+" sign means any host header, and the :80 means anything on port 80. Since there is no application path after the final "/" it reserves anything that runs on port 80. This is what is causing the 503 Service Unavailable errors, as this reservation will prevent W3SVC from obtaining the rights to listen on port 80 when it tries to start the site. Furthermore, applications that run in IIS do not need explicit reservations to run, only non-IIS applications have to reserve a URL namespace if they want to use HTTP to listen for requests.  One example are WCF applications that are running on HTTP, as these are non-IIS applications that use HTTP to listen for requests.   To resolve the problem for the default web site, we have to remove the reserved namespace for port 80 with the following command.

netsh http delete urlacl https://+:80/

URL reservation successfully deleted

After removing this namespace, WCF applications or other non-IIS applications running on this server may break.  So a new URL reservation may be needed for those applications.  The new URL reservation should point to the specific application on port 80, not the root.  This will prevent the URL reservation from blocking all applications under port 80.  The next question is who added the namespace in the first place?  There is no real way to identify that, however the HTTPEvent 15007 in the System Event log will give a good indication of the Date and Time the reservation was made.


To summarize, if you are getting a 503 Service Unavailable that looks like the one in this blog post, and you have checked all of the items in the checklist. It is probably time to look at the URL Reservations, and make sure their are not any all inclusive registrations for the port the web site is running on. Meaning https://+:80/, a registration for https://+:80/Application_Name is OK, as it only registers the Application_Name namespace, not the entire port 80 namespace.