wlittle

While it may seem extreme, it was the only solution that we found. To clarify what I said earlier, we found that the issue lies within the .NET framework folder - the folder simply becomes too large once MB is installed. When we removed MB from our first server and moved it to the second, we did need to rebuild the first server. We could have likely cleaned up the .NET framework folder, but the dependencies for what was contained within those folders was unknown. We decided for the sake of a stable environment that a rebuild was necessary. Again, I wish that I had a less extreme solution to offer, but this is what we did that worked for us. See if there is anything you can do with your .NET framework folder, and check your server's error logs as they will tell you exactly what file/folder it's getting stuck on. This is how we managed to figure out that our .NET framework folder was the issue.

Wow, thank you! I will remember this for the future. I was not aware of the available fix. I was not successful in removing the temporary files, but if I ever run into this issue again I will certainly remember the available fix. Thank you again.

Hello SiFinn, I work with Sabastasio, and unfortunately our solution was to have the Malwarebytes Management Console on a separate server. We discovered that the issue was related to directory limitations within the backup solution - a directory path became too long for the backup solution to handle (too many folders inside of folders) as a result of running 2 or more versions of SQL. We attempted to change settings, move folders around, etc. without success. The only option that we found was to spin up a second WS2012R2 server dedicated to running the Malware Bytes management console. This was the only solution that worked for us. Once we did this (and removed the Malware Bytes console/SQL 2012 from the first server) our backups succeeded on both servers. I wish I had more of an easier fix for you.