Environment
Novell Access Manager 3.1 Access Administration
Situation
The Access Manager 3.x ambkup/amrestore process leaves a migrated-to-different-hardware Primary AC believing it is the only member of the Tree, but from oriifinal and untouched Secondary AC's point of view, it still believes Primary is a member of the Tree as well as itself. However a dstrace will report a 625 communication error.
Steps to duplicate:
- Performed an ambackup
- Copied file to new workstation
- Downed original server
- Brought up a virtual server with same name/ip as the original, and installed the Admin Console. Then copied the backup file from the workstation, and ran amrestore following the PDF documentation.
Everything run with no errors, and communication between Access Manager components is fine ie. they can all talk to the newly installed primary Admin Console.
- However, under the Primary AC's Auditing | Troubleshooting | Configuration screen |"Other Known Device Manager Servers" does show the Secondary AC with a "Remove" button present. Unfortunately, the eDirectory replica ring on the Primary doesn't agree.
The restore process does not include the server object associated with the secondary AC.
Steps to duplicate:
- Performed an ambackup
- Copied file to new workstation
- Downed original server
- Brought up a virtual server with same name/ip as the original, and installed the Admin Console. Then copied the backup file from the workstation, and ran amrestore following the PDF documentation.
Everything run with no errors, and communication between Access Manager components is fine ie. they can all talk to the newly installed primary Admin Console.
- However, under the Primary AC's Auditing | Troubleshooting | Configuration screen |"Other Known Device Manager Servers" does show the Secondary AC with a "Remove" button present. Unfortunately, the eDirectory replica ring on the Primary doesn't agree.
The restore process does not include the server object associated with the secondary AC.
Resolution
There is no way to actually fix this issue via a code change. However, there are two ways (and possibly a third) to approach
this:
1) Promote the secondary to primary and install the new hardware as a
secondary. No configuration restore is needed.
2) Install the primary on new hardware as above. Restore the configuration.
Remove the secondary entry in trouble shooting. Re-install the secondary as a
secondary to the new primary.
or one option that is more complicated ...
3) Do an eDirectory backup for migration. Install primary on the new
hardware. Restore the full eDirectory backup. eDirectory has the ability to
move the entire database to new hardware. This mechanism will keep the same
eDirectory id's and the replication ring will stay intact.
The problem, in the case above, comes where we only backup configuration data. During a restore
there is no way to reproduce the eDirectory replication ring. By doing a full eDir backup, we can
overcome this. The following links give more details on how to backup eDir
- https://www.novell.com/documentation/edir88/edir88/data/a5sq6ju.html
- https://www.novell.com/documentation/edir88/edir88/data/agatd4y.html#agatd4y