Backup Exec 15 after Update no communication with vCenter - all AVVI jobs fail

Is there an Event ID 1000 logged on the BE media server when the remote agent stops during the VM backup ?

Does restarting the remote agent service allow the backup to complete ?

Just to add to VJware's comment -  a VMware agent backup heavily uses the Remote Agent (beremote.exe) process on the Backup Exec Server. As such troublshooting when and why the Remote Agent is stopping could help understand why you cannot backup VMware resources.

Hi VJware thanks for your reply!

Yes event id 1000 ist logged with a reference to ..\backup exec\VMware\VixDisklib\bin\libcurl.dll.

Application error.

And NO - restarting the remote agent service does not help anyway. The job aborts suddenly. But other not-VAAI-based job remain running.

Full event log entry is:

- System

  - Provider

   [ Name]  Application Error
 
  - EventID 1000

   [ Qualifiers]  0
 
   Level 2
 
   Task 100
 
   Keywords 0x80000000000000
 
  - TimeCreated

   [ SystemTime]  2015-04-18T21:02:16.000000000Z
 
   EventRecordID 51869
 
   Channel Application
 
   Computer A650WAP0002.hbalan.ffm
 
   Security
 

- EventData

   beremote.exe
   14.2.1180.0
   54f9310e
   libcurl.dll
   0.0.0.0
   4fb54c60
   c0000409
   0000000000048ff3
   db0
   01d07a150adcc248
   C:\Program Files\Symantec\Backup Exec\beremote.exe
   C:\Program Files\Symantec\Backup Exec\VMware\VixDiskLib\bin\libcurl.dll
   30f5d3ed-e60e-11e4-80cb-000af70f9366
   

Before we installed BE 15 the BE 2014 ran without errors.

No changes at vCenter level occurred since BE install (in-place migration).
   

This indicates a service crash. Pls log a formal support case for us to analyze the crash dump.

I would be very grateful if you would share the final solution. I have having the exact same problem. I have logged a support case but would appreciate the extra feedback.

@JGrogan - If you have the same issue, i would strongly suggest to continue working with support. Having multiple cases of the same issue helps us to identify the issue quicker and have a fix as well.

Up to today the case is open and under investigation by Symantec.

Support first looks after a bunch full of unneeded tasks.

The question is. why is BE 15 not able to initiate a trusted communication
with our vCenter server after the update from 2014?

I found a workaround that may be helpful. Use at your own risk. We still have a BEX 2012 server in our environment so I grabbed the libcurl.dll from that server and replaced the one on the new server (after finding a safe place to keep a copy of the new DLL). My VMWare vmdk backups are now working. 

I also still have a case open with support and hope they find a better solution. I think the reason for using the newer version is due to all the SSL vunerabilities found in the past year. Using this older DLL is a risk. 

Best of luck!

Thanks for your update!

Yesterday I had the sane idea to change the DLL but due other impacts I were not able to realize it. At our customer location it´s the only BE server, but testing will be possible. In our case the problem is that we have backup our complete backupserver (with OS, BE, SQL, catalogs and 15TB dedup area) to realize an full backup yet. The painful story needs estimated 60h to get on LTO5. And meanwhile I allowed not to start any incremental backups, maybe they interfere or not.