We have a Exchange cluster with 4 nodes.
Our Exchange cluster usually backs-up correctly, when the Avamar cluster resource is located at a certain cluster node, lets call it server_node_2.
We do have a domain name and IP address for this cluster resource and it seems to be fine, lets call it avamar_dag. Moving around the avamar_dag around the nodes also works well and I can always ping the avamar_dag, as long as the resource is up.
When for some reason (a server restart, for instance) the avamar_dag changes owner, the backup fails because it is expecting the service on the server_node_2. The error on Avamar logs explicitly tells that it fails because it can't connect to the service on the host server_node_2. The error is:
avexvss Error <0000>: Connecting to remote server server_node_2 failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
So when I move the avamar_dag back to server_node_2, next backup will run correctly.
Why is it pointing to the cluster node instead of the dag resource? It seems like a configuration issue but I couldn't figure out where it is.
Because, on the Avamar Administrator, we do have the cluster resource name configured as the client for Avamar Exchange backup, so managing backup and restore for the Exchange is always based on the avamar_dag name.
Solved! Go to Solution.
Don't know if you have the same option as I have but what we did:
we have exchange PROD over in the prod location
and then we have DR exchange servers that are always syncing
(I an not an excahange person just the person who does the backups and learns a few thing)
We backup the PASSIVE copy from the DR site.
restores seem to be the same as you are using exchange admin account to manage the restore back to the mail box, all my restores have gone pretty well using the passive copy,
We are able to perform backups and restores normally, no issues there. We also backup the passive copies.
We have 4 Exchange nodes and 4 mailstores (databases). Each server has an active copy of it's database and a passive copy of 2 others. This makes Exchange resilient to the failure of 2 servers.
Now, the cluster have the Avamar backup service as a resource that can be online at any of the servers. That works well. The problem is that the Avamar backup of the Exchange will only work if the cluster backup service is online at a specific server, and backup fails if the service is moved to other server.
It is the expected behavior of a cluster to move failing services to another node, which occurs if, for example, you reboot a server. This is the purpose of a cluster on the first place. Avamar should point to the DAG domain name or IP, so it would always work no matter what the owner node is. But until I move manually the Avamar service back to that specific server, Avamar Exchange backup will fail.
After contacting support, I got it sorted really fast. The tech support guy figured it out quickly and it was very nice.
It turns out that I needed a few flags on the avexvss.cmd file on the Avamar DAG folder, as well as on the nodes var folder.
On the DAG folder avexvss.cmd file :
(note: replace the clusternode name and IP with your own, one line for each cluster node)
On each node var folder avexvss.cmd file, place the same flags as above, except the "--federated" flag.
This worked for me and DAG backups now complete successfully when the Avamar cluster backup service switches node.