locked
How to have SCOM automatically uninstall an agent when VM get's decommissioned RRS feed

  • Question

  • Hello,

    We are going to be using a system whereby virtual machines will be able to autoscale (new VM's built and when not needed VM's will be decommissioned).  As part of a new virtual machine build we have the MomAgent.msi to install the agent and point the agent/vm to our SCOM 2012 R2 Management Servers.  We then have our SCOM 2012 R2 management servers set to auto-approve agent install requests.  So far so good it's working well in our testing. With the agent installed and registered with our SCOM Management Servers we can have eyes on Up/Down of our Virtual Machines that all should be up. 

    Now I'm looking for solutions/script ideas perhaps on how to remove an agent when a virtual machine gets decommissioned.  When autoscaling determines that a virtual machine is not needed, it will automatically remove/decommission the virtual machine for us.  In this scenario we don't want to be alerted that a VM is down.  We need to have the agent on our SCOM Management Server(s) removed so alerting happens on that Virtual Machine. 

    I know I can uninstall an agent from a virtual machine before the decommission.  But I don't think this does anything to the SCOM Management Server would it? 

    Or do I need to initiate from the virtual machine itself a script that will connect/execute on our SCOM Management server the removal of a virtual machine so alerting doesn't occur?

    Thank you in advance for any advice/assistance you can provide. 

    Monday, February 22, 2016 5:36 PM

Answers

  • Hi,

    I faced the same problem recently and I have found an almost "ready to use" script, which I execute as part of the decommissioning process along with the removal of the agent. You are right that the removal of the agent has nothing to do with the object in the SCOM DB. So I used the script provided by David Allen on his page:

    SCOM 2012 R2 – Delete Agent using PowerShell

    The script has only one drawback, which is also seen from the comments below - it leaves some leftovers (mostly under Monitoring -> Windows Computers). So in order to remove those normally you have to run the following cmdlet:

    Remove-SCOMDisabledClassInstance

    This is also suggested by David Allen in the comments. The big problem with this cmdlet is that it has an interactive prompts, which cannot be disabled or worked around. No matter what do you do (-WarningAction SilentlyContinue, ErroAction, etc) you cannot get rid of this Warning dialog. So in order to sort this out you can use the following method:

    $MG.EntityObjects.DeleteDisabledObjects()

    Daniele Grandini wrote about this some years ago (credits to him also):

    "In fact, the cmdlet author didn’t follow powershell best practices implementing the Confirm common parameter to let the user bypass the confirmation question."

    How to schedule the Remove-SCOMDisabledClassInstance comdlet

    So in the end your "ready to use" version of the script will look like this:

    Param(
      [string]$ManagementServer,
      [string]$AgentFQDN
    )
    Import-Module OperationsManager
    [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager.Common") 
    [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager")
    
    try{
    
    $MGConnSetting = New-Object Microsoft.EnterpriseManagement.ManagementGroupConnectionSettings($ManagementServer) 
    $MG = New-Object Microsoft.EnterpriseManagement.ManagementGroup($MGConnSetting) 
    $Admin = $MG.Administration
    
    $agentManagedComputerType = [Microsoft.EnterpriseManagement.Administration.AgentManagedComputer]; 
    $genericListType = [System.Collections.Generic.List``1] 
    $genericList = $genericListType.MakeGenericType($agentManagedComputerType) 
    $agentList = new-object $genericList.FullName
    
    #Replace DNSHostName with FQDN of agent to be deleted. 
    #ComputerName is a SCOM management server to query 
    $agent = Get-SCOMAgent -DNSHostName $AgentFQDN -ComputerName $ManagementServer 
    $agentList.Add($agent);
    
    $genericReadOnlyCollectionType = [System.Collections.ObjectModel.ReadOnlyCollection``1] 
    $genericReadOnlyCollection = $genericReadOnlyCollectionType.MakeGenericType($agentManagedComputerType) 
    $agentReadOnlyCollection = new-object $genericReadOnlyCollection.FullName @(,$agentList);
    
    $admin.DeleteAgentManagedComputers($agentList)
    $MG.EntityObjects.DeleteDisabledObjects()
    }
     Catch {
    
    $host.SetShouldExit(100) 
    exit
          }

    So this script you need to execute along with every un-deployment you make and you will remove also the object of the respective VM from SCOM.

    Hope this helps. Regards,



    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)




    • Edited by Stoyan ChalakovMVP Tuesday, February 23, 2016 2:31 PM
    • Proposed as answer by Yan Li_ Friday, February 26, 2016 7:20 AM
    • Marked as answer by Yan Li_ Monday, March 7, 2016 9:12 AM
    Tuesday, February 23, 2016 2:18 PM

All replies

  • if you uninstall the  SCOM agent from VM  before decommissioning it. That will remove that from SCOM console too.

    If VM is decommissioned and SCOM agent is not uninstalled then only option left is to "delete" the agent from SCOM console.

    safest way is to run  the script on the VM before shutting it down to uninstall the SCOM agent.


    Thanks, S K Agrawal

    Tuesday, February 23, 2016 6:49 AM
  • It is highly recommend that you should develop a script to uninstall the manual installed SCOM aganet before the decommsion of VM such that SCOM no longer to monitor the decommision VM. Moreover, you should remove the entity in SCOM
    roger
    Tuesday, February 23, 2016 7:29 AM
  • Hi,

    Here's a script that should work:

    http://blogs.msdn.com/b/scshell/archive/2007/04/25/deleting-agents.aspx

    Thanks,

    Sam

    Tuesday, February 23, 2016 7:55 AM
  • Hi,

    I faced the same problem recently and I have found an almost "ready to use" script, which I execute as part of the decommissioning process along with the removal of the agent. You are right that the removal of the agent has nothing to do with the object in the SCOM DB. So I used the script provided by David Allen on his page:

    SCOM 2012 R2 – Delete Agent using PowerShell

    The script has only one drawback, which is also seen from the comments below - it leaves some leftovers (mostly under Monitoring -> Windows Computers). So in order to remove those normally you have to run the following cmdlet:

    Remove-SCOMDisabledClassInstance

    This is also suggested by David Allen in the comments. The big problem with this cmdlet is that it has an interactive prompts, which cannot be disabled or worked around. No matter what do you do (-WarningAction SilentlyContinue, ErroAction, etc) you cannot get rid of this Warning dialog. So in order to sort this out you can use the following method:

    $MG.EntityObjects.DeleteDisabledObjects()

    Daniele Grandini wrote about this some years ago (credits to him also):

    "In fact, the cmdlet author didn’t follow powershell best practices implementing the Confirm common parameter to let the user bypass the confirmation question."

    How to schedule the Remove-SCOMDisabledClassInstance comdlet

    So in the end your "ready to use" version of the script will look like this:

    Param(
      [string]$ManagementServer,
      [string]$AgentFQDN
    )
    Import-Module OperationsManager
    [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager.Common") 
    [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager")
    
    try{
    
    $MGConnSetting = New-Object Microsoft.EnterpriseManagement.ManagementGroupConnectionSettings($ManagementServer) 
    $MG = New-Object Microsoft.EnterpriseManagement.ManagementGroup($MGConnSetting) 
    $Admin = $MG.Administration
    
    $agentManagedComputerType = [Microsoft.EnterpriseManagement.Administration.AgentManagedComputer]; 
    $genericListType = [System.Collections.Generic.List``1] 
    $genericList = $genericListType.MakeGenericType($agentManagedComputerType) 
    $agentList = new-object $genericList.FullName
    
    #Replace DNSHostName with FQDN of agent to be deleted. 
    #ComputerName is a SCOM management server to query 
    $agent = Get-SCOMAgent -DNSHostName $AgentFQDN -ComputerName $ManagementServer 
    $agentList.Add($agent);
    
    $genericReadOnlyCollectionType = [System.Collections.ObjectModel.ReadOnlyCollection``1] 
    $genericReadOnlyCollection = $genericReadOnlyCollectionType.MakeGenericType($agentManagedComputerType) 
    $agentReadOnlyCollection = new-object $genericReadOnlyCollection.FullName @(,$agentList);
    
    $admin.DeleteAgentManagedComputers($agentList)
    $MG.EntityObjects.DeleteDisabledObjects()
    }
     Catch {
    
    $host.SetShouldExit(100) 
    exit
          }

    So this script you need to execute along with every un-deployment you make and you will remove also the object of the respective VM from SCOM.

    Hope this helps. Regards,



    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)




    • Edited by Stoyan ChalakovMVP Tuesday, February 23, 2016 2:31 PM
    • Proposed as answer by Yan Li_ Friday, February 26, 2016 7:20 AM
    • Marked as answer by Yan Li_ Monday, March 7, 2016 9:12 AM
    Tuesday, February 23, 2016 2:18 PM
  • Thank you very much Stoyan for taking the time to answer this post. A follow up question for you though so I can better understand what needs to be done.

    In my case I need to uninstall or remove the virtual machine being managed from the SCOM server...and I need to initiate that removal from the VM itself.  So to confirm using your script I would logon to the VM that I'm about to decommission and I would run your powershell script as follows:

    ./MyScript -ManagementServer "mgmtserver1.domain.com" -AgentFQDN "sever123.domain.com"

    I've created a file called removeagent.ps1.  I've copied your code into this script.  I'm opening up Powershell I Administrator Mode on the virtual machine I intend to decommission.  I try to execute the script and some red text flashes up to tell me that the Import-Module OperationsManager cannot be found...then my Powershell window closes immediately (only way to see the error was to put in a sleep command so I could pause the script).  

    So if I'm going to be executing this script from the virtual machine that is being decommissioned I'll need to have the OperationsManager modules loaded into Powershell first?  But these virtual machines I'm decommissioning are not Operations Manager Servers..they are just Windows Server 2012 servers used for various purposes (not SCOM)...so none of these servers will have the necessary modules installed. 

    I think I've misunderstood how to use your script Stoyan. 

    I need to be able to run this script from the VM I'm decomming so is there a solution to loading the necessary modules without installing SCOM on all my VM's?

    Thank you.


    • Edited by greavette Monday, March 14, 2016 1:25 PM
    Monday, March 14, 2016 1:14 PM
  • Hi,

    you cannot run the script from the VM you are decommissioning, you can run it only on server or client, where you have the SCOM PowerShell modules installed. They are installed together with the SCOM console.

    The script makes a connection to your SCOM Management Group, searches for the agent and removes it from the Management Group. It is intended to be run  during or after the decommissioning process took place and the agent is no longer operational. If you run the script prior to deprovisioning the virtual machine, the SCOM agent on the VM will contact its Primary Management Server and the agent will either appear under "Pending Management" or under the respective Management Server in the Administration\Agent Managed pane of the SCOM console.

    So in your case, after decommissioning the VM, simply run:

    removeagent.ps1 -ManagementServer "mgmtserver1.domain.com" -AgentFQDN "sever123.domain.com"

    and the agent should be gone.

    Back to the behavior you are facing:

    " I try to execute the script and some red text flashes up and the entire powershell window suddenly closes?  I've even opened up my Powershell ISE and it also immediately closes?  I've never seen Powershell do that before. " What account are you using to run the script? Can you make a screenshot of the errors (text in red)?

    This happens, because you don't have the SCOM PowerShell modules installed on the VM and you cannot import the module and load the assemblies.  In order to workaround this you'll have to trigger the script either on a SCOM Management Server or on a server, which has the console installed on it. 

    I personally execute it as a automation task at the end of the decommissioning process. I am doing a PS connection to a server, which has the console installed and am executing the script on it. Of course AgentFQDN is the FQDN of the VM that has been decommissioned.

    Hope this helps. Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)





    Monday, March 14, 2016 1:46 PM
  • Thank you very much Stoyan for responding to my question. I had hoped to be able to find a solution whereby I could remove the server from SCOM remotely (which is not an easy task I agree) and your excellent response makes total sense. 

    I will accept your answer as a good one in that hopefully someone else will find it useful.  For myself I will need to perhaps 'tweak' my solution as my problem is these virtual machines can and will be decommissioned at anytime and if we don't remove the agent from SCOM or at the very least put it in maintenance mode we'll get a false alert to a downed VM when in actual fact it was a planned decommission. 

    Thank you very much for taking the time to respond to my questions..

    Monday, March 14, 2016 1:59 PM
  • Hi,

    I have identified two separate scenarios in my case:

    - The VM is being shutdown from a portal by the customer and will not be used for particular time. After this it can still be powered on and used.

    In this case as part of the process  a script is being executed, which puts the VM in Maintenance Mode for the specific time frame (entered by the customer).

    - The VM is being completely decommissioned and is not used anymore.

    In this case, as part of the process I simply connect to a server with the console on it and execute the above mentioned script. I decided to go this way (is not the best one in every situation) as I wanted to bypass the procedure of uninstalling the agent from SCOM.

    Glad I could help. Don't hesitate to ask further if you have other questions.

    Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)

    Monday, March 14, 2016 2:12 PM
  • I used a similar script in SC orchestrator for this. With orchestrator's rest interface i'll trigger the runbook with the parameter of the server's fqdn that gets decommisioned. The trigger isn't run on the vm itself but the "cloud orchestrator" (cloudforms from redhat in my case).

    you can achieve this without SC orchestrator and just trigger the script directly on a host with SDK access to scom.


    Rob Korving
    http://jama00.wordpress.com/

    Monday, March 14, 2016 3:00 PM