SharePoint 2010/2013 Content Query Web Part..Please Open in Office Web Apps..Ugh, I loathe you right now

First off, thank you very much Ben Prins for getting me moving in the right direction on this one – www.benprins.net/2014/05/19/sharepoint-2013-cqwp-office-online-hyperlink

Here’s the scenario: A client was looking into rolling out Office Web Apps as the default open behavior for documents in a recently upgraded SharePoint 2013 farm (Started as a 2007 farm and upgraded to 2010 and 2013 throughout the years). Cool right? Follow this document (https://technet.microsoft.com/en-us/library/ee837425.aspx) and turn off OpenInClient and you should be rocking and rolling in the deep with those web apps..

Everything was looking great except throughout the site they were using content query web parts #CQWPFail. Content query web parts have their place and this client did not want to revamp a ton of pages and replace them with the shiny new SharePoint 2013 search web parts (The CSWP can span site collections like a boss, but the CQWP is pretty simple/easy to configure if you’re just looking at one site collection..unless XSLT is involved. Keep reading..). The content query web parts had no honor..they refused to acknowledge the OpenInClient setting. Not cool CQWP…

Since this was an upgraded SharePoint site as a troubleshooting step we create a brand new “Vanilla” SharePoint 2013 site collection and did a quick test. These CQWP’s seemed to have a little more honor..If the query was set to a specific list/library it would open in the web app. If the query was set to a site collection/site level..it would try to open in client. Unfortunately that was the entire reason the client wanted to use CQWP’s back when they set it up in 2010..to cross sites and surface documents using custom content types.

I think you know where this is going…time to brush up on those XSLT skills. After some research I found this page which states the files used for the CQWP: https://msdn.microsoft.com/en-us/library/office/bb447557(v=office.14).aspx I did a (insert favorite file comparison tool here..I used WinMerge) against these 2 files (Comparing the 2010 upgraded site to the vanilla 2013 site):

  • /Style Library/XSL Style Sheets/ContentQueryMain.xsl
  • /Style Library/XSL Style Sheets/ItemStyle.xsl

What do you know??…there were differences. We updated the 2010 upgraded site’s ContentQueryMain.xsl and ItemStyle.xsl files and now at least queries directly to lists/libraries started working.

After this I found Ben’s awesome blog post and ran through the steps on there (I did have to make a few changes so I’ll post my detailed steps and I posted comments on his blog):

  1. Crack open that ItemStyle.xsl file (I checked it out first and then opened with NotePad)
  2. Right underneath this line (Since we’re editing the default style…you could create you’re own, but we wanted to update all existing web parts without too many changes)

<xsl:template name=”Default” match=”*” mode=”itemstyle”>

Paste the following lines:

  • Some things to note about this:
    • ?web=1 is what forces the document to open in Office Web Apps. Pretty nifty..instead of using a hard-coded link to WopiFrame.aspx and trying to parse the LinkUrl field..which I tried and failed because the URL passed to WopiFrame.aspx must contain be in this format: http://webappurl/sites/sitecollectionurl/siteurl/_layouts/WopiFrame.aspx?sourcedoc=/relative path to file
    • Feel free to add additional entries for doc/xsl/ppt
  1. After this I found the <div class=”link-item”> and updated it with this code:

Check these guys out:

2010 Fails on ALL Queries:

clip_image002

2013 is a little better..but falls short when a query is set at the “site level”

clip_image004

Here’s the site collection with the updated XSLT (Check out that sexy hyperlink at the bottom!)

clip_image006

Cool Stuff. Also another plug for Ben Prin’s blog…check out this post: http://www.benprins.net/2012/05/20/show-all-fields-and-values-with-xslt/

The XSLT snippet from this post allows you to see all fields and values that are available..which was super useful in troubleshooting.

SharePoint 2013/2016 Cloud Hybrid Search Service Application

I ran through the setup of the new SharePoint 2013/2016 Cloud Hybrid Search Service Application and wrote about it on the Skyline blog! Definitely an exciting new service and the best hybrid search experience to date..

http://www.skylinetechnologies.com/Insights/Skyline-Blog/October-2015/SharePoint-Cloud-Hybrid-Search-Service-Application

SharePoint 2013 – Search Index Component Stuck in Degraded (Yellow) State

I read many posts about this, but none had my solution so let’s get into it. Oh the infamous yellow triangle! One of my Index Components was in a degraded state. First off, I logged into the server to make sure disk space wasn’t the issue. There was loads of disk space. I then tried the following:

  • Restarted SharePoint Server Search 15 Service
  • Cleared Config Cache
  • Reset the Index and ran a full crawl of all content

Some sources day a server reboot would fix the issue, but that’s no fun. I did some digging and found that restarting the SharePoint Search Host Controller Service fixed the issue in this case.

-AJB

SharePoint 2013 – “2010 Mode” Site Collection Search Scopes

One migration tidbit to note when going from 2010 to 2013. Search scopes are contained in the Search Service database..NOT the content database. This means that if a site heavily relies on search scopes..and you are choosing to keep this site in “2010 Mode” (Not generally recommended, but sometimes makes sense) then you will need to upgrade the Search database as well. This is because sites running in “2010 Mode” will use existing scopes, but you cannot create new search scopes after the content database is upgraded to SharePoint 2013. Side Note – If this site collection is upgraded to SharePoint 2013 then you can use the fancy shmancy new result sources.

The search database can be upgraded using the following PowerShell cmdlet:

Restore-SPEnterpriseSearchServiceApplication

More about this cmdlet here: https://technet.microsoft.com/en-us/library/ff608131.aspx

This process is rock solid…kind of. It doesn’t give you GUIDs, but the search database names are in the following format:

  • <Search Service Application Name>_AnalyticsReportingDB
  • <Search Service Application Name>_CrawlDB

I had a DB naming format and this did NOT work for me. The search Admin DB (The one I restored) was renamed as I went through the SQL backup/restore process so it had the naming down. I used the process described here to get everything nice and clean: http://www.andrewjbillings.com/sharepoint-2013-foundation-creating-the-search-service-with-powershell-and-removing-those-pesky-guids/

Search database names were clean..search scopes were showing up. Life is good

SharePoint 2013 – Crawling a “2010 Mode” Site Collection

Working on an upgrade project we decided to keep a SharePoint site (highly customized) in 2010 mode for the time being. First, here is the list of items that will not function while the SharePoint site remains in “2010 compatibility mode.” This is because the features were deprecated/removed and replaced with new/different services and functionality.

Please see the entire list at this official Microsoft link: https://technet.microsoft.com/en-us/library/Ff607742.aspx

Feature Replaced by in SharePoint 2013
Search Scopes Result Sources
SharePoint Web Analytics Reports Analytics now built into Search Service Application

*I remember reading about workflows experiencing intermittent issues in 2010 mode (As described here: http://en.share-gate.com/blog/not-working-after-sharepoint-migration-to-2013), but there is no official documentation stating this fact and it all depends how customized the workflow is.

After getting the search scopes migrated and showing up in the search scope admin area of site settings I noticed no results were coming in. The SharePoint site was added to the default content source in search which is for crawling SharePoint sites I tried giving it its own content source with type SharePoint Site and still no-go. After changing the content source to type Web Site everything was rocking and rolling..

-AJB

SharePoint 2013 – Search Service Application Not Provisioning Correctly After Server Rename

OK so here’s a fun one! I had a server that originally had SharePoint installed on it and the server was eventually renamed. After the rename I went and re-installed SharePoint because the new environment was to have a new name, use new service accounts, and have a different database naming scheme. After re-installing the SharePoint bits and running PSConfig almost everything was working correctly…Search on the other hand was not able to provision. I was getting the following error consistantly in the eventvwr application log:

The Execute method of job definition Microsoft.SharePoint.Administration.SPServiceInstanceJobDefinition (ID 7588c6ba-6e23-4712-aff4-8c1f53d2d4ec) threw an exception. More information is included below.

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

I checked folder and registry permissions and other than the fact that both the old service accounts and new service accounts were applied, everything seemed fine. I was not able to start the search service instance on this single server environment until I ran the following stsadm command:


SharePoint 2013 Foundation – Creating the Search Service with PowerShell and Removing those Pesky GUIDs

I found this awesome PowerShell script on Gary LaPointe’s blog and decided to give it a try. This essentially mimics the SharePoint Configuration Wizard, but it gives you the power to use PowerShell! Below are is my experience with this script and how I went about removing the GUIDs from the database names.

Note: This bases the DB Server off of the default DB Server specified in Central Admin (Can be change using PowerShell Later) and it results in databases with GUIDs at the end, but we’ll remove those later :). Obviously change the Managed Account and App Pool names to fit your environment.

This will result in a default topology, but there are GUIDs..yuck! If GUIDs are unacceptable there is a method of renaming Search Service Databases on http://technet.microsoft.com/en-us/library/jj219654.aspx. I went ahead and tried this out.

1. Run the following commands to suspend the search service

2. Now Go into SQL Server Management Studio and set each Search DB to Read-Only Mode (Accept the message to close existing connections). Right Click Database | Properties | Options. Set Read-Only to True

3. Perform a copy-only backup of each Search Database

4. Detach all of the old databases

5. Restore each database backup (Change Restore to File Names so there are no GUIDS in the MDF and LDF files)

6. Right Click Each Database and Rename (Had a pain with Admin DB. I ended up detaching and reattaching with new name)

7. Restore the old databases (Delete MDF and LDF Files first! May need to close out SQL Mgmt Studio).

8. Use PowerShell to point the Search Service Application at the renamed databases

9. Delete the old Databases with GUIDs

Check it out!
clip_image002

 

Edit: As Tuppence pointed out below there is now a way to set this up from the get-go. Check out this link: http://www.funwithsharepoint.com/provision-search-for-sharepoint-foundation-2013-using-powershell-with-clean-db-names/

Creating a SharePoint 2013 Index Component – PowerShell Bug

After setting up SharePoint 2013 Search with David at Trek Bicycles we encountered a bug with the PowerShell cmdlet:

When using the –RootFolder parameter to specify where you want the index location (For Example: C:\SPSearch) to be you must have the folders created ahead of time. After creating the folders on the servers where you are creating the index components on, you will still received the error message “New-SPEnterpriseSearchIndexComponent : Cannot bind parameter ‘RootDirectory’

The cmdlet does a check not only on the servers you are creating the index component on, but also on the server where you run the PowerShell script (in this case the app server, which will not have any index components at this time). After creating the folders on the app server it will create the index partitions successfully, even though nothing was/should be written to that folder.

This is described at the bottom of this blog post: http://blogs.msdn.com/b/chandru/archive/2013/02/19/sharepoint-2013-configuring-search-service-application-and-topology-using-powershell.aspx

Using Fiddler2 as a proxy for SharePoint Search

I was looking for a way to troubleshoot search crawl errors a little bit better and figured why not use a tool I already use daily…Fiddler! Here is a quick guide on how to use Fiddler2 as a search proxy so you can see what is happening when the user agent is crawling the content.

  1. Login to the appropriate SharePoint 2010 Application Server where Fiddler is installed
  2. Run Fiddler2 as the SharePoint 2010 default content access account
  3. Minimize the Fiddler2 window and browse to http://localhost:8888
  4. You should see a screen similar to this:
  5. Fiddler Echo Service
  6. Login to central admin
  7. Go to Application management > Manage Service Applications > Search Service Application
  8. Click on None next to Proxy Server: Select “use the proxy server specified” and type http://localhost for Address and 8888 for port.
  9. Click OK
  10. Now run a full crawl on the content source in question. The crawl results will appear in the Fiddler2 window on the server.

Now watch for any errors…especially those pesky red 500 errors!