I found myself very frustrated earlier this week when I found that SharePoint search was not working. It wasn't returning any errors when you submitted a search. It just wouldn't provide any results.
After a quick glance at the error logs, I found I was getting an Event ID 2436 saying Access Denied:
Details: Access is denied. Verify that either the
Default Content Access Account has access to this repository, or add
a crawl rule to crawl this repository. If the repository being crawled is a
SharePoint repository, verify that the account you are using has
"Full Read" permissions on the SharePoint Web Application
being crawled. (0x80041205)
Naturally, I immediately checked my Web Application Policy to confirm that my Search account had Read Access in case someone inadvertantly removed it. However, it was still there.
After about half the morning of removing and re-adding permissions and resetting passwords and re-creating the index, I finally found several posts pointing at the .NET 3.5 SP1 update causing this problem. Sure enough, the update had been installed over the weekend.
Thankfully, this one was an easy fix that could be done on the fly. Open RegEdit and go to HKLP\System\CurrentControlSet\Control\Lsa and create a new DWORD value named DisableLoopbackCheck. Then, set the value to 1. Lastly, restart the WSS Search service and then run the following from a command line to initiate a full crawl:
stsadm -o spsearch -action fullcrawlstart
Within a couple minutes, search was back online and users were happy.
Mike Laurencelle
I'm a SharePoint & Server Systems Administrator for Sears Home Improvement Products, headquartered in sunny Longwood, Florida. My primary functions revolve around SharePoint and Virtualization technologies.
I've been in the IT industry now for about 18 years. For me, IT is more than a job to make a living, more than a career to call my own. It's my passion. I am a self proclaimed geek and have interest in all things technology. I can't imagine being in any other field - I absolutely love what I do.
I was recently having an issue after setting up MOSS where I kept seeing Event ID 7888 in the event logs.
Event ID 7888
Event Type: ErrorEvent Source: Office SharePoint ServerEvent Category: Office Server General Event ID: 7888
A runtime exception was detected. Details follow.
Message: Access Denied! Only site admin can access Data Source object from user profile DB.
Techinal Details:
System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB.
at Microsoft.Office.Server.UserProfiles.SRPSite.AdminCheck(String message)
at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(IDataRecord rec)
at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(String strDSName)
at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site, Boolean fAllowEveryoneRead)
at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site)
at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.GetDataSource()
at Microsoft.Office.Server.UserProfiles.BDCConnector.RefreshConfiguration(String sspName)
This turned out to be that the search account did not have all of the necessary permissions. If you are following best practices by using multiple accounts for different jobs within SharePoint, you may need to verify eactly which account is causing this error.
- Go to Central Administrator >> Operations tab >> Services on Server >> Office SharePoint Server Search.
- Click on "Configure Office SharePoint Server Search Service Settings.
- Locate the account listed under "Configure Profile Account" flr the "Farm Search Service Account"
Now you know which account to give the privilages to.
- Go to Central Administrator >> Shared Services >> Personalization Services Permissions
- On the "Manage Permissions: Shared Services Rights" page, make sure the account you found is listed with "Manage user profiles" rights. If it is not listed with this permission, add it.
After updating this permission, the Event ID 7888 problem should go away.
After the birth of my baby daughter two days after my last post, I've been a little preoccupied (see: sleep deprived) so many extra-curricular activities had to be cut. Now, as she is sleeping through the night allowing me to get a decent night's sleep, I'm getting back to normal and ready to start posting again!
As we've been moving more and more documents from network file shares into SharePoint, one of the things we realized pretty quickly that we had to work with our users on is the use of illegal characters in file names. Some jumped out at me right away as favorites that everyone loves to user like the ? question mark or # pound sign. There were others that came along occasionally but I wanted to find a complete list so that I could provide it to my users for some pre-move clean up work. So, after searching, I found this link on Microsoft's site that has a nice document on moving files from file shares into SharePoint. In the document, it points out the list of illegal characters. They are:
Additionally, I found that a lot of users accidentally have two periods between the file name and the extension. For example "myfile..doc" and apparently SharePoint doesn't like this either so the 2nd period has to be removed. This too is covered in the document along with a lot of other gotchas that I found out the hard way. I only wish I'd found a document like this one sooner. So, hopefully someone will find this document useful and it will give them some additional information to help make their file migration a little smoother.
http://office.microsoft.com/download/afile.aspx?AssetID=AM102437441033
1