Veeam Error: Agent failed to process method {DataTransfer.SyncDisk}

The other night I had my Veeam box decide it was not going to backup my VM’s.  This, naturally, is unacceptable behavior!  The error I was getting was the following (I cut out all the junk from my environment):

Processing <VMName> Error: An unexpected network error occurred. Failed to write data to the file <StorageUNC>.vbk]. Failed to download disk. Shared memory connection was closed. Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.

Before you jump to the obvious, there were no network related issues.  I did some digging and I found the solution!  I apologize to the random blog that I found the solution from, I have since closed the tab and lost the link.  Anywho, the following directory needs to be empty:

C:\Windows\TEMP\vmware-SYSTEM

I had a log file left in the directory.  Cleared it out, bounced the box (because why not?), and kicked off a backup of all my VM’s which completed without issue.

Kaspersky Security Center Failing “Backup of Administration Server data” task

Today I realized that the backups for my Kaspersky Security Center (Version: 10.4.343) were not completing successfully.  They were failing with the following error:

“Unknown error: System error 0x5 (Access is denied.)”

A little bit of background, I have one master Kaspersky Security Center administration server and a few slave servers off of that (for different customers).  Each are running on Server 2012R2 and have their DB’s on separate 2012R2 boxes using SQL 2012.   I also use a domain service account to run the Administration Service on the servers hosting the Security Center as I have had some issues with the built in account it generates during installation in the past.

Honestly, it is kind of silly that this took me about an hour to figure out but I’m going to blame that on my caffeine not kicking in fast enough.  At first I figured the issue was that I did not explicitly delegate permissions to the service account running that admin service to the file share that I was saving the backup to.  Strike one, no dice.   After some deliberating with myself and those in the room I finally woke up and realized it’s a backup of the database.  The database, as I said earlier, is on a separate box with an installation of SQL 2012.  SQL uses a built in account to perform all of its actions named NT Service\MSSQLSERVER.  Naturally I cannot grant permissions to this account on my remote share since it is a local account, and granting permissions to the computer account didn’t work unfortunately (strike two).  After all this, the solution was right in front of my face.  The share the backup is saving to needs to be on the same box as the DB.  Once I reconfigured to meet those requirements backups started flowing like Niagra Falls.

All in all, I had a pretty bad brain fart when setting up my backup tasks.  Oops!