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 –

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 ( 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 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 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: 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:


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


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


Cool Stuff. Also another plug for Ben Prin’s blog…check out this post:

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/Server 2012 R2: Config Wizard Fails with Error “Value Does Not Fall Within The Expected Range”

Ran into an interesting installation error – SharePoint was failing to create the Configuration Database..or so it appeared. Running New-SPConfigurationDatabase and running the SharePoint Products Configuration Wizard were both failing with the error “Value does not fall within expected range.” We were able to track down this issue in the ULS Logs and noticed all sorts of IIS-related errors:

Creating new application pool ‘SecurityTokenServiceApplicationPool’.

Adding DOMAIN\spfarmacct to local group IIS_WPG.

Adding DOMAIN\spfarmacct to local group WSS_WPG.

Adding DOMAIN\spfarmacct to local group PerformanceMonitorUsers.

Attempting to give SE_ASSIGNPRIMARYTOKEN_NAME privilege to application pool user DOMAIN\spfarmacct

Attempting to give SE_INCREASE_QUOTA_NAME privilege to application pool user DOMAIN\spfarmacct

An exception occurred while committing IIS configuration changes: Value does not fall within the expected range.

Unable to unprovision metabase object IIS://localhost/w3svc/AppPools/SharePoint Central Administration v4: System.Runtime.InteropServices.COMException (0x80070003): The system cannot find the path specified.

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)

at System.DirectoryServices.DirectoryEntry.Bind()

at System.DirectoryServices.DirectoryEntry.get_AdsObject()

at System.DirectoryServices.DirectoryEntry.DeleteTree()

at Microsoft.SharePoint.Administration.SPMetabaseObject.Unprovision()

Removing the Web Server (IIS) Role Service and letting the prerequisite installer configure IIS was the ticket to get “past” the SharePoint Products Configuration Wizard. It looked like something was up with the client’s Windows Server 2012 R2 image which caused IIS to get a little out of whack. Some other items to watch out for in this configuration (SP10/Svr 2012 R2):


SharePoint Open With Explorer Not Working – Check those managed paths

Try searching the internet for “SharePoint Open With Explorer Issues” and you will be busy for hours searching through all of the different forums, blogs, etc. Some of the most common recurring issues I found in my searching:

  • No “Root” site collection
  • Web Client service not started/not configured correctly on the client PC
  • Hot fixes need to be applied
  • The SharePoint site URL’s are not added to Trusted Sites/Local Intranet Zone

There are many more out there, but these were the most common I found..Now on to this SharePoint troubleshooting tale:

The client just went through a SharePoint 2010 to 2013 upgrade and Explorer View was working for some site collections and not others. This was reproducible on a Windows 7 Client with IE 10 or IE 11. We also did a test on Windows 10 and everything seemed to work there (Web Client must act different in the new OS). The open with explorer would work for 1-2 times after restarting the Web Client service. Then it would start prompting to add the site to Trusted Sites. Then after restarting Web Client this process would start all over again.

After some investigating I noticed something interesting in the Fiddler Traces..

Working Site Collection:

PROPFIND http://sitesp13ent01.ajb.loc/
207 MULTI-STATUS (text/xml)

PROPFIND http://sitesp13ent01.ajb.loc/sites
207 MULTI-STATUS (text/xml)

Non-Working Site Collection (It will give the error “We’re having a problem opening this location in File Explorer. Add this web site to your Trusted Sites list and try again”):

PROPFIND http://sitesp13ent01.ajb.loc/
207 MULTI-STATUS (text/xml)

PROPFIND http://sitesp13ent01.ajb.loc/depts
404 NOT FOUND ()

PROPFIND http://sitesp13ent01.ajb.loc/depts/it/Shared%20Documents
207 MULTI-STATUS (text/xml)

Notice anything weird?? There is a 404 Not Found for the /depts path. Let’s take a look at SharePoint Central Admin for the managed paths config for this web app:


Any site collection under the /sites/ wildcard managed path was working correctly and any of the depts site collections were not. WebDav is smart enough to honor wildcard managed paths, but does not work with “nested” explicit inclusions as it tries to hit each level of the URL..

Fixing the issue:

  1. Option A – Create an explicit managed path at depts and create site collection at depts URL
  2. Option B
    • Add depts as managed path (wildcard inclusion)
    • Deleted all depts/* explicit inclusions
    • If there is a site collection at depts this will need to be deleted
    • Note: Only tested 1 level deep (For example: depts/it). Did not test a scenario where there is more than 1 level (For example: depts/it/projects)


SharePoint 2013 – Publishing Sites Loading W/ Unexpected Error

Ran into a unique issue today so I figured I’d blog about it!

This was only affecting site collections with the SharePoint Publishing Infrastructure Feature enabled. I created a new site collection with Team Site template and that loaded fine until the Publishing Feature was activated and then it started to load w/ errors.

There was a line in the logs that stuck out:

DelegateControl: Exception thrown while adding control ‘Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapDataSource’: System.InvalidOperationException: Operation is not valid due to the current state of the object.   

 at Microsoft.SharePoint.SPUserToken.GetClaimsUserLoginName()   

 at Microsoft.SharePoint.SPSite.CopyUserToken(SPUserToken userToken)   

 at Microsoft.SharePoint.SPSite.SPSiteConstructor(SPFarm farm, Guid applicationId, Guid contentDatabaseId, Guid siteId, Guid siteSubscriptionId, SPUrlZone zone, Uri requestUri, String serverRelativeUrl, Boolean hostHeaderIsSiteName, SPUserToken userToken, Boolean appWebRequest, String appHostHeaderRedirectDomain, String appSiteDomainPrefix, String subscriptionName, String appSiteDomainId, Uri primaryUri)   

 at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, Boolean swapSchemeForPathBasedSites, SPUserToken userToken)   

 at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, SPUserToken userToken)   

 at Microsoft.SharePoint.SPSite..ctor(String requestUrl, SPUserToken userToken)   

 at Microsoft.SharePoint.Publishing.CachedObjectFactory.get_SuperUserSite()   

 at Microsoft.SharePoint.Publishing.CachedObjectFactory.OpenWebFromSuperUserSite(Guid webId)   

 at Microsoft.SharePoint.Publishing.CacheManager..ctor(SPSite site)   

 at Microsoft.SharePoint.Publishing.CacheManager.GetManager(SPSite site, Boolean useContextSite, Boolean allowContextSiteOptimization, Boolean refreshIfNoContext)   

 at Microsoft.SharePoint.Publishing.CachedAreaLookup.EnsureLookup(Boolean errorsAsExceptions)   

 at Microsoft.SharePoint.Publishing.CachedAreaLookup.GetCachedAreaOrException()

I double checked the Object Cache settings for all web apps and everything looked good.

Removing the Object Cache Accounts using this PowerShell command made the sites with Publishing Infrastructure enabled load up without errors:

After that I ran the commands to re-add the Object Cache (SuperUser/SuperReader) accounts and everything was still working. A few days earlier the application pool account for this web app expired and was reset to the original password, which may have had something to do with this. Looks like it just needed a little reset of the Object Cache accounts and everything was back up and running!

SharePoint 2013 – 404 Error When Connecting to ACS or ADFS /_trust/default.aspx

Ran into an interesting error this morning that I thought I’d share. Recently, I worked on a project utilizing Azure ACS with Google Accounts. This was working on multiple servers, but one was displaying a Page Cannot Be Displayed message when clicking the Google Sign-In button. Looking at a network trace it was getting a 404 error for the following page:


Doing a little bit of research this page is used when utilizing ADFS/ACS. Interesting part about this is it worked on 2 out of the 3 servers and the server affected worked with Windows Integrated login. I checked a network trace on a working server and saw that after it hits the /_trust/default.aspx it redirects to the ACS URL ( and then redirects to I was able to hit both of these URL’s individually on the non-working server.

I popped open IIS on the problematic server and noticed something interesting. The _trust IIS Virtual Directory was missing!


Big surprise, the other 2 (working) servers had this Virtual Directory. Running the provision PowerShell method fixed the issue..I’m really digging this command lately.

Thanks Jasper for the tip!

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.


Duplicate List DisplayName causing ListData.svc 500 error

This is a fun one I haven’t seen in a while so I figured I’d blog. Support issue today where user was trying to access listdata.svc


This worked at the web app URL root, the site collection root, but was giving a 500 error at a specific subsite. There was a subsite underneath the affected site and that one loaded up just fine as well..seemed to be isolated to one site.

This issue is caused by a couple of things (specifically if it’s isolated to a single site or list):

  1. Invalid characters in list (Either displayname of list or column names):
  2. List view threshold/list lookup threshold
  3. Anonymous user tries to access ListData.svc
  4. svc does not work with Discussion Lists
  5. A few others:

It was none of these..pretty small site with nothing too crazy for naming or anything like that. Turns out the user created a list and gave it the same displayname as another list on the site (URL’s different..sharing the same displayname). This caused the entire site to throw a 500 error when accessing it with listdata.svc. Even when explicitly going to a list on the site that wasn’t affected. Once the user switched one of the lists to <listname> (old) everything started working.


SharePoint 2013 – Another FIPS 140-2 Adventure “The encryption type requested is not supported by the KDC”

Oh Federal Information Processing Standard (FIPS) 140-2 AKA FIPS 140-2…You got me again! See the original post here:

As stated in several Official Microsoft documents, SharePoint uses several Windows encryption algorithms for computing hash values that do not comply with FIPS 140-2..therefore you CANNOT enable the FIPSAlgorithmPolicy registry key. Here’s some info:

So in this situation we found that the group policy was applied so we retracted that and SharePoint was “back up.” At this time sites were loading, but I was seeing a bunch of errors related to search and distributed cache in the eventvwr/ULS Logs:

System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner exception. —> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. —> System.ComponentModel.Win32Exception: The encryption type requested is not supported by the KDC

This led me to the following blog post:

In this scenario 3 things still needed to happen:

First, IIS Crypto was ran and set to FIPS 140-2 mode. This needed to be reverted as this blocks MD5 hashes.

Then, the AD attribute msDS-SupportedEncryptionTypes needed to be changed from 24 to 28 on all SharePoint 2013 servers. The value of 24 does NOT include MD5 hashes..which SharePoint desperately needs.


After this was set Local Security Policy needed some tweaking (“Network Security: Configure Encryption types allowed for Kerberos”)

This was set to the following (Blocking MD5):


Once checking ALL boxes containing MD5 we were back up and running..Search was working and distributed cache was happy..SharePoint was happy..we were all pretty happy in fact 🙂



SharePoint Admin Tool Belt Addition – C2WTS Troubleshooting

I was troubleshooting an issue with the Claims to Windows Token Service the other day and found a great tool to assist. I was working in a SSRS integrated environment configured with Kerberos and was getting the error “Cannot convert claims to windows token” when configuring a data source to test against. The issue was that the C2WTS service account was not in the local admin group. I had requested this access, but in this environment the local admins were all in an Active Directory Group and I did not have permissions to confirm this and adding the account in local admin explicitly was whipped out with Group Policy. Anyways, enough about the issue..the awesome tool is at and is called c2WTS tester

Add it to your SP Admin tool belt!