Introduction
If you're working in the domain of cloud migrations and transformations—whether from on-premises to cloud, cloud to cloud, or vice versa—one of the most common tasks every cloud engineer and architect must plan for is the cloning, backup, and restoration of virtual machines (VMs) on destination servers.
While there are several automated methods to achieve this, real-world client environments often vary significantly, making smooth transitions and task completion more complex than expected. A frequent challenge during such transitions is ensuring that the "source" VM remains online and domain-joined, while simultaneously bringing the newly cloned VM to life on the destination—also within the same domain.
This article addresses such scenarios, where I, as an architect, have had to step in and document a restoration logic tailored to the client's domain setup. In fact, I've encountered this requirement in nearly 8 out of 10 client engagements. That experience inspired me to publish this article—not only to streamline onboarding for new team members but also to avoid repeatedly preparing secure, domain-controlled VM restoration documentation for Azure Portal environments.
Before you start
Note: On the source VM that you intend to restore or clone, ensure a local administrator account is active and accessible. This is essential for performing local administrative operations post-restoration.
To restore a VM (i.e., create a new VM from backup), ensure you have the appropriate Azure role-based access control (RBAC) permissions required for the Restore VM operation.
If you do not have sufficient permissions, you can choose to restore the disk instead. Once the disk is restored, you can use the auto-generated template from the restore operation to manually create a new VM.
Before proceeding, prepare a mapping information table with details such as:
Method 1. Select a restore point
1. Expecting that the VM is getting backed up backup center, Navigate to Backup center in the Azure portal and click Restore from the Overview tab.
![Image1]()
2. Select Azure Virtual machines as the Datasource type, and then select a Backup instance.
![Image2]()
3. Select a VM and click Continue.
4. In the next screen that appears, select a restore point to use for the recovery.
![Picture3]()
Choose a VM restore configuration
1. In Restore Virtual Machine, select a restore option:
o Create new: Use this option if you want to create a new VM. You can create a VM with simple settings or restore a disk and create a customized VM.
o Replace existing: Use this option if you want to replace disks on an existing VM.
![Picture4]()
Specify settings for your selected restore option "Create New" or "Replace Existing"
If selected "Create New" Option As one of the restore options, you can create a VM quickly with basic settings from a restore point.
In Restore Virtual Machine > Create new > Restore Type, select Create new virtual machine.
In Virtual machine name, specify a VM that doesn't exist in the subscription.
In Resource group, select an existing resource group for the new VM, or create a new one with a globally unique name. If you assign a name that already exists, Azure assigns the group the same name as the VM.
In Virtual network, select the VNet in which the VM will be placed. All VNet's associated with the subscription in the same location as the vault, which is active and not attached with any affinity group, are displayed. Select the subnet. Note: The first subnet is selected by default.
In Staging Location, specify the storage account for the VM.
![Picture5]()
4. Choose the required subscription from the Subscription drop-down list to restore an Azure VM to a different subscription.
Azure Backup now supports Cross Subscription Restore (CSR), you can now restore an Azure VM using a recovery point from default subscription to another. Default subscription is the subscription where recovery point is available.
The following screenshot lists all subscriptions under the tenant where you've permissions, which enable you to restore the Azure VM to another subscription.
![Picture6]()
5. Choose the required zone from the Availability Zone drop-down list to restore an Azure VM pinned to any zone to a different zone. Azure Backup now supports Cross Zonal Restore (CZR), you can now restore an Azure VM from the default zone to any available zones. Default zone is the zone in which Azure VM is running.
The following screenshot lists all zones that enable you to restore Azure VM to another zone.As one of the restore options, you can create a disk from a restore point. Then with the disk, you can do one of the following actions:
· Use the template that's generated during the restore operation to customize settings, and trigger VM deployment. You edit the default template settings and submit the template for VM deployment.
· Attach restored disks to an existing VM.
· Create a new VM from the restored disks using PowerShell.
1. In Restore configuration > Create new > Restore Type, select Restore disks.
2. In Resource group, select an existing resource group for the restored disks, or create a new one with a globally unique name.
3. In Staging location, specify the storage account. The template file is stored here, and VHD files are also created in some scenarios.
![Picture8]()
4. Choose the required subscription from the Subscription drop-down list to restore the VM disks to a different subscription.
Azure Backup now supports Cross Subscription Restore (CSR). Like Azure VM, you can now restore Azure VM disks using a recovery point from default subscription to another. Default subscription is the subscription where recovery point is available.
5. Choose the required zone from the Availability Zone drop-down list to restore the VM disks to a different zone.
Azure Backup now supports Cross Zonal Restore (CZR). Like Azure VM, you can now restore Azure VM disks from the default zone to any available zones. Default zone is the zone in which the VM disks reside.
6. Select Restore to trigger the restore operation.
Common Action for both the methods #1 & #2
Before starting the cloned copy Mapping to domain its always suggested to shut down the source VM.
As said earlier log into the "Destination" server with the local admin account. mostly via sandbox or via RDP
After logging in using local administrator, click on my computer or system Properties and rename the server to required name and FQDN of the server and then change member of domain to Workgroup server.
Once clicked Ok system would ask you to restart the computer as shown in picture below.
![Picture10]()
Now re-login into the destination server with local admin account and keep "Domain adding credentials" handy.
Go to my computer or System Details change the member of to domain details to the required information and add the server to the domain with FQDN and when the system prompts for domain access credentials provide the credentials and NOT the LOCAL administrator credentials.
When successfully added to Domain you will get following message as shown in below screen.
![Picture11]()
Restart the VM server to ensure the domain mapping has happened successfully to the destination server.
Re join the Source Server
One the most common action is when the destination server is changed from member of domain to workgroup system sends signal to de-register the server from domain with previous name. This causes the source to be not registered in trusted Domain. hence, we need to register the server again on to domain. To do perform following actions:
log into the "Source" server with the local admin account. mostly via sandbox or via RDP
After logging in using local administrator, click on "My Computer" or system Properties and rename the server to required name and FQDN of the server and then change member of domain to Workgroup server.
![Picture12]()
Once clicked Ok, system would ask you to restart the computer as showin in picture below.
![Picture13]()
On Restart, log into server with local administrator again
Go to my computer or System Details change the member of to domain details to the required information and add the server to the domain with FQDN and when the system prompts for domain access credentials provide the credentials and NOT the LOCAL administrator credentials.
When successfully added to Domain you will get following message as shown in below screen.
![Picture11]()
Now save the changes and restart the server VM.
Now Log in with a Domian registered account to ensure the domain is now configured and trusts the server and allows domain users to log into the server.
Conclusion
As said earlier, with proper planning and mapping data, it's a standard operation and an easy way to clone a server with no loss of VM server to bad cloning.
Good Luck!!!
Reference
For VM Image Capture
If it is a Windows VM, then run sysprep for generalizing the windows installation.
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/capture-image-resource
https://learn.microsoft.com/en-us/azure/virtual-machines/capture-image-portal
VM Disk Snapshot:
You can create a snapshot of a VHD and then create a managed disk from the snapshot and deploy VM.
https://learn.microsoft.com/en-us/azure/virtual-machines/snapshot-copy-managed-disk?tabs=portal#create-a-snapshot-of-a-vhd
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/create-vm-specialized-portal
From one Tenant to another:
https://medium.com/@morsi.masmoudi/complete-guide-to-cloning-and-moving-a-vm-from-one-azure-tenant-to-another-8fa65dd6955a
from one region to another:
https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.blinkops.com/blog/clone-azure-vm&ved=2ahUKEwjOz_DLgZyQAxWP2DgGHTu_C8UQFnoECCYQAQ&usg=AOvVaw1lKg3Tu66AHJ-hNuU2tngC