Have you experienced an inconsistency with some mailboxes going into a quarantined state after being migrated to Exchange Server 2019 that seemed unexplainable? I had this very situation. A customer with a small-to-medium environment had a single mailbox that would routinely go into a quarantined state after it was migrated. At the time, about 100 mailboxes had been migrated and this was the only affected mailbox.
Having not experienced this before, I approached in a way that I seemed reasonable:
- Disable the quarantine with Disable-Quarantine: the mailbox would go back into quarantine within about two minutes.
- Disabled client access methods systematically with Disable-CASMailbox: I eliminated the usually unnecessary POP and IMAP, then ActiveSync… and then everything; no difference.
- Tried migrating it back to Exchange Server 2013: it could not migrate due to the quarantine.
- Migrated all other mailboxes off of the database and created a dial-tone database after copying the original database and logs files away: this worked rather temporarily but would still go into quarantine. Eventually, I migrated it back to Exchange Server 2013 after doing this and recovered the data using the original files as a Recovery Database.
After migrating the mailbox back to Exchange Server 2013, the mailbox would no longer go into a quarantined state and no other mailboxes did this. The plan was to save this particular mailbox until the end and see about addressing it if it repeated. I created a dedicated mailbox database for the task so it would be isolated.
Eventually, It Hit Another Mailbox and Resolution
After a couple hundred other mailboxes were migrated, another mailbox experienced the same situation. Before walking through the process to create a dial tone database and migrate it back, I wanted to have another go at troubleshooting the scenario. The originally affected mailbox was larger (~60GB, but definitely a supported size), but the second affected mailbox was less than 5GB. Further, the larger mailbox became next to zero in size after the dial tone database.
This second mailbox happened some months later as there were other issues halting the migration, such as issues with the backup software. Someone else experienced this issue and the resolution was related to the MaxSend and MaxReceive size in the transport configuration being set to Unlimited.
I frantically checked the environment and it happened to have those properties set to Unlimited!
I built the initial Exchange Server 2013 environment some years before as part of a migration from Exchange Server 2010. I don’t recall if those settings were there at the time, but the default for Exchange Server 2019 is about 10MB. The rest of the world had standardized on 25MB and Microsoft gave this 10MB of padding when it used this as the basis of operation in Exchange Online. Microsoft had moved on to 150MB, so I decided that this should be adequate and provided 40% padding over that. Simply having a finite value established fixed the issue.
Having unlimited values is not a recommended practice. First and foremost, the underlying storage is not unlimited. Any time one user of operation can consume all of the available resources can create an opportunity for a sort of denial of service attack by consuming the resources and taking all of the dependent operations offline.
After testing the scenario, the mailbox no longer was placed into a quarantined state. I followed up with the customer letting them know what I set the value to which was acceptable for them.