cancel
Showing results for 
Search instead for 
Did you mean: 

incorrect password EC8F1B8E EC8F17B7 EC8F03ED E7D10041 EBAb03F1

ges87
Level 5

When trying to run automated backup jobs, multiple clients are reporing this error. When this happens, usually the clients goes on reporting the same error at every attempt. Result: multiple clients are not backing up since months.

Activity log reports everytime 2 events. the first is an info event with error EC8F1B8E: cannot find the specified volume.

The second is an error event containing the remaining error codes, and the specifications:

-cannot enstablish connection to \\servername\sharename

-network password not correct

 

However the password specified IS indeed correct, infact the cleints in the past have backed up succesfully, and each clients is using a different user account with non-expiring password and explicit permissions for the right folder in the network share.

 

This is not the first time I get this kind of problem. Sometimes I got around it by changing the servername with the serverIP, however this also doesn't always work. And as more and more clients get affected, apparently randomly, unless I change all backup destinations I need to find an alternative way to solve this problem once and for all....

1 ACCEPTED SOLUTION

Accepted Solutions

I solved the problem by uninstalling from all affected server SSR2013R2, the agent, cleaning up any remaining file, registry key, removing all policies related to those server and the relative backup destinations, and then reinstalling everything. In test VM that had this problem, I instead just tried to upgrade SSR to V16 and that also solved the problem, without any need to reinstall or delete anything.

So it seems that it's exactly the upgrade of the agent that causes the problem...

View solution in original post

4 REPLIES 4

criley
Moderator
Moderator
Employee Accredited

@ges87

This sounds very similar to an issue that has already been reported to us. Did this problem start following an upgrade of the Management Solution?

more or less yes, little after upgrading to 2016. Clients still 2013R2

criley
Moderator
Moderator
Employee Accredited

@ges87

OK, the solution/workaround involved is not simple at all. We'll also need to review client-side logs to confirm it's the same issue.

Can you open a support case please? (provide case number here)

I solved the problem by uninstalling from all affected server SSR2013R2, the agent, cleaning up any remaining file, registry key, removing all policies related to those server and the relative backup destinations, and then reinstalling everything. In test VM that had this problem, I instead just tried to upgrade SSR to V16 and that also solved the problem, without any need to reinstall or delete anything.

So it seems that it's exactly the upgrade of the agent that causes the problem...