Daryl Hunter – Hubby, Daddy, Mentor, Friend

Just recently I upgraded one of my customers to Veeam Backup & Replication v5 and ran into some weird CLSID / Authentication errors.  I have many Veeam B&R v4.1 jobs that were working perfectly well, but immediately after the v5 upgrade, I started getting the following in my reports:

Well, that's annoying.  I know from experience when I see "80070005" that it's almost always (ALMOST always) authentication related.  I'm not familiar with the COM class ID.  I'm not familiar with the exact secret sauce of the Veeam Guest Agent (real-time install /uninstall during the Veeam job).  But I can see something is funky.

So, I start as usual – I check my Veeam job and make sure I'm using a useful user – and I'm using the DOMAINadministrator account – I'm quite positive this account has local admin rights, and appropriate log-on rights for any services.  But, just for fun, I create another user (cleverly named: Veeam) and give it all appropriate rights, including Veeam Backup box "Service" rights – restart services and retry.  Same error.  Bugger!

I notice this is a VSS issue so I disable VSS in my backup jobs, and they work fine without issue.  I re-enable VSS, and it gives the errors.

Looking closer, I notice that the CLSID is identical on all the jobs / warnings – so – I stop looking at the Guest VMs, and start focusing on the Veeam Backup box itself.  I finally realize I'm not making headway and gather log bundles and get Veeam Support in the mix and @benmilligan jumps into the case (Hooray!)  I've worked with Ben on a few other cases in the past, so I look forward to the chat again.  Ben jumps in (via Webex) and we start poking around and continue to see issues that are – well – wonky.

We try to re-register the Veeam Guest Agent service:

No change.  Hmm.  That's weird.  So, we take time to double check the CLSID just incase we're barking down the wrong tree.  Jump into regedit, and do a quick search for that GUID.

Sure enough – it's the Veeam VSS Guest Agent… see how the CLSID matches the error in our Veeam report?  But the permissions are right.  We know it's related to the VSS Guest Agent.

So, let's go back to DOMAINAdministrator for everything, restart the services, and take another trip to the backup logs:

Wait?  What the French Toast?  What are those SQL Errors?  The jobs are running – why are we having SQL Errors?  Huh?

Ben has a great idea to reset permissions to the Veeam SQL Database… So, let's fire up the SQL Surface Area Configuration:

We're going to re-add an Administrator (forcing permissions) for the Veeam database:

Great.  Click OK.  Restart Services and let's check the logs again.

Much better.   Now, just for fun – let's run a job…

And it works.  What in the world?  We just left Veeam alone for the weekend to make sure everything worked – and I can happily report it does.

Because he's full of awesome, Ben took time to lab this issue and came back with the following three key points:

• The original VeeamGuestAgentControl.exe /regserver action is the actual way to fix this.  That command worked as expected and resolved the actual COM object issue.
• But the database issue wouldn't let the Veeam VSS jobs run properly.  For whatever unknown reason, the Veeam 4.1 -> 5.0.1 uprade broke something with the Veeam Database authentication (the 80070005 error).
• Re-registering the COM object (#1) and fixing the DB Authentication (#2) fully resolved this issue.

So, there ya go.  Weird.  Hope this helps someone.