Hello,
We have a new SCOM environment which consists of 3 Management Servers. The VEEAM Management Pack has been installed the collector components are only installed on Management Server #3.
The health state of Management Servers #1 and #2 now show as critical and when you view the health explorer it's complaining that it's not able to access the 'Veeam VMWare' event log on these Servers; as you'd expect this is because the components are not installed there.
We have the 'Veeam VMWare Collector Resource Pool' defined and only Management Server #3 is a member of that pool.
Are we missing some other steps required to prevent this alert or should it simply be disabled using an override?
Grateful for any pointers on this one.
Pete
-
- Influencer
- Posts: 10
- Liked: never
- Joined: Jun 04, 2014 1:31 pm
- Full Name: Pete West
- Contact:
-
- Veteran
- Posts: 452
- Liked: 76 times
- Joined: May 02, 2012 1:49 pm
- Full Name: Sergey Goncharenko
- Contact:
Re: Failed accessing Veeam VMWare Event Log
Hi Pete,
Usually this is happening When you decommission a VM with SCOM agent inside. SCOM sometimes keeps the agent record for a while and even when VM is no there anymore, the relationship that we make between in-guest object and a VM keeps the VM object alive, this is when it just attaches to All management servers resource pool, which means to any available SCOM server.
To workaround the issue, you can perform topology rebuild process in our web UI and then launch on-demand discovery of VM2Agent relationship with the following script:
We are still investigating different processes which could cause an object to become orphaned and hopefully we can come up with better solution. We would highly appreciate if you can tell us how the process of VM decomissioning works in your environment - are you uninstalling the SCOM agent as a part of this process?
Let me know if the issue still exists even after on-demand relationship rediscovery.
Usually this is happening When you decommission a VM with SCOM agent inside. SCOM sometimes keeps the agent record for a while and even when VM is no there anymore, the relationship that we make between in-guest object and a VM keeps the VM object alive, this is when it just attaches to All management servers resource pool, which means to any available SCOM server.
To workaround the issue, you can perform topology rebuild process in our web UI and then launch on-demand discovery of VM2Agent relationship with the following script:
Code: Select all
$disc=get-scomdiscovery -name "veeam*VMware*VMContains*"
$RMS=get-scomclass -displayname "root*emulator" | get-scomclassinstance
$task=get-scomtask -displayname "*on demand*"
$discid=""+$disc.Id;
$Override=@{DiscoveryId=$discid}
Start-SCOMTask -Task $task -Instance $RMS -Override $Override
Let me know if the issue still exists even after on-demand relationship rediscovery.
-
- Influencer
- Posts: 10
- Liked: never
- Joined: Jun 04, 2014 1:31 pm
- Full Name: Pete West
- Contact:
Re: Failed accessing Veeam VMWare Event Log
Unfortunately this didn't work for us.
I actually had a ticket opened with support and the eventual fix was to create an empty event log on each of the Management Servers. It's a bit of a workaround but it suits our needs in this case.
I actually had a ticket opened with support and the eventual fix was to create an empty event log on each of the Management Servers. It's a bit of a workaround but it suits our needs in this case.
-
- Veteran
- Posts: 452
- Liked: 76 times
- Joined: May 02, 2012 1:49 pm
- Full Name: Sergey Goncharenko
- Contact:
Re: Failed accessing Veeam VMWare Event Log
Hi Pete,
Yes, this workaround should work, although we would still highly appreciate if you can help us understand what kind of objects is causing the issue in your environment. Could you try to run the following PowerShell script on one of your management servers? It will show you objects which are not managed by Veeam collectors and although for groups it's expected it is wrong for VMs for example. Could you send us the output?
https://drive.google.com/file/d/0BxwETG ... sp=sharing
Thanks.
Yes, this workaround should work, although we would still highly appreciate if you can help us understand what kind of objects is causing the issue in your environment. Could you try to run the following PowerShell script on one of your management servers? It will show you objects which are not managed by Veeam collectors and although for groups it's expected it is wrong for VMs for example. Could you send us the output?
https://drive.google.com/file/d/0BxwETG ... sp=sharing
Thanks.
Who is online
Users browsing this forum: No registered users and 3 guests