A central hub of Azure cloud migration services and tools to discover, assess, and migrate workloads to the cloud.
Hi again ANTHONY KELMAN MAMANI VARGAS & thx for join me at Q&A platform,
Error 110099 is only a high-level “replication couldn't be enabled” error, so discovery working correctly doesn't tell us which replication prerequisite failed.
I would reproduce the failure once and immediately check the appliance logs under C:\ProgramData\Microsoft Azure\Logs. Search around that timestamp for the VM name and 110099, but also look for the underlying exception from the gateway/replication components. That's where I'd expect a more useful VMware/VDDK, snapshot, datastore, connectivity, or Azure-side error.
At the same timestamp, check the Azure Activity Log for the failed Microsoft.RecoveryServices/vaults/replicationFabrics/replicationProtectionContainers/replicationMigrationItems/write operation and inspect its full status message and correlation ID. If the portal only exposes 110099, Microsoft support can use that correlation ID to retrieve the provider-side failure that isn't exposed publicly.
If only one VM fails, I'd focus first on its VMDKs, existing snapshots, independent/non-persistent disks, RDMs and vCenter permissions required for snapshot/datastore operations. If several unrelated VMs fail with 110099, it's much more likely to be appliance/VDDK connectivity, RBAC/storage configuration, or the Recovery Services backend rather than an individual VM disk problem.
A useful isolation test is therefore to enable replication for one small, standard VMware VM. If that also fails, collect its failure timestamp, appliance logs and Activity Log correlation ID and investigate the common replication path rather than the original VM.
rgds,
Alex