000014241 - AM7.1:How to rebuild a Pre-SP2 replica installed in Windows 2003 Server after a replication failure

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 3Show Document
  • View in full screen mode

Article Content

Article Number000014241
Applies ToMicrosoft Windows Server 2003
RSA Authentication Manager 7.1
Replication failed
To perform this procedure services on the Primary will be stopped for a short period of time.
IssueHow to rebuild a replica installed in Windows 2003 Server after a replication failure
Resolution

Preparation for the cleanup and rebuilding:

There are certain patches that will be required later in this solution, one for the back-end database and once for the server. These downloads are large; it is helpful to download and check them first, so they will be available when required.   

If you have previously downloaded a copy of the Database patch installer, with files dated before 10/7/2009, download a copy of the updated installer. It is recommended to use the Download Central website for the database patch, please see A47708 for details.   It can also be download from the FTP site, but this is a large download, and the FTP site is slower than Download Central. If you still prefer to use FTP: 

 ftp.rsasecurity.com/support/Patches/AM/7.1/database/install-db-win32-x86.zip 32-bit

ftp.rsasecurity.com/support/Patches/AM/7.1/database/install-db-win64-AMD.zip 64-bit

ftp.rsasecurity.com/support/Patches/AM/7.1/database/readme.zip 

The Server patch is currently not available on Download Central, you will need to get it by FTP:

ftp.rsasecurity.com/support/Patches/AM/7.1/Auth_Mgr/Aug_28_2009/install-ippi-win32-x86.zip  (32 bit) 

 

ftp.rsasecurity.com/support/Patches/AM/7.1/Auth_Mgr/Aug_28_2009/install-ippi-win64-AMD.zip  (64 bit)

 

 

In some cases,  a SHA1 or MD5 checksum will be published for the patch files. If one is available, it is recommended to check the SHA1 or MD5 checksum of the download against published values, to verify they were not corrupted during transfer. Please see   A47810 to verify the SHA1SUM or A47982 to verify the MD5 checksums of the files.


1. (If Radius was set up on the Replica)

- Log in to Primary Security Console

- Navigate to RADIUS server -> Manage Existing

- Pick up the failed replica RADIUS server(s) and delete it/them.

2. If possible, uninstall the AM7.1 software from the failed Replica(s), while the functioning servers are running.  Reboot, and remove any RSA directories from the failed Replicas.

3. In the Operations Console on the Primary, Manage Instance Replication, Delete Replicas, select the failed Replica(s) and delete it/them.

4. On the Primary, run a backup using the backup utility in the Operations Console (Maintenance->Backups->Create Backup).

5. Install the Aug. 28th Server Patch on the Primary, it should have been downloaded and checked in the  Preparation section above.

 6. Repeat step 5 on any working Replicas.

 7. On the Primary, navigate to c:\Program Files\RSASecurity\RSAAuthenticationManager\utils (or wherever it is installed on your system) and run the following command:

rsautil setup-replication -a list

You will be prompted for the superadmin password to run all rsautil commands. Upon supplying the correct password the command will run.

 

8. If the failed Replica Installation is in the list, run the following command:

rsautil setup-replication -a remove-replica -n <name of replica to be removed>

 

9. On the Primary, run the following command:

rsautil setup-replication -a remove-unreg-replicas

10. On the Primary, run another backup using the backup utility in the Operations Console (Maintenance->Backups->Create Backup).

11. On the Primary, change directory to c:\Program Files\RSASecurity\RSAAuthenticationManager\utils

 

12. ***NOTE: Steps 12 applies ONLY if there are no working replicas. If you have any working replicas skip step 12.***

Issue the following commands:

rsautil setup-replication -a remove-primary

rsautil setup-replication -a set-primary

Confirm and answer Y to all questions

 ***NOTE: Steps 12 applies ONLY if there are no working replicas. If you have any working replicas skip step 12.***

 

13. On the Primary, change directory to c:\Program Files\RSASecurity\RSAAuthenticationManager\utils

14. Issue the following command:

rsautil manage-rep-error -a run-script -o cleanup_propagation.sql

 

15. Change directory to c:\Program Files\RSASecurity\RSAAuthenticationManager\server

 16. Restart Authentication Manager services on the Primary TWICE through Windows Services.  

 17. Once services have restarted, change directory to c:\Program Files\RSASecurity\RSAAuthenticationManager\db\admin\<instancename>\bdump

 18.  If any .trc files were created since the time of the last restart of services are larger than 3MB, then restart services again

 19. On the Primary, log into the Security Console and click the Setup->Instances menu. Verify that replication status is "Running"

 

20. On the Primary, run a backup using the backup utility in the Operations Console (Maintenance->Backups->Create Backup).

21. On the Primary, go to your \utils directory. Type:

sqlplus 

and check the version of Oracle installed. If the version displayed is 10.2.0.3.0, you will need to install the Oracle patch, if it is 10.2.0.4.0 you do not need to install the patch. If required, install the Database patch on the Primary. It should have been downloaded and checked in the  Preparation section above.  Run a backup when done.

22. repeat Step 21 on any functioning Replicas, one at a time. Run a backup of the Primary after patching each Replica.

 At this stage, consider installing the AM7.1-SP2 Patch on your Primary, and all functioning Replicas. RSA Security recommends using AM7.1 SP2 .  

SP2 includes significant fixes, including Replication fixes.   Once all existing server(s) are at the SP2 level, there is a new installer that can be used to natively install AM7.1 with the database patch and SP2, which saves a significant amount of effort.   Also, all future hotfixes will have SP2 as a prerequisite.

NON-SP2 INSTALL PATH   (this path will no longer work after 12/31/2009, but is being kept for reference)

23. Generate a new replica package and install the AM7.1 unpatched replica as per the Administration Guide. 

24. Install the database patch on the reinstalled Replica. It should have been downloaded and checked in the Preparation section above.   

25. Install the Server fix on the reinstalled Replica. It should have been downloaded and checked in the  Preparation section above .  

26. On the Primary, run a backup using the backup utility in the Operations Console (Maintenance->Backups->Create Backup). 

 

SP2 INSTALL PATH 

23. Download BOTH the SP2 upgrade patch, AND the SP2 Full Kit, from Download Central.  

24. Apply the SP2 Upgrade patch (not the full kit) to the Primary RSA AM7.1 server, as per the instructions. Check the Replication Status to verify Replication is working.    Repeat for any working Replicas, one at a time.

25.  Generate a new Replica Package. 

26.  Use the Replica Package And the AM7.1 SP2 full kit (not the upgrade patch) to install a new AM7.1 SP2 Replica, follow the installation instructions. 


If problems persist you may find it necessary to perform some sql to search for and remove the replica from certain tables in the database:

 

Note the semicolon at the ends of the commands below. This is not a typo. Should you forget to put the semicolon before attempting to execute the command, type '/' (without the quotes) at the prompt and then hit enter.


log on to SQL:

 

            Open a command prompt and navigate to the install directory (by default c:\Program Files\RSASecurity\RSAAuthenticationManager) and then to the \utils subdirectory.  Run the following command:  

rsautil manage-secrets ?a get com.rsa.db.root.password

 

This password will be used in the following command to log onto the SQL server

sqlplus sys/<password> as sysdba

 

SQL> select inst.id, inst.name from rsa_rep.ims_component_registry comp, rsa_rep.ims_instance inst where comp.instance_id = inst.id;

 

 

 

            Should see no rows related to problem replica.  If any are found, run the following:

SQL> delete  from rsa_rep.ims_component_registry where instance_id = <'Replica Inst ID'>;
(use single quotes to enclose id)

 

 

SQL> select * from rsa_rep.ims_instance_node_addresses;

  

 Should see no rows related to problem replica.  .  If any are found, run the following:
SQL> delete from rsa_rep.ims_instance_node_addresses where node_id = <'node id'>;
(use single quoutes to enclose node address id) 

 

 

SQL> select id, name from rsa_rep.ims_instance_node;

 

 Should see no rows related to problem replica.  .  If any are found, run the following:

SQL> delete from rsa_rep.ims_instance_node where id = <'node id'>;
(use single quotes to enclose node id)

 

 

            SQL> select name from rsa_rep.ims_instance; 

 

You should not see the problem Replica.  If any are found, run the following:
            SQL> delete from rsa_rep.ims_instance where name = <FQHN>; 
(
use single quotes to enclose fqhn)
 

  SQL>  commit;

SQL > exit

 

NotesNote: if using a AM7.1 SP2 system on Windows, Please see Primus How to clean up an RSA Authentication Manager primary  and reattach a replica after a replication failure (Windows 2003 Server)
For the same Solution for a Solaris system, See How to rebuild a pre-SP2 replica running in Solaris or RHEL4 after a replication failure
Legacy Article IDa46860

Attachments

    Outcomes