Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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.

    http://mysiteshost/Person.aspx?accountname=DOMAIN%255CUsername

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

    http://mysiteshost/Person.aspx?accountname=DOMAIN\Username 

works perfectly.

Any ideas?

share|improve this question
    
What patching level is your SharePoint installation? I have never seen this issue in my environments –  Robert Lindgren May 7 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 May 8 at 15:52
    
Just to clarify, you are using AD as the Connection Source for profile sync? (e.g. not openLDAP or similar) –  Russell May 13 at 5:02
    
Correct, AD is the connection source for the user profile service. –  ShellNinja May 14 at 15:30
    
Can confirm same issue on SP 2013 SP1 + April 2014 CU, I'll post patching level tomorrow... –  SharePoint Internship May 21 at 18:49

6 Answers 6

up vote 0 down vote accepted

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

share|improve this answer

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.

share|improve this answer
    
Awesome. Simply awesome. Thanks Trevor. –  ShellNinja Jun 26 at 18:47

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);

becomes:

    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.)

share|improve this answer
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 May 7 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 –  Jim Bob Howard Jun 10 at 21:22
    
Good point that I omitted - we had to do the same thing. Feel free to add an edit. –  ShellNinja Jun 12 at 12:27

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)

share|improve this answer
    
Welcome to stack - please post answers with answers. This is better suited for a comment. –  ShellNinja May 30 at 16:23

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.

share|improve this answer
    
Welcome to stack. Please post answers with answers... Your answer does not contain one and only rephrases what has already been stated. –  ShellNinja May 30 at 16: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);
});
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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