To solve the issue, the best approach is to use the replication capabilities of Rapid Recovery.
To explain the process, we assume that the core to be replaced is called OldCore, the core to take its place is called NewCore and the replication TargetCore is called TargetCore.
For simplicity, we assume that there are no replicated machines on the OldCore Server (if they are, it is easy to extend the process explained below).
1. Install the Core software on the NewCore server
2. Add the NewCore as a replication target to the OldCore.
3. Since Rapid Recovery allows "Y" shaped Replication, add the servers protected on the OldCore to the replication with the NewTarget. As such, the servers protected by the OldCore server are replicated both on the TargetCore and the NewCore servers.
4. Wait for the replication to finish. When it is done, you have the servers protected by the OldCore server replicated both on the NewCore and the Target Core and the recovery points on the OldCore are in sync with those on the NewCore.
5. Make sure that no jobs are running and pause protection on the Old Core
6. Collect the following information from the OldCore for each agent by exporting the registry keys and values below:
a. The agent protection configuration registry key
HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Agents\\AgentProtectionConfiguration
This includes the backup schedule and the protection groups for each agent
b. The Rollup service registry key for each agent
HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Agents\\RollupService
This includes the rollup settings and the agent retention policy. If you do not have agents with their own retention policy, you can skip this (or do it only for the agents that have such a retention policy).
Note: To simplify the jobs above, use KB#157147 which shows how to execute this operations in seconds via powershell.
c. The core Retention Policy
HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\RollupService
This contains the OldCore retention policy.
d. Sql and Exchange settings (if present)
HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Agents\\AgentExchangeServerConfiguration
HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Agents\\SqlServer
e. Collect the time replication time stamp value for each agent
HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Agents\\ReplicationService\AgentRemoteSlaveCoreSettings\0\LastReplicatedRecoveryPointTimestamp
Please note that this value is recorded in UTC/GMT. To find the value in local time please run the folowing powershell commandlet:
PS C:\> get-date("RegValue")
For instance, if the actual timestamp registry value is 2017-03-15T21:02:50.1005556Z
you need to run
PS C:\> get-date("2017-03-15T21:02:50.1005556Z")
to get the local time timestamp. In this case, it would be Wednesday, March 15, 2017 5:02:50 PM
7. Break the replication between the OldCore and the NewCore. Start on the OldCore by navigating to the replication page and deleting the replication. On the NewCore navigate to the replication page and delete the replication to the NewCore server while keeping recovery points.
8. Protect the machines from the OldCore on the new core using any desired available protection method (i.e. using active directory). Set protection to paused. Do Not remove the machines on the OldCore from protection prior to having them protected on the New Core as this will trigger new base images.
9. Import the registry settings exported at #6a, #6b, 6c# and 6d#. Do not resume protection yet.
10. On the TargetCore remove the OldCore from protection while keeping the recovery points.
11. On the NewCore add TargetCore to replication and add all desired Agents to replication while keeping the replication paused.
12. Import the registry settings exported at #6e. Do not resume replication yet.
13. Make sure that no job is running and bounce the RapidRecoveryCore service.
14. When the NewCore comes back up and the Repository Check job finishes, re-enable protection and replication for one agent. Force a snapshot and make sure that both the snapshot and the replication job are incrementals. If they are not, try to check the steps above to figure out if you skipped any step. Otherwise, re-enable both protection and replication and you are ready to go.
Before re-enabling protection and replication do not omit doing an in-depth check of the settings of your backup environment. There is always possible that some settings were missed or not moved properly and you may be faced with issues at a later time. For instance, check if the Exchange log truncation is enabled.
Note: Experience shows that Standby machines need to be set up directly on the NewCore machine due to credential encryption issues (you cannot change the credentials needed for StandBy exports without redoing the StandBy export).
Disclaimer: Although the steps above should assure you an easy core transfer, you may encounter unexpected issues that require working with a support engineer. When in doubt, do not hesitate to open a case with the support team.
