Removing SCOM Management Groups from your dual, triple, quad-homed agents!!!


I was recently working with a customer in the process of doing an upgrade from 2007 r2 to 2012 SP1.  When we thought we started to dual home the 2K+ agents we just pushed, we really found that we had dual, triple, and even quadruple homed some of them.  This was very interesting as it seemed no one knew about the "ghost" MGs that other teams had stood up. Through all the torch changes between the administrators they were never uninstalled.  Well time to get down to business, so we started to do some research and found Bob's blog on how to Remove a Management Group.

Problem here was that we had multiple MGs, so we decided to modify it to where it would do a loop through all MGs that didn't match the one I wanted the agent to report to. The Script is below and you just need to change the "SCOM2012Lab" portion to the Management Group you want to keep(Update...I removed the (Call objMSConfig.ReloadConfiguration) as I found that it would stop the agent.  Added some syntax from Kevin Holman to do a out of bad agent restart = .bat file) In my testing it took around 2-2 1/2 mins for the agent to restart:

Option Explicit
'On Error Resume Next

'Create COM object to get MGs
Dim objMSConfig
Set objMSConfig = CreateObject("AgentConfigManager.MgmtSvcCfg")

'Get management groups
Dim AllMGs, MG
Set AllMGs = objMSConfig.GetManagementGroups()

Dim objFSO, objFile, strDirectory, strFile, RSFile, strServiceName, objWMIService, colListofServices, objService, sFilePath
strDirectory = "c:\Temp"
strFile = "\MGOutput.txt"
RSFile = "\RestartHS.bat"
strServiceName = "HealthService"

Dim objSFSO 'As FileSystemObject
Dim objTextFile 'As Object
Dim oShell
Set oShell = CreateObject( "WScript.Shell" )

'MGOutput File
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.CreateTextFile(strDirectory & strFile)

'Restart File
sFilePath=strDirectory & RSFile
Set objSFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objSFSO.CreateTextFile(sFilePath, True)
objTextFile.Write ("net stop Healthservice && net start Healthservice")
objTextFile.Close

'Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
'Set colListOfServices = objWMIService.ExecQuery ("Select * from Win32_Service Where Name ='" & strServiceName & "'")
   

If AllMGs.count = 1 Then
 objFile.WriteLine ("There is only 1 Management Group on your server ")
Else
 For each MG in AllMGs
  'Remove management group(s)
  If MG.ManagementGroupName <> "SCOM2012Lab" Then
   Call objMSConfig.RemoveManagementGroup(MG.ManagementGroupName)
   If Err.number <> 0 Then
    objFile.WriteLine ("Failed to remove " + MG.ManagementGroupName + " from server")
   Else
    objFile.WriteLine ("Management Group " + MG.ManagementGroupName + " has been removed")
    'Call objMSConfig.ReloadConfiguration
 oShell.run sFilePath
 End If
  Else
   objFile.WriteLine ("Management Group " + MG.ManagementGroupName + " was recorded but not removed")
  End If
 Next
End If

objFile.Close

I always like to copy this to an agent to test it out first to view the output before I create a rule in my "good" management group. To do this enter the above code into a text file and save as RemoveMG.vbs.  Next you will most likely need to execute from Admin command prompt. If you do get an error try changing the output location to a folder that you will have access to.  Once you have tested this it is time to create the rule.

First thing first we need to open the SCOM console -> Authoring -> Rules and create a new rule under the Windows Server XXXX Computer for each respective version you have (i.e. 2003, 2008, 2012)

You will need to enter a name for the rule that makes sense to you.  Once you do this make sure that you select an appropriate Management Pack to store it in as well and the check box for enabled is NOT checked.

Next you will need to enter a schedule and in the customers case we needed the rule to run every 4 hours just to make sure that other Management Groups configuration wasn't deployed to our agent:
We now need to enter in the .vbs script above for our script the rule will execute:

Now that we have this created we just need to enable when you are ready to remove the other MGs. Yea! 


We did it successful migration!

Wait, What is going one?  The boxes are not going gray in 2007 instance or other instances!  The reason behind this the config seems to be cached on the agents.  So we also wrote a PowerShell script to go out to all agents we want(you control this from the top of the script) and it goes out stops the SCOM service, renames the Health Service State folder and restarts the service.  Once this has been completed you will start to see the agents in your other("bad, old", whatever you prefer to call it) MGs go gray.  Once they do you can simply delete from those respective consoles.

The restart PowerShell script:

Import-Module OperationsManager
$agents =
Get-SCOMAgent | ? {$_.version -lt '7.1'} | ? {$_.version -gt '6.5'}
foreach ($agent in $agents)
                       
{
    $strcomputer =$agent.name
    $path = "\\$strComputer\c$\ProgramFiles\System Center Operations Manager\Agent\Health Service State_OLD"
    $hsPath = "\\$strComputer\c$\ProgramFiles\System Center Operations Manager\Agent\Health Service State"
    $newName = "Health Service State_OLD"
    $service = Get-Service -ComputerName $strcomputer -Name"HealthService" 

    $strcomputer
    Stop-Service -InputObject $service -Force
    if(Test-Path -Path $path )       
     {
          Remove-Item -Path $path -Recurse
          Rename-Item $hsPath $newName       
     }      
    else
     {
          Rename-Item $hsPath $newName       
     }
Start-Service -InputObject $Service
}

Now I just run this as a user that will have permissions to touch all machines and in PowerShell ISE on one of the mgmt. servers.  If you are working with SCOM 2012 R2 agents you will need to update the $Path & $hsPath as they change in the SCOM 2012 version.  This is the reason that I am limiting the Agent lookup to versions 6.5 - 7.1.  Once you do run this you will start to see an output in the results screen very similar to below:

Good Luck and I hope this saves you LOTS of time and heartache! 

 

Disclaimer:

This example is provided “AS IS” with no warranty expressed or implied. Run at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.

**Always test in your lab first**  Do this at your own risk!! The author will not be held responsible for any damage you incur when making these changes!

 

Comments (6)

  1. Anonymous says:

    These scripts certainly saved me a great deal of time. Thank you for posting!

  2. John Bradshaw says:

    Very nice....Works like a charm!
    Thx

  3. Anonymous says:

    task

  4. John Bradshaw says:

    Hi Matt,
    I've just tried to run this on a separate Management Group for a different domain than I did before and nothing seems to happen. Is there a way to check why the Rule is not working? (On any individual client box in this domain it runs fine and cleans up the
    MGs).
    Thx,
    John Bradshaw

  5. John Bradshaw says:

    Oh, the MG is 2012r2

  6. EricGS says:

    Running this against a Group it correctly removed all the old Management Groups, but left the service stopped on all the servers in the group. I note it creates a batch file to stop and start the service, but this never seems to get called.

Skip to main content