SharePoint Troubleshooting by Ayman El-Hattab

Yesterday, I released a new, free bonus issue of the Understanding SharePoint Journal. Written by Ayman El-Hattab, this issue walks you through different techniques and tools that are valuable in fixing problems in SharePoint. Quite frankly, this should be part of the SharePoint documentation, but then again…

What I like in particular about Ayman’s issue is that he targets not only developers, but also administrators. Even if you have no idea about the difference between a class and an object (in my world, that means you are not a developer) you’ll still learn plenty of tips and tricks to help you out.

Here are some of the topic covered:

  • Debugging Your SharePoint Code
  • Unified Logging Services (SharePoint Trace Logs)
  • Windows Event Logs
  • Post-deployment Troubleshooting
  • SharePoint Troubleshooting Toolbox (excellent overview of various tools)

In any case, to get the issue, you need to be on the USPJ mailing list. You can sign up on the Understanding SharePoint Journal web page, and you’ll get the password to the free SharePoint resources within a couple of minutes.

Let me know what you think, and feel free to send feedback to Ayman as well. He has published his email address in his blog:


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

I’ve Sold My Soul

Update: This was supposed to be such a joyous occasion, but alas, that’s not how it turned out. Read about it here.

The news should be out by now; I’ve gone ahead and sold my soul by starting a new permanent job  here in Norway. Although this is probably extremely uninteresting to you, as you are here to read about things that benefit you rather than affect me, I’d still like to mention it.

The culprit behind this vile scheme? Ergo Group in Norway. When I let the news go that I was looking for a permanent position, Ergo came out the clear winner.

First, this will not mean I stop writing. Quite the contrary, my contract states that I shall continue writing, both books, articles, and Understanding SharePoint Journal.

Second, this means I get a lot more input on what to write. Just the first few days, I’ve had inspiration for at least two new articles and one journal issue.

I will also encounter situations and problems now that I work with others to a greater extent. I, of course, never make any mistakes, so that’s why I need external inspiration for further debugging articles. Oh, and I’m also very modest.

The first article came out on Friday, and explains one of those really obscure scenarios that it would have taken years to discover in a lab environment. Basically, if you share your database server with other applications, you may encounter a situation in which you cannot add new servers to a farm due to certain content in other databases.

Read that article here: Shared SQL Server for SharePoint? Watch Out!

I have now started writing down placeholder articles in Live Writer for new post and article ideas, and since I started at Ergo, I have created six placeholder articles. So, make sure you follow along, either on twitter (@furuknap) or through RSS.


Pin It

Shared SQL Server for SharePoint? Watch Out!

I just encountered a weird problem. When trying to run the SharePoint Products and Technologies Configuration Wizard and connecting a server to an existing farm, the whole config wizard crashed when we clicked the Retrieve Database Names, sporting a fancy new exception I have never seen before:


System.Data.SqlClient.SqlException: Operand type clash: uniqueidentifier is incompatible with int
Invalid column name ‘Version’.

Of course, Googling this didn’t turn up any relevant result, at least not when combined with SharePoint. That’s about to change 🙂

After a few hours of searching we found out that the problem is that the SharePoint config wizard iterates through all the other databases on the server, and runs a query to try to detect whether the database is a SharePoint config database.

The way the wizard does this is by checking for the existence of a table called Versions, and if found, tries to get the value from the Version column in the row where VersionId is equal to a vertain value, as such:

SELECT @Version=Version FROM [dbo].[Versions] WHERE VersionId=@VersionId

This may seem like a good idea, until you realize that if you already have a database, usually non-SharePoint, with incompatible column types, such as one where VersionId is an int rather than the uniqueidentifier that the config Wizard expects, then you get the above exception.

To recreate the exception, do the following, which is very non-intrusive and won’t hurt your SQL-server:

  1. Create a new database on the same SQL-server as your SharePoint config database. I’ve named mine Test
  2. Add a new table, perhaps as such:
  3. USE [test]
    /****** Object:  Table [dbo].[Versions]    Script Date: 09/04/2009 16:25:48 ******/
    CREATE TABLE [dbo].[Versions](
        [Version] [int] NOT NULL,
        [VersionId] [int] NOT NULL
    ) ON [PRIMARY]

  4. Run the SharePoint Products and Technologies Configuration Wizard on a new server and attempt to connect to the SQL server by hitting the Retrieve Database Names.
  5. Enjoy your brand new exception.

So, how do you work around this issue? Well, delete the offending database, of course! Or, if you plan on keeping your job, try setting explicit deny access on the offending database for your install account. Of course, if you run the config wizard as administrator, that’s out of the question.

This problem only occurs when adding new servers to the farm, so one option may be to simply take the offending database offline while you set up your new server. If you really want to be hardcore, and remember my default disclaimer that doing anything I say in production is just plain stupid, then you can copy the dsn value from the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB registry key from one of the existing servers.

But, as I said, that’s just plain stupid.


Pin It