I’ve planned myself one of those problem fixing days again. And I started off with an easy one:
A critical Sharepoint event log entry that said: The Execute method of job definition Microsoft.SharePoint.Administration.SPSqmTimerJobDefinition etc.
Luckily I was not the only one with this problem. Ian Anker wrote this up in his blog way better then I ever can. So here is a link:
Issue 2: Another Event log Error on our TFS production server
This was also a Sharepoint issue one a bit easier to solve though. The error was:
Load control template file /_controltemplates/SearchArea.ascx failed: ‘Microsoft.SharePoint.WebControls.SearchArea,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c’ is not allowed here because it does not extend class ‘System.Web.UI.UserControl’.
After some research I found out that the SearchArea.ascx file was left behind because we upgraded from WSS 3.0 to Sharepoint Foundation 2010. Renaming the file on disk to SearchArea.ascx_old stopped the errors from popping up. I guess you could probably remove it, but after that first issue, I didn’t want to tempt fate any more than I had to.
And now to lunch.
Sometimes you have those days where all you do is troubleshoot and fix ‘problems’. These can be your most fulfilling days, or the most frustrating ones depending on how many of these issues you can resolve before lunch (or the end of the day for that matter).
Now and again, I can plan my day of troubleshooting, where I can pick up those event log errors on my TFS server that don’t hurt too much but keep annoying my SCOM Admin. Or perhaps fix that thing you have a work around for that takes 10 minutes extra of your time so its not deemed very urgent.
Well, today I had one of those days and I’d thought to share the solutions to the problems I have solved.
Issue 1: An Event log Error on our TFS production server
This is a Sharepoint issue, so probably not TFS specific, but the full error was:
An exception occurred when trying to issue security token: Could not connect to http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:32843.
It turned out there was a application pool down on the server (The “SharePoint Web Services Root” to be precise). After starting this thing back up, the problems were solved, or so I thought. It turned out I had opened a Pandora’s box. Which, if I had known beforehand would probably have stopped me from going the route I’m about to describe, and just reinstall Sharepoint on the TFS server.
First of all the “Sharepoint Web Services” website in IIS manager was presenting strange errors: The object identifier does not represent a valid object. With no good option to be found on the Internet I recreated the website by hand (including all bindings, advanced settings, virtual directories and applications). This solved the immediate problem of the error message in the IIS manager.
But the Security Token Service still wouldn’t work. So I decided to compare the IIS settings and configuration to a working installation of Sharepoint Foundation 2010. And it turned out, our TFS server did not have the SecurityTokenServiceApplication application configured. So I created it and set it to all the correct app pools, folder etc. After that I had to change the web.confg of the SecurityToken.svc because it enabled the WindowsAuthentication Module which was already enabled.
To make a very long and tedious story short. It now works, the errors have disappeared from my event log and Sharepoint Admin Monitoring page. But next time I’ll just reinstall Sharepoint Foundation 2010 I think. This was 4 hours of my life I am not going to get back.