Kaseya Community

Home » Discussion Forums » Monitoring - VSA » Script to Create a Monitor Set of all Automatic Services

Learn more about how AuthAnvil can protect and enhance your Kaseya experience

Similar Posts

KASM revision C (Monitor Set of all Automatic Services)

by
on May 11, 2010

create custom monitor set from service/executable

by
on Nov 30, 2016

Monitoring Automatic Services

by
on Nov 8, 2016

Monitoring Automatic Services

by
on Oct 21, 2010

Dealing with Windows Core All Automatic Services

by
on Aug 29, 2016
Details
  • 13 Replies
  • 0 Subscribers
  • Postedover 10 years ago

Script to Create a Monitor Set of all Automatic Services

  • LegacyPoster
    Posted by
    on Dec 14, 2007 8:17 PM
    KASM_RevB.zip
    I always wished that Kaseya would have made it easier to monitor services on a computer. From my standpoint, any service that is set to run automatically, especially on a server, should be monitored. With Kaseya, it has always been too labor intensive to create a monitor set for all variations of computers and services. So, I decided that I would create a vbscript and a Kaseya script that would gather a list of all Automatic Services on a computer, and create a Monitor Set that could be imported and assigned to each computer for which it was run against. Granted, this will create a special monitor set for each computer, but it’s better than having to create them manually, or worse, not monitoring all of the services that are set to run automatically.

    Before running these scripts, make sure you have run an Update List By Scan from the Monitor Tab, on the Function List under Edit, to make sure Kaseya knows about all services on the computer.

    By default, the monitor set will set the following Service Settings:

    Restart Attempts: 3
    Restart Intervals: 60 Seconds
    Rearm: 300 Seconds (5 Minutes)

    The above can be changed in the vbscript or changed for specific services after the monitor set has been imported.

    The attached vbscript and Kaseya script will create an .XML file for each computer that it is ran against, for importing as a Monitor Set. The name of the .XML file will be in the following format:

    KASM-GroupID-MachineID.xml

    I placed the prefix KASM (Kaseya Automatic Services Monitor) there so that when the monitor sets are imported, all of these monitoring sets will be listed together. Additionally, I place the GroupID first so that each monitor set will be grouped by GroupID and then MachineID. The GroupID and MachineID are Kaseya Variables that are retrieved using the Kaseya Get Variable script function, using the SQL View Data as the type, and retrieving the variables from the SQL View vmachine/groupName for the GroupID and vMachine/machName for the MachineID.

    The vbscript is called using two command line arguments such as the following:

    Cscript KASM.vbs PathName MonitorSetName

    PathName - Then name of the path where to write the XML file.
    Example: c:temp

    MonitorSetName - The name of the monitor set to create. Do not supply an extension, an extension of .xml will be added automatically.
    Example: KASM-AcmeComputerCorp-Computer01

    Note, the attached Kaseya Script will automatically assign these two command line arguments.

    After these scripts run, a file will have been created and copied to the Kaseya Server and stored under the computer name that the script was ran for. After running the script, select Get File in the Function List on the left hand side of the screen, under File Transfer. Select the computer that you ran the script against, and look in the folder KASM. From there, click on the .XML file and it will open in your browser. Depending on your browser, select the Save As option and save the file, insuring that it has an .XML extension.

    After saving the file, you will want to import the monitor set. Select the Monitor Tab within Kaseya, and then select Monitor Sets from the Function List on the left. From there, click on the IMPORT button. Then browse to the .xml file you just saved, and select UPLOAD. You should then see a screen that says Monitor Set: MonitorSetFileName imported successfully. Close this screen.

    You should then see the newly created monitor set named KASM-GroupID-MachineID Services Monitor. Now you will need to edit this monitor set to assign the Group Alarm Column to Services (this cannot be set with an imported monitor set). Edit the monitor set, and from the drop down box labeled “Group Alarm Column”, change it from Other to Services, then click Save. While you are here, click on the Services Check Tab. From there you will see all of the automatic services listed. You will notice in the drop down box that usually lists a shortcut to each page of services, will be listed as “undefined”. This I believe is a bug within Kaseya. I will open a ticket with Kaseya to see if this is a bug or if there is a workaround. Either way, it does not impact functionality.

    The next and final step is to go and assign the new monitor set to the computer. From the Monitor Tab, in the left Function List, select Assign Monitoring. From there use the drop-down selection box to select the monitor set you want to assign, and assign it to the correct computer.

    To see the status of the monitor set assigned to the computer, select Monitor Log from the Function List and click on the computer name you just assigned the monitoring set to. It will take a minute or two for all of the services to start responding. For each of the services, you can click the plus (+) symbol next to the service to see the description of the service and its restart attempts. The description will contain the friendly name of the service as well as the Log On As, showing what account the service is using to start the service, as well as the actual executable file that the service is running (always good stuff to know).

    If services get added or removed from a computer set that you created, you can either add or remove them from the created monitor set, or remove the monitor set from the computer, delete the monitor set, and then re-run the script and then import and re-assign. Note, Kaseya does not stop you from importing a duplicate monitor set with the same name.

    One last note. XML files have a few reserved characters that could show up in the description of a service. The vbscript looks for these characters and makes substitutions as follows:

    "&" becomes "and"
    "
    ">" becomes "GT"
    "'" becomes "APOS" for Apostrophe
    """ becomes "DQ" for Double Quote

    Hopefully you’ll find these scripts beneficial in your environment. Please post here any problems you may have.









    Legacy Forum Name: Script to Create a Monitor Set of all Automatic Services,
    Legacy Posted By Username: gssloan
  • LegacyPoster
    Posted by
    on Oct 30, 2007 9:17 PM
    I've written a VB script to list, check,and startauto services. I plan to usethe service stopped event id to triggerrun it.The advantage is it starts any auto start services that aren't currently running. It also doesn't have to be configured per device. I have some more work on it, but it's close.

    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: connectex
  • LegacyPoster
    Posted by
    on Dec 2, 2007 7:04 PM
    Great script. Super time saver. Incredible.

    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: myArch-man
  • LegacyPoster
    Posted by
    on Dec 3, 2007 8:12 PM
    myArch-man wrote:
    Great script. Super time saver. Incredible.


    Thanks for your feedback.

    Greg


    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: gssloan
  • LegacyPoster
    Posted by
    on Dec 4, 2007 1:53 PM
    Hi Connectex, your script could be useful in many ways, are you so kind to post it?

    Regards,

    Claudio


    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: achab
  • LegacyPoster
    Posted by
    on Dec 9, 2007 7:24 PM
    This script has really save me a ton of time. Thank you, Thank you, Thank you! :-D

    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: ebrush
  • LegacyPoster
    Posted by
    on Dec 10, 2007 5:22 PM
    ebrush wrote:
    This script has really save me a ton of time. Thank you, Thank you, Thank you! :-D


    Glad to hear it. Thanks for the feedback.

    Greg




    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: gssloan
  • LegacyPoster
    Posted by
    on Dec 11, 2007 4:15 PM
    Help. Where do these XML files go? I am having trouble figuring out the entire process. I downloaded the KASM files to my managed files directory and imported the script, but I don't see the monitor sets get created. Any ideas on what I can look at to make this work? -Eric.

    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: espeer
  • LegacyPoster
    Posted by
    on Dec 11, 2007 7:08 PM
    I wonder about overhead though. Don't the monitor sets add another perfmon counter. (Maybe I am completely way off). So just raising the questions. I've noticed that each monitor service seems to create another PID in task manager. What are the implications?

    Thanks!


    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: rvines
  • LegacyPoster
    Posted by
    on Dec 14, 2007 3:42 AM
    Hi,

    Just a quick question on this script. I have tested it out and it works fantastic, however, my query is as follows:

    If I am applying exchange server updates for example, and that update stops exchange services until the update is applied, how will this affect the Automatic Services Monitor Set?

    Obviously, I don't really want the services to be restarted DURING the update, but I do want them to be checked and started after the subsequent reboot of the server.

    Any thoughts,

    Cheers,

    Dean


    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: Dean
  • LegacyPoster
    Posted by
    on Dec 14, 2007 5:44 PM
    If you're deploying the update via Kaseya or a Kaseya script it's not an issue. However, if you do it manually you'll have to useMonitor->Suspend Alarms option to avoid the monitoring restarting your services and so on.

    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: connectex
  • LegacyPoster
    Posted by
    on Dec 14, 2007 8:17 PM
    I'm feeling dense. Kind of like in that Simpsons episode where everyone gets the joke except Lisa...

    I can't seem to get the KASM script to work for the life of me. Those instructions seem quite straight forward, but it just doesn't work for me. Can someone please post the files again and lay out another procedure for me?

    Where does the XML file go, and how does the monitor set get created? Does it automatically get created?

    I appreciate it. -Eric.


    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: espeer
  • Dikesh
    Posted by
    on Jan 19, 2017 11:19 PM

    Can anyone give me the download link for this script.
  • GreyDuck
    Posted by
    on Jan 24, 2017 12:34 AM

    I'm not really sure you want this script. A different monitor set created for each and every server endpoint? Great googly moogly. It's a remarkable feat of programming but it isn't the most efficient use of one's time I've ever seen, never mind the damage it does to the scroll bar in your Monitor Set edit list.... let alone the picker when you're going to apply the thing.

    So, what do we do here at Resource One?

    I have a procedure that gets run once per week. This procedure checks the "automatic" status of a number of key services: DNS. DHCP. IIS. And so on. Each one found to be in the "automatic" state gets a YES flag in a Custom Field created for this purpose. At that point it's a piece of cake to setup Views that can be used in Policy Management so that anything with a YES for, let's say, the "Serves DNS" custom field gets the DNS services monitor set.

    It does mean adding all the services you care about to the checks in the procedure and you need custom fields for all of them. Your mileage may vary on this approach. We keep this sort of thing on a short leash, and also use things like an Exchange 2010 group-of-services monitor set applied via a view populated by a script that checks which (if any) version of Exchange is installed on a server. That way one check script applies one monitor set to keep watch on a bunch of services, and it's all done automatically via Policy Management.

    And that's my couple of pennies' worth.