Which Folders Can You Exclude From Antivirus for SQL Server?
A workload exclusion and an unprotected host are different decisions. Scope the exception to the demonstrated interaction and keep the other controls.
Two sentences get used interchangeably in database reviews, and they mean very different things. One says a specific workload needs a specific exception; the other says the host no longer needs endpoint protection. The first is a scoped engineering decision, and the second is an unowned risk. Separating them is the whole task, and it starts with what the server actually does.
Two Sentences That Sound the Same
An exception names a path, a process or a file type and gives a reason for it. An abandonment removes a control from a machine and gives a reason for that instead. The two can produce similar performance numbers and completely different security postures.
A database server is a poor candidate for abandonment because it stores the data everything else depends on. It is also a poor candidate for a desktop-grade policy, because scanning files a database holds open causes problems a desktop never sees. The honest position sits in the middle, and it has to be argued rather than assumed. That argument is what a review should capture.
Compare the Exception and the Abandonment
Put the two options side by side on four points: what stays protected, what becomes exposed, who owns the decision, and what evidence supports it.
A scoped exception leaves the rest of the host under the same protection as before, keeps the decision with a named owner, and rests on a reproduced symptom. An abandonment removes protection from everything and usually rests on the claim that the machine is not exposed. That claim has to survive the server's actual roles, because file shares, linked servers, agent jobs and administrative file transfers all create exposure a firewall never sees. Only one column of the comparison below survives a change of ownership, since it records what was decided and why.
| Point | Scoped exception | Blanket exclusion |
|---|---|---|
| Coverage | Only the named paths or processes | The whole host |
| Evidence needed | A reproduced interaction | An argument about exposure |
| Owner | A named reviewer with a date | Usually nobody |
| Behaviour after an update | Reviewed again | Silently inherited |
Scope an Exception to the Demonstrated Interaction
Start from the symptom rather than from a list. A file-access conflict, resource pressure and a slow query look different in the logs and lead to different fixes. Reproduce the symptom with protection enabled, then identify the exact path or process involved.
Typical candidates are database files, log files, backups and full-text catalog files, and Microsoft's guidance on antivirus software and SQL Server remains the reference for the deployed version and security product. Do not copy a list from another server, and do not assume one service name covers every installed component. The smallest exception that addresses the demonstrated interaction is the one to propose. Anything broader needs its own argument.
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled
Review that list against the server's role, because an exclusion added for one incident tends to stay forever. A short note beside each entry is enough to make the next audit possible.
Keep the Network and Identity Controls
An endpoint exception says nothing about who may reach the database. Firewall policy should still constrain which sources can open a SQL or management session, and application accounts should still bound what those sessions may do.
A VPN belongs in that same conversation and is frequently misused as an argument. Restricting the access path does not validate the files, scripts or queries that arrive through it. An encrypted tunnel is also opaque to a network sensor, so the visibility a sensor gives you is not the visibility a host agent gives you. Those are different evidence streams, and neither replaces the other. Patch management, trusted administrative tooling and a tested recovery path remain separate responsibilities with their own owners. Role hygiene belongs here too: unrelated browsing, downloads and shared-file duties should stay off the database host unless its owner has explicitly accepted them.
Test the Change, Then Own It
Test with a representative workload and the security checks that matter, then compare stability, throughput and continued protection rather than only the original error.
Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20
Keep a supported rollback path and an owner who reviews the exception after component or product updates, because an exclusion written for one build can outlive the reason it existed. Record the scope, the reason and the review date in the same place as the server's build record. Without that, the next reviewer inherits a list with no argument behind it. An exception is defensible only while its reason is still true.