none
13 health mailboxes for a single database in Exchange 2013? RRS feed

  • Question

  • I have a client with an Exchange 2013 CU8 server.

    It was clean install exchange, not migrated from any previous version, where PST's from another mail server were copied up into the server.

    This server has a single database, right now sitting about 82GB in size.

    But there are 13 health mailboxes showing in exchange shell when I do a statistics line to get the mailbox sizes.

    In AD under the expected OU in exchange system objects / monitoring mailboxes I see 11 of them.

    if I search AD for health, I see 11 of them.  But in the shell, it shows one of them, a health mailbox at 2.5GB, name is "healthmailbox-PIOEX-mailbox-database-1967778532" (which is the database name it was given) and in a |FL shell output for the mailbox space used, shows a legacy DN under exchange administrative group.

    I can't find it anywhere in AD.

    I found another post in this forum to clean up the health mailboxes, delete them from AD, restart the services, and it should make empty new ones.

    I tried that, it never touched two of the mailboxes (including this large 2.5GB one) but the rest did get deleted and recreated - all 11 of them.

    Now I have 12 "in-place archive - healthmailbox -blah blah" from them all, as well as now doubled ones (i.e. healthmailbox-pioex-001 is showing now twice, all the way through 010).  I also have three health mailboxes that are healthmailbox with a GUID string after them, and hten the two healthmailbox ones I mentioned above.

    So now I have 24 healthmailbox entries in my output, as well as the 13 in-place archives.

    What can I do to clean this out?  So far my google searches are mostly pointing to the same post here about deleting the users then restarting the service, which only seemed to make things more messy here.

    Thanks for any suggestions.

    John


    John

    Thursday, March 3, 2016 7:42 PM

Answers

  • Hi john,

    Fisrt of all, Make sure that there are no pasw policys applied on the OU

    <ADdomain>\Microsoft Exchange System Objects\Monitoring Mailboxes.

    The deleted the accounts that are in the OU:

    Get-Mailbox -Monitoring | Disable-Mailbox

    Delete all health mailboxes you might find that are orphand but do NOT delete the following System mailboxes as exchange needs these:

    SystemMailbox{1f05a927-eacb-4d69-b268-866a22b2e30d}
    SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}
    SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
    Migration.8f3e7716-2011-43e4-96b1-aba62d229136
    FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042

    Wait for AD replication and restart “Microsoft Exchange Server Health Manager”

    a new healthmailbox will be created for each DB copy and 10 for each CAS following the namespcae:

    “HealthMailbox-“ + host name of server + “-“ + database name.

    “HealthMailbox-“ + host name of the CAS server + “-001” through “010.”

    Afther that all should be fine again. Do bear in mind the following rules:

    Password resets

    HM Worker is responsible for maintaining the password for Monitoring mailboxes. HM worker uses a complex algorithm to generate password to be used for monitoring mailbox.

    The password for monitoring mailbox is reset under the following conditions:

    • A new health mailbox is being created
    • Each time HM Worker process starts and is not able to retrieve the existing password for the monitoring mailbox
    • Any other scenario where HM Worker is not able to get hold of existing password for the monitoring mailbox

    Best practices

    Here are some best practices regarding management of user accounts associated with monitoring mailboxes as well as mailboxes themselves:

    • Do not apply third party customized password policies to user accounts of monitoring mailboxes
    • Exclude monitoring mailboxes from user account lockout policies
    • Do not move the user accounts out from the Monitoring Mailboxes container
    • Do not change the user account properties, like restricting password change etc.
    • Do not change AD permission inheritance
    • Since HM worker handles password resets for monitoring mailboxes, in a large environment, it is normal to see increased password reset traffic for monitoring mailbox accounts; note that doing one of the things above might increase the frequency of those resets
    • Do not move the monitoring mailboxes between mailbox databases
    • Do not apply mailbox quotas to monitoring mailboxes
    • If applying a retention policy, ensure the data within the monitoring mailbox is retained for a minimum of 30 days before being deleted


    MCTS exchange 2013 | MCTS-MCITP exchange 2010 | MCTS-MCITP Exchange: 2007 | MCSA Messaging: 2003 | MCP windows 2000

    • Marked as answer by jdthird Friday, March 4, 2016 4:14 PM
    Thursday, March 3, 2016 10:02 PM

All replies

  • Hi john,

    Fisrt of all, Make sure that there are no pasw policys applied on the OU

    <ADdomain>\Microsoft Exchange System Objects\Monitoring Mailboxes.

    The deleted the accounts that are in the OU:

    Get-Mailbox -Monitoring | Disable-Mailbox

    Delete all health mailboxes you might find that are orphand but do NOT delete the following System mailboxes as exchange needs these:

    SystemMailbox{1f05a927-eacb-4d69-b268-866a22b2e30d}
    SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}
    SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
    Migration.8f3e7716-2011-43e4-96b1-aba62d229136
    FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042

    Wait for AD replication and restart “Microsoft Exchange Server Health Manager”

    a new healthmailbox will be created for each DB copy and 10 for each CAS following the namespcae:

    “HealthMailbox-“ + host name of server + “-“ + database name.

    “HealthMailbox-“ + host name of the CAS server + “-001” through “010.”

    Afther that all should be fine again. Do bear in mind the following rules:

    Password resets

    HM Worker is responsible for maintaining the password for Monitoring mailboxes. HM worker uses a complex algorithm to generate password to be used for monitoring mailbox.

    The password for monitoring mailbox is reset under the following conditions:

    • A new health mailbox is being created
    • Each time HM Worker process starts and is not able to retrieve the existing password for the monitoring mailbox
    • Any other scenario where HM Worker is not able to get hold of existing password for the monitoring mailbox

    Best practices

    Here are some best practices regarding management of user accounts associated with monitoring mailboxes as well as mailboxes themselves:

    • Do not apply third party customized password policies to user accounts of monitoring mailboxes
    • Exclude monitoring mailboxes from user account lockout policies
    • Do not move the user accounts out from the Monitoring Mailboxes container
    • Do not change the user account properties, like restricting password change etc.
    • Do not change AD permission inheritance
    • Since HM worker handles password resets for monitoring mailboxes, in a large environment, it is normal to see increased password reset traffic for monitoring mailbox accounts; note that doing one of the things above might increase the frequency of those resets
    • Do not move the monitoring mailboxes between mailbox databases
    • Do not apply mailbox quotas to monitoring mailboxes
    • If applying a retention policy, ensure the data within the monitoring mailbox is retained for a minimum of 30 days before being deleted


    MCTS exchange 2013 | MCTS-MCITP exchange 2010 | MCTS-MCITP Exchange: 2007 | MCSA Messaging: 2003 | MCP windows 2000

    • Marked as answer by jdthird Friday, March 4, 2016 4:14 PM
    Thursday, March 3, 2016 10:02 PM
  • Hi John,

    Welcome to Technet forum.

    We create a Health Mailbox for every mailbox database hosted on a Mailbox server (Active or Passive) and 10 Health Mailboxes for every CAS role, we could refer to the following link:

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

    Please check if there is a database naming “mailbox database 1967778532”, if this database is not used, we could delete it to remove this health mailbox which could not find in ADUC.
    If this database is unmount, we could mount it to check if we could see health mailbox in ADUC.

    As you said, when you said, there are 24 health mailboxes after you recreate. If that, we suggest you create a new database and move all mailboxes to the new database to check if the issue persist.

    If not, please run the following command and post result to us for troubleshooting:

    Get-Mailbox –Monitor | FL displayname

    Best Regard,

    Jim Xu

    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Jim Xu
    TechNet Community Support

    Friday, March 4, 2016 6:46 AM
    Moderator
  • Thanks.  For the best practices, I don't see anything that was done out of normal here, everything seems to follow the suggestions.

    No password policies in place there either.

    Now, was there an easier way to delete the mailboxes?  There were thirty odd in place archives and such, so what I ended up doing was a get-mailboxstatistics against the database, porting it to a text file, then copying and pasting the names and GUID's of all the mailboxes into another text file.  Then one at a time I did a remove-storemailbox using the GUID as the identity, setting it to disabled.  After all was done, I did the get-mailboxstatistics where it searched for a disconnect reason and removed them all.

    That was just a real pain of copy/paste over and over and over...

    I restarted the service, and now have what I should, although now there's a new "In-Place Archive - HealthMailbox-PIOEX-001" already - does one of them get created during this process as well?

    But the 2.5GB one is gone, and things look better again other than this in-place being created already...

    Thanks


    John

    Friday, March 4, 2016 4:14 PM