some outline information on migrating from AM 7.1 SP4 to AM 8.1
Agents do not need to be upgraded at the same time as you upgrade the Servers, so I would do basically what you said your plan was, “After the import we plan to shut down production RSA servers, both primary and secondary(s) and change their IPs to match the older 7.x server” with a minor variation: (more details below).
Deploy an AM 8.1 Primary (as a VMWare VM, physical RSA appliance or if running AM 8.1 SP1 as a Microsoft HyperV) with new name and IP - we can change this to match the AM 7.1 Primary name and IP address later
I recommend waiting to deploy an AM 8.1 replica though, you may run into problem trying to simultaneously migrate/import data into the AM 8.1 Primary while it is trying to replicate all changes to replica in real time
1. Create migration package with AM 7.1 export utility, optionally include logs if you want to run reports in 8.1 for data from the last 30 days (default) BUT it is simpler and less problematic to only migrate data and not logs. Migration Utility is in the extras folder from the 8.1 software
2. Import/Migrate the package file into AM 8.1 from the Operations Console
3. Shutdown AM 7.1 Primary - leave AM 7.1 replica up if you want users to still authenticate
4. Change the FQDN and IP of AM 8.1 to match old AM 7.1, from the AM 8.1 Operations console.
5. Open the Real Time Authentication Monitor on the AM 8.1 primary to verify it authenticates users
6. Stop at least the AM service on AM 7.1 Replica
7. Verify that your new AM 8.1 primary is authenticating
8. If necessary Uninstall your Trial license on AM 8.1 and import your Production license
9. shutdown the AM 7.1 replica
10. Deploy your AM 8.1 replica.
Regards, Jay
Your AM 7.1 Server must be running 7.1 SP4 or migration won’t work. Also a 7.1 migration will take any existing external Identity Sources (such as Active Directory) and configure them in AM 8.1
You can migrate from AM 7.1 SP4 to either AM 8.0 or AM 8.1 virtual appliance, but the licenses for these two are different from each other, and different from your AM 7.1 license. You will want to ‘upgrade’ your current 7.1 license so you can download an AM 8.1 license from the Secure Care Online Knowledge web site.
Basically you run a utility against your current AM 7.1 database, then decide if you can have a little down time for a cut-over or can have absolutely no downtime (Advanced) with AM 7.1 while you bring up your AM 8.1. Most customers do not need absolutely no downtime, considering you could reasonably run your AM 7.1 production while you setup your AM 8.1, and you could schedule 15minutes of downtime for a quick cutover.
Note: if your new AM 8 Primary has the same IP and name as the current production AM 7.1 server/appliance then obviously they cannot both be on the same network at the same time, but you can swap out the old for the new, and the agents continue to work without re-configuration. Build the New AM with a different name and IP and after shutting down the AM 7.1 Production, rename and re-IP the new AM 8.1 Primary – that way you do not need to do anything to the Agents.
An important step is the Migration Prep tool that will highlight potential problems that could happen during a migration, such as unsupported characters or too many extended attributes.
Authentication Manager 8.1 is a Virtual Appliance that runs on Suse Linux and is deployed into a Virtual infrastructure such as VMware ESX or VCloud. AM 8.1 is also available to run on your AM 7.1 Appliance Hardware. Note: avoid using IE8 with very large (168Mg) database migration files, but other versions of IE, or Chrome of Firefox work fine.
You can also migrate several times, in effect doing your migration over to see how it turns out. The second and later time is an overwrite, not an append.
First stop is Secure Care and click on the very large 8.X link on the main home page for various documents and videos.
Basic migration plan:
1. Pre-Migration – Migration Export Tool – You need Master Password. Choose Test or Production
2. deploy AM 8.0/8.1
3. If your AM 7.1 has external Identity Sources, they will be created during migration, but if you have AM 7.1 users in the internal database and want to migrate those users to an external Identity Source then first Setup AD as the external Identity Source for those users
4. Import from the 8.x Operations Console
a. If you are migrating users from an AM 7.1 internal database to a new external Identity Source, then the first name, last name
and username match AD exactly, migration will assign user token to the Identity in AD
b. Those users who do not match on those three attributes will be migrated into the AM 8.1 internal database with their tokens assigned
i. You would manually located each AD entry for each of these internal users
ii. Un-Assign token from user in internal database
iii. Assign token to user in AD
iv. Remove user from internal database
Other considerations:
1. Assign new tokens while still in 7.1, could save some time
2. Remove old tokens before migration, so you do not migrate old or expired tokens
