Make sure that the HSM library installation path is exactly the same on the source and target machines. The third-party library must be placed in the same physical directory location on all source and target systems. Use an absolute path that meets the requirements listed in RFUTIL ROLL FORWARD qualifier.

To ensure replication target access, copy the .ks file for the HSM-enabled TDE keystore to replicas or hot standby databases. For example: 

cp /largedisk/lopez/lin64/125/hsm/orders/sports2020.ks chung@10.0.0.76:/largedisk/lopez/lin64/125/hsm/orders/

The HSM token ID should be visible to all databases. If the HSM is shared on a network location or particular to machines where the database resides, each database accessing the HSM sees the same token. If HSMs on source and target machines are separate, the security administrator must physically copy the HSM token from the source to the target machine when the HSM is enabled, much the same as the keystore must be physically copied when enabling HSM. OpenEdge functionality assumes that HSM commercial vendors provide administrative tools to back up (extract) an HSM token and restore (insert) it into the HSM.

Enabling HSM on a replication target or hot standby database relies on the AI roll-forward mechanism. To roll forward or replicate the AI file, the target database keystore file must be up-to-date. Certain database operations, such as enabling and disabling HSM, generate a new keystore file. To ensure propagation of keystore changes in a replication environment, follow the guidelines in Perform roll-forward recovery on encryption-enabled databases. To avoid errors, Progress recommends that the DBA archive and track all versions of the keystore file. If you encounter an error, see Troubleshoot HSM connections and configuration.