The VB Application identified by the event source logged this Application UnityDisasterRecoveryBACKUP: Thread ID: 7560 ,Logged: Automatic backup failed - could not write to destination path: G:\
I get this whether I use a mapped drive or UNC. I have specified in the mapped drive to use another account. I believe the problem is that the server we are backing up to is not in the UNITY domain. This is a Standalone Unity sever for voice mail only. does the server that we backup to have to be in the same domain? It seems like that would be the only was you can be able to access a drive with an account on the unity server.
The first thing to understand is that error is being kicked back to me from Windows - DiRT has zero control over this and cannot somehow overcome this.
The next thing to try is making sure you can do a backup to a local drive - you didn't indicate if you'd try that but I assume it does. Can you confirm?
Then I need to know what version of DiRT and what version of Unity you're running.
Then you can try the "Two hop" backup method which was added for situations where the service running your SQL services is not able to write to the remote drive location (more often than not this is the pinch point). This option does the backup locally, then copies it remotely then removes the files on the local box. As long as the account running DiRt has write access to the remote location this should always work (i.e. the account associated with SQL does not come into play here).
I think the problem is with the account running DiRT. Currently that is Unityinstall. However, Unityinstall does not have access to the remote location. Since this is a stanalone Unity the remote server is not in the same domain. Therefore there is no local account that has access rights to that share. Is this the problem. I have received word that this was working before.
Not sure what you're hoping to hear from me... if the account doesn't have rights to the remote location, it doesn't have rights. If you are logged into the box as UnityInstall presumably copies to that share fail, too, right?
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...