Sharepoint Errors and Solutions

Internet Explorer cannot display the webpage (of a new web application).

​We've all done it. You create the web application in Central Administration and then immediately jump to the browser to admire your new site. But there's nothing there. This usually happens when you are trying to show someone how easy it is to provision a site with SharePoint.

Oops. We missed a step. You need to create a site collection before you will be able to see anything. Obvious, but you'd be surprised how often it happens during the quick demo under pressure.

Central Administration->Application Management->Site Collections->Create Site Collections. Don't forget to select the right web application.

Still not working? If you are using a port other than 80 you might need to check your firewall rules. Also you may need to configure DNS records. If you did that and it still can't resolve it, try doing an ipconfig /flushdns on the client.

Cannot connect to the configuration database

​This error message usually indicates a network connectivity problem between the SharePoint server and SQL Server machines. Check for network problems and firewall settings. These are the things most likely to have changed that our outside your control.

Check that your application pool account has permissions to the SQL Server database. Changes to the SQL Server configuration can also be a cause, and might have changed without your knowledge.

It can also be caused by the SQL Server database not running or offline. Check this by going to Services on Server and ensuring that the SQL services are running (MSSQL-----).

Access denied by Business Data Connectivity

​You have created an External Content Type, probably in SharePoint Designer. You have finally onfigured authentication correctly (after a couple of false starts - you have figured which account it is using to connect to the database, and you have configured the database to allow that account access to the correct database). You have created a list based on that external content type.

And still you can't see the data. You still missed something. Sheesh.

Oh, yes, of course. You need to go into your Business Data Connectivity Service Application, and set the permissions on the object. First, go to Central Administration->Application Management->Manage service applications. Find your Business Data Connectivity service application and go to the Manage page. Select the external content type and go to Set Permissions on the ECB menu, or the Set Object Permissions on the ribbon. From the Set Object Permissions pop-up dialog page you can add accounts and set their permissions. You will need to give the user who is logging in to SharePoint at least Execute permission to be able to see the list items. Note that this is nothing to do with the account that will access the database - that's another issue.

When you change these permissions it can take up to a minute before the behaviour changes as seen in the user's browser, particularly if the BCS service is running cross-farm. By the way, you only need to add the "Execute" permission to view the contents of the external list.

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

​This is what happens if you try to use pass-through authentication (also known as "User's Identity" when configuring the external content type in SharePoint Designer), and the database is on a separate server, and you are using NTLM.

With pass-through you are asking BCS to use the identity of the currently logged-in user to talk to the database (or other external system). This is not a bad strategy if you are giving individual users access to your database. The problem arises if the database is on another machine, because NTLM doesn't have the ability to pass the identity on (a process called delegation) and will instead try to connect to the back-end system anonymously. This is commonly known as the "double-hop problem".

There are a couple of ways around this. One is to implement Kerberos, which is nothing like as difficult to configure as some people suggest. But it isn't trivial. The other option is to use impersonation by making use of the Secure Store Service. The Secure Store Service can be configured either to cache a user's credentials (which means they will have to enter them again at some point when prompted), or you can configure a database access account and allow a group of users to use this account. The drawback of this second method is that you lose the audit trail of who did what in the database.

I suppose a third option is to use the trusted subsystem model and let the account running BCS have access to the database (sometimes referred to as RevertToSelf). This is okay for test and development systems but is probably not sufficiently robust security for production use.

The changes cannot be saved to the system definition, because the entered connection properties contain invalid values.

​RevertToSelf, so named because of the method call used to implement it, is an authentication method in which the identity of the process running BCS is used to access the back-end system (usually a database such as SQL Server). It is also known as "BDC Identity" in the dialogs of SharePoint Designer. This allows you to use the trusted subsystem model of authentication against a back-end system.

Whether you should do this at all on a production server is perhaps another matter for security experts to debate. Anyway, for whatever reason, that is what you are trying to do. Seems simple enough - what could possibly go wrong?

I turns out this is disabled by default (are they trying to tell you something?). To enable it, you need to do a bit of work with PowerShell on the server, thus:

$bdc = Get-SPServiceApplication | where {$_ -match "Business Data Connectivity"}

$bdc.RevertToSelfAllowed = $true

$bdc.Update

Cannot connect to the LobSystem (External System).

​Sometimes the message gets lost in translation. A colloquialism finds its way into the names of XML elements and error messages. What is a lobsystem? And what has it got to do with databases and external content types? I'm just visualizing a lobster. Then again, that may be because it's nearly lunchtime and I'm getting hungry.

So, presumably, the author of this message was thinking of a LOB System, where LOB is an acronym for "Line of Business". And some databases and back-end systems contain information connected with a particular business line, if the back-end system contains business data, and if the system is a business system at all. So the notion of an LOB System becomes somehow synonymous with any kind of back-end system that you are talking to using BCS. So it means you can't talk to the database. Aha! Thank you.

And the most common reason for not being able to get to the database, apart from someone forgetting to plug it into the network or switch it on, is permissions. And usually the database is SQL Server and we don't have permissions set up in SQL Server. Remember that the user account that needs access to the database will depend on the method used to authenticate. If you use pass-through or impersonation using Secure Store Service (individual) it will be the user's identity. If you use RevertToSelf it will be the BDC identity, which means the application pool account. If you are impersonating using a group account it will be the account you set up in the Secure Store Service when you set up the application.

You can quickly check for problems by going to the database server and looking in the application event log for the tell-tale SQL Server authentication errors. For a good article about dealing with this problem see this blog post.