bdc2:// The parameter is incorrect. (Access denied by BDC.)

I got this error and spent hours on finding solution. Here is the list you need to check:

 

has the account ‘MOSS-RTM\Administrator’  actually got access to the SQL Server? MOSS-RTM\Administrator is the default content access account? If SQL Server is on a different server is this a domain account?

 also is  Office SharePoint Server Search Windows Service was running with the LOCAL SERVICE account.? This is what I failed even I gave db permission to the account

 

Local Server Farm cannot be detected.  This was the most common error we encountered while attempting to get Surfacting deployed on test systems came from security problems.  We found two causes for the following  screen which occurred during a crawl of the data:

1.       NT AUTHORITY\Local Service did not have permission to access to the <%SysVol%>\Windows\system32\drivers\etc\hosts file. 

 

2.       Once this problem was resolved, the screen persisted until we gave a real domain\user account the right to access content ( the default account is NT AUTHORITY\Local Service and this does not work. Check it by  
 Central Administration > Operations > Services on Server   ->
The Default content access account that is located in your ‘Configure Search Settings’ doesn’t have the correct permissions. There is a good chance that the password has either expired or someone has changed it recently.

Click on the user name on the Configure Serach Settings and make sure the user you enter has enough rights to access the content.

Note: Specify an account to use as the default account when crawling content. This account must have read access to the content being crawled. To avoid crawling unpublished versions of documents, ensure that this account is not an administrator on the target server.

And always check C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS. Search by Sort the files by Date Modified and open the latest one. There’s a good chance that you see something simular to Access Denied 

 

MOSS 2007 Business Data Catalog – errors when trying to crawl data

I’ve got a couple of posts coming up that will hopefully save you some time if you are experiencing errors when trying to crawl your BDC content source.

The first is to do with VarBinary(MAX) columns in SQL Server (these translate to System.Byte[] in your application definition file when created with BDC Meta Man). MOSS 2007 can’t crawl these column types and for some reason just errors when it tries to. You get a helpful error such as:

bdc2://8fc7f113-6ef8-4f74-8e79-efca15b79488/380…
The parameter is incorrect. (The indexer has encountered a field of type ‘System.Byte[]‘. This type of field is not indexable.)

I think you’ll end up with none of the table with these columns returned in your SpecificFinder method being crawled by MOSS. Only solution so far is to make sure the SpecificFinder method doesn’t return any System.Byte[] type columns from SQL Server. If you do want these columns to be returned you’ll need to create another method different to the SpecificFinder and make it a GenericInvoker method. More on how to do that in a future post.

 

The second error is to do with users who have been given explicit permissions to the BDC. These permissions are set at

Shared Service Provider -> Business Data Catalog Permissions

All is well and good until this user is deleted from the Active Directory. They remain in the BDC permissions list, and when you try to crawl your BDC data source you get an error of:

 

bdc2://65c462fb-8f81-45aa-ba85-198a0165b0d3/904…
The parameter is incorrect. (Could not create a security identifier for the identity ‘USB-SERVER1\testuser’. This identity may have been deleted.)

None of your BDC data seems to be crawled at all, so if you are doing a full crawl, you’ll get no BDC search results returned (which can be scary if they were coming back before!)

Simple fix for this is to just make sure you remove users from the BDC permission list if they are removed from AD or add the username into the permission. We hit this problem as we had a test user created in AD that we were testing permissions out with etc and when we removed him we hit the above error.

An unhandled exception occurred in the user interface.Exception Information: OSearch (Administrator)

I was getting this error while trying to start the Office SharePoint Server Search service on a standalone dev machine that I was configuring. The machine was not a part of any domain so I would just enter the username for the search account without the domain name. To solve this error one needs to provide the MachineName\AccountName for the search account to use

If you get Exception from HRESULT: 0×80040D23 when clicking Search Setting

Operations -> Service on Server -> Stop the Office SharePoint Server Search  and restart. Enter all information for new service. Make sure the Authorized user have permission on the search database

Then go to Shared Service 1 ->Search Setting