Seems this is quite common but none of the Microsoft suggested fixes worked for me so thought I’d round up some of the things I did find and what worked for me.
So what was the actual problem?
After we’d installed security update KB983444 for SharePoint we were unable to browse to the SharePoint site or the SharePoint Central Admin site.
We were also getting messages in the event log along the lines of
“Access to table dbo.Versions is blocked because the signature is not valid”
As i said at the beginning it’s quite common and there are a couple of posts from Microsoft about and how to fix it.
From the SharePoint team: http://blogs.msdn.com/b/sharepoint/archive/2010/06/22/installing-kb938444.aspx
When you install any SharePoint patch the binaries installed first and then the database is upgraded separately. What can sometimes happen is that the install doesn’t complete so the suggestion from the two articles above is to give SharePoint a kick and re-do the database upgrade with the following command
psconfig -cmd upgrade -inplace b2b -wait –force
The problem we had was the command fail on stage 2 of 4 with a similar error
“Access to table dbo.dtProperties is blocked because the signature is not valid”
Here are some of the things I found which may help in other scenarios but didn’t work for me here!
- Download the update and extract the msp file, reapply the patch, reboot and then run the upgrade command again.
- Remove the groupboard template (we weren’t using it!), reapply the patch
- Remove SharePoint and the Windows Internal Database, reinstall and reattach the content database (This isn’t a fix in my opinion. What after you’ve done all that, you apply the patch and the same thing happens again?)
- Ensure you have owner permissions on the SQL database
- Ensure the account you are running the update from is in the security groups WSS_ADMIN_WPG, WSS_RESTRICTED, WSS_WPG (and IIS_IUSRS for Windows 2008)
- Use these order ativan online canada commands to reprovision the web servicestsadm -o provisionservice -action stop -servicetype spwebservice -servicename ""
stsadm -o provisionservice -action start -servicetype spwebservice -servicename ""
psconfig -cmd upgrade -inplace b2b -wait -force
Your mileage may vary with all of these suggestions so use at your own risk.
So where to go from here? I really didn’t want to go back to backups in case I ran into the same thing after reapplying the patch.
I trawled through the logs again to figure out exactly what was going on and went back to the fact the error message was slightly different from when I’d first started.
I opened SQL management studio and noticed that in the database there is a folder for system tables. In all the other databases there were empty but in this instance there was one table called dtProperties. I couldn’t ever remember seeing that before so I logged onto our server to see if it was the same.
I went back through the logs and as far as I could tell it was running through all the tables and falling over when it got to the dtProperties table.
Our server didn’t have this table so since I was running out of ideas and was at the stage where I thought I’d be reverting to backups I took a backup of the database and deleted the table.
I ran the PSEXEC command again and it completed successfully!
The SharePoint site was backup as was the central admin site.
My “guess” is that during the upgrade the dtProperties table is a temporary table that had been left behind (if anyone knows otherwise please let me know!)
I really wouldn’t recommend directly accessing the SQL tables in this way though. I was fully prepared to go back to backups but was determined to figure out what was going on.
I’ve skipped over the part where I spent an hour reading the logs line by line to figure out exactly what was going on!
Hope this helps someone else.
Latest posts by Andy Parkes (see all)
- My Year In Running – 2017 - January 1, 2018
- Run For Your Life – A Magazine About Everyday Runners - December 9, 2017
- DNS Server Can’t Resolve Against Itself - December 6, 2017