Hi all,
I've been running a cross-forest AD and E2010 to E2013 on-prem migration for a couple of months now, and have already migrated many hundreds of computer accounts, user accounts and mailboxes. Last night when attempting to migrate the latest batch of users& mailboxes I hit this problem and it so far has me stumped:
My process for users & mailboxes is:
1. Run the prepare-moverequest.ps1 script to create the disabled MEU's in the target forest. This works a treat.
2. Run a new-moverequest for batches of mailboxes with -suspendwhenreadytocomplete enabled to get a batch to 95%
3. On the appointed migration date, run ADMT user migration to update the target MEU - match & merge the account, add SIDHistory, copy the password, enable the account etc.
4. Resume the auto-suspended move request to complete the mailbox move for the user. As its only the last 5% plus deltas, this normally finished pretty quickly, and the user is all set to logon the following morning in the target forest.
This process has served me well and has succeeded for getting close to a thousand users & mailboxes. However, last night it broke... Now when I run ADMT it immediately, consistently and repeatably corrupts the target MEU object and the in-progress move
request, and the only action I have found that "fixes" it, is to delete the target MEU object completely and start again at point 1... but as I said, the error will reoccur as soon as I catch up to point 3 again.
I have found that if I swap around steps 3 & 4 - i.e. resume the mailbox move, and let it run to 100% completion *before* I run ADMT to update the MEU object, then all appears to be OK as far as I can tell. Whilst that is a "workaround", it
isn't an ideal solution, since the migration process is heavily scripted and is predicated on running the steps in the order listed above.
When I have objects in this corrupted state, any mailbox move currently in the queue that is in any state other than completed is immediately corrupted. I cannot resume it - I cannot even remove it... every EMS cmdlet (including all moverequest and all mailbox
cmdlets) that references the affected mailbox displays the "WARNING: Database is mandatory on UserMailbox" message.
These are standard user mailboxes, NOT system health or arbitration mailboxes. I see the web is literally awash with references to this error message, but very much of the time it's linked to those system mailboxes... even more concerningly, the only "solution"
that I've so far seen to "fix" the issue is to delete and recreate the affected mailbox, which I'd prefer not to do.
I've done side-by-side comparison of attribute values of corrupted & non-corrupted MEU objects. I can see no obvious attribute value missing on affected users... all have a correctly populated HomeMDB attribute, and no mailbox databases are being removed..
The only other change in behaviour that I can focus on as a suspect is that ADMT has suddenly become unable to make the target accounts enabled due to non-complex passwords that aren't compliant with the target password policy. This has previously not been
an issue, and is giving me reason to wonder if someone (it wasn't me!) has recently implemented or enabled password complexity rules in the target forest, which I am endeavouring to look into now.
But... - could the password problem & ergo the target MEU not becoming enabled be the cause of the issue with corrupting the target MEU object and the moverequest? - and if so, why? Obviously since this is the only other obvious & observable change
in the environment, the troubleshooting handbook, page 1 says we must consider that as a possibility, and I will most certainly be investigating that until I either exclude it or confirm it to be related...
Note that once the MEU object has got itself in this corrupted state, resetting the password on the MEU & enabling it at that point does not help, I *have* to delete the MEU & start again clean.
I would very much like to know:
a) What is this darned "WARNING: Database is mandatory on UserMailbox" error referring to, what attribute does it not like?
b) Is there another fix for the target object other than deleting it? everything I've thought of/tried so far has failed.
Any help / thoughts or suggestions would be very much appreciated!
TIA
Paul G.