Agent Management Pack – Making a SCOM Admin’s life a little easier

<!--[if lt IE 9]>


Comments (68)
  1. Bo Lucas says:

    Kevin, I am trying to seal this mp but keep getting XSD verification failed for management pack. The SchemaVersion is not declared. I have sealed mps I have exported from SCOM 2012 before, it requires the different exe, but this one is not working. Any thoughts?

    1. Bo Lucas says:

      Nevermind. I was in fact using the wrong mpseal. 😉

  2. ForMUKESH says:

    Kevin, It a very useful as a SCOM administrator. The only problem what i face that it not allowing to select multiple object to copy . I need to pass those missing software for any agent to the concern team so that they can install the missing software/Powershell module But unfortunately i am not able to copy and paste it. Please let me know if you can provide any workaround.
    I have 1000+ agent don’t have Powershell installed.

    Thanks for providing a very useful article,

    1. ForMUKESH says:

      I am able to pull those information through PowerShell.
      Once again thanks Kevin and Team for this article.

  3. Pete Aston says:

    Kevin, thanks very much for this management pack, it’s really useful! I’ve got hundreds of manually installed agents to update and this is making short work of it.

  4. Dean Sinnick says:

    Looking Forward to using this pack.
    It would be great if there was a way to schedule flush agents in bulk as part of a regular maintenance schedule. It was also be good to see a powershell management pack or repository in SCOM where you could build a custom library of scripts and target them against computers or groups.

    1. Kevin Holman says:

      You can schedule flushing agents if you want, just create a rule with a scheduler datasource and use the flush write action. That said – I do not recommend this as I do not see that to be needed. The only time you should have to flush the cache is when the ESE DB grows huge, or gets stuck/corrupt, which is pretty infrequent.

  5. Daniele says:

    Great stuff as usual. Why not hosting this on github to accpet community contribution?

  6. Kenneth Rappold says:

    Great contribution once again. Thank you!

  7. Michiel says:

    As always another great contribution.
    It would be nice to have a task to set proxy enabled and see this as a property. And the same for setting the agent remotely manageable.

  8. Michiel says:

    As always another great contribution.
    It would be nice to have a task to set proxy enabled on the agents and see this as a property. The same for remotely manageable.

    1. Kevin Holman says:

      Michiel – I added the remotely manageable and a task to be able to set this without editing SQL servers – in the latest revision. I disagree with proxy enabled – because I believe we should enable this as a default and be done with it:

  9. Maxim says:

    Thanks for MP. For server 2016 and Windows 10 OS version 6.3 incorrect.

    1. Kevin Holman says:

      Why is that “incorrect” ? That’s what the registry reports.

      1. Maxim says:

        Hello! You read HKLM “SOFTWARE\Microsoft\Windows NT\CurrentVersion”
        But In W10 and Server 2016 new registry key apply

        1. Kevin Holman says:

          Ok – good feedback. I updated to version .77 and switched this discvoery to powershell to better handle this situation. The numbers now align to the same way the built in OS version discovery works.


          1. Maxim says:

            Ok, thanks!

  10. rob1974 says:

    Nice and handy mp, but i think you should give a security warning as this can give operators way to much power.

    So I don’t like the run any ps command/restart any service/execute any software, imho they should be disabled by default.

    1. Kevin Holman says:

      Rob – I agree. However – I DO have a warning. did you not see this:

      Additionally – I have created two versions of this MP. One with everything above, and one without the “risky” tasks, like exposing the ability to execute any PowerShell, restart any service, and install any software from a share. If those are things you don’t ever want exposed in your SCOM environment – import the other MP. You can control who sees which tasks, but by default operators will see tasks.

      1. rob1974 says:

        I guess i didn’t read the last line 🙂

        1. JVD says:

          Furthermore you could always create a seperate security group in SCOM that excludes operators from using those risky tasks.

          1. rob1974 says:

            The whole point is, ppl tend to forget that after the import. So operators unexpectedly get admin powers. That’s where the biggest risk is imho.

  11. Manideep karnati says:

    Really great and useful stuff, before I implement this, i would like to know if there are any prerequisites for running powershell script? And what is the account that this task uses?

    1. Kevin Holman says:

      The prereq for a PowerShell script is PowerShell.

      The credentials tasks will run under is the same as any task in SCOM – console task runs as the console user, agent tasks run as the default agent action account (or runas account if specifically configured)

  12. Ian Blyth says:

    Great MP and I found a few old Management Groups that I cleared but one is proving difficult to remove. It is called SCOM12 MESSAGING DEPT. On the first try I received the following message.
    Failed to remove SCOM12
    So the task does not like spaces.
    After experimenting using double quotes seemed to get it work but
    Failed to remove SCOM12 MESSAGING DEPT
    Exit code 0
    This is an AD Integrated MG. Is that a problem for the task?

    1. Kevin Holman says:

      Yikes! I don’t know. I didn’t even know we allowed spaces in a management group name. I can probably fix the task to allow for that.

  13. Hi Kevin,

    would it be possible to add a task to configure a failover MS on an agent?
    If would be really useful to do this from this state view in the console.


    1. Kevin Holman says:

      I’m working on this.

  14. Hi Kevin. As always you work is incredible. It would be great to add a task that check the root cause of a grey agent (wmi, Ping, port check, etc) in one single task OR add a view that only show the grey agents with colums that check these information as you do with the versión of Powershell and agents. What you think?

    1. Kevin Holman says:

      I added a HealthService Watcher view.

      Root cause for grey agents is next to impossible. The grey agent is not communicating with SCOM. To know why from the server perspective would be very difficult.

      1. Matias says:

        Yeah but keep in mind that with the Powershell MP, you can track for example the port connection, WMI, FQDN, etc and this way reach a possible root cause. Am I right?

  15. Hi Kevin,

    ACS is a diffrent story and i don’t know how popular ACS is, but why not to add ACS agent and ACS Collector components detection like APM and enable these services restart tasks?

    thank you.

    1. and also it would be a good idea to see active thresholds on healthservice from this post

      1. Kevin Holman says:

        Active thresholds in place are derived from config which is derived from the management group config service. This is something I can easily pick up from the agent in a discovery.

    2. Kevin Holman says:

      My problem with discovery of ACS, is that so few customers use ACS, and we already discover the forwarder, and settings in another MP I wrote:

      I am hesitant to include more properties than absolutely needed – because the more properties a class has – the slower it returns data to the console.

  16. venkatesh says:

    We have recently built a new 2016 environment and have installed this MP to ease the administrative overhead. However, when I tried using the HealthService-Restart task, it failed citing health service is not present. Need to manually login to the server & restart the service. Any parameters which needs to be changed while running this task??

    1. staxkill says:

      Hi Kevin,
      we upgraded from RTM directly to UR3 (because of the cumulative UR) and the dll spotchecks for the agents, gateways etc. were fine.
      Nevertheless states your SCOM Management Pack for the gateway servers that they are still on 2016 RTM because the HealthService.dll won’t be updated with UR3 there (but it will with UR2 to 8.0.10949.0 according to So the file version is still 8.0.10918.0 (RTM) with release date 7/8/2016…

      I noticed the “Special case for bug in SCOM 2016 UR3 missing HealthService.dll patch” in the SCOM.Management.Server.Class.PowerShell.Properties.Discovery.ps1 where you use instead the MOMWsManModules.dll (used for the dll spotcheck in the UR3 step by step guide) in case the fileversion for the HealthService.dll is on UR2 (8.0.10949.0). After checking for both versions (UR2 + RTM) for the bug

      ($ServerURFileVersion -eq “8.0.10949.0” -or $ServerURFileVersion -eq “8.0.10918.0”)

      the SCOM Servers view states the correct Server UR Level for the gateways.

      Communication between gateways and agents/mgmtservers work correctly but wanted to mention and make sure that it is “expteced” and by design. I know it is quite complicated to check for all conditions because with UR2 HealthService.dll was updated and with UR3 MOMWsManModules.dll… so which file can be used that is universal…

      Kind Regards,

  17. staxkill says:

    Systems with PS 4/5 do not necessarily have HLKM\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine\PowerShellVersion but definitely have instead SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine\PowerShellVersion. Question how to merge that…
    That’s why the SCOM Agents view states on several systems “PS Installed” = false but “PS Ver” = 4.0/5.0/5.1 (you get this from $PSVersionTable).


    1. Kevin Holman says:

      What OS/Build version doesn’t have the key I am using? Everything in my lab has it. Trying to repro.

      1. staxkill says:

        I’ve seen this on some systems with Windows Server 2012 R2/6.3.9600.

        1. Kevin Holman says:

          I will update the discovery in the next version to just look for HLKM\SOFTWARE\Microsoft\PowerShell

  18. Hi Kevin,
    we have some Windows Server 2008 R2 how doesn´t run the “SCOM.Management.Server.Class.PowerShell.Properties.Discovery.ps1”
    Event ID 22406:
    “The PowerShell script failed with below exception

    System.Management.Automation.ParseException: Missing statement block in switch statement clause.
    At line:44 char:20
    + 7.1 <<<< .10226.0 {"2012 R2 RTM"}
    at System.Management.Automation.Parser.ReportException(Object targetObject, Type exceptionType, Token errToken, String resourceIdAndErrorId, Object[] args)
    at System.Management.Automation.Parser.SwitchClausesRule()
    at System.Management.Automation.Parser.SwitchStatementRule()
    at System.Management.Automation.Parser.StatementRule()
    at System.Management.Automation.Parser.StatementListRule(Token start)
    at System.Management.Automation.Parser.ScriptBlockRule(String name, Boolean requireBrace, Boolean isFilter, ParameterDeclarationNode parameterDeclaration, List`1 functionComments, List`1 parameterComments)
    at System.Management.Automation.Parser.FunctionDeclarationRule()
    at System.Management.Automation.Parser.StatementRule()
    at System.Management.Automation.Parser.StatementListRule(Token start)
    at System.Management.Automation.Parser.ScriptBlockRule(String name, Boolean requireBrace, Boolean isFilter, ParameterDeclarationNode parameterDeclaration, List`1 functionComments, List`1 parameterComments)
    at System.Management.Automation.Parser.FunctionDeclarationRule()
    at System.Management.Automation.Parser.StatementRule()
    at System.Management.Automation.Parser.StatementListRule(Token start)
    at System.Management.Automation.Parser.ScriptBlockRule(String name, Boolean requireBrace, Boolean isFilter, ParameterDeclarationNode parameterDeclaration, List`1 functionComments, List`1 parameterComments)
    at System.Management.Automation.Parser.ParseScriptBlock(String input, Boolean interactiveInput)
    at System.Management.Automation.ScriptCommandProcessor..ctor(String script, ExecutionContext context, Boolean isFilter, Boolean useLocalScope, Boolean interactiveCommand, CommandOrigin origin)
    at System.Management.Automation.Runspaces.Command.CreateCommandProcessor(ExecutionContext executionContext, CommandFactory commandFactory, Boolean addToHistory)
    at System.Management.Automation.Runspaces.LocalPipeline.CreatePipelineProcessor()
    at System.Management.Automation.Runspaces.LocalPipeline.InvokeHelper()
    at System.Management.Automation.Runspaces.LocalPipeline.InvokeThreadProc()

    Script Name: SCOM.Management.Server.Class.PowerShell.Properties.Discovery.ps1

    One or more workflows were affected by this.

    Workflow name: SCOM.Management.Server.Class.PowerShell.Properties.Discovery
    Instance name: x
    Instance ID: {ACA0B06C-C5B4-354E-83CD-6D3DD438C825}
    Management group: x "

    Some not all. Have any Tips ?

    1. Kevin Holman says:


      Apparently POSH 2.0 on WS2008R2 doesn’t like the switch statement and the full number. I need to encapsulate each number in quotes to resolve this. I will fix this in the next version update soon.

  19. Ian Blyth says:

    In the SCOM HealthService view you can display the install date but you cannot sort the column on the date. In the Agent Managed view in Administration you can sort by the installed date. It would be nice if that column was sortable to avoid going back to the Administration view,



    1. Kevin Holman says:

      Ian – I added this capability in version .45. All you have to do in the XML is change the view default IsSortable=True

      I have no idea why SCOM defaults to some view columns as not sortable. To me, they should ALL be sortable!

  20. John Bradshaw says:

    Hi Kevin,
    Does the previous version of the MP need to be uninstalled before importing this one?
    John Bradshaw

    1. Kevin Holman says:

      Not that I know of. Unsealed MP’s simply replace previous unsealed MP’s. However, if you sealed it – you will likely need to replace it because of structural changes.

  21. Ben Gransmore says:

    Hi Kevin,

    We are having problem with your SCOM Management MP that is reporting the Gateway servers as RTM rather than UR2 along with the server version of 7.2.11822.0 rather than 8.0.10918.0.

    The steps i have taken:

    – Went into control panel to compare the versions of SCOM in which there was no change. Looks like the verion is not updated here
    – Compare the Registry HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup on the MS and on the gateway. The gateway servers doesn’t include the ServerVersion however does include the Current version which is the same as the MS still listing the version on both as RTM
    – Checked the HealthService.dll files on both which both say 8.0.10949.0
    – At line 1162 in your MP it says “8.0.10949.0 {“2016 UR2″} #Gateway”

    I have screenshots of everything if required.

    1. Kevin Holman says:

      I see the bug now – I have it fixed – will publish after testing next week.

      1. Ben Gransmore says:

        Thanks Kevin!

  22. Sean says:

    Hi Kevin,

    Brilliant MP, really is very helpful!!.

    We were using the OMS Workspace Add function for our server estate. We had entered the appropriate information and checked the box to say ‘Use these settings for future tasks’. Recently we’ve changed OMS Workspaces, and would like to change the OMS Add defaults, is there a way to do this?


    1. rob1974 says:

      For the ones using the mp for upgrade from scom 2012 to 2016 and want to have an excel list:

      import-module operationsmanager
      New-SCOMManagementGroupConnection -ComputerName

      $class = get-scomclass -displayname “SCOM Agent Management Class”
      $instances = Get-SCOMClassInstance -Class $class|Sort-Object displayname
      $serverlist= @()

      foreach ($instance in $instances) {
      $props = @{
      Server = $instance.DisplayName
      OS = ($instance|Select-Object -ExpandProperty *.OSName).value
      PSver = ($instance|Select-Object -ExpandProperty *.PSVersion).value
      dotNet = ($instance|Select-Object -ExpandProperty *.CLRVersion).value
      $serverprops = New-Object psobject -Property $props
      $serverlist += $serverprops

      $serverlist|export-csv -Path “C:\temp\serverlist.csv”

  23. Steve says:

    Kevin, what an awesome MP. Immeasurably helpful in migrating a large MG to new servers. I have been using the MG – ADD task. I found that although the task is successful, the output always reads “Failed to add MY MG” even when modifying just one agent. My MG has spaces in it so I’m putting both the MG and the FQDN of the MS in quotes – not sure if that matters.

    1. Kevin Holman says:

      Yeah – someone else brought that to my attention. You might have to find workarounds for that. I’d never recommend a management group with spaces, I am surprised we allow for that. 🙂

  24. Hi, Kevin is it possible to make from “SCOM.Management.DeleteAgent.WA” a fragement to use this in other MP´s.
    I want to make a RecoveryTask for a Evententry to delete the Agent in the Scomlandscape.

  25. Michael Stefansen says:

    Hi Kevin
    I’m sure this yet another great tool from you and your colleagues. But apparently I can’t use the Management Pack 🙁 I have imported the managment pack in our newly installed SCOM 2016 environment, but I don’t get the folder “SCOM Management” in the console.
    Is this management pack not supported in SCOM 2016?

    1. Michael Stefansen says:

      Okay I figured it out – wrong Management Pack – DoH 🙁

  26. Jukka-Pekka Gröhn says:


  27. alexander says:

    Good day.
    I think what is missing in this section is “SCOM Server Tasks:” agent Repair tasks.

  28. Steeve Roy says:

    That would be nice to have some Linux equivalent (to know the OMS Workspace, etc).

  29. Jonathan Ortiz says:

    Kevin no se que tan adecuado sea que el MP contenga una tarea de verificación y remediacion del estado del WMI.

  30. Robert Raschke says:

    Hi Kevin, great MP! Makes my life much more easy…
    What I noticed though: All of my 2008R2 servers report a powershell verion of “2”. Even when executing “$PSVersionTable.PSVersion” through your powershell task remotely on the agent, it says its powershell v2.
    When executing “$PSVersionTable.PSVersion” directly in a powershell console on the 2008R2 box, I get the correct installed version 5 in the result…
    The same is for the “$PSVersionTable.CLRVersion”. Only the 2008R2 Sharepoint servers report CLR4, all others report CLR2 even if they are on .NET 4.5.2 and up.
    Any idea about that?

  31. DougGr says:

    Everything about this MP is amazing. Well done sir.

  32. frederik says:


    Will you release an updated version that will be compatible with SCOM 1801?
    This is a very usefull MP and I would like to see it supported in our 1801 environment.

  33. Hi Kevin!
    Great MP – well done!
    Is it possible to add one more SCOM task to “clean uninstall SCOM agent”? For our scom users in our company it would be the easiest way to trigger an uninstall of agents without being SCOM-administrator (but being local administrator on the monitored system). So for SCOM-admins it is ensured that the SCOM agent is uninstalled on the monitored system and it is deleted in SCOM itself in a clean way.

    Thank you very much!


  34. Pezza72 says:

    Hi Kevin,

    Just wanted to clarify on this since a previous answer to a question was that the pre-req is “Powershell”. I note that there is a mention of PowerShell 2 for going to 2016, but are the tasks in this pack dependent on PowerShell v2, or will it run on PowerShell v1?

    This pack will be so useful, especially for the agent tasks and management group tasks, but a lot of the servers that we are migrating from (and eventually getting rid of) are v1, and I believe that the Jimmy Harper version relies on v2. The migration involved is from SCOM2007.



  35. Bert Pinoy says:

    Hi Kevin,
    I’m experiencing an issue with the script: SCOM.Management.Agent.Class.PowerShell.Properties.Discovery.ps1
    When initially importing the management pack everything is discovered well. A customer of mine is currently updating powershell on all it’s servers to version 5.X but the property PSVersion is not updated in SCOM (discovery runs every hour).
    There are several servers which are showing PSVersion 4.0 but have been updated to 5.1 a few days ago.
    Looking in eventviewer shows me successful execution of the script but it shows: PowerShell Version is (4.0).
    When manually running the discovery script (on the same server, also under SYSTEM account) I get the correct version: PowerShell Version is (5.1).
    When running the script: $PSVersionTable.PSVersion (from the Execute any Powershell) I also get the wrong version.

    Any idea what might be going on here?

    Thanks for the feedback!
    Best regards,

Comments are closed.

Skip to main content