Hi Community!

I have noticed a very critical step on the ManagedHost replacement. When re-adding a ManagedHost, the re-mapping window prompts on the final step. Occasionally, the window might not appear, is there a workaround to re-map the re-adding ManagedHost? Or at least re-do the step of "Add Host"?

I have done some lab testing based on the steps below.

Scenario/procedure:

1. Check database to record ID for managed hosts.
2. Remove host successfully.
3. Re-add host with the same IP, all steps passed.
4. Re-map windows DOES NOT pop up.
5. New managed host can be seen in "System and License Management".
6. Remove the newly added host again.
7. Alter database to remove the managed host with the newest ID that is not on the record.
8. Re-add host with the same IP.
9. Re-map windows pops up asking if it is the ORIGINAL managed host (instead of re-added managed host).

First observation on psql tables managedhost and serverhost.

Both tables showed result as expected on step 1 and 2.

However, on step 3, both tables automatically changed the values of the ManagedHost from its deleted status to active status BEFORE the appearance of remap prompt on web GUI. Which means, re-adding a ManagedHost DOES NOT write a new ManagedHost with a new id in both tables. But rather, it uses the same id of the deleted ManagedHost and rewrite both tables even BEFORE knowing whether the new ManagedHost needs remapping or not.

Here is the second observation,

During step 3, I have monitored the list of changes needed to deploy on web GUI in Admin tab, RIGHT BEFORE and AFTER I accepted the remap prompt. Note that the components that need to deploy CHANGED.

I then located deployment.xml on Console,

/opt/qradar/conf/deployment.xml

/store/configservices/backup/deployed/deployment.xml

/store/configservices/backup/deployed/GLOBALSET/deployment.xml

/store/configservices/backup/deployed/LOCALSET/deployment.xml

/store/configservices/backup/staging/deployment.xml

/store/configservices/deployed/deployment.xml

/store/configservices/deployed/GLOBALSET/deployment.xml

/store/configservices/deployed/LOCALSET/deployment.xml

New approach,

1. Backed up deployment.xml except the ones in directory /store/configservices/backup/.
2. Removed existing FP. DID NOT perform deploy changes.
3. Added new FP (not the same VM). Deliberately closed the window of System and License Management.
4. Monitored the progress in presence.log in new FP until "Done presence script".
5. Moved backup deployment.xml files to the corresponding directories in Console.
6. Performed full deployment. 1 out of 7 Timed out (EP, not the replaced FP).
7. Performed deploy changes. EP timed out again.
8. Performed a manual deployment on the timeout EP. Successful.
9. Performed deploy changes on web GUI again. All successful.
10. Checked log sources. 6 log sources point at FP, same as original settings. 3 out of 6 displayed real time events.
11. Performed simple healthcheck and did not find any outstanding issue. # drq, # ./cliniq and # systemctl --failed.

The new approach seems working fine on re-mapping. However, I am not sure if there is any hidden issue in the practice.
Please advise. Thank you!

Best regards,

Philip