Q: What permission or role is required to get search Usage analytics reports
A: To see Microsoft 365 Search and intelligence usage analytics reports you’d need “Global reader” or “Search editor” role.
Q: What permission or role is required to get access to Search Feedback under Microsoft 365 admin center – Settings – Search & intelligence – Insights – Feedback
A: You’d need at least “Global reader” or “Search editor” role.
Developers in the organization can use both – Azure Apps and SharePoint Apps to work with SharePoint sites in their “daemon” applications.
It is recommended to use Azure apps so, you want to know – what are SharePoint Apps registered and their owners, who registered SharePoint Apps. Eventually you would disable SharePoint Apps-only principal but before that you’d move Devs from SP-App-only to Azure App (see Disable Custom App Authentication).
(SharePoint App-only service principals aka SP-App-Only are SPN or App registered from within SharePoint using AppRegNew.aspx system page).
One of the approaches – track Apps/Owners with Unified Audit Log
The following PowerShell code:
$operations = 'Add service principal.'
$recordType = 'AzureActiveDirectory'
Search-UnifiedAuditLog -StartDate $start -EndDate $end -ResultSize $resultSize -Formatted -Operations $operations -RecordType $recordType
returns events with operation = ‘Add service principal.’ Nice, but…
if an app was registered in Azure – event contains an UPN under UserIds property:
Unfortunately, in case with registering app in SharePoint, an audit log event will be like:
i.e. UserId registerd is “spo_service@support.onmicrosoft.com”, so we do not know who registered a SharePoint-only app
In theory – we could use events recorded immediately before and after “Add service principal” event to track a user and site who has registered a SharePoint-only app… But for me it seems like too complicated for automation.
Instead we can do simple search through audit log for events “AppRegNew.aspx page visited”. This gives us a good approximation of who registered SP-App-only principal. Worst scenario – we reach more people than we really need (including those who started registering sp-app-only but did not complete) but all of them would be definitely our target auditory.
Consider the following code:
$freeText = "appregnew" $operations = 'PageViewed' $recordType = 'SharePoint' $results = Search-UnifiedAuditLog -StartDate $start -EndDate $end -ResultSize $resultSize -FreeText $freeText -Operations $operations -RecordType $recordType
this would give you all users who loaded “/_layouts/15/appregnew.aspx” page
Update: Sites.Selected API MS Graph permissions was introduced by Microsoft in 2021. It was a good move towards site-level development, but still developers were limited with only what MS Graph API provides for SharePoint dev.
So devs had to use AppInv.aspx at site level to provide ACS permissions to their apps to be able to use SharePoint CSOM and REST APIs.
Recently Microsoft introduced Sites.Selected SharePoint API permissions for registered Azure Apps! So now devs should be fully happy without ACS-based permissions.
OnNew:
Set(SharePointFormMode, “NewForm”); NewForm(formNew); Navigate(screenNew, ScreenTransition.None)
OnEdit:
Set(SharePointFormMode, “EditForm”); EditForm(formEdit); Navigate(screenEdit, ScreenTransition.None)
OnView:
Set(SharePointFormMode, “ViewForm”); ViewForm(formView); Navigate(screenView, ScreenTransition.None)
OnSave – If(SharePointFormMode=”CreateForm”, SubmitForm(CreateItemForm), If(SharePointFormMode=”EditForm”, SubmitForm(EditItemForm)))
OnCancel – If(SharePointFormMode=”CreateForm”, ResetForm(CreateItemForm), If(SharePointFormMode=”EditForm”, ResetForm(EditItemForm)))
Can I use PowerShell 7 “-Parallel” option against SharePoint list items with PnP.PowerShell? Can I run something like:
$items | ForEach-Object -Parallel {
$listItem = Set-PnPListItem -List "LargeList" -Identity $_ -Values @{"Number" = $(Get-Random -Minimum 100 -Maximum 200 ) }
} Yes, sure… But! Since it’s a cloud operation against Microsoft 365 – you will be throttled if you start more than 2 parallel threads! Using just 2 threads does not provide significant performance improvements.
So, try PnP.PowerShell batches instead. When you use batching, number of requests to the server are much lower. Consider something like:
$batch = New-PnPBatch
1..100 | ForEach-Object{ Add-PnPListItem -List "ItemTest" -Values @{"Title"="Test Item Batched $_"} -Batch $batch }
Invoke-PnPBatch -Batch $batchAdding and setting 100 items with “Add-PnPListItem” and “Set-PnPListItem” in a large (more than 5000 items ) SharePoint list measurements:
| Add-PnPListItem Time per item, seconds | Set-PnPListItem Time per item, seconds | |
| Regular, without batching | 1.26 | 1.55 |
| Using batches (New-PnPBatch) | 0.10 | 0.80 |
| Using “Parallel” option, with ThrottleLimit 2 | 0.69 | 0.79 |
| Using “Parallel” option, with ThrottleLimit 3 | 0.44 (fails level: ~4/100) | 0.53 (fails level: ~3/100) |
Adding items with PnP.PowerShell batching is much faster than without batching.
More:
Scenario 1: You have a large (>5k items) list in SharePoint Online.
You need to delete this list.
Scenario 2: You have a large (>5k items) list in SharePoint Online.
You need to delete all the list items, but keep the list.
GUI: Microsoft improved SharePoint, so now it takes ~1 second to delete any SharePoint list, including 5000+ items list via GUI.
PowerShell: “Remove-PnPList -Identity $list” command works very fast – ~1 second to delete entire list with >5000 items.
In this scenario we need to keep the list, but make it empty (clean it out).
GUI: You can change the list view settings “Item Limit” to <5000, but (at least in my experience) when you try to select, let say, 1000 items and delete them via GUI – it says “775 items were not deleted from large list”:
so this option seems like not a good one.
ShareGate: 3-rd party tools like Sharegate, SysKit give a good results too.
PowerShell
Try this PowerShell command with ScriptBlock:
Get-PnPListItem -List $list -Fields "ID" -PageSize 100 -ScriptBlock { Param($items) $items | Sort-Object -Property Id -Descending | ForEach-Object{ $_.DeleteObject() } }
or this PowerShell with batches:
$batch = New-PnPBatch
1..12000 | Foreach-Object { Remove-PnPListItem -List $list -Identity $_ -Batch $batch }
Invoke-PnPBatch -Batch $batchfor me both methods gave same good result: ~17 items per second ( ~7 times faster than regular).
Consider the following scenario: in a large SharePoint list there are items you need to delete and the rest must stay (typical case might be to purge old items).
How fast are PnP batches? What is better in terms of performance – ScriptBlock or Batching? Here are my measurements:
| Time elapsed, seconds | with batches | with scriptBlock | without batches |
| Add-PnPListItem (100 items) | 6-10 seconds | 60-120 seconds | |
| Add-PnPListItem (500 items) | 20-40 seconds | 230-600 seconds | |
| Add-PnPListItem (7000 items) | 314-600 seconds | ||
| Add-PnPListItem (37000 items) | 3200 seconds | ||
| Remove-PnPListItem (1000 items) | 58-103 seconds | 58 seconds | 430-1060 seconds |
| Remove-PnPListItem (7000 items) | 395-990 seconds 3000 seconds | 397-980 seconds | |
| Remove-PnPListItem (30000 items) | one big batch : 13600 seconds 30 batches 1000 items each: 3500 seconds |
both – PnP PowerShell batches and ScriptBlocks are 7-10 times faster than plain PnP PowerShell!
Note… For the sake of history: It used to be like that for 5k+ lists:
“Remove-PnPList” fails with a message “The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator”. Deleting with GUI fails too.
References: