E2013 to E2019 Migration - Move Request Failing

[ch...@thechrisbrewer.com]

Hello all,

I seem to be losing my mind a bit this morning with something that has previously "just worked". Currently in the process of upgrading/migrating an Exchange 2013 environment to an Exchange 2019 environment (all on-prem). Two DAGs set up - one on the 2013 mailbox servers and one on the 2019 servers.

I had been able to migrate mailboxes to the first database set up (and replicated across the DAG) on the 2019 servers without issue. I realized I probably needed to go ahead and create a second database for the remaining mailboxes and went ahead and did that (and replicated across the DAG).

When I started my latest migration batch, it hung for quite some time before timing out and throwing errors about unable to communicate with the mailbox database. Even if I were to get into Powershell and run 'New-MoveRequest -Identity us...@domain.dom -TargetDatabase "New_2019_DB" -WhatIf', I'm immediately getting back:

Failed to communicate with the mailbox database. There is no support for this operation.

    + CategoryInfo          : ResourceUnavailable: (:) [New-MoveRequest], NoSupportException

    + FullyQualifiedErrorId : [Server=2019-server,RequestId=97ec7fba-f182-4944-973c-1ca600898827,TimeStamp=12/10/2020 5:41:50 PM] [FailureCategory=Cmdlet-NoSupportException] 857FB474,Microsoft.Exchange.Manage

   ment.Migration.MailboxReplication.MoveRequest.NewMoveRequest

    + PSComputerName        : 2019-server.fqdn.dom

But supplying the original 2019 database in the request lets me "create" the move request (if I hadn't specified WhatIf).

I went ahead and smoked the new database yesterday and re-created it this morning, this time without adding the replication back in, and am still getting the above error.

Thoughts?

Thanks,

Chris

[Michael B. Smith]

How are you doing on disk space?

 

Are you executing the PS cmdlets from the 2019 server?

--
You received this message because you are subscribed to the Google Groups "ntexchange" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntexchange+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntexchange/cc5437af-5a02-4b16-b3c7-3fe9f59db3b5n%40googlegroups.com.

[ch...@thechrisbrewer.com]

System drive is about 80-85% utilized on all 2019 servers. Exchange database drive is nearly completely empty - added new specifically for the second database. I'll go ahead and add some space to the system drives since they're getting up there, but hadn't seen any other issues pop up yet that would typically point to disk utilization.

Yes, the PS cmdlets were run from the 2019 servers.

Thanks,

Chris

[Michael B. Smith]

So the first database isn’t on the new drive? That makes me suspect the new drive. Have you tested it, like with robocopy on some large files?

To view this discussion on the web visit https://groups.google.com/d/msgid/ntexchange/6e2bcbdd-63c5-420d-818e-f9af5cfba113n%40googlegroups.com.

[ch...@thechrisbrewer.com]

It's all virtual drives (VMware) so theoretically, there shouldn't be any corruption on this new allocation of data. I can work to delete and re-add the disk though just as a precaution.

Each 2019 server is set up with a System drive (C:) and a dedicated data drive for each database (currently 2, including the busted new one - F: & G:). Both of the data drives are ReFS formated with 64K allocation unit size. It's the newest drive (G:) with the newest database (DB2) that's having issues.

Thanks,

Chris