Error 1326 Logon Failure When Attempting To Backup To Remote Server

Hi all:

We currently have a production server (prodserver) and backup server (backupserver) in the same domain, and I am attempting to backup dbs from the production box on to the backup box using the following:

backup database db to disk = '\backupservere$ackupdb.bak' with init

when executing from SSMS, I receive the following error:

Msg 3201, Level 16, State 1, Line 1
Cannot open backup device '\backupservere$ackupdb.bak' Operating system error 1326 (Logon failure: unknown user name or bad password)

Here's where the issue lies for me:


Both the production and backup box are running services under the same domain accounts, let's call it "domainsqlagent"

domainsqlagent has domain admin rights on backupserver and prodserver

I can login to both the production and backup servers using the domain account, map drives, hit administrative shares, drag and drop files, etc between the servers

If I use xp_cmdshell to try and simply move a file between prodserver and backupserver, I receive the above error as well. However, if I open an cmd window and execute the move command from DOS, it will successfully move.

There is a development server on the domain as well (devserver) using domainsqlagent to run the service accounts, and I can successfully backup databases from dev to prod, dev to backup, backup to dev, backup to prod, prod to dev, but NOT prod to backup
Finally, if I create a maintenance plan in SSMS, I cannot create a connection to the backup server (error reads the connection may not be configured correctly or you may not have the right permissions on this connection)

The backup server was changed to a different domain (domain2) before I arrived here, but has been switched back now, rebooted, service accounts changed via Configuration Manager, services restarted (and rebooted again for good measure).
Does SSMS use a different security context to create the connections to remote servers? From all my tests, the domainsqlagent account has all the correct rights and is working OK. Could this be a network issue? The network admin and I have been banging our heads against a wall for the past couple of days, so if anyone has seen something like this, I'd appreciate any help.


Thanks,

Craig