What I did is:
User profile services -> Manage User properties: create custom property like "HideFromPeopleSearch", boolean, do not allow users to edit value, Indexed
Here are some resources to study, learn, improve your skills on Microsoft SharePoint, SQL, Office 365, Azure:
Problem: non-personal accounts (service accounts, functional accounts) are shown in Office 365 people search, which might confuse users.
There is a managed property called "HideFromDelve"
I found pretty useless IIS Log Parser (with Studio) for SharePoint.
The reasons are - blank spaces and "%20" symbols in Url in SharePoint IIS logs which confuses IIS Log Parser and prevents you from search through logs using IIS Log Parser
i.e., if your SharePoint users want to investigate their file "/sites/Very%20Important%20site/much%20more%20important%20unique%20file.docx" - you will stuck.
finally, I found plain Powershell commands the most useful to parse IIS logs, like this:
OneNote document is not a one file, but a number of files in a folder. You can save OneNote document in SharePoint and it would looks like a file, but internal implementation of OneNote in SharePoint is actually a folder content type.
And if you try to assign properties to OneNote document - you just can't.
I haven't seen any clear instructions from Microsoft on the subject. And here we have an “unsupported” workarounds. Actually, there are two: “Change Content Type” way and “Quick Edit View” way.
As you know, Project Server 2016 is actually a service application on SharePoint Server 2016.
Which means if you want Project Server 2016, you must have SharePoint 2016 first.
But if you have SharePoint 2016 farm, it's much easier to get Project 2016. Moreover, once you build robust, scalable and high-available SharePoint, you get the same to you Project "for free".
NB: Project is licensed separately.
No physician is really good before he has killed one or two patients. ~Hindu Proverb
No architect is really good before he has killed one or two farms. ~Vladilen Karassev