Setting lockdown mode to enterprise or compliance fails on the secondary cluster of a NetBackup Flex Scale cluster on which disaster recovery is configured
This issue is applicable only to the secondary cluster of a NetBackup Flex Scale cluster on which disaster recovery is configured. On the secondary cluster, when the lockdown mode is set for the first time, it fails due to a bug. This leaves the system in such a state that all the successive attempts continue to fail unless at least one of the retention values (minimum retention or maximum retention) is changed.
Additionally, you may have to manually mark the relevant STU for on the NetBackup UI. Usually this is done automatically, but in some cases, manual action is needed. This happens because the API to update the storage server and STU from the Flex Scale cluster fails. You can refresh the storage server from the NetBackup primary server since it polls the attributes from storage server in Flex Scale cluster and gets the WORM attribute. However, there is no such polling for STU. Hence, any STU on such a storage server must be manually marked as WORM.
(IA-46555)
Workaround:
Retry setting the lockdown mode after changing at least one of the retention values (minimum retention or maximum retention). For example, if in the first attempt, the minimum retention was set to 1 days and maximum retention was set to 365 days, in the second attempt, set the minimum retention to 1 days and maximum retention to 366 days. For STU that needs to be WORM-enabled, mark the STU to from the NetBackup UI.