We are using Authentication Manager 8.1. Would it be better to convert our appliance from a VMWare vm to a Hyper-V vm, or is it better to create a new appliance in Hyper-V instead?
Would anyone have any instructions on how to do either option?
Thanks in advance
T-Prime
Hi Edward,
Thanks for that info. What if I only have 1 server appliance? Would it be better to create a new instance of the RSA Authentication Manager in Hyper-V using the 8.1.1.0.0 version and then migrating the settings from 8.1 over to 8.1 sp1?
I’m looking for the best possible path with the least amount of user impact (and headache for IT) as possible to get this VM over to Hyper-V.
Terrence
Terrence Prime
System Administrator
Direct 803.744.1875
Fax 803.343.7017
Rogers Townsend & Thomas, PC
1221 Main Street 14th Floor
Columbia, SC 29201
Main 803.771.7900
Visit rtt-law.com<http://www.rtt-law.com/>
Hello,
you will not be able to set up an 8.1.1.0.0 replica to an 8.1 primary, nor can you migrate data from 8.1 to 8.1.1 such as restore a backup between different versions. Backup and restore is very version-specific... (In 8.4 we may relax this requirement, but for now it is version and patch specific until specified in our documentation that restore from different versions works). The best way would be as indicated: Make sure the current primary matches a version of Hyper-V base image, set up a Hyper-V replica, promote it. Now you have a primary in Hyper-V with all your data. And everyone is still authenticating to the original machine, so there is no outage. Now you can have time to deal with any IP address changes or name changes in the Hyper-V environment to make it as seamless as possible.
You could just set up a new Hyper-V Primary as 8.1.1.0.0 with just the initial admin accounts and no users, and then patch the current primary to 8.1.1.0.0, then make a backup of it and restore backup to the Hyper-V, that would work since source and target would be same 8.1.1.0.0 version.
Thanks, Edward. I'll look into setting that scenario up. Would there happen to be any documentation on creating a replica by chance?
To add to Edward Davis's suggestion, with a basic license you are allowed one primary and one replica so you can still stand up a second server to do the work he suggested. In addition, that basic license allows you not only a primary and replica in production, but also to create a primary/replica deployment in a lab environment for your upgrade and testing.
Regards,
Erica
Hi Erica,
That's good to know. So, I can begin creating the replica immediately without any impact on the primary appliance? Or does it require that I shutdown the appliance or stop any services at all? I've never created a replica for an RSA appliance and want to have as much info as I can get to make sure I minimize the impact on our production network as possible.
Thanks again for you input on this.
T-Prime
Primary keeps cranking along doing normal work when setting up a replica. The steps are in the help menu of the security console, and also the setup guide for Authentication Manager.
The base version of a replica must match the major version of the primary:
example, Primary might be 8.1.1.15.0 (8.1 sp1 patch 15) so the replica must start as 8.1.1.0.0, then once set up, can be patched with patch 15 to match the primary. A replica of base version 8.1.0.0.0 could not be set up against an 8.1.1.15.0 primary.
Or primary may be 8.3.0.4.0, replica the starts life as 8.3.0.0.0 and later can have patch 4 installed. A replica starting life as 8.2.1.0.0 would not be able to set up against an 8.3.0.4.0 primary.
Since Hyper-V support starts at 8.1.1.0.0, and Hyper-V does not exist in 8.1.0.0.0, your primary must be at least 8.1.1.0.0 to set up a new Hyper-V replica 8.1.1.0.0 to it.
If you are on 8.1.0.0.0, there is no version that can run on Hyper-V.
Hyper-V is only possible starting with 8.1.1.0.0 and up (8.1 sp1) which has a new full base installer for Hyper -V
8.1.0.0.0 vmware and hardware base installers, no Hyper-V
8.1.1.0.0 Hyper-V base installer, [vmware and hardware have patches to 8.1.1.0.0, no base installer]
8.2.0.0.0 base installers for all
8.2.1.0.0 base installers for all
8.3.0.0.0 base installers for all
Also, there is no reliable method of converting an already set-up machine to a new base platform, and we would not be able to support it. There are system fingerprints created on the first setup and the software is now tied to the machine is was installed on for security reasons. New installs on the target platform are always the path to take***.
***Hyper-V live migration or Vmware Vmotion is supported, but these do not change the system to the point of non work-ability.
---
The way to go about it would be:
Make sure the current servers are all at least 8.1.1.0.0 (8.1 sp1)
Deploy a new replica 8.1.1.0.0 into hyper-v. Later, promote for maintenance, so it becomes the new primary.
Then delete one of the replicas, and re-depoy a replica into Hyper -v. Using these or similar steps you can 'leapfrog' your way onto new platforms.
-----
In actual fact, the best and most reliable way to do it, would be get your current environment patched all the way up to 8.3.0.4.0 (8.3 patch 4) first.
Then deploy the new Hyper-V replica as base image 8.3.0.0.0, and then once set up and running, patch it to 8.3.0.4.0. Next, do the planned promotion steps and the Hyper-V becomes the primary, and the other primary demotes and becomes a replica....and you can now delete the unwanted replicas, and spin up new replicas into Hyper-V.