Is Windows Server 2019 for Configuration Server (Process Server and Master Target Server) for Azure Site Recovery

Question

I have some questions about Azure Site Recovery and I am looking for some answers.

1. Support for Windows Server 2019 for Configuration Server (Process Server and Master Target Server). Is Windows 2019 supported for all of them because overall in documentation also in Support matrix 2020 it is mentioned Windows 2016).
   I have also noticed in UEFI Site Recovery now supports disaster recovery for VMware VMs with UEFI-based boot architecture- Supported operating systems include Windows Server 2019.
2. Do I definitely need Two process Server (Linux + Windows) on MS Azure side for failback? What about the process server for replication do I also need an addition process server for replicating Linux machines.
3. I read that “You can only fail back to the original vCenter and Configuration server. You cannot deploy a new Configuration server and fail back using it. Also, you cannot add a new vCenter to the existing Configuration server and failback into the new vCenter”. That means if the original Vcenter is corrupted then the master target's ESX host should have access to the virtual machine's datastore. My understanding is that MS ASR creates VMs in Vcenter on failback using the replication images.
4. I also read that for failback “I need a process server as a VM in MS Azure cloud (temporarily) but what about the Master Target Server? It is written if the On-Premises Master Target Server is available I can perform a replication. Please let me know if I need both of them in MS Azure cloud as a VMs.
5. I have another question about temporary process server? Why temporary? My understanding is that a failback may be necessary more than one time.
6. Is it possible to have an automated failover and automated failback?

Answer 1

@Siraj Hasan Thank you for your post and I apologize for the delayed response!

1. Support for Windows Server 2019 for Configuration Server (Process Server and Master Target Server). Is Windows 2019 supported for all of them because overall in documentation also in Support matrix 2020 it is mentioned Windows 2016).
   Documentation is accurate. Currently we support 2016 for CS, and 2019 is in our backlog.

I have also noticed in UEFI Site Recovery now supports disaster recovery for VMware VMs with UEFI-based boot architecture- Supported operating systems include Windows Server 2019.
This is correct, as the doc mentions here. But note that secure UEFI boot is not supported.

1. Do I need Two process Server (Linux + Windows) on MS Azure side for failback? What about the process server for replication do I also need an addition process server for replicating Linux machines?
   If you have a Linux environment on-prem then you'll need to deploy a separate Linux Master Target Server on-prem. For Windows, this is not necessary (unless scale requirements demand this). Process Server is required on Azure side for Reprotect/Failback, it receives data from protected Azure VM and sends it to on-prem.
2. I read that “You can only fail back to the original vCenter and Configuration server. You cannot deploy a new Configuration server and fail back using it. Also, you cannot add a new vCenter to the existing Configuration server and failback into the new vCenter”. That means if the original Vcenter is corrupted then the master target's ESX host should have access to the virtual machine's datastore. My understanding is that MS ASR creates VMs in Vcenter on failback using the replication images.
   Not sure about the question. can you expand. Its true that you need the original Config Server for failback.
3. I also read that for failback “I need a process server as a VM in MS Azure cloud (temporarily) but what about the Master Target Server? It is written if the On-Premises Master Target Server is available I can perform a replication. Please let me know if I need both in MS Azure cloud as VMs.
   See this link here.
4. I have another question about temporary process server? Why temporary? My understanding is that a failback may be necessary more than one time.
   Its temporary because its only needed during Failback. Generally we don't see customers running Failbacks a lot, and so its redundant infra running in Azure. Hence the temporary label.
5. Is it possible to have an automated failover and automated failback?
   Failover and failback are customer-initiated, not automated.

---------------------------------------------------------------------------------------------------------------

If the response helped, do "Accept Answer" and up-vote it.