1

Currently running into some errors when trying to setup External Content Types with SharePoint 2010. The goal is simple which is to connect to a SQL Server and pull information into SharePoint to an External List. The server setup is 1 SQL Server, and 1 Web Front End. I have created a Secure Store Service Target application ID and given it Windows account credentials, as well as a SQL account. Setting up the ECT in SPD connects to the database just fine with the given Target Application ID and I am able to create permissions and save the ECT. After this I create an External List and browse to it in SharePoint, it then prompts with the "Cannot connect to LobSystem" error.

External Content Type list attempts to connect to the SQL Server but fails with this message:

Cannot connect to the LobSystem (External System).

The SPN's are setup for both SQL server and each application pool account.

The SharePoint server logs the following message:

Could not open connection using 'data source=SQLServerName;initial catalog=DatabaseName;pooling=true;persist security info=false;user id=TARGETAPPID;password=**' in App Domain '/LM/W3SVC/1695757697/ROOT-1-129640094970601303'. The full exception text is: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

The SQL servers port is not default, and I am wondering whether this may have something to do with the error messages I am getting. Where would the aliasing settings be? I have tried to connect with the aliased name of the SQL server; however, SPD cannot find it. Any guidance is greatly appreciated. I have read 3-4 pages in on Google with the "LobSystem error" term, none of the information is helpful.

Improve this question

2 Answers 2

Reset to default
1

Alias settings can be found on the servers by running cliconfg.exe on the SharePoint server.

Improve this answer
5
  • I have been able to successfully connect with the SSS through using a SQL account after configuring in SPD with the proper aliased server name (case-sensitive). I am now getting a "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'." message when using "Users Identity" for authentication. I have full permissions to the database (note this is with using the aliased server name). The SQL server has been configured to use just Windows authentication.
    – Erik M
    Commented Oct 25, 2011 at 19:43
  • Are you trying to access this from an anonymous public facing site? I have had this problem with those sites, and you have to use revert to self and a data view web part to truly reveal external content anonmyously. I have a link for instructions on this if this is the case.
    – Lori
    Commented Oct 25, 2011 at 20:20
  • I am trying to access it within an Intranet site, we have 2 domains setup. I think we have pin pointed it to being related to that as when my co-worker or myself login we get the "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'." message, and my other co-worker will be allowed access(once granted on the database) since his username is on the proper domain the servers are on.
    – Erik M
    Commented Oct 25, 2011 at 21:02
  • That is very possible. You might consider using authentication with the application pool ID "revert to self" for SQL and granting or removing permissions to the ECT in the Business Data Connectivity Service and through the External list permissions. This could bypass this issue.
    – Lori
    Commented Oct 25, 2011 at 21:25
  • Thanks Lori, we have decided to use the Secure Store Services with an SQL account, instead of changing up how our domain is currently configured. SQL authentication passes all information encrypted so I think this will do the trick.
    – Erik M
    Commented Oct 25, 2011 at 22:27
0

Based on your first post you talked about using secure store mapped to a windows credentials Since you mentioned secure store I'm assuming you configured authentication type on ECT to be Impersonated windows identity since you mentioned SQL not being on different port configuring alias using SQL Server Client Config Utility should help with the initial error you were getting Later in your response you mentioned you configured authentication type on ECT to be "UsersIdentity" Did you not want to use Secure Store ? if you are using UsersIdentity otherwise pass through you have to use kerberos constrained delegation for it to work its pretty clear from the error message you mentioned since NTLM can't delegate users credentials to SQL in this case, falls back to anonymous See this post http://www.spmcm.me/Blog/Lists/Posts/Post.aspx?ID=38 if you download the presentation each authentication option is explained in detail there

Hope that helps

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.