A few days ago I was troubleshooting a problem with an ISA array after upgrading the VMware environment as you can read in this article. I had a same kind of problem with a RSA environment. After upgrading the VMware Tools and the Virtual Hardware, the RSA database didn’t start anymore. RSA noticed to much changes on the guest host, so we had to revert back to the “old” virtual machine.
To upgrade the VMware Tools and the Virtual Hardware I had to install a new server and restore the RSA primary database on the new server. The process for restoring the primary database can also be found in the RSA Administrator’s Guide.
There are two methods to restore the primary database:
I decided to use the first method, since we didn’t use a replica instance, and started installing a new server. I installed the new server under VMware. After the pre-installation I moved the server to another VLAN (port-group). I changed the hostname and the IP address of the new server to exactly the same hostname and IP address of the “live” RSA server. Next I installed a RSA AM7.1 SP2 primary instance with its default settings.
On the “live” RSA server I opened the RSA Operation Console to create a backup of the primary database (Maintenance – Backups – Create Backup).
The backup process creates 3 separate files. This files need to be copied to the newly installed server. The *.dmp file is the file which contains the actual database configuration and is the most important. To restore the database on the new server, I had to take the following steps:
The above steps help you restore the RSA database, but you still need to restore the RADIUS configuration separately. To restore the RADIUS configuration you first need to backup the RADIUS configuration from the “live” server. Creating a backup of the RADIUS configuration is very straightforward. You just need to copy the directory %RSA_install_root%\radius. To restore the RADIUS configuration on the new server, I had to take the following steps;
The RADIUS server service is restarted automatically after executing the command above. After restoring the primary database and the RADIUS configuration you can shutdown the “live” server and change the network configuration (port-group assignment within VMware). The new server should be working directly. At least, it did for me.
If your configuration consists for one or more replica instances, you should perform the following steps for each replica instance:
If you use the On-Demand feature and you publish the RSA Self-Service portal via the reverse proxy solution, like a Microsoft ISA server, you should pay extra attention to the certificate chain configuration. The new server uses a different self-signed root certificate to sign the SSL certificate of the RSA Self-Service webpage. You need to import the new root certificate on the reverse proxy server and you should be ready to go.
Once I tried to restore the primary database with the second method (promoting replica to primary). This method wasn’t easy in my opinion and resulted in multiple error messages and an unsuccessful migration. I like the first method, because it is very straightforward and there isn’t a lot of downtime.
Some of our customers use eSafe as forwarding proxy for SMTP and HTTP scanning. Today I had to restore an eSafe, which is configured in NitroInspection II Router mode. I had created a backup configuration file from the running eSafe server and installed a new eSafe server with the default settings.
After the installation I connected my laptop to the eSafe server and opened the default browser page:
After logging in with the default username (admin) and password (esafe), I browsed to the backup configuration file and started restoring to this configuration. The eSafe appliance needs to reboot after the restore.
I know noticed that after the initial restore and reboot, the eSafe server lost the IP configuration from both NIC’s in the server. I had to restore the IP settings manually, which can be done by editing the following files:
I always forget the syntax when editing the networking files, so I had to search the internet for the correct syntax. Below the configuration of eth0.
After rebooting the network service (/etc/init.d/network restart) I was able to communicate with the eSafe server and everything looked normal, but it wasn’t. I noticed that the service eSafe wasn’t able to start.
Contacting eSafe resulted in re-installing the eSafe appliance from scratch. Manually configure the correct IP settings through the web interface and only restore the file /opt/eSafe/eSafeCR/esafecfg.ini. Next I rebooted the server and this time the configuration was restored and the service was running.
eSafes technical personnel told me that the problem could arise, when restoring the tar.gz file to different hardware, and that’s exactly what I tried.