Englando's Blog

SharePoint and more!

Hiding Users from Office 365 SharePoint Global Search Results

So I’ve been playing around with Office 365 and one of my objectives at the moment is to set it up for external access for things like extranets etc.

One method of adding external users (whilst retaining the ability to have multi-factor authentication) is to add them using the Users list in the “Office 365 Admin Center” (Centre to me!).

However, this results in the problem that the user shows up in SharePoint Online searches and Delve which we usually don’t want to happen for external users.

So my answer to this is to exclude the users using a Search Query Rule, and exclude them based on a user profile field, in this case I have set each external user account’s Department field to “None” (via SharePoint Online User Profiles).

  1. Go to the O365 Admin Centre for your tenancy, then navigate to the SharePoint admin centre (or go direct if you have a shortcut somewhere)
  2. Click on “search” from the list to the left hand side O365SearchCapture1
  3. Click on “Manage Query Rules” O365SearchCapture2
  4. Click on “Select a Result Source …” and select “Local People Results (System)”O365SearchCapture3O365SearchCapture4
  5. Click on “New Query Rule”O365SearchCapture5
  6. Type in the “Rule name”, in my case I types Exclude External User (see image below)
  7. Click on “Context” to expand that section, then ensure “One of these sources” is selected and it reads “Local People Results” below it (see image below)
  8. In the Query Conditions section click “Remove Condition” so that the event fires for all keywords and will capture partial names
  9. Click “Change ranked results by changing the query” (see image below)
  10. Enter something like {searchTerms} -Department:None into the “Query text” box if you want to exclude where Department = None.  You can test by changing {searchTerms} to your keyword, e.g. Joe Bloggs -Department:None.  Remember to put it back to the text in bold above  O365SearchCapture6
  11. Save
  12. I had to add the new rule to a new group for it to work so do this too by clicking on the check box to the left of the new rule, then click on “Order Selected Rules”
  13. In the pop up window enter a new group name and click OK
  14. The rule should take effect within a few minutes so test using a SharePoint Online search box.

As for Delve I am still working on that, it is meant to take it’s data from the SharePoint index but I’ll need to wait for Delve to update so that I can test.  There also appears to be two fields in the user profile related to Delve and Office Graph which I am also testing and again I have to wait until Delve updates before I know if changing those fields has any effect.


2014 in review

The stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 4,800 times in 2014. If it were a NYC subway train, it would take about 4 trips to carry that many people.

Click here to see the complete report.

Blog – 2013 in review

The stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 8,100 times in 2013. If it were a NYC subway train, it would take about 7 trips to carry that many people.

Click here to see the complete report.

Locking Down SharePoint 2010 Application Pages – A Word of Warning!

I have created a new no-code expenses solution in SharePoint 2010 (with InfoPath 2010) and was going to permission individual documents via SharePoint Designer workflows.

However, after a recent conversation with Microsoft technical experts the suggestion was that if there are going to be more than 5000 items in the library then we shouldn’t be setting unique permissions for each form due to performance degradation.

So whilst looking at other options I came across an out of the box STSADM command to block regular users from accessing the forms pages in the new expenses site.  This would prevent a user from getting to pages such as allitems.aspx:

stsadm -o activatefeature -url <site collection url> -filename ViewFormPagesLockDown\feature.xml
More info here:  In my case this is for authenticated users – once activated I also had to remove the “View Application Pages” permission from the Contribute permission level I was using.

This would have been a great solution, however the downside was that enabling this feature also blocked regular users from connecting to the .aspx pages in the _vti_bin folder.  There are pages in here that are required for my InfoPath form when it opens – lists.aspx is one.

What happens now is the user gets prompted to enter a username and password when they open the form, but their own username and password doesn’t work as their access is blocked.

So I deactivated the lockdown mode with this command:

stsadm -o deactivatefeature -url <site collection url> -filename ViewFormPagesLockDown\feature.xml
And checked that users could again see the allitems.aspx page, and they could.  But the _vti_bin location was still inaccessible to regular users.  Puzzling.
The solution I found was that I had to create a new permission level in the site (by copying the Contribute permission level I was using) and assigned all authenticated users to it.  This resolved the issue connecting to _vti_bin pages and users are no longer requested for a login prompt in the InfoPath form.

SharePoint 2010 Refiners not Showing for Some Searches

Just a little titbit for anyone that finds when they perform a search in SharePoint 2010 a refiner doesn’t show, but it does for other searches even though keywords are in results of both searches.  This issue was just pointed out on our Intranet for People Searches.

This may be caused by the MetadataThreshold setting for individual refiners in the Refinement Panel.

  • So edit your search results page
  • Edit your Refinement Panel web part settings
  • Edit the Filter Category Definition text


  • Change the MetadataThreshold setting for whichever refiner you are having a problem with from it’s current value to less than the number of search results you have.  In my case it was 3 results.  But I changed the value to 1.


  • You may also want to change your NumberOfFiltersToDisplay and MaxNumberOfFilters values depending on how many times the refiner keyword appears within search results.  In my case we have over 200 departments so for some searches not all department names were showing for the particular search results.
  • Save the settings and your page and try your search again,  you should now see the refiner

2012 in review

The stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 8,000 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 13 years to get that many views.

Click here to see the complete report.

So I’ll be off to the European SharePoint Conference next week which is on from Tuesday 5th to Thursday 7th.  There are a number of seminar sessions I will be attending and I hope to blog about anything interesting and useful.

If you are going to be there then please let me know either here or via my conference profile.

Unable to display this Web Part – XSLTListView and XSLTDataView web part issues in IE – RESOLVED

Just posting this for anyone that has been shot in the foot by the latest December CU for SharePoint 2010.

This is from the Microsoft article KB2639184 :

Create a list or library in SharePoint 2010. Open the list / library in SharePoint Designer. Close and hide the XSLTListView Web part on the page. Insert a DataForm web part on the page. If the list contains a large number of columns or custom XSL has been applied to the DataForm web part the following error message may be displayed:

“Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.”

You will also see System.StackOverflowException errors in the SharePoint log.

Now this issue arose after the installation of the June CU.  Microsoft in their wisdom reduced the timeout for XSLT transformation from 5 seconds to 1 second without giving the administrator the option of increasing it manually via Powershell.  The reduction is a securtity measure to reduce the risk of successfull DoS attacks.  However if you have an internal SharePoint installaton (which many companies do) this new change is fairly pointless.

The timeout essentially causes any modified XSLTListViewWebPart and XSLTDataViewWebParts to error intermittently when viewed in the browser.

However it was meant to have been fixed in the August CU.  Here is the major issue … Installing the December CU breaks the fix from August!!  I would recommend you DO NOT INSTALL the December CU until the next (February?) CU or hotfix is released.

The solutions offered by Microsoft are at this page:  However none of those options are particularly viable for us.  What we need is a hotfix and I will post an update should I get hold of one.


there is now a hot fix available from Microsoft to resolve this issue,  you need to log a call with them and ask for sharepointfoundation2010-kb2597136-fullfile-x64-glb.exe

Once installed use the Powershell script below to make the change to the Timeout value.  Changing it to 2 seconds for us worked and the webparts are now showing fine.

SAMPLE PowerShell to set XsltTransformTimeOut


$farm = Get-SPFarm

$farm.XsltTransformTimeOut = 5




Blog at

Up ↑