IIS7: Sharepoint 2007 fails with 503 Service unavailable errors

Recently I have seen a few of these cases come in so I thought I would share

what I know at this time.


Technologies involved


- Windows Server 2008 64 bit
- SharePoint 2007 (64 bit) configured as a dedicated indexing Server




After installing the 64bit version of Sharepoint 2007 on Windows 2008 Server we see the following behavior:

IIS crashing as soon as any request is made to the server and gives a 503 Server Unavailable error message




In the event log you will see the following event entries:

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          6/24/2008 2:43:16 PM
Event ID:      5139
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      <ComputerName>

A listener channel for protocol 'http' in worker process '5764' serving application pool 'DefaultAppPool' reported a listener channel failure.  The data field contains the error number.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <Provider Name="Microsoft-Windows-WAS" Guid="{524B5D04-133C-4A62-8362-64E8EDB9CE40}" EventSourceName="WAS" />
    <EventID Qualifiers="32768">5139</EventID>
    <TimeCreated SystemTime="2008-06-24T18:43:16.000Z" />
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Security />
    <Data Name="AppPoolID">DefaultAppPool</Data>
    <Data Name="ProcessID">5764</Data>
    <Data Name="param3">0</Data>
    <Data Name="ProtocolID">http</Data>

Also all sites when browsed return a 503 Service unavailable




It was found that after configuring a shared service provider for Sharepoint ipv6 entries are added to the hosts file that look similar to the following:

fe80::1451:3968:5b73:2978    ServerName # Added by Office SharePoint Server Search (6/23/2008 6:14 PM).

These entries are added for the dedicated crawler

We found that if we removed these entries, that the site starting working again, but once the WAS service is restarted they are added back




It was found that if you use the setting "Use all web front end computers for crawling" then it does not add the IPv6 entries, if you use a dedicated host then Sharepoint adds these entires

Below are the steps to use all frontend servers for crawling:

Central Admin Website --> Operations --> Services on Server --> Go to the server that hasthe search installed --> Office Sharepoint Server Search --> enter all the information and change it from "Use a dedicated web front end computer for crawling" to "Use all web front end for crawling"


Workaround 2:

Disable IPv6 on the NIC
Removed the entry from the hosts file. The entries look like:

fe80::1451:3968:5b73:2978    ServerName # Added by Office SharePoint Server Search (6/23/2008 6:14 PM).

Restart the Windows SharePoint Services Search and Office SharePoint Services Search service

The entries are then added back using the IPv4 address

Broken again by enabling ipv6
Removing the ipv4 entry from the hosts file
Restarting the Windows SharePoint Services Search and Office SharePoint Services Search service

Now restart the application pools in IIS and you should be able to browse the sites.


More Info


So at this time using a dedicated crawler is not working. Once I have more information on how to get this working I will post it to the blog.


Best Regards,

IIS/ASP.NET Support Escalation Engineer

Comments (8)
  1. JoeFrazier4th says:


    i was getting the error

    LoadBalancer.UnRegisterLauncher failed:  The remote name could not be resolved: "COMPUTERNAME"

    and none of my sharepoint webapps would stay started.

    i would get Service unavailable when i tried to open any sharepoint page.


    thank you!!!!

  2. Jeff,

    thanks a lot for posting this! I would have never guessed that the app pool crashes were happening because we had recently changed the setting from "use all WFE for crawling" to a dedicated server.

    Quick note: your Workaround #1 does not work, as the central admin web app is unavailable as well. For Workaround #2: even though we had IP6 active, the hosts file entry we had was IP4… sp # Added by Office SharePoint Server Search (5/11/2009 5:14 PM).

    Deleting that line, then disabling IP6 (just to be safe), and then restarting the "Stopped" app pools was all that was neccessary to get everything working again.

    What I found odd btw is that also our non-SharePoint app pools had crashed because of that hosts file entry.

    Thanks again for your helpful info!


  3. Body: My friend Ralph today ran into the issue described here: http://blogs.msdn.com/jmacleod/archive

  4. joelji says:

    Thanks a lot Jeff.

    For me the scenario was same: MOSS 2007 x64 with SP2 in a Windows server 2008 x64 with IIS7. Central Admin was working fine but SSP admin site/new webApp created was throwing error ‘503 Service Unavailable’. I found that the WebApp for SSP for stopped. Even when i tried to start it from IIS manually it failed.

    I tried the first workaround:

    "Use all web front end for crawling" and recycled the App pool in IIS which solved the issue.

  5. ravindarg says:

    Can someone please post exact STSADM command to change crawl service to use WFE(web front end) servers from dedicated server option. I am having same issue and Central admin is not working. Thanks

  6. paul says:

    You would think that IIS would on this version at least be able to read IPV6 format. Thanks for the info.

  7. Darwin says:

    Thanks!!  Work-a-round #2 worked great for me!  Saw the entries, commented out and they popped back in like you described.  I took off IPv6 and restarted and BOOM, worked.  I don't think I'd ever have found that.  I was all over iis admin to no avail.  THANKS for the post!  

Comments are closed.

Skip to main content