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


 

This is a little example MP for some things that are possible with SCOM.  It also serves as a good example MP on how to write classes, discoveries, and most importantly many task examples for command line, VBscript, and PowerShell.

I didn’t write all these – a bunch of ideas came from Jimmy Harper, Matt Taylor, and Tim McFadden and their MP’s.  This was more to combine lots of useful administration in one place.

 

First – useful discovered properties:

 

image

 

image

 

The “real” agent version

The UR level of the agent

Any Management Groups that the agent belongs to.  This is nice to see for old management groups that get left behind.

A check if PowerShell is installed and what version.  This is important because PowerShell 2.0 is required on all agents if you want to move to SCOM 2016.

CLR .NET runtime version available to PowerShell

OS Version and Name

Primary and Failover management servers.  I am getting this straight from the agents config XML file, sometimes agents might not be configured as you think – this is from the authoritative source…. what’s in that specific agents config.

Lastly, the default Agent Action account.  Helpful to find any agents where someone installed incorrectly.

 

Next up – the tasks:

 

image

 

One of the problems with tasks, is that they are scoped to a specific class.  Some cool tasks are attached to Windows Computer, some to HealthService, some to specific app classes.  Or – people write tasks and scope to System.Entity.  This places the task in ALL views.  That’s handy, but if everyone did that we’d have an unusable console for tasks.

Computer Management – duh.

 

Create Test Event – this task creates event 100 with source TEST in the app event log, and there is a rule in the MP to generate an info alert.  This will let you test end to end agent function, and notifications.

image

 

Execute any PowerShell – this task accepts one parameter – “ScriptBody” which allows you to pass any powershell statements and they will execute locally on the agent and return output:

image

image

 

Execute any Service Restart – this will take a servicename as a parameter and restart the service on any agent on demand.  You should NOT use this for the Healthservice – there is a special task for that:

image

 

Execute any Software from Share – this task will accept an executable or command line including an e4xecutable, and a share path which contains the software, and it will run it locally on the agent.  This is useful to install missing UR updates, or any other software you want deployed.  This will require that “Domain Computers” have read access to the files on the share.

image

 

Export Event Log – this task will export any local event log and save the export to a share.  It will require that the “Domain Computers” have write access to the share.

image

 

HealthService – Flush – This task will stop the agent service, delete the health service store, cache, and config, and start the service back up, provoking a complete refresh of the agents config, management packs, and ESE database store.

 

HealthService – Restart – This is a special task which will reliably bounce the HealthService on agents using an “out of band” script process.  Many scripts to bounce the agent service fail because when the service stops, the script to start it back up is destroyed from memory.

 

Management Group – ADD and Management Group – REMOVE – these are script based tasks to add or remove a management group from an agent

Ping – (Console Task) – Duh

Remote Desktop – (Console Task) – Duh

 

Do you have other useful agent management tasks that you think should be in a pack like this?  Or discovered properties that are useful as well?  I welcome your feedback.

 

 

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.

 

 

Download the MP here:  https://gallery.technet.microsoft.com/SCOM-Agent-Management-b96680d5


Comments (20)

  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.

  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:

    Kevin,
    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:

    Kevin,
    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.

  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
        https://stackoverflow.com/questions/31072543/reliable-way-to-get-windows-version-from-registry

        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.

          Thanks!

          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 🙂

  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)

Skip to main content