Forum Discussion
OWA inline CID images still not displayed – EEMS mitigation side effect persists?
- Jun 24, 2026
[SOLVED] – Solution found, sharing for the community
After further investigation and help from the community, we were able to resolve the issue. Here is the complete solution for anyone facing the same problem:
Root cause confirmed: The EEMS mitigation M2.1.0 remained active even after installing the June 2026 SU (KB5094139). The URL Rewrite rule (script-src-attr 'none') was still present in the OWA web.config and continued to block inline CID image rendering.
Solution (after installing KB5094139):
Step 1: Block M2.1.0 from being re-applied by EEMS:
Set-ExchangeServer -Identity <YourServerName> -MitigationsBlocked @("M2.1.0")
Step 2: Create a backup of the web.config, then remove the M2.1 rule manually:
Copy-Item "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config" `
"C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config.bak_$(Get-Date -Format 'yyyyMMdd_HHmmss')"
PowerShell:
$webConfigPath = "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config"
[xml]$webConfig = Get-Content $webConfigPath -Encoding UTF8# Rewrite-Knoten finden
$rewriteNode = $webConfig.configuration.'system.webServer'.rewrite# Alle M2.1-Regeln aus outboundRules entfernen
$outboundRules = $rewriteNode.outboundRules
$rulesToRemove = $outboundRules.rule | Where-Object { $_.name -like "*M2.1*" }
foreach ($rule in $rulesToRemove) {
$outboundRules.RemoveChild($rule) | Out-Null
Write-Host "Regel entfernt: $($rule.name)" -ForegroundColor Green
}# Alle M2.1-PreConditions entfernen
$preConditionsToRemove = $outboundRules.preConditions | Where-Object { $_.name -like "*M2.1*" }
foreach ($pre in $preConditionsToRemove) {
$outboundRules.RemoveChild($pre) | Out-Null
Write-Host "PreCondition entfernt: $($pre.name)" -ForegroundColor Green
}# Gespeicherte Datei zurückschreiben
$webConfig.Save($webConfigPath)
Write-Host "web.config gespeichert." -ForegroundColor CyanStep 3: Verify the rule is gone:
Select-String -Path "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config" `
-Pattern "M2.1|rewrite" -CaseSensitive:$false
Expected: No M2.1 rule entry remaining ✅
Step 4: An IIS reset is not strictly required, but can be done to be safe:
iisreset /noforce
Result: Inline CID images are displayed correctly in OWA again. ✅
Important notes:
- Only do this after installing KB5094139 – the SU fixes CVE-2026-42897 on code level
- Microsoft explicitly allows removing M2.1 after the SU is installed (see techcommunity.microsoft.com)
- The remaining <preCondition> entry in web.config is harmless without its associated rule
- To revert: Set-ExchangeServer -MitigationsBlocked @() + restart MSExchangeMitigation service
Hope this helps other admins! 🙌
[SOLVED] – Solution found, sharing for the community
After further investigation and help from the community, we were able to resolve the issue. Here is the complete solution for anyone facing the same problem:
Root cause confirmed: The EEMS mitigation M2.1.0 remained active even after installing the June 2026 SU (KB5094139). The URL Rewrite rule (script-src-attr 'none') was still present in the OWA web.config and continued to block inline CID image rendering.
Solution (after installing KB5094139):
Step 1: Block M2.1.0 from being re-applied by EEMS:
Set-ExchangeServer -Identity <YourServerName> -MitigationsBlocked @("M2.1.0")
Step 2: Create a backup of the web.config, then remove the M2.1 rule manually:
Copy-Item "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config" `
"C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config.bak_$(Get-Date -Format 'yyyyMMdd_HHmmss')"
PowerShell:
$webConfigPath = "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config"
[xml]$webConfig = Get-Content $webConfigPath -Encoding UTF8
# Rewrite-Knoten finden
$rewriteNode = $webConfig.configuration.'system.webServer'.rewrite
# Alle M2.1-Regeln aus outboundRules entfernen
$outboundRules = $rewriteNode.outboundRules
$rulesToRemove = $outboundRules.rule | Where-Object { $_.name -like "*M2.1*" }
foreach ($rule in $rulesToRemove) {
$outboundRules.RemoveChild($rule) | Out-Null
Write-Host "Regel entfernt: $($rule.name)" -ForegroundColor Green
}
# Alle M2.1-PreConditions entfernen
$preConditionsToRemove = $outboundRules.preConditions | Where-Object { $_.name -like "*M2.1*" }
foreach ($pre in $preConditionsToRemove) {
$outboundRules.RemoveChild($pre) | Out-Null
Write-Host "PreCondition entfernt: $($pre.name)" -ForegroundColor Green
}
# Gespeicherte Datei zurückschreiben
$webConfig.Save($webConfigPath)
Write-Host "web.config gespeichert." -ForegroundColor Cyan
Step 3: Verify the rule is gone:
Select-String -Path "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config" `
-Pattern "M2.1|rewrite" -CaseSensitive:$false
Expected: No M2.1 rule entry remaining ✅
Step 4: An IIS reset is not strictly required, but can be done to be safe:
iisreset /noforce
Result: Inline CID images are displayed correctly in OWA again. ✅
Important notes:
- Only do this after installing KB5094139 – the SU fixes CVE-2026-42897 on code level
- Microsoft explicitly allows removing M2.1 after the SU is installed (see techcommunity.microsoft.com)
- The remaining <preCondition> entry in web.config is harmless without its associated rule
- To revert: Set-ExchangeServer -MitigationsBlocked @() + restart MSExchangeMitigation service
Hope this helps other admins! 🙌
I verified the issue without installing the June SU patch (KB5094139). After removing the rule entry from the web.config file as mentioned above, the issue was resolved. However, MitigationsEnabled must be be set to False; otherwise, the mitigation service may reapply the rule.
Alternatively, instead of manually removing the rule entry from web.config, I disabled the outbound rule in IIS URL Rewrite and restarted the Exchange Mitigation Service to verify whether it would resynchronize and re-enable the rule. The rule remained disabled, indicating that the mitigation service did not overwrite the manually disabled rule. Based on this test, disabling the outbound rule in IIS is sufficient, and there is no need to disable the mitigation service.