Hi, there
our customer have purchased new RSA AM 8.4, which will be setuped on VMware EXSi, but need migrate configuration from the old hardware appliance whose version is 8.1 SP2.
I am not sure whether the migration can be process and how to migrate
old AM 8.1 SP2 was configured with LDAP server to read user databases and some users configured Radius attribute to bind to ASA user group.
thank you so much.
I am not sure what your starting version is, there is no 8.1 SP2. However, what needs to be done is: upgrade current version to target version, then can do a backup current primary/restore to target primary, and that will get the entire configuration onto 8.4. Then can install new 8.4 replicas (do not set up 8.4 replicas before restore or they will be cut-off and need to be set up again).
Backup and restore is version specific, the source and target versions must match exactly or restore will fail.
None of these can be skipped:
....lets say current version is 8.1 sp1. [8.1.1.0.0]
8.1.1.0.0 - upgrade to 8.2.0.0.0
8.2.0.0.0 - upgrade to 8.2.1.0.0 (8.2.sp1)
8.2.1.0.0 - upgrade to 8.3.0.0.0
8.3.0.0.0 - upgrade to ***8.4.0.0.0
Now backup and restore to target 8.4.0.0.0.
***NOTE: 8.4 update is too large to upload via browser, so either choose the update source as NFS or Windows share,
or CD-ROM, and can go from 8.3.0.0.0 to 8.4.0.0.0. If you want to use a browser you need 8.3.0.6.0 first, as 8.3 patch 6 has a configuration parameter to allow unlimited browser uploads, so the larger upgrade 8.4.0.0.0 will install.
Alternatively, if you want to keep users and tokens and pins assigned, but don't mind re-configuring LDAP and any agents by hand on 8.4, you can skip all these patches, and just to an 'export users and tokens' from the source version, and import that to 8.4. If users are in LDAP build that connection in 8.4 first. Export/import users and tokens will bring all users and assigned authenticators and pins over, but you'd need to build out the rest of the config on 8.4 from scratch, and build the agents again (also clearing node secrets on the agents if they have them). If you have too many agents or other config, then patching and backup/restore is best.
A word of caution -- the export/import mechanism does keep token assignments, PINs, etc, but does NOT maintain admin assignments, User Groups, agents, and certain other associations. Read the admin guide and Security Console Help topic on import/export carefully.
This requires careful planning. I suggest treating the two things (upgrade, change to VM) as separate projects, or at least, as separate sub-projects within an overall plan.
Are you planning to keep the same hostnames and IP addresses for the deployment? That way you don't have to replace the sdconf.rec on all the agents, but you have to proceed carefully so you don't put two hosts with the same name/address on the network at the same time.
Another way to migrate to VMs is to build a VM at the same AM level as the existing system and add it as a replica. You can then promote it to primary and begin to replace the other hardware appliances with VM replicas. One you have all the replacements complete, update them.
There are still other choices to be made, trade-offs to consider. If this is starting to sound more complicated than you hoped, I recommend that you contact your RSA sales rep to discuss engaging RSA Professional Service to help you plan and implement these changes.
Hi, Edward & Steven
thank you for you guys replies first
let me introduce the current status simply:
the current version on hardware appliances are AM 8.1 SP1 P02
configured as RADIUS Server on CISCO ASA FW for anyconnect VPN usage
the new two AM VMs will have new hostnames and IP addresses, also will setup as primary and replica instance
because end user will not agree to do upgrade action on the product hardware appliances,
and now these two hardware appliances were already at Primary and Replica Instance status, so I can not build a new VM and add it as a replica
hence I want to setup new primary instance VM at the version 8.1 SP1 P02 and import new license, then restore configurations(backuped from hardware appliance) to it
then I upgrade this new VM to AM 8.4 step by step, and add another VM directly installed version AM 8.4 as replica at last. Is this plan OK????
or do you have any other suggestion? thank you.
------------------------------------------------------------------------------------------------------------
In addition, I have a question about configuration backup and restore:
Does LDAP users's RADIUS User Attribute also can be bakcuped and restored in the whole backup/restore action?
Yes, you can restore the backup to a different deployment (new servers) as long as the new primary is at the same version of AM (as you noted). Everything in the db and a few other things will be in the backup, so the RADIUS stuff should all be there. The replica from the old deployment will be automatically deleted from the new primary. You will need to issue a new sdconf.rec for any regular agents, and the RADIUS clients will have to be reconfigured with the new server addresses. If you've added your own console certs, they will need to be replaced since the hostname is changing. There are other things to consider; carefully read the console help topic "Restore from Backup" and the section of the same title in the Administrator's Guide for more.
There are articles here in Link, as well, that can help: Restore from Backup .
Good luck.
OK, thank you Steven.
I am not sure what your starting version is, there is no 8.1 SP2. However, what needs to be done is: upgrade current version to target version, then can do a backup current primary/restore to target primary, and that will get the entire configuration onto 8.4. Then can install new 8.4 replicas (do not set up 8.4 replicas before restore or they will be cut-off and need to be set up again).
Backup and restore is version specific, the source and target versions must match exactly or restore will fail.
None of these can be skipped:
....lets say current version is 8.1 sp1. [8.1.1.0.0]
8.1.1.0.0 - upgrade to 8.2.0.0.0
8.2.0.0.0 - upgrade to 8.2.1.0.0 (8.2.sp1)
8.2.1.0.0 - upgrade to 8.3.0.0.0
8.3.0.0.0 - upgrade to ***8.4.0.0.0
Now backup and restore to target 8.4.0.0.0.
***NOTE: 8.4 update is too large to upload via browser, so either choose the update source as NFS or Windows share,
or CD-ROM, and can go from 8.3.0.0.0 to 8.4.0.0.0. If you want to use a browser you need 8.3.0.6.0 first, as 8.3 patch 6 has a configuration parameter to allow unlimited browser uploads, so the larger upgrade 8.4.0.0.0 will install.
Alternatively, if you want to keep users and tokens and pins assigned, but don't mind re-configuring LDAP and any agents by hand on 8.4, you can skip all these patches, and just to an 'export users and tokens' from the source version, and import that to 8.4. If users are in LDAP build that connection in 8.4 first. Export/import users and tokens will bring all users and assigned authenticators and pins over, but you'd need to build out the rest of the config on 8.4 from scratch, and build the agents again (also clearing node secrets on the agents if they have them). If you have too many agents or other config, then patching and backup/restore is best.