This post was most recently updated on July 26th, 2024.
3 min read.This post describes a peculiar problem that a customer had. In their intranet, all of their employees had a managed metadata -typed managed property in SharePoint User Profile Service and a mapping from that property to RefinableString31. RefinableString31, in turn, was used on Search DisplayTemplates to show the textual value of the managed metadata field.
Symptoms
The mapping and displaying of the values worked beautifully – except for one user. Her people search results profile wouldn’t show her office address no matter how long the customer waited for the content to be reindexed, even though the data did exist in Active Directory.
The DisplayTemplate was custom-made, and the relevant part is shown below.
From the JavaScript code that SharePoint generates from the DisplayTemplate, there was no value for the RefinableString31 even though the mapping was made correctly. The mapping can be checked from: https://[tenant]-admin.sharepoint.com/_layouts/15/searchadmin/ta_managedproperty.aspx?property=RefinableString31&level=tenant (replace [tenant] with your tenant and RefinableString31 with your property).
What was even more bizarre was that for other users the value was there – nothing strange there! It was just this one user with the issue!
Solution
Now, quite a few things can cause the mapping, crawling or data populating process to fail, so we need to apply the process of elimination to find the step that resolves the issue for us! In this case, the following things were already working, so that narrows the scope of the investigation down a lot:
- Mapping was okay because for other people the search results had the value for RefinableString31.
- User Profile Service had the value for the managed metadata field… So the profile in the AD and the synchronization were apparently working.
- Indexing had gone through because other fields had fresh values and other users had values.
It was just this one user with this one field that had no value in the search index, even though the field had a value in the user profile property.
What was left, was some kind of obscure problem in search crawling, and boy would that not be a surprise at all.
In on-prem situations, this is pretty straightforward to fix – launch a new full crawl for the content source where mysites/people directory is, and before or later it’ll finish and you’ll have your data. In SharePoint Online you can’t do that, so we had to figure out another way.
Quick googling revealed that SharePoint Online does not do full crawls for the People results source. Instead, it reindexes all user profiles that have values that have changed at the next time incremental crawl runs. This, typically, can be anything from 2-8 hours depending on the farm load. This means that our next option is to make sure the crawler picks this field up as a modified one and updates the value!
So, quite simply, I accessed the problematic user’s profile in SharePoint Online User Profile Service (found from an URL similar to https://[tenant]-admin.sharepoint.com/_layouts/15/tenantprofileadmin/ProfMngr.aspx), edited the About me -field by adding one space to the end (this was to make sure something had actually changed) and saved the profile.
The next day the profile was fine. Yay!
And just in case it wasn’t, the next thing would’ve been to use Mikael Svenson’s SPO-Trigger-Reindex -Powershell Script to force SharePoint Online to reindex the profile. It’s a useful script, that I luckily didn’t need this time.
Some further reading
- http://spr.com/overcoming-office-365sharepoint-online-development-challenges-part-2/
- https://github.com/wobba/SPO-Trigger-Reindex
- http://sharepoint.stackexchange.com/questions/147500/managed-properties-not-available-as-refiners-on-content-search-web-part-sharepo
- How to solve keyboard shortcuts not working in Google Chrome on Windows? - September 10, 2024
- Search (and secretly, sync) broken in OneNote? A quick fix! - September 3, 2024
- “Destination Path Too Long” when copying files in File Explorer? Easy workaround(s)! - August 27, 2024