RE: IIS Problems
- From: Scott Shinnie <ScottShinnie@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 3 Oct 2006 07:33:01 -0700
Hi Jim,
Thanks for the informative post, thankfully I have not reinstalled IIS and
Exchange as I had planned. I thought this was necessary as I am convinced I
have changed settings within IIS which have affected OWA etc provided by
exchange. I will try a restore of the metadatabase, unfortunately I have
never made a backup within IIS, there are some automatic backups but these
are all after the problems began. I will check the shadow volume copy and
tape if necessary. I am also going to backup my sharepoitn site, resinstall
sharepoint and a restore of the site to ensure these are returned to default.
My problems started as soon as I started trying to apply a new SSL
certificate to a specific sharepoint site.
I have changed account settings on the application pools and this may also
be the root cause. I will check as per your post.
Direct access to sharepoint site from the outside world is my goal.
Thanks a million.
Scott
"Jim Martin [MSFT]" wrote:
Thanks for the post, Scott..
First of all I hope I caught you before you reinstalled IIS. You should
not uninstall and reinstall IIS on SBS. Put simply, it breaks a lot of
things. They can be fixed but you don't want to go there. I would focus
on fixing what is currently broken. The problems are probably not
insurmountable.
If you have a backup of your IIS metabase from before the changes were made
then that is your best bet. Try to pinpoint the point in time when you
made the changes -0 that way we know what timeframe of a backup to look
for. Then go to IIS, right-click the server, 'All Tasks', 'Backup/Restore
Configuration', then look for backups (automatic or otherwise) from just
before the changes were made. If you see one that looks likely, create
another backup of the current configuration (don't want you to lose any
ground, and try restoring it. Do an IISRESET after restoring. If that
doesn't yield the right results, you can restore the backup you just made.
You can also check to see if you have a volume shadow copy of the metabase.
Check to see if you have volume shadow copy enabled on your system drive
(probably C:). If so, you might be able to retrieve a backup copy that
way. To see if volume shadow copy was enabled on the drive go to the
properties of the volume in Windows Explorer, the 'Shadow Copies' tab. It
will show which volumes it is enabled for and when the snapshots are taken.
If that is enabled, you can retrieve previous versions of the file by
accessing a share that the file resides on. But before doing that stop the
IIS Admin Service, then backup the current metabase file (go to
"c:\windows\system32\inetsrv" and make a file copy of MetaBase.xml. Then
to restore it from a previous version go to
"\\servername\c$\windows\system32\inetsrv", right-click the matabase.xml
file, go to the 'Previous Versions' tab, select the version of the file
that is most likely the latest one before the changes were made, then click
'Restore'. Then start the IIS Admin service, the WWW publishing service,
SMTP, and any other services that were previously stopped. Then see if
that restored functionality.
You can also try restoring the matabase.xml file from a tape backup taken
before the changes.
If restoring the metabase does not work, then it is best to focus on one
issue at a time. Since changes to Companyweb is where it started I would
focus on getting that to work and then go from there. I would start by
making sure that Companyweb it configured to listen on at least the
internal IP address, port 80 and port 444 (for SSL), and that it is
configured to use 2 host headers: 'companyweb' and
'companyweb.internaldomain.local'. Also, make sure you have 2 filters
listed under the ISAPI' filters tab: 'SHRPTFLT' (priority=high) and
'stsfltr' (priority=unknown). Then check the 'Home Directory' tab and make
sure it is using application 'root' in the DefaultAppPool. Then if you
have an 'ASP.NET' tab make sure it is using version 1.1, not 2.0.
Similar action should be taken on the Default Website. It should be
configured to listen on at least the internal IP address, port 80 and port
443 (for SSL), and that it is NOT configured to use host header: Also,
make sure you have 3 filters listed under the ISAPI' filters tab: 'SBSFLT'
(priority=high), 'fpexedll.dll (priority=low), and 'OwaLogon'
(priority=low). Then check the 'Home Directory' tab and make sure it is
using application 'Default Application' in the DefaultAppPool. Then if you
have an 'ASP.NET' tab make sure it is using version 1.1, not 2.0.
You can also enable logging for each website to get more details about what
is happening when access is attempted ('Web Site' tab, 'Enable Logging'
checkbox, 'Properties' button, 'Advanced' tab, check all boxes, OK, etc.
I hope this helps.
Jim
- Follow-Ups:
- RE: IIS Problems
- From: Jim Martin [MSFT]
- RE: IIS Problems
- References:
- RE: IIS Problems
- From: Jim Martin [MSFT]
- RE: IIS Problems
- Prev by Date: RE: Could not load all ISAPI filters for site/service
- Next by Date: Re: Monitor RWW Activity
- Previous by thread: RE: IIS Problems
- Next by thread: RE: IIS Problems
- Index(es):