Migrating from hardware appliances to Virtual

[NareshJagernaut]

We currently have 2 hardware appliances and want to migrate to virtual appliances. Can we simply add the virtual appliances as replicas and then when we're ready switch the virtual to primary and shutdown the hardware appliances? We would also be changing the hostname and IP to match the shutdown hardware appliance.

[JayGuillette · Accepted solution]

Since Hardware and virtual appliances inter-operate (if same of close software versions) then there are a couple different ways to do this, including attaching a virtual replica to a physical primary and promoting.  Then you could change the name and IP of the newly promoted virtual to the shutdown original physical primary.

You could also backup the database from the physical and restore it to the virtual, either an isolated virtual with the same name and IP or a virtual that you change to the same name and IP as the original hardware appliance after original is offline (which would make all agents think they were communicating to the original hardware primary and you would not need to update their sdconf.rec files 

[GregHowley]

similar question.  We have 4 appliances, 2 virtual & 2 physical.  Primary is virtual.  To migrate the physical replicas, is it simply a matter of backing them up, shutting them down & installing to virtual with the same name & IP?

[JayGuillette]

You don't have to migrate replicas, you simply deploy a new virtual replica then remove the original hardware replica from the Primary Operations console and shut it down.  You can then rename the new virtual replica to the name of the now decommissioned HW appliance, likewise you  could also re-IP the new virtual to use to IP of the old HW appliance.

A replica is kind of a real time, mostly read-only backup or copy of the primary database, so you do not backup the replica database, nor do you migrate it.

Optionally you could delete the HW replica first, then deploy the new virtual replica with the original name and IP of the hardware, so that DNS would not need modifications

[GregHowley]

Excellent, thanks very much.

[GregHowley]

Hi Jay,

Further to this question: my VM team is asking if there is an ova file they need to create the new VM.

Am I wrong in assuming that they just stand up a standard Windows Server and I push the replication to it?

Thanks

[JayGuillette]

Am servers can be deployed as a VM .ova file that you would download from RSA Link, which you would need a valid license to do.

You Navigate to the AM Authentication Manager Downloads...

https://community.rsa.com/community/products/securid/authentication-manager/downloads 

where you will see patches and updates, but there is also a link to [Full Product Downloads]  which is where the .ova files to deploy a new VM are located.

1. Deploy a VM .ova as a replica to your currently deployed Primary, then

2. when ready promote that replica to be the new Primary. 

3. Optionally you can shut down the original primary and rename and /or Re-IP the new VM primary to be the same as the original.

[GregHowley]

Jay,

Thanks so much for your help. I have successfully configured & attached

the new VM replicas.

Before I do the official cutover, my ISP and Network teams have asked me to

"confirm that the key has been also replicated to the new RSA"

Is this done in the replication?

Thanks

[JayGuillette]

Short answer is yes.

The Primary generates a unique private key when deployed, from a unique Self Signed Root CA that was generated when RSA created your company's AM license.  This Cert is primarily used as the console certificate, which is why your browser complains that it is an un-trusted, unknown CA Certificate Authority (because RSA is not a Certificate Authority like Verisign, Go Daddy, Comodo, etc...)  That same Root CA signs the Certs for all replicas deployed from this primary.

But these keys are not stored in the AM database, therefore they are not "replicated" through replication.  They are stored in .jks files local to the AM server, primary or replica.  so the replica has its key, but it got there through deployment not through replication.

Many customer replace the RSA self-signed Console Certificate with a cert signed either by their own internal CA or from a public CA.

000030016 - How to replace the RSA Authentication Manager 8.1 SP1 self-signed console certificate with a certificate th… 

You can also replace Virtual host Web Tier RSA self signed certificate in a similiar manner.

https://community.rsa.com/docs/DOC-64670  

A few customers copy the Root CA self signed certificate and import it into their browsers because they "trust" this certificate because they verified the SHA2 signature on the RSA software when they downloaded from RSA Link Download Central, and they installed the Primary, so they have 1st hand trust instead of asserted trust through a CA.