Unsolved
This post is more than 5 years old
132 Posts
0
2609
Updating DDBEA lockbox info with MSSQL admin GUI - supported?
Customer found a feature in the MSSQL Management GUI that appears to take care of adding and removing users for DDBEA in terms of putting their info into the lockbox - but after attempting to use it to change the DDboost user, a test backup we ran failed.
All of the "Data Domain side" steps for the new DDboost user were performed, and the actual "add user" feature did not throw any errors - but the backup job appeared to have issues accessing the Data Domain.
Also, side question - is the "config file" used for command line lockbox updating referenced at any time after it is used with the command line, or does it just serve to provide additional parameter input at the time the command is run?
All comments/feedback appreciated - thanks. (especially if anyone has actual instructions for changing or updating user/password information in DDBEA for SQL - they don't appear to exist anywhere)
connolly
132 Posts
0
February 22nd, 2018 12:00
No replies on this, and nothing found whatsoever relating to the process scenario for a customer needing to change the DDboost user password in the DDBEA setup.
No one has had to change credentials for DDBEA with SQL? Guess I'll have to log an SR to find out.
rugby01
85 Posts
0
February 22nd, 2018 13:00
This is not correct. you must use the ddbmadmin command, Networker, or eCDM. There is no native lockbox management in SQL as far I've seen.
connolly
132 Posts
0
February 22nd, 2018 13:00
I believe that there is now the "msagentadmin" command for the MS DDBEA operations - and there do appear to be plenty of options for the lockbox itself and its password.
But the only apparent options for the DDboost user and the DD is to "de-register" the entire system and then "re-register" it. That seems like a somewhat "drastic" course of action just to change a password.
Not to mention that when it looked like we had "guessed" what to do, we got an error that seemed to indicate there was a "connection still in use"; there may have been a "logical" connection in use, but we weren't trying to back anything up - and there's no info about what needs to be done to "break" any existing connections if that needs to be done.