Wanda, Our situation is not exactly like you described, but we do support backups of remote servers on eight campuses around the state. We don't have login rights to any client servers.
We have a third-party TSM monitoring application that sends an e-mail to the client admin and opens a ticket in our ticketing system when a backup is mssed or fails. The monitoring application also sends a daily report to all client admins showing the status of their clients; successful, missed, failed, not scheduled, etc.. It's a great report. Nevertheless, we have the same problem. I don't think technology can solve it. Client admins have no qualms about ignoring canned messages, from wherever. Some even filter them from their InBox. My tactic is to escalate after a few days of misses or failures by calling an admin on the phone. It's more persuasive than e-mail. If the problem is long standing, and an admin is close by, I make a house call. These measures usually lead to a solution. If not, I take out Thor's Hammer and remove a client from the schedule when it has missed its backup several days in a row. I notify the admin(s) by e-mail, and voila!, he or she suddenly fixes the problem. It's magical. I have the support of my manager and my director in doing this. We're at the mercy of failed backups because they are usually Windows servers that had a bad systemstate backup, but a good data backup. So, we can't justify taking them off the schedule. There seem to be an indefinite number of ways a Windows server can fail a systemstate backup. Many admins aren't concerned about bad systemstate backups, and few client admins can or will read dsmerror.log. So we have them send it to us. We find the error, send them the solution and hope. We can't login to their server and fix it ourselves so we don't have much leverage. Failed backups, fail forever, but missed backups come and go. So, we age the problem for missed backups. Wait a day and it'll be working again. Not always, but often. Best wishes, Keith Arbogast Indiana University .
