When migrating from one Exchange Server to another (new one) or moving from physical to a virtual machine, you might need to clone your current Exchange Server. There could be various other reasons why you need to clone your Exchange Server. In this article, we will be discussing the stepwise process to clone an Exchange Server.
Why You Would Need to Clone an Exchange Server?
Here are some reasons why you would need to clone an Exchange Server:
- When an Exchange Server has failed, you need to restore or clone the server to recover the server and get the services working as soon as possible.
- When migrating from an older Exchange Server to a new one, you would need to clone the server to a sandbox network to test the migration.
- Moving from a physical installation of the Exchange Server to a virtual environment would involve cloning of the server to virtual environment.
- Testing and troubleshooting any known issues or incompatibility issues with Cumulative Update installation before deploying in the production environment.
- To ensure business continuity, you would clone the Exchange Server (standalone) to act as a backup server in case the primary server fails.
- Clone the Exchange Server in a sandbox environment so that it can be used for training and education purposes.
Stepwise Process to Clone an Exchange Server
Below, we will be explaining the process for cloning an Exchange Server.
Note: Based on the scenario, you must carefully execute the process to avoid any unnecessary damage to the production environment.
Step 1: Prepare Sandbox Environment
A sandbox model is a network which has the same configuration of the production environment but it is isolated from the production environment. This would need to be prepared by the network team. Also, ensure that it doesn’t have any access to the internet or connectivity with any device on the production network. Any connectivity would result in conflicts, loss of data, network issues, and configuration issues.
Step 2: Select the Cloning Approach and Perform Cloning
Once you have the sandbox environment ready, there are two approaches to clone the Exchange Server:
Perform the Cloning Process
A cloning process would be made on a virtual machine. The process involves the following steps:
Note: The details are different depending on the hypervisor that you would be using, such as Hyper-V, VMWare, Proxmox, or any other.
- Shut down the production servers.
- Export the virtual machines.
- Import the virtual machines (with different names) in the sandbox network.
- Start the machines.
Restore from Previous Backup (Bare-Metal or Virtual Machine)
This is the most clean and non-intrusive operation as it involves full restore of the servers from a previous backup. If the server is a physical server, this is the right approach as there is no cloning option. There are tools that you can use from some of the hypervisors to backup a physical server and convert it to a virtual machine.
Things to Consider When Cloning the Exchange Server
When cloning, machine would be a copy of the production. So, you must be careful when setting up the network and the network VLAN for the sandbox. It’s important that no traffic is allowed from the sandbox to the production as this could cause havoc with the Active Directory schema, user authentication, device onboarding, email traffic, and may also cause data loss. It is also important to not use production user machines to connect to the sandbox, as this would cause issues when connecting back to the production network.
When cloning an Exchange Server, it is important to also clone the Active Directory Servers as it’s vital for running the Exchange Server. In case of a Database Availability Group, the nodes and servers which are used as file share witness must also be cloned.
Apart from this, when cloning an Exchange Server, you must consider that this will also clone the data. If the cloned servers will be used for testing or user training, this will include actual company data. It is highly recommended to do such tests or training using dummy data and not the company data to ensure that no data can be leaked or exposed.
You should also take into consideration the resources and storage of the cloned servers and the efforts needed before proceeding.
What to Do if Something Goes Wrong?
When cloning an Exchange Server, if the sandbox model is not setup correctly, this could lead to configuration and routing issues, apart from data loss. In such cases, where there is conflict of resources and services, databases or transaction logs can get corrupted. There are some challenges when it comes to recovery. You can restore from the backup but this would result in data loss – from when the server was backed up to when the server went down. Apart from that, you would need to consider the resources and the time needed for recovery.
As an alternative, you can use Stellar Repair for Exchange. This tool will enable you to open any version of Exchange Server database without the need of an Exchange Server. You will be able to explore the data stores and granularly export user mailboxes, user archives, public folders, shared mailboxes, and disabled mailbox, to PST and other file formats. You will be able to export directly to an Exchange Server database of any version with automatic mailbox matching. This will help reduce the time to restore, ensure no data loss, and simplify the recovery process.
To Conclude
Microsoft is generally against cloning of an Exchange Server due to the complexity and risks involved. Microsoft suggests other methods to support the procedure, like migration plan or third-party deployment tools for ensuring proper configuration and operation of the new Exchange Server setup and to prevent any data loss. If you would still consider the cloning process for testing and training purposes, you can follow the stepwise process explained in this post for cloning the Exchange Server.
If anything goes wrong and the databases get corrupted, you can use Stellar Repair for Exchange to repair the corrupt databases. This tool will help you recover the data from corrupt databases in just a few simple steps, thus minimizing the downtime.
Was this article helpful?
