Kaseya Community

Windows Server Backup Monitoring

  • I've been trying to find a quicker way to check backups of clients that are using Windows Server Backup rather than have to remote into each machine, so I decided to create a way to do it within Kaseya. Here's what I came up with.

    I have an alert that checks events under Windows Backup logs. When any Windows Backup event is detected, it runs a procedure that drops the event descriptions into the custom fields that I have displayed in this view. In the beginning, I only had one field (WSB_Status) that the procedure would update. It would update any time there was a WSB event. I was thinking that if a failure would occur, that would be the last event and I would see it in this view.

    However I quickly learned, that quite frequently, WSB will still generate a "Backup Successul" log entry after it completes, even when there's an error. This would cause the column to update as such and a failure would go un-noticed.

    To remedy this, I also created a WSB_Error field/column. The procedure would still update WSB_Status on every event as before, but in addition to that it would also update WSB_Error ONLY if the event type was anything other than "Informational."

    Here is the procedure in its current state.

    Each machine also has a procedure scheduled for the evening that resets all of these fields to blank so that I know I'm getting fresh results when backups start at night.

    In the picture above, you can see one instance where an error occurred and I was able to see it even though a "Successful" event occurred and updated "WSB_Status" with that after it ended. At this point I thought I had it licked and started to use this for my Windows Backup monitoring. However just recently it was brought to my attention that a client's backups were failing--backups that I have been checking as successful with no errors in this view. In this case, it was a failing external drive and going through the event logs there were definitely errors that the Kaseya's monitoring should have picked up, yet my WSB_Error field wasn't getting updated.

    I manually remoted into each server that uses WSB today and found a couple more that have been failing for a while that I've been passing off as successful because the fields were not being updated. WHOOPS!

    Looking manually at the machine's event logs, I am seeing that the "Error" event and the "Completed" event are being generated at the exact same time down to the second. I'm thinking this is the culprit. The "Completed" event is generated last. My guess is since they are generated at the same time, Kaseya is only picking on the "Completed" one, passing that to the updater procedure, and ignoring the "Error" event because of the rapid log generation.

    Can anyone confirm this? If so, are there any work-arounds that I can try?

  • Hi smmsp,

    This is exactly what I'm looking for.

    Are you able to help me set it up (I've never created an agent procedure before) and just tried via your screenshot, however it always wants to give me current_state after system info.

    Thanks in advanced.

    Kind Regards

    Wesley

  • I'm adding the event log alert setting here as well. Assign Event Set and Set Alert Actions.



    Formatting
    [edited by: smmsp at 9:37 AM (GMT -7) on Jun 12, 2017]
  • I go about this slightly differently. I have Kaseya kick off a Powershell script which initiates the backup instead of scheduling them through WSB. In the script I check to see if the expected backup drive is available. If not, it writes an event to the Event Log using my own Event Number and emails me. If it is then it performs a backup. A successful backup writes an event to the Event Log using my own Event Number and then does a test restore. A successful test restore writes an event to the Event Log - again, with a. A failed backup or restore also writes an event to The Event Log - again using my own numbers so I can easily monitor for the events with Kaseya. I can also monitor for none of my event numbers which would mean that, for some reason, the backup did not run.