Replication Settings.

These control how replication works.

In this demo I used default settings.

*

Extension Settings.

These define post-deployment automation.

Leave the defaults and click the create button.

Note: The Create button is used to configure post-deployment automation for the VM replication.

Essentially, it allows you to:

1. Enable update management:

• If you select “Allow ASR to manage” in Update settings, ASR will automatically install updates and manage the replication agent on the VM after replication or failover.
• Default: keeps your DR environment patched automatically.

*

2. Attach an Automation Account:

You can either create a new automation account or use an existing one.

Automation accounts let you run post-failover scripts like:

• Updating configurations.
• Starting/stopping services.
• Custom notifications.
• Optional but recommended for advanced automation.

*

Review your setting and start replication.

1. Click start replication.

*

2. When you start replication, ASR begins initial replication:

• Copies the entire VM disk(s) to the target region (secondary/DR region).
• This can take time depending on VM size, network bandwidth, and storage type.

Status you’ll see in the portal:

• Initial replication in progress.
• Later changes will show as replication health: normal once the initial sync completes.

Note: Azure automatically provisions a vault and associated resources in a default resource group (Site-recovery-vault-RG) for replication and also an automation account.

Note: Replication can take up to 30 minutes.

*

Test the failover

1. After the replication process is complete, you should see the following resources:

• A storage account created in the same region as the source resources (East US).
• An automation account is automatically provisioned as part of the replication setup.
• A Recovery Services vault created to manage and store replication data.

*

2. In your Recovery Service vault, go to Protected items → Replicated items

Select VM01 to proceed to the Test Failover page.

Note: You will see a warning sign because the test failover was never performed successfully.

*

3. Click on Test Failover to initiate the failover process.

Note: The Recovery Point Objective (RPO) currently shows a value of 50 seconds, indicating minimal potential data loss.

*

4. As you can see, the failover process completed successfully.

*

5. It will create a new resource in the West US region with a VM, disk, network interface, and virtual network.

*

6. Our test VM01 and its accompanying resources have been successfully replicated to the West US region.

*

7. Assign a public IP address to the replicated VM.

• Go to your VM
• Navigate to Virtual Machines and select the VM you want to assign a public IP.
• Check network interface
• Under Settings, click Networking.
• Note the Network Interface (NIC) attached to the VM.

*

8. Associate a public IP.

• Click the NIC name to open its settings.
• Under Settings, select IP configurations.
• Click on the IP configuration (usually ipconfig1).

*

For a public IP address, either:

• Select the "Public IP address settings," and assign as "Dynamic" or "Static."
• Use an existing or create a new IP address: select a previously created public IP.
• Click Save.

*

9. Verify that the public IP is assigned to VM01.

• Go back to the VM’s Overview page.
• The public IP address should now appear.

*

Conclusion
By following these steps, you successfully integrated Visual Studio Code with Azure, created and configured essential resources, implemented disaster recovery to a secondary region, and validated the setup through a test failover. Assigning a public IP address to the replicated VM ensures remote accessibility and completes the full disaster recovery cycle.

This same technique can be extended to:

• Automate the deployment of additional Azure resources directly from Visual Studio Code.
• Implement recovery solutions for multiple virtual machines or applications.
• Create Infrastructure-as-Code (IaC) templates for consistent and repeatable DR configurations.
• Integrate monitoring and alerting solutions to enhance resilience and operational visibility.

Through this workflow, you gain hands-on experience in managing Azure resources, automating DR processes, and improving business continuity readiness, all from within your development environment.

*

Written by Kirill.A - Azure & Cybersecurity Consultant at AntusNet