Problem:
Customer installed Office Web Apps, runs PSCONFIG and then sees the dreaded 500-Internal Server Error when browsing to site collections in their farm.

Resolution:

From past experience, I knew this must be a problem with the web.config and that it must have to do with installing Office Web Apps because everything was working fine just before doing so. And it was affecting all web applications on the farm. I did the basics, reset IIS, clear the config cache but none of that worked, although I hoped it would. After scouring the internet, asking colleagues, I was so happy to find this blog post that fixed the problem: http://amritatalreja.wordpress.com/2011/07/27/http-error-500-19-internal-server-error-after-installing-office-web-application/

1. Open web.config file for one of your web applications
2. do a search for <staticContent> and if you find this block below, you’ll notice that there are two <staticContent> tags. You will need to manually remove the block highlighted. REMEMBER: Backup the web.config file first!!!
   
   <staticContent>
   <mimeMap fileExtension=".atomsvc" mimeType="application/atomsvc+xml" />
   <remove fileExtension=".svg" />
   <mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
   </staticContent>
   <staticContent />
   </system.webServer>

Fight Comparison
GSP vs BJ Penn I….after getting his butt kicked in the first round, GSP listened to his coach, modified his game, like I modified the web.config file per my online coach Amrita, and won by split decision. A win is a win.

Problem:
End-user created a web site from the Projects Web Database site template and upon browsing to the home page of that site would receive an ‘Unexpected error occurred while running macro’ message:

Resolution:
The user did not know it but they had invoked Access Services by creating a site from the Projects Web Database template so that allowed me to narrow down my troubleshooting scope. I checked to see if Access Services was turned on in the farm and yes it was. Upon further research I discovered that if Access Services is activated on an Application Server you will also need to turn on the Microsoft SharePoint Foundation Web application Service, thus turning that machine into a WFE/APP server. Problem with this approach is that it could affect your licensing agreement because licensing depends on the number of WFE’s your farm has.

User decided to do this instead:

• start the Access Database Service on an existing WFE(s)
• stop the Access Database service on the APP server(s)

Fight Comparison
Mike Tyson vs Frank Bruno I…Frank Bruno was a big, monstrous guy, but Mike was fearless and took him out in the 5th. This error looked more complex than it really was….just like Frank Bruno.

Problem:  
This customer would try and browse to their My Site web application but would receive the dreaded 500 - Internal Server error:

From my experience, right off the bat I know this is usually a web.config problem. I was given a clue by the customer that this happened during a time when some of the admins were playing around with the installation of some 3rd party web parts in this environment. My hunch was that something got written to the web.config for this web app because when I looked at Central Admin, I noticed that they had deployed these custom web parts to ALL web applications including My Sites. So the moral of the story is to be selective when deploying web parts and only install them on the web applications that need them.

Resolution:
Since this My Site web application was pretty clean, meaning no customizations were MEANT to have been installed on it, I figured the quickest thing would be to:

• Create a blank dummy web application
• Copy that web.config file from that web application to the My Site web application (of course backup the existing web.config file first)
• default location of web.config file c:\inetpub\wwwroot\wss\virtualDirectories\[name of web application]\web.config
• problem solved

Fight Comparison
Aaron Pryor vs Alexis Arguello…Pryor just had Alexis number

Problem: User clicks on a preformatted URL like this:

http://sharepoint/sites/test/Lists/Calendar/calendar.aspx?CalendarDate=4/16/2012 in order to get to a week view of a calendar but no data appears. I verified that data for this week does indeed exist. I also verified that I could not reproduce this issue on a pre SP1 + Dec. 2011 CU environment so it appears to be a bug present before this build. This particular customer was on the Feb. 2011 CU:

Resolution:
It was not possible for the customer to patch up to a higher patch level at this time, but thanks to my colleague Kerry Williams, he figured out that changing the date format in the URL fixed the problem and displayed data in the weekly view as the user expected: http://sharepoint/sites/test/Lists/Calendar/calendar.aspx?CalendarDate=2012-04-16. This was an easy change that the user was able to make on their links to these views

Fight Comparison:

No Contest