The situation was that I thought I would bring my SharePoint 2013 up to date with the latest cumulative update, at the time of writing December 2013 as we are still waiting for the issue with SP1 to be remedied.

So the cumulative update ran through fine and apart from a few complaints in the upgrade file to do with PowerPivot, all was well. So I went in to a demo site and got an empty screen with the following: Server Error: http://go.microsoft.com/fwlink?LinkID=177673. When you click on that link it takes you to an update deployment page for SharePoint Foundation 2010.

So I checked central administration upgrade status – nothing. And checked the database upgrade status, all fine. So I went with my cavalier-lazy and ran the SharePoint 2013 Products Configuration Wizard. After the usual multi-stage process it completed with no complaints. Checked my site, no joy – same result.

So I had a hunt around and fired up the SharePoint 2013 Management Shell and Test-SPContentDatabase on the content database for my demo site and nothing. So I ran it as administrator and again got nothing. So I tried Upgrade-SPContentDatabase and it helpfully told me that my content database didn’t need upgrading.

So I had another hunt around and tried psconfig -cmd upgrade -inplace b2b -wait -force and again got no errors. So I admitted defeat and started hunting through my ULS logs. This threw up interesting errors, the start of which was:

04/21/2014 10:55:41.99  w3wp.exe (0x3208)                        0x237C SharePoint Foundation          Database                       880i High     System.Data.SqlClient.SqlException (0x80131904): CREATE TABLE permission denied in database ‘

So again I took the lazy approach and fired up SQL Trace on my database and narrowed down the filter to have a Database Name like the content database and ran it up, and assuming it was psconfig related ran that again. The command ran through with no errors reported to the command line and when I stopped the trace and had a look I didn’t see anything. And nothing in the ULS log. So I waited. And the same entry appeared again – don’t you love asynchronous stuff?

So I was a bit more patient this time – I restarted the trace, and ran psconfig, and waited until the error appeared in ULS. Then stopped the trace and went looking. And there it was, a big long SQL statement running under an account that didn’t have sufficient priviledge to create the table. So being a hacker I gave that account dbo priviledge – ran psconfig and after a suitable pause my site is running again.

The interesting bit ? The identity wasn’t the application pool identity of the web application, it wasn’t the identity of the timer service (Ok I know it wouldn’t be, owstimer.exe wasn’t owning up in ULS). On my VM it was the identity of the portal web application / community sites. I’m nonplussed but will put it on my “to learn” list.