Summary
The HealthChecker reports a false positive "Duplicate Overrides" error when multiple Setting Overrides exist for the same ComponentName/SectionName/Parameter but are targeted at different servers. Overrides with Status = ServerMismatch (meaning they don't apply to the server being analyzed) are incorrectly included in the duplicate detection logic.
Steps to Reproduce
- Have two or more Exchange servers (e.g.,
Server-A and Server-B).
- Create per-server Setting Overrides that target the same component/section/parameter (e.g., via the Flighting Service), such as:
FlightingServiceOverride_Server-A_F1.1 targeting Server-A
FlightingServiceOverride_Server-B_F1.1 targeting Server-B
- Run HealthChecker against either server.
Expected Behavior
Each server should only evaluate overrides that apply to it (i.e., Status = Accepted). Since only one override per server is Accepted, no duplicate should be flagged.
Actual Behavior
Both servers show the red error:
Error! Duplicate Overrides have been detected for the same parameter causing possible misconfigurations. Please address as soon as possible.
This happens because when Server-A is analyzed, it sees:
| Override Name |
ComponentName |
SectionName |
Status |
Parameters |
FlightingServiceOverride_Server-B_F1.1 |
Global |
ExchangeOnpremAsThirdPartyAppId |
ServerMismatch |
Enabled=true |
FlightingServiceOverride_Server-A_F1.1 |
Global |
ExchangeOnpremAsThirdPartyAppId |
Accepted |
Enabled=true |
Both entries are grouped together and the parameter Enabled appears twice, triggering the duplicate detection — even though only one override actually applies to the server.
Root Cause
In Invoke-AnalyzerExchangeInformation.ps1, the duplicate detection groups all SimpleSettingOverrides without filtering out ServerMismatch entries:
|
$groupedResults = $exchangeInformation.SettingOverrides.SimpleSettingOverrides | |
|
Group-Object ComponentName, SectionName | |
|
Where-Object { $_.Count -gt 1 } |
The ServerMismatch status means the override is targeted at a different server and does not apply. It should be excluded before grouping, similar to how Get-FilteredSettingOverrideInformation.ps1 already filters on Status -eq "Accepted" for its callers.
The Status property is populated by Get-ExchangeSettingOverride.ps1 directly from the Exchange diagnostic XML.
Suggested Fix
Add a Where-Object filter before the Group-Object to exclude ServerMismatch overrides:
$groupedResults = $exchangeInformation.SettingOverrides.SimpleSettingOverrides |
Where-Object { $_.Status -ne "ServerMismatch" } |
Group-Object ComponentName, SectionName |
Where-Object { $_.Count -gt 1 }
Summary
The HealthChecker reports a false positive "Duplicate Overrides" error when multiple Setting Overrides exist for the same
ComponentName/SectionName/Parameterbut are targeted at different servers. Overrides withStatus = ServerMismatch(meaning they don't apply to the server being analyzed) are incorrectly included in the duplicate detection logic.Steps to Reproduce
Server-AandServer-B).FlightingServiceOverride_Server-A_F1.1targetingServer-AFlightingServiceOverride_Server-B_F1.1targetingServer-BExpected Behavior
Each server should only evaluate overrides that apply to it (i.e.,
Status = Accepted). Since only one override per server isAccepted, no duplicate should be flagged.Actual Behavior
Both servers show the red error:
This happens because when
Server-Ais analyzed, it sees:FlightingServiceOverride_Server-B_F1.1FlightingServiceOverride_Server-A_F1.1Both entries are grouped together and the parameter
Enabledappears twice, triggering the duplicate detection — even though only one override actually applies to the server.Root Cause
In
Invoke-AnalyzerExchangeInformation.ps1, the duplicate detection groups allSimpleSettingOverrideswithout filtering outServerMismatchentries:CSS-Exchange/Diagnostics/HealthChecker/Analyzer/Invoke-AnalyzerExchangeInformation.ps1
Lines 738 to 740 in 33dc436
The
ServerMismatchstatus means the override is targeted at a different server and does not apply. It should be excluded before grouping, similar to howGet-FilteredSettingOverrideInformation.ps1already filters onStatus -eq "Accepted"for its callers.The
Statusproperty is populated byGet-ExchangeSettingOverride.ps1directly from the Exchange diagnostic XML.Suggested Fix
Add a
Where-Objectfilter before theGroup-Objectto excludeServerMismatchoverrides: