What needs to be excluded and why
ASP.NET creates and replaces short-lived assemblies, cache files, and hash.web during compilation. Microsoft documents that antivirus activity in monitored ASP.NET directories can trigger unintended AppDomain unloads. Real-time inspection can also contend with rapidly appended IIS request logs, showing up as access-denied compilation errors, failed background jobs, HTTP 500 or 503 responses, extra CPU and disk latency, or repeated application-pool recycling.
Exclusions are controlled security exceptions, not a reason to stop the SentinelOne agent. Apply SentinelOne Singularity exclusions for IIS only to the affected server group and the exact paths in use. Never exclude an entire drive or global types such as *.aspx, *.dll, *.log, or *.tmp.
Where to add the exclusions in the SentinelOne Management Console
Choose the smallest scope
In current consoles, open Policies and Settings > Endpoint Security and Cloud Workload Security > Exclusions. Older releases may show Settings > Exclusions, or Policy Settings > selected policy or group > Exclusions. The important controls are the Account, Site, or Group scope selector and the Exclusions panel.
Create a dedicated IIS server group when practical. An account-level rule can expose workstations and unrelated servers that do not need the exception.
Create each exclusion
Select New Exclusion, Create Exclusion, or the plus button. In the newer workflow, choose Agent Interoperability, select Windows, and click Continue. Then choose Path, File/Path, or Process, enter one item, enable Include subfolders only for a directory, add a change-ticket reference, and select Save.
For w3wp.exe, use its full executable path and leave Apply to child processes off if that control is available. This preserves scrutiny of unexpected cmd.exe or powershell.exe children.
Select the least permissive mode
Suppress Alerts addresses a confirmed false positive but does not reduce the monitoring that causes an interoperability or performance issue. Start with Interoperability for a proven scanning conflict. Use Performance Focus only when Interoperability fails and SentinelOne Support approves the added loss of visibility.
After saving, let the agent receive policy, then recycle the affected application pool. Reboot the server in a maintenance window if the console help or Support says the selected mode requires it.
The actual exclusion list
Microsoft's ASP.NET and Windows Server guidance is the workload authority for these locations. Add only paths that exist and serve the affected app pool.
ASP.NET and IIS folders
For .NET Framework 4.x, the common compilation paths are:
%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\, for 64-bit app pools%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\, for 32-bit app pools
For an application still using CLR 2.0, use the matching Framework64\v2.0.50727 or Framework\v2.0.50727 path. Do not add legacy paths to servers that do not use them.
Other published IIS locations are:
%SystemDrive%\inetpub\temp\, or the narrowerIIS Temporary Compressed FilesandASP Compiled Templatessubfolders%SystemRoot%\IIS Temporary Compressed Files\, if present%SystemDrive%\inetpub\logs\, when IIS uses the default request-log location- The actual custom request-log directory shown in IIS Manager under the server or site Logging > Directory
Microsoft also lists the applicable .NET Framework Config directory, %SystemRoot%\System32\inetsrv\config\, the application's physical root, and its parent application root. These are sensitive locations. Add them only when testing identifies a collision there, and substitute the real site path, such as D:\Sites\ContosoPortal, instead of assuming %SystemDrive%\inetpub\wwwroot.
IIS process files
Microsoft's Web Server role list includes these process paths:
%SystemRoot%\System32\inetsrv\w3wp.exe%SystemRoot%\SysWOW64\inetsrv\w3wp.exe, for applicable 32-bit installations- The exact configured path to
php-cgi.exe, only when the site uses PHP through FastCGI
Treat process exclusions as conditional, not baseline. w3wp.exe hosts internet-facing code and is frequently abused by web shells, so try the temporary compilation and log folders first. Do not broadly exclude csc.exe, vbc.exe, cmd.exe, or PowerShell.
Verification
Confirm policy delivery
In the Exclusions panel, confirm each entry is enabled and shows the intended Windows OS, mode, path, and Site or Group scope. Open the endpoint record and verify that the server belongs to that scope, is online, and has a policy update later than the change.
Exercise IIS and inspect evidence
During a maintenance test, recycle one noncritical app pool and send at least 20 representative requests. Confirm that the site warms up, new compiled files appear, IIS logs continue growing, and the previous failure does not recur.
Run these checks in an elevated PowerShell session:
powershell Import-Module WebAdministration Get-Website | Select-Object Name,State,PhysicalPath
$temp = Join-Path $env:SystemRoot 'Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files' Get-ChildItem $temp -Recurse -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 10 FullName,LastWriteTime
$logs = Join-Path $env:SystemDrive 'inetpub\logs\LogFiles' Get-ChildItem $logs -Recurse -File -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 10 FullName,Length,LastWriteTime
Review Event Viewer > Windows Logs > Application and System for ASP.NET, .NET Runtime, WAS, and W3SVC-WP events. Compare the same 30-minute window in SentinelOne Activities, Alerts, or the endpoint timeline. Fewer lock, access-denied, compilation, and unexpected-recycle errors, with normal request logging, is stronger proof than the mere absence of a SentinelOne alert.
Common pitfalls and what to do if the exclusion is not honored
The path or scope is wrong
Copy the observed path from the SentinelOne event or IIS configuration. Check drive letters, 32-bit versus 64-bit Framework directories, Include subfolders, inheritance, and the endpoint's assigned Group. Use one path per exclusion.
The process still has the old policy state
Recycle the specific app pool after policy delivery. For Interoperability or Performance Focus exclusions that remain ineffective, reboot during an approved window and test again.
IIS uses custom locations
Use Get-Website, IIS Manager's Logging feature, applicationHost.config, and any web.config compilation tempDirectory setting to find the real paths. A default C: rule cannot match logs or site content moved to D:.
SentinelOne is not the blocker
Check NTFS permissions, free disk space, Microsoft Defender, Controlled Folder Access, AppLocker or WDAC, and application-pool identity rights. If the problem remains, record an exact failure timestamp, app-pool name, failing path, agent version, and Windows event IDs, then fetch endpoint logs from the console and open a SentinelOne support case. Windows agent logs under C:\ProgramData\Sentinel\logs are protected and may require Support to interpret.
Where to find the vendor's authoritative documentation
Use the SentinelOne Resource Center as the canonical public source. For version-specific UI labels and exclusion semantics, use the Management Console help, SentinelOne customer support portal, or your authorized managed security provider.
For the workload paths, compare the current Microsoft articles for ASP.NET antivirus exclusions and Windows Server Web Server exclusions. Review every exception after an IIS, .NET, application, or SentinelOne agent upgrade, and remove entries that no longer have an operational justification.