Among the multitude of issues I faced in the process of creating an internet facing publishing portal in SharePoint, this one was killing me for a couple of days.
After extending my web application to intranet zone, i enabled FBA authentication with anonymous access in my default zone. The strange thing i noticed is that if you open a page for the first time, you’ll hit a page showing 401 – Unauthorized error. But if you refresh the page in your browser, the page loads fine in anonymous mode. Each and every ‘postbacks’ in your pages will face the same issue. After hours of googling and found the solution for the problem. To get rid of the issue
1. Change <compilation batch=”true” debug=”true”> to <compilation batch=”false” debug=”false”> in your web.config.
2. Allow anonymous access in the windows authentication zone. To do that follow these steps.
- Go to Central Administration -> Application Management -> Authentication Providers
- Select your web application
- Choose the appropriate zone which is configured to use windows authentication
- Check ‘Allow anonymous access’
- Click OK
Whoomp! The issue is gone.
I was in the process of migrating a MOSS publishing site to a production server. I extended the site to intranet zone to have the default zone to be configured for FBA authentication. While extending the site I made a typo while specifying a host header for the site. When I tried to delete the extended web application by selecting it from the web applications list in CA I was not able to find the extended application’s entry. Then I googled for a while to find a solution and found it here – http://sharepointnotes.wordpress.com/2008/07/17/quick-tip-delete-extended-web-application/.
To delete an extended web application,
1. Go to Central Administration -> Application Management -> Remove SharePoint from IIS Web Site
2. Select the original web application from the list
3. Select the appropriate extended application to delete
4. Press OK
Recently I did a fresh installation of SharePoint 2007 in a standalone system and applied all the service packs and cumulative updates released. After working in the server for 2-3 days I noticed the free space of the SharePoint installation drive going down at a very high rate. I lost over 5.5 GB of the free space in the disk over the past two days. I installed this handy tool to investigate the sizes of the folders residing in the drive. To my surprise, I found out the ’12 Hive’ occupying around 6 GB of the disk space. When I opened it to check the individual sizes of its sub folders I found that the whole space is taken by the LOGS folder. It contained around 3-4 files sizing over a GB. I stopped the WSS Tracing service in the services and deleted all the XL log files. But when I switched on logging it started growing again. I googled out the issue for a few minutes and found this useful post – http://blogs.vertigo.com/personal/steventap/Blog/archive/2007/01/19/managing-sharepoint-2007-moss-application-log-size.aspx dealing about this issue. The solution is just to configure the Diagnostic Logging in Central Administration -> Operations -> Diagnostic Logging. I just configured ‘Least Critical Event to report to the trace log’ to be medium, since I’m working in a dev environment. You can configure it according to your server’s nature such as production, staging etc.