Over last few weeks I’ve received a number of questions about Delve modifications and administration. Delve is not a very configurable service and I’ve had questions in the past on how to exclude some users from appearing in the service. Those questions were a repeating theme for a while now, especially when the company has a strict policy on which users should be visible to others.
There were some UserVoice cases related to the issue, with one being opened for more than 4 years, but never reached a threshold that may have pressured Microsoft into development of the requested features. Now, when UserVoice partnership with Microsoft is coming to an end in 2021 it’s hard to predict whether this issue will be raised again on the new platform.
Ok, let’s dig in. Delve for admins is not giving us any customizations and that is why we should look into SharePoint and User attributes.
One of the attributes we know that hides users and plays with their visibility is msExchHideFromAddressLists. Attribute is available in the on-premises Active Directory environment and should be set there. Let’s look into it in more detail.
There are several ways to setup your tenant depending on the environment your Company has. If you have a cloud only environment, which means that it is not connected to your on-premises Active Directory domain and user identities are not synced, you may have a little problem. Unfortunately all of the settings presented here are not working for cloud only environments and local AD is a prerequisite.
Ok, let’s assume that you already have local AD. If you have your user identities synced to the cloud – that is great, if not you can follow guide available here – best after you prepare Active Directory for the setup.
Active Directory setup
Now let’s go back to the appropriate attribute – msExchHideFromAddressLists. It is not available out-of-the-box after simple AD deployment. Attribute in question is related to the Exchange Server and for it to be available you need to either install Exchange Server or take an easier path – only extend the Active Directory Schema. If you haven’t done this before, you can follow the steps below:
- Download Exchange Server ISO from official Microsoft sources,
- Ensure your account has appropriate permissions and is a member of Schema Admins and Enterprise Admins security groups,
- Update your .Net Framework on the server,
- Reboot your server – there may be some previous installations and pending reboots after them,
- Mount ISO on the Domain Controller. It needs to be a member of the Active Directory domain in question and site as the schema master,
- Open the Elevated Command Prompt and run:
<DriveLetter>:\Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareSchema
- If you have only one Domain Controller you are set and ready to go, if not you need to run the following command:
<DriveLetter>:\Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD /OrganizationName:"<OrgNameHere>"
- Wait for the replication and run Azure AD Connect to setup identity sync.
Why we use msExchHideFromAddressLists
Why to focus on this attribute? That one is easy. msExchHideFromAddressLists contents are mapped to SharePoint Online attribute SPS-HideFromAddressLists during the directory synchronization process via Azure AD Connect and this is what we want. Delve is set to automatically exclude and filter users with SPS-HideFromAddressLists set to true.
Attribute changes and checks
You may go ahead and set appropriate values to the attribute. As you can see I have some users in my lab. I’ve set up Azure AD Connect to sync O365-synced OU to the cloud:
With default setup users are visible in Delve:
Let’s set required attribute to TRUE:
If the attribute is not propagated to Azure AD you may need to fill mailNickname attribute. This is a common issue while operating without an Exchange Server.
After changing User attributes you need to wait for the crawl and re-indexing of SharePoint contents. You can take this time to remove User from Organization View in Delve and across your Microsoft 365 tenant. If this part is neglected it will be possible to find the user from there. After the re-indexing results should look similar to this:
When Classic Sites were still common in SharePoint Online there were some additional steps to be taken in order to interact with SharePoint People Search. Currently there is no Search Site dedicated to Users and your job ends here. SPS-HideFromAddressLists is taken into account by SharePoint People Search and no additional steps are required.
If you still can access the old People Search Results page you may need to change the query there. To check if any additional actions are required of you, you can navigate to:
If you were able to access the page please follow the steps below:
- Edit Search Results page
- Edit People Results Web Part
- Change query
- Change Query Text from:
Make sure you use quotation marks!
- Apply changes to the Search results Web Part
- Check-in changes to the Page
- Publish changes
And now you are all set!