Problem Description
The Druva-EnterpriseWorkloads service terminates unexpectedly with Error 1067 on the secondary node (Node 2) of a SQL Server Failover Cluster Instance (FCI). Backups stop working entirely when the active role fails over to Node 2, leaving SQL databases unprotected.
Traceback
The following error is observed in the Enterprise Workloads agent logs on Node 2:
level=error ts=2026-04-10T17:32:44.5750379Z filename=configmgr.go:85 Module=ConfigManager method=NewConfigManager message="failed to load config file: failed to decrypt secure encrypt tag field [string] (Win32CryptUnprotectData): Failed to decrypt the data(decryptBytes): Key not valid for use in specified state.)"
Additionally, the service enters a loop attempting to list SQL jobs but fails with a decode error, and secondary network connectivity issues may appear (e.g., unable to reach devicemgmt-reverseproxy-dcp.druva.com).
Cause
The agent was not activated using the correct FCI cluster activation command. When the standard (non-FCI) activation is used, the agent encrypts its configuration file (config.yaml) using Windows DPAPI with a node-specific machine key. Since the config and lock files reside on a shared cluster drive (e.g., C:\ProgramData\Druva\EnterpriseWorkloads\mssql\), Node 2 cannot decrypt a config file that was encrypted by Node 1's machine key.
Specifically:
The
config.yamlwas missing theactivation_modeattribute (which should be set to1for FCI).The code flow was going through DPAPI decryption instead of cluster-mode decryption, confirming the FCI activation flag was not applied during initial setup.
Resolution
Perform a re-registration of the agent on both FCI nodes using the correct FCI cluster activation command:
Stop the Druva-EnterpriseWorkloads service on the active node.
Rename (back up) the existing config files:
Config.yamlMssqlPlugin.yml
Start the service.
Re-register Node 1 (primary) using the correct command:
EnterpriseWorkloadsAgent.exe mssql activate -t <token> --sql-fci-cluster -kRepeat the re-registration on Node 2 (secondary).
⚠️ Important: Use --sql-fci-cluster as a single flag. Do not use --sql -fci-cluster (with a space), as this is treated as two separate flags and will not enable cluster-mode encryption.
Verification
To confirm that the resolution has applied successfully, execute a routine failover verification:
Open the Failover Cluster Manager.
Manually move the SQL Server FCI role from Node 1 to Node 2.
Confirm that the
Druva-EnterpriseWorkloadsservice shifts cleanly into aRunningstate on Node 2 without generating Error 1067.Trigger an ad-hoc backup from the Druva Cloud Console to verify successful communication and data transfer.
See also