I've setup MySites in SharePoint 2013 and created some test sites. Everything seems to be working well except on searching people. Using search center finds the person and the link's backslash is escaped.


This link fails to load with a "User Not Found" error. However, changing to:


works perfectly.

Any ideas?

  • What patching level is your SharePoint installation? I have never seen this issue in my environments Commented May 7, 2014 at 13:37
  • 15.0.4569.1000 I doubt anyone else has either. I think of myself as a decent search monkey and haven't had luck finding anything authoritative.
    – ShellNinja
    Commented May 8, 2014 at 15:52
  • Just to clarify, you are using AD as the Connection Source for profile sync? (e.g. not openLDAP or similar)
    – Russell
    Commented May 13, 2014 at 5:02
  • Correct, AD is the connection source for the user profile service.
    – ShellNinja
    Commented May 14, 2014 at 15:30
  • Can confirm same issue on SP 2013 SP1 + April 2014 CU, I'll post patching level tomorrow... Commented May 21, 2014 at 18:49

6 Answers 6


This issue is resolved in the September 2014 Cumulative Update for SharePoint 2013. Please use this rather than any workarounds. http://support.microsoft.com/kb/2995904

  • this is what fixed it for me. Thanks for the follow-up Trevor!
    – Mike
    Commented Apr 10, 2015 at 15:05

A more global fix can be found by editing Search.ClientControls.js until a permanent fix is found. This will present you with a farm-wide fix, that not only fixes People Search, but other contextual searches as well. I've documented the workaround, but it involves removing references to a new function named encodeURI introduced by April 2014 CU/MS14-022 (depending on patch level) persisting through the June 2014 CU on all SharePoint servers. Given this is temporary, making backups of the original files is vital as is restoration of the backups before applying any future SharePoint patches.


I was able to fix the issue by removing code in Item_Person.html, Item_Person_CompactHorizontal.html (there are two), and Item_Person_HoverPanel.html for the encodedPath variable.

    var encodedPath = $urlHtmlEncode(ctx.CurrentItem.Path);


    var encodedPath = ctx.CurrentItem.Path;

(Not all lines look exactly like this, but you're still looking to unwrap the ctx.CurrentItem.Path in each case.)

  • 1
    If anyone has a better answer (yes I know I shouldn't edit the system created templates) I'll mark it as accepted. I'd like to hear it!
    – ShellNinja
    Commented May 7, 2014 at 13:21
  • That's the solution we have implemented and it works great! But, you have to make the change to: Item_Person.html, Item_Person_CompactHorizontal.html (there are two), and Item_Person_HoverPanel.html Commented Jun 10, 2014 at 21:22
  • Good point that I omitted - we had to do the same thing. Feel free to add an edit.
    – ShellNinja
    Commented Jun 12, 2014 at 12:27
  • Glad they patched it out so it's worth noting that the patch should be used rather than the solution here.
    – ShellNinja
    Commented Jan 28, 2016 at 17:24

A slight variation on the reply above, We use Search Center Site and search results are directed to results.aspx, Added the Script Editor web part and the following script

function customSearchResultsFixUrlEncoding(str, find, replace) {
  return str.replace(new RegExp(find, 'g'), replace);
$('.ms-searchCenter-result-main').on("click", "a", function (event) {
    var url= $(this).attr('href');
    var url2 = customSearchResultsFixUrlEncoding(url, "%2520", "%20");
    var url2 = customSearchResultsFixUrlEncoding(url2, "%255C", "%5C");
    var url2 = customSearchResultsFixUrlEncoding(url2, "%252E", "%2E");
    $(this).attr('href', url2);

I was searching for a reason for this bug and it looks like this is the only post out there so far. You are not alone..

I verified this as an issue on 2 separate farms with: SQL Server 2014 and SharePoint 2013 April 2014 CU.

I had to do the same thing with Item_Person.html. I am looking for a better solution, but since this is a bug, there would probably be a hotfix for it that replaces the template(s)

  • Welcome to stack - please post answers with answers. This is better suited for a comment.
    – ShellNinja
    Commented May 30, 2014 at 16:23
  • I posted a question yesterday on this site with the same exact issue. I came across this while googling..me sad. :) Commented Sep 26, 2014 at 19:52

We noticed this behavior was working in an environment with SP1 but broke after installing the April CU to our SharePoint environments. We have a ticket open with Microsoft and they have confirmed its an issue on their end.

I have added a Script Editor Web-Part to the Search Results page with the following JavaScript:

var $j = jQuery.noConflict();
$j('#s4-workspace').on("click", "a[id='NameFieldLink']", function (event) {
        var URL = $j(this).attr('href');
        var NewURL = URL.replace('%255C', '%5C').replace('%252E', '%2E');

          $j(this).attr('href', NewURL);

The JavaScript replaces the incorrect markup to allow the link to resolve correctly. This is a very lightweight approach to solving the issue and is easily revertible if/when Microsoft fixes the issue on their end.

  • Welcome to stack. Please post answers with answers... Your answer does not contain one and only rephrases what has already been stated.
    – ShellNinja
    Commented May 30, 2014 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.