EDCA: Exchange Deployment & Compliance Assessment v0.9 Preview

EDCA-DATA-001: No expired Exchange certificates

Category: Data Security | Severity: Medium | Frameworks: Best Practice, NIS2, DISA, ANSSI, BSI

Remediation

Replace expired certificates and assign them to Exchange services.

# Diagnose: List Exchange certificates with expiry status
Get-ExchangeCertificate -Server $env:COMPUTERNAME | Select-Object Thumbprint, Subject, NotAfter, Status, Services | Sort-Object NotAfter | Format-Table -AutoSize
# To renew: Import-ExchangeCertificate -FileData ([Byte[]](Get-Content <pfx> -Encoding Byte -ReadCount 0)) -Password (Read-Host -AsSecureString)
# Then enable: Enable-ExchangeCertificate -Thumbprint <thumb> -Services SMTP,IIS

Considerations

Certificate renewal on an Exchange server requires updating the certificate on all Services (IIS, SMTP, IMAP, POP3) and removing the expired certificate. If using a third-party CA, plan lead time for certificate issuance (typically 1–5 business days). Internal clients may show SSL warnings until the new certificate is fully propagated via Directory Services.

References

• Microsoft Exchange certificate procedures
• V-259649 Exchange servers must use approved DOD certificates (EX19-MB-000019)
• V-259578 Exchange servers must use approved DOD certificates (EX19-ED-000016)
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-002: Auth certificate baseline

Category: Data Security | Severity: High | Frameworks: Best Practice, NIS2, ANSSI

Remediation

Verify the Auth Certificate is valid and present on all Exchange servers. If the primary Auth Certificate was replaced without rerunning the Hybrid Configuration Wizard, re-run the wizard to sync the Auth Certificate with Azure AD.

Get-AuthConfig | Format-List CurrentCertificateThumbprint, PreviousCertificateThumbprint

Considerations

The OAuth authentication certificate is required for hybrid features (free/busy lookup, mail routing to Exchange Online Archive, cross-premises calendar delegation). Replacing the Auth certificate requires coordinated updates on all Exchange servers and a brief interruption to hybrid connectivity. Follow the Microsoft Auth Certificate renewal procedure precisely.

References

• CSS AuthCertificateCheck
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)

EDCA-DATA-003: Internal transport certificate baseline

Category: Data Security | Severity: High | Frameworks: Best Practice, NIS2, ANSSI, BSI

Remediation

If the Internal Transport Certificate is missing or expired, create a new one using New-ExchangeCertificate with the server NetBIOS name, FQDN, and SMTP service assignment. Run Enable-ExchangeCertificate -Services SMTP after confirming propagation to all Exchange servers.

# Replace the placeholder values with the actual server FQDN and NetBIOS name before running.
# The FQDN is the fully qualified DNS name (e.g. ex1.contoso.com); the NetBIOS name is typically $env:COMPUTERNAME.
$serverFQDN = [System.Net.Dns]::GetHostEntry('').HostName
$serverNetBIOS = $env:COMPUTERNAME
New-ExchangeCertificate -PrivateKeyExportable $false -Services SMTP -SubjectName ('CN=' + $serverFQDN) -DomainName $serverFQDN, $serverNetBIOS

Considerations

The internal transport certificate is used for Exchange-to-Exchange SMTP TLS. Replacing it requires the certificate to be propagated to all Exchange servers in the organization before activation. A brief interruption to inter-server TLS may occur during certificate rollover.

References

• CSS InternalTransportCertificateCheck
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-004: Serialized data signing baseline

Category: Data Security | Severity: High | Frameworks: Best Practice, CISA

Remediation

Ensure PowerShell Serialization Payload Signing is enabled on Exchange 2016 CU23+ or Exchange 2019 CU12+ with January 2023 SU or later installed. Verify the signing certificate is valid and present on all Exchange servers.

# Diagnose: Check serialized data signing SettingOverride status
Get-SettingOverride | Where-Object { $_.ComponentName -eq 'Data' -and $_.SectionName -eq 'EnableSerializationDataSigning' } | Select-Object Name, ComponentName, SectionName, Parameters, Server | Format-List
# Expected: an override with Parameters containing 'Enabled=True' applied globally or to target servers.

Considerations

Serialized data signing requires a minimum Exchange Cumulative Update level (Exchange 2019 CU12+ or Exchange SE). Enabling it on an older build that does not fully support the feature may cause issues. Verify supported build version before enabling. After enabling, a brief transport interruption may occur while services restart.

References

• CSS SerializedDataSigningCheck
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - enable serialized data signing to prevent deserialization attacks

EDCA-DATA-005: TLS 1.0 and TLS 1.1 are disabled

Category: Data Security | Severity: High | Frameworks: Best Practice, NIS2, CIS, CISA, DISA, ANSSI, BSI

Remediation

Disable TLS 1.0 and TLS 1.1 for both Server and Client sides in SCHANNEL, creating keys if absent and setting DisabledByDefault.

foreach ($ver in 'TLS 1.0', 'TLS 1.1') {
    foreach ($side in 'Server', 'Client') {
        $path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\$ver\$side"
        New-Item -Path $path -Force | Out-Null
        Set-ItemProperty -Path $path -Name Enabled -Type DWord -Value 0
        Set-ItemProperty -Path $path -Name DisabledByDefault -Type DWord -Value 1
    }
}

Considerations

Disabling TLS 1.0 and TLS 1.1 can break connectivity with legacy clients, monitoring systems, and SMTP relay partners that do not support TLS 1.2. Audit all TLS-dependent applications, relay connectors, and partner connectors before disabling. Monitor Exchange transport logs after enforcement for TLS handshake failures.

References

• Microsoft TLS best practices
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• CIS Microsoft Windows Server Benchmark
• CIS Microsoft Windows Server 2022 Benchmark v3.0.0 (L1): Ensure TLS 1.0 is disabled (Enabled = 0) under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0
• CIS Microsoft Windows Server 2022 Benchmark v3.0.0 (L1): Ensure TLS 1.1 is disabled (Enabled = 0) under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1
• V-259646 Exchange must use encryption for Outlook Web App (OWA) access (EX19-MB-000007)
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-006: TLS 1.2 is enabled

Category: Data Security | Severity: High | Frameworks: Best Practice, NIS2, CIS, CISA, DISA, ANSSI, BSI

Remediation

Enable TLS 1.2 for both Server and Client sides in SCHANNEL, creating keys if absent and clearing DisabledByDefault.

$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2'
foreach ($side in 'Server', 'Client') {
    New-Item -Path "$path\$side" -Force | Out-Null
    Set-ItemProperty -Path "$path\$side" -Name Enabled -Type DWord -Value 1
    Set-ItemProperty -Path "$path\$side" -Name DisabledByDefault -Type DWord -Value 0
}

Considerations

Enabling TLS 1.2 is generally low-risk on modern systems. However, if TLS 1.0 and 1.1 are simultaneously disabled, applications or services that do not support TLS 1.2 will fail. Test dependent systems before disabling older protocol versions alongside enabling TLS 1.2.

References

• Microsoft TLS 1.2 deployment guidance
• CIS Microsoft Windows Server Benchmark
• CIS Microsoft Windows Server 2022 Benchmark v3.0.0 (L1): Ensure TLS 1.2 is enabled (Enabled = 1, DisabledByDefault = 0) under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2
• DISA STIG EX19-MB-000236 (HIGH): The application must protect the confidentiality and integrity of transmitted information (V-259710)
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-007: TLS 1.3 is disabled for Exchange compatibility

Category: Data Security | Severity: Medium | Frameworks: Best Practice, NIS2, ANSSI, BSI

Remediation

Disable TLS 1.3 server protocol in SCHANNEL on supported Windows Server versions for Exchange compatibility.

New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Name Enabled -Type DWord -Value 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Name DisabledByDefault -Type DWord -Value 1

Considerations

TLS 1.3 is currently not supported by Exchange Server transport. Enabling TLS 1.3 at the OS Schannel level will not cause Exchange SMTP issues but Exchange will not use it for mail transport. IIS may use TLS 1.3 for HTTPS connections if IIS supports it, which is generally safe on Server 2022. Note (ANSSI tension, Feb 2026): ANSSI's post-quantum TLS transition guidance (Transition-post-quantique-protocole-TLS-1-3, 2026) recommends TLS 1.3 with hybrid post-quantum key exchange (e.g. X25519MLKEM768) as the forward-looking cryptographic baseline. This control reflects Exchange's current compatibility constraint — not an ANSSI recommendation to disable TLS 1.3 broadly. Organizations should monitor Microsoft's Exchange roadmap for native TLS 1.3 support and plan to re-enable it once compatibility is confirmed, particularly to benefit from post-quantum cipher suite support.

References

• TLS registry settings (Windows Server)
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• CIS Microsoft Windows Server Benchmark
• EDPB Guidelines, Recommendations, Best Practices
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• ANSSI - Transition post-quantique de TLS 1.3 (2026)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-008: Trusted root certificates baseline

Category: Data Security | Severity: Medium | Frameworks: Best Practice, NIS2

Remediation

Enable automatic root certificate updates via Group Policy or manually install required root certificates. Ensure the DigiCert Global Root G2 certificate (thumbprint: DDEE4455FF006677112288990011CCDD4455DDEE) is installed on all Exchange servers to prevent certificate validation failures.

# Diagnose: Check automatic root certificate update policy and presence of DigiCert Global Root G2
$val = (Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot' -Name DisableRootAutoUpdate -ErrorAction SilentlyContinue).DisableRootAutoUpdate
"DisableRootAutoUpdate: $(if ($null -eq $val) { 'not set (auto-update active)' } else { $val })"
$cert = Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Thumbprint -eq 'DDEE4455FF006677112288990011CCDD4455DDEE' }
"DigiCert Global Root G2: $(if ($cert) { 'Present (expires ' + $cert.NotAfter.ToString('yyyy-MM-dd') + ')' } else { 'NOT FOUND - required for Exchange hybrid and modern auth' })"

Considerations

Automatic root certificate updates require outbound HTTPS access to Windows Update. In isolated environments, certificates must be manually distributed. The DigiCert Global Root G2 certificate is required by Microsoft 365 and Azure services; its absence will cause TLS trust chain failures for Exchange hybrid and modern authentication.

References

• CSS TrustedRootCertificatesCheck
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6

EDCA-DATA-009: IIS HSTS configuration baseline for Exchange sites

Category: Data Security | Severity: Medium | Frameworks: Best Practice, CISA, ANSSI, BSI

Remediation

Review and correct IIS HSTS configuration for Exchange websites, especially Exchange Back End and redirectHttpToHttps settings.

# Diagnose: Check Strict-Transport-Security header configuration on Exchange IIS sites
Import-Module WebAdministration -ErrorAction SilentlyContinue
Get-Website | Where-Object { $_.Name -match 'Default Web Site|Exchange Back End' } | ForEach-Object { $site = $_.Name; Get-WebConfigurationProperty -PSPath "IIS:\Sites\$site" -Filter 'system.webServer/httpProtocol/customHeaders' -Name '.' | Where-Object { $_.name -eq 'Strict-Transport-Security' } | Select-Object @{N='Site';E={$site}}, name, value }
# HSTS must NOT be applied to Exchange Back End (port 444) - it breaks internal services.

Considerations

Enabling HSTS instructs browsers to only connect to Exchange sites over HTTPS. If any IIS HTTP binding is required for any reason (e.g., certificate renewal challenges), HSTS will prevent HTTP connections for the duration of the max-age period. Test all Exchange virtual directories for HTTPS functionality before enabling HSTS.

References

• CSS HSTS guidance
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - enable HTTP Strict Transport Security (HSTS) on Exchange web virtual directories
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen
• BSI APP.5.2.A12 — Einsatz von Outlook Anywhere, MAPI over HTTP und Outlook im Web

EDCA-DATA-010: TLS insecure renegotiation values hardened

Category: Data Security | Severity: Medium | Frameworks: Best Practice, NIS2, ANSSI, BSI

Remediation

Configure TLS versions consistently across Exchange servers. Set Client and Server Enabled and DisabledByDefault DWORD values under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols for each TLS version. Also configure SystemDefaultTlsVersions and SchUseStrongCrypto in .NET Framework registry paths. TLS 1.2 must be enabled; TLS 1.3 must be disabled for Exchange.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL' -Name AllowInsecureRenegoClients -Type DWord -Value 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL' -Name AllowInsecureRenegoServers -Type DWord -Value 0

Considerations

TLS renegotiation settings affect all TLS connections on the server at the Schannel layer. Disabling insecure renegotiation prevents certain downgrade attacks but may break connectivity with clients that require renegotiation for session resumption. Test with monitoring and SMTP partner systems before enforcing.

References

• CSS TLS hardening checks
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-011: Weak Schannel ciphers (NULL, DES, RC4, Triple-DES) are explicitly disabled

Category: Data Security | Severity: High | Frameworks: Best Practice, NIS2, ANSSI, BSI

Remediation

Explicitly disable each weak cipher by setting the DWORD registry value Enabled=0 under the corresponding SCHANNEL\Ciphers subkey. A system restart is required for the changes to take effect.

# Disable weak SCHANNEL ciphers (NULL, DES, RC4 variants, Triple DES).
# Run on each Exchange / Windows server. Requires a restart to take effect.

$ciphers = @(
    'NULL',
    'DES 56/56',
    'RC4 40/128',
    'RC4 56/128',
    'RC4 64/128',
    'RC4 128/128',
    'Triple DES 168'
)

foreach ($cipher in $ciphers) {
    $path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\$cipher"
    if (-not (Test-Path -Path $path)) {
        New-Item -Path $path -Force | Out-Null
    }
    Set-ItemProperty -Path $path -Name 'Enabled' -Type DWord -Value 0
    Write-Host "Disabled: $cipher"
}

Write-Host 'Done. Restart the server for the changes to take effect.'

Considerations

Disabling weak Schannel ciphers (NULL, DES, RC4, Triple-DES) affects all TLS-dependent applications on the server, not just Exchange. Legacy monitoring agents, SMTP relay partners, or backup agents that only support RC4 or Triple-DES will fail to connect after this change. Audit all TLS consumers before applying. Monitor for connectivity failures after enforcement.

References

• NCSC TLS-Richtlijnen 2025 §3.3.4 - Bulkversleuteling
• Microsoft - How to restrict the use of certain cryptographic algorithms in Schannel
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-012: Weak Schannel hash algorithms (MD5, SHA-1) are explicitly disabled

Category: Data Security | Severity: High | Frameworks: Best Practice, NIS2, ANSSI, BSI

Remediation

Explicitly disable MD5 and SHA-1 by setting the DWORD registry value Enabled=0 under the corresponding SCHANNEL\Hashes subkey. A system restart is required for the changes to take effect.

# Disable weak SCHANNEL hash algorithms (MD5, SHA-1).
# Run on each Exchange / Windows server. Requires a restart to take effect.

$hashes = @('MD5', 'SHA')

foreach ($hash in $hashes) {
    $path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\$hash"
    if (-not (Test-Path -Path $path)) {
        New-Item -Path $path -Force | Out-Null
    }
    Set-ItemProperty -Path $path -Name 'Enabled' -Type DWord -Value 0
    Write-Host "Disabled: $hash"
}

Write-Host 'Done. Restart the server for the changes to take effect.'

Considerations

Disabling MD5 and SHA-1 at the Schannel hash algorithm level affects all TLS handshakes on the server. Some legacy SMTP partners or certificate chains that use SHA-1 signed certificates may fail TLS negotiation. Review active TLS session partner certificate chains before applying. Plan for a short transition period to identify impacted connections.

References

• NCSC TLS-Richtlijnen 2025 §3.3.5 - Hashfuncties
• Microsoft - How to restrict the use of certain cryptographic algorithms in Schannel
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-013: Non-forward-secret key exchange (PKCS / static RSA) is explicitly disabled

Category: Data Security | Severity: High | Frameworks: Best Practice, NIS2, ANSSI, BSI

Remediation

Explicitly disable the PKCS key exchange algorithm by setting the DWORD registry value Enabled=0 under SCHANNEL\KeyExchangeAlgorithms\PKCS. A system restart is required for the changes to take effect.

# Disable the non-forward-secret PKCS (static RSA) key exchange algorithm in SCHANNEL.
# Run on each Exchange / Windows server. Requires a restart to take effect.

$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS'
if (-not (Test-Path -Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Enabled' -Type DWord -Value 0
Write-Host 'PKCS key exchange disabled. Restart the server for the changes to take effect.'

Considerations

Disabling non-forward-secret key exchange (PKCS/static RSA) removes cipher suites that do not provide forward secrecy from TLS negotiation. This improves security by ensuring session keys cannot be decrypted retroactively if the server private key is compromised. Legacy clients or SMTP partners that only support RSA key exchange may be unable to establish TLS sessions after this change.

References

• NCSC TLS-Richtlijnen 2025 §3.3.3 - Sleuteluitwisseling
• Microsoft - How to restrict the use of certain cryptographic algorithms in Schannel
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-014: S/MIME is enabled for Outlook Web App

Category: Data Security | Severity: Low | Frameworks: Best Practice, CIS

Remediation

Enable S/MIME on all OWA virtual directories.

# Enable S/MIME on all OWA virtual directories on this server.
Get-OwaVirtualDirectory -Server $env:COMPUTERNAME | Set-OwaVirtualDirectory -SMIMEEnabled $true

Considerations

S/MIME requires end-user certificates to be provisioned and users must install the S/MIME control in their browser. Enabling this setting does not automatically configure certificates for users.

References

• CIS 2.3.5 (L1): Ensure Enable S/MIME for OWA is set to True
• S/MIME for message signing and encryption in Exchange Server

EDCA-DATA-015: RPC client access connections require encryption

Category: Data Security | Severity: Medium | Frameworks: Best Practice, BSI, CIS, DISA

Remediation

Set EncryptionRequired to True on the RPC client access service.

# Require encryption for MAPI/RPC client connections.
Set-RpcClientAccess -Server $env:COMPUTERNAME -EncryptionRequired $true

Considerations

Enabling encryption required may break older Outlook clients that do not support encrypted MAPI connections. Verify Outlook version compatibility before enforcing this setting.

References

• CIS 2.3.6 (L1): Ensure Require client MAPI encryption is set to True
• Set-RpcClientAccess in Exchange Server
• V-259645 Exchange must use encryption for RPC client access (EX19-MB-000006)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-016: AES256-CBC encryption mode is enabled for IRM-protected messages

Category: Data Security | Severity: Medium | Frameworks: Best Practice

Remediation

On Exchange 2016 CU23 or Exchange 2019 CU13 with October 2023 SU or later, create the EnableEncryptionAlgorithmCBC setting override to enable AES256-CBC mode encryption. On November 2024 SU or later, MSIPC is enabled by default and only the EnableEncryptionAlgorithmCBC override is required. Refresh VariantConfiguration and restart W3SVC and WAS after applying the override.

New-SettingOverride -Name 'EnableEncryptionAlgorithmCBC' -Parameters @('Enabled=True') -Component Encryption -Reason 'Enable AES256-CBC encryption' -Section EnableEncryptionAlgorithmCBC
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force

Considerations

Only applicable when IRM (AD RMS or Azure RMS) is in use. Requires Exchange 2016 CU23 with October 2023 SU or Exchange 2019 CU13 with October 2023 SU, or any later build. In a hybrid Exchange Online environment, additional steps are required to enable AES256-CBC on the Exchange Online side - contact Microsoft Support. In a coexistence environment with Exchange Server 2013 (end of life), enabling AES256-CBC may cause intermittent mail delivery and journaling failures.

References

• Enable support for AES256-CBC-encrypted content in Exchange Server August 2023 SU

EDCA-DATA-017: Exchange database/log volumes are BitLocker-protected

Category: Data Security | Severity: Medium | Frameworks: Best Practice

Remediation

Enable BitLocker Drive Encryption on all volumes that host Exchange database and transaction log files. Use Enable-BitLocker or BitLocker Drive Encryption in the Windows Server GUI. Store recovery keys securely in Active Directory before enabling.

Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, ProtectionStatus | Format-Table -AutoSize

Considerations

Enabling BitLocker on an existing Exchange volume requires a recovery key stored in Active Directory or a key management solution. The initial encryption pass increases I/O load but does not require an offline maintenance window for an already-mounted volume.

References

• Exchange Server Preferred Architecture: Server component requirements
• BitLocker overview

EDCA-DATA-018: TLS 1.2 approved cipher suite allowlist enforces forward secrecy

Category: Data Security | Severity: Medium | Frameworks: ANSSI, BSI

Remediation

Configure the Schannel cipher suite order via Group Policy (Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order) or via the registry under HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002. Prioritise ECDHE cipher suites with AES-GCM. Remove or demote cipher suites without forward secrecy. Apply IISCrypto or a custom GPO to set the recommended order.

# Inspect current Schannel cipher suite order
Get-TlsCipherSuite | Select-Object Name, Exchange, Hash, Cipher, KeyLength | Format-Table -AutoSize

# Check for non-forward-secret suites (no ECDHE or DHE in name)
Get-TlsCipherSuite | Where-Object { $_.Name -notmatch 'ECDHE|DHE' } | Select-Object Name | Format-Table -AutoSize

# Recommended ANSSI-aligned TLS 1.2 cipher suites (forward-secret, AES-GCM preferred):
# TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
# TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
# TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
# TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
# TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
# TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

# Example: disable a non-PFS cipher suite
# Disable-TlsCipherSuite -Name 'TLS_RSA_WITH_AES_256_CBC_SHA256'

Considerations

Removing cipher suites from the Schannel order affects ALL TLS-dependent applications on the server. SMTP partner systems, monitoring agents, and internal applications must support at least one remaining cipher suite to maintain connectivity. Before enforcing a restrictive cipher suite list, audit all TLS connections using network capture or transport log analysis. The Windows Schannel cipher suite order is controlled by Group Policy; if a GPO already manages this setting, changes must be made through the GPO. Exchange transport uses Schannel for both inbound and outbound SMTP TLS negotiation. If a restricted cipher suite list causes inbound TLS failures, review receive connector logs for TLS handshake errors.

References

• Cipher Suites in TLS/SSL (Schannel SSP)
• Configuring TLS cipher suites via Group Policy
• ANSSI - Recommandations de sécurité relatives à TLS (v1.2, 2020)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-DATA-019: SchUseStrongCrypto is enabled for .NET Framework

Category: Data Security | Severity: Medium | Frameworks: Best Practice, DISA

Remediation

Set SchUseStrongCrypto to 1 in both the 64-bit and WoW6432Node .NET Framework v4.0.30319 registry paths.

foreach ($path in @(
    'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319',
    'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319'
)) {
    New-Item -Path $path -Force | Out-Null
    Set-ItemProperty -Path $path -Name SchUseStrongCrypto -Type DWord -Value 1
}

Considerations

SchUseStrongCrypto affects all .NET applications on the server, not just Exchange. Setting it to 1 restricts .NET code to TLS 1.2+ and strong cipher suites for outbound connections. This may break connectivity with legacy services that do not support TLS 1.2. Test dependent integrations before enforcing.

References

• Microsoft — Transport Layer Security (TLS) best practices with .NET Framework
• V-259577 Exchange must have the SchUseStrongCrypto registry value set (EX19-MB-000207)

EDCA-GOV-001: Shared mailbox type consistency

Category: Governance | Severity: Low | Frameworks: Best Practice

Remediation

Disable the Active Directory account for each non-user mailbox that has an enabled account.

# Diagnose: Find non-user mailboxes (Shared, Room, Equipment) with enabled accounts
Get-Mailbox -ResultSize Unlimited | Where-Object { $_.RecipientTypeDetails -ne 'UserMailbox' -and -not $_.AccountDisabled } | Select-Object DisplayName, RecipientTypeDetails, PrimarySmtpAddress | Sort-Object RecipientTypeDetails, DisplayName
# To fix:
# Disable-MailboxAccount -Identity <alias> -Confirm:$false

Considerations

Disabling the account on a shared or resource mailbox does not affect mailbox access via delegation. Verify that no service accounts, automations, or applications authenticate using the mailbox's AD account before disabling it. In hybrid environments, account state is synchronized from on-premises AD to Entra ID - disabling the account on-premises also disables the cloud identity.

References

• Convert a mailbox in Exchange Server

EDCA-GOV-002: Exchange product line lifecycle status

Category: Governance | Severity: High | Frameworks: Best Practice, NIS2, CISA, BSI

Remediation

Ensure Exchange Server SE is running the latest approved update. If running Exchange 2016 or 2019, plan migration to Exchange Server SE first.

# Diagnose: Check Exchange Server build version against lifecycle dates
Get-ExchangeServer | Select-Object Name, AdminDisplayVersion, Edition, IsEdge | Format-Table -AutoSize
# Compare build numbers at: https://learn.microsoft.com/exchange/new-features/build-numbers

Considerations

Migrating from Exchange 2016 or Exchange 2019 to Exchange SE requires environment planning and coexistence testing. Plan for sufficient coexistence time and test hybrid features, mail flow, and client connectivity before decommissioning older servers.

References

• Exchange Server build numbers, release dates, and support status
• CISA KEV Catalog: Apply patches for known exploited Exchange Server vulnerabilities within required timelines
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(e): security in network and information systems maintenance - Section 6.3, 6.4, 9
• BSI APP.5.2.A9 — Sichere Konfiguration von Exchange-Servern

EDCA-GOV-003: EEMS baseline

Category: Governance | Severity: High | Frameworks: Best Practice, CISA, BSI

Remediation

Ensure the MSExchangeMitigation Windows service is set to Automatic startup and is in a Running state. Verify the server has outbound connectivity to the Office Configuration Service (OCS) mitigation endpoint at officeclient.microsoft.com.

Get-Service MSExchangeMitigation | Format-List Name, Status, StartType

Considerations

EEMS automatically applies mitigations from Microsoft without requiring manual patching. If organizational policy requires change control approval before applying any system changes, EEMS may not be appropriate in enforce mode. Review EEMS logs after automatic mitigations are applied to assess impact.

References

• CSS EEMSCheck
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - enable the Microsoft Exchange Emergency Mitigation Service
• BSI APP.5.2.A9 — Sichere Konfiguration von Exchange-Servern

EDCA-GOV-004: Exchange Hybrid Application baseline

Category: Governance | Severity: Medium | Frameworks: Best Practice

Remediation

Deploy a dedicated Exchange Hybrid Application using the ConfigureExchangeHybridApplication tool to support the transition from EWS to Microsoft Graph API for hybrid functionality.

# Diagnose: Check Hybrid AuthServer and IntraOrganization Connector configuration
Get-AuthServer | Where-Object { $_.Type -eq 'AzureAD' } | Select-Object Name, Enabled, ApplicationIdentifier, DomainName | Format-List
Get-IntraOrganizationConnector | Select-Object Name, Enabled, TargetAddressDomains, DiscoveryEndpoint | Format-List

Considerations

The Exchange Hybrid Application is used by Exchange Online to communicate with on-premises Exchange. Removing or changing the hybrid application configuration will disrupt hybrid mail flow, free/busy lookups, and cross-premises mailbox moves. Any reconfiguration must be coordinated with Exchange Online and verified in the Exchange Admin Center.

References

• CSS ExchangeHybridApplicationCheck

EDCA-GOV-005: Mailbox database issue-warning quota is configured

Category: Governance | Severity: Low | Frameworks: Best Practice, CIS

Remediation

Set IssueWarningQuota on each mailbox database to a defined quota value.

# Set issue-warning quota on a specific mailbox database (adjust name and size as needed).
# To target a specific database: replace 'DatabaseName' with the actual database name.
Set-MailboxDatabase -Identity 'DatabaseName' -IssueWarningQuota 1.9GB -UseDatabaseQuotaDefaults $true

Considerations

The appropriate quota size depends on mailbox storage capacity. Ensure that the configured value aligns with your organisation's mailbox retention and storage policies.

References

• CIS 2.1.1 (L1): Ensure Mailbox quotas Issue warning at is set
• Configure storage quotas for a mailbox in Exchange Server

EDCA-GOV-006: Mailbox database prohibit-send-receive quota is configured

Category: Governance | Severity: Low | Frameworks: Best Practice, CIS

Remediation

Set ProhibitSendReceiveQuota on each mailbox database to a defined quota value.

# Set prohibit-send-receive quota on a specific mailbox database (adjust name and size as needed).
# To target a specific database: replace 'DatabaseName' with the actual database name.
Set-MailboxDatabase -Identity 'DatabaseName' -ProhibitSendReceiveQuota 2GB

Considerations

Ensure the prohibit-send-receive quota is set higher than the prohibit-send quota and the issue-warning quota. Coordinate with your storage and capacity planning team before adjusting.

References

• CIS 2.1.3 (L1): Ensure Mailbox quotas Prohibit send and receive at is set
• Configure storage quotas for a mailbox in Exchange Server

EDCA-GOV-007: Mailbox database prohibit-send quota is configured

Category: Governance | Severity: Low | Frameworks: Best Practice, CIS

Remediation

Set ProhibitSendQuota on each mailbox database to a defined quota value.

# Set prohibit-send quota on a specific mailbox database (adjust name and size as needed).
# To target a specific database: replace 'DatabaseName' with the actual database name.
Set-MailboxDatabase -Identity 'DatabaseName' -ProhibitSendQuota 1.95GB

Considerations

Set this value between the issue-warning quota and the prohibit-send-receive quota. Review impacts on users with large mailboxes before applying.

References

• CIS 2.1.4 (L1): Ensure Mailbox quotas Prohibit send at is set
• Configure storage quotas for a mailbox in Exchange Server

EDCA-GOV-008: Exchange Send Fatal Errors to Microsoft is disabled

Category: Governance | Severity: Medium | Frameworks: DISA

Remediation

Run Set-ExchangeServer -Identity <ServerName> -ErrorReportingEnabled $false for each non-compliant Exchange server.

Set-ExchangeServer -Identity '<ServerName>' -ErrorReportingEnabled $false

Considerations

Disabling error reporting reduces Microsoft's ability to diagnose critical Exchange failures. If this setting is mandatory for compliance, compensate with internal diagnostic tooling (e.g., CSS-Exchange Health Checker, SCOM, or equivalent).

References

• V-259665 Exchange Send Fatal Errors to Microsoft must be disabled (EX19-MB-000063)
• V-259591 Exchange Send Fatal Errors to Microsoft must be disabled (EX19-ED-000056)
• Set-ExchangeDiagnosticInfo cmdlet

EDCA-GOV-009: Exchange Customer Experience Improvement Program (CEIP) is disabled

Category: Governance | Severity: Medium | Frameworks: DISA

Remediation

Run Set-OrganizationConfig -CustomerFeedbackEnabled $false to disable the Customer Experience Improvement Program.

Set-OrganizationConfig -CustomerFeedbackEnabled $false

Considerations

CEIP data is asynchronously batched and transmitted. Disabling it has no operational impact on Exchange functionality. Apply via Group Policy in domain-joined environments to ensure it is not re-enabled after updates.

References

• V-259666 Exchange must not send customer experience reports to Microsoft (EX19-MB-000064)

EDCA-GOV-010: Exchange mail quota settings do not block mail flow

Category: Governance | Severity: Low | Frameworks: DISA

Remediation

Review and adjust ProhibitSend and ProhibitSendReceive quota settings on mailbox databases and individual mailboxes to ensure they do not block legitimate mail flow.

# Review mailbox database quota settings
Get-MailboxDatabase | Select-Object Name, ProhibitSendQuota, ProhibitSendReceiveQuota, IssueWarningQuota

# Review individual mailbox quota overrides
Get-Mailbox -ResultSize Unlimited | Where-Object { $_.UseDatabaseQuotaDefaults -eq $false } |
    Select-Object DisplayName, ProhibitSendQuota, ProhibitSendReceiveQuota

Considerations

Quota values must accommodate normal business mailbox usage. Exchange 2016 DISA STIG explicitly addresses receive quotas (/320). The send quota requirement is a formal STIG rule for Exchange 2019 and Exchange SE; the principle applies to Exchange 2016 as well, but there is no corresponding formal 2016 STIG rule for send quotas.

References

• V-259675 Exchange mail quota settings must not restrict receiving mail (EX19-MB-000122)
• V-259676 Exchange mail quota settings must not restrict sending mail (EX19-MB-000123)
• Set-MailboxDatabase cmdlet

EDCA-GOV-011: Exchange software baseline is documented and monitored for unauthorized changes

Category: Governance | Severity: Medium | Frameworks: DISA

Remediation

Create and maintain a documented software baseline, and implement file integrity monitoring for the Exchange installation directory.

# Document Exchange binary baseline hashes. Run from EMS on each Exchange server.
$exchPath = $exinstall
Get-ChildItem $exchPath -Recurse -File -ErrorAction SilentlyContinue | Get-FileHash -Algorithm SHA256 | Select-Object Hash, Path | Export-Csv ($env:COMPUTERNAME + '-ExchangeBaseline.csv') -NoTypeInformation
Write-Host ('Baseline written to ' + $env:COMPUTERNAME + '-ExchangeBaseline.csv')

Considerations

File integrity monitoring solutions (e.g., Microsoft Defender for Endpoint, Tripwire, AIDE) are typically required to meet this control in an automated fashion. Store baselines in a write-protected location. Refresh the baseline after each Exchange Cumulative Update.

References

• V-259700 An Exchange software baseline copy must exist (EX19-MB-000196)
• V-259701 Exchange software must be monitored for unauthorized changes (EX19-MB-000197)
• V-259633 The Exchange software baseline copy must exist (EX19-ED-000197)

EDCA-GOV-012: Exchange services are documented and unnecessary services are disabled

Category: Governance | Severity: Medium | Frameworks: DISA, ANSSI, BSI

Remediation

Enumerate all running services on Exchange servers and document required services. Disable any non-essential services. POP3 and IMAP4 are disabled by default in Exchange and should remain disabled unless explicitly required. If not in use, set both the back-end and front-end service instances to Disabled and stop any running instances.

# List all Exchange-related services and their startup types
Get-Service -DisplayName 'Microsoft Exchange*' | Select-Object DisplayName, Status, StartType | Sort-Object DisplayName

# Diagnose: Check POP3 and IMAP4 service state
Get-Service -Name MSExchangePOP3, MSExchangePOP3BE, MSExchangeIMAP4, MSExchangeIMAP4BE -ErrorAction SilentlyContinue | Select-Object Name, DisplayName, Status, StartType

# To disable POP3 (frontend + backend):
# Set-Service -Name MSExchangePOP3   -StartupType Disabled
# Set-Service -Name MSExchangePOP3BE -StartupType Disabled
# Stop-Service -Name MSExchangePOP3,   MSExchangePOP3BE   -Force -ErrorAction SilentlyContinue

# To disable IMAP4 (frontend + backend):
# Set-Service -Name MSExchangeIMAP4   -StartupType Disabled
# Set-Service -Name MSExchangeIMAP4BE -StartupType Disabled
# Stop-Service -Name MSExchangeIMAP4, MSExchangeIMAP4BE -Force -ErrorAction SilentlyContinue

Considerations

Disabling Exchange services without understanding their role can cause mail flow, client connectivity, or high-availability failures. Consult the Exchange service documentation before disabling any service. Test changes in a non-production environment. Before disabling POP3 or IMAP4, confirm that no mail clients, monitoring systems, or legacy integrations depend on those protocols. Disabling POP3/IMAP4 services does not affect MAPI, EWS, ActiveSync, or SMTP connectivity.

References

• V-259702 Exchange services must be documented and unnecessary services must be removed or disabled (EX19-MB-000198)
• V-259635 Exchange services must be documented and unnecessary services must be removed or disabled (EX19-ED-000198)
• Exchange services reference
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI SYS.1.1.A6 — Deaktivierung nicht benötigter Dienste

EDCA-IAC-001: UPN matches primary SMTP address

Category: Identity and Access Control | Severity: Medium | Frameworks: Best Practice

Remediation

Align UPN values and primary SMTP addresses according to identity policy. Use IdFix (https://github.com/microsoft/idfix) to identify and remediate UPN and format errors before synchronizing with Entra ID. Where aligning UPNs is not feasible, configure Alternate Login ID via AD FS or the Entra ID email sign-in feature as a compensating control.

# Diagnose: Find user mailboxes where UserPrincipalName differs from primary SMTP address
Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox | Where-Object { $_.UserPrincipalName -ne $_.WindowsEmailAddress.ToString() } | Select-Object DisplayName, UserPrincipalName, WindowsEmailAddress | Sort-Object DisplayName

Considerations

Updating a user principal name (UPN) in Active Directory affects the login identity used by Modern Authentication. Changes must be coordinated with the identity team and may temporarily disrupt SSO. Email addresses remain unaffected unless also updated. If UPN alignment is not possible due to organisational constraints (e.g. corporate UPN suffix differs from mail domain), configure Alternate Login ID in AD FS or enable email sign-in in Entra ID as a compensating control rather than leaving mismatches unaddressed.

References

• IdFix — identify and fix directory synchronization errors before Entra ID Connect sync
• Configuring Alternate Login ID (AD FS) — when UPN-to-SMTP alignment is not feasible
• Email as alternate login ID (Entra ID) — when UPN-to-SMTP alignment is not feasible

EDCA-IAC-002: Exchange computer membership baseline

Category: Identity and Access Control | Severity: Medium | Frameworks: Best Practice

Remediation

Add the Exchange server's computer object to both the Exchange Trusted Subsystem and Exchange Servers universal security groups in Active Directory. Perform an IISReset after updating group membership.

# Diagnose: Check Exchange server computer account AD group membership
$groups = (Get-ADComputer $env:COMPUTERNAME -Properties MemberOf -ErrorAction SilentlyContinue).MemberOf
$groups | ForEach-Object { (Get-ADGroup $_ -ErrorAction SilentlyContinue).Name } | Where-Object { $_ } | Sort-Object
# Expected: 'Exchange Servers', 'Exchange Trusted Subsystem', 'Exchange Windows Permissions'

Considerations

Exchange Server computer accounts must be members of the Exchange Servers universal security group for correct service operation. Removing Exchange from this group will break Exchange service functionality. This control is informational - remediation should only be performed if the membership was accidentally altered.

References

• CSS ExchangeComputerMembership

EDCA-IAC-003: NTLMv2 authentication enforcement baseline

Category: Identity and Access Control | Severity: High | Frameworks: Best Practice, CIS, CISA, ANSSI, BSI

Remediation

Set LmCompatibilityLevel to 5 (refuse LM and NTLM, send NTLMv2), and set NtlmMinClientSec and NtlmMinServerSec to require NTLMv2 session security with 128-bit encryption.

# Enforce NTLMv2 only - refuse LM and NTLM (CIS 2.3.11.7)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Type DWord -Value 5

# Require NTLMv2 session security + 128-bit encryption for NTLM SSP clients (CIS 2.3.11.10)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name NtlmMinClientSec -Type DWord -Value 537395200

# Require NTLMv2 session security + 128-bit encryption for NTLM SSP servers (CIS 2.3.11.11)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name NtlmMinServerSec -Type DWord -Value 537395200

Considerations

Setting LAN Manager authentication level to NTLMv2-only will break authentication for legacy clients and systems that only support LM or NTLM authentication. Requiring NTLM 128-bit session encryption drops connections from legacy clients that only support 56-bit encryption (pre-Windows 2000). Verify all clients, servers, and services that authenticate against Exchange or AD support NTLMv2 and 128-bit session security before enforcing these policies. Test against any legacy NTLM-dependent services before applying.

References

• CIS Microsoft Windows Server Benchmark
• Network security: LAN Manager authentication level
• CIS 2.3.11.7 (L1): Ensure 'Network security: LAN Manager authentication level' is set to 'Send NTLMv2 response only. Refuse LM & NTLM'
• Network security: minimum session security for NTLM SSP based clients and servers
• CIS 2.3.11.10 (L1): Ensure 'Network security: Minimum session security for NTLM SSP based (including secure RPC) clients' is set to 'Require NTLMv2 session security, Require 128-bit encryption'
• CIS 2.3.11.11 (L1): Ensure 'Network security: Minimum session security for NTLM SSP based (including secure RPC) servers' is set to 'Require NTLMv2 session security, Require 128-bit encryption'
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI APP.2.2.A9 — Schutz der Authentisierung beim Einsatz von AD DS
• BSI SYS.1.2.3.A5 — Sichere Authentisierung und Autorisierung in Windows Server

EDCA-IAC-004: Modern Authentication is configured

Category: Identity and Access Control | Severity: High | Frameworks: Best Practice, CISA

Remediation

Enable all Modern Authentication prerequisites on-premises. Additional AD FS or Azure AD / Exchange Online configuration steps must be completed separately.

# === DIAGNOSTICS ===
# Check OAuth2ClientProfileEnabled
Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled

# Check auth servers (Type, IsDefaultAuthorizationEndpoint, AuthMetadataUrl)
Get-AuthServer | Select-Object Name, Type, Enabled, IsDefaultAuthorizationEndpoint, AuthMetadataUrl | Format-List

# Check SSL Offloading on Outlook Anywhere connectors
Get-OutlookAnywhere | Select-Object Identity, SSLOffloading

# Check OAuthAuthentication on virtual directories
Get-MapiVirtualDirectory | Select-Object Identity, OAuthAuthentication
Get-WebServicesVirtualDirectory | Select-Object Identity, OAuthAuthentication
Get-ActiveSyncVirtualDirectory | Select-Object Identity, OAuthAuthentication
Get-AutodiscoverVirtualDirectory | Select-Object Identity, OAuthAuthentication

# === REMEDIATION — Common steps (both HMA and AD FS) ===
# 1. Enable Modern Authentication at the organization level
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

# 2. Disable SSL Offloading on Outlook Anywhere connectors
Get-OutlookAnywhere | Set-OutlookAnywhere -SSLOffloading $false

# 3. Enable OAuth on virtual directories that support the parameter
# NOTE: Set-MapiVirtualDirectory and Set-ActiveSyncVirtualDirectory do not expose -OAuthAuthentication.
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -OAuthAuthentication $true
Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -OAuthAuthentication $true

# 4. Restart IIS to apply virtual directory changes
IISReset /noforce

# === FOR HMA (Entra/Azure AD) — Requires Classic Full Hybrid ===
# Set EvoSTS as the default authorization endpoint (replace 'EvoSts' if named differently):
Set-AuthServer -Identity 'EvoSts' -IsDefaultAuthorizationEndpoint $true
# NOTE: Full HMA setup requires running the Hybrid Configuration Wizard and Azure AD steps. See:
# https://learn.microsoft.com/microsoft-365/enterprise/configure-exchange-server-for-hybrid-modern-authentication

# === FOR AD FS — Requires Exchange 2019 CU13+ or Exchange SE, and AD FS 2019+ ===
# Create an auth server pointing to the AD FS federation metadata URL:
New-AuthServer -Type ADFS -Name 'MyADFSServer' -AuthMetadataUrl 'https://<adfs-fqdn>/FederationMetadata/2007-06/FederationMetadata.xml'
Set-AuthServer -Identity 'MyADFSServer' -IsDefaultAuthorizationEndpoint $true
# NOTE: Full AD FS setup requires configuring ADFS application groups, scopes, and client policies. See:
# https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/enable-modern-auth-in-exchange-server-on-premises

Considerations

• HMA (Entra/Azure AD): requires Classic Full Hybrid configuration (Hybrid Configuration Wizard with Full option). Modern Hybrid (Hybrid Agent) does not support HMA. Minimum Exchange versions: 2013 CU19, 2016 CU8, 2019 RTM, SE RTM.
• AD FS Modern Authentication: does not require Exchange Hybrid or Entra ID. Supported only on Exchange 2019 CU13+ and Exchange SE. Exchange 2016 and 2013 are not supported for AD FS modern auth. Requires AD FS on Windows Server 2019 or later. AD FS cannot be installed on the Exchange server.
• The AuthMetadataUrl of the default auth server identifies the method: URLs containing login.windows.net or login.microsoftonline.com indicate HMA; on-premises FQDN URLs indicate AD FS.
• SSL Offloading is incompatible with Modern Authentication: disabling SSL Offloading changes how Outlook Anywhere authenticates and may require reconfiguring load balancer TLS termination to SSL Bridging.
• Disabling SSL Offloading and enabling Extended Protection should be coordinated - see EDCA-SEC-014.
• IISReset briefly interrupts OWA, ECP, EWS, and Autodiscover. Schedule during a maintenance window.
• For AD FS, Outlook for Windows requires build 16327.20200 or later (Outlook 365 Current Channel 2304+). Outlook 2021 Volume License and Outlook 2016/2019 (any version) do not support AD FS modern auth.
• Pilot with a subset of users before enabling Modern Authentication broadly. Use authentication policies (New-AuthenticationPolicy) to selectively enable or block Modern Auth per user.
• Rolling back Modern Auth requires setting OAuth2ClientProfileEnabled back to $false, resetting the auth server IsDefaultAuthorizationEndpoint, then restarting IIS.

References

• Enabling Modern Auth in Exchange on-premises (AD FS)
• Configure Exchange Server on-premises to use Hybrid Modern Authentication (HMA)
• Hybrid Modern Authentication overview and prerequisites
• CISA MS Exchange Security Best Practices

EDCA-IAC-005: RDP requires Network Level Authentication

Category: Identity and Access Control | Severity: High | Frameworks: CIS, ANSSI, BSI

Remediation

Require NLA for RDP-Tcp endpoint.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Type DWord -Value 1

Considerations

Enabling Network Level Authentication (NLA) for RDP requires that connecting clients support CredSSP authentication. Very old RDP clients (pre-Vista) may not connect. Some RDP proxy solutions may require configuration updates. Test admin connectivity after enabling NLA before applying broadly.

References

• CIS Microsoft Windows Server 2019/2022/2025 Benchmarks
• NLA for Remote Desktop
• CIS 18.10.28.3.8 (L1): Ensure 'Require user authentication for remote connections by using Network Level Authentication' is set to 'Enabled'
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI SYS.1.2.3.A6 — Sicherheit beim Fernzugriff über RDP

EDCA-IAC-006: WDigest UseLogonCredential disabled

Category: Identity and Access Control | Severity: High | Frameworks: CIS, ANSSI, BSI

Remediation

Disable WDigest credential caching by setting UseLogonCredential to 0.

New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential -Type DWord -Value 0

Considerations

Disabling WDigest UseLogonCredential prevents cleartext password caching in LSASS memory, which is a common credential harvesting technique. There is no operational impact on Exchange functionality from disabling this setting. A reboot may be required for the change to take full effect.

References

• CIS Microsoft Windows Server 2019/2022/2025 Benchmarks
• UseLogonCredential security guidance
• CIS 18.3.7 (L1): Ensure 'MSS: (UseLogonCredential) WDigest Authentication' (UseLogonCredential registry value) is set to 'Disabled'
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI APP.2.2.A9 — Schutz der Authentisierung beim Einsatz von AD DS
• BSI SYS.1.2.3.A5 — Sichere Authentisierung und Autorisierung in Windows Server

EDCA-IAC-007: Alternate Service Account (ASA) usage follows Kerberos best practice

Category: Identity and Access Control | Severity: Low | Frameworks: Best Practice, CISA

Remediation

If ASA is required, use a dedicated account, keep credentials synchronized across Client Access servers, and rotate with RollAlternateServiceAccountPassword.ps1; otherwise remove ASA credentials.

# Diagnose: Check Alternate Service Account credential status on Client Access servers
Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | Select-Object Name, AlternateServiceAccountConfiguration | Format-List
# Review for stale or multiple credential entries. Only the current ASA password should be active.

# To initially assign an ASA credential to Client Access services (run once per server):
# Set-ClientAccessService -Identity $env:COMPUTERNAME -AlternateServiceAccountCredential (Get-Credential)

# To rotate the ASA password across all Client Access servers using the built-in Exchange rollover script:
$rollScript = Join-Path $exinstall 'Scripts' | Join-Path -ChildPath 'RollAlternateServiceAccountPassword.ps1'
# & $rollScript -ToEntireForest -GenerateNewPasswordFor 'DOMAIN\ASAAccountName' -Verbose

Considerations

The Kerberos Alternate Service Account (ASA) must be configured identically on all load-balanced Exchange Client Access servers. The ASA password must be periodically rotated and kept consistent across all servers. Misconfiguration will break Kerberos authentication and fall back to NTLM, which may be blocked by other security policies.

References

• Configure Kerberos authentication for load-balanced Client Access services
• Get-ClientAccessService cmdlet
• ASA rollout and verification guidance
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - use Kerberos (Alternate Service Account) rather than NTLM for load-balanced Client Access authentication

EDCA-IAC-008: Exchange split permissions are enabled

Category: Identity and Access Control | Severity: High | Frameworks: CISA

Remediation

Enable Exchange AD Split Permissions by re-running Exchange Setup with /PrepareAD /ActiveDirectorySplitPermissions:true. This cannot be applied via a PowerShell cmdlet post-installation.

# Diagnose: Check if Exchange role groups currently hold mail recipient and security group creation rights
Get-ManagementRoleAssignment | Where-Object { $_.Role -match 'Mail Recipient Creation|Security Group Creation' } | Select-Object Role, RoleAssignee, RoleAssigneeType | Format-Table -AutoSize
# If Exchange role groups appear above, AD split permissions are NOT currently enabled.
# To enable (IRREVERSIBLE without re-running /PrepareAD - plan carefully):
# .\Setup.exe /PrepareAD /ActiveDirectorySplitPermissions:true /IAcceptExchangeServerLicenseTerms

Considerations

Enabling Exchange split permissions removes Exchange administrators ability to directly modify Active Directory user and group objects. This is an organizational change requiring coordination with the Active Directory team. After enabling, Exchange provisioning workflows must be updated to use AD admin procedures for security group management.

References

• Exchange split permissions
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - enable Exchange split permissions to limit Exchange Server's Active Directory write access

EDCA-IAC-009: Basic Authentication is disabled after Modern Authentication rollout

Category: Identity and Access Control | Severity: High | Frameworks: CISA, BSI

Remediation

Create or update the organization's default authentication policy to block Basic Authentication for all tracked protocols (ActiveSync, Autodiscover, IMAP, MAPI, OfflineAddressBook, OutlookService, POP, ReportingWebServices, REST, RPC, SMTP, WebServices, WindowsLiveId). Validate that Modern Authentication (EX-BP-049) is fully functional for all clients before blocking Basic Authentication to prevent access outages.

# Check the current default authentication policy
$orgConfig = Get-OrganizationConfig
$policyName = [string]$orgConfig.DefaultAuthenticationPolicy

$params = @{
    AllowBasicAuthActiveSync           = $false
    AllowBasicAuthAutodiscover         = $false
    AllowBasicAuthImap                 = $false
    AllowBasicAuthMapi                 = $false
    AllowBasicAuthOfflineAddressBook   = $false
    AllowBasicAuthOutlookService       = $false
    AllowBasicAuthPop                  = $false
    AllowBasicAuthReportingWebServices = $false
    AllowBasicAuthRest                 = $false
    AllowBasicAuthRpc                  = $false
    AllowBasicAuthSmtp                 = $false
    AllowBasicAuthWebServices          = $false
    AllowBasicAuthWindowsLiveId        = $false
}

if (-not [string]::IsNullOrWhiteSpace($policyName)) {
    # Update the existing default policy to block Basic Auth for all tracked protocols
    Set-AuthenticationPolicy -Identity $policyName @params
} else {
    # No default policy exists: create one that blocks all Basic Auth and assign it as the org default
    New-AuthenticationPolicy -Name 'Block Basic Auth' @params
    Set-OrganizationConfig -DefaultAuthenticationPolicy 'Block Basic Auth'
}

Considerations

Disabling Basic Authentication will immediately break any client or application still using Basic Auth for SMTP, EWS, WebDAV, or remote PowerShell connections. Perform a comprehensive audit of all application authentication methods before disabling. Applications that cannot be migrated to Modern Authentication require alternative integration approaches.

References

• Enable Modern Authentication in Exchange on-premises
• Disabling Legacy Authentication in Exchange Server 2019
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - disable Basic Authentication after Modern Authentication is fully deployed
• BSI APP.5.2.A3 — Berechtigungsmanagement und Zugriffsrechte

EDCA-IAC-010: Administrative access to EAC and remote PowerShell is restricted

Category: Identity and Access Control | Severity: High | Frameworks: CISA, DISA, BSI

Remediation

Create Client Access Rules to restrict EAC and remote PowerShell access to authorized source IP ranges, and disable RemotePowerShellEnabled for all users who are not Exchange administrators.

# --- Check 1: Client Access Rules ---
# Review existing rules; look for rules covering RemotePowerShell and ExchangeAdminCenter protocols.
Get-ClientAccessRule | Select-Object Name, Action, AnyOfProtocols, AnyOfClientIPAddressesOrRanges, Priority, Enabled | Sort-Object Priority | Format-Table -AutoSize

# Create a rule to allow only trusted management IP ranges for remote PowerShell and EAC
# (replace 10.0.0.0/8 with your actual management IP range)
New-ClientAccessRule -Name 'Allow PS and EAC from management range' -Action AllowAccess -AnyOfProtocols RemotePowerShell, ExchangeAdminCenter -AnyOfClientIPAddressesOrRanges 10.0.0.0/8 -Priority 1
New-ClientAccessRule -Name 'Block PS and EAC from all other sources' -Action DenyAccess -AnyOfProtocols RemotePowerShell, ExchangeAdminCenter -AnyOfClientIPAddressesOrRanges 0.0.0.0-255.255.255.255 -Priority 2

# --- Check 2: Non-Exchange-admin users with RemotePowerShellEnabled ---
# Find Exchange RBAC role group members (Exchange admins):
$adminSams = [System.Collections.Generic.HashSet[string]]::new([System.StringComparer]::OrdinalIgnoreCase)
Get-RoleGroup | ForEach-Object {
    Get-RoleGroupMember -Identity $_.Name -ErrorAction SilentlyContinue |
        ForEach-Object { $null = $adminSams.Add($_.SamAccountName) }
}

# Find non-admin users with RemotePowerShellEnabled = $true and disable it:
Get-User -Filter {RemotePowerShellEnabled -eq $true} -ResultSize Unlimited |
    Where-Object { -not $adminSams.Contains($_.SamAccountName) } |
    ForEach-Object {
        Write-Host "Disabling RemotePowerShellEnabled for $($_.Name) ($($_.SamAccountName))"
        Set-User -Identity $_.Identity -RemotePowerShellEnabled $false
    }

Considerations

Restricting EAC and remote PowerShell access to specific client access rules may lock out administrators working from unregistered IP addresses. Ensure VPN or jump server access is available for administrative operations. Changes to Client Access Rules take effect immediately and can lock out the current session.

References

• Client Access Rules in Exchange
• Network ports for clients and mail flow in Exchange
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - restrict administrative access to Exchange Admin Center and remote PowerShell
• V-259698 Role-Based Access Control must be defined for privileged and nonprivileged users (EX19-MB-000173)
• V-259655 The RBAC role for audit log management must be defined and restricted (EX19-MB-000034)
• BSI APP.5.2.A3 — Berechtigungsmanagement und Zugriffsrechte
• BSI APP.2.2.A17 — Anmelderestriktionen für hochprivilegierte Konten der Gesamtstruktur auf Clients und Servern

EDCA-IAC-011: Dedicated hybrid app is used by EvoSTS AuthServer

Category: Identity and Access Control | Severity: High | Frameworks: Best Practice, CISA

Remediation

Deploy a dedicated Exchange Hybrid Application using the ConfigureExchangeHybridApplication tool to support the transition from EWS to Microsoft Graph API for hybrid functionality.

# Diagnose: Check EvoSTS AuthServer ApplicationIdentifier for dedicated hybrid app configuration
Get-AuthServer | Where-Object { $_.Type -eq 'AzureAD' } | Select-Object Name, Enabled, ApplicationIdentifier, DomainName | Format-List
# Default (non-dedicated) app ApplicationIdentifier: 48af08dc-f6d2-435f-b2a7-069abd99c086
# A dedicated hybrid app will show a different GUID provisioned via the Hybrid Configuration Wizard.

Considerations

Transitioning from a shared to a dedicated hybrid application requires creating a new dedicated application in Azure AD and re-registering the EvoSTS AuthServer in Exchange. During the transition period, hybrid connectivity (free/busy, mail routing, mailbox moves) may be briefly interrupted. Test hybrid features after completing the migration.

References

• CSS ExchangeHybridApplicationCheck
• Dedicated Exchange Hybrid Application guidance
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - use a dedicated hybrid application identity to avoid over-privileged EvoSTS AuthServer

EDCA-IAC-012: Windows Integrated Authentication (NTLM/Negotiate) is present on Exchange virtual directories

Category: Identity and Access Control | Severity: Medium | Frameworks: Best Practice, DISA

Remediation

Restore NTLM and WindowsIntegrated (Negotiate) to the authentication methods of the affected virtual directories. For MAPI, restore Ntlm and Negotiate in IISAuthenticationMethods. For all other virtual directories, restore Ntlm and WindowsIntegrated in InternalAuthenticationMethods.

# Restore Windows Integrated Authentication on affected virtual directories.
# Replace <Server> with the actual server name and adjust the site name if needed.
# Run only the line(s) that correspond to the affected virtual directory.

# MAPI virtual directory
Set-MapiVirtualDirectory -Identity '<Server>\mapi (Default Web Site)' -IISAuthenticationMethods Ntlm,Negotiate,OAuth

# OWA virtual directory
Set-OwaVirtualDirectory -Identity '<Server>\owa (Default Web Site)' -InternalAuthenticationMethods WindowsIntegrated,Basic,Fba

# ECP virtual directory
Set-EcpVirtualDirectory -Identity '<Server>\ecp (Default Web Site)' -InternalAuthenticationMethods WindowsIntegrated,Basic,Fba

# EWS virtual directory
Set-WebServicesVirtualDirectory -Identity '<Server>\EWS (Default Web Site)' -InternalAuthenticationMethods Ntlm,WindowsIntegrated,WSSecurity,OAuth

# Autodiscover virtual directory
Set-AutodiscoverVirtualDirectory -Identity '<Server>\Autodiscover (Default Web Site)' -InternalAuthenticationMethods Ntlm,WindowsIntegrated

# After restoring, run iisreset /noforce on the Exchange server to apply the changes.

Considerations

Windows Integrated Authentication (NTLM/Negotiate) is required for internal Outlook clients using MAPI over HTTPS on some configurations. Removing it without enabling Modern Authentication as a replacement will break internal Outlook connectivity. This control verifies presence, not absence - the authentication method should be preserved alongside other authentication methods.

References

• Default authentication settings for Exchange virtual directories
• Set-OwaVirtualDirectory
• Set-WebServicesVirtualDirectory
• V-259650 Exchange must have authenticated access set to integrated Windows authentication only (EX19-MB-000020)
• V-259703 Exchange Outlook Anywhere clients must use NTLM authentication to access email (EX19-MB-000203)

EDCA-IAC-013: OWA forms-based authentication is configured per version requirements

Category: Identity and Access Control | Severity: Medium | Frameworks: DISA

Remediation

Enable forms-based authentication on Exchange 2019 and Exchange SE OWA virtual directories. On Exchange 2016, disable forms-based authentication.

# Exchange 2019 and Exchange SE: enable forms-based authentication
Get-OwaVirtualDirectory -Server $env:COMPUTERNAME | Set-OwaVirtualDirectory -FormsAuthentication $true -LogonFormat UserName -DefaultDomain $env:USERDNSDOMAIN

# Exchange 2016 exception: disable forms-based authentication
# Get-OwaVirtualDirectory -Server $env:COMPUTERNAME | Set-OwaVirtualDirectory -FormsAuthentication $false

Considerations

Exchange 2019 and Exchange SE require forms-based authentication enabled (DISA STIG ). Exchange 2016 is the exception: the DISA STIG requires FBA disabled. These requirements are directly opposed between versions -- verify the installed Exchange version before applying.

References

• V-259647 Exchange must have forms-based authentication enabled (EX19-MB-000008)
• V-228417 Exchange must have forms-based authentication disabled (EX16-MB-002920)
• Set-OwaVirtualDirectory cmdlet

EDCA-IAC-014: Mobile device mailbox policy does not allow simple passwords

Category: Identity and Access Control | Severity: Medium | Frameworks: Best Practice, CIS

Remediation

Disable simple passwords in the default mobile device mailbox policy.

# Disallow simple passwords in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -AllowSimplePassword $false

Considerations

Disabling simple passwords requires users to set a more complex PIN or password on their devices. End-user communication may be required before enforcing this change.

References

• CIS 3.1 (L1): Ensure Allow simple passwords is set to False
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-015: Mobile device mailbox policy does not allow unmanaged devices

Category: Identity and Access Control | Severity: Medium | Frameworks: Best Practice, CIS

Remediation

Block unmanaged devices in the default mobile device mailbox policy.

# Block unmanaged (non-provisionable) devices in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -AllowNonProvisionableDevices $false

Considerations

Blocking non-provisionable devices will prevent some older devices from synchronising. Evaluate the device inventory before enforcing this setting.

References

• CIS 3.2 (L1): Ensure Allow unmanaged devices is set to False
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-016: Mobile device mailbox policy enforces password history of 4 or more

Category: Identity and Access Control | Severity: Low | Frameworks: Best Practice, CIS

Remediation

Set password history to 4 or more in the default mobile device mailbox policy.

# Enforce a password history of 4 in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -PasswordHistory 4

Considerations

Password history enforcement requires devices to track previous passwords. Most modern smartphones support this feature.

References

• CIS 3.3 (L1): Ensure Enforce password history is set to 4 or greater
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-017: Mobile device mailbox policy requires a minimum password length of 4 or more

Category: Identity and Access Control | Severity: Low | Frameworks: Best Practice, CIS

Remediation

Set minimum password length to 4 or more in the default mobile device mailbox policy.

# Require a minimum password length of 4 in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -MinPasswordLength 4

Considerations

Setting a minimum password length together with alphanumeric password requirements provides stronger protection than PIN-only policies.

References

• CIS 3.4 (L1): Ensure Minimum password length is set to 4 or more
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-018: Mobile device mailbox policy limits maximum failed password attempts to 10 or fewer

Category: Identity and Access Control | Severity: Medium | Frameworks: Best Practice, CIS

Remediation

Set maximum failed password attempts to 10 in the default mobile device mailbox policy.

# Limit failed password attempts to 10 in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -MaxPasswordFailedAttempts 10

Considerations

Setting a low value (e.g., 4-5) may result in accidental device wipes. A value of 10 balances security and usability. Ensure users are aware of the wipe policy.

References

• CIS 3.5 (L1): Ensure Number of attempts allowed is set to 10
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-019: Mobile device mailbox policy requires password expiration of 365 days or less

Category: Identity and Access Control | Severity: Low | Frameworks: Best Practice, CIS

Remediation

Set password expiration to 365 days or fewer in the default mobile device mailbox policy.

# Set password expiration to 365 days in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -PasswordExpiration 365

Considerations

Frequent password expiration can cause user friction and may lead to weaker passwords being chosen. Consider balancing expiration frequency with other compensating controls.

References

• CIS 3.6 (L1): Ensure Password expiration is set to 365 or less
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-020: Mobile device mailbox policy refresh interval is 1 day or less

Category: Identity and Access Control | Severity: Low | Frameworks: Best Practice, CIS

Remediation

Set the device policy refresh interval to 1 day in the default mobile device mailbox policy.

# Set the policy refresh interval to 1 day in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -DevicePolicyRefreshInterval 1.00:00:00

Considerations

A refresh interval of 1 day is a reasonable baseline. More frequent intervals increase server-side load. The value is expressed as a TimeSpan.

References

• CIS 3.7 (L1): Ensure Refresh interval is set to 1
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-021: Mobile device mailbox policy requires an alphanumeric password

Category: Identity and Access Control | Severity: Medium | Frameworks: Best Practice, CIS

Remediation

Require alphanumeric passwords in the default mobile device mailbox policy.

# Require alphanumeric passwords in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -AlphanumericPasswordRequired $true

Considerations

Alphanumeric passwords must be combined with a minimum password length requirement to be effective. Note that some devices may display a full keyboard rather than a numeric PIN pad when this is enabled.

References

• CIS 3.8 (L1): Ensure Require alphanumeric password is set to True
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-022: Mobile device mailbox policy requires device encryption

Category: Identity and Access Control | Severity: High | Frameworks: Best Practice, CIS

Remediation

Require device encryption in the default mobile device mailbox policy.

# Require device encryption in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -RequireDeviceEncryption $true

Considerations

Some older devices do not support device encryption and will be blocked if this setting is enabled together with AllowNonProvisionableDevices $false. Review the device inventory before enforcing.

References

• CIS 3.9 (L1): Ensure Require encryption on device is set to True
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-023: Mobile device mailbox policy requires a device password

Category: Identity and Access Control | Severity: High | Frameworks: Best Practice, CIS

Remediation

Require a device password in the default mobile device mailbox policy.

# Require a device password in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -PasswordEnabled $true

Considerations

Requiring a password on mobile devices may cause friction for users who previously had no PIN. Communicate this change in advance and provide instructions for setting a compliant password.

References

• CIS 3.10 (L1): Ensure Require password is set to True
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-024: Mobile device mailbox policy locks after 15 minutes of inactivity

Category: Identity and Access Control | Severity: Medium | Frameworks: Best Practice, CIS

Remediation

Set the inactivity lock timeout to 15 minutes or less in the default mobile device mailbox policy.

# Set the inactivity lock to 15 minutes in the default mobile device mailbox policy.
Set-MobileDeviceMailboxPolicy -Identity Default -MaxInactivityTimeLock 00:15:00

Considerations

A shorter inactivity timeout provides more security but may be inconvenient for users. A 15-minute limit is broadly accepted as a good balance. Consider shorter timeouts for high-security environments.

References

• CIS 3.11 (L1): Ensure Time without user input before password must be re-entered is set to 15
• Mobile device mailbox policies in Exchange Server

EDCA-IAC-026: Kerberos AES encryption is enforced; RC4 and DES are disabled

Category: Identity and Access Control | Severity: High | Frameworks: ANSSI, BSI

Remediation

Set SupportedEncryptionTypes to 24 (AES128 + AES256 only) under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters via Group Policy (Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options: 'Network security: Configure encryption types allowed for Kerberos'). A reboot is required for the change to take full effect.

# Check current Kerberos supported encryption types
$kerbPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters'
$val = (Get-ItemProperty $kerbPath -Name SupportedEncryptionTypes -ErrorAction SilentlyContinue).SupportedEncryptionTypes
if ($null -eq $val) {
    "SupportedEncryptionTypes: not set (system default - RC4 is included)"
} else {
    $types = @()
    if ($val -band 1)  { $types += 'DES-CBC-CRC' }
    if ($val -band 2)  { $types += 'DES-CBC-MD5' }
    if ($val -band 4)  { $types += 'RC4-HMAC' }
    if ($val -band 8)  { $types += 'AES128-CTS-HMAC-SHA1' }
    if ($val -band 16) { $types += 'AES256-CTS-HMAC-SHA1' }
    "SupportedEncryptionTypes: $val - Enabled: $($types -join ', ')"
}

# Set AES128 + AES256 only (24 = 8 + 16)
New-Item -Path $kerbPath -Force | Out-Null
Set-ItemProperty -Path $kerbPath -Name SupportedEncryptionTypes -Type DWord -Value 24
Write-Host 'Kerberos SupportedEncryptionTypes set to 24 (AES128 + AES256 only). A reboot is required.'

Considerations

Disabling RC4 Kerberos requires that all Kerberos service principals the Exchange server authenticates against also have AES keys. Domain controllers on Windows Server 2008 R2 and later support AES Kerberos by default. Service accounts that have never had their password changed since AES support was introduced in the domain may only have RC4 keys in their msDS-SupportedEncryptionTypes attribute; those accounts must have their passwords reset before AES-only is enforced. Before setting SupportedEncryptionTypes=24 on Exchange servers, verify that all domain controllers in the AD site list AES in their computer account msDS-SupportedEncryptionTypes. After the change, reboot the Exchange server and monitor for Kerberos failures (Event ID 4769 failure code 0x17 = KDC_ERR_ETYPE_NOSUPP) in the Security event log.

References

• Network security: Configure encryption types allowed for Kerberos
• Decrypting the selection of supported Kerberos encryption types
• ANSSI - Recommandations pour l'administration sécurisée des SI reposant sur AD (2023)
• BSI APP.2.2.A9 — Schutz der Authentisierung beim Einsatz von AD DS

EDCA-IAC-027: Exchange computer accounts do not have unconstrained Kerberos delegation

Category: Identity and Access Control | Severity: High | Frameworks: ANSSI

Remediation

Remove the TRUSTED_FOR_DELEGATION flag from Exchange computer accounts in Active Directory using Set-ADComputer or the Active Directory Users and Computers console (Account tab: clear 'Trust this computer for delegation to any service (Kerberos only)'). If delegation is required for a specific integration, configure constrained delegation targeting only the required SPNs.

# Check if this Exchange server's computer account has unconstrained Kerberos delegation
try {
    $computer = Get-ADComputer -Identity $env:COMPUTERNAME -Properties userAccountControl, TrustedForDelegation -ErrorAction Stop
    $unconstrained = $computer.TrustedForDelegation
    "Computer: $($computer.Name)"
    "TrustedForDelegation (unconstrained): $unconstrained"
    if ($unconstrained) {
        Write-Warning 'UNCONSTRAINED delegation is ENABLED - this is a HIGH severity finding.'
    } else {
        Write-Host 'TrustedForDelegation is not set - compliant.'
    }
} catch {
    "Unable to query Active Directory: $($_.Exception.Message)"
    "Ensure the ActiveDirectory PowerShell module is available (RSAT or AD DS role)."
}

# To remediate (requires Domain Admin or delegated rights on the computer object):
# Set-ADComputer -Identity $env:COMPUTERNAME -TrustedForDelegation $false

Considerations

Exchange Server does not require unconstrained delegation for Exchange 2016, 2019, or Exchange SE mail flow, client connectivity, or DAG operations. If unconstrained delegation is found enabled, it is likely a historical misconfiguration or was set during an older Exchange setup process. Remediation (removing TrustedForDelegation) does not affect Exchange functionality. If a specific third-party integration requires Kerberos delegation, configure resource-based constrained delegation (RBCD) or S4U2Proxy constrained delegation scoped to the specific service SPNs instead.

References

• Kerberos constrained delegation overview
• Configure Kerberos constrained delegation (S4U2Proxy)
• ANSSI - Recommandations pour l'administration sécurisée des SI reposant sur AD (2023)

EDCA-IAC-028: Domain object DACL WriteDACL ACEs carry the Inherit-Only flag

Category: Identity and Access Control | Severity: High | Frameworks: Best Practice, ANSSI

Remediation

Install the minimum qualifying cumulative update for your Exchange version (Exchange 2016 CU12 / Exchange 2019 CU1 or later, or any Exchange SE build), then run Setup /PrepareAD as a member of Enterprise Admins. Run Setup /PrepareDomain in every domain of the forest as a member of Domain Admins for each domain. The /PrepareAD operation automatically runs /PrepareDomain for the domain in which it is executed, but not for other domains in the forest.

# Diagnose domain object DACL WriteDACL ACE state
# Run from any domain-joined machine; requires read access to AD (no elevated rights needed for diagnosis)
param(
    [string]$Domain = ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name)
)

# The Exchange WriteDACL ACEs use ObjectType = all-zeros (applies to all object types)
# and carry the target class GUID in InheritedObjectType.
$userClassGuid          = [Guid]'bf967aba-0de6-11d0-a285-00aa003049e2'  # User
$inetOrgPersonClassGuid = [Guid]'4828cc14-1437-45bc-9b07-ad6f015e5f28' # inetOrgPerson
$groupClassGuid         = [Guid]'bf967a9c-0de6-11d0-a285-00aa003049e2' # Group (AdminSDHolder, Exchange 2016+)
$writeDaclRight         = [System.DirectoryServices.ActiveDirectoryRights]::WriteDacl

try {
    $domainDN    = ('DC=' + ($Domain -replace '\.', ',DC='))
    $domainEntry = [System.DirectoryServices.DirectoryEntry]"LDAP://$domainDN"
    $domainAcl   = $domainEntry.get_objectSecurity()
    $ewpSid      = (New-Object System.Security.Principal.NTAccount 'Exchange Windows Permissions').Translate([System.Security.Principal.SecurityIdentifier]).Value
    $rules        = @($domainAcl.GetAccessRules($true, $true, [System.Security.Principal.SecurityIdentifier]))

    foreach ($guid in @($userClassGuid, $inetOrgPersonClassGuid)) {
        $ace = $rules | Where-Object {
            $_.IdentityReference.Value -eq $ewpSid -and
            $_.ActiveDirectoryRights -band $writeDaclRight -and
            $_.ObjectType -eq [Guid]::Empty -and
            $_.InheritedObjectType -eq $guid
        } | Select-Object -First 1
        if ($null -eq $ace) {
            Write-Host "COMPLIANT: InheritedObjectType $guid — ACE absent (Exchange Windows Permissions holds no WriteDACL on the domain object for this class)."
        } elseif ($ace.PropagationFlags -band [System.Security.AccessControl.PropagationFlags]::InheritOnly) {
            Write-Host "COMPLIANT: InheritedObjectType $guid — ACE present, Inherit-Only flag is SET."
        } else {
            Write-Warning "NON-COMPLIANT: InheritedObjectType $guid — ACE present, Inherit-Only flag is MISSING. WriteDACL applies to the domain object itself."
        }
    }
} catch {
    Write-Error "Failed to read domain object DACL: $($_.Exception.Message)"
    Write-Host "Ensure LDAP access to the domain and that the 'Exchange Windows Permissions' group exists."
}

# Remediation: install qualifying CU, then from the Exchange setup directory:
#   .\Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
# In each additional domain in the forest:
#   .\Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Considerations

This control applies only when Exchange runs in the Shared Permissions model (the default). When AD Split Permissions is enabled, Exchange does not hold WriteDACL rights on the domain object and the control is not applicable. The fix requires Setup /PrepareAD plus Setup /PrepareDomain in every domain of the forest; /PrepareDomain does not run automatically for domains other than the one in which /PrepareAD is executed. The control is satisfied when the ACEs are absent from the domain object DACL as well as when they carry the Inherit-Only flag; both states mean Exchange Windows Permissions holds no effective WriteDACL right on the domain object itself. ExchangeSE builds always meet the minimum build requirement; however, compliance still requires that Setup /PrepareAD has been run — which is done automatically during initial Exchange setup. The control reports Warning rather than Fail when no installed Exchange build meets the minimum required version (Exchange 2016 CU12 or Exchange 2019 CU1), indicating that the qualifying cumulative update must be installed before /PrepareAD can apply the fix.

References

• Microsoft KB — Reducing permissions required to run Exchange Server (Shared Permissions Model)
• ANSSI - Recommandations pour l'administration sécurisée des SI reposant sur AD (2023)

EDCA-MON-001: Admin audit logging enabled and configured

Category: Monitoring | Severity: Medium | Frameworks: Best Practice, NIS2, CIS, DISA, ANSSI, BSI

Remediation

Enable Exchange admin audit logging and configure audit record parameters including age limit.

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true -AdminAuditLogAgeLimit 90.00:00:00

Considerations

Admin audit logging generates storage overhead in the arbitration mailbox over time. The default 90-day retention period should be reviewed against organizational compliance requirements; it may be insufficient for regulatory requirements. Ensure the log mailbox (arbitration mailbox) has adequate space. Enabling verbose logging significantly increases log volume and should be used selectively.

References

• Admin audit logging in Exchange
• CIS Microsoft Exchange Server Benchmark
• CIS 1.1.1 (L1): Ensure 'AdminAuditLogEnabled' is set to 'True'
• V-259648 Exchange must have administrator audit logging enabled (EX19-MB-000016)
• V-259654 Exchange audit record parameters must be set (EX19-MB-000033)
• Set-AdminAuditLogConfig cmdlet
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(b): incident handling and audit logging - Section 3.2-3.6, 7, 2.2-2.3
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)
• BSI SYS.1.1.A10 — Protokollierung
• BSI APP.2.2.A7 — Umsetzung sicherer Verwaltungsmethoden für Active Directory

EDCA-MON-002: PowerShell Script Block Logging enabled

Category: Monitoring | Severity: Medium | Frameworks: CIS, ANSSI, BSI

Remediation

Enable Script Block Logging via PowerShell policy registry.

New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' -Name EnableScriptBlockLogging -Type DWord -Value 1

Considerations

Enabling PowerShell Script Block Logging generates detailed logs of all executed script blocks in the Security and Windows PowerShell event logs. This can produce high log volume on active systems. Ensure log retention and collection capacity are adequate before enabling on production Exchange servers.

References

• CIS Microsoft Windows Server 2019 Benchmark v3.0.0
• PowerShell Group Policy settings
• CIS 18.9.104.1.2 (L1): Ensure 'Turn on PowerShell Script Block Logging' is set to 'Enabled'
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)
• BSI SYS.1.2.3.A7 — Verwendung der Windows PowerShell

EDCA-MON-003: Server pending reboot cleared

Category: Monitoring | Severity: Medium | Frameworks: Best Practice

Remediation

Reboot the server to clear pending reboot flags. If registry keys persist after the reboot, manually delete them from the indicated registry locations. Always back up the registry before making manual edits.

# Diagnose: Check for pending reboot indicators in registry
@{ 'CBS RebootPending'='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'; 'WU RebootRequired'='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'; 'PFRO PendingRename'='HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' }.GetEnumerator() | ForEach-Object { "$($_.Key): $(if (Test-Path $_.Value) { 'REBOOT PENDING' } else { 'clear' })" }
# Plan an approved maintenance window to reboot the server to clear all pending indicators.

Considerations

Clearing a pending reboot clears only the state flag - the actual rebooted state is required for changes (such as software updates or service changes) to take effect. Schedule a maintenance window with DAG failover for the reboot. Verify all DAG members are in a healthy state before rebooting any member.

References

• CSS reboot pending guidance

EDCA-MON-004: Transport connectivity logging is enabled

Category: Monitoring | Severity: Medium | Frameworks: DISA, ANSSI

Remediation

Enable transport connectivity logging.

Set-TransportService -Identity $env:COMPUTERNAME -ConnectivityLogEnabled $true

Considerations

Transport connectivity logging generates log files that can grow rapidly on high-traffic servers. Ensure the connectivity log volume has adequate capacity and that log cleanup is configured. Connectivity logs may be required for support investigations into mail flow issues.

References

• Get-TransportService cmdlet
• Set-TransportService cmdlet
• V-259652 Exchange connectivity logging must be enabled (EX19-MB-000031)
• V-259582 Exchange connectivity logging must be enabled (EX19-ED-000031)
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)

EDCA-MON-005: Transport message tracking logging is enabled

Category: Monitoring | Severity: Medium | Frameworks: DISA, ANSSI

Remediation

Enable message tracking logging on transport service.

Set-TransportService -Identity $env:COMPUTERNAME -MessageTrackingLogEnabled $true

Considerations

Message tracking logs contain metadata about every message processed by Transport. On high-traffic servers these logs can consume substantial disk space. Ensure log rotation and disk capacity are appropriate. Message tracking logs may contain sensitive information about internal communication patterns.

References

• Get-TransportService cmdlet
• Set-TransportService cmdlet
• V-259657 Exchange message tracking logging must be enabled (EX19-MB-000041)
• V-259583 Exchange message tracking logging must be enabled (EX19-ED-000041)
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)

EDCA-MON-006: Transport message subject logging is disabled

Category: Monitoring | Severity: Medium | Frameworks: DISA, ANSSI

Remediation

Disable message tracking subject logging.

Set-TransportService -Identity $env:COMPUTERNAME -MessageTrackingLogSubjectLoggingEnabled $false

Considerations

Enabling message subject logging can expose sensitive information in log files. This setting should be disabled in security-sensitive environments. Forensic investigations may require temporary enabling of subject logging with appropriate data governance controls in place.

References

• Get-TransportService cmdlet
• Set-TransportService cmdlet
• V-259656 Exchange email subject line logging must be disabled (EX19-MB-000040)
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)

EDCA-MON-007: Receive connector protocol logging is set to Verbose

Category: Monitoring | Severity: Medium | Frameworks: Best Practice, CIS, DISA, ANSSI

Remediation

Set ProtocolLoggingLevel to Verbose on all receive connectors.

# Enable verbose protocol logging on all receive connectors of this server.
Get-ReceiveConnector -Server $env:COMPUTERNAME | Set-ReceiveConnector -ProtocolLoggingLevel Verbose

Considerations

Verbose protocol logging generates significant disk I/O on high-volume servers. Ensure that adequate disk space and a log rotation / archival policy are in place. Review log paths via Get-TransportService.

References

• CIS 4.1 (L1): Ensure ProtocolLoggingLevel is set to Verbose on Receive Connectors
• Configure protocol logging in Exchange Server
• V-259682 The Exchange global inbound message size must be controlled (EX19-MB-000129)
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)

EDCA-MON-008: Send connector protocol logging is set to Verbose

Category: Monitoring | Severity: Medium | Frameworks: Best Practice, CIS

Remediation

Set ProtocolLoggingLevel to Verbose on all send connectors.

# Enable verbose protocol logging on all send connectors.
Get-SendConnector | Set-SendConnector -ProtocolLoggingLevel Verbose

Considerations

Same storage and rotation considerations as receive connector protocol logging. Coordinate log archival so that verbose logs are retained for at least 90 days for forensic purposes.

References

• CIS 4.4 (L1): Ensure ProtocolLoggingLevel is set to Verbose on Send Connectors
• Configure protocol logging in Exchange Server

EDCA-MON-009: Exchange transport queue monitoring is configured

Category: Monitoring | Severity: Medium | Frameworks: DISA, ANSSI

Remediation

Ensure EdgeTransport.exe.config is present at $ExInstall\Bin\EdgeTransport.exe.config. To customize message expiration timeouts, add or update the NormalPriorityMessageExpirationTimeout and CriticalPriorityMessageExpirationTimeout keys in the appSettings section. Restart the Microsoft Exchange Transport service after any changes.

# Back pressure settings are in $ExInstall\Bin\EdgeTransport.exe.config
# Example appSettings entries (add inside <appSettings>):
#   <add key="NormalPriorityMessageExpirationTimeout"   value="2.00:00:00" />
#   <add key="CriticalPriorityMessageExpirationTimeout" value="0.04:00:00" />
# Restart the transport service after editing:
Restart-Service MSExchangeTransport

Considerations

Exchange SMTP queue growth is disk-bounded: back pressure monitors disk space percentage and database checkpoint depth, not message count. When disk pressure thresholds are reached, Exchange defers inbound SMTP connections. Message expiration is time-bounded by priority - normal messages default to 2 days, critical messages default to 4 hours. These timeouts are enforced even when queues are near-full; critical messages are not protected by size limits. If NormalPriorityMessageExpirationTimeout or CriticalPriorityMessageExpirationTimeout are absent from EdgeTransport.exe.config, Exchange uses built-in compiled defaults (2.00:00:00 and 0.04:00:00 respectively). Changes to EdgeTransport.exe.config require a restart of the Microsoft Exchange Transport service. Use care when modifying back-pressure thresholds as overly aggressive settings may cause unnecessary mail deferral.

References

• V-259659 Exchange queue monitoring must be configured with threshold and action (EX19-MB-000048)
• Back pressure and resource monitoring in Exchange Server
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)

EDCA-MON-010: Exchange audit data is protected from unauthorized access

Category: Monitoring | Severity: Medium | Frameworks: DISA, ANSSI

Remediation

Restrict NTFS permissions on Exchange log directories and limit RBAC access to audit management roles.

# Review NTFS permissions on exchange log directories and restrict to Exchange Admin and SYSTEM only.

Considerations

Audit log protection requires both file-system (NTFS) and RBAC controls. Overly restrictive permissions may interfere with Exchange service accounts that must write to log directories. Review default Exchange service account permissions before making changes. Admin audit entries are recorded in the AuditLog system mailbox; verify its existence and accessibility with: Get-Mailbox -AuditLog.

References

• V-259660 Exchange must protect audit data against unauthorized read access (EX19-MB-000052)
• V-259661 Exchange must protect audit data against unauthorized access (EX19-MB-000053)
• V-259662 Exchange must protect audit data against unauthorized deletion (EX19-MB-000054)
• Audit logging in Exchange Server
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)

EDCA-MON-011: Exchange audit data resides on a separate partition

Category: Monitoring | Severity: Medium | Frameworks: DISA

Remediation

Move Exchange audit log paths to a dedicated volume separate from the OS and Exchange application volumes.

# Verify audit log paths are on dedicated volumes.

Considerations

Moving log paths requires downtime and reconfiguration of the Transport service and audit log configuration. Plan for a maintenance window and ensure the target volume has adequate capacity for log growth.

References

• V-259663 Exchange audit data must be on separate partitions (EX19-MB-000058)
• Exchange Server storage configuration

EDCA-MON-012: Exchange diagnostic event log levels are set to Lowest

Category: Monitoring | Severity: Medium | Frameworks: DISA

Remediation

Set all Exchange diagnostic event log categories to Lowest.

Get-EventLogLevel | Set-EventLogLevel -Level Lowest

Considerations

Setting all categories to Lowest reduces diagnostic logging granularity. If an issue is actively being investigated, consider temporarily raising specific category levels during the investigation period and returning them to Lowest afterwards.

References

• V-259653 Exchange diagnostic event-log must be configured to the minimum level (EX19-MB-000032)
• V-259581 Exchange email diagnostic log level must be set to the lowest level (EX19-ED-000032)
• V-228358 Exchange diagnostic event-log must be configured to the minimum level (EX16-MB-000050)
• Set-EventLogLevel cmdlet

EDCA-MON-013: Windows Advanced Audit Policy is configured

Category: Monitoring | Severity: High | Frameworks: ANSSI, BSI

Remediation

Configure Advanced Audit Policy subcategories using auditpol or Group Policy to ensure Logon, Account Logon, Account Management, Special Logon, and Process Creation events are audited.

# Check current Advanced Audit Policy subcategory settings
auditpol /get /category:"Logon/Logoff","Account Logon","Account Management","Detailed Tracking" 2>&1

# Apply recommended subcategory settings (Success/Failure where appropriate)
# Logon
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
# Account Logon
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable
# Account Management
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
# Special Logon
auditpol /set /subcategory:"Special Logon" /success:enable
# Process Creation
auditpol /set /subcategory:"Process Creation" /success:enable

Considerations

Enabling advanced audit subcategories increases Security event log volume on Exchange servers. Ensure the event log size and retention policy (Security log maximum size and Archive policy) are set appropriately before enabling. In environments using Group Policy for audit settings, ensure the 'Audit: Force audit policy subcategory settings' policy is enabled so that subcategory settings override legacy category settings. High-volume servers may require a SIEM or log forwarding pipeline to handle the increased event rate.

References

• Advanced security audit policy settings
• auditpol command-line tool
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)
• BSI SYS.1.1.A10 — Protokollierung
• BSI APP.2.2.A7 — Umsetzung sicherer Verwaltungsmethoden für Active Directory

EDCA-MON-014: PowerShell Module Logging is enabled

Category: Monitoring | Severity: Medium | Frameworks: ANSSI, BSI, CIS

Remediation

Enable PowerShell Module Logging via registry or Group Policy. Set EnableModuleLogging to 1 under the ModuleLogging key and configure the ModuleNames value to '*' to log all modules.

# Check current Module Logging state
$modLogPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging'
$val = (Get-ItemProperty $modLogPath -Name EnableModuleLogging -ErrorAction SilentlyContinue).EnableModuleLogging
"EnableModuleLogging: $(if ($null -eq $val) { 'not set (disabled)' } else { $val })"

# Enable Module Logging and log all modules
New-Item -Path $modLogPath -Force | Out-Null
Set-ItemProperty -Path $modLogPath -Name EnableModuleLogging -Type DWord -Value 1

$modNamesPath = "$modLogPath\ModuleNames"
New-Item -Path $modNamesPath -Force | Out-Null
Set-ItemProperty -Path $modNamesPath -Name '*' -Type String -Value '*'

Write-Host 'PowerShell Module Logging enabled for all modules.'

Considerations

Enabling PowerShell Module Logging generates verbose log entries in the Windows PowerShell event log (Microsoft-Windows-PowerShell/Operational) for every PowerShell pipeline execution. On Exchange servers running frequent scheduled tasks or automation, this can generate high log volume. Ensure adequate event log size and a log collection or archival policy before enabling. Module Logging and Script Block Logging are complementary; together they provide complete PowerShell visibility. Module Logging captures invocation details while Script Block Logging captures the script content. Both should be enabled for comprehensive coverage.

References

• PowerShell Group Policy settings (Module Logging)
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory (2022)
• BSI SYS.1.2.3.A7 — Verwendung der Windows PowerShell

EDCA-PERF-001: CTS processor affinity baseline

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Remove or reset the CtsProcessorAffinityPercentage DWORD value to 0 under HKLM\SOFTWARE\Microsoft\ExchangeServer\V15\Search\SystemParameters. This setting limits search performance and should not be used as a long-term fix.

Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ExchangeServer\V15\Search\SystemParameters' -Name CtsProcessorAffinityPercentage -ErrorAction SilentlyContinue

Considerations

Changing the CTS processor affinity can reduce throughput on servers with many concurrent connections. This setting is rarely needed and should only be changed based on Microsoft support guidance. Incorrect configuration can degrade search performance.

References

• CSS CTSProcessorAffinityPercentageCheck

EDCA-PERF-002: High Performance power plan is active

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Set active power plan to High Performance.

powercfg /SETACTIVE 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

Considerations

Changing the power plan to High Performance increases power consumption on physical hosts. On virtual machines, the hypervisor controls CPU frequency and this setting has limited effect. Verify that your data center or cloud infrastructure supports and benefits from this configuration.

References

• CSS power plan recommendation
• Exchange deployment and performance guidance

EDCA-PERF-003: Hyper-Threading/SMT not enabled

Category: Performance | Severity: Low | Frameworks: Best Practice

Remediation

Review BIOS/host settings for SMT/Hyper-Threading and disable per performance policy where approved.

# Diagnose: Check Hyper-Threading/SMT state (LogicalProcessors > Cores indicates HT is enabled)
Get-WmiObject -Class Win32_Processor | Select-Object Name, NumberOfCores, NumberOfLogicalProcessors | ForEach-Object { "$($_.Name): $($_.NumberOfCores) cores / $($_.NumberOfLogicalProcessors) logical - HT: $(if ($_.NumberOfLogicalProcessors -gt $_.NumberOfCores) {'ENABLED'} else {'disabled'})" }
# If HT/SMT is enabled, disable it in BIOS firmware. Verify Exchange sizing after the change.

Considerations

Disabling Hyper-Threading/SMT is a mitigation for CPU side-channel vulnerabilities (MDS, TAA, Spectre). The performance reduction can be up to 30%. Only apply this if regulatory requirements or your threat model mandate it. This change requires a reboot and coordination with production scheduling.

References

• CSS processor topology guidance

EDCA-PERF-004: NodeRunner memory limit baseline

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Set memoryLimitMegabytes to 0 in the noderunner.exe configuration file for optimal performance. Only apply a non-zero limit as a temporary workaround if the noderunner process is causing measurable server impact.

# Diagnose: Check NodeRunner.exe.config memory limit setting
$exchPath = $exinstall
$cfg = Join-Path $exchPath 'Bin\Search\Ceres\Runtime\1.0\noderunner.exe.config'
if (Test-Path $cfg) { ([xml](Get-Content $cfg)).configuration.noderunner.memorySettings } else { "Config not found: $cfg" }

Considerations

Adjusting the NodeRunner memory limit affects Exchange content indexing and search performance. Setting the limit too low can cause content index to lag or fail. The change takes effect after a service restart and should be tested against search responsiveness.

References

• CSS NodeRunnerMemoryLimitCheck

EDCA-PERF-005: NUMA BIOS baseline

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Verify BIOS NUMA settings are configured so the OS can detect all processor cores. If only half the logical cores are visible to the OS, consult your server or OS vendor to correct the NUMA BIOS configuration.

# Diagnose: Check NUMA node and processor visibility from the OS
Get-WmiObject -Class Win32_Processor | Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, NumberOfEnabledCore
"OS-visible logical processor count: $([System.Environment]::ProcessorCount)"
# Uneven core distribution across sockets or mismatched totals may indicate a NUMA misconfiguration - verify BIOS settings.

Considerations

BIOS-level NUMA configuration changes require server restart and must be coordinated with the hardware vendor. Incorrect NUMA configuration can degrade memory access performance on multi-socket systems.

References

• CSS NumaBiosCheck

EDCA-PERF-006: Processor socket count and logical core baseline

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Reduce the number of processor sockets to no more than 2, or reduce logical processors to within the supported maximum (24 for Exchange 2016, 48 for Exchange 2019/SE). If the CPU is throttled, verify the Power Plan is set to High Performance and change it immediately if not.

# Diagnose: Check processor socket count, clock speeds, and logical processor counts
Get-WmiObject -Class Win32_Processor | Select-Object Name, MaxClockSpeed, CurrentClockSpeed, NumberOfCores, NumberOfLogicalProcessors
"Total sockets: $((Get-WmiObject -Class Win32_Processor | Measure-Object).Count)"
"Total logical processors: $([System.Environment]::ProcessorCount)"
# If CurrentClockSpeed is significantly below MaxClockSpeed, review BIOS power and performance settings.

Considerations

Processor socket count and logical core limits are a hardware sizing concern addressed at deployment time. On VMware, the socket count maps to vCPU socket configuration rather than physical sockets; reducing vCPU sockets requires a VM power-off. On physical hardware, reducing socket count requires hardware maintenance. Processor replacement or configuration changes require hardware maintenance windows and potential load redistribution across the DAG.

References

• CSS ProcessorCheck

EDCA-PERF-007: Receive Side Scaling (RSS) enabled

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Enable RSS on adapters where supported.

Get-NetAdapterRss | Where-Object { -not $_.Enabled } | ForEach-Object { Enable-NetAdapterRss -Name $_.Name -Confirm:$false }

Considerations

Enabling or reconfiguring RSS settings may require a network adapter driver update and a server reboot. Changes to RSS may briefly interrupt network connectivity. Verify that the network adapter firmware supports the target RSS configuration.

References

• CSS NIC/RSS checks

EDCA-PERF-008: Single page file configuration

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Review and standardize page file settings through approved OS baseline controls.

# Manual remediation recommended: align page file configuration with Exchange server baseline.

Considerations

Exchange has specific page file sizing recommendations based on installed RAM. Changing page file settings requires a reboot. Placing the page file on the Exchange database volume is not recommended. Follow CSS and Microsoft guidance for page file placement and size.

References

• CSS page file warning logic

EDCA-PERF-009: Sleepy NIC baseline

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Disable NIC power-saving by setting the PnPCapabilities DWORD value to 24 or 280 under HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318} for each affected network adapter.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\NNNN' -Name PnPCapabilities -Value 24 -Type DWord

Considerations

Disabling sleep and power-saving settings on network adapters prevents idle disconnects but may marginally increase power consumption. This setting is almost always the correct configuration for production Exchange servers. Requires testing after changing NIC advanced settings.

References

• CSS SleepyNICCheck

EDCA-PERF-010: TCP/IP settings baseline

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Set the KeepAliveTime DWORD value under HKLM\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters to between 900000 and 1800000 milliseconds (15 to 30 minutes) to prevent idle TCP connections from being dropped prematurely.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' -Name KeepAliveTime -Value 900000 -Type DWord

Considerations

TCP/IP stack changes (Chimney Offload, Large Send Offload, etc.) affect all network traffic on the server, not just Exchange. Some settings require a reboot. Verify that the current NIC driver supports the target configuration. Changes should be tested in a staging environment first.

References

• CSS TCPIPSettingsCheck

EDCA-PERF-011: VMXNET3 adapter health baseline (ESX)

Category: Performance | Severity: Low | Frameworks: Best Practice

Remediation

When PacketsReceivedDiscarded is non-zero on a VMXNET3 adapter, increase the receive buffer settings to their maximum values to reduce the risk of buffer exhaustion: set Small Rx Buffers to 8192 and Rx Ring #1 Size to 4096 via the adapter Advanced Properties in Device Manager. If random interface resets are observed alongside packet loss, also disable the 'adaptive rx ring sizing' advanced property. No reboot is required, but existing TCP sessions (including RDP) may be disrupted when the driver reloads the new configuration - use a vSphere console to make changes where possible.

# Diagnose: Show VMXNET3 adapters, packet loss counter, and current ring/buffer settings
$vmxnet = @(Get-NetAdapter | Where-Object { $_.InterfaceDescription -like '*VMXNET3*' })
if ($vmxnet.Count -eq 0) { Write-Host 'No VMXNET3 adapters found.'; return }

foreach ($nic in $vmxnet) {
    Write-Host ('--- Adapter: {0} ({1}) ---' -f $nic.Name, $nic.InterfaceDescription)

    # Packet loss counter (Good=0, Warning<1000, Error>=1000)
    $stats = Get-NetAdapterStatistics -Name $nic.Name -ErrorAction SilentlyContinue
    if ($null -ne $stats) {
        $discards = ($stats.PSObject.Properties | Where-Object { $_.Name -match 'Discard' } | Measure-Object -Property Value -Sum).Sum
        Write-Host ('  PacketsReceivedDiscarded : {0}  (Good=0 / Warning<1000 / Error>=1000)' -f $discards)
    }

    # Current advanced driver properties (ring size and buffer settings)
    $advProps = Get-NetAdapterAdvancedProperty -Name $nic.Name -ErrorAction SilentlyContinue
    $ring1    = $advProps | Where-Object { $_.DisplayName -match 'Rx Ring.*#?\s*1|Ring.*#?\s*1' } | Select-Object -First 1
    $smallRx  = $advProps | Where-Object { $_.DisplayName -match 'Small' } | Select-Object -First 1
    $adaptive = $advProps | Where-Object { $_.DisplayName -match 'adaptive' } | Select-Object -First 1
    Write-Host ('  Rx Ring #1 Size          : {0}  (recommended: 4096)' -f $(if ($ring1)   { $ring1.DisplayValue }   else { 'not found' }))
    Write-Host ('  Small Rx Buffers         : {0}  (recommended: 8192)' -f $(if ($smallRx) { $smallRx.DisplayValue } else { 'not found' }))
    if ($adaptive) { Write-Host ('  Adaptive Rx Ring Sizing  : {0}  (recommended: Disabled)' -f $adaptive.DisplayValue) }
}

# To update: open Device Manager -> Network Adapters -> right-click VMXNET3 adapter
# -> Properties -> Advanced tab -> set Rx Ring #1 Size = 4096, Small Rx Buffers = 8192
# Alternatively, use Set-NetAdapterAdvancedProperty (name may vary by driver version):
# Set-NetAdapterAdvancedProperty -Name 'Ethernet0' -DisplayName 'Rx Ring #1 Size' -DisplayValue '4096'
# Set-NetAdapterAdvancedProperty -Name 'Ethernet0' -DisplayName 'Small Rx Buffers' -DisplayValue '8192'

Considerations

Only applicable in VMware environments with VMXNET3 virtual NICs. The PacketsReceivedDiscarded counter accumulates from the last reboot or NIC driver reset, so a non-zero value may reflect historical activity rather than an active issue. Increasing Small Rx Buffers and Rx Ring #1 Size allocates more memory for the virtual NIC receive path, which increases memory overhead on both the VM and the ESXi host. Increase values gradually when host memory resources are near capacity, and monitor host memory balloon activity after changes. No reboot is required to apply ring/buffer changes, but the driver will momentarily reset the adapter, which will disconnect active TCP sessions - including RDP and Exchange client connections. Perform changes during a maintenance window or via vSphere console to avoid disruption. The Small Rx Buffers and Rx Ring #1 Size settings affect non-jumbo frame traffic only. On hosts running VMware Tools 10.4.0 or later, adaptive rx ring sizing is disabled by default.

References

• Microsoft CSS-Exchange HealthChecker: PacketsLossCheck
• VMware KB 2039495: Large packet loss in the guest OS using VMXNET3 in ESXi
• VMware KB 78343: Disable adaptive rx ring sizing to avoid random interface reset

EDCA-PERF-012: Exchange-to-DC/GC processor core ratio does not exceed 8:1

Category: Performance | Severity: High | Frameworks: Best Practice

Remediation

Add additional Global Catalog servers (or promote existing DCs to GC role) in the Exchange AD site to bring the ratio to 8:1 or better. Alternatively, reduce the number of Exchange processor cores by adjusting the virtual machine configuration or decommissioning servers.

# STEP 1: Discover GC-enabled domain controllers per AD site
$gcsBySite = @{}
Get-ADDomainController -Filter { IsGlobalCatalog -eq $true } | ForEach-Object {
    $siteName = $_.Site
    if (-not $gcsBySite.ContainsKey($siteName)) { $gcsBySite[$siteName] = @() }
    $gcsBySite[$siteName] += $_.HostName
}

# STEP 2: Exchange server core counts per site
$exchangeBySite = @{}
Get-ExchangeServer | Where-Object { $_.ServerRole -notlike '*Edge*' } | ForEach-Object {
    $siteName = (([string]$_.Site -split '/')[-1]).Trim()
    $srvName  = [string]$_.Name
    $cores    = (@(Get-CimInstance -ComputerName $srvName -ClassName Win32_Processor -ErrorAction SilentlyContinue) | Measure-Object -Property NumberOfCores -Sum).Sum
    [PSCustomObject]@{ Server = $srvName; Site = $siteName; Cores = if ($null -ne $cores) { $cores } else { 'N/A' } }
    if (-not $exchangeBySite.ContainsKey($siteName)) { $exchangeBySite[$siteName] = 0 }
    if ($null -ne $cores) { $exchangeBySite[$siteName] += $cores }
} | Format-Table Server, Site, Cores -AutoSize

# STEP 3: GC core counts per site + ratio
foreach ($site in ($exchangeBySite.Keys | Sort-Object)) {
    $exCores = $exchangeBySite[$site]
    $gcNames = if ($gcsBySite.ContainsKey($site)) { $gcsBySite[$site] } else { @() }
    if ($gcNames.Count -eq 0) { Write-Warning ('No GC found in site ' + $site); continue }
    $totalGcCores = 0
    foreach ($dcName in $gcNames) {
        $dcCores = (@(Get-CimInstance -ComputerName $dcName -ClassName Win32_Processor -ErrorAction SilentlyContinue) | Measure-Object -Property NumberOfCores -Sum).Sum
        [PSCustomObject]@{ DC = $dcName; Site = $site; Cores = if ($null -ne $dcCores) { $dcCores } else { 'N/A' } }
        if ($null -ne $dcCores) { $totalGcCores += $dcCores }
    }
    if ($totalGcCores -gt 0) {
        $ratio = [math]::Round($exCores / $totalGcCores, 2)
        $status = if ($ratio -le 8) { 'PASS' } else { 'FAIL' }
        Write-Host ($status + ': Site=' + $site + '  Exchange=' + $exCores + ' cores  GC=' + $totalGcCores + ' cores  Ratio=' + $ratio + ':1 (limit 8:1)')
    }
}

Considerations

When the Exchange-to-DC/GC core ratio exceeds 8:1 in an Active Directory site, Exchange Server cannot service LDAP lookup requests at the required rate. This manifests as increased LDAP query latency, causing slow mailbox logons, delayed Free/Busy lookups, and sluggish recipient resolution in Outlook. Under sustained load, GC servers experience elevated CPU utilization that can cascade into authentication failures and client disconnections. During peak periods, transport components may time out waiting for LDAP responses, resulting in delivery delays or NDRs. In severe cases, Exchange Managed Availability health probes fail, causing the frontend service to be disabled and users to lose access entirely. The impact is site-scoped - sites where the ratio is within limits remain unaffected while non-compliant sites degrade independently.

References

• Exchange Server preferred architecture: directory server design
• Microsoft CSS Exchange HealthChecker: DCCoreRatio
• Exchange Server Performance recommendations: processor

EDCA-PERF-013: Page file initial and maximum size match Exchange version baseline

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Set the page file to a fixed size equal to the Exchange version target. For Exchange 2016: if total RAM is 32 GB or more, set Initial and Maximum to 32778 MB; otherwise set both to RAM in MB + 10. For Exchange 2019 / Exchange SE: set both to 25% of total RAM rounded up to the nearest MB. After changing the page file size a reboot is required for the new values to take effect.

# Inspect current page file configuration
$cs    = Get-CimInstance Win32_ComputerSystem
$pfCfg = Get-CimInstance Win32_PageFileSetting
$ramGB = [math]::Round($cs.TotalPhysicalMemory / 1GB, 2)
$ramMB = [int][math]::Round($ramGB * 1024)
Write-Host ('Total RAM: {0} GB ({1} MB)' -f $ramGB, $ramMB)
$pfCfg | Format-Table Name, InitialSize, MaximumSize -AutoSize

# Determine target based on Exchange version
$adminDisplayVersion = (Get-ExchangeServer -Identity $env:COMPUTERNAME).AdminDisplayVersion
if ($adminDisplayVersion -match 'Version 15\.1') {
    $targetMB = if ($ramMB -ge 32768) { 32778 } else { $ramMB + 10 }
} else {
    # Exchange 2019 / Exchange SE: 25% of RAM
    $targetMB = [int][math]::Ceiling($ramMB * 0.25)
}
Write-Host ('Target page file size: {0} MB' -f $targetMB)

# Disable automatic page file management if currently enabled
if ($cs.AutomaticManagedPagefile) {
    Set-CimInstance -InputObject $cs -Property @{ AutomaticManagedPagefile = $false }
    Write-Host 'Automatic page file management disabled.'
}

# Apply fixed size (uncomment to execute -- requires reboot)
# $pfCfg | Set-CimInstance -Property @{ InitialSize = $targetMB; MaximumSize = $targetMB }
# Write-Host ('Page file set to {0} MB fixed. Reboot required.' -f $targetMB)
# Restart-Computer -Force

Considerations

Applying this change requires a reboot; schedule during a maintenance window. If Windows Automatic Managed Page File is enabled, disable it before setting explicit values - the InitialSize and MaximumSize values in Win32_PageFileSetting are disregarded while automatic management is active. The 32778 MB cap for Exchange 2016 applies regardless of how much additional RAM is installed beyond 32 GB. For Exchange 2019 and Exchange SE the 25% rule scales with RAM; verify the system drive has sufficient free space before applying, particularly on high-memory servers. On virtual machines, an oversized page file consumes datastore capacity without a performance benefit; review available storage alongside any planned RAM changes.

References

• Microsoft CSS Exchange HealthChecker: PagefileSizeCheck
• Exchange Server performance recommendations: page file
• Exchange Server preferred architecture

EDCA-PERF-014: Memory meets Exchange version and role requirements

Category: Performance | Severity: High | Frameworks: Best Practice

Remediation

Add physical or virtual memory until the server meets the minimum for its Exchange version and role. For virtual machines, ensure the hypervisor memory reservation equals the full vRAM allocation and that dynamic memory / memory ballooning is disabled. Use the Exchange Server role requirements calculator (https://aka.ms/Exchange2019Calc) to size Mailbox servers based on actual mailbox count, message profile, and availability requirements before provisioning.

# Report current installed memory and evaluate against Exchange requirements
$cs     = Get-CimInstance Win32_ComputerSystem
$ramGB  = [math]::Round($cs.TotalPhysicalMemory / 1GB, 2)
Write-Host ('Installed RAM: {0} GB' -f $ramGB)

$exSrv  = Get-ExchangeServer -Identity $env:COMPUTERNAME -ErrorAction SilentlyContinue
$ver    = if ($null -ne $exSrv) { [string]$exSrv.AdminDisplayVersion } else { 'Unknown' }
$isEdge = ($null -ne $exSrv) -and ([string]$exSrv.ServerRole -like '*Edge*')
Write-Host ('Version: {0}' -f $ver)
Write-Host ('Role   : {0}' -f (if ($isEdge) { 'Edge Transport' } else { 'Mailbox' }))

# Requirements table
$minGB = 0; $maxGB = $null
if ($ver -match 'Version 15\.1') {
    $minGB = if ($isEdge) { 4 } else { 8 }
    $maxGB = if ($isEdge) { $null } else { 192 }
} elseif ($ver -match 'Version 15\.2') {
    $minGB = if ($isEdge) { 8 } else { 32 }
    $maxGB = if ($isEdge) { $null } else { 256 }
}

if ($ramGB -lt $minGB) { Write-Warning ('RAM {0} GB is below the {1} GB minimum.' -f $ramGB, $minGB) }
elseif ($null -ne $maxGB -and $ramGB -gt $maxGB) { Write-Warning ('RAM {0} GB exceeds the {1} GB maximum.' -f $ramGB, $maxGB) }
else { Write-Host 'RAM is within the supported range.' }

Considerations

Adding physical memory to a server requires downtime; plan capacity changes in advance using the Exchange Server role requirements calculator (https://aka.ms/Exchange2019Calc). On virtual machines, increasing vRAM typically requires powering off the VM; enabling a 100% hypervisor memory reservation may prevent the hypervisor from overcommitting memory to other guests - coordinate with the platform team before making changes. Disabling dynamic memory features (Hyper-V Dynamic Memory or VMware memory ballooning) may require a reboot to take full effect. Note that memory overcommit at the hypervisor layer can cause the guest OS to report a higher RAM total than is actually guaranteed, resulting in a falsely compliant assessment; verify hypervisor-level reservations alongside any reported values. The maximum RAM limits for Mailbox servers (192 GB for Exchange 2016, 256 GB for Exchange 2019/SE) represent the upper boundary of Microsoft’s tested configurations; address larger mailbox populations by adding servers rather than exceeding the documented ceiling.

References

• Exchange Server 2019 and Exchange SE system requirements
• Exchange Server virtualization: memory requirements and recommendations
• Exchange Server role requirements calculator

EDCA-PERF-015: Processor cores meet Exchange version and role requirements

Category: Performance | Severity: High | Frameworks: Best Practice

Remediation

Reduce the number of physical cores (or assigned vCPUs on virtual machines) to the supported maximum for the Exchange version. For virtual machines, also ensure the vCPU count does not exceed twice the number of physical processor cores available on the host. Use the Exchange Server role requirements calculator (https://aka.ms/Exchange2019Calc) to determine the optimal core count based on mailbox count and message profile before resizing.

# Report current processor topology and evaluate against Exchange requirements
$cs      = Get-CimInstance Win32_ComputerSystem
$cores   = (@(Get-CimInstance Win32_Processor) | Measure-Object -Property NumberOfCores -Sum).Sum
$logical = [int]$cs.NumberOfLogicalProcessors
Write-Host ('Physical cores  : {0}' -f $cores)
Write-Host ('Logical procs   : {0}' -f $logical)
Write-Host ('vCPU:pCore ratio: {0}:1' -f [math]::Round($logical / $cores, 2))

$exSrv  = Get-ExchangeServer -Identity $env:COMPUTERNAME -ErrorAction SilentlyContinue
$ver    = if ($null -ne $exSrv) { [string]$exSrv.AdminDisplayVersion } else { 'Unknown' }
Write-Host ('Exchange version: {0}' -f $ver)

$maxCores = $null
if ($ver -match 'Version 15\.1') { $maxCores = 24 }
elseif ($ver -match 'Version 15\.2') { $maxCores = 48 }

if ($null -ne $maxCores -and $cores -gt $maxCores) {
    Write-Warning ('Physical core count ({0}) exceeds the {1}-core maximum.' -f $cores, $maxCores)
} else { Write-Host 'Core count is within the supported range.' }

$ratio = [math]::Round($logical / $cores, 2)
if ($ratio -gt 2) {
    Write-Warning ('vCPU:pCore ratio {0}:1 exceeds the supported 2:1 maximum.' -f $ratio)
} elseif ($ratio -gt 1) {
    Write-Warning ('vCPU:pCore ratio {0}:1 is above the recommended 1:1 ratio.' -f $ratio)
} else { Write-Host 'vCPU:pCore ratio is compliant.' }

Considerations

• Assigning more cores than the supported maximum does not improve Exchange throughput; the worker process thread pool is tuned for the documented core counts and excess cores introduce additional scheduling latency.
• On virtual machines, a vCPU:pCore ratio above 2:1 causes CPU ready time in the hypervisor scheduler, manifesting as unpredictable latency spikes in Exchange processing. Even the 2:1 ratio is an upper bound; a 1:1 ratio is recommended for production Mailbox workloads.
• Reducing the vCPU count on a virtual machine requires a reboot before Exchange processes observe the new topology; schedule during a maintenance window.
• Use the Exchange Server role requirements calculator (https://aka.ms/Exchange2019Calc) to determine the optimal core count before making changes.

References

• Exchange Server 2019 and Exchange SE system requirements
• Exchange Server virtualization: requirements for hardware virtualization
• Exchange Server role requirements calculator

EDCA-PERF-016: TcpAckFrequency is at its default value on all IP-enabled network adapters

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Remove the TcpAckFrequency registry value from each IP-enabled network adapter to restore the Windows delayed ACK default. Removing the value is preferred over setting it to 2 — an absent key and the value 2 are equivalent, and removing it avoids a stale override. No reboot is required; the change takes effect for new TCP connections immediately.

# Restore default delayed ACK behaviour by removing TcpAckFrequency override
$nicConfigs = @(Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled })
foreach ($nic in $nicConfigs) {
    $guid    = [string]$nic.SettingID
    $regPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\' + $guid
    if (Test-Path -Path $regPath) {
        $val = (Get-ItemProperty -Path $regPath -Name TcpAckFrequency -ErrorAction SilentlyContinue).TcpAckFrequency
        if ($null -ne $val -and [int]$val -ne 2) {
            Remove-ItemProperty -Path $regPath -Name TcpAckFrequency -Force
            Write-Host ('Removed TcpAckFrequency={2} from adapter: {0} ({1})' -f $nic.Description, $guid, $val)
        } else {
            $display = if ($null -eq $val) { 'not set (default)' } else { [string]$val }
            Write-Host ('TcpAckFrequency={2} on adapter: {0} ({1}); no action needed.' -f $nic.Description, $guid, $display)
        }
    } else {
        Write-Warning ('Registry path not found for adapter: {0} ({1})' -f $nic.Description, $guid)
    }
}
Write-Host 'Done. No reboot required; existing connections resume correct behaviour after reconnection.'

Considerations

Setting TcpAckFrequency = 1 turns off delayed ACKs, so the system sends an ACK for every single TCP segment. That creates a lot of tiny packets, drives up NIC interrupts, and increases CPU load on both Exchange and the clients. And because it applies to the whole adapter, the extra noise affects all TCP traffic, not just MAPI.

It also doesn't solve Outlook latency issues. The well-known 200 ms delay—especially in certain VMware environments—comes from the NSX vnetflt introspection driver pausing packets, not from delayed ACK. Changing TcpAckFrequency just adds overhead without fixing the real problem. The proper fix is documented in EDCA-PERF-017.

Going the other direction isn't better. Values 3 or higher hold ACKs even longer than the default 200 ms, which slows down interactive protocols like MAPI and makes Outlook feel less responsive.

And there's no point setting it to 2. According to Microsoft, "missing key," "0," and "2" all behave the same. The cleanest option is simply to remove the key entirely.

Microsoft does not recommend configuring this unless you've studied the environment very carefully.

References

• Microsoft KB 328890: Registry entry for controlling TCP Acknowledgment behavior

EDCA-PERF-017: VMware NSX Introspection drivers are not running

Category: Performance | Severity: Medium | Frameworks: Best Practice

Remediation

Stop and disable the vsepflt and/or vnetflt services on the Exchange server. Verify with the security team that no endpoint security product (such as VMware Carbon Black or a third-party NGAV integrated with NSX) relies on these drivers before disabling them. A reboot is not required to stop the services, but disabling them prevents them from starting on the next boot.

# Stop and disable VMware NSX Introspection drivers
foreach ($svcName in @('vsepflt', 'vnetflt')) {
    $svc = Get-Service -Name $svcName -ErrorAction SilentlyContinue
    if ($null -eq $svc) {
        Write-Host "Service '$svcName' not found; skipping."
        continue
    }
    if ($svc.Status -eq 'Running') {
        Stop-Service -Name $svcName -Force -ErrorAction SilentlyContinue
        Write-Host "Stopped service: $svcName"
    } else {
        Write-Host "Service '$svcName' is already stopped (Status: $($svc.Status))."
    }
    Set-Service -Name $svcName -StartupType Disabled -ErrorAction SilentlyContinue
    Write-Host "Disabled service: $svcName"
}
Write-Host 'Done. Reboot is not required to take effect.'

Considerations

• Before disabling the introspection drivers, confirm with the security team that no endpoint protection product installed on the server requires NSX Guest Introspection. Disabling the drivers while a third-party security product depends on them may leave the server unprotected without raising an obvious alert.
• The vsepflt and vnetflt drivers are installed automatically when VMware Tools is installed with the NSX components option. Upgrading VMware Tools may re-enable disabled services; verify the drivers remain disabled after any VMware Tools update.
• If the introspection capability is required for security compliance, consider whether the Exchange server should be moved to a host or cluster segment where the NSX policy does not apply, rather than disabling drivers on a per-VM basis.
• The performance impact of vnetflt is most visible under high connection rates (large numbers of Outlook Online mode clients or active MAPI connections). Environments with a predominantly cached-mode Outlook client population or smaller mailbox counts may observe less pronounced latency improvement after disabling the driver.

References

• VMware Guest Introspection and Exchange latency
• VMware KB: Disable Guest Introspection drivers

EDCA-SEC-001: MAPI over HTTP is enabled

Category: Platform Security | Severity: Medium | Frameworks: Best Practice, CISA

Remediation

Enable and validate MAPI over HTTP configuration for applicable virtual directories and clients.

# Diagnose: Check MAPI over HTTP status
Get-OrganizationConfig | Select-Object MapiHttpEnabled
Get-MapiVirtualDirectory -Server $env:COMPUTERNAME | Select-Object Server, Name, InternalUrl, ExternalUrl, IISAuthenticationMethods

Considerations

If MAPI over HTTP is enabled for the first time in an existing environment, connected Outlook clients may require a profile restart or re-creation. Test with a pilot group before rolling out to all users. Ensure no client access rules are blocking MAPI over HTTP before enabling.

References

• MAPI over HTTP in Exchange Server
• CIS 2.1.1 (L1): Ensure MAPI over HTTP is Enabled

EDCA-SEC-002: .NET Framework version compatible with Exchange

Category: Platform Security | Severity: High | Frameworks: Best Practice

Remediation

Update .NET Framework to at least version 4.8 following Exchange-specific guidance to sequence the upgrade correctly relative to Exchange CU installation.

# Diagnose: Check installed .NET Framework release key (528040+ required for 4.8)
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' | Select-Object Release, Version

Considerations

Upgrading Exchange Server to a newer Cumulative Update (CU) requires scheduled downtime and thorough regression testing, particularly for hybrid configurations and third-party integrations. Follow the upgrade readiness checklist and verify all coexistence prerequisites before proceeding.

References

• Exchange Server supportability matrix

EDCA-SEC-003: AD Domain functional level compatible with Exchange

Category: Platform Security | Severity: High | Frameworks: Best Practice

Remediation

Raise the AD Domain functional level to the minimum required for the installed Exchange version. All domain controllers in the domain must be running the corresponding Windows Server version before raising the domain functional level.

# Check current domain functional level and raise if required:
# Set-ADDomainMode -Identity <DomainFQDN> -DomainMode Windows2012R2Domain

Considerations

Raising the AD domain functional level is irreversible without a full forest recovery. Ensure all domain controllers in the domain are running the required Windows Server version before raising the functional level. Test in a non-production environment first. Coordinate with the Active Directory team, as the change affects all services in the domain — not only Exchange.

References

• Exchange Server system requirements

EDCA-SEC-004: AD Forest functional level compatible with Exchange

Category: Platform Security | Severity: High | Frameworks: Best Practice

Remediation

Raise the AD Forest functional level to the minimum required for the installed Exchange version. All domain controllers in the forest must be running the corresponding Windows Server version before raising the forest functional level.

# Check current forest functional level and raise if required:
# Set-ADForestMode -Identity <ForestFQDN> -ForestMode Windows2012R2Forest

Considerations

Raising the AD forest functional level requires all domain controllers in all domains in the forest to be running the required Windows Server version. The change is irreversible without a full forest recovery. Coordinate with all domain administrators in the forest before proceeding, as the impact spans every domain and every service relying on AD in the entire forest.

References

• Exchange Server system requirements

EDCA-SEC-005: AD site count baseline

Category: Platform Security | Severity: Low | Frameworks: Best Practice

Remediation

Reduce the number of AD sites. As a workaround, increase the topology cache lifetime to 24 hours by changing ExchangeTopologyCacheLifetime to 1.00:00:00,00:20:00 in %ExchangeInstallPath%\Bin\Microsoft.Exchange.Directory.TopologyService.exe.config.

# Diagnose: List all AD sites visible in the current forest
$forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
"Total AD sites: $(($forest.Sites | Measure-Object).Count)"
$forest.Sites | Select-Object Name | Sort-Object Name

Considerations

Reducing the number of AD sites requires Active Directory topology changes that must be coordinated with the Active Directory team. Unnecessary sites may remain without functional impact but add administrative overhead.

References

• CSS ADSiteCount

EDCA-SEC-006: Setting overrides baseline

Category: Platform Security | Severity: Medium | Frameworks: Best Practice

Remediation

Remove problematic Setting Overrides using Remove-SettingOverride. Review existing overrides with Get-SettingOverride and remove those flagged by the check. Only modify overrides as directed by Microsoft documentation or CSS support - incorrect usage can cause serious Exchange damage.

Get-SettingOverride | Format-List Name, ComponentName, SectionName, Status

Considerations

Setting overrides are typically applied by Microsoft support to mitigate specific issues. Removing an override can re-expose the condition that originally required it. Review the purpose of each override with Microsoft before removing it.

The following overrides are expected and should not be treated as an issue:

• EnableSigningVerification: automatically set by Exchange when serialized data signing (EX-BP-054) is enabled.
• EnableExchangeHybrid3PAppFeature and FlightingServiceOverride_<ServerName>_F1.1[.x] (one per server): expected when the dedicated Exchange hybrid application is configured.
• EnableAMSIBodyScan* (e.g., EnableAMSIBodyScanAllProtocols, EnableAMSIBodyScanForEcp, EnableAMSIBodyScanForEws, EnableAMSIBodyScanForOwa, EnableAMSIBodyScanForEcpEwsOwaPS): expected when AMSI body scanning is enabled per-protocol or globally.
• EnableEncryptionAlgorithmCBC: enables AES256-CBC encryption mode for IRM-protected messages (EX-BP-153).

References

• CSS SettingOverridesCheck
• Deploy dedicated Exchange hybrid app
• Exchange Server AMSI integration

EDCA-SEC-007: Visual C++ redistributable version baseline

Category: Platform Security | Severity: Medium | Frameworks: Best Practice

Remediation

Install the latest Visual C++ Redistributable version required for the installed Exchange server role from the Microsoft Visual C++ Redistributable Latest Supported Downloads page.

# Diagnose: List installed Visual C++ Redistributable versions
@('HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*','HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*') | ForEach-Object { Get-ItemProperty $_ -ErrorAction SilentlyContinue } | Where-Object { $_.DisplayName -like '*Visual C++*' } | Select-Object DisplayName, DisplayVersion | Sort-Object DisplayName

Considerations

Updating Visual C++ redistributables typically does not require downtime but may require a server reboot. Only install versions validated by the Exchange Cumulative Update prerequisites documentation for the installed Exchange build.

References

• CSS VisualCRedistributableVersionCheck

EDCA-SEC-008: Exchange database/log volume block size is 64KB

Category: Platform Security | Severity: Medium | Frameworks: Best Practice

Remediation

Use 64KB allocation unit size on volumes that host Exchange database/log paths.

# Diagnose: Identify volumes hosting Exchange databases and logs for block size verification
Get-MailboxDatabase -Server $env:COMPUTERNAME | Select-Object Name, EdbFilePath, LogFolderPath
# For each volume run: fsutil fsinfo ntfsinfo <DriveLetter>:
# 'Bytes Per Cluster' should be 65536 (64 KB). Smaller values require reformatting and database migration.

Considerations

Changing the block size of existing volumes requires reformatting - all data must be migrated to temporary storage, volumes reformatted, and data restored. This requires a planned maintenance window with database failovers. New volumes should be formatted with 64 KB blocks before use.

References

• Exchange storage best practices
• Exchange CSS storage checks

EDCA-SEC-009: Exchange database/log volumes use NTFS or ReFS

Category: Platform Security | Severity: Medium | Frameworks: Best Practice

Remediation

Move Exchange database/log files to NTFS or ReFS-formatted volumes.

# Diagnose: Check filesystem type on Exchange-related volumes
Get-WmiObject -Class Win32_Volume | Where-Object { $_.DriveType -eq 3 -and $_.FileSystem -ne 'NTFS' -and $_.FileSystem -ne 'ReFS' } | Select-Object Name, FileSystem
Get-MailboxDatabase -Server $env:COMPUTERNAME | Select-Object Name, EdbFilePath, LogFolderPath

Considerations

Converting an existing FAT32 volume to NTFS or ReFS requires data migration and reformatting if in-place conversion is not supported. ReFS offers resilience advantages but some Exchange administrators prefer NTFS for its wider tool compatibility. Verify ReFS is supported for the Exchange version before using it for database volumes.

References

• Exchange storage best practices
• Exchange CSS storage guidance

EDCA-SEC-010: OS volume filesystem is NTFS

Category: Platform Security | Severity: Low | Frameworks: Best Practice

Remediation

Use NTFS for the OS volume on Exchange servers.

# Diagnose: Check filesystem type of the boot/OS volume
Get-WmiObject -Class Win32_Volume -Filter 'BootVolume = True' | Select-Object Name, FileSystem, BlockSize
# Exchange is supported only on NTFS OS volumes. ReFS is not supported for the OS drive.

Considerations

The OS volume filesystem cannot be changed on a live server without reinstalling the operating system. This control is an environmental prerequisite when provisioning new Exchange servers.

References

• Exchange Server prerequisites and platform guidance

EDCA-SEC-011: RPC minimum connection timeout baseline

Category: Platform Security | Severity: Medium | Frameworks: Best Practice

Remediation

Adjust the RPC MinConnectionTimeout registry setting to a more aggressive value than the OS defaults if network devices are dropping idle connections before the Exchange timeout triggers.

# Diagnose: Check RPC MinimumConnectionTimeout registry value
$val = (Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\RPC' -Name MinimumConnectionTimeout -ErrorAction SilentlyContinue).MinimumConnectionTimeout
"MinimumConnectionTimeout: $(if ($null -eq $val) { 'not set (OS default)' } else { "$val seconds" })"
# Exchange recommended: 120 seconds. Set: New-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\RPC' -Name MinimumConnectionTimeout -Value 120 -PropertyType DWord -Force

Considerations

Adjusting the RPC minimum connection timeout can affect Outlook MAPI connectivity behavior. Changes should be tested against Outlook profile connect/reconnect timing before applying to all servers.

References

• CSS RPCMinConnectionTimeoutCheck

EDCA-SEC-012: AMSI integration baseline

Category: Platform Security | Severity: High | Frameworks: Best Practice, CISA

Remediation

Ensure AMSI integration is enabled and no Setting Overrides exist that disable it. If Body Scanning is enabled, verify it is supported on the installed Exchange build version.

Get-SettingOverride | Where-Object { $_.SectionName -like '*AMSI*' } | Format-List

Considerations

Some third-party antivirus products that replace the Windows Defender AMSI provider may not register an AMSI provider even when active. Verify AMSI integration compatibility with your antivirus vendor before enforcing this control. Incorrectly disabling AMSI can leave Exchange endpoints exposed to script-based attacks.

References

• CSS AMSIIntegration
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - enable AMSI integration to detect and block malicious scripts

EDCA-SEC-013: Credential Guard disabled on Exchange servers

Category: Platform Security | Severity: High | Frameworks: Best Practice, ANSSI, BSI

Remediation

Disable Credential Guard via Windows Defender Credential Guard Group Policy or by setting LsaCfgFlags to 0 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa and EnableVirtualizationBasedSecurity to 0 under HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard. A reboot is required.

# Diagnose: Check whether Credential Guard / VBS is currently enabled
$lsa = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LsaCfgFlags -ErrorAction SilentlyContinue
$dg  = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard' -Name EnableVirtualizationBasedSecurity -ErrorAction SilentlyContinue
"LsaCfgFlags: $(if ($null -ne $lsa) { $lsa.LsaCfgFlags } else { 'not set' }) (0=disabled, 1=enabled with UEFI lock, 2=enabled without lock)"
"EnableVirtualizationBasedSecurity: $(if ($null -ne $dg) { $dg.EnableVirtualizationBasedSecurity } else { 'not set' }) (0=disabled, 1=enabled)"

# Fix: disable Credential Guard. A reboot is required after making these changes.
# Option 1: via registry (requires reboot)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LsaCfgFlags -Type DWord -Value 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard' -Name EnableVirtualizationBasedSecurity -Type DWord -Value 0
Write-Host 'Credential Guard registry settings cleared. Reboot required to complete deactivation.'

# Option 2: via Group Policy (preferred for domain members)
# Computer Configuration > Administrative Templates > System > Device Guard
#   Turn On Virtualization Based Security = Disabled

Considerations

Credential Guard is not supported on Exchange servers because it can interfere with Exchange service authentication. This control documents the required state (disabled). Do not enable Credential Guard on Exchange hosts without explicit Microsoft support guidance.

ANSSI and BSI both recommend Credential Guard on member servers handling privileged credentials (ANSSI AD admin guide 2023; BSI SYS.1.2.3.A8). Exchange servers are an explicit exception to this recommendation due to Microsoft's unsupported-configuration statement. Document this exception in your organization's risk register and reference this control as the formal exception basis.

References

• CSS Credential Guard check
• Manage Windows Defender Credential Guard
• ANSSI - Recommandations pour l'administration sécurisée des SI reposant sur AD (2023)
• BSI SYS.1.2.3.A8 — Nutzung des Virtual Secure Mode (VSM)

EDCA-SEC-014: Extended Protection enabled on Exchange virtual directories

Category: Platform Security | Severity: High | Frameworks: Best Practice, NIS2, BSI, CIS, CISA

Remediation

Use the ExchangeExtendedProtectionManagement.ps1 script from the CSS-Exchange toolkit (https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/) from an elevated Exchange Management Shell (EMS) with Organization Management permissions. Before enabling, disable SSL Offloading for Outlook Anywhere if applicable (Exchange 2019 CU14+ does this automatically). Use -ShowExtendedProtection to view current configuration, -PrerequisitesCheckOnly to validate prerequisites, or run without arguments to enable on all servers.

# Download latest script:
# Invoke-WebRequest -Uri 'https://github.com/microsoft/CSS-Exchange/releases/latest/download/ExchangeExtendedProtectionManagement.ps1' -OutFile '.\ExchangeExtendedProtectionManagement.ps1'

# View current Extended Protection configuration:
.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection

# Check prerequisites without making changes:
.\ExchangeExtendedProtectionManagement.ps1 -PrerequisitesCheckOnly

# Enable Extended Protection on all Exchange servers (recommended):
.\ExchangeExtendedProtectionManagement.ps1

# Enable on specific servers only:
.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames Server1, Server2

# Modern Hybrid (skip EWS Front End on Hybrid Agent servers):
.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames HybridServer1 -ExcludeVirtualDirectories EWSFrontEnd

# Before enabling, disable SSL Offloading for Outlook Anywhere if applicable:
Set-OutlookAnywhere -Identity 'Server\Rpc (Default Web Site)' -SSLOffloading $false -InternalClientAuthenticationMethod NTLM -ExternalClientAuthenticationMethod NTLM

Considerations

• Enabling Extended Protection can break Outlook connectivity in some older hybrid configurations and may require configuration changes to specific virtual directories (e.g., EWS, AutoDiscover). Microsoft recommends thorough testing in a non-production environment first. Some older Outlook clients and third-party EWS integrations may not be compatible with Extended Protection.
• SSL Offloading is incompatible with Extended Protection: if a load balancer terminates TLS and forwards plain HTTP to Exchange (SSL Offloading), the Channel Binding Token check will fail and all client connections will be blocked after Extended Protection is enabled. SSL Offloading must be disabled before enabling Extended Protection. SSL Bridging (re-encrypt at the load balancer using the same certificate as Exchange) is supported. Exchange 2019 CU14 and later automatically disables SSL Offloading for Outlook Anywhere during setup.
• Extended Protection is incompatible with NTLMv1: Channel Binding Tokens (CBT) used by Extended Protection are not supported by NTLMv1. Any client or Exchange server configured to use NTLMv1 will receive repeated password prompts with no way to authenticate successfully once Extended Protection is enabled. Before enabling Extended Protection, ensure NTLMv1 is disabled on all clients and Exchange servers by setting the LmCompatibilityLevel registry value (HKLM\System\CurrentControlSet\Control\Lsa) to at least 3 (Send NTLMv2 response only); the recommended value is 5 (Send NTLMv2 response only. Refuse LM & NTLM). This can be managed centrally via Group Policy (Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level). See EDCA-SEC-047 for the related NTLMv1 disabled control.

References

• Microsoft Exchange Extended Protection guidance
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(i)(j): access control and multi-factor authentication - Section 11.5-11.7, 11.3, 10, 2.2
• CIS Microsoft Exchange Server Benchmark
• CIS Microsoft Exchange Server 2019 Benchmark v1.0.0: Ensure Extended Protection is Enabled on Exchange virtual directories
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - enable Extended Protection for Authentication on all Exchange virtual directories
• BSI APP.5.2.A9 — Sichere Konfiguration von Exchange-Servern
• BSI APP.5.2.A12 — Einsatz von Outlook Anywhere, MAPI over HTTP und Outlook im Web

EDCA-SEC-015: FIP-FS baseline

Category: Platform Security | Severity: Medium | Frameworks: Best Practice, DISA

Remediation

Run Reset-ScanEngineVersion.ps1 from the CSS-Exchange toolkit to remove the problematic FIP-FS scan engine version folder (2201010000 or higher). On fixed Exchange builds, delete the folder manually or restart the Transport service.

# Diagnose: Check FIP-FS scan engine version (versions >= 2201010000 caused the Y2K22 bug on unpatched Exchange)
$exchPath = $exinstall
Get-ChildItem (Join-Path $exchPath 'FIP-FS\Data\Engines\amd64\Microsoft') -Directory -ErrorAction SilentlyContinue | Select-Object Name, LastWriteTime | Sort-Object Name
Get-Service MSExchangeTransport | Select-Object Name, Status

Considerations

FIP-FS (File Inspection for Filtering) is used by the Exchange transport pipeline for content filtering. FIP-FS failures typically indicate scan engine issues. Repair or reinstallation of the scan engine may temporarily disable content filtering. Review impact on transport rules and malware filtering before proceeding.

References

• CSS FIPFSCheck
• V-259694 Exchange antimalware agent must be enabled and configured (EX19-MB-000146)
• V-259695 The Exchange malware scanning agent must be configured for automatic updates (EX19-MB-000147)

EDCA-SEC-016: IIS web.config baseline

Category: Platform Security | Severity: Medium | Frameworks: Best Practice

Remediation

Replace all %ExchangeInstallDir% placeholder tokens in Exchange web.config and SharedWebConfig.config files with the actual Exchange installation path.

# Diagnose: Scan for unresolved %ExchangeInstallDir% placeholder tokens in Exchange web.config files
$exchPath = $exinstall
Get-ChildItem $exchPath -Filter 'web.config' -Recurse -ErrorAction SilentlyContinue | Select-String '%ExchangeInstallDir%' | Select-Object Path, LineNumber, Line | Format-Table -AutoSize

Considerations

Modifying IIS web.config files for Exchange virtual directories can break authentication, HTTPS bindings, or client connectivity. Only apply changes that are explicitly documented in Exchange configuration guidance. Back up web.config files before making any manual changes.

References

• CSS IISWebConfigCheck

EDCA-SEC-017: IPv6 enabled baseline

Category: Platform Security | Severity: Medium | Frameworks: Best Practice

Remediation

If disabling IPv6, disable it consistently both on the NIC adapters and in the registry under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters (DisabledComponents). Partial disabling causes more problems than leaving IPv6 enabled.

# Diagnose: Check IPv6 DisabledComponents registry value and adapter binding state
$val = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters' -Name DisabledComponents -ErrorAction SilentlyContinue).DisabledComponents
"DisabledComponents: $(if ($null -eq $val) { 'not set (IPv6 fully enabled - default)' } else { '0x{0:X2} ({0})' -f $val })"
Get-NetAdapterBinding -ComponentID 'ms_tcpip6' | Select-Object Name, Enabled

Considerations

Completely disabling IPv6 at the OS level is not recommended by Microsoft and can cause issues with Windows Server networking stack and Active Directory on Server 2019 and later. Use the Exchange CSS guidance - which configures specific IPv6 bindings - rather than disabling IPv6 entirely. Exchange Server itself does not require IPv6 but the Windows stack does.

References

• CSS IPv6EnabledCheck

EDCA-SEC-018: LLMNR disabled by policy

Category: Platform Security | Severity: Medium | Frameworks: Best Practice, CIS, ANSSI, BSI

Remediation

Disable LLMNR using DNS client policy registry key.

# Group Policy equivalent:
# Computer Configuration > Administrative Templates > Network > DNS Client
#   Turn off Multicast Name Resolution = Enabled
#
New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -Force | Out-Null; Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast -Type DWord -Value 0

Considerations

Disabling LLMNR requires a Group Policy change. This affects all Windows name resolution on the network segment, not just Exchange. LLMNR is commonly exploited in NTLM relay attack scenarios (e.g., Responder). Disabling LLMNR is low-risk for environments with properly configured DNS.

References

• CIS Microsoft Windows Server Benchmark
• CIS 18.5.4.2 (L1): Ensure 'Turn off multicast name resolution' (LLMNR) is set to 'Enabled'
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI APP.2.2.A3 — Planung der Gruppenrichtlinien unter Windows

EDCA-SEC-019: Microsoft Defender antivirus exclusions configured for Exchange

Category: Platform Security | Severity: High | Frameworks: Best Practice, CISA, DISA, BSI

Remediation

Use the CSS-Exchange Set-ExchAVExclusions.ps1 script to automatically configure all required Microsoft Defender exclusions for the installed Exchange version. Run from an elevated Exchange Management Shell on each Exchange server: .\Set-ExchAVExclusions.ps1 The script auto-detects the Exchange install path and version and sets all recommended folder and process exclusions. To list all expected exclusions without applying them, use the -ListRecommendedExclusions switch: .\Set-ExchAVExclusions.ps1 -ListRecommendedExclusions To test whether exclusions are correctly applied, use the separate Test-ExchAVExclusions.ps1 script (https://microsoft.github.io/CSS-Exchange/Diagnostics/Test-ExchAVExclusions/). The script is available from https://aka.ms/ExchAVExclusions. Alternatively, add exclusions manually using Set-MpPreference or Add-MpPreference - verify paths match the Exchange install path for the installed version.

# Download and run Set-ExchAVExclusions.ps1 (requires elevated Exchange Management Shell)
# https://aka.ms/ExchAVExclusions

# List all expected exclusions without applying them:
# .\Set-ExchAVExclusions.ps1 -ListRecommendedExclusions

# Test whether exclusions are properly applied (separate script):
# .\Test-ExchAVExclusions.ps1  # https://microsoft.github.io/CSS-Exchange/Diagnostics/Test-ExchAVExclusions/

# Apply all recommended exclusions:
# .\Set-ExchAVExclusions.ps1

# Review currently configured exclusions:
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpPreference | Select-Object -ExpandProperty ExclusionProcess

Considerations

Microsoft Defender antivirus exclusions for Exchange must be kept current as Exchange paths evolve across Cumulative Updates. EDCA checks the specific folder paths listed in the Microsoft documentation; a parent-folder exclusion (e.g. excluding the entire \TransportRoles tree) is treated as covering all required subdirectories. The CSS-Exchange Set-ExchAVExclusions.ps1 script resolves individual database and log paths dynamically, so running that script on a server with default database locations will satisfy the \Mailbox check. Exclusions should be validated against the current Microsoft-recommended list for the installed Exchange version.

References

• Running Windows antivirus software on Exchange servers
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - configure Microsoft Defender antivirus with correct Exchange-specific exclusions
• DISA STIG EX19-MB-000134 (HIGH): Exchange servers must have an approved DOD email-aware virus protection software installed (V-259686)
• CSS-Exchange Set-ExchAVExclusions script
• BSI SYS.1.1.A9 — Einsatz von Virenschutz-Programmen auf Servern
• BSI APP.5.2.A9 — Sichere Konfiguration von Exchange-Servern

EDCA-SEC-020: OWA Download Domains configured

Category: Platform Security | Severity: Medium | Frameworks: Best Practice, CISA

Remediation

Configure OWA download domains according to Exchange security best practices. If Hybrid Modern Authentication is active, also apply the OWA HMA Download Domain Support setting override.

# Diagnose: Check OWA virtual directory DownloadDomains configuration
Get-OwaVirtualDirectory -Server $env:COMPUTERNAME | Select-Object Server, Name, DownloadDomains, ExternalUrl, InternalUrl | Format-List

# Diagnose: Check if the OWA HMA Download Domain Support override is configured
Get-SettingOverride | Where-Object { $_.ComponentName -eq 'OAuth' -and $_.SectionName -eq 'OAuthIdentityCacheFixForDownloadDomains' }

# If Hybrid Modern Authentication is active and the override is missing, configure it:
New-SettingOverride -Name "OWA HMA Download Domain Support" -Component "OAuth" -Section "OAuthIdentityCacheFixForDownloadDomains" -Parameters ("Enabled=true") -Reason "Enable support for OWA HMA when Download Domains are in use"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force

Considerations

Configuring OWA Download Domains creates a separate subdomain (e.g., attachments.domain.com) for serving attachment content. This requires DNS configuration and possibly additional SSL certificate coverage for the new subdomain. After configuration, browser clients will be redirected to the attachment domain when downloading from OWA. When HMA is active, the OAuthIdentityCacheFixForDownloadDomains setting override ensures OWA HMA token identity caching is compatible with Download Domains. Restart-Service on W3SVC and WAS will briefly interrupt web services - schedule during a maintenance window.

References

• OWA Download Domains configuration guidance
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - configure OWA Download Domains to prevent NTLM relay attacks
• Configure Exchange Server on-premises to use Hybrid Modern Authentication

EDCA-SEC-021: POP3 and IMAP services disabled unless explicitly required

Category: Platform Security | Severity: Medium | Frameworks: Best Practice, BSI, CIS, DISA

Remediation

Disable POP3 and IMAP4 Exchange services when not required.

Set-Service -Name MSExchangePOP3 -StartupType Disabled
Stop-Service -Name MSExchangePOP3 -ErrorAction SilentlyContinue
Set-Service -Name MSExchangePOP3BE -StartupType Disabled
Stop-Service -Name MSExchangePOP3BE -ErrorAction SilentlyContinue
Set-Service -Name MSExchangeIMAP4 -StartupType Disabled
Stop-Service -Name MSExchangeIMAP4 -ErrorAction SilentlyContinue
Set-Service -Name MSExchangeIMAP4BE -StartupType Disabled
Stop-Service -Name MSExchangeIMAP4BE -ErrorAction SilentlyContinue

Considerations

If POP3 or IMAP4 services are actively used by clients (mobile devices, legacy mail clients, monitoring systems), disabling them will cause connectivity failures. Audit client usage before disabling these services. If these services are required, ensure they are explicitly permitted and secured with TLS.

References

• Exchange POP3 and IMAP4 service management
• CIS Microsoft Exchange Server Benchmark
• CIS 2.4.1 (L1): Ensure 'POP3' Windows services are set to 'Disabled'
• CIS 2.4.2 (L1): Ensure 'IMAP4' Windows services are set to 'Disabled'
• V-259667 The Exchange IMAP4 service must be disabled (EX19-MB-000065)
• V-259668 The Exchange POP3 service must be disabled (EX19-MB-000066)
• BSI SYS.1.1.A6 — Deaktivierung nicht benötigter Dienste
• BSI APP.5.2.A9 — Sichere Konfiguration von Exchange-Servern

EDCA-SEC-022: PowerShell execution policy is not unrestricted

Category: Platform Security | Severity: Low | Frameworks: Best Practice, NIS2, DISA, ANSSI, BSI

Remediation

Set local machine execution policy to RemoteSigned.

# Group Policy equivalent:
# Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell
#   Turn on Script Execution = Enabled (Allow only signed scripts / Allow local scripts and remote signed scripts)
#
Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned -Force

Considerations

Changing the PowerShell execution policy to AllSigned or RemoteSigned will prevent unsigned scripts from running. Audit all scripts used for Exchange management and automation before enforcing a restrictive policy. Scripts used by monitoring tools or automation systems may fail if not properly signed.

References

• V-259664 Exchange local machine policy must require signed scripts (EX19-MB-000061)
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(i)(j): access control and multi-factor authentication - Section 11.5-11.7, 11.3, 10, 2.2
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI SYS.1.2.3.A7 — Verwendung der Windows PowerShell
• about_Execution_Policies

EDCA-SEC-023: SMBv1 server protocol is disabled

Category: Platform Security | Severity: High | Frameworks: Best Practice, CIS, CISA, ANSSI, BSI

Remediation

Disable SMBv1 using the SMB server configuration cmdlet and remove the Windows optional feature.

# Group Policy equivalent (requires MS Security Guide ADMX templates):
# Computer Configuration > Administrative Templates > MS Security Guide
#   Configure SMBv1 Server = Disabled
#   Configure SMBv1 client driver = Enabled (Disable driver)
#
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

Considerations

Disabling SMBv1 will prevent file sharing with Windows XP and Windows Server 2003 clients or servers. In modern environments this is typically safe. Verify there are no legacy systems (e.g., old printers, NAS devices, or monitoring appliances) on the network that require SMBv1 before disabling.

References

• CIS Microsoft Windows Server Benchmark
• SMB security hardening guidance
• CIS 4.8 (IG1): Uninstall or Disable Unnecessary Services on Enterprise Assets and Software
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI SYS.1.2.3.A4 — Schutz vor Ausnutzung von Schwachstellen in Anwendungen

EDCA-SEC-024: Vulnerability baseline

Category: Platform Security | Severity: High | Frameworks: Best Practice, DISA

Remediation

Apply the latest Exchange security updates to remediate known vulnerabilities. Address specific CVEs flagged by the check including SMBv3 (CVE-2020-0796), .NET (CVE-2020-1147), and download domain issues (CVE-2021-1730).

# Diagnose: Check Exchange build version and SMBv1 status
Get-ExchangeServer | Select-Object Name, AdminDisplayVersion, Edition | Format-Table -AutoSize
# Compare build numbers at: https://learn.microsoft.com/exchange/new-features/build-numbers
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol
# SMBv1 should be disabled - Exchange does not require it.

Considerations

Applying Exchange security patches requires scheduled downtime and thorough regression testing. Patches may change default configuration, IIS bindings, or service behavior. Use DAG maintenance mode and test mail flow and client connectivity after each patch.

References

• CSS VulnerabilityCheck
• V-259712 Exchange must be configured in accordance with DOD security configuration settings based on STIGs, NSA guides, CTOs, and DTMs (EX19-MB-000283)

EDCA-SEC-025: Windows Firewall enabled for all profiles

Category: Platform Security | Severity: High | Frameworks: Best Practice, CIS, NIS2, ANSSI, BSI

Remediation

Enable all Windows Firewall profiles.

# Group Policy equivalent:
# Computer Configuration > Windows Settings > Security Settings
#   Windows Defender Firewall with Advanced Security
#   Domain / Private / Public Profile > Firewall state = On
#
Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True

Considerations

The Windows Firewall must include all Exchange-required inbound and outbound port rules before enabling. Missing rules will block SMTP transport, client access, or management traffic. Review Exchange port requirements for all installed roles before enabling the firewall. Monitor event logs for blocked connections after enforcement.

References

• CIS Microsoft Windows Server Benchmark
• Windows Defender Firewall with Advanced Security
• CIS 9.1.1 (L1): Ensure 'Windows Firewall: Domain: Firewall state' is set to 'On'
• CIS 9.2.1 (L1): Ensure 'Windows Firewall: Private: Firewall state' is set to 'On'
• CIS 9.3.1 (L1): Ensure 'Windows Firewall: Public: Firewall state' is set to 'On'
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(e): network and information systems security - Section 6.3, 6.4, 3.2-3.4
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI SYS.1.1.A19 — Einrichtung lokaler Paketfilter

EDCA-SEC-026: Microsoft Defender real-time protection enabled

Category: Platform Security | Severity: Medium | Frameworks: BSI, CIS, CISA

Remediation

Enable Defender real-time monitoring.

# Group Policy equivalent:
# Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Real-time Protection
#   Turn off real-time protection = Disabled  (Disabled policy = real-time protection ON)
#
Set-MpPreference -DisableRealtimeMonitoring $false

Considerations

Microsoft Defender real-time protection on Exchange servers must be configured with correct Exchange-specific exclusions to avoid false positives and performance degradation. Enabling real-time protection without the correct exclusions can cause database corruption or transport stalls. Verify all Microsoft-recommended exclusions are in place before enabling.

References

• CIS Microsoft Windows Server 2019/2022/2025 Benchmarks
• Get-MpComputerStatus reference
• CIS 10.1 (IG1): Deploy and Maintain Anti-Malware Software
• BSI SYS.1.1.A9 — Einsatz von Virenschutz-Programmen auf Servern

EDCA-SEC-027: IIS loaded modules are signed and trusted

Category: Platform Security | Severity: High | Frameworks: Best Practice

Remediation

Remove or replace unsigned/untrusted IIS modules and validate module chain-of-trust.

# Diagnose: List IIS global modules and check Authenticode signature status
Import-Module WebAdministration -ErrorAction SilentlyContinue
Get-WebConfiguration 'system.webServer/globalModules/*' | Select-Object Name, Image | ForEach-Object { $sig = Get-AuthenticodeSignature $_.Image -ErrorAction SilentlyContinue; [PSCustomObject]@{ Name=$_.Name; SignatureStatus=$sig.Status; SignedBy=$sig.SignerCertificate.Subject } }

Considerations

Unsigned or untrusted IIS modules in Exchange virtual directories may have been installed by Exchange patches or third-party products. Removing a module required by Exchange or a legitimate third-party product will break the associated Exchange functionality. Verify the purpose of each flagged module before removal.

References

• CSS IIS module anomaly checks

EDCA-SEC-028: Dynamic memory disabled for virtualized Exchange hosts

Category: Platform Security | Severity: High | Frameworks: Best Practice

Remediation

Disable dynamic memory for Exchange virtual machines and align reserved/maximum memory with sizing guidance.

# Diagnose: Check virtualization platform and physical memory configuration
Get-WmiObject -Class Win32_ComputerSystem | Select-Object Manufacturer, Model, @{N='TotalRAMGB';E={[math]::Round($_.TotalPhysicalMemory/1GB,2)}}
# If hosted on Hyper-V, check on the host: Get-VM -Name $env:COMPUTERNAME | Select-Object DynamicMemoryEnabled
# Dynamic memory must be disabled in hypervisor settings to prevent Exchange memory pressure.

Considerations

Dynamic memory for Exchange VMs creates unpredictable memory pressure that can cause Exchange process crashes and transport stalls. If dynamic memory is currently enabled, disabling it requires coordination with the virtualization team and a VM reboot. The VM should be sized with static memory according to Exchange sizing guidelines.

References

• CSS dynamic memory check

EDCA-SEC-029: MSMQ feature not installed on Exchange hosts

Category: Platform Security | Severity: Low | Frameworks: Best Practice

Remediation

Review dependency impact and remove MSMQ-related Windows features if not explicitly required.

# Diagnose: Check if MSMQ Windows feature is installed
Get-WindowsFeature MSMQ* | Select-Object Name, DisplayName, Installed
# MSMQ is not required by Exchange. Uninstall if no other workload depends on it:
# Uninstall-WindowsFeature MSMQ

Considerations

MSMQ on Exchange servers is not typically required and can introduce attack surface. Removing the MSMQ Windows feature requires a server reboot. Verify no Exchange services or third-party products depend on MSMQ before removing it.

References

• CSS MSMQ feature check

EDCA-SEC-030: DisableAsyncNotification reset to baseline

Category: Platform Security | Severity: Medium | Frameworks: Best Practice

Remediation

Reset DisableAsyncNotification to 0 in Exchange registry root.

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15' -Name DisableAsyncNotification -Type DWord -Value 0

Considerations

The DisableAsyncNotification registry value was introduced as a mitigation for a specific Exchange issue. If it is set incorrectly it can affect push notification delivery for OWA and Outlook. Only reset this value if it has drifted from the baseline without explicit support guidance.

References

• CSS DisableAsyncNotification warning

EDCA-SEC-031: TokenCacheModule loaded status reviewed

Category: Platform Security | Severity: Low | Frameworks: Best Practice

Remediation

If TokenCacheModule is present, no action is required — this is the expected state on a patched server. If TokenCacheModule is absent on a server running Exchange 2019 CU13 or later (or Exchange SE), re-run Exchange Setup /Mode:Upgrade to restore the module, or re-apply the August 2023 Security Update. Do not manually remove TokenCacheModule from IIS; doing so re-exposes the server to CVE-2023-21709 and CVE-2023-36434.

# Diagnose: Check if TokenCacheModule is loaded in IIS global modules
Import-Module WebAdministration -ErrorAction SilentlyContinue
Get-WebConfiguration 'system.webServer/globalModules/*' | Where-Object { $_.Name -eq 'TokenCacheModule' } | Select-Object Name, Image
Get-ExchangeServer $env:COMPUTERNAME | Select-Object Name, AdminDisplayVersion
# If TokenCacheModule is present on November 2021-patched Exchange, apply KB5008631 rollback guidance.

Considerations

The TokenCacheModule mitigates CVE-2023-21709 and CVE-2023-36434. Removing it would re-expose the server to these vulnerabilities. If the module is not present after patching, check whether the rollback procedure was applied and re-apply the Exchange patch that includes the module.

References

• CVE-2023-21709 mitigation script guidance

EDCA-SEC-032: P2 FROM header manipulation detection is not disabled

Category: Platform Security | Severity: High | Frameworks: CISA

Remediation

Remove Exchange setting overrides that disable P2 FROM detection disclaimer/header actions.

Get-SettingOverride | Where-Object { $_.Name -match 'DisableP2FromRegexMatch' } | Remove-SettingOverride -Confirm:$false
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name MSExchangeTransport

Considerations

Enabling P2 FROM header detection may cause some forwarded messages or messages from systems that rewrite headers to be rejected. Test with monitoring enabled (log-only mode if supported) before enforcement. This control reduces spoofing risk but must be validated against legitimate internal forwarding scenarios.

References

• Exchange non-RFC compliant P2 FROM header detection
• CISA AA21-062A: Mitigate Microsoft Exchange Server Vulnerabilities - enable P2 FROM header manipulation detection to reduce spoofing risk

EDCA-SEC-033: Transport pickup directory path is not configured

Category: Platform Security | Severity: Medium | Frameworks: Best Practice, CIS

Remediation

Clear the PickupDirectoryPath on each transport service instance.

# Clear the pickup directory path on the local transport service.
Set-TransportService -Identity $env:COMPUTERNAME -PickupDirectoryPath $null

Considerations

Clearing the pickup directory disables the file-based mail injection mechanism. Ensure no legitimate applications or scripts rely on this path before making the change.

References

• CIS 2.2.1 (L1): Ensure Transport Pickup Directory Path is not set
• Configure the Pickup directory and the Replay directory in Exchange Server

EDCA-SEC-034: Exchange anti-spam filtering is installed, enabled, and configured

Category: Platform Security | Severity: Medium | Frameworks: DISA, BSI

Remediation

On Mailbox servers, run the Install-AntiSpamAgents.ps1 script provided with Exchange to install the anti-spam transport agents, then restart the Microsoft Exchange Transport service. Enable each agent using Enable-TransportAgent and verify filtering is enabled using the corresponding configuration cmdlet: Set-ContentFilterConfig -Enabled $true, Set-SenderFilterConfig -Enabled $true, Set-SenderIdConfig -Enabled $true, Set-SenderReputationConfig -Enabled $true. On Edge Transport servers the agents are installed by default; only the enabled state needs verification.

# Check transport agent state
Get-TransportAgent | Where-Object { $_.Identity -in 'Content Filter Agent', 'Sender Filter Agent', 'Sender Id Agent', 'Protocol Analysis Agent' } | Select-Object Identity, Enabled

# Check config-level enabled state for each agent
Get-ContentFilterConfig    | Select-Object Enabled
Get-SenderFilterConfig     | Select-Object Enabled
Get-SenderIdConfig         | Select-Object Enabled
Get-SenderReputationConfig | Select-Object Enabled

# Install anti-spam agents on a Mailbox server (not required on Edge Transport — agents are present by default)
# Run Install-AntiSpamAgents.ps1 from the Exchange Management Shell on the Mailbox server

# Restart the transport service after installation
Restart-Service MSExchangeTransport

# Enable each required anti-spam agent at the transport layer
Enable-TransportAgent -Identity 'Content Filter Agent'
Enable-TransportAgent -Identity 'Sender Filter Agent'
Enable-TransportAgent -Identity 'Sender Id Agent'
Enable-TransportAgent -Identity 'Protocol Analysis Agent'

# Enable filtering at the configuration level
Set-ContentFilterConfig    -Enabled $true
Set-SenderFilterConfig     -Enabled $true
Set-SenderIdConfig         -Enabled $true
Set-SenderReputationConfig -Enabled $true

# Example: specify internal SMTP relay servers that should bypass spam filtering
# Set-TransportConfig -InternalSMTPServers @{Add = '10.0.0.1', '10.0.0.2'}

Considerations

Anti-spam agents are not installed by default on Mailbox servers. In hybrid deployments using EOP or Defender for Office 365 for cloud-based spam filtering, on-premises anti-spam may be intentionally disabled. Document the anti-spam technology in use and ensure it meets DISA requirements if these agents are not used.

References

• V-259689 Exchange must have anti-spam filtering installed (EX19-MB-000137)
• V-259690 Exchange must have anti-spam filtering enabled (EX19-MB-000138)
• V-259691 Exchange must have anti-spam filtering configured (EX19-MB-000139)
• Anti-spam protection in Exchange Server
• BSI APP.5.2.A9 — Sichere Konfiguration von Exchange-Servern

EDCA-SEC-035: Exchange application directory is protected from unauthorized access

Category: Platform Security | Severity: Medium | Frameworks: DISA

Remediation

Review and tighten NTFS ACLs on the Exchange installation directory (default: %ExchangeInstallPath%).

# Diagnose: Review NTFS ACLs on the Exchange installation directory.
(Get-Acl $exinstall).Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited | Sort-Object IdentityReference | Format-Table -AutoSize
# Verify that only privileged principals (SYSTEM, Administrators, Exchange Trusted Subsystem) have Write or FullControl.
# Unexpected Write or FullControl entries should be investigated and removed.

Considerations

Changing Exchange directory ACLs may break Exchange services or update processes. Only remove permissions that are explicitly not required. Test ACL changes in a non-production environment and verify that all Exchange services start successfully after changes.

References

• V-259699 The Exchange application directory must be protected from unauthorized access (EX19-MB-000194)
• Exchange Server security best practices

EDCA-SEC-036: Exchange email application does not share a partition with another application

Category: Platform Security | Severity: Medium | Frameworks: DISA

Remediation

Ensure Exchange is installed on a volume not shared with other application binaries. Review installed applications on Exchange servers.

# Diagnose: Identify the Exchange install drive and list top-level directories not part of Exchange or Windows.
$exchDrive = Split-Path $exinstall -Qualifier
Get-ChildItem $exchDrive -Directory -ErrorAction SilentlyContinue |
    Where-Object { $_.Name -notin @('Exchange', 'ExchangeSetupLogs', 'Program Files', 'Program Files (x86)', 'Windows', 'Users', 'PerfLogs', 'inetpub') } |
    Select-Object FullName
# Unexpected directories on the Exchange volume may indicate other applications are co-located.

Considerations

Migrating Exchange to a different volume is a complex operation that may require reinstallation. In many environments this is a planning concern addressed at deployment time. Document deviations with a risk acceptance if remediation is not feasible.

References

• V-259704 The Exchange email application must not share a partition with another application (EX19-MB-000229)
• Exchange Server deployment best practices

EDCA-SEC-037: LDAP client signing is set to require signing

Category: Platform Security | Severity: High | Frameworks: ANSSI, BSI

Remediation

Set LdapClientIntegrity to 2 (Require signing) under HKLM\SYSTEM\CurrentControlSet\Services\LDAP via Group Policy (Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options: 'Network security: LDAP client signing requirements' → 'Require signing') or directly via registry. Values: 0 = None, 1 = Negotiate signing, 2 = Require signing.

# Group Policy equivalent:
# Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
#   Network security: LDAP client signing requirements = Require signing
#
# Check current LDAP client signing setting
$ldapPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\LDAP'
$val = (Get-ItemProperty $ldapPath -Name LdapClientIntegrity -ErrorAction SilentlyContinue).LdapClientIntegrity
$status = switch ($val) {
    0       { 'None - unsigned LDAP allowed (non-compliant)' }
    1       { 'Negotiate signing' }
    2       { 'Require signing (compliant)' }
    $null   { 'Not set - defaults to Negotiate (1)' }
    default { "Unknown ($val)" }
}
"LdapClientIntegrity: $(if ($null -eq $val) { 'not set' } else { $val }) - $status"

# Set LDAP client to require signing (2)
Set-ItemProperty -Path $ldapPath -Name LdapClientIntegrity -Type DWord -Value 2
Write-Host 'LDAP client signing set to Require (2). No restart required.'

Considerations

Setting LdapClientIntegrity=2 requires that all outbound LDAP connections from this server use signed LDAP. Active Directory domain controllers on Windows Server 2008 and later support LDAP signing universally. If LDAPS (port 636 with TLS) is already in use for Exchange LDAP queries, LDAPS provides both integrity and confidentiality, making LdapClientIntegrity complementary for any remaining plaintext LDAP (port 389) connections. After setting LdapClientIntegrity=2, monitor for LDAP error 81 (LDAP_SERVER_DOWN) or authentication failures in the Exchange application log that may indicate a domain controller refusing unsigned LDAP. If any non-Windows LDAP server is queried from this Exchange server, verify it supports LDAP signing (SASL integrity protection) before enforcing.

References

• How to enable LDAP signing in Windows Server
• 2020 LDAP channel binding and LDAP signing requirements for Windows
• ANSSI - Recommandations pour l'administration sécurisée des SI reposant sur AD (2023)
• BSI APP.2.2.A8 — Absicherung des 'Sicheren Kanals'

EDCA-SEC-038: Exchange has the most current approved update installed

Category: Platform Security | Severity: Medium | Frameworks: DISA, ANSSI, BSI

Remediation

Install the latest approved Cumulative Update for the installed Exchange Server version.

# Check current Exchange build for all servers
Get-ExchangeServer | Select-Object Name, AdminDisplayVersion, Edition

Considerations

Always test Cumulative Update installations in a non-production environment first. Review the Microsoft Exchange Team Blog for known issues before applying. Exchange 2016 reached end of mainstream support in October 2025; CU23 is the final build -- Exchange 2016 organizations should prioritize migration.

References

• V-259711 Exchange must have the most current, approved Cumulative Update installed (EX19-MB-000244)
• Exchange Server build numbers and release dates
• Exchange Update Wizard
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI APP.5.2.A9 — Sichere Konfiguration von Exchange-Servern

EDCA-SEC-039: Exchange built-in Malware Agent is properly configured for the Exchange version

Category: Platform Security | Severity: Medium | Frameworks: DISA, BSI

Remediation

Enable and configure the malware filtering agent on Exchange 2019 and Exchange SE. On Exchange 2016, disable the built-in agent only when a compliant third-party antimalware solution is actively protecting Exchange transport.

# Exchange 2019 and Exchange SE: enable malware filtering agent
# Enable-TransportAgent -Identity 'Malware Agent'
# Set-MalwareFilteringServer $env:COMPUTERNAME -BypassFiltering $false
# & "$env:ExchangeInstallPath\Scripts\Enable-AntimalwareScanning.ps1"

# Exchange 2016 exception: disable built-in agent when third-party AV covers Exchange transport
# & "$env:ExchangeInstallPath\Scripts\Disable-AntimalwareScanning.ps1"

Considerations

For Exchange 2019 and Exchange SE, verify the FIP-FS engine is healthy before enabling automatic updates -- see EX-BP-042 for engine version health checks. For Exchange 2016, do NOT disable the malware agent unless a compliant third-party solution is actively protecting Exchange transport; disabling without a replacement leaves mail flow unprotected.

References

• V-259694 Exchange antimalware agent must be enabled and configured (EX19-MB-000146)
• V-259695 The Exchange malware scanning agent must be configured for automatic updates (EX19-MB-000147)
• Malware protection in Exchange Server
• BSI SYS.1.1.A9 — Einsatz von Virenschutz-Programmen auf Servern
• BSI APP.5.2.A9 — Sichere Konfiguration von Exchange-Servern

EDCA-SEC-040: Exchange database/log volumes are formatted with ReFS

Category: Platform Security | Severity: Low | Frameworks: Best Practice

Remediation

Format Exchange database and transaction log volumes with ReFS. ReFS cannot be applied in-place; volumes must be re-initialized. Plan a database move to an alternate DAG copy, reformat the volume with ReFS, and move the database back.

Get-Volume | Where-Object { $_.DriveType -eq 'Fixed' } | Select-Object DriveLetter, FileSystem, FileSystemLabel | Format-Table -AutoSize

Considerations

Converting an existing NTFS Exchange volume to ReFS requires offline reformatting and a planned database failover. NTFS remains a supported filesystem (see EX-BP-016); this control enforces the stricter Preferred Architecture recommendation. For new deployments, format all Exchange data volumes with ReFS during initial volume preparation before database creation.

References

• Exchange Server Preferred Architecture: Storage design
• Resilient File System (ReFS) overview

EDCA-SEC-041: LAPS is deployed for local administrator accounts

Category: Platform Security | Severity: Medium | Frameworks: ANSSI, BSI

Remediation

Deploy Windows LAPS (Windows Server 2019+) or legacy Microsoft LAPS. For Windows LAPS: ensure the Active Directory schema is updated and configure LAPS policy via Group Policy (Computer Configuration > Administrative Templates > System > LAPS). For legacy LAPS: install the LAPS MSI and configure via LAPS Group Policy extension.

# Group Policy equivalent:
# Computer Configuration > Administrative Templates > System > LAPS
#   Enable local admin password management = Enabled
#   (For legacy LAPS: Computer Configuration > Administrative Templates > LAPS)
#
# Check if Windows LAPS attribute is present (Windows Server 2019+)
try {
    $attr = Get-ADComputer -Identity $env:COMPUTERNAME -Properties 'msLAPS-Password','msLAPS-PasswordExpirationTime' -ErrorAction Stop
    if ($null -ne $attr.'msLAPS-Password') {
        "Windows LAPS: attribute msLAPS-Password is populated"
    } else {
        "Windows LAPS: msLAPS-Password attribute exists but is empty - LAPS may not yet have generated a password"
    }
} catch {
    "Windows LAPS: msLAPS-Password attribute not found - LAPS may not be configured or schema not extended"
}

# Check for legacy LAPS (ms-Mcs-AdmPwd attribute)
try {
    $legacyAttr = Get-ADComputer -Identity $env:COMPUTERNAME -Properties 'ms-Mcs-AdmPwd' -ErrorAction Stop
    if ($null -ne $legacyAttr.'ms-Mcs-AdmPwd') {
        "Legacy LAPS: ms-Mcs-AdmPwd attribute is populated"
    }
} catch {
    "Legacy LAPS: ms-Mcs-AdmPwd attribute not present"
}

Considerations

LAPS manages the local administrator account (built-in SID S-1-5-21-*-500 or a named account) and requires Active Directory schema extensions. In environments that use Windows Server 2019 and later, prefer Windows LAPS over legacy LAPS as it is built into the OS and supports Azure AD and enhanced encryption. If the Exchange server has a custom local administrator account name (not 'Administrator'), configure LAPS to target that account name explicitly. LAPS password storage in AD requires appropriate ACLs to prevent unauthorized read access to the msLAPS-Password attribute.

References

• Windows LAPS overview
• Deploy Windows LAPS
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI APP.2.2.A7 — Umsetzung sicherer Verwaltungsmethoden für Active Directory

EDCA-SEC-042: NetBIOS over TCP/IP is disabled on all network interfaces

Category: Platform Security | Severity: Low | Frameworks: ANSSI, BSI

Remediation

Disable NetBIOS over TCP/IP on all network adapters by setting the NetbiosOptions registry value to 2 (disabled) under each interface GUID key in HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces. Alternatively, configure via Group Policy using a startup script or use the Network Adapter advanced properties in the GUI.

# Group Policy equivalent:
# Computer Configuration > Preferences > Windows Settings > Registry
#   Key: HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}
#   Value: NetbiosOptions = 2 (DWORD) — Disabled
#
# Check current NetBIOS over TCP/IP setting per interface
$interfacesPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces'
Get-ChildItem $interfacesPath | ForEach-Object {
    $val = (Get-ItemProperty $_.PSPath -Name NetbiosOptions -ErrorAction SilentlyContinue).NetbiosOptions
    $status = switch ($val) { 0 { 'Default (use DHCP)' } 1 { 'Enabled' } 2 { 'Disabled' } default { "Unknown ($val)" } }
    [PSCustomObject]@{ Interface = $_.PSChildName; NetbiosOptions = $val; Status = $status }
} | Format-Table -AutoSize

# Disable NetBIOS on all interfaces (set to 2 = disabled)
Get-ChildItem $interfacesPath | ForEach-Object {
    Set-ItemProperty -Path $_.PSPath -Name NetbiosOptions -Type DWord -Value 2
    Write-Host "Disabled NetBIOS on interface: $($_.PSChildName)"
}
Write-Host 'Done. Changes take effect immediately (no reboot required).'

Considerations

Disabling NetBIOS over TCP/IP on Exchange servers is safe in modern Active Directory environments where DNS provides all name resolution. Verify that no legacy applications, backup agents, or monitoring tools rely on NetBIOS name resolution before disabling. In environments with very old Windows clients (pre-Windows 2000) or legacy SMB-dependent systems, NetBIOS may still be required on specific segments. If the server hosts any application that broadcasts NetBIOS names (e.g., legacy file sharing over NBT), connectivity to those shares from NetBIOS-dependent clients will be lost. After disabling, monitor for any connectivity failures, particularly from older SMTP relay devices that use NetBIOS for host lookup.

References

• NetBIOS over TCP/IP configuration
• Disable NetBIOS over TCP/IP
• ANSSI - Mise en œuvre sécurisée d'un serveur Windows membre AD DS (2025)
• BSI APP.2.2.A3 — Planung der Gruppenrichtlinien unter Windows

EDCA-SEC-043: SMB packet signing is required on server and client

Category: Platform Security | Severity: High | Frameworks: ANSSI, BSI, CIS

Remediation

Set RequireSecuritySignature=1 for both LanmanServer (SMB server) and LanmanWorkstation (SMB client) via registry or Group Policy (Security Options: 'Microsoft network server: Digitally sign communications (always)' and 'Microsoft network client: Digitally sign communications (always)').

# Group Policy equivalent:
# Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
#   Microsoft network server: Digitally sign communications (always) = Enabled
#   Microsoft network client: Digitally sign communications (always) = Enabled
#
# Check SMB server signing (LanmanServer)
$serverPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters'
$serverReq = (Get-ItemProperty $serverPath -Name RequireSecuritySignature -ErrorAction SilentlyContinue).RequireSecuritySignature
"SMB Server RequireSecuritySignature: $(if ($null -eq $serverReq) { 'not set (default: 0 - not required)' } else { $serverReq })"

# Check SMB client signing (LanmanWorkstation)
$clientPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters'
$clientReq = (Get-ItemProperty $clientPath -Name RequireSecuritySignature -ErrorAction SilentlyContinue).RequireSecuritySignature
"SMB Client RequireSecuritySignature: $(if ($null -eq $clientReq) { 'not set (default: 0 - not required)' } else { $clientReq })"

# Require SMB signing on server and client (1 = required)
Set-ItemProperty -Path $serverPath -Name RequireSecuritySignature -Type DWord -Value 1
Set-ItemProperty -Path $clientPath -Name RequireSecuritySignature -Type DWord -Value 1
Write-Host 'SMB signing required on server and client. No restart required; applies to new connections.'

Considerations

Requiring SMB signing affects all SMB connections on the Exchange server: DAG log file replication, file share witness connections, administrative share access, and SYSVOL/NETLOGON traversal. All supported Windows SMB clients negotiate signing automatically — modern Windows versions (Vista and later) all support SMB signing. Requiring signing on the SMB client (LanmanWorkstation) means this Exchange server will refuse to connect to SMB targets that do not offer signing; verify that all SMB targets (file share witnesses, backup targets) support signing before enforcing the client setting. This control is complementary to EDCA-SEC-023 (SMBv1 disabled) — SMBv1 does not support mandatory signing and should already be disabled.

References

• Overview of Server Message Block signing
• Configure SMB signing with confidence
• ANSSI - Recommandations pour l'administration sécurisée des SI reposant sur AD (2023)
• BSI SYS.1.2.3.A5 — Sichere Authentisierung und Autorisierung in Windows Server
• CIS Microsoft Windows Server 2019/2022/2025 Benchmarks — 2.3.8/2.3.9 SMB signing

EDCA-RES-001: Core Exchange services are running

Category: Resilience | Severity: High | Frameworks: Best Practice, NIS2

Remediation

Run Test-ServiceHealth to identify required Exchange services that are not running, then start them.

# Diagnose: Check which required Exchange services are not running
Test-ServiceHealth | Where-Object { -not $_.RequiredServicesRunning } | Select-Object Role, ServicesNotRunning

# Remediate: Start services that are not running
Test-ServiceHealth | Where-Object { -not $_.RequiredServicesRunning } | ForEach-Object { $_.ServicesNotRunning | ForEach-Object { Start-Service -Name $_ -ErrorAction SilentlyContinue } }

Considerations

Restarting Exchange services disrupts active client sessions and mail flow. Always use DAG maintenance mode or scheduled maintenance windows when restarting services on production servers.

References

• Microsoft Exchange services overview
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(c): business continuity and crisis management - Section 6.3, 6.4, 3.2-3.4

EDCA-RES-002: Unified content cleanup baseline

Category: Resilience | Severity: Low | Frameworks: Best Practice

Remediation

Add the correct UnifiedContent temp path to %ExchangeInstallPath%\Bin\Monitoring\Config\AntiMalware.xml to enable the monitoring probe to automatically clean up temp files from the EdgeTransport process.

# Diagnose: Check UnifiedContent temp directory for stale file accumulation
$exchPath = $exinstall
Get-ChildItem (Join-Path $exchPath 'TransportRoles\data\Temp\UnifiedContent') -Recurse -ErrorAction SilentlyContinue | Measure-Object Length -Sum | Select-Object Count, @{N='TotalMB';E={[math]::Round($_.Sum/1MB,2)}}

Considerations

The Unified Content Cleanup task temporarily increases I/O load on the transport database volume when running. Schedule cleanup tasks during low-traffic periods. Cleaning a large accumulated backlog may take extended time.

References

• CSS UnifiedContentCleanup

EDCA-RES-003: Replication health checks pass

Category: Resilience | Severity: Medium | Frameworks: Best Practice, NIS2

Remediation

Investigate and resolve failed DAG replication checks.

# Diagnose: Run DAG replication health checks and review database copy status
Test-ReplicationHealth -Server $env:COMPUTERNAME | Sort-Object CheckDescription | Format-Table CheckDescription, Result, Error -AutoSize
Get-MailboxDatabaseCopyStatus -Server $env:COMPUTERNAME | Select-Object Name, Status, CopyQueueLength, ReplayQueueLength, ContentIndexState | Format-Table -AutoSize

Considerations

Replication failures may have causes beyond configuration - including storage latency, network connectivity, or witness server unavailability. Do not make DAG configuration changes during active failovers or when the DAG is already in a degraded state. Follow the resolution steps appropriate for each specific replication health check failure.

References

• Test-ReplicationHealth command
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(c): business continuity and crisis management - Section 6.3, 6.4, 3.2-3.4

EDCA-RES-004: Mailbox database deleted item retention is at least 14 days

Category: Resilience | Severity: Medium | Frameworks: Best Practice, CIS

Remediation

Set DeletedItemRetention to at least 14 days on every mailbox database.

# Set deleted item retention to 14 days on a specific mailbox database.
# To target a specific database: replace 'DatabaseName' with the actual database name.
Set-MailboxDatabase -Identity 'DatabaseName' -DeletedItemRetention 14.00:00:00

Considerations

Increasing the retention period will consume additional storage in the Recoverable Items folder. Review mailbox database storage capacity before extending the retention period significantly beyond the recommended minimum.

References

• CIS 2.1.2 (L1): Ensure Keep deleted items for the specified number of days is set to 14
• Configure deleted item retention and recoverable items quotas

EDCA-RES-005: Mailbox database deleted mailbox retention is at least 30 days

Category: Resilience | Severity: Medium | Frameworks: Best Practice, CIS

Remediation

Set MailboxRetention to at least 30 days on every mailbox database.

# Set deleted mailbox retention to 30 days on a specific mailbox database.
# To target a specific database: replace 'DatabaseName' with the actual database name.
Set-MailboxDatabase -Identity 'DatabaseName' -MailboxRetention 30.00:00:00

Considerations

Soft-deleted mailboxes consume database storage until permanently purged. Check available storage prior to extending the retention period.

References

• CIS 2.1.5 (L1): Ensure Keep deleted mailboxes for the specified number of days is set to 30
• Configure deleted mailbox retention and manage mailbox restore requests

EDCA-RES-006: Mailbox database is not permanently deleted until it has been backed up

Category: Resilience | Severity: Medium | Frameworks: Best Practice, CIS, DISA

Remediation

Enable the RetainDeletedItemsUntilBackup flag on every mailbox database.

# Ensure mailbox database items are not permanently deleted before backup.
# To target a specific database: replace 'DatabaseName' with the actual database name.
Set-MailboxDatabase -Identity 'DatabaseName' -RetainDeletedItemsUntilBackup $true

Considerations

Enabling this setting requires a functioning and regularly executed backup solution. Without a backup program, Exchange will defer purging indefinitely and the Recoverable Items folder may grow without bound, consuming storage.

References

• CIS 2.1.6 (L1): Ensure Do not permanently delete items until the database has been backed up is set to True
• Set-MailboxDatabase: RetainDeletedItemsUntilBackup parameter
• V-259671 Exchange mailboxes must be retained until backups are complete (EX19-MB-000115)

EDCA-RES-007: Exchange circular logging is disabled

Category: Resilience | Severity: Low | Frameworks: DISA

Remediation

Disable circular logging on all mailbox databases.

# Disable circular logging on a specific mailbox database.
# To target a specific database: replace 'DatabaseName' with the actual database name.
Set-MailboxDatabase -Identity 'DatabaseName' -CircularLoggingEnabled $false

Considerations

Disabling circular logging requires a dedicated storage allocation for transaction logs. Ensure log volumes have adequate capacity and log backup processes are in place. For DAG members, circular logging changes require a database dismount and remount.

References

• V-259658 Exchange circular logging must be disabled (EX19-MB-000042)
• Set-MailboxDatabase cmdlet

EDCA-RES-008: Exchange mailbox databases reside on a dedicated partition

Category: Resilience | Severity: Medium | Frameworks: DISA

Remediation

Move mailbox database files to a dedicated volume separate from OS, Exchange binaries, and transaction logs.

# Verify mailbox database paths are on dedicated volumes.

Considerations

Moving mailbox databases requires a database portability operation or backup-restore cycle. Plan a maintenance window. Ensure the target volume is formatted with 64KB allocation unit size as required by Exchange.

References

• V-259669 Exchange Mailbox databases must reside on a dedicated partition (EX19-MB-000105)
• Exchange storage best practices

EDCA-RES-009: Exchange mailbox stores mount at startup

Category: Resilience | Severity: Low | Frameworks: DISA

Remediation

Set all mailbox databases to mount at startup.

Get-MailboxDatabase | Set-MailboxDatabase -MountAtStartup $true

Considerations

In some disaster recovery scenarios, databases are intentionally left set not to mount automatically. Verify that no databases used for DR or archival purposes should remain unmounted before applying this setting globally.

References

• V-259674 Exchange mailbox stores must mount at startup (EX19-MB-000121)
• Set-MailboxDatabase cmdlet

EDCA-RES-010: Exchange mailbox databases are in a highly available and redundant configuration

Category: Resilience | Severity: Medium | Frameworks: DISA

Remediation

Configure a Database Availability Group with at least two mailbox database copies across different servers.

# Check mailbox database copy status.

Considerations

DAG deployment requires at least two Exchange Mailbox servers and a witness server (file share witness or Azure cloud witness). Planning DAG deployment involves network, storage, and licensing considerations. This is a significant infrastructure change requiring careful planning.

References

• V-259709 Exchange must provide mailbox databases in a highly available and redundant configuration (EX19-MB-000234)
• Database Availability Groups in Exchange Server

EDCA-RES-011: Single Item Recovery enabled on user mailboxes

Category: Resilience | Severity: Medium | Frameworks: Best Practice

Remediation

Enable Single Item Recovery on all user mailboxes where it is currently disabled.

Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox | Where-Object { -not $_.SingleItemRecoveryEnabled } | Set-Mailbox -SingleItemRecoveryEnabled $true

Considerations

Enabling Single Item Recovery increases Recoverable Items folder storage usage because purged items are retained beyond the normal dumpster expiry for the full deleted-item retention period. Ensure adequate mailbox database storage capacity before enabling globally. Single Item Recovery is superseded by In-Place Hold or Litigation Hold when a hold is active on the mailbox.

References

• Exchange Server Preferred Architecture: Data resiliency
• Enable or disable single item recovery for a mailbox
• Set-Mailbox: SingleItemRecoveryEnabled parameter

EDCA-RES-012: DAG members span at least two Active Directory sites

Category: Resilience | Severity: High | Frameworks: Best Practice

Remediation

Extend the DAG by adding member servers in a second Active Directory site. Configure Active Manager for site-aware failover and place the file share witness appropriately for the resulting quorum model.

# Diagnose: Show DAG membership and AD site per Exchange server
Get-ExchangeServer | Select-Object Name, MemberOfDAG, Site | Format-Table -AutoSize

Considerations

Deploying DAG members across multiple AD sites requires inter-site network connectivity with sufficient bandwidth for continuous database replication. A file share witness or alternate witness server must be placed correctly for the resulting quorum model. In single-site lab or small environments where site resilience is not a requirement, this control may not be applicable.

References

• Exchange Server Preferred Architecture: DAG design
• Database availability groups (DAGs)

EDCA-TLS-001: Receive connector internal and external relay patterns are separated

Category: Transport Security | Severity: High | Frameworks: Best Practice, DISA

Remediation

Review and redesign receive connectors to separate internal and external relay/auth patterns.

# Diagnose: Audit receive connector relay scopes and authentication settings
Get-ReceiveConnector -Server $env:COMPUTERNAME | Select-Object Name, Bindings, RemoteIPRanges, PermissionGroups, AuthMechanism, TlsEnabled | Format-List
# Connectors with 'AnonymousUsers' in PermissionGroups and open RemoteIPRanges (0.0.0.0-255.255.255.255) are open relays.

Considerations

Restricting or reconfiguring receive connectors can block legitimate SMTP relay from applications and devices. Carefully audit all SMTP relay sources before changing connector permissions or authentication settings. Test mail flow from all relay sources after applying changes.

References

• Receive connectors in Exchange Server
• V-259687 Exchange internal receive connectors must not allow anonymous connections (EX19-MB-000135)

EDCA-TLS-002: Transport retry configuration baseline

Category: Transport Security | Severity: Medium | Frameworks: Best Practice

Remediation

Use Set-TransportService to set MaxPerDomainOutboundConnections to 40 or higher and MessageRetryInterval to 5 minutes or less to prevent mail queue buildup during delivery retries.

Set-TransportService -Identity $env:COMPUTERNAME -MaxPerDomainOutboundConnections 40 -MessageRetryInterval 00:05:00

Considerations

Adjusting transport retry configuration can affect how quickly Exchange requeues messages after a transient failure. Changes to retry intervals impact end-user mail delivery experience during disruptions. Follow Microsoft guidance for retry values - overly aggressive retries increase load on target servers.

References

• CSS TransportRetryConfigCheck

EDCA-TLS-003: Hybrid send connector TLS integrity

Category: Transport Security | Severity: High | Frameworks: Best Practice, NIS2

Remediation

Correct hybrid send connector TLS settings and certificate bindings to match Exchange hybrid best practices.

# Diagnose: Inspect send connector TLS configuration for hybrid mail flow
Get-SendConnector | Select-Object Name, Enabled, RequireTLS, TlsAuthLevel, TlsCertificateName, TlsDomain, CloudServicesMailEnabled | Format-List
# Hybrid send connector should have: RequireTLS=True, TlsAuthLevel=DomainValidation, TlsDomain=*.mail.protection.outlook.com

Considerations

Hybrid send connector TLS settings affect mail routing to Exchange Online. Weakening TLS requirements may allow plaintext transport to Exchange Online. Verify the connector certificate is trusted by Exchange Online before changing TLS settings. Test hybrid mail flow after any connector certificate changes.

References

• CSS Hybrid Connector checks
• ENISA / NIS2 Directive (EU) 2022/2555 - Article 21(2)(h): cryptography and encryption policies - Section 9, 6.7, 6.3, 6.6

EDCA-TLS-004: Automatic forwarding to all remote domains is disabled

Category: Transport Security | Severity: High | Frameworks: Best Practice, CIS, DISA

Remediation

Set AutoForwardEnabled to False on all remote domains, especially the default domain.

# Disable automatic forwarding to all remote domains.
Get-RemoteDomain | Set-RemoteDomain -AutoForwardEnabled $false

Considerations

Disabling auto-forward breaks any legitimate auto-forward rules users have configured to external addresses. Communicate the change in advance and provide an alternative (e.g., distribution groups or consent-based forwarding via Transport Rules).

References

• CIS 2.3.4 (L1): Ensure AutoForwardEnabled is set to False
• Control automatic external email forwarding in Microsoft 365 and Exchange
• V-259651 Exchange auto-forwarding email to remote domains must be disabled or restricted (EX19-MB-000021)
• V-259672 Exchange email forwarding must be restricted (EX19-MB-000116)
• V-259673 Exchange email-forwarding SMTP domains must be restricted (EX19-MB-000117)

EDCA-TLS-005: Automatic replies to remote domains are disabled

Category: Transport Security | Severity: Medium | Frameworks: Best Practice, CIS, DISA

Remediation

Set AutoReplyEnabled to False on all remote domains.

# Disable automatic replies to remote domains.
Get-RemoteDomain | Set-RemoteDomain -AutoReplyEnabled $false

Considerations

This setting prevents client-rule-based auto-replies from being sent externally. It does not affect Out-of-Office messages controlled by the AllowedOOFType setting. Ensure users are informed that client-side auto-replies will no longer reach external recipients.

References

• CIS 2.3.3 (L1): Ensure AutoReplyEnabled is set to False
• Remote domains in Exchange Server
• V-259692 Exchange must not send automated replies to remote domains (EX19-MB-000140)

EDCA-TLS-006: Non-delivery reports to remote domains are disabled

Category: Transport Security | Severity: Medium | Frameworks: Best Practice, CIS, DISA

Remediation

Set NDREnabled to False on all remote domains.

# Disable NDRs to remote domains.
Get-RemoteDomain | Set-RemoteDomain -NDREnabled $false

Considerations

This is a CIS Level 2 control. Disabling NDRs to external senders may complicate troubleshooting of legitimate delivery failures. Consider whether your organization needs external NDRs for business continuity before applying.

References

• CIS 2.3.1 (L2): Ensure NDREnabled is set to False
• Configure external postmaster address
• V-259706 Exchange must not send nondelivery reports to remote domains (EX19-MB-000231)

EDCA-TLS-007: Out-of-Office messages to remote domains are set to None

Category: Transport Security | Severity: Low | Frameworks: Best Practice, CIS, DISA

Remediation

Set AllowedOOFType to None on all remote domains.

# Disable Out-of-Office messages to remote domains.
Get-RemoteDomain | Set-RemoteDomain -AllowedOOFType None

Considerations

This is a CIS Level 2 control. Disabling OOF to external recipients may impact customer-facing communication. Evaluate business requirements before applying, and consider creating explicit exceptions for partner domains. In Exchange hybrid deployments, the remote domain representing the Microsoft 365 tenant is configured with IsInternal=True by the Hybrid Configuration Wizard and may legitimately have AllowedOOFType set to a non-None value to support OOF flow between on-premises and cloud mailboxes. Such internal hybrid domains are excluded from this check.

References

• CIS 2.3.2 (L2): Ensure AllowedOOFType is set to None
• Remote domains in Exchange Server - OOF settings
• V-259688 Exchange external/internet-bound automated response messages must be disabled (EX19-MB-000136)
• V-228392 Exchange external/Internet-bound automated response messages must be disabled (EX16-MB-000480)

EDCA-TLS-008: Organization-wide maximum send message size is 25 MB or less

Category: Transport Security | Severity: Low | Frameworks: Best Practice, CIS

Remediation

Set the organization-wide MaxSendSize to 25 MB.

# Set organization-wide maximum send size to 25 MB.
Set-TransportConfig -MaxSendSize 25MB

Considerations

Reducing MaxSendSize below the current value will cause existing clients sending large attachments to receive NDRs. Communicate the change and advise users to use SharePoint or OneDrive links for large file transfers instead of email attachments.

References

• CIS 2.2.2 (L1): Ensure MaxSendSize is set to 25 MB
• Message size limits in Exchange Server

EDCA-TLS-009: Organization-wide maximum receive message size is 25 MB or less

Category: Transport Security | Severity: Low | Frameworks: Best Practice, CIS, DISA

Remediation

Set the organization-wide MaxReceiveSize to 25 MB.

# Set organization-wide maximum receive size to 25 MB.
Set-TransportConfig -MaxReceiveSize 25MB

Considerations

Reducing MaxReceiveSize may cause legitimate large-attachment emails from external senders to bounce. Communicate the change to relevant users and external partners who may send large files.

References

• CIS 2.2.3 (L1): Ensure MaxReceiveSize is set to 25 MB
• Message size limits in Exchange Server
• V-259683 The Exchange global outbound message size must be controlled (EX19-MB-000130)

EDCA-TLS-010: External send connector uses DNS routing

Category: Transport Security | Severity: Medium | Frameworks: Best Practice, CIS, DISA

Remediation

Enable DNS routing on the send connector used for internet mail.

# Enable DNS routing on the internet send connector (address space = '*').
Get-SendConnector | Where-Object { $_.AddressSpaces -like '*SMTP:*;*' -or $_.AddressSpaces -like '*' } |
    Set-SendConnector -DNSRoutingEnabled $true

Considerations

Switching from smart host to DNS routing requires that Exchange servers can resolve MX records and establish direct outbound SMTP connections on port 25. Ensure that firewall rules and DNS are configured accordingly before making this change.

References

• CIS 2.2.8 (L1): Ensure UseExternalDNSServersEnabled is configured and RequireDNSRouting is set to True
• Create a Send connector to send email to the internet in Exchange
• V-259670 Exchange internet-facing send connectors must specify a smart host (EX19-MB-000106)

EDCA-TLS-011: External send connector does not ignore STARTTLS

Category: Transport Security | Severity: High | Frameworks: Best Practice, BSI, CIS, NIS2

Remediation

Set IgnoreStartTLS to False on the external send connector.

# Ensure STARTTLS is not ignored on the internet send connector.
Get-SendConnector | Where-Object { $_.AddressSpaces -like '*' } |
    Set-SendConnector -IgnoreStartTLS $false

Considerations

Setting IgnoreStartTLS to False means Exchange will attempt STARTTLS whenever a remote server advertises it. If the remote server presents an invalid or untrusted certificate and RequireTLS is also True, delivery may fail. Test with a non-production connector first.

References

• CIS 2.2.9 (L1): Ensure IgnoreSTARTTLS is set to False
• Send connector TLS configuration in Exchange Server
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-TLS-012: Send connector maximum message size is 25 MB or less

Category: Transport Security | Severity: Low | Frameworks: Best Practice, CIS, DISA

Remediation

Set MaxMessageSize to 25 MB or less on all send connectors.

# Set the send size limit on all send connectors.
Get-SendConnector | Set-SendConnector -MaxMessageSize 25MB

Considerations

Reducing the maximum send size may cause legitimate large-attachment emails to be rejected. Coordinate with business stakeholders before lowering the limit.

References

• CIS 2.2.4 (L1): Ensure Maximum send size Connector level is set to 25
• Message size limits in Exchange Server
• V-259681 Exchange message size restrictions must be controlled on send connectors (EX19-MB-000128)

EDCA-TLS-013: Receive connector maximum message size is 25 MB or less

Category: Transport Security | Severity: Low | Frameworks: Best Practice, CIS, DISA

Remediation

Set MaxMessageSize to 25 MB or less on all receive connectors.

# Set the receive size limit on all receive connectors on this server.
Get-ReceiveConnector -Server $env:COMPUTERNAME | Set-ReceiveConnector -MaxMessageSize 25MB

Considerations

Reducing the connector-level limit may cause some inbound emails to be rejected. Ensure the value aligns with the organisation-level MaxReceiveSize setting.

References

• CIS 2.2.5 (L1): Ensure Maximum receive size Connector level is set to 25
• Message size limits in Exchange Server
• V-259677 Exchange Message size restrictions must be controlled on Receive connectors (EX19-MB-000124)

EDCA-TLS-014: External send connector has domain security enabled

Category: Transport Security | Severity: Medium | Frameworks: Best Practice, BSI, CIS, DISA, NIS2

Remediation

Enable DomainSecureEnabled on the external send connector.

# Enable domain security on the internet send connector.
Get-SendConnector | Where-Object { $_.AddressSpaces -like '*' } |
    Set-SendConnector -DomainSecureEnabled $true

Considerations

Domain security requires both sending and receiving mail systems to be configured with valid certificates and mutual TLS settings. Coordinate with partner mail administrators before enabling.

References

• CIS 2.2.10 (L1): Ensure External send connector authentication Domain security is set to True
• Domain Security in Exchange Server
• V-259708 Exchange internal send connectors must use an authentication level (EX19-MB-000233)
• BSI APP.5.2.A11 — Absicherung der Kommunikation zwischen Exchange-Systemen

EDCA-TLS-015: Exchange Receive Connector maximum hop count is 60

Category: Transport Security | Severity: Low | Frameworks: DISA

Remediation

Set MaxHopCount to 60 on all receive connectors.

Get-ReceiveConnector | Set-ReceiveConnector -MaxHopCount 60

Considerations

A hop count below 60 may cause legitimate messages with complex routing paths to be rejected. The default Exchange value is 60. Only modify if directed by STIG guidance or confirmed routing loop analysis.

References

• V-259678 The Exchange Receive Connector Maximum Hop Count must be 60 (EX19-MB-000125)
• Set-ReceiveConnector cmdlet

EDCA-TLS-016: Exchange transport service maximum outbound connections is 1000

Category: Transport Security | Severity: Low | Frameworks: DISA

Remediation

Set MaxOutboundConnections to 1000 on the transport service.

Set-TransportService -Identity $env:COMPUTERNAME -MaxOutboundConnections 1000

Considerations

Setting connection limits too low may throttle outbound mail flow, particularly during peak delivery times. Review connector usage and balance security with operational mail flow requirements.

References

• V-259679 The Exchange send connector connections count must be limited (EX19-MB-000126)
• Set-TransportService cmdlet

EDCA-TLS-017: Exchange outbound connection limit per domain is controlled

Category: Transport Security | Severity: Low | Frameworks: DISA

Remediation

Set MaxPerDomainOutboundConnections to 20 on the transport service.

Set-TransportService -Identity $env:COMPUTERNAME -MaxPerDomainOutboundConnections 20

Considerations

Setting this limit too low may slow delivery to high-volume partner domains. Review typical delivery volumes per domain before applying strict limits.

References

• V-259684 The Exchange Outbound Connection Limit per Domain Count must be controlled (EX19-MB-000131)
• Set-TransportService cmdlet

EDCA-TLS-018: Exchange outbound connection timeout is 10 minutes or less

Category: Transport Security | Severity: Low | Frameworks: DISA

Remediation

Set ConnectionInactivityTimeOut to 10 minutes or less on all send connectors.

Get-SendConnector | Set-SendConnector -ConnectionInactivityTimeOut 00:10:00

Considerations

Reducing timeout values may cause premature connection failures to slow remote mail servers. Monitor NDR rates after applying changes. The default Exchange value is 10 minutes so this is typically already compliant.

References

• V-259685 The Exchange Outbound Connection Timeout must be 10 minutes or less (EX19-MB-000132)
• Set-SendConnector cmdlet

EDCA-TLS-019: Exchange global recipient count limit is set

Category: Transport Security | Severity: Low | Frameworks: DISA