This post was most recently updated on September 30th, 2022.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.
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.
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!
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!
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. That is one darn useful script, by the way.
Some further reading
- How to fix catastrophic mouse/touch device input lag on Windows 10? - January 23, 2024
- How to update RAM on Synology DS423+? - January 16, 2024
- How to work around Docker failing to access WSL on Windows? - January 9, 2024