none
Complete network and post-replication configuration failed RRS feed

  • Question

  • I was setting up ASR for some VMware-to-Azure migrations and I'm getting a nonsensical error. The data ships up, but the configuration loses the vnet information and it won't let me set it after the fact. In the initial job, I find an error about a string that is not a valid resource id. It very well may not be a valid resource id. I recognize various names in the string and they have nothing at all to do with the VM I want to migrate. It is an id that, if valid, would have to do with a network interface on an existing Azure VM. I am hoping all this some weird fluke that will resolve itself tomorrow, because this migration is supposed to happen in 9 days. Just in case, I wanted to post this in case I am not the only one having this weird issue.
    Thursday, May 16, 2019 9:26 PM

Answers

All replies

  • Could you share the error details (message or a screenshot) for us to investigate if there are any known issues?

    Friday, May 17, 2019 5:31 AM
    Moderator
  • If my account gets verified soon, I can post some screen shots that I took. In the meantime, here is the text of the messages.

    From the "Site Recovery job" "Complete network and post-replication configuration" step:

    • Error ID
      578
    • Error Message
      '/subscriptions/f1c043c7-d39a-4d52-94c3-eece376c64f6/resourceGroups/rg-iei-eus2-prod-k8s01/providers/Microsoft.Compute/virtualMachineScaleSets/k8s-main-33490154-vmss/virtualMachines/0/networkInterfaces/k8s-main-33490154-vmss/ipConfigurations/ipconfig1' is not a valid resource Id.
    • Possible causes
      Ensure correct resource Id was specified.
    • Recommendation
      Verify resource Id and try operation again.
    • First Seen At
      5/16/2019, 4:51:55 PM

    I will note here that the only connection the VM I am ASRing has to the resource id listed is that it is targeting the same subscription. It is targeting a different resource group and different subnet.

    If I open up the configuration of the replicated VM, I find that the VNet is no longer specified and the target interface is secondary. If I try to set the VNet and set the interface to primary, I get the following error:

    Failed to complete the operation. Error: The properties of the virtual machine can't be configured. Ensure that the virtual machine is configured for protection successfully. Request Id: afc38da7-dd0c-4d33-ab36-cad6ae5ca069-2019-05-17T13:03:29Z-Ibz;cf503a4c-9ecd-4aba-ac59-98c6a12b0061

    I have had this problem with 6 VMs (two of them twice) so far.


    Friday, May 17, 2019 2:03 PM
  • I will add that I have successfully migrated dozens of VMs in recent months. These specific VMs were actually already set up in ASR, but I decided to make a change to the drive type which can only be done when initially setting them up. Fortunately, I realized something was wrong before I removed all 15 of the VMs scheduled to migrate on 5/25.
    Friday, May 17, 2019 2:09 PM
  • I will also add that I have updated to the latest version of Azure Site Recovery as part of trying to figure out what is going on. (the agent version is 9.24.1)
    Friday, May 17, 2019 6:56 PM
  • Screen shots I couldn't post previously:

    Friday, May 17, 2019 7:31 PM
  • I now have a work-around. I can set up the initial replication with a different vnet and, once in the Recovery Service Vault, I can change the configuration to match what I really want.

    If it turns out that the problem somehow really is in the configuration of the seemingly unrelated virtual scale set, that it being town down and rebuilt tonight, so that problem could go away.

    Monday, May 20, 2019 10:38 PM
  • For completeness, I wanted to follow up and say that after that virtual scale set was torn down and replaced, the issue persists, but it references an ipconfig of a vm in the new scale set. Fortunately, the work-around still works.
    Wednesday, May 22, 2019 2:25 PM
  • @Marshall Sutherland Looks like you've done a great job troubleshooting this issue and finally coming up with a workaround for now. Can you reach out to support? Because this issue requires a deep dive technically for further investigation to find the root cause of failure. Let me know if you've any limitations creating a support request.

    Friday, May 24, 2019 9:52 AM
    Moderator
  • I originally posted here because we only have basic support on our Azure account. What would be the proper channel to open a support ticket for this?
    Friday, May 24, 2019 1:11 PM

  • Here is the link https://docs.microsoft.com/en-in/azure/azure-supportability/how-to-create-azure-support-request to create support case. Let me know if you've any limitations creating a support case.
    Monday, May 27, 2019 8:04 AM
    Moderator
  • As stated above, we currently only have basic support, so I get this message:

    "With your current support plan, you can create requests for billing, subscription management and quota increase."

    Monday, May 27, 2019 3:15 PM
  • Send me an email @ AzCommunity [at] Microsoft dot com with subject line "ATTN" Sadiqh - Complete network and post-replication configuration failed. Share your subscription ID and I can help you enabling one time free support.
    Tuesday, May 28, 2019 5:01 AM
    Moderator
  • To wrap this up... Microsoft Support told me that this is caused by a known issue in ASR. There should be a fix out within 2 months. Their recommended workaround is the same one I used, which is to target a different vnet, then change it to the one you really want once the initial replication is complete.
    Friday, May 31, 2019 2:45 PM