Convert VMWare appliance to Hyper-V
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
- Auth Manager
- Authentication Manager
- Community Thread
- Forum Thread
- RSA Authentication Manager
- RSA SecurID
- RSA SecurID Access
If you are on 18.104.22.168.0, there is no version that can run on Hyper-V.
Hyper-V is only possible starting with 22.214.171.124.0 and up (8.1 sp1) which has a new full base installer for Hyper -V
126.96.36.199.0 vmware and hardware base installers, no Hyper-V
188.8.131.52.0 Hyper-V base installer, [vmware and hardware have patches to 184.108.40.206.0, no base installer]
220.127.116.11.0 base installers for all
18.104.22.168.0 base installers for all
22.214.171.124.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 126.96.36.199.0 (8.1 sp1)
Deploy a new replica 188.8.131.52.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 184.108.40.206.0 (8.3 patch 4) first.
Then deploy the new Hyper-V replica as base image 220.127.116.11.0, and then once set up and running, patch it to 18.104.22.168.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.
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 22.214.171.124.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.
Rogers Townsend & Thomas, PC
1221 Main Street 14th Floor
Columbia, SC 29201
you will not be able to set up an 126.96.36.199.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 188.8.131.52.0 with just the initial admin accounts and no users, and then patch the current primary to 184.108.40.206.0, then make a backup of it and restore backup to the Hyper-V, that would work since source and target would be same 220.127.116.11.0 version.
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.
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.
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 18.104.22.168.0 (8.1 sp1 patch 15) so the replica must start as 22.214.171.124.0, then once set up, can be patched with patch 15 to match the primary. A replica of base version 126.96.36.199.0 could not be set up against an 188.8.131.52.0 primary.
Or primary may be 184.108.40.206.0, replica the starts life as 220.127.116.11.0 and later can have patch 4 installed. A replica starting life as 18.104.22.168.0 would not be able to set up against an 22.214.171.124.0 primary.
Since Hyper-V support starts at 126.96.36.199.0, and Hyper-V does not exist in 188.8.131.52.0, your primary must be at least 184.108.40.206.0 to set up a new Hyper-V replica 220.127.116.11.0 to it.