Hi,I'm in real need for some assistance on how to troubleshoot a Sharepointserver that is unreachable.Today a consultant installed a web application on a server also hosting WSS 3.0 and right after that the Sharepoint site has been unreachable. This also includes the central administration.I was not around to find out what that consultant did at the server. Since I don't have access to central administration I have only "Windows" methods.The IIS site looks fine (meaning content and administration sites are up and the application pools as well). Network service is being used. The SQL server (Windows Internal) is also up and running with the Network service having access to it. The system event log does not provide any errors. However the application log tells me that the Sharepoint Search error 2424:"The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again".Apart from that, not much interesting in the application log either. I read quite a few articles on that but they are all actually about the search server and all pretty much assume you can use central administration. The server in Windows 2008 SP1 Std x64. And the error message trying to start the content site or the administration web site is simply "HTTP 500 Internal Server Error".

If you are running IIS 7.0, then you should be able to get the stack trace of the 500 error. Open IIS Manager Select the central admin web app In the actiosn pane, select "Failed request tracing..." Select the "Enable" checkbox Submit an http req again to central admin web browse to the log directory from the checkbox step and see what's up If all else fails, you can try to remove the server from the farm and then add it back. ChrisChris Givens CEO, Architecting Connected Systems Blog Twitter

Thanks Chris, I enabled this (for documentation I added a Failed Request Tracing Rule) as well.I certainly creater log files, do you have a good tip on how to best analyze these for an IIS rookie?

I don't actually, I'm a dev guy and love log files. The first time I turned it on I was amazed at the amount of information it dumps out. I'd guess that your error would be towards the last 1/4 of the log file for that request. ChrisChris Givens CEO, Architecting Connected Systems Blog Twitter

OK, I went through the logfile from the beginning to end and the only thing that I really react to as an error is pasted here. It doesn't tell me much but perhaps to someone else? I've seen one post on the newsgroups mentioning it has to do with 32/64 bit http://social.msdn.microsoft.com/Forums/en/sharepointdevelopment/thread/1131026f-7d8b-4e88-8d2c-398b12f4336d However: <Data Name="ContextId">{00000000-0000-0000-5401-0080030000F5}</Data> <Data Name="ModuleName">IsapiModule</Data> <Data Name="Notification">128</Data> <Data Name="HttpStatus">500</Data> <Data Name="HttpReason">Internal Server Error</Data> <Data Name="HttpSubStatus">0</Data> <Data Name="ErrorCode">2147942593</Data> <Data Name="ConfigExceptionInfo"></Data> and a few lines below <freb:Description Data="ErrorCode">%1 is not a valid Win32 application.Erik, with many, many certs! ;-)

Sounds like someone dropped a 64bit dll in your bin directory. Check to make sure nothing crazy is sitting in any of the web application bin directories. ChrisChris Givens CEO, Architecting Connected Systems Blog Twitter

Wow, what a mess: 1) WSS 3.0 using WID - ouch 2) Some random consultant created a web app and broke it all and isn't required to fix it? Wow, ouch again! 3) Network Service is the service acocunt for all this? Oof, bad juju. 4) You are troubleshooting it now and don't have access to Central Admin due to it being down or because you don't have farm admin rights for performing stsadm commands directly on the server? This is important, because you will definitely need the ability run stsadm commands. If you don't have rights, you'll need to get local admin rights on this server to fix things. Ok, so with that out of the way, I'm guessing that the fact this is a single standalone install with WID, no domain accounts, and a random consultant blowing it up, then it means this is just a development server that rarely gets used, right? That could be its only use, imo. ;) Ok, so 500 is likely due to the new web app messing up your AAMs or something of that nature. You say that IIS looks fine, but isn't there a new application pool or at least a new web site that was created by the consultant? What do you se ethere? Is it started or stopped? Are Central Admin and all the other app pools started or stopped? what about each site? Is the default site started or stopped? What are the bindings that you see for each site that you need to access? How do they compare to the bindings for the new site created by the consultant? Let us know all the ports and host headers/bindings for each site as well as the status of each app pool and site. Please also confirm that the Network Service is the service account for _every_ app pool. Thanks!SharePoint Architect || Microsoft MVP || My Blog

Hy, i`ve had exactly the same problem and my fast solution was uninstalling php 5.3.2, it was doing a conflict with wss. after the wss started,i had repaired my php + fastcgi + iis.

Hi and thanks for you efforts. The problem was that the application pools were enabled for 32bit. All of them! Changing it back to x64 resolves the problem (of course, setting 32 bit on the "3rd party" application pool is the right way to go). For other people that may experience the problem:The consultant had run (adminscript folder of IIS) "adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 true". Not exactly wise but in an attempt to solve his/hers issue. Running the script again with the false value makes WSS happy again.Erik, with many, many certs! ;-)