September 25, 2020 - 10:30, by Steven Van de Craen -
In an hybrid search environment the Cloud Search Service Application indexes local file shares and ships the index to SharePoint Online for querying. If you are indexing a local file share then you’ll notice something funny with those search results in Modern Search in SharePoint Online.
As you see the Modern Search just renders the result as non-clickable. Now you could still use Classic Search, but then it would get blocked if you click on it in a modern browser (which you should) due to security concerns.
Not allowed to load local resource: file://myserver/testfileshare/test.txt
The first issue (the visualisation in Modern Search) could be handled by using your own Modern Search results, for example via the PnP Modern Search Solution or use classic search result pages, so I’m not digging into this. The second issue however is generic and requires some thought.
I have seen environments that link directly to file servers for content and ideally that content would be moved into the environment. But there are still valid reasons for file shares and organisations may want to expose them to users through search. So for those cases you would need to find a solution. Here’s what I came up with…
- Use Internet Explorer; ugh. I can’t recommend this anymore but since it technically solves the issue so I’m adding it to the list.
- Start the browser with a flag to allow loading local resources (eg Chrome used to have --allow-file-access-from-files but this no longer works); it cannot be enforced for external users (if applicable) and it doesn’t feel like the right approach.
- Use a browser extension; there are browser extensions that restore the functionality when clicking on a file:// link. The issue I have with extensions is are they safe and trustworthy?
- Use Microsoft Edge IE Mode; users still use a modern browser but specific sites will use the IEMode. It would be a shame to have your entire “modern” SharePoint Online environment to run in IE Mode, no? Also it cannot be enforced for external users (if applicable)
- Put a web server or application in front of the file share; it shows the directory and file structure of the file share with authentication to ensure results are properly shielded
- If you have any other suggestions or solutions feel free to let me know
So let’s go with number 5 on the list. Now I want to have my search results coming from the application.
- Either the application supports being crawled directly as a website by SharePoint Search, and you just configure the Content Sources as such
- Or it may be possible to configure Server Name Mappings to transform the original file share UNC path
Run crawl and voila the search results are transformed into a web url
In either case your search results would now be coming from a web application and you won’t have the issue anymore.
So, what’s your take on this?
February 26, 2020 - 15:17, by Steven Van de Craen -
I’ve been using the new Microsoft Edge (Chromium based, Insider, Chredge, …) ever since the beginning and have loved it from the start. But a recent change (version 79 ?) has an issue with Windows Credentials, something I run into for SharePoint environments with Windows Authentication (NTLM, Kerberos).
Before the update it would prompt with a prefilled credential prompt:
I could just press “Sign in” to continue.
But after the update it would prompt a different style prompt without prefilled credentials or option to save the credentials, forcing me to enter the full username and password every time.
It seems this will be fixed properly in a future update, but for now it is possible to revert to the original credential prompt and functionality via the following workaround:
- Browse to edge://flags/#edge-windows-credentials-for-http-auth
- Change this setting to Disabled (and restart the browser)
Credits & Info: https://techcommunity.microsoft.com/t5/discussions/windows-integrated-authentication-not-working-canary-amp-dev/m-p/934866/highlight/true#M14559