Users of Microsoft 365 can go to “My Microsoft 365 profile”:
and update profile providing some details like birthday, home/mobile phone, summary, education, hobbies, skills and projects. Some properties are text fields, some are metadata. Specifically – projects, “skills and expertise”, “schools and education” and “Interests and hobbies” are backed by metadata:
People can add information free, as the corresponding term store’s submission policy is “Open policy: Users can add terms from a tagging application.” by default.
The Problem
The problem is: all mentioned user profile properties are not connected to term store by default:
and everything users add to their profiles goes to the default “Keywords” term store under “System” term group:
(To ensure – a SharePoint admin can go to “More features” – “User Profiles” – “Manage User Properties” and “Content services” – “Term Store” from SharePoint admin center.)
Obviously, after some time there will be a mess… Universities, hobbies, skills and projects are different subjects and should not be in the same list.
Solution
Once the problem is understood, the solution would be straight-forward:
If you are just implementing Microsoft 365:
Create a Term Set
Map User Profile Property to a Term Set
The only you need is to
1. Provide permissions to yourself so you can create a term group and term store:
Under SharePoint admin center – Content Services – Term Store
2. Create a term group, e.g. “User Profile Properties”
and 3. come up with names for your term sets, as default naming is ambiguous/controversial:
How a user can see it in his/her personal profile (Delve)
SharePoint Admin Center User Profiles Properties Display Name
SharePoint Admin Center User Profiles Properties Internal Name
Project
Past projects
SPS-PastProjects
Skills and expertise: Here are some of my professional skills
Skills
SPS-Skills
Skills and expertise You can also ask me about
Ask Me About
SPS-Responsibility
Schools and education
Schools
SPS-School
Interests and hobbies
Interests
SPS-Interests
Create term set:
Configure submission policy, so users can add terms:
(alternatively, you may want to have closed submission policy but in this case you would pre-create terms so users can choose from existing)
Map User Profile Property to a Term Set (Under SharePoint admin center – More features – User Profiles – Manage User Properties):
If you already have users with their profiles filled with values
In case you already have users with their profiles filled with values, you need to deal with it, and you have 3 options:
Inform users about the change and that all values will be lost and ask them to update their profiles again
(if number of profiles/values relatively small) – just manually write it down and re-create after reconfiguration
Develop a custom PowerShell script to save all the values and custom PowerShell script to restore the values.
Published: May 1, 2022 Update from Mar 5, 2023: Microsoft confirmed this as valid solution. Update from May 20, 2024: still true Update from June 12, 2024: I have just found “ABP in Exchange Online“… Looking into it…
Scenario
You want specific users do not appear in Microsoft 365 SharePoint, Teams or Outlook search results. For instance, when user left company and the account is not deleted, but just disabled in Entra Id (Azure AD), so account is present and searchable. Or there are two accounts of the same person – main one and a secondary one – so you want secondary account is removed from org structure and search. Etc.
Solution
Set “ShowInAddressList” Azure AD User object property to false. It’s done using Az module, e.g. with PowerShell:
In many cases we do not need some accounts to appear in Microsoft 365 Search. Examples are:
a) secondary or admin accounts e.g. a person have several roles and several accounts under the same name, e.g. regular user: John Smith John.Smith@contoso.com administrative account: John Smith John.Smith.Admin@contoso.com b) role, shared or service accounts: marketing@contoso.com c) non-mail-enabled objects d) disabled accounts
Getting multiple search results for the same person might confuse users and even lead to miscommunication and broken processes.
There is a good article by Tania Menice (Microsoft): Exclude Users From Delve and SharePoint Online People Search with the latest updates explaining how it is done for classic search and stating that currently it is not possible for modern search, but Microsoft is working on it.
In short, the article says:
Set the profiles AD property msExchHideFromAddressLists to True or Yes,
Sync/wait, so finally SharePoint UPA service SPS-HideFromAddressLists property will be updated (as it is mapped to msExchHideFromAddressLists AD property)
Under SharePoint classic search – update query to: {searchboxquery} -“SPS-HideFromAddressLists”:1
It works perfect for classic search. The problem is it does not work as expected in modern Microsoft Search.
“People” vertical is not customizable so far. So we cannot change query in Microsoft 365 search to do the same trick. But… it seems like Microsoft is working on it so finally it should be done by some kind of ootb config.
Here is how different services or search entry points respect SPS-HideFromAddressLists SharePoint UPA property:
So only “People” vertical in Microsoft search does not respect SPS-HideFromAddressLists (msExchHideFromAddressLists).
(Modern) Microsoft 365 Search
What about cloud-based accounts (not synchronized from local AD)?
There is a configuration setting “Show in global address list” that does the same job. It’s under Microsoft 365 admin center -> Active Users -> User – Edit -> Mail -> Show in global address list:
And another configuration settings “Hide from global address list (GAL)” under Exchange Admin Center:
I tested behavior for different kind of accounts and here are results:
User Account
#1
#2
#3
#4
#5
Enabled
Yes
No
Yes
Yes
Yes
Licensed (E5)
No
Yes
Yes
Yes
Yes
m365 Admin Center: Show in Global Address List
n/a
No
No
Yes
No
Exchange Admin Center: Hide from global address list (GAL)
n/a
Yes
Yes
No
Yes
ShowInAddressList Entra Id property value
null
null
null
null
False
SPO UPA ‘SPS-HideFromAddressLists‘ value
False
False
False
False
True
Outlook Address List “All Users”
Shown
Office.com Search: Vertical “All”
Shown
Office.com Search: Vertical “People”
Shown
Shown
Shown
Shown
Bing Work Search: All/People verticals
Shown
Shown
Teams Search: “All” Vertical
Shown
Shown
Teams Search: “People” vertical
Shown
Shown
Shown
Shown
Microsoft 365 Profile card – Organization
Shown
Shown
Teams Profile card – Organization
Shown
Shown
Shown
Shown
Teams People Picker
Shown
Shown
Shown
Shown
SharePoint People Picker
Shown
Outlook People Picker:
Shown
* – some users can see changes after hours, for some it takes days
It seems confusing we have 4 properties responsible for the same:
“Show in Global Address List” under m365 Admin Center
“Hide from global address list (GAL)” under Exchange Admin Center
“ShowInAddressList” Azure AD User object property
“SPS-HideFromAddressLists” SharePoint User Profile property
Are these properties related to each other?
Let’s test it:
Action-Consequences (immediate reaction – minutes if not other mentioned)
“Show in Global Address List” under m365 Admin Center
“Hide from global address list (GAL)” under Exchange Admin Center
ShowInAddressList Azure AD User object property
SPS-HideFromAddressLists SharePoint User Profile property
New user created, license assigned
Yes
Off
null
False
Uncheck “Show in my organization address list” under Microsoft 365 admin center
No
On
after one minute: null after 24 hours: null
after one minute: False after 24 hours: False
Set “ShowInAddressList” Azure AD User object property to “True”
Yes
Off
True
False
Set “ShowInAddressList” Azure AD User object property to “False”
“Show in Global Address List” under m365 Admin Center and “Hide from global address list (GAL)” under Exchange Admin Center – same switch, i.e. if you change one – another is updated automatically Neither of them affect “ShowInAddressList” Azure AD User object property or “SPS-HideFromAddressLists” SharePoint User Profile property
“SPS-HideFromAddressLists” SharePoint User Profile property is not changeable. If you try to change the property value you get an error message: “Set-PnPUserProfileProperty : Property Not Editable: This property can not be modified.“
“ShowInAddressList” Azure AD User object property is editable and synchronized to “Show in Global Address List” under m365 Admin Center and “Hide from global address list (GAL)” under Exchange Admin Center, and also with “SPS-HideFromAddressLists” SharePoint User Profile property (takes minutes), but then search crawler must pick this change up (takes hours) to hide/show the user (this was tested and validated for cloud-born accounts only)
here Microsoft says: regarding showInAddressList – Do not use in Microsoft Graph. Manage this property through the Microsoft 365 admin center instead. Represents whether the user should be included in the Outlook global address list. See Known issue.
Known issue (Microsoft): showInAddressList property is out of sync with Microsoft Exchange. When querying users through Microsoft Graph, the showInAddressList property may not indicate the same status shown in Microsoft Exchange. We recommend you manage this functionality directly with Microsoft Exchange through the Microsoft 365 admin center and not to use this property in Microsoft Graph.
Disclaimer
I used and tested all cloud-born accounts only. I do not have on-prem AD, so If your users are synchronized from local AD – do your own research – is this property synced from some local AD property, and if so – set AD property instead.
Microsoft is constantly changing the product. So what I found out here now might differ with what you work with.
It’s a good idea to test/validate this solution in your non-prod environment and against test users in your prod environment.
Bottom line
Setting “ShowInAddressList” Azure AD User object property to “false” is the most effective way to hide user account from search, but it could be changed only with PowerShell:
UPDATE: this approach only works if the mobile number is stored in SPO UPA. If the mobile number is stored in AAD only, the admin will need to remove the mobile number from AAD for the affected users.
Scenario: you administer SharePoint Online Microsoft 365 tenant business asks you to remove mobile phone numbers from SharePoint User Profiles:
Solution:
As a SharePoint administrator, you can do it: 1. Start Microsoft 365 SharePoint Admin Center 2. Navigate to More Features -> User Profiles -> Manage User Properties
3. Under “Contact Information” -> Mobile phone -> Edit
4. Uncheck “Replicable”, Save, wait a minute or two 5. – Select “Default Privacy Settings”: “Only Me” – Uncheck “User can override” – Uncheck “Allow users to edit values for this property” – Uncheck “Show in the profile properties section of the user’s profile page” – Uncheck “Indexed”
6. Save
Note: Microsoft implemented new MS-Graph API that adds or deletes profile card custom properties using the profile card API in Microsoft Graph
your organization maintain custom active directory attributes – e.g. Campus Name, Employee Id, Hiring Category etc.
your organization use Microsoft 365 for collaboration
users want to search for custom properties like “Employee id” or refine search by custom properties like Campus Name
What is Microsoft saying
“The following Azure AD user attributes are synced to the UPA.” : (Azure AD attributes) – UserPrincipalName, DisplayName, GivenName, sn, telephoneNumber, proxyAddresses, PhysicalDeliveryOfficeName, Title, Department, WWWHomePage, PreferredLanguage, msExchHideFromAddressList, Manager Respective User profile property display names: Account Name, User Name, User Principal Name, Name, FirstName, LastName, Work phone, Work Email, SIP Address, Office, Title, Job Title, Department, Public site redirect, Language Preferences, SPS-HideFromAddressLists, Manager (here)
Q: “Why isn’t it possible to map additional properties for UPA synchronization to sync from Azure AD to the User Profile Application?” A: “UPA synchronization is limited to a preconfigured set of properties to guarantee consistent performance across the service.” (here)
“You can make the following attributes from Azure Active Directory (Azure AD) visible on users’ profile cards. These attributes are not case-sensitive: UserPrincipalName, Fax, StreetAddress, PostalCode, StateOrProvince, Alias” (here)
“You can add any of the 15 Azure AD custom extension attributes to users’ profile cards… Custom properties are not searchable and can’t be used to search for people across Microsoft apps and services.” (here)
Solution
It takes a few steps to solve the problem:
create a custom property under SharePoint Online User Profiles service
synchronize AD/AAD attribute with SPO User Profile custom property
configure Search Schema – map crawled property to managed property
Detailed:
Create a custom property under SharePoint Online User Profiles service
Ensure you have a SharePoint Administrator role activated
Navigate to SharePoint Admin Center – more features – User Profiles – Manage user properties – New Property
Configure custom property according to your needs, – ensure “Policy Settings” “Default Privacy Setting:” Everyone is selected – ensure “Search Settings” “Indexed” is selected
Hint: you can fill this property for some user profiles – for search to pick it up and crawl the property – so you could configure search schema mapping before synchronizing property from Active Directory
Synchronize Active Directory attribute to SharePoint Online User Profile
That would be a custom solution – e.g. scheduled PowerShell script. You can host this script in Azure Functions if you sync Azure AD attributes to SPO or use on-prem machine if you need access to local AD.
PowerShell Script example (TBP)
Configure Search Schema – map crawled property to managed property
Ensure you have a SharePoint Administrator role activated
Navigate to SharePoint Admin Center – More features – Search – Manage Search Schema
Select Crawled Properties and ensure search picked up your custom property and crawled it – you should see your property name under Category: People.
Full-text search and/or query-based search
If you want your custom property is generally available in full-text-search – i.e. user simply enter value in a search bar and gets results – typical scenario might be an employee id – here are the steps (under Search Schema)
create a new managed property
for Full-text search
select Searchable
under Advanced searchable settings – select Full-text index: PeopleIdx
for Query-based search – select Queryable and Retrievable
map this managed property to crawled property
Free-text search: you just enter what you search for into search bar and click search.
Query-based search allows you to use KQL – e.g. you are searching for keyword “PowerShell” with full-text search, but want only people with PowerShell skills located in a specific building or campus – search query might look like “PowerShell campus:Stanford”
Refine search with custom property
If you want to be able to refine your search with custom property – in this case the steps are (under Search Schema):
under Managed Properties – select a refinable string property that is not taken (not mapped) – e.g. RefinableSting53
setup alias – so you could refer to this RefinableSting53 by meaningful name
The following solution is for Classic Search only.
What I did is:
User profile services -> Manage User properties: create custom property like “HideFromPeopleSearch”, boolean, do not allow users to edit value, Indexed
Client-side PowerShell script using PnP library:
Connect-PnPOnline -Url https://domain-admin.sharepoint.com
…
$nonPeople = Get-ADUser -filter … # based on what’s in your AD and how you separate people and non-people accounts
foreach($account in $nonPeople) {
Set-PnPUserProfileProperty -Property ‘HideFromPeopleSearch’ -Value ‘True’ -Account $account.UserPrincipalName
}
SearchCenter -> Site Settings -> Search Schema: use any pre-created RefinableString managed property (e.g. RefinableString33), add mapping to crawled property people:HideFromPeopleSearch,
SearchCenter -> Site Settings -> Search Query rules: Local People Results, new Query rule, change ranked results by changing query, {searchTerms} -RefinableString33=True
