Not receiving syslog messages for event id 190

[JaySt]

i'd like to see if anyone is able to test or experience the same thing as i am.
I have VBR send syslog (TLS) to a syslog server. I filter some event ids, as they are noise, but alot is received for alot of actions in the VBR.
However, out of 20+ jobs, only 2 jobs currently send out event id 190 (backup job completion) and i can see only 2 messages in my syslog server with that instanceID (event id).

I have tested alot of things but it seems that VBR just does not send out 190 over syslog (eventviewer shows the event though) for all completions.

VBR is at the latest 12.3.2 build.

i also have a case open, 07791753

[david.domask]

Hi JaySt,

Thanks for sharing the case number and sorry to hear about the challenges. I've not heard of such issues previously and checking my lab, not seeing any missing 190's either, so probably best to continue with Support and see what they can identify.

Just to confirm though, these are all VMware jobs or it's other job types? Other job types will use different event IDs, so that may be the case. If it's all VMware ones though, then will need to wait and see what Support identifies.

[JaySt]

i've vmware and non-vmware jobs. But i'm focussing purely on the vmware ones, just on event id 190.
i'll continue with support.

can i ask a bit about your lab setup?
do you use TLS on port 6514 for sending?
Do you filter any events?

[david.domask]

Got it, let's see what Support can find.

For the lab I work in, no filtering, and not using TLS; really cannot say if that would be relevant as I think first it's prudent to figure out if the events are actually being sent and lost in transmission or if they're never being sent in the first place. If it is being lost in transmission, I could imagine an over-active network security system flagging the events, but that's just a guess.

[JaySt]

Got it.
We see the same behavior an problem during low and high activity. The issue is exclusively for evt 190 it seems. All others seem to come through. So that makes it less likely its being fired in the first place and suspect some specific circumstances to cause an specific issues with 190.
There seems to be no logging about specific events triggered or send, only some general entries show in backupmanager.log