What needs to be excluded and why
SentinelOne Singularity real-time protection is valuable on SharePoint servers, but SharePoint is unusually sensitive to file locks and I/O latency. Search crawl components, the indexer, IIS worker processes, ULS logging, ASP.NET compilation, BLOB cache writes, and SQL Server database activity can all create rapid file churn that endpoint agents may inspect at the wrong time.
The goal is not to turn off protection for the farm. The practical fix is to scope SentinelOne Singularity exclusions for SharePoint Server to Microsoft-published SharePoint and SQL Server antivirus exclusion locations, then apply the narrowest SentinelOne exclusion mode that resolves the conflict.
Where to add the exclusions in the SentinelOne Management Console
Choose the right scope
In the SentinelOne Management Console, add exclusions at the smallest scope that covers the affected servers. For most farms, that means a dedicated Site, Group, or Policy for SharePoint Web Front End, Application, Search, and SQL roles.
Avoid tenant-wide exclusions unless every endpoint in the tenant runs the same workload. SharePoint exclusions that are reasonable on a search server are excessive on laptops or general-purpose file servers.
Add a new exclusion
Console labels change between SentinelOne releases, but the path is generally one of these:
- Settings > Exclusions > Path or File/Path
- Policy Settings > select the relevant policy or group > Exclusions
- Global Settings > Exclusions, if your organization manages exclusions centrally
Select Add Exclusion, Create Exclusion, or the + button. For Windows servers, choose Windows as the operating system and use Path, File, or Process depending on the item.
Pick the exclusion mode carefully
Start with a path or process exclusion that suppresses scanning only where the vendor guidance requires it. If the console offers Agent Interoperability, Interoperability, or Performance Focus, use the least permissive mode that fixes the SharePoint or SQL issue.
SentinelOne advises caution with Interoperability and Performance exclusions because they reduce agent visibility and mitigation for the excluded item. Document the business reason, affected servers, change ticket, and rollback plan before saving.
The actual exclusion list
SharePoint Server Subscription Edition, 2019, and 2016
Use the actual drive letter where SharePoint is installed. Microsoft uses Drive: as a placeholder, commonly C:.
Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\LogsDrive:\Program Files\Microsoft Office Servers\16.0\Data\Office Server\Applications- The custom SharePoint search index location, if your farm stores index files outside the default path
Drive:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET FilesDrive:\Windows\Microsoft.NET\Framework64\v4.0.30319\ConfigDrive:\ProgramData\Microsoft\SharePointDrive:\Users\<SharePoint service account>\AppData\Local\TempDrive:\Users\<SharePoint search service account>\AppData\Local\TempDrive:\Users\Default\AppData\Local\TempDrive:\WINDOWS\System32\LogFilesDrive:\Windows\SysWOW64\LogFilesDrive:\inetpub\wwwroot\wss\VirtualDirectories\<web application folder>Drive:\inetpub\temp\IIS Temporary Compressed Files- The disk-based BLOB cache location, for example
C:\Blobcache, if configured
SharePoint Server 2013
For SharePoint 2013 application and search servers, include the SharePoint Server 2013 Office Server paths plus the SharePoint Foundation 2013 paths that apply to your farm.
Drive:\Program Files\Microsoft Office Servers\15.0\Data- The custom search index location, if different from the default data path
Drive:\Program Files\Microsoft Office Servers\15.0\LogsDrive:\Program Files\Microsoft Office Servers\15.0\BinDrive:\Program Files\Microsoft Office Servers\15.0\Synchronization ServiceDrive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LogsDrive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\Data\Applications, only where SharePoint Foundation Search is running- The BLOB cache location, if configured
SQL Server hosts used by SharePoint
If SQL Server runs SentinelOne, exclude the database and log file locations configured for the SharePoint SQL instance. Do not guess these paths from another environment.
- SQL data files: directories containing
.mdfand.ndf - SQL log files: directories containing
.ldf - SQL backup folders containing
.bakand.trn, if backups land locally before being copied elsewhere - SQL full-text catalog folders, commonly
...\MSSQL\FTDATA - SQL trace file locations containing
.trc, if SQL tracing or auditing is enabled - SQL cluster locations such as the quorum drive,
C:\Windows\Cluster, and the MSDTC directory, where applicable
Typical SQL processes to exclude, where present, are sqlservr.exe, sqlagent.exe, sqlbrowser.exe, and SQLDumper.exe. Scope these to the installed SQL Server binaries, not every executable with a matching name on the server.
SharePoint and IIS processes
Process exclusions should be used sparingly and only when path exclusions do not resolve the issue. Common SharePoint farm processes that may be involved include noderunner.exe, hostcontrollerservice.exe, w3wp.exe, OWSTIMER.EXE, and Microsoft.SharePoint.exe workloads launched by farm services.
For most farms, path exclusions for Microsoft-published folders are safer than broad process exclusions for w3wp.exe, because IIS worker processes can host many applications.
Verification
Confirm SentinelOne policy assignment
In the SentinelOne console, open the affected endpoint and confirm it is in the Site, Group, and Policy where the exclusions were added. Check the endpoint details or policy panel for a recent policy update time after the exclusion change.
Allow several minutes for policy propagation. For Interoperability or Performance Focus changes, restart the affected SharePoint service, IIS application pool, SQL service, or the server during a maintenance window if SentinelOne guidance or support requires it.
Check SharePoint health
On a SharePoint server, review ULS logs under Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Logs or the equivalent version folder. Look for fewer access denied, file locked, crawl, and index component errors after the exclusions apply.
Useful PowerShell checks include:
Get-SPTimerJob | Where-Object {$_.LastRunTime -gt (Get-Date).AddHours(-4)} | Select Name,LastRunTime,Status
Get-SPEnterpriseSearchStatus -SearchApplication <Search service application>
Get-Process noderunner,w3wp,OWSTIMER,sqlservr -ErrorAction SilentlyContinue | Select ProcessName,Id,Path
Check Windows and SQL logs
Use Event Viewer to review Windows Logs > Application and System on SharePoint and SQL servers. Also check SharePoint-specific event sources, SQL Server events, and service control manager events around the time jobs previously failed.
On SQL Server, review the SQL ERRORLOG for I/O stalls, database open errors, backup failures, or full-text catalog problems. A successful fix should reduce lock-related failures without removing SentinelOne visibility across unrelated paths.
Common pitfalls and what to do if the exclusion is not honored
The path does not match the agent view
SentinelOne may require device-style paths, wildcard syntax, or exact casing rules depending on console version and exclusion type. If a standard Windows path does not apply, compare it with the path shown in the SentinelOne event details and recreate the exclusion using that observed path format.
The exclusion was added at the wrong scope
A common mistake is adding the exclusion globally in documentation but locally in the wrong SentinelOne Site or Group. Confirm the endpoint is actually receiving the policy that contains the exclusion.
The service was never restarted
Some exclusions do not affect already-running processes until the process restarts. Recycle the affected IIS application pool, restart SharePoint Timer Service, restart the SharePoint Search Host Controller where appropriate, or reboot during a maintenance window for deeper interoperability changes.
The farm uses custom locations
SharePoint farms often move search indexes, BLOB cache, SQL data, SQL logs, and backups to non-default volumes. Use Central Administration, SharePoint Management Shell, SQL Server configuration, and your build documentation to identify the real locations before creating exclusions.
The exclusion is too broad
Do not exclude C:\, all of Program Files, or every IIS folder because one crawl component failed. Broad exclusions create blind spots and make incident response harder. If a broad temporary exclusion is needed for emergency recovery, replace it with exact paths after service is restored.
Where to find the vendor's authoritative documentation
SentinelOne product behavior, console labels, and exclusion modes can change by management console and agent version. Use the SentinelOne resource center at https://www.sentinelone.com/resources/ as the canonical public starting point, and use the SentinelOne support portal or your managed security provider for version-specific exclusion articles.
For the SharePoint and SQL paths themselves, Microsoft publishes the authoritative workload guidance. Review Microsoft Support guidance for SharePoint antivirus exclusions and Microsoft Learn guidance for configuring antivirus software with SQL Server before committing production changes.