SBS 2008 Sites down...again

There are not too many sites, but your bindings are wrong. Edit the bindings fore the default website and remove 443. Then restart the site to release the port. The SBS web apps site should then be able to be started. Once everything is started, I would do one last IISReset from a command prompt just to make sure everything comes back.

-Cliff

Went to remove it and it says that it will cause the bindings of another site to be unusable.  Is that what you were expecting?  I have not yet done it.

That doesn't sound quite right. Posting the exact error would be helpful.

'The certificate associated with this binding is also assigned to another site's binding.  Deleting this binding will cause the HTTPS binding of the other site to be unusable.  Do you still want to continue?' Then I am given the Yes/No/Cancel option.

Still wondering if you have any idea on this...

Back up the cert and proceed.

-Cliff

Okay, here is an update.  Did as requested and after IISreset two of the 3 sites listed in the SBS Console came back up.  The companyweb did not.
Could this be because port 80 is still active on the default web site?
Oh, an I am not getting alerts when you post so I apologize for any delays in not replying promptly.

Mark

Sites keep the same state they were in. An IISReset does not try to start stopped sites. Manually start the site THEN do an IISReset. And no, non-SSL sites can use the same port, so there is no conflict on 80.

-Cliff

Okay Cliff!  The site is currently experiencing a power outage with no ETA on recovery time.  I may not be able to work on this until tomorrow morning.  
Yeah...I did the IISreset first then restarted the sites.  I'll redo it as soon as I have access.
Thanks for everything!

I still have the issue where the COMPANYWEB site is down.  Checked event viewer and immediately following iisreset is an error code 1007 from IISW3SVC.  Error info reads:
The World Wide Web Publishing Service (WWW Service) did not register the URL prefix https://*:987/ for site 1738968964. The necessary network binding may already be in use. The site has been disabled. The data field contains the error number.

So somewhere in your site list, another site has a binding using port 987. Find it.

-Cliff

Sorry for the delay.  Here are the two sites that have the 987 bindings:
SBS Sharepoint (NOTE: has a black box next to it.  Down site, correct?)
Sharepoint - 80
The SBS Sharepoint site only has bindings for 987...nothing else, but has a full folder structure below it.  Sharepoint-80 has no folder structure beneath it.  I am assuming then that the -80 is the invalid one and needs to be removed...is that correct?

-Mark

Just remove the binding. It is PROBABLY a dead site...means someone reran the sharepoint config wizard unnecessarily. But just to be safe and to preserve any data, no need to remove the site. Just the binding will suffice. Then your company web should start safely.

So, here is what happened:
When I went to remove the binding, delete was not an option in the Sharepoint - 80 site. It is an option in the other SBS Sharepoint site.  However, the SBS Sharepoint has a full file structure and the Sharepoint-80 does not.
Should I delete the Sharepoint-80 site or just remove the binding on the SBS Sharepoint?

Sharepoint -80 site has been stopped but am still not able to delete the binding. So, just on a hunch I went edit the binding and an error message came up in the window "Edit Site Binding"
Details:
Filename:
\\?\C:\inetpub\wwwroot\wss\virtualdirectories\80\web.config
Error: Cannot read configuration file

Don't know what that indicates.

Likely a permissions issue. You are logged in as administrator and launched the IIS control panel using the "run as administrator" option?

-Cliff

Okay, since the Sharepoint - 80 site is stopped I figured starting the other site wouldn't hurt anything to try.  Started the SBS Sharepoint site, ran IISRESET, the site came up.  However, when I attempted to remote into the system to see what is going on the website did not come up. I'm going to check on the internal computers to see if the intranet comes up, and will advise.

So I was able to confirm that the intranet is functional but now the remote web workplace isn't functioning.  Wierd.  

The two are completely unrelated as far as IIS is concerned. If RWW quit working it means that something was changed unrelated to SharePoint. Are you sure you didn't stop the site or that it did indeed start after you did your IISReset?

In re-reading this thread, it seems as though somewhere along the line someone has done some *significant* manual changes within IIS and chose to break away from the SBS wizards. While you can do this if you are *very* skilled *AND* very careful, it is rarely a good idea and even more rarely required (the wizards only automate the manual process, there is no pixie dust in them) ....so I'm guessing those changes are continuing to cascade and cause you issues.

For example, that SharePoint - 80 site is not created by SBS and never exists in any default configuration or created by any patch. The *only* way that occurs is if someone manually ran the SharePoint configuration wizard, which SBS automates so is never required.

Just sayin' ...

-Cliff

There was an issue some time back where we were working with Microsoft on the server.  The tech that I had worked with at the time is no longer with the company, so I can't follow up with him about this.  Neither the tech that was working on this nor I are that skilled with IIS or even Sharepoint.  I'm learning...but I wouldn't make manual drastic changes unless MS instructed me to.
At this point, what would you consider I do from a 'best practices' standpoint?  What can I do to undo any manual changes (ie uninstall Sharepoint or IIS?) Then rerun the wizards?  Any suggestions as to where to go from here would be helpful.

Thanks for everything!  

Honestly, at this point we seem to be going in circles. This issue is large enough that I believe it to be beyond the scope of an EE problem. You'd be best served by brining in a trusted consultant to help clean up the issue where they can get hands-on with the server, see what has been changed, and get things back to a stable state. The cost of such an expert would be less than the cost in wages for the time you've already invested in trying to fix this issue yourself.

-Cliff

Thanks for everything!