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 2010 – Office Web Apps Cache Expiration

I was doing some browsing around a SharePoitn 2010/Office Web Apps-Enabled farm the other day and noticed something interesting that I thought I’d share. By default when you setup Office Web Apps in SharePoint 2010 the cache expiration does not get set in the web app’s property bag.

I started by checking the web app cache URL’s propery bag items. As you can see there is nothing related to cache expiration:

After this I went ahead and set the max size/cache expiration for the Office Web Apps cache URL and then checked the property bag items:

Notice the waccacheexpirationperiod entry now!

 

-AJB

Patching an Office Web Apps 2013 Farm

Recently I brought the patch level of an Office Web Apps server up to March 2013 PU. Microsoft updates the Office updates listing here: http://technet.microsoft.com/en-us/office/ee748587.aspx

There is a cardinal rule when applying updates to an Office Web Apps 2013 farm and if you get one thing from this post make sure it is this..Remove the machine from the farm (Using PowerShell: Remove-OfficeWebAppsMachine) prior to patching. This means that after applying the updates you must “recreate the farm” using the New-OfficeWebAppsFarm PowerShell command. The updates apply really fast..for a PROD environment I only took 4 minutes!

For a normal Office Web Apps update this is ALL that is needed (SharePoint’s binding to the office web apps farm is based on the server name so usually you do not have to even log on to a SharePoint server). Pretty simple..unless there are more servers and Office Web Apps needs to be HA (See this post if that is the case: http://www.wictorwilen.se/office-web-apps-2013-patching-your-wac-farm-with-no-downtime).

Since the March 2013 PU is not just your average update (See list of changes/added functionality here: http://support.microsoft.com/kb/2767967) you need to do slight configuration on the SharePoint servers. I know the KB article was for February CU, but we are applying March PU – which only has a few incremental changes plus it’s a PU, which means it was more thoroughly tested.

Steps to follow for March 2013 PU to add WordPDF functionality:

  1. After applying the update, you need to log into a SharePoint server to add a binding for the new PDF viewer:

    Note: This seems to place a binding in the internal-http(s) zone, which is no good in scenarios (such as ours) using external-https. In this case I needed to remove all bindings and then add all bindings and everything will be updated to external-https as it should. I tried changing the zone name property, but it is a read only field (and the –allowhttps=$true only switched it from internal-http to internal-https)

    1. After applying this new binding you need to create a new result type for PDF Files:
      1. Site Settings > (Search) Result Types and then finding the PDF Result Type. Choose to Copy the Result Type.
      2. Give the new Result Type an appropriate name, “PDF with Preview” for instance. Then scroll down to Actions and in the “What should these results look like?” drop-down, choose to use the Word Display Template.

     Here’s a couple of sweet PowerShell scripts I came across (From Wictor Wilén) to obtain the version number for Skydrive/O365 Office Web Apps Server:

    US (Current Version is 16.0.2130.1021):

    EUC (Current Version is 16.0.2130.1021):

    Just to put things in perspective – March 2013 PU is version number 15.0.4481.1005