Wednesday, May 1, 2013

SharePoint 2013: Distributed Cache Hosts in Farm Exceeds the Recommended Value

I am glad I am learning things simply by looking at the Health Issues in our new production environment. This morning I saw and interesting one stating that "The number of Distributed Cache hosts in the farm exceeds the recommended value."

Reviewing the issue showed the following:



 
The explanation, which is also the cause, stated that every machine on the farm has the Distributed Cache service started. Although this occurs simply by installing SharePoint 2013 and adding servers to the farm, I didn't realize that not every server should be running this service. I associated the Distributed Cache with AppFabric in my head and just assumed that each server needed it.
 
The summary of the problem is stated as "On a farm with four or more servers, you must not start the Distributed Cache service on all servers on the farm. If you configure all servers as cache hosts, you may experience reliability and performance problems in the farm." (Reference here)
 
It turns out that you actually need to remove the service from the servers that shouldn't run it - not stop it - actually remove it. This can be peformed using the SharePoint PowerShell cmdlet Remove-SPDistributedCacheServiceInstance :
 

You simply run this command on each server that doesn't need to run the Distributed Cache service. There is no output from the cmdlet but now when you review the Services on Server for the selected server, the Distributed Cache Host is no longer listed:



Since it not recommended to run on an application server running Excel Services, I removed it from that one. I also removed it from my main search application server.

I recommend reviewing Plan for feeds and the Distributed Cache service in SharePoint Server 2013 as well as the other related material linked within that post.



Friday, April 26, 2013

SharePoint 2013/2016: SQL Partition Exceeded Max Bytes

We noticed on one of our new application servers that the event log had multiple errors stating:

Table SqlIoData_Partition18 has 442900480 bytes that has exceeded the max bytes 442857142


From the Task Category, notice that this is coming from the Usage Infrastructure. The root cause was that we were collecting too much usage data and most of it was probably unneccessary.

To throttle the usage collection, from Central Administration click on Monitoring from the quick launch:



On the Monitoring page, click on Configure usage and health data collection:

Notice the important info here..."..but also uses system resourcs and can impact performance and disk usage". Crap. I don't need all that. Simply uncheck items you don't care about and only have several items checked:


If you are like me you probably don't know what half these things are anyway. Here are the events that I kept checked:  (click on the image for a larger view)

The text on the page gives us a little helpful hint. Enable the events you need to investigate issues and then disable them after the investigation is complete.

No more max bytes errors in the event log anymore!

UPDATE 5/1/2013: I spoke too soon. Apparently leaving the SQL IO Usage produces a large amount of usage data. I had more max bytes errors this morning. This is with just a handful of us on the new production servers. I unchecked SQL IO Usage and SQL Latency Usage. Eventually I'll probably be down to just Page Requests being checked.

UPDATE 9/18/2013: After applying the SharePoint 2013 updates and enabling Usage for Page Requests, I still encountered this error. Seems like the root cause and potential workarounds are explained here: http://blogs.msdn.com/b/sharepoint_strategery/archive/2012/04/16/usage-file-and-web-analytics-reports-with-blind-spots.aspx

Thursday, April 25, 2013

SharePoint 2013 Search: Removing the Junk from your Search Trunk

Have you ever noticed how much nonsense or irrelevant results come back from various search queries? It's nobody's fault. The content is out there and happens to match the terms we are searching. But do we really need all of this stuff if it's not useful?

I have been recently fine-tuning what comes back in search results. People want content. They don't want containers of content, lists of content, links to content - just plain results they can use. Therefore, I have tweaked my main results to perform the following:

  1. Remove excess external content type links and nonsense
  2. Remove Folders from search results
  3. Remove overall list results (AllItems.aspx)
  4. Remove Link List Items
  5. Remove Link Lists
  6. Remove Explorer Views (web folder results)

I only performed these tweaks on my main results page (a.k.a. Everything) by modifying the query on the Search Results web part:


 
 
External Content Type Nonsense
Even though I created custom Result Sources and Result Types for some of my external content data (aka BDC/BCS stuff), I noticed I would still get crazy bdc3:// results back. This was the first thing I removed:
 
Folders
I noticed folders being returned, which may be correct, but we want content - not the containers of content. I opened one of my folder results and it brought me to a list of --- more folders!! Ahh. We don't need that. Therefore I added another property filter as follows:
 


 

 
Full List Results (AllItems.aspx)
How many search results show the AllItems.aspx view?? In some queries it's every result. We just need the list item itself, not the full list of irrelevant items. Therefore I decided to filter that out too:


Links List Items
We happen to use many lists of links to display items on various department, office, or home pages. They are convienent and provide an easy way to add a new link to a page. However, for search results, we want links to the main content, not links to links to content. For this I needed to add a filter using the contentclass property:

Links Lists
Removing the link items was good but now the entire links list is being returned in results. Might as well remove that too:


Explorer View
Finally I noticed web folders correlating to Explorer Views of lists being returned. There is no need to gunk up the results with various views. Therefore I filtered these out as well using the secret STS_List_850 contentclass:

My final query text?

Here is what I have so far to get all of the junk out of my search results:


Conclusion
I am getting cleaner results with mostly documents, posts, relevant list items, calendar items, etc. I am starting to feel much better with the improvement on our relevancy.
 
Search on!!!
 

NOW AVAILABLE!!!

 

Monday, April 22, 2013

Stemming in SharePoint 2013 Search

Stemming essentially performs searches for words that share the same stem. Stemming in SharePoint 2013 is enabled by default and although it can be disabled, there is no UI option in the Search Results Web Part anymore. In addition, the EnableStemming property in the object model is also deprecated.

To disable stemming you need to:
  1. Export a Search Results Web Part
  2. Open the file in a text editor
  3. Set the EnableStemming property to false ("EnableStemming":false)
  4. Save the file
  5. Import the web part back onto the search results page
  6. Remove the existing web part from the search results page

While classic examples of stemming are explained as “run” and “ran” as well as “writes” and “wrote”, the results I am seeing are not so. The behavior I am experiencing in SharePoint 2013 is mostly plural and singular versions of words. For example “party” also presents results for “parties” (and vice-versa). “Search” is providing hits on “search” and “searches” but not “searcher”. I am not seeing "wrote" hits when I search for "write" nor do I see "ran" results when I search for "run".
Since there is no longer support for third-party stemming tools (and thus the previous registry entries are no longer used), the workaround to all of this is to include any additional stemming as synoynyms in a thesaurus file which may be loaded into SharePoint via PowerShell commands.

I have crawled 100GB of content so I should have a great sampling of words. Has anyone seen anything different with stemming?






Tuesday, April 9, 2013

SharePoint 2013: Dashboard Designer Not Showing Databases from Analysis Services - Resolution

Scenario
Currently only 1 WFE
PPS Service running on 1 Application Server
Unattended Service Account entered via the PPS Service Application
Same service account belongs to a Role in SSAS (2012) with Read permissions on a cube
BI Center Site Collection created


Problem
Launch Dashboard Designer
Create New Data Source from Analysis Services
Enter Analysis Services Server
Database drop-down shows Loading... but then nothing appears in drop-down list.


Resolution

  1. Install  Microsoft® SQL Server® 2012 ADOMD.NET and Microsoft® Analysis Services OLE DB Provider for Microsoft® SQL Server® 2012 from the Microsoft® SQL Server® 2012 Feature Pack on the WFE and the server running the PPS Service
  2. Install  Microsoft® SQL Server® 2008 R2 ADOMD.NET and Microsoft® Analysis Services OLE DB Provider for Microsoft® SQL Server® 2008 R2 from the Microsoft® SQL Server® 2008 R2 Feature Pack on the WFE and the server running the PPS Service
  3. IISRESET on the WFE and the server running PPS.
  4. Refresh the BI Center Site Collection
  5. Launch Dashboard Designer again from BI Center Site Collection
  6. Enter SSAS Server Name
  7. Database drop-down loads with the databases now!


I wouldn't be suprised if I need to install ADOMD.NET on any new WFEs that I build out but I will update this post when that time comes.

UPDATE 5/28/2013: I built out a new WFE and suprisingly I did not have to install ADOMD.NET. Everything appears to be working correctly.



 
 

Matched Content