The SharePoint item being crawled returned an error when attempting to download the item…
I just came across this one with one of my SharePoint 2010 customers.
They were facing this error message in their crawl log for 3 lists and couldn’t figure out what’s the issue. When they tried to browse the list everything looked fine, except for that the view was a access based datasheet view.
So we started looking into this issue by drilling into the ULS logs and found the following:
CSTS3Accessor::Init fails, Url sts4s://yoursite/siteid={GUID}/weburl=yourweburl/webid={WebID}/listid={ListID}/viewid={viewI}, hr=8004FD0F [sts3handler.cxx:312] d:\office\source\search\native\gather\protocols\sts3\sts3handler.cxx
We also checked the IIS logs on the crawl target server and found the request for this particular element in the IIS log returned a 200 OK.
One of the first things you will find on the internet when searching for this issue, is to check the useragent settings on your crawl servers which you can find in the registry of the box under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager\UserAgent
The common statement is to update the user agent string, or at least the Internet Explorer (MSIE) part of it, to represent a more up to date user agent. (Out of the box it shows version 4 – which we also could see in the IIS logs of the crawl target).
So we gave this approach a shot and changed the registry values, rebooted the servers and started a full crawl… and after all those steps we felt pretty confident to get rid of those errors… but after the crawl was done when we checked the crawl log, for sure the errors still persisted.
So after checking one more time that we had all the registry keys done right we cranked up verbose logging for search ready to start drilling deeper into the issue. Unfortunately the ULS logs turned out not to be of great help.
So we went to the crawl server and tried browsing the page again, even looked at the zone settings and everything looked just fine.
On the edge of desperation we came up with the idea to login as the search crawl account and try to browse the page and BOOOM here SharePoint is screaming at us with a nice big error message, which basically told us that the list has exceeded the threshold for lookup columns (which out of the box is set to 8).
This Access WebDatabase had 16 lookup columns. So for testing purposes we changed the threshold in central admin to be 17 and started a incremental crawl and voila all our crawl issues disappeared from the logs. Obviously this should not be the final fix and my customer agreed to change the design of the list to reduce the amount of lookup columns. But at the end the crawl logs in SharePoint told us the truth even though as so often they didn’t tell us the whole story…
Hope it helps.
UPDATED: Gigantic Config DB… why… and how to get it back to normal
It has been pretty quiet around here but I’m trying to get some content up every now and then…
This was an issue I encountered recently with one of my clients. Their configuration datbase has grown up to 43GB and they couldn’t get it back to normal size which according to this TechNet Article is definied as small (~1GB) in size.
The first thing I have done to drill down into this issue was to open the disk usage by table report for the database within SQL management studio. This report showed me at the first glance that the timerjob history table size was very huge. Usually the timerjob history gets cleaned by a timerjob called “Delete job history” which by default runs every week
The next thing was to check the timerjob history in Central Admin and look for the last runs of this particular timerjob. And here I found the job failing for multiple weeks. When checking the error message it was pretty clear, the timerjob failed because the transaction log of the config db was full!!!
The next step was to check the settings for the transactionlogs in SQL server management studio and here I found the size of the transactionlog limited…After setting the size of the transactionlog to unlimited and running the timerjob the timerjob history table in the disk usage by table report shrunk back to a normal size and the database size could be normalized back to less than 1GB.
UPDATE:
A good friend of mine Paul Grimley contacted me about this blogpost and highlighted that it would be helpful to update this article with some general guidance on database maintenance for SharePoint. Especially guidance on how we got the database size in the above described scenario back to normal.
In general I would recommend this TechNet article on SharePoint Database maintenance. It is for SharePoint 2010 but still valid for 2013. It also gives particular guidance on how to shrink data files.
Also I would like to share some articles Paul pointed me at which look at this topic from a supportability perspective:
- Support for changes to the databases that are used by Office server products and by Windows SharePoint Services (Please read this one very carefully!!!)
- Database Maintenance for Microsoft SharePoint 2010 Products
Plus extra Kudos to Paul for checking the delete history timerjob on his environment – which lead us to identify that the schedule of the timerjob has changed from weekly in SharePoint 2010 to daily in SharePoint 2013.
Hope this helps…
SharePoint 2013–Missing serverside dependencies
This health-analyzer warning popped up from time to time in SharePoint 2010 environments as well. So when I encountered it the other day I had already an idea on how to handle this.
This is what I saw in SharePoint Central admin:
The error message is not telling you that much usually I would use the webpart ID provided and figure out which webpart is referenced by using Powershell, but this time I just guessed 
.
So I went to Central admin >> General application settings >> Farm Search Administration
In 2010 clicking this link had the consequence that the error vanished from the health analyzer. So I refreshed the health rule and… found another error appeared instead.
[MissingWebPart] WebPart class [8307a780-2546-f10b-551f-0e692d0fce39] (class [Microsoft.Office.Server.Search.WebControls.SearchApplicationShortcutsList] from assembly [Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]) is referenced [1] times in the database [DBName], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [DBName], but are not installed on the current farm. Please install any feature or solution which contains these web parts.
[MissingWebPart] WebPart class [63104819-a32f-88b6-ab4a-7bbd4fbb40e8] (class [Microsoft.Office.Server.Search.WebControls.FarmSystemStatus] from assembly [Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]) is referenced [1] times in the database [DBName], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [DBName], but are not installed on the current farm. Please install any feature or solution which contains these web parts.
[MissingWebPart] WebPart class [9328cc53-be2c-1cca-f310-ddd573a106a5] (class [Microsoft.Office.Server.Search.WebControls.FarmSearchApplicationList] from assembly [Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]) is referenced [1] times in the database [DBName], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [DBName], but are not installed on the current farm. Please install any feature or solution which contains these web parts.
[MissingWebPart] WebPart class [4465f30a-0604-4d3c-39fd-ecdb8812f3f3] (class [Microsoft.Office.Server.Search.WebControls.SearchTopologyOverview] from assembly [Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]) is referenced [1] times in the database [DBName], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [DBName], but are not installed on the current farm. Please install any feature or solution which contains these web parts.
[MissingWebPart] WebPart class [a9bc1035-cf56-e003-8a4d-fff0bb3da148] (class [Microsoft.Office.Server.Search.WebControls.SearchApplicationSystemStatus] from assembly [Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]) is referenced [1] times in the database [DBName], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [DBName], but are not installed on the current farm. Please install any feature or solution which contains these web parts.
This gives you something to read at least.
What jumped right into my eye is that all referenced controls are related to search. So I jumped to the Search Service Application, where I found everything working as expected.
The reference “WebControls.SearchApplicationShortcutsList” pointed me to the little shortcut list in the right hand corner of the service application config site.
I clicked both links listed below and when I refreshed the health analyzer rule it was gone.
So I think the lesson learned from that is that you can fix this particular issue (missing references in the Central Admin contentdatabase) in almost the same way as you did in SharePoint2010.
List Threshold and Search crawl error–The Site cannot be downloaded
After doing a migration from SharePoint 2007 to SharePoint 2010 for one of my clients I experienced a funny Search crawl error. My client had a webpart on their SharePoint 2007 environment which displays the recently changed documents on the site. Everything was working just fine in SharePoint 2007 and the migration to SharePoint 2010 was running successfully as well.
Once we configured a search crawl to index the content we encountered several issues in the crawl logs telling us that the site can’t be downloaded and for that can’t be crawled.
After we ensured that the crawl account had appropriate permissions on the webapplication I used a little move I pull from time to time to troubleshoot searrch crawl issues. I logged in as the crawl account and we found that when the crawl account accesses the site a threshold error gets thrown which tells us that the webpart is exceeding the allowed threshold of 5000 items (default setting for the webapplication).
You can adjust the threshold in the webapplication general settings in central administration I would not recommend it though because you open up the door for very severe performance issues within your environment. Rather I would recommend to rethink the way you query your data from SharePoint to be more performance efficient.
My client was using his account with administrative privileges to verify if everything was working as expected after the migration but for this account the threshold will not be applied. The crawl account just has read permissions to the content and for that wasn’t able to crawl the content due to the threshold.
After removing the webpart from the site(s) crawling was just working fine. The webpart will need to be replaced by one beeing a little bit more aware of the threshold in SharePoint 2010 
.
Farm provisioning issues
During my work onsite with a client I faced an interesting issue which I think is worth mentioning here. After the SharePoint binary installation the SP2010 farm gots provisioned and we were about to join the other servers into the farm (connect them to the created configuration database). On one of the machines though we found a hotfix for a specific language pack missing. But somehow this server was joined the farm, on the “Servers in farm” site you could find a note that this server is missing an important update. The patching overview in the SharePoint central administration displayed the missing hotfix as well. So we downloaded the hotfix, installed it on the machine and thought about running the configuration wizzard to properly connect the server to the farm again. When it comes up to running the configuration wizard we encountered an error within the wizard telling us that the hotfix we just installed is not installed on the system. Our first approach was to reboot the machine and rerun the SharePoint configuration wizard again… Same result. Bummer!
Then I thought, ok we remove the server from the farm and join it back in again, removing a server from a SharePoint farm can be done in several different ways,
- using the SharePoint configuration wizard… ehm, not in this case!
- using the central admin
- using good ol’ psconfig.exe
- The way described below 🙂
Because number one was not applicable I removed the server from the farm using the central administration, but when running the SharePoint configuration wizard it still locked to be connected to the farm somehow and it failed running.
Because you cant trust the UI, I removed the server using psconfig.exe (psconfig -cmd configdb –disconnect), which told me that the server has successfully been removed from the farm. But when running the SharePoint configuration wizard the same issue occured and it failed out at the end.
So I said to myself: “Self…we have a problem here”, shortly before starting to cry and thinking about how to get out of the room and run away the SharePoint admins swiss army knife PowerShell came to my mind and I remembered an powershell cmdlet “Disconnect-SPConfigurationDatabase”. I ran the cmdlet and when firing up the SharePoint configuration wizard I now saw the option to join an existing farm or create a farm myself. I joined the server to the existing farm and… it worked just like a charm.
EventID 10016 – The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
When you install SharePoint2010 you might encounter some kind of the following Error in your Eventlog
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{GUID}
and APPID
{GUID}
to the user Domain\AccountName SID (SID) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.
When you now try to grant the GUID Application DCOM permissions in the dcomcnfg you will find yourself not beeing able to modify the properties (at least when you are running Windows Server 2008 R2).
To be able to modify the properties you first need to grant your account permissions in the registry:
Find the key: HKEY_CLASSES_ROOT\AppID\GUID
Right click and select properties, on the security tab you grant your account full control permissions.
Now you can use the dcomcnfg to modify the permissions to get rid of the error.
Please be aware: manipulating your registry is done at your own risk, don’t blame me if you screw up your system.
EventID 1004 – C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe’ does not exist
During my daily work I face a lot of SharePoint related errors, blood red eventlogs or even some warnings, which color logfiles in colors they are not supposed to have.
Like this little warning right here occurring in your system eventlog: EventID 1004
Detection of product {GUID}’, feature ‘PeopleILM’, component ‘{GUID}’ failed. The resource ‘C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe’ does not exist.
This one can be resolved easily by granting the Network Service permissions to the folder “C:\Program Files\Microsoft Office Servers\14.0\Service”
Insufficient Database permissions – proc_GetProductVersions \ EventID 5214
After applying SharePoint2010 Service Pack 1 and the republished June CUP I encountered a strange error in the eventlog.
“Insufficient SQL database permissions for user ‘Name: <user id> SID: <GUID> ImpersonationLevel: Impersonation’ in database ‘SharePoint_Config’ on SQL Server instance ‘<DB Server>’. Additional error information from SQL Server is included below.
The EXECUTE permission was denied on the object ‘proc_GetProductVersions’, database ‘SharePoint_Config’, schema ‘dbo’.”
After a little bit of investigation I figured out how to reproduce the error.
- Click on a SharePoint site the SiteActions menu
- Click “New Site”
- When the silverlight menu opens the error gets written into the eventlog. The enduser is not affected by the problem but you end up with an critical event in the eventlog.
I found it interesting that the user id gets written into the eventlog and not the application pool ID. Also the error only occours when using the silverlight enabled create new site dialog.
I opened up a call with the Microsoft premier support and they could reproduce my error as well in their environments.
The support engineer added a defect to the bugtracking database and confirmed the following workaround:
- Connect to your DB Server where you host your SharePoint configuration database.
- Open the SQL Management studio
- Expand the SharePoint configuration database
- Navigate to programmability\StoredProcedures and select the stored procedure “dbo.proc_GetProductVersions”
- Right click the stored procedure and select properties
- Select permissions
- On the new popup screen, click Search, select [WSS_Content_Application_Pools] database role and click OK.
- On the first popup screen, select the role, check Execute permission and click OK.
Also you can shorten this steps by running the following SQL command:
USE DBName
GRANT EXECUTE ON OBJECT:dbo.proc_GetProductVersions TO [Domain\AppPoolUser]
Go
Unfortunately I don’t know when Microsoft will implement a fix for this issue.
SharePoint Soldiers 