Windows 10: Replicating a replica to Azure?

This may seem trivial, but I can't find appropriate documentation on the matter.Hyper-V replication from 1 Hyper-V to another.. Easy..But what are the implications of replicating the replica to a third Hyper-V? The idea is to replicate Hyper-V to an Offsite Hyper-V. Then replicate that Offsite Hyper-V to Azure.Is there any documentation around this? I can't find it.

:)

 

Verification of Replica failed.

Hi,

We have 4 DC in a domain located in 3 sites and all are running Windows 2012. After some GPO application, the replicated between the PDC and a DC on another site started to fail. We tried all the methods that we could find in the forum but none of them could
resolve the issue. So we decided to demote the secondary DC and promote back again. But it did not success as we got the error domain cannot be reached.

last attempt we tried to setup a new VM and tried to promote it to DC which also failed with the following error.

Verification of Replica failed. The wizard cannot access the list of domains in the forest. The target account name is incorrect"

Error getting the list of sites from teh target environment. The wizard cannot access the list of domains in the forest. The error is: The target account name is incorrect.

Please help

Thanks

Arun

 

How can I force a synchronise within Azure Site Recovery please?

I've got a machine that doesn't seem to want to replicate the final drive and is coming up with the error:

• 
  
• 
  
  78170
  
• 
  
  Replication has been flow controlled for the disks 'Disk1, Disk3' on the source machine.
  
• 
  
  The process server flow controls a replicating machine when the amount of data on the process server pending to be replicated for the machine exceeds the process server cache threshold for the machine. This can happen if 1. There is currently insufficient
  network throughput/bandwidth available on the process server to upload data to the log/target Azure storage account, which in turn can be caused due to network glitches or network outages. 2. Data change rate(churn) spikes on the replicating machine could
  have caused the cache folder on the process server to fill up. 3. Storage IOPs/throughput limits may have been hit on the log/target storage account resulting in reduced end to end upload throughput and as a consequence caused the process server cache folder
  to fill up.
  
• 
  
  1) Ensure that there is network connectivity from the process server to the target/log storage account in Azure. 2) Ensure that the "Microsoft Azure Recovery Services Agent", and "InMage Scout Vx Agent - Sentinel/Outpost" services are running on the process
  server machine. 3) Ensure that you have sufficient network bandwidth between the process server and Azure and that you are replicating to the appropriate tier of storage for the replicating machine. The ASR deployment planner (Azure Site Recovery Deployment Planner for VMware disaster recovery - Azure Site Recovery | Microsoft Learn)
  can be used to estimate the required bandwidth and the appropriate storage tier for a virtual machine to replicate to. Refer to the article Troubleshoot replication issues for disaster recovery of VMware VMs and physical servers to Azure by using Azure Site Recovery - Azure Site Recovery , to learn how to troubleshoot replication issues.
  
• 
  
  • Azure Site Recovery Deployment Planner for VMware disaster recovery - Azure Site Recovery | Microsoft Learn
  • Troubleshoot replication issues for disaster recovery of VMware VMs and physical servers to Azure by using Azure Site Recovery - Azure Site Recovery | Microsoft Learn
• 
  
  05/07/2018, 16:04:53
  
• 
  
• 
  
  78026
  
• 
  
  RPO has exceeded the configured threshold for source disks 'Disk3, Disk3'.
  
• 
  
  The RPO for a replicating machine may be impacted if: 1. The machine is shutdown, the Mobility service components on the machine is not running, or the machine doesn't have network connectivity to the process server. 2. The replicating machine is unable
  to upload changes fast enough to the process server, or the replicating machine has been flow controlled/throttled by the process server, thereby causing the machine to go into a non-data replication mode. 3. Recovery tag generation failures on the replicating
  machine. 4. The process server is unable to upload changes fast enough to the target/log Azure storage account (or the master target server if replicating to an on-premises site). This in turn can happen due to network connectivity issues /glitches or insufficient
  network throughput/bandwidth between the process server and the Azure log/target storage account. 5. Storage IOPs/throughput limits are being hit on the log/target storage account resulting in reduced end to end upload throughput from the process server to
  the log/target storage account in Azure.
  
• 
  
  1. If there are other errors for the replicating machine, resolve them first. 2. See the list of recent events for the replicating machine that may be impacting the RPO of the machine by going to the events section of the recovery services vault. If there
  are any such events, resolve them. 3. Ensure that you have sufficient network bandwidth between the process server and the log/target Azure storage account (or master target server if replicating to on-premises site) to upload replication data, and that you
  are replicating to the appropriate tier of storage based on the data change rate characteristics of the replicating machine. Use the ASR deployment planner (https://aka.ms/asr-v2a-deployment-planner) to estimate the necessary network bandwidth requirements
  and the appropriate tier of storage to replicate to. Refer to the article https://aka.ms/asr-v2a-rpo-exceeded , to learn how to troubleshoot replication issues.
  
• 
  
  • https://aka.ms/asr-v2a-deployment-planner
  • https://aka.ms/asr-v2a-rpo-exceeded
• 
  
  05/07/2018, 13:54:11
  

I've followed all of the suggestions and the source machine doesn't seem to have any issues. The ASR box itself has 16 cpu cores, 32gb ram and a total of 3 TB's allocated to it for caching. Our link is a gigabit link from the office out to the internet and
we have a vpn gateway used for our P2P link.

Any ideas how i can force a replication to restart without disabling protection and recreating the job again?

Thanks

Matt

 

Migrating On Prem VM to Azure

Hi Experts, We have a requirement of moving out VMs as is in Azure from Current On-Prem and the process we are following is

1. Create a RAW image from an on-prem VM.
   
2. Convert the RAW image to VHD.
   
3. Move the VHD file to Azure Storage.
   
4. Convert the Disks to managed disks.
   
5. Mount the OS disk to the C drive and other disks respectively.
   

Issue - Once we mount the OS disk we are not able to RDP to the machine we have followed the steps suggested in the below links and as usual there are millions of documents and none point in the right direction unfrotunately.

Links followed to figure out options to get this done -

Prepare a Windows VHD to upload to Azure - Azure Virtual Machines | Microsoft Docs - Microsoft documentation.

Create a Windows VM from a specialized VHD in the Azure portal - Azure Virtual Machines - Microsoft documentation.

Upload a VHD to Azure and create a virtual machine - Stephanie Kahlam - Some helpful people created this and

We have tried options

1. Created image from managed disk and tried to initiate the VM and got exception as below
   Provisioning failed.
   OS Provisioning for VM 'demo-1' did not finish in the allotted time. However, the VM guest agent was detected running. This suggests the guest OS has not been properly prepared to be used as a VM image (with CreateOption=FromImage). To resolve this issue, either use the VHD as is with CreateOption=Attach or prepare it properly for use as an image:
   * Instructions for Windows: https://azure.microsoft.com/documentation/articles/virtual-machines-windows-upload-image/
   * Instructions for Linux: https://azure.microsoft.com/documentation/articles/virtual-machines-linux-capture-image/.
   
   
   and the suggested solution 1 to use CreateOption=Attach creates the VM but does not allow us to RDP to the machine so we are assuming it's not booting up. The other option suggested in the hyperlink is to create image using SysPrep which is not an option for us as we are performing a lift and shift.
   

I would like to get some guidance from experts on to the right process to follow.