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:

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–Not able to remove an app…

Earlier this year I was playing around with Apps in SharePoint 2013 and deployed a app on one of my developer sites. Now a few weeks ago I noticed this early app experiments and wanted to remove it again. I was logged in as my farm admin (which is also a sitecollection admin to the dev site) and clicked remove… This is what happened:

AppRemovalProblem

This confused me a little bit, I did as the friendly message told me, refreshed the page and tried again… same outcome.

Next idea which came to my head was to give it a try using Powershell which you can find described pretty good at TechNet.

When I tried to remove the app using Powershell I experienced an error telling me:

image

When I cracked ULS viewer open I got some more details

System.InvalidOperationException: The System Account cannot perform this action.   
at Microsoft.SharePoint.Administration.SPApp.RegisterTasks(SqlSession session, Guid originalAppInstanceId, Guid paramSiteId, ICollection`1 tasks, SPAppJobOperation operation, SPUser jobCreator)   
at Microsoft.SharePoint.Administration.SPApp.RegisterTasksAndDependencies(SqlSession session, ICollection`1 tasks, ICollection`1 dependencies, Guid siteId, Guid instanceId, SPAppJobOperation operation, SPUser jobCreator)   
at Microsoft.SharePoint.Administration.SPApp.InstallNoPermissionCheck(SPAppInstance instance, Boolean isUninstall, Guid siteId, SqlSession session, Guid contentDatabaseId, SPUser jobCreator)   
at Microsoft.SharePoint.Administration.SPApp.Install(SPAppInstance instance, SPWeb web, String oauthAppId, Boolean alwaysOverwrite, Boolean isUninstall)   
at Microsoft.SharePoint.Administration.SPApp.Uninstall(SPAppInstance instance, SPWeb web)   
at Microsoft.SharePoint.Administration.SPAppInstance.UninstallInternal(Boolean adminOperationMode)   
at Microsoft.SharePoint.Administration.SPAppCmdlets.UninstallSP

AppInstanceCmdlet.InternalProcessRecord()   
at Microsoft.SharePoint.PowerShell.SPCmdlet.ProcessRecord()

With this knowledge I checked the details of the app:

AppDetails

And found the app being owned by another user which I used for developing (and deploying) the app.

AppDetails

When I logged in with this account and tried to remove the app… it worked.

 

AppRemovalSuccess

Cant get siteowner for readonly sites

This is something I stumbled across recently… I wanted to retrieve a specific type of sites and their owners, when I checked the output of my script I figured that some sites seemed not to have siteowners, which irritated me a little. So I went to Central Admin checked the sites in the “View all sitecollections” area and found owners assigned to the sites. After fiddling around with PowerShell I figured out that if your site is set read-only you cant retrieve the siteowner anymore.

In the below PowerShell window you can see that I get a site and retrieve the owner from it. After that I set the site to be read-only, when I now retry to retrieve the owner I don’t get any information back. Once I set the read-only mode to false again the retrieval of the siteowner is working as expected.

I noticed this behavior in a SharePoint 2010 environment first and reproduced it in a SharePoint 2013 environment (from which I took the below screenshots).

image

If you look at the site in SharePoint 2013 you will be notified about the read-only status of your site.

image

In my special case I worked around it by retrieving the sitecollection administrators as I just needed somebody to contact but if you are really looking for that owner (or secondary owner) you might want to put a little bit more logic to your scripts to handle read-only sites.

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:

image

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 Smiley.

So I went to Central admin >> General application settings >> Farm Search Administration

image

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.

image

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.

SharePoint 2013–March 2013 PU BCS database didn’t upgrade

This happened to me quite a while ago but I haven’t found the time to blog about it.

When you applied the March2013 PU (see here Stefan Goßners Blog post – about it and why you should apply it) it happened that your BCS database didn’t upgrade and was listed in central administration as a database for which additional actions are required.

To fix this open your good friend Powershell and do the following:

$bcsdb = Get-SPDatabase | where{$_.type -eq “Microsoft.SharePoint.BusinessData.SharedService.BdcServiceDatabase”}
$bcsdb.provision()

When you now check central admin you should find it marked with “no action required”

DISCLAIMER: If your farm gets broken by whatever reasons, don’t blame me. Don’t ever run scripts you just found on the internet on your prod environment, if you don’t understand what they are doing.

SPTechCon 2013 San Francisco

In a couple of days I will be travelling to San Francisco to attend SPTechCon 2013. I’m super excited to go.When I attended the conference the last time in 2012 I really enjoyed it and the people I met. The setting of the conference is a smaller one compared to the big Microsoft SharePoint Conference but this gives you a good chance to catch up with a lot of interesting people. So I’m looking forward to a great conference and hope to catch up with a lot of people of the SharePoint community. If you are attending SPTechCon and want to grab some lunch or dinner or just hang out and talk some SharePoint (or pretty much anything else) feel free to comment here or hit me up on Twitter @SPSoldier.