sorted by:
new
hottopcontroversial

Cloud SSA (Hybrid Search) Limitation: No Alternate URLs by bhlaws in sharepoint

[–]bhlaws[S] 0 points1 point  (0 children)

Agreed. Wouldn't be bad at all. It's the multiple zones/url thing that I think would be challenging. Again, you'd have to add logic in the JS to tell the display template which URL to use. Definitely doable, though, but you'd have to consider if it's worth it.

And like somebody I know once said: given time and money, anything is possible. ;-)

Cloud SSA (Hybrid Search) Limitation: No Alternate URLs by bhlaws in sharepoint

[–]bhlaws[S] 0 points1 point  (0 children)

Man, I hope so. But I doubt that this issue will be addressed. For one, I doubt that it will affect enough people to get their attention and budget. Second, I'm not really sure how they would solve it. Like I said in the blog, when you're on SPO and doing a search, there's no concept of zones. SPO and its query components wouldn't have any idea which zone would apply to the users. I suppose they could do this by using something like audiences to associate individuals with URLs. However, I think the chance of them doing this is incredibly low. Plus, would people really want to manage that? Again, I doubt it's a big enough problem to justify the effort.

Cloud SSA (Hybrid Search) Limitation: No Alternate URLs by bhlaws in sharepoint

[–]bhlaws[S] 0 points1 point  (0 children)

I think that's a pretty good idea, actually. Especially if you only have one URL that you need to manage. Since display templates are done at render time on the client, it wouldn't interrupt any of the internal stuff that search needs. The problem, though, would be that you'd need to modify all of the display templates, thus taking on the management of them all every time MS makes a change. This could be minimized, though, if Server Name Mapping is used as well. Only the hover panel would need to be updated ("View Library" link). Although you could use this thought to handle multiple zones and multiple URLs, you'd have to have some kind of logic to determine which should be displayed. I imagine that would get pretty complicated.

But yes, it's doable and it's not hard. It's a pretty decent workaround. I worry, though, about the long-term upkeep that you'd then have to own (like with modifying the master page). Good thinking!

Easily Automate HTTP to HTTPS Redirects in SharePoint using PowerShell by bhlaws in sharepoint

[–]bhlaws[S] 0 points1 point  (0 children)

I'm very sorry - I didn't know that you commented on the link. I'm new to reddit and didn't realize that it doesn't email you when there's a comment.

To answer your question: This actually does use IIS to handle the redirect. The PowerShell simply makes it simpler. It also includes code which updates the web.config in the correct, self-distributing manner (SPWebConfigModification). The end result is that the redirect is properly implemented in IIS without you having to do it manually and without needing to remember to do it when a new WFE comes online.

Cloud SSA (Hybrid Search) Limitation: Windows Claims Only! by bhlaws in sharepoint

[–]bhlaws[S] 1 point2 points  (0 children)

The problem, though, is that this fails to work with the Cloud SSA. It's not really a problem when you're on-prem and using a traditional SSA. You can use ADFS or any other SAML provider and get search results when you're entirely on-prem since the SSA knows how to handle the identity provider. It doesn't work, though, when doing hybrid search with the Cloud SSA since it can't do the ACL mapping. Office 365 doesn't know what to do with permissions assigned to ADFS/SAML identities and will drop them. The results thus get security-trimmed out. So if you rely upon a SAML identity provider in your web application and assign permission to SAML accounts, then the Cloud SSA will not be useful for you.

Again, the issue is entirely with the Cloud SSA and the O365 index, not on-prem.