Host-Named Site Collection Limitations

The Disclaimer

I’ve encountered these limitations on my main development farm and was able to reproduce on one other… one March 2013 PU and one August 2013 CU. It may not be a widespread issue and I am looking for a solution – any help appreciated in the comments 🙂

The Problem

Whilst host-named site collections have been around for a while, it’s only with the release of SharePoint 2013 that they are the “preferred method to deploy sites in SharePoint 2013”. I’m not sure how linked this is to Cloud First and Office 365 but I’d hazard a guess they are linked..

The Technet guidance is fairly comprehensive so no need to repeat that here. Benjamin Athawes’ cheat sheet is useful and summarises options too (thanks mate!)

However, I stumbled across an annoying issue using Claims-based Authentication (as standard) when using the People Picker from Office (2010/2013) from the Document Information Panel accessing a content type in a host-named site collection:

Word 2013 just crashes (helpful!) and Word 2010 hangs for a while but at least doesn’t crash.

Diagnosis

Using Fiddler highlights some web service calls – initially to /_vti_bin/people.asmx as you might expect to resolve the name of the Owner, but subsequently to

/_vti_bin/spclaimproviderwebservice.svc which results in this undesirable behaviour:

The main element being HTTP/1.1 500 System.ServiceModel.ServiceActivationException

It didn’t take long to discover that this was being caused by WCF bindings – in a normal non-SharePoint environment it might be easy to add in the following to the web.config:

Even in SharePoint 2013 this change WILL fix the above issue, however it also causes other issues…. such as

– Drag/Drop

– Various other client-side functionality

The now familiar ServiceActivationException pops up…

I’m yet to find a proper workaround or configuration which will allows both People Picker and Drag/Drop etc to work on premises. Maybe I missed something simple…

Posted

September 18, 2013

Blog, SharePoint

Gus Fraser

Tags:

SharePoint, SharePoint 2013

Comments

3 responses to “Host-Named Site Collection Limitations”

Hois Christian

September 8, 2014

Does anybody have a soltions for it. I have this Problem too. Need urgently a Workaround!

Reply
Michele

December 7, 2014

Hi Gus, thanks for the article, I was looking at the Fiddler trace before reading this, but I would have not figured out it was an issue with the bindings. I was misleaded by the spclaimproviderwebservice.svc
How did you figured out from the trace it is a WCF bindings issue?
I then tested it and having one binding only solves the issue.

btw this happens regardless of having host named site collection

Reply
David Piedra

March 12, 2015

Dont know if you already found a solution but here’s what we did to fix our sharepoint:
We had a problem similar to yours, at first we make a decision to leave all people picker fields not mandatory, this fix the problem on the new document scenario, but not the open and save as existing document scenario. After researching the web for a while, found an blog (https://sharepoint4u.wordpress.com/2014/06/05/the-issue-of-people-and-group-fields-on-document-infomation-panel-and-infopath-forms/) that says exactly whay you say here, could modify the web.config but not recomended. But says another thing, never manually add a site binding in the IIS (or something like that 🙂 ).
After reading this we check our IIS and found that the site bindings where like this:
http — site_name — 80 — *
After this, we changed for this:
http — site_name — 80 — ip_address_of_local_IIS_server

We have 2 sharepoint web servers, we do this in both.

This resolves our problem, so far not found or experience any other side effects.
Hope this could help someone.

Reply