Delete a VM container object from the SCOM DB

[Stoyan Chalakov]

Hi all,

I am looking for a way to automate the deletion of VM Container objects (Veeam MP for Microsoft System Center, VMWare) in an automnated way. I have no prblems getting the VM object, belonging to the Veeam.Virt.Extensions.VMware.VMGUEST class, using PowerShell:

Code: Select all

Get-SCOMClassInstance -Class Veeam.Virt.Extensions.VMware.VMGUEST | where {$_.displayname -like "computername"}

The Problem is that there are no methods that allow the deletion fo this object.

How can I script the deletion of the VM Container object? Any help is much appreciated. Thanks in advance!

[sergey.g]

Hi Stoyan,

Why would you need to delete an object in SCOM? There is no such thing as object deletion in SCOM, you can just discover less items during next discovery cycle. To undiscover a VM you can overwrite Stage 2 - Virtual Machine discovery rule, there are parameters to not to discover VMs with specific keyword in their name, or VMs on a specific datastore or in a specific VM folder.



Let me know you exact use case, maybe I can provide more invormation.
Thanks.

[Stoyan Chalakov]

Privet Sergey,

I was most probably not clear enough. Let me try to explain you this in a better way.

A customer deploys a VM (from a Portal, deployment is automated) and the customer's VM gets monitored by SCOM. So when the customer decides that the VM is not needed anymore, as part of the undeployment process the SCOM Agent is removed (Remove-SCXAgent for Linux, for Windows using the script, mentioned here:

https://blog.pohn.ch/automating-the-sco ... owershell/

My Problem is that when the Agent is removed from SCOM I have a Veeam VM Container object left, which then alerts as unavailable and causes confusion.

So I Need to get rid of this VM Container object (class Veeam.Virt.Extensions.VMware.VMGUEST) at the time of the undeployment of the VM, the same way I do with the standard objects from class System.Computer.

So I could disable the disocvery for this particular VM Container object (using PowerShell), but then I will have to run Remove-SCOMDisabledClassInstance as part of the undeployment and this particular cmdlet (as described in the blog above) cannot be automated, because of its prompt.

Any ideas? Big thanks in advance.

BR,
STU

[Stoyan Chalakov]

Hey Sergey,

any ideas?

Regards

[sergey.g]

Hi Stoyan,

Sorry for a delay, but I had to doublecheck a couple of things.

Are you sure that the object that left is of "Veeam.Virt.Extensions.VMware.VMGUEST" class? This one should be removed when VM is gone from the vCenter environment even if it's not gone it should not alert. There is also VM to SCOM Agent relationship and it is created between a VM and a special object inside a Windows Computer object - it's of the "Veeam.Virt.Extensions.VMware.VMwareVirtualMachine" class. So, this object should be undiscovered when Windows Computer is gone, but since it's also "connected" to the VM via the VM2Agent discovery it could be still present and it could create issues.

The Vm2Agent discovery runs once a day to minimize performance load for Root Management Server Emulator. However there is a way to trigger it on demand with the corresponding SCOM task. I've created a sample script - it works like a charm in my lab. Could you try it in your environment after all undeployment steps are done?

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

I would appreciate your feedback regarding the class that is creating issues and regarding trying out the code above.
Thanks.

[Stoyan Chalakov]

Hi Sergey,

no worries, you guys (you and the colleagues from the support) already pointed me in the right direction, many thanks for that. The specific thing here was that I was initially kind of "mailman" so I had no possibility to check all the things on my own. So after the guys from the support asked whether the VM is present in vCenter and also about alert itself, I decided to take a closer look myself and found out that actually the VMs are gone both from vCenter and also the Veeam objects (class Veeam.Virt.Extensions.VMware.VMGUEST). So the only possible cause for the heartbeat alerts could be the System.Computer object. This was also the case. For some reason the object was still present in the DB and was the source of the alerts.
Still I find your findings and script highly interesting, as this could be additional factor influencing the removal of a VM. Big thanks, Sergey. I will deep-dive into the topic, test the script and let you know how it looks like.

Once again, many thanks for your time and efforts!

Stoyan

[Stoyan Chalakov]

Hi Sergey,

your script works like a charm. Once again "Many thanks" for all your efforts, you really helped me a lot

Regards,
Stoyan