Troubleshooting
Problem
After a database restore, the server starts correctly in the foreground, but all the client or administrator connections may fail with the errors below (see Symptom section).
Symptom
Message(s) at client side:
ANS1051I Invalid user id or password
Message(s) at server side:
ANR0150E Failed to open Admin XX. There was an error decrypting the Admin password.
ANR0435W Session 1 for node XX (WinNT) refused - internal error detected.
If the administrator try to update the admin or node password from the server foreground console it fails with:
ANR2017I Administrator SERVER_CONSOLE issued command: UPDATE ADMIN xx ?***?
ANR9999D_3855409967 secUpdatePassword(secpwd.c:393) Thread<178>: Unable to get key of type 3:256
ANR9999D Thread<178> issued message 9999 from:
ANR9999D Thread<178> 7ffdf8dd5697 OutDiagToCons()+167
ANR9999D Thread<178> 7ffdf8dcef12 outDiagfExt()+112
ANR9999D Thread<178> 7ffdf8b422ee secUpdatePassword()+13e
ANR9999D Thread<178> 7ffdf83b0e28 UpdateAdmin()+1178
ANR9999D Thread<178> 7ffdf83a2173 AdmUpdateAdmin()+413
ANR9999D Thread<178> 7ffdf8498d4d AdmUseExtCmdTab()+17bd
ANR9999D Thread<178> 7ffdf836a10a AdmCommandLocal()+57a
ANR9999D Thread<178> 7ffdf83695f4 admCommand()+1304
ANR9999D Thread<178> 7ffdf8b77ed7 SmExecuteCommand()+357
ANR9999D Thread<178> 7ffdf8b7845c SmLocalConsoleSession()+4ac
ANR9999D Thread<178> 7ffdf82d7e61 startThread()+141
ANR9999D Thread<178> 7ffe03b64f7f beginthreadex()+107
ANR9999D Thread<178> 7ffe03b65126 endthreadex()+192
ANR9999D Thread<178> 7ffe0dbb168d BaseThreadInitThunk()+d
ANR9999D Thread<178> 7ffe0e434629 RtlUserThreadStart()+1d
ANR9999D_1762506284 secUpdatePassword(secpwd.c:435) Thread<178>: Error 9999 updating password for admin 19
ANR9999D Thread<178> issued message 9999 from:
ANR9999D Thread<178> 7ffdf8dd5697 OutDiagToCons()+167
ANR9999D Thread<178> 7ffdf8dcef12 outDiagfExt()+112
ANR9999D Thread<178> 7ffdf8b4246d secUpdatePassword()+2bd
ANR9999D Thread<178> 7ffdf83b0e28 UpdateAdmin()+1178
ANR9999D Thread<178> 7ffdf83a2173 AdmUpdateAdmin()+413
ANR9999D Thread<178> 7ffdf8498d4d AdmUseExtCmdTab()+17bd
ANR9999D Thread<178> 7ffdf836a10a AdmCommandLocal()+57a
ANR9999D Thread<178> 7ffdf83695f4 admCommand()+1304
ANR9999D Thread<178> 7ffdf8b77ed7 SmExecuteCommand()+357
ANR9999D Thread<178> 7ffdf8b7845c SmLocalConsoleSession()+4ac
ANR9999D Thread<178> 7ffdf82d7e61 startThread()+141
ANR9999D Thread<178> 7ffe03b64f7f beginthreadex()+107
ANR9999D Thread<178> 7ffe03b65126 endthreadex()+192
ANR9999D Thread<178> 7ffe0dbb168d BaseThreadInitThunk()+d
ANR9999D Thread<178> 7ffe0e434629 RtlUserThreadStart()+1d
Cause
The Master Encryption Key was not restored.
Environment
IBM Spectrum Protect server at level 7.1.8+ or 8.1.2+ on all platforms.
Diagnosing The Problem
Check if the following message can be seen when the server starts in the foreground:
ANR2285S The server master encryption key cannot be read. Storage pool data and passwords encrypted with this key will be unavailable until the key is restored from a backup.
This message indicates that the master encryption key was not restored.
Resolving The Problem
Since IBM Spectrum Protect server release 7.1.8 and 8.1.2 or higher, it becomes mandatory to save the master encryption key generated by the server. The master encryption key is stored in the two files dsmkeydb.kdb and dsmkeydb.sth. The key is saved by the server via the PROTECTKEY / PASSWORD options of the BACKUP DB or SET DBRECOVERY commands.
This problem may happen if at BACKUP DB or SET DBRECOVERY time, the administrator of the server chooses to set the PROTECTKEY to NO. In that case he is responsible to save and restore the dsmkeydb.kdb and dsmkeydb.sth manually out of IBM Spectrum Protect's control.
The server issues a prompt like below if PROTECTKEY is set to NO to be sure the impact of the NO is well understood:
ANR2784W Specifying PROTECTKEYS=NO requires the server's encryption keys to be backed up manually.
Do you wish to proceed? (Yes (Y)/No (N))
If this problem happens after a DB restore, that means the key was probably not saved via the PROTECTKEY option. Contact the administrator of the server to get the needed dsmkeydb.kdb and dsmkeydb.sth files and copy them back to the server instance directory and restart the server.
Related Information
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg22014985