Some time ago I had the bright idea of moving the SQL databases for Sharepoint. I was running a VPC with only one virtual drive and started running out of disk space. So I decided to create another virtual drive, detach the SQL databases from SQL Server, copy them to the new drive, mount the databases and test the Sharepoint configuration.
Everything should have worked perfectly, wrong! In theory Sharepoint should only be looking at the logical names of the databases, but it seems that I was mistaken. Most of the functionality in Sharepoint worked perfectly expect for "MySite". When I selected the link at the top of the Sharepoint site.
I got the following error.
As you can see it is completely descriptive and tells you exactly what to do to fix the error, NOT!!!!
So, now what! Without some more information to go on, it becomes a bit difficult to resolve the error and as we all know the "Event Log" only goes so far.
Fortunately Sharepoint has been built using the .NET framework and we can use that to get some more info. To do this, we need to go and change some settings in the web.config file that sits in the root of the web site in IIS. Even tough Sharepoint stores most of its information in the SQL Server content database, it still needs the .NET framework to process this information.
To find the web config file, we need to navigate to the "Inetpub" directory using windows explorer.
Under the "Inetpub -> wwwroot -> wss -> Virtualdirectories" folder, you will find sub folders representing each of the web applications used by Sharepoint including the system web applications. Each of these have their own web.config file.
Find the correct folder representing the web application causing the problem and edit the web.config file using your preferred text editor. I like using "Notepad" as it is "Light Weight" and does not have all the "Bells" and Whistles" I do not need.
There are two section that we need to modify in this file. The first section involves the "Call Stack" of the .NET framework. This will give us a list of all the assemblies involved in the error. This can be done by setting the "CallStack=True" flag.
The second thing that we need to do is switch the "customErrors mode=Off" so that the information will actually be displayed on the screen.
Once these options have been configured and the web.config file saved. We can then re-simulate the error and see what you get back.
As you can see, we now get a lot more information back that can potentially be used to help resolve the error. I did not say the information will be useful, I only said that you will have more of it.
Remember to change the web.config back to it's original state after you have resolved the error. This information should not be available publicly on the intra or Internet as this could be a potential security risk.
Related Blogs: