🔹 Short description (excerpt)

Antivirus software on Exchange servers is mandatory – but it is often far more complex than a simple file scanner.
Even when customers claim their antivirus is configured according to Microsoft recommendations, we still encounter unusual, non-obvious issues.
This article explains how to properly verify antivirus exclusions, why process-level integration matters, and how Microsoft’s own diagnostic tools help uncover hidden risks.

🧠 Antivirus on Exchange: More Than Just a File Scanner

No one disputes the need for antivirus software on Exchange servers.

The real challenge is that modern antivirus products are rarely limited to:

• file and directory scanning
• scheduled on-access checks

In practice, many solutions:

• inject DLLs into processes
• hook into IIS worker processes
• monitor service behavior
• integrate deeply with application logic

Microsoft’s Exchange product group is very explicit about this and provides detailed guidance covering not only files and directories, but also processes that must be excluded.

📄 Official documentation:
https://learn.microsoft.com/en-us/exchange/antispam-and-antimalware/windows-antivirus-software

Despite this, misconfigurations are still common.

⚠️ “Everything Is Configured According to Recommendations” – Yet Problems Persist

In multiple real-world support cases, we encounter symptoms such as:

• intermittent IIS issues
• behavior resembling session pool exhaustion
• random Exchange instability
• problems that disappear after service restarts

At the same time, customers or InfoSec teams usually state:

“Antivirus is fully configured according to Microsoft best practices.”

This leads to the most important question:

How can we verify that — objectively?

🔍 Verifying Antivirus Configuration the Right Way

✅ Test-ExchAVExclusions

Microsoft provides a diagnostic script developed by Exchange support engineers, not as generic documentation but as a practical verification tool:

🔗 https://microsoft.github.io/CSS-Exchange/Diagnostics/Test-ExchAVExclusions/

Important considerations:

• The script runs as-is
• It creates EICAR test files
• This can trigger antivirus alerts
• ⚠️ It is recommended to notify the InfoSec / antivirus team in advance

What the script checks:

• File and directory exclusions
• Antivirus integration with Exchange-related processes
• Unexpected third-party modules loaded into Exchange components
• Antivirus behavior from a supportability perspective

🧩 A Real Case: IIS Symptoms and an Antivirus Service Crash

In one investigated case:

• The issue manifested as an IIS-related problem
• Symptoms resembled session pool exhaustion
• Around the same time, the antivirus service crashed

Important clarification

Without a memory dump captured at the time of the issue, we cannot conclusively prove that the IIS problem was caused by the antivirus service crash.

Temporal correlation alone is not sufficient to establish a root cause.
To make such a claim, a memory dump would be required.

🔎 What the Investigation Did Reveal

Although we cannot state with certainty that the antivirus crash caused the IIS issue, the investigation clearly identified configuration problems that must be addressed:

• Required antivirus exclusions were missing
• Antivirus modules were loaded into Exchange and IIS processes
• Integration was detected even in purely server-side Exchange services

These findings alone justify corrective action  –  regardless of whether they were the direct trigger of this specific incident.

⚠️ Antivirus Integration with IIS and Exchange Services

The Test-ExchAVExclusions script reported:

Notable examples included:

🔹 IIS (w3wp.exe)

The IIS worker process directly handles client requests.
If third-party antivirus modules are injected into w3wp.exe, a crash or instability in the antivirus component may result in:

• stalled or blocked requests
• apparent session pool exhaustion
• random IIS failures
• issues resolved only after restarting IIS

🔹 MSExchangeDagMgmt (DAG Management Service)

This service:

• is purely server-side
• has no user traffic
• is responsible for internal DAG management

Despite this, antivirus modules were loaded into the process.

This is particularly important because:

• Microsoft explicitly recommends excluding this service
• Yet antivirus integration was still present

This strongly indicates misconfiguration.

🧬 Can an Antivirus Crash Lead to These Symptoms?

Yes  –  it is technically possible.

If an antivirus product:

• injects modules into IIS or Exchange services
• hooks into in-process logic
• bypasses supported inspection mechanisms

Then a crash or failure of the antivirus service can leave:

• orphaned hooks
• blocked threads
• unstable request handling

However, without a dump, this remains a plausible technical explanation, not a proven root cause for this specific incident.

🛠 What Was Done  –  and What to Do If It Happens Again

✅ Immediate Actions

• Identified missing and incorrect antivirus exclusions
• Provided the customer with:
  • a validated list of required exclusions
  • guidance on correcting process-level exclusions
• Explained why directory-only exclusions are insufficient

Correcting these issues is required independently of root cause confirmation.

📌 If the Issue Reproduces

The customer was provided with instructions to:

• Capture a memory dump
• Collect logs while the issue is active
• Avoid restarting services before diagnostics are secured

This allows moving from correlation to evidence and enables meaningful escalation  – either internally or with antivirus vendor support.

📋 Generating a Clean Exclusion List per Server

To obtain a server-specific list of recommended exclusions, Microsoft provides another script:

🔗 https://microsoft.github.io/CSS-Exchange/Setup/Set-ExchAVExclusions/

Run it in listing mode only:

This mode:

• Does not apply any configuration
• Generates a text file with:
  • directory exclusions
  • file exclusions
  • process exclusions

⚠️ Do not run this script without parameters unless you intend to automatically configure Microsoft Defender.

🧬 A Note on AMSI

For scanning user traffic, Exchange relies on AMSI (Antimalware Scan Interface).

AMSI enables:

• in-memory scanning
• inspection without deep process injection
• supported and predictable antivirus integration

Problems often arise when antivirus products:

• bypass AMSI
• inject directly into Exchange or IIS processes
• operate outside supported integration paths

✅ Final Takeaways

• Antivirus configuration on Exchange is not limited to folders
• Process-level exclusions are critical
• “Configured according to best practices” must be verified, not assumed
• Antivirus integration into IIS and server-only Exchange services is a recurring hidden risk
• Microsoft provides official, support-engineer-built tools to detect these issues

Even when the root cause cannot be proven without a dump, objectively incorrect antivirus integration must be fixed — and doing so often prevents the next outage.

End.