Modern Search Results and file shares

September 25, 2020 - 10:30, by Steven Van de Craen - 0 Comments

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…

  1. 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.
  2. 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.
  3. 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?
  4. 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)
  5. 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
  6. 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.

  1. Either the application supports being crawled directly as a website by SharePoint Search, and you just configure the Content Sources as such
  2. 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?

Get ItemID of files which have no checked in version

April 9, 2020 - 14:20, by Steven Van de Craen - 0 Comments

Had the requirement to get the CheckedOutFile collection of a SharePoint List programmatically and it had to include the ItemID for the file (for use in further programmation).

Via PowerShell you can quite easily get the Path Identity information which contains the ItemID:

PowerShell CheckedOutFiles

Notice that the number at the end is the ItemID.

However, via C# CSOM this is a lot harder as the ObjectPathIdentity class is “inaccessible due to its protection level”. You can’t directly get to this info so I created an extension method “GetPath” to get this info:

public static class ClientObjectExtensions
    public static string GetPath(this ClientObject o)
        string result = null;

        if (o != null)
            var q = o.GetType().InvokeMember("Path", BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.Public, null, o, null);
            var r = q.GetType().InvokeMember("Identity", BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.Public, null, q, null);

            result = r.ToString();

        return result;

Which can be integrated into the C# CSOM logic



Now you can extract this value from the string and continue to work with it as needed.

SPFx Web Part assets and external users

March 23, 2020 - 11:34, by Steven Van de Craen - 0 Comments

Last week we ran into an issue where external (guest) users on SharePoint Online needed access to custom developed SharePoint Framework Web Parts deployed to the app catalog. By default don’t have access to this location so they receive an access denied on the web part assets.

We brainstormed about deploying to a public CDN but decided against this as it would open up the assets to potentially everyone rather than all our external users. Perhaps this is an unnecessary concern but we’re rolling with it.

A few years ago Microsoft made a change in how guest users receive access to SharePoint by deprecating/disabling the use of “Everyone” or “All Authenticated Users” for external users. See:

While possible to restore this functionality it is better to introduce a dynamic group in Azure Active Directory to identify guest users. Note that this functionality requires Azure AD Premium P1 or higher.


Specify the membership type during group creation:

Specify the membership type during group creation


Next use the rule builder to select all guest users (or other requirements you might have). My query is (user.userType -eq "Guest")

(user.userType -eq "Guest")


It may take a few minutes before the group membership reflects the rule(s).

It may take a few minutes before the group membership reflects the rule(s).


Finally, when the group is fully propagated it can be added to the SPO App Catalog with read rights. Note that it might take up to 24 hours (not official) for the group to show up in the People Picker.

Guest Users in People Picker


Hope this helps.

Failed to queue mysite for provisioning for user

March 4, 2020 - 11:00, by Steven Van de Craen - 0 Comments

I was seeing this issue in a SharePoint 2016 environment (Event Log ID 8144 and ULS logs):

Failed to queue mysite for provisioning for user:[domain\user-DELETED-12066432-19B1-4F17-82C9-CF3FC9385325] with correlationid:[12066432-19b1-4f17-82c9-cf3fc9385325] on queue type:[Interactive]. Error:[Microsoft.SharePoint.SPException: The specified user domain\user-DELETED-12066432-19B1-4F17-82C9-CF3FC9385325 could not be found.
   at Microsoft.SharePoint.SPWeb.EnsureUser(String logonName)
   at Microsoft.Office.Server.UserProfiles.MySiteInstantiationManager.EnsureUserAndFixQuota(String owner, SPSite rootSite)
   at Microsoft.Office.Server.UserProfiles.SiteInstantiationWorkItemJobDefinition.<>c__DisplayClass19.<AddWorkItemElev>b__18(SPWeb web)]

This error repeats every 5 minutes as the timer job tries to provision a MySite for this user, however it no longer exists (can happen in some edge case scenario’s mostly related to Active Directory).

Navigate to the User Profile overview, find the user profile and delete it to fix the issue.

Manage User Profiles

Open document in browser, open document in client

February 6, 2019 - 12:40, by Van de Craen Steven - 0 Comments

"Hey I have a link to a Word document in a SharePoint document library and I have this link on a page to it that I want to open directly in the browser [Word Online]."

"Sure no problem, just append ?web=1 to the link"

"Wow, cool! Can you do the same for opening directly in Word?"


Just linking to the document would offer it as download


I considered a complex hyperlink with an onclick handler that would then open it in Word etcetera etcetera, very convoluted and a thing from the past really.

Then I found out about the Office URI Schemes:

  • ms-word:ofv|u|https://mysharepoint/mylibrary/mydocument.docx
  • ms-word:ofe|u| https://mysharepoint/mylibrary/mydocument.docx

ofv = open for view, ofe = open for edit

You can read up on them here:

Even works in emails if you can construct the hyperlink href yourself. In a simple text mail it will not detect as a hyperlink and just render plain text.


Must admit that was a TIL.


SharePoint 2019 not loading style sheets in document libraries

February 5, 2019 - 15:18, by Van de Craen Steven - 0 Comments

Reblogging this for reference…

An issue I ran into during an upgrade to SharePoint 2019 with custom branding was that the style sheets weren't loaded correctly by the browser. The console logs showed these resources being downloaded as application/octet-stream mime type rather than text/css.

Stefan Goßner has a blog post about this explaining that the mime type cannot be determined properly for files hosted in document libraries. Currently a workaround exists that enables the IIS 6 Metabase Compatibility Windows Feature:

import-module servermanager

install-windowsfeature web-metabase

A fix is in the works and should resolve the issue permanently without the need for the workaround.

SharePoint Server Search and TIF file indexing

November 23, 2018 - 16:30, by Steven Van de Craen - 0 Comments

A client who was using TIF files in SharePoint 2016 reported that the search results didn’t link to the file directly, but rather to the List Item Display Form (DispForm.aspx?ID=x) for these files and wanted that changed.

Most info on the web on how to configure for TIF file indexing is rather outdated and incomplete so here’s an update for SharePoint 2016 and 2019.


1. Enable the TIFF iFilter on all servers configured for “Content Processing” in the Search Topology

Install-WindowsFeature -Name "Windows-TIFF-IFilter"


2. [Windows Server 2012 (R2) only] Enable the Windows Search Service Feature on all servers configured for “Content Processing” in the Search Topology

Install-WindowsFeature -Name "Search-Service"


3. Add both tif and tiff to the list of Crawled File Types for the Search Service Application

Add to Crawled File Types


4. Add both tif and tiff as a file format to the Search Service Application

$ssa = Get-SPEnterpriseSearchServiceApplication

New-SPEnterpriseSearchFileFormat -SearchApplication $ssa tif "TIFF Image File" "image/tiff"

New-SPEnterpriseSearchFileFormat -SearchApplication $ssa tiff "TIFF Image File" "image/tiff"


5. Restart the SharePoint Search Host Controller on all servers configured for “Content Processing” in the Search Topology

Restart-Service SPSearchHostController


6. Run a Full Crawl


You should now have proper indexing of TIF files.

Crawl Log

TIF search result

SharePoint 2019 and the new OneDrive Sync Client

November 20, 2018 - 14:34, by Steven Van de Craen - 0 Comments

I’ve been running various tests and scenario’s with the new SharePoint 2019 that released about a month ago and ran into an issue with the new OneDrive Sync Client (aka NGSC or Next Generation Sync Client).

OneDrive sync error

Sorry, we couldn’t sync this folder. Contact your IT administrator to configure OneDrive to sync SharePoint on-premise folders

Aside from the obvious grammar error (on-premise vs on-premises) I didn’t expect this issue as I had Windows 10, the latest OneDrive client and SharePoint 2019 as outlined here: Except I ignored the part where it says you need to configure Group Policy objects for it to work.

To set up OneDrive with SharePoint Server 2019, configure the following Group Policy objects:

  1. SharePoint on-premises server URL and tenant folder name The URL will help the sync client locate the SharePoint Server and allows the sync client to authenticate and set up sync. The tenant folder name lets you specify the name of the root folder that will be created in File Explorer. If you don’t supply a tenant name, the sync client will use the first segment of the URL as the name. For example, would become “Office.”
  2. SharePoint prioritization setting for hybrid customers that use SharePoint Online (SPO) and SharePoint on-premises server This setting lets you specify if the sync client should authenticate against SharePoint Online or the SharePoint on-premises server if the identity exists in both identity providers. Learn how to manage OneDrive using Group Policy

Now a quick way to configure these values is using the registry editor.



  • Name: SharePointOnPremPrioritization
  • Type: REG_DWORD
  • Value:
    • 0: prioritizes for SharePoint Online (“PrioritizeSPO”)
    • 1: prioritizes for SharePoint 2019 (“PrioritizeSharePointOnPrem”)




Once you configure these values you can sync a SharePoint 2019 library with the new sync client.

Issue with setting managed metadata fields in a SharePoint workflow

November 9, 2018 - 11:41, by Steven Van de Craen - 0 Comments


One of my on-prem customers is running Nintex Workflow on SharePoint 2016 and escalated an issue with setting a Taxonomy/Managed Metadata field value via a workflow. They experienced that the workflow would not change the value, or in some case it would but only once.

I managed to scope the issue down to the following:

  1. It works in SharePoint 2010 but doesn’t in SharePoint 2013, 2016, 2019 (had to spin up a VM of each for proper testing)
  2. It only affects Workflow Foundation/SharePoint 2010 Workflow Engine workflows (SharePoint Designer can create them, Nintex Workflow on-prem is based on this)
  3. For files that haven’t been given a value for the managed metadata field the workflow can set the value once. If the field has been set or cleared previously by UI, code, workflow, it will no longer accept new values via the workflow. For Office documents this may not work since background property promotion also causes the issue

So that makes it a pretty narrow scope and explains why there aren’t that many reports on this. But since not everyone is moving to the cloud at the same speed this is still be a relevant issue for some.


I’m going with SharePoint 2016, but I managed to reproduce this in 2013 and 2019 as well.

Create a document library and create a Managed Metadata field with some values and upload a document

Create a new workflow using the “SharePoint 2010 Workflow Platform” (SharePoint Designer or Nintex Workflow)

Create workflow 

Configure the workflow to update the Managed Metadata field. This field expects the format TERMLABEL|TERMGUID (I’m using a hardcoded value)

Workflow step

Publish the workflow and run it on new files. For non-Office documents this should work once.

Result #1

Next, change or clear the value through UI or whatever and run the same workflow again. You should see that even though the workflow has run it could change the value.

Workaround or fix?

I’ve been digging into the internals and it seems that once the managed metadata field is set or cleared, it keeps properties in the SPFile.Properties property bag that interfere with the update process. If you delete these properties and update the SPFile the workflow can update the value (again only once since the properties are added again).

Removing the properties requires an SPFile.Update() which in term creates a new version and is less than ideal.

Escalating this to PSS and hoping for a fix would probably be the right way, but since the narrow scope of the issue and since it is in older technology I have low hopes on this getting fixed soon.

In my case I wrote a Web Service that would allow for updating the Managed Metadata field value through the SharePoint Object Model. And this Web Method can be called in the workflow. It even allows for the workflow designer to specify the type of update (Update, UpdateOverwriteVersion or SystemUpdate). So although not very intuitive the workflow designer can now update Managed Metadata fields through the Web Method, and all other fields through the regular workflow action.

Web service input

OneDrive sync client and green locks (read-only sync)

December 7, 2017 - 15:31, by Steven Van de Craen - 0 Comments

The issue

I recently ran into an Office 365 environment where all users were seeing green locks on files and folders synched with the OneDrive For Business client.

OneDrive read-only sync

If this isn’t expected, in cases where the user should definitely have write access to these files you might want to check the following Library Settings:

Require content approval for submitted items?

Go to Library Settings > Versioning:

 Content Approval

If your library has this enabled than OneDrive will only sync in read-only mode. If you disable this setting your sync client should inform you that you now have read-write access and the green lock icon should be gone.

OneDrive read-write message 

If it doesn’t then please read on.

Require documents to be checked out before they can be edited?

Go to Library Settings > Versioning:

Require Check Out

Another feature that’s not compatible with the full OneDrive sync experience. Again as before, you will have to disable this and it should resolve immediately. If not then continue reading…

Required Columns

Go to the Library Settings and check the columns:

Library Columns

Check with the columns on the library, if any of them are “required” this will cause a read-only sync. In the screen this is the case for my ‘Department’ field.

Wait a minute! Does this mean we lose the ability of having required metadata ???

Well, luckily NO. You just have to use a different approach and use Content Types.

The solution

Go to the Library Settings > Advanced Settings:

Allow management of Content Types


Content Types are a great way to have different types of content, each with a different set of metadata, workflows, template, and more. You should familiarize yourself with the concept of Site Columns, Site Content Types, List Columns, List Content Types, Content Type Inheritance, etc. It really depends on the use case but in my example I just modified the List-level Column and Content Type, in other cases this may not be the best approach. If you’re looking for more information on Content Types you can easily find this on the web.


To make your field required go into the Content Type (you can click on its name) and configure each field as optional, required or hidden.

List Content Type Information


The result is that the field/column itself is not configured as Required, but it is configured Required for the Content Type. And when uploading documents of that Content Type the user will still have to provide a value for the field.

Edit Item


Almost there…

If you followed the above steps you’ll still be having the original issue. This is because in the background the field will still be “Required”. And if you have Content Types enabled you won’t be able to change this setting because the UI hides it from the List Column Settings!

Here are a few options to resolve this situation:

  1. If you are using Site Columns then you can change the “Require” setting and push the change down to lists and libraries. This is quite easy to do but will impact all lists and libraries where this is used. You’ll have to inspect those lists to see if they have Content Types enabled (and that the Content Type requires the field) or users will no longer have to specify a value (= functionality change)
  2. You can disable Content Types on the Library, change the List Column setting and re-enable Content Types. This is also easy to do from the UI. All Content Types will be preserved during the operation but some users might be impacted during the operation. Afterwards, verify per Content Type which fields should be required.
  3. Use CSOM or PowerShell to directly manipulate the List Column settings.


Options (2) and (3) are rather similar, but if you prefer the latter here’s a PnP PowerShell script that should assist you. I like PowerShell because it is transparant and can easily be viewed and modified. And I like PnP and its CmdLets because it really abstracts complex operations. Note that you will have to install the PnP CmdLets first.


cls ## Variables $userName = "yourusername" $siteUrl = "yoursiteurl" $listName = "yourlistname" ## Script start if (!$cred) { $cred = Get-Credential $userName } Connect-PnPOnline –Url $siteUrl -Credential $cred ### $web = Get-PnPWeb $list = Get-PnPList $listName ### QUERY OR CHANGE $bChangeField = $false Get-PnPField -List $list | % { $f = $_ # List all required fields, except the built-in FileLeafRef field which is required but by design if ($f.Required -and $f.StaticName -ne 'FileLeafRef') { Write-Host ($f.StaticName) -ForegroundColor Red if ($bChangeField) { Set-PnPField -Identity $f -Values @{Required=$false} Write-Host (" -> updated") -ForegroundColor DarkYellow } else { Write-Host (" -> reporting only") -ForegroundColor DarkYellow } } }

The script has a flag to control the actual field update vs reporting only.

After running (with actual update) it should resolve the issue.

OneDrive read-write sync

if it doesn’t I’d be interested to hear about it in the comments!


Some list settings are not compatible with the OneDrive sync experience and make it a read-only sync. You can disable these via the UI or via code/script.

 Next >>