Exchange 2013/2016 Monitoring Mailboxes

Can someone explain why the MSExchangeHM workers use a CONSTRUCTED UserPrincipalName when attempting to logon to Monitoring Mailboxes. Typically, the constructed UPN is in form Alias@DefaultAcceptedDomain.

Since not everyone uses AD Forest Name = Default SMTP Domain (an there's probably a minority of people doing this indeed), then this causes the Managed Availability components to fail login on when the default Accepted Domain is NOT the same as the Forest's

Root Domain's Fqdn.

E.g. in an Exchange 2007 pre-existing environment:

Default Accepted Domain = company.com

Forest Root DNS = company.local

In this case, Monitoring Mailboxes' UPN (as created in AD) is HealthMailboxXXXXXXXXXX@company.local - we observed Login Failures in Security Event log on all Exchange servers (Unknown User Name or Bad Password). After a few ticks, all "proxy-kind" Server Components

States show Inactive (Requester: HealthApi).

We therefore created a new Accepted Domain, named "company.local" and configured it as Default. Restarted the MSExchangeHM service on ALL Exchange 2013 servers and this fixed it.

After rolling out CU8 in our qual lab, we found that the HealthApi bought back all proxy-kind Server Component States to Inactive. Back to Security event logs, issue reappeared.

Reason:

company.com Accepted Domain was named "Default Domain". For a reason, Exchange setup forced it to default again (indeed, as the name says but why the hell is it touching an existing object ????).

Final resolution was to:

1. Rename "Default Domain" to "company.com"

2. Rename "company.local" to "Default Domain" and make it Default again. Expecting that next setup will not break things again (at least, "Default Domain" is now Default, so shouldn't).

In the end, the question is:

Why on hell, developers did prefer constructing a UserPrincipalName rather than doing something really stupid (???) as using the UserPrincipalName property ?

Dear Microsoft, not everyone is using contoso.com everywhere... :)