We have 2 exchange servers, each has all roles including 1 mailbox database. We also have 1 DAG. Of course Exch1 is the primary.

We have 23 healthmailboxes: 10 as HealthMailbox-Exch1-001/010, 10 as HealthMailbox-Exch2-001/010. and 3 other HealthMailbox-(long string).

We understand 1 healthmailbox for each database, 10 for each CAS. 

Q1: why we got the 3rd HealthMaibox-(long string)? 

We always experienced HealthMaibox-Exch2-001 keeps on logon failure according to ADAudit Plus report. We have deleted all healthmailboxes and restarted Health manager to recreate them. Always the same result.

Q2: why we got logon failure on the healthmailbox, even on the first day of recreation? We dont have any GPO for force pswd change, and further more by default all healthmailboxes are "pswd never expired"

Thanks for help.

GPING

Get-Mailbox -Monitoring | fl *Userprin*

Hi GPING,

Up to Exchange 2013 CU6, we created one Health Mailbox per mailbox database copy and one per CAS.  The naming convention was not particularly admin-friendly, being that it was the GUID - either of the CAS or of the database.

CU6 introduced some tasty changes to both the naming convention and the amount of Health Mailboxes that are created.  We now create a Health Mailbox for every mailbox database hosted on a Mailbox server (Active or Passive) and 10 Health Mailboxes for every CAS role!

• Database Health mailbox is now HealthMailbox+Servername+DatabaseName
• CAS Health Mailboxes are now HealthMailbox+ServerName+001-010 (remember, 10 per CAS role)

Q1.So question to you, what are the versions of Ex you are in.?

2 servers multirole: 10CAS+10CAS+2DB(active+passive)+1DB(nonDAG) = 23 so is this correct.

Please note this change is only on the Displayname attribute the 'Name' attribute is still GUID based

Q2. They have passwords which are periodically reset.  The password is a random 128 character secure string, so if you have any kind of domain password policy which could affect that, then it's possible to cause issues when the passwords are reset on the Health mailbox accounts.

Not necessarily a force password change one.

You can view password change/failure activity from the following log:

....\Exchange Server\V15\Logging\Monitoring\Monitoring\MSExchangeHMWorker\ActiveMonitoringTraceLogs

Run this cmdlet and verify that the UPN is correctly showing or not.

Get-Mailbox -Monitoring  | fl *Userprin*

References:

Exchange 2013 Health Mailboxes

http://blogs.technet.com/b/admoore/archive/2015/03/11/exchange-2013-health-mailboxes.aspx

Logon Errors:

https://social.technet.microsoft.com/Forums/exchange/en-US/be11fc40-0660-4bcb-88c9-43b89000af03/exchange-2013-monitoring-mailbox

Thanks Satyajit.

The domain controller recorded very frequent "Kerberos pre-authentication failed" with the HealthMailbox-Exch2-001, (60-90 failures a day). But not a single record with other healthmailboxes.

If any GPO affects it will affect all other healthmailboxes, correct?

And ActiveMonitoringTraceLogs is bit messy /unreadable: not-local-timestamp / no result on searching for (healthmailbox string / code / characters like "authenticat" / logon ) etc.

Still Q: why it always failed on HealthMailbox-Exch2-001, during couple times of (deleting all healthmailboxes / recreate them).

Hi Gping,

Did you check the UPN? Also please share the full error details with the eve

An example entry in Eventlog \ security

Kerberos pre-authentication failed.

Account Information:
Security ID: xxx\SM_e48b724944484d338
Account Name: SM_e48b724944484d338

Service Information:
Service Name: krbtgt/xxx.LOCAL

Network Information:
Client Address: ::ffff:10.33.220.166
Client Port: 45233

Additional Information:
Ticket Options: 0x40810010
Failure Code: 0x18
Pre-Authentication Type: 2

Certificate Information:
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:

Certificate information is only provided if a certificate was used for pre-authentication.

Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.

Hi Gping,

If the ticket request fails Windows will either log this event, 4768 or 4771 with failure as the type.

Failure Code: 0x18  
Pre-authentication information was invalid  
Usually means bad password

When was the last time you had rebooted your servers(All Exch,AD).

This article says issue got resolved after reboot.

All Exchs and DCs  were reboot one month (4 wks) ago during our monthly server patching.

All healthmailboxes were deleted / recreated by restart the exchange health manager about 2 wks ago. The healthmailbox-exch2-001 always got the same problem, though I deleted/recreated all health mailboxes 2-3 times in the past 2 months. NOT for any other health mailboxes.

The link you provided might not be relevant as they had a service/process needed to be refreshed. However exchange health mailboxes were created / managed by system, in the past the exch servers were reboot monthly, the problem never changed.

Hi,

So you have not rebooted the servers after recreation of the healthmailboxes.

Since when do you suspect this issue is occuring.

Please also confirm that the UPNs are showing correctly for all mailboxes.

Satyajit:

As I have said, our servers reboot monthly. The problem is there for few months. and I delete / recreate all HMboxes 2-3 times in the past 2 months. 

"get-mailbox -monitoring | fl userprin*"  shows all "Healthmailbox??????????...???@domain.local"

Hi Gping,

Thanks for confirming the details. I'm running out of clues now.

Check if there is any change in the error pattern if you disable the particular mailbox account using ADUC.

Refer to the Password resets section and try to do the don't dos, to check if the healthmailbox responds as expected.

• Like, move it out of monitoring OU to a inheritance blocked OU.
• Resetting the password manually to see HMWorker process resets it again.
• Disabling the mailbox and restart the service to get a new mailbox, without deleting the AD account.