SharePoint site mysteriously stopped showing up
At my client today the weird stuff started happening. We have a Publishing Portal that gets created through a wsp solution. The main page of this portal needs anonymous access so we have to turn that on at the Web Application level. The same exact solution is on our development machines and we went to move it to a staging environment. We created the custom portal site in the staging environment and didn’t do anything else in SharePoint except turn the anonymous access on at the Web Application level (just like we do on the development machines). However, when we went to the site the search box didn’t show on the page – there was just blank space in it’s place.
When I did a view source on the page and looked for the search section where this should of been I saw this:
<td valign="top"> <div WebPartID="00000000-0000-0000-0000-000000000000" HasPers="true" id="WebPartWPQ1" width="100%" OnlyForMePart="true" allowDelete="false" style="" > </div> </td>
So, I found this very strange and chalked this up to portal features not being installed correctly on the box. This is because this particular search box only works with a portal. According to it’s documentation it looks for features turned on at the farm and if it doesn’t find any there it looks for the featre at the web app and it continues this process through the site collection and then finally to the actual site.
Then, while I was researching this the client came to me and said there are more issues. They went to do an approval process, on the actual publishing page, and got an error that said “Unexpected error occured”. In fact, we also lost all of our css styles too, which was really weird.
At this point I realized I was going down the wrong path with the portal features, we seem to have a much bigger issue. So, I had them turn their logging up to verbose (this might have been overkill, but I wanted to make sure we got our log).
To do this: go to central administration – operations – diagnostic logging and then set the event throttling like below:
After the event logging was turned on we recreated the error one more time and I went to the logs. The logs had messages about not being able to connect to the SQL Server Session Database.
So, at this point I realized it is a connection issue, which means app pool issue usually. When we went to the app pool account we saw that it was set to Network Services. However, the client had already set this to the right account. So, how did it turn back?
Basically, in SharePoint you try not to modify IIS directly if you have the choice. You try to let SharePoint do it for you. In this case the app pool account was set directly in IIS. However, the services account wasn’t set on SharePoint. This is at Central Administration – Operations – service accounts. You must set this account correctly. In our case we were setting anonymous access to our web application, through Central Administration. This means SharePoint has to make modifications to IIS directly. Well, when SharePoint makes these modifications to IIS, it sets IIS exactly like you have it setup in Central Administration. So, changes you make directly in IIS can be overwritten. The following article gives a good explanation of this:
So, what did we learn today – do not modify your IIS when dealing with SharePoint sites. Myself and this particular client actually knew this, but there are other mitigating factors in which they have to modify IIS. They just were not aware of the service accounts in Central Administration. If you do modify IIS directly be really careful and make sure SharePoint can “recreate” the settings if you make any changes in Central Administration. Also, if you are dealing with a farm, be careful that changes get propogated throughout the web front ends.