IIS Problems
|
Prev: Unable to receive some faxes
Next: w32time Event ID 29
From: Scott Shinnie on 3 Oct 2006 03:48 Hi, My problem occurred when I tried to make the internal companyweb site available to external users. Now I am going round in circles and have introduced several problems with companyweb, OWA, RWW and even backup pages do not display correctly. The local server will not display companyweb but internal clients can still access companyweb. I have tried to resolve with no success for several days, on checking several valuable posts on this site I plan to reinstall IIS as per KB887305. I am unsure if I should also reinstall Sharepoint as well using the maintenace and reinstall option. Any advice before I proceed. What is the best way to roll back OWA, RWW to their default state. Thanks Scott
From: Jim Martin [MSFT] on 3 Oct 2006 09:28 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
From: Scott Shinnie on 3 Oct 2006 10:33 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 > > >
From: Jim Martin [MSFT] on 3 Oct 2006 11:06 Scott, Changing the account settings for the app pools definitely can cause issues. As a reference the default app pool should be running under Network Service. Did you try backing up your current configuration and rerunning the CEICW? You said "My problems started as soon as I started trying to apply a new SSL certificate to a specific sharepoint site." Doed that mean you have more than one Sharepoint site? Did you apply a cert to the Companyweb site? Was it a public cert or one that was created internally? You don't have ISA by chance do you? That makes publishing Companyweb easier. Jim
From: Scott Shinnie on 3 Oct 2006 11:28
Jim, Unfortunately I don't have ISA. I had a MS article which described publishing a sharepoint site to external users. I created a test site in order to not affect my current setup (failed miserably there) it advised to create a new certificate (generated internally) and apply this to the new site. Once applied it advised to reimport the original certificate to the default web site whcih was exported before the work began. This was done, I have tried to remove these certificates completely but the wizard only allows to remove/replace on the current site. Leaving the office in an hour or so and will try the advice you have given me, I will let you know how I get on. Thanks for all your help, you have given me some hope that all is not lost (yet!) "Jim Martin [MSFT]" wrote: > Scott, > > Changing the account settings for the app pools definitely can cause > issues. As a reference the default app pool should be running under > Network Service. > > Did you try backing up your current configuration and rerunning the CEICW? > > You said "My problems started as soon as I started trying to apply a new > SSL > certificate to a specific sharepoint site." Doed that mean you have more > than one Sharepoint site? Did you apply a cert to the Companyweb site? > Was it a public cert or one that was created internally? > > You don't have ISA by chance do you? That makes publishing Companyweb > easier. > > Jim > > |