SharePoint 2013 Search re-write host

Hi Adam, have you looked at the Server Name Mappings setting in SharePoint Central Admin>Search Administration? If I understand it right, it will let you change the display address of indexed search results.

thanks

Mike

The server name mappings are set. When you look at the search results the URL at the bottom of the result looks correct but when you hover over an office document the result actually goes to the original searched URL. This apparently has something to do with Office Web Apps, ADFS, and SharePoint not being fully happy with each other. This also apparently happens on some SharePoint applications as well. Thus why I am trying to use the F5 to re-map the host information that is returned to the browser.

You shouldn't need to do that. I'll see if I can reproduce it in my lab here, but I recommend creating a support case with Microsoft as well. It'll take some time for me to get it set up.

I think this all stems from having search crawl a non-default zone. Changing our permissions on the default zone adds another level of SharePoint stupidity as well. We actually have a case with MS and they appear to be stumped as well.

I actually have the replace working for when you click the link for the document. It now sends you to the Office Web apps server correctly but the fly out preview does not show anything. I have a feeling that is due to it not liking the multiple redirects that the ADFS setup requires.

I will keep plugging away at it. We are also looking at another configuration to find out which one causes the least amount of pain with the greatest functionality.

Adam,

I am running into the same issue with our SharePoint 2013 + ADFS deployment. First off, you can't have search crawl a non-Default zone. Other things start blowing up. You are also correct with the server name mappings... changing those just change the "Green" link displayed on the page but not the URL to the item itself. (So what's the point of this option? Really, I want to know!)

In our config we did the following:

• Configured the Default Zone for HTTPS on Port 444 using NTLM as the Auth provider.
• Make sure all other sites like My and Search are configured the same.
• Extend the sites to one of the other zones. It doesn't matter which, just make sure they are the same zones. In our case we used HTTPS on Port 443 and picked our SAML claims provider in the "Custom" zone.
• We then send internal and external traffic through the F5 using the most current iApp Template for SharePoint (V1.1)

This will get you 95% of the way. I have three issues that I can't resolve. NewsFeeds always have the Default Zone URLS. Not sure why this is. So when you follow people, sites or documents the URL to them will contain the 444 site. The other issue we have ran into with SAML is that the WebDAV mapped drives to SharePoint document libraries time out. WebDAV doesn't know how to re-auth with SAML. The last issue is that none of the Microsoft iOS office apps work with On-Prem SAML SharePoint.

I was hoping that I could do a "re-write" for the NewsFeeds with the F5. The issue we have with WebDAV is a little harder to fix. It doesn't look like you can tweak the Auth Token to make it work. Maybe one of you F5 wiz kidz can figure something out. the closest thing I can get to work is changing the ADFS auth token to 8 hours and then change everyone's IE home page to SharePoint. :) It will authenticate them when they go to check the morning news and keep it active for the "working" hours. However this opens some possible security issues.

Now the mobile app thing is another strange beast. When I go through the F5 I can't get them to work at all. Yet if I bypass the F5 and go to the WFE I can get the Android mobile app to work 100% of the time and the iOS app to work during the life of the Auth Token.

I have a case open with Microsoft on the NewsFeeds and iOS app issues but I would be interested if you or anyone here has figured out a work around with the F5. In short SAML "works" with SharePoint 2013. Just not fully from what I can tell. However, these short coming should be manageable with some F5 hackery. Any ideas community?

We ended up going back to Kerberos. The issues we ran into with SAML documented above as well as the requirement (late coming) for full BI functionality forced us back.

So our users are back to entering their credentials when they jump between Host Name Site Collections unless they are in Windows and have the SharePoint domain in their Trusted or Local intranet zones.

-Adam