Process to enable disaster recovery for work group on-prem servers

Question

Process to enable disaster recovery for work group on-prem servers

KrupaVani Gundraju 0

Hello Community,

We are working on enabling disaster recovery for on-prem servers.

What is the detailed process for enabling DR for work group servers?

Bharath Y P 10,180 Reputation points Microsoft External Staff Moderator

2026-06-30T17:02:46.19+00:00

Hello Krupavani Gundraju, Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!

2 answers

Your answer

Bharath Y P 10,180 Reputation points Microsoft External Staff Moderator

2026-06-30T17:02:46.19+00:00

Hello Krupavani Gundraju, Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!

Answer 1

Hello Krupavani Gundraju, For physical-server DR to Azure, Azure Site Recovery treats a server the same whether it's domain-joined or workgroup (non-domain-joined) — ASR does not require Active Directory for the replication itself. The "workgroup" detail only affects two practical things:

Credentials — you supply a local admin account (e.g., .\Administrator or ServerName\localadmin) for Mobility Service push-install, instead of a domain account.
Post-failover identity/auth — apps that relied on the workgroup machine's local accounts will keep working, but you should plan how users/apps will reach the failed-over VM in Azure (DNS/IP, local logins).

So: treat them as ordinary physical Windows/Linux servers and follow the physical-server ASR flow.

Two important caveats to set expectations up front

No failback to physical. After a failover to Azure, a physical server cannot fail back to an on-prem physical machine — you can only fail back to a VMware VM (or just run it in Azure and rebuild on-prem manually). This is a hard ASR limitation; make sure stakeholders accept it. Physical server DR (limitations)
Use the Modernized appliance, not "Enable replication (Classic)." The AI answer on the thread points to the Classic VMware/physical flow; for new deployments Microsoft recommends the Modernized ASR replication appliance. Also note: create a NEW Recovery Services vault for the appliance — don't reuse one already protecting other items. Physical server architecture – Modernized

End-to-end process for workgroup physical servers

1. Plan & prerequisites

Define RTO(maximum downtime)/RPO(acceptable data loss), list the servers, confirm each meets Azure VM + replicated-machine support (OS version, disk count/size ≤32 TB, boot type, etc.).
Confirm OS is supported (Windows Server 2016+/supported Linux). Note older Win Server 2008/2012 are EOS.

2. Prepare Azure (target)

Create an Azure subscription / target VNet / subnet and ensure RBAC: your account needs replication permissions (Contributor + Site Recovery Contributor, plus VM Contributor on the target RG/VNet).

3. Create the Recovery Services vault

Azure portal → Recovery Services vaults → Create (a fresh vault) → in the vault, Site Recovery → choose the physical machines / VMware to Azure scenario.

4. Deploy the ASR replication appliance on-prem (Modernized)

Download and set up the ASR replication appliance (a Windows Server VM/physical box on the same network that can reach your workgroup servers + Azure over HTTPS/443 outbound). It bundles the process server, proxy, recovery-services agent, etc.
Register the appliance to the vault.

5. Install the Mobility Service on each workgroup server

You can let ASR push-install it (supply a local admin credential per server, since they're workgroup — format ServerName\localadmin), or install it manually (recommended for tightly firewalled/workgroup machines to avoid push/WMI/firewall headaches).
Ensure each server can reach the appliance and required ports are open. Mobility service install

6. Enable replication

In the vault → Enable replication → Physical machines → add each server by IP/FQDN, pick the appliance, the target RG/VNet/subnet/storage/managed-disk type, and a replication policy (RPO threshold, recovery-point retention, app-consistent snapshot frequency).
Initial replication seeds, then it stays in continuous delta replication.

7. Configure recovery & validate

Build Recovery Plans (boot order, scripts) for multi-server apps.
Run a Test Failover (DR drill) into an isolated VNet — validates boot + app health with zero impact to production. Do this regularly. DR drill / test failover

8. Real failover (when needed)

Run Failover to spin the servers up as Azure VMs. Remember failback is to VMware VMs only.

References (relevant docs)

Set up disaster recovery to Azure for on-premises physical servers (enable replication, source/target settings, network/ports, jobs): https://learn.microsoft.com/azure/site-recovery/physical-azure-disaster-recovery

Hope this helps. If the information was useful, please consider accepting the answer and upvoting. Feel free to reach out if you need any further assistance. Thank you.

Bharath Y P 10,180 Reputation points Microsoft External Staff Moderator

2026-07-01T06:43:35.91+00:00

Hello Krupavani Gundraju, Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!

Answer 2

For on-premises workgroup (non-domain-joined) physical servers, Azure Site Recovery (ASR) can be used to enable disaster recovery to Azure. The high-level process is:

Create and prepare a Recovery Services vault
1. In the Azure portal, go to Recovery Services vaults and create or select an existing vault.
2. In the vault, select Enable Site Recovery to start the Site Recovery configuration.
Start the “Enable replication (Classic)” flow for physical servers
1. On the vault home page, under VMware machines to Azure, select Enable replication (Classic).
2. This wizard is used for both VMware and physical machines; workgroup physical servers are handled by selecting Physical machines later.
Configure the source environment
1. On the Source environment tab:
  - In Configuration server, specify the configuration server name (this is the on-prem ASR configuration server that discovers and manages your physical machines).
  - In Machine type, select Physical machines.
  - In Process server, keep the default selection or use Add Process Server if a separate process server is required.
  - Select Next.
Configure the target (Azure) environment
1. On the Target environment tab:
  - In Target subscription, select the Azure subscription.
  - In Resource group, select or specify the resource group where the failed-over VMs will be created.
  - For Post-failover deployment model, select Resource Manager.
  - Under Target azure network, choose the Azure storage/network resources to use for replication and failover.
  - In Subnet, select the Azure virtual network and subnet that the Azure VMs will connect to after failover.
  - Select Next.
Add the workgroup physical servers
1. On the Physical machine selection tab:
  - Select Add Physical machine.
  - Specify the name and IP address of each workgroup server.
  - Select the operating system (Windows or Linux) for the machine.
  - Wait a few minutes for the servers to be discovered and listed.
Configure replication settings
1. On the Replication settings tab:
  - Select and verify the user account details that ASR will use to install the mobility service and manage replication on the physical servers.
Select the replication policy
1. On the Replication policy tab:
  - Verify that the correct replication policy is selected (RPO, retention, etc., as previously defined in the vault).
Enable replication and monitor initial sync
1. On the Review tab:
  - Review all selections and then select Enable Replication.
2. Monitor progress:
  - Go to Settings > Jobs > Site Recovery Jobs in the vault and track the Enable Protection and Finalize Protection jobs.
  - After Finalize Protection completes, the machine is ready for failover.
Monitor ongoing health and discovery
1. To monitor added servers:
  - In the vault, go to Configuration Servers and check Last Contact At to ensure the configuration server is in contact with the workgroup servers.
2. To force discovery of new machines without waiting for the scheduled discovery:
  - Highlight (do not click) the configuration server and select Refresh.

Once these steps are complete, the workgroup on-premises servers are continuously replicated to Azure and can be failed over using standard Azure Site Recovery failover workflows from the Recovery Services vault.

References: