Troubleshooting - Trusted root certificates (error code 151066)
You may receive an error message “Site Recovery configuration failed.” while configuring Azure to Azure VM replication. Most of these issues occurred due to the required trusted root certificates used for authorization and authentication aren't present on the machine. This troubleshooting article details some of the possible causes and recommended actions to resolve this issue.
ASR Failover network architecture
I'm new to Azure and I have requirement to set up disaster recovery for an on-prem server. I am aware of the process in replicating the server to the cloud. However, I am not able to grasp how networking should be in a disaster situation. Server is in 172.x.x.x network and I know that s2s VPN should be set up between the Azure network and the on-prem network And Azure network and on-prem can't be on the same subnet for s2s to work. So when I failover to cloud, how would the cloud server talk to the on-prem network? And devices in on-prem talk to the server in the cloud?Cachestorage/Recovery vault for site recovery Manager best practices
What are the suggested best practices for Cache storage . What is the default recommendation on no of VMs that should be part of same cache storage . Where should the recovery vault for site replication should be shall I configure on DR site with Geo replication enabled assuming
ASR Replication Issue - Error ID 70171
Hi. I'm new to using this forum so hopefully someone can help me I have 2 x on-premise Hyper-V Windows 2012 R2 which replicate 10 servers into an Azure Recovery Vault which is used for ASR. I have a configured ASR policy which has been working for most of the year with no issues. On Thursday last week I received notification to upgrade my Hyper-V Hosts from Azure ACS to AAD for ASR. I did this and it all went well and they're on Agent Ver 5.1.2700.0 (latest) and I updated the MARS Agents to the latest too as I had a notice about these needing updating to the latest version. When I now list my 10 servers in Azure they are all RED and Replication Health is Critical and RPO column is blank. If I open ALL the servers they correctly state the App-and Crash resistance times : so why are they RED and stated as Replication Health Critical ?? The on-premise hyper-v replications says all is working and I used this article to check the finer points that replication is indeed being sent: https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-azure-to-azure-troubleshoot-errors#outbound-connectivity-for-site-recovery-urls-or-ip-ranges-error-code-151037-or-151072). Any ideas ?Migrating VMs with greater than 8TB disk
Hello All, I wanted to see if anyone had experience with migrating VMs to Azure with data disks that are greater than 8TB in size. How did you handle it? can we use databox for something like that? This would be from a VMware environment on prem to Azure. ThanksAzure Site recovery clearing locks
Recently had an issue in re-protecting VM's following failover to a secondary region. Tried everything and couldn't resolve eventually after speaking with Azure support i ran the below script and resolved the issue with locks not clearing on failed over VM's cls $subscriptionId = Read-Host 'What is your Azure Subscription ID?' $rgName = Read-Host 'Specify the name of the Resource group in which your VM is located' $vmName = Read-Host 'Specify the name of the VM' # Sign-in with Azure account credentials Login-AzureRmAccount # Select Azure Subscription Select-AzureRmSubscription -SubscriptionId $subscriptionId # Remove any locks $locks = Get-AzureRmResourceLock -ResourceGroupName $rgName -ResourceName $vmName -ResourceType Microsoft.Compute/virtualMachines if ($locks -ne $null -and $locks.Count -ge 0){ $canDelete = Read-Host 'The VM has locks that could prevent cleanup of Azure Site Recovery stale links left from previous protection. Do you want the locks deleted to ensure cleanup goes smoothly? Reply with Y/N.' if ($canDelete.ToLower() -eq "y"){ Foreach ($lock in $locks) { $lockId = $lock.LockId Remove-AzureRmResourceLock -LockId $lockId -Force Write-Host "Removed Lock $lockId for $vmName" } } } $linksResourceId = 'https://management.azure.com/subscriptions/' + $subscriptionId + '/providers/Microsoft.Resources/links' $vmId = '/subscriptions/' + $subscriptionId + '/resourceGroups/' + $rgName + '/providers/Microsoft.Compute/virtualMachines/' + $vmName + '/' Write-Host $("Deleting links for $vmId using resourceId: $linksResourceId") $links = @(Get-AzureRmResource -ResourceId $linksResourceId| Where-Object {$_.Properties.sourceId -match $vmId -and $_.Properties.targetId.ToLower().Contains("microsoft.recoveryservices/vaults")}) Write-Host "Links to be deleted" $links #Delete all links which are of type Foreach ($link in $links) { Write-Host $("Deleting link " + $link.Name) Remove-AzureRmResource -ResourceId $link.ResourceId -Force } $links = @(Get-AzureRmResource -ResourceId $linksResourceId| Where-Object {$_.Properties.sourceId -match $vmId -and $_.Properties.targetId.ToLower().Contains("/protecteditemarmid/")}) Write-Host "Cross subscription Links to be deleted" $links #Delete all links which are of type Foreach ($link in $links) { Write-Host $("Deleting link " + $link.Name) Remove-AzureRmResource -ResourceId $link.ResourceId -Force } Write-Host $("Deleted all links ")
Azure site recovery- replication policy for offline initial replication
Hi, I have 2 sites each site has one SCVMM configured to do Azure Site Recovery. ASR is configured to replicate the VM form one site to another. Here is the issue, my VM size is big and i want to do the initial replication offline instead of over the Network. And it just not allowing me to save the policy, saying permission issues can anyone help me to find, what could be going wrong here ?? ERROR MESSAGE Permissions couldn't be set for one or more hosts on the initial replication folder path. Provider error code: 31218 Provider error message: The VMM service couldn't provide permissions for cs\nimblenter image description hereecs1$ on \nimblecs1\f$. Error: Object reference not set to an instance of an object.. During cloud configuration, the VMM service provides permissions for Hyper-V service accounts on the import and export paths used for initial replication. Provider error possible causes: The VMM service doesn't have the required privileges to modify the permissions on the import and export paths. Provider error recommended action: Ensure that the VMM service account has the required privileges to perform this operation. POSSIBLE CAUSES Verify that the initial replication path exists and is accessible.Recovery Services vault limit increased to 500 vaults per subscription per region
Today, we are delighted to announce increased scale limits for Azure Backup. Users can now create as many as 500 recovery services vaults in each subscription per region as compared to the earlier limit of 25 vaults per region per subscription. Customers who have been hitting the vault limits due to a restriction of 25 vaults can now go ahead and create vaults to manage their resources better. In addition, the number of Azure virtual machines that can be registered against each vault has been increased to 1,000 from the earlier limit of 200 machines under each vault. Read about it in the Azure blog.GDPR offers one more reason to focus on your disaster recovery strategy
Has your organization failed to devise a business continuity and disaster recovery plan because of the perception that it’s complex or expensive? Or perhaps you have a disaster recovery plan, but maybe you're not testing it frequently enough because of concerns about impacting production systems. If you’re in either category, you’ll want to start developing a plan now. Especially if your company does business in the European Union (EU) or might have any data on EU citizens. The General Data Protection Regulation (GDPR), which goes into effect May 25, 2018, is the EU’s new data protection regulation. While it doesn’t explicitly require that you back up data or implement a site recovery solution, the GDPR requirements provide additional reasons to stop waiting and fine-tune your DR plan. Learn more about it in the Azure blog.
