LabTech ESXI Host Hardware Monitor

On April 2, 2014, in How-to, Projects, Scripting, by Cubert aka (Cube Dweller)


NEW ->LabTech ESXi Hardware Monitor v2.1

Squidwork’s ESX Hardware monitor is a set of scripts, a custom group and search for Labtech that will monitor the CIM data provided through the VMWare API for ESX 4 and 5. The probe will launch hourly and report back to Labtech any hardware failure or warning. The script will email an alarm to any email address you would like. The script can be modified to also set an alarm, create a ticket or anything else Labtech scripting will let you do.

New in version 2.1:

We added several checks for false alarms and socket errors to prevent alarms and emails on non failures.

We added alarm flood control, once a email goes out it will not send another until the system has reported a “all OK” then alerts are reset to go out on next fail.

Added extra EDFs to control processes.


Here is how it works:

Download the zip file, extract and import the  XML files into your Labtech system.







Addendum Update:

After you import “all” scripts in Version 2.1  Download this zip and import this script. This script should then be used in your group scheduled script  probe instead of the v2.1. This v.2.2 of that one script.  Download update here

Download extra files directly if import fails for any reason here.

After the import you should have a VMware script group that has 3 scripts in it.

Script #1 (The Installer) will install the monitor to a Windows system. You will need to provide the FQDN or IP of the ESX host you want to monitor when you execute the installer script. When the scheduler pops up make sure to add your ESX host. The only thing you should need to do is execute the installer on a Windows system. The installer will configure the system and add the system to the custom group and search. You do not need to configure anything else at this point. The ESX user and password will be fetched from the Locations password menu for VMWare.



The next script (The Monitor) is assigned to the custom group “Systems that monitor ESX hosts” to run every hour. You can modify this to run at what interval you like.  The Monitor will query your “Locations” passwords database table and retrieve the VMWare user listed just like the original Labtech probes do. The monitor get the CIM health data and returns it to Labtech, It also looks to see if we are “Not OK” and fires off a email if failures are picked up.

After the Monitor runs you should see data on the Info Tab -> VMWare sub tab


You will need to edit the monitor script updating the email address that it reports to when failures are found, you can also modify monitor script to create a ticket, fire off an alarm, set an alert or anything your heart desires. Line 39 of the script ESX Hardware Monitor V2-1 needs to be edited and the email changed to the email you want to get the alerts.

The 3rd script is a updater script that will fetch the latest build of the Nagios Plugin:”” script maintained by   You can run this script against any Windows box that has the monitor installed and it will get the latest version of this script and deploy it to that system. This way you can keep up with all the fixes they do to this script. You may want to run this script on the group once or twice a year just to make sure you have the latest fixes and updates.





Cubert 😎

Tagged with:

26 Responses to “LabTech ESXI Host Hardware Monitor”

  1. […] Labtech ESXI Host Hardware Monitor […]

  2. Tim says:

    Hi There,

    First off, LOVE your script. was easy to setup and install!!

    I have one problem though. the script emails me with OK alerts….

    I see in the script if ESXSTATUS Not = OK – Server. but the logs show this parameter as an alert and sends the email…. i have tried widcards such as OK – Server% and OK – Server: but no luck….

    Are you able to shed any light on this?


  3. Tim,

    I just updated the probe to version 2.1 This adds a few new features and also takes care of that false alarm. I have it now ignoring socket errors and timeouts.

    As always do not forget to Edit line 39 and change the email address.

  4. CG says:

    Tried to download the zip but the files in it are corrupt. The monitor XML is showing as almost 88MB compressed?

  5. I am uploading another Exported set of Scripts now. The total size of zip should be 65207KB.

    It carries the Python Installer and extra CIM packages needed to make it all work.

  6. Had complaints that the zip was still un-usable. Repacked zip with each script, search and group and re packaged it. Zip package is now 65107KB

  7. tfpvg says:

    This works GREAT! Thank you so much, LabTech really screwed the pooch on this and you solved the problem with class. I had no issues with download or corrupt files.

    1. Scripts did not import into folders correctly, landed at root I just had to drag them to the new group.
    2. Emails were going out regardless of OK status. Had to add 2 lines:
    25 GOTO :StatusGoodEnd
    32 :StatusGoodEnd
    3. Actual monitoring script did not attach to group. attached it and set it to run hourly.
    4. Auto Join Search group was not set properly, changed to ‘Systems that monitor local ESX hosts’
    5. Scheduled Python update at installation for every 6 months.
    6. **Do NOT install this on a VM running on the target ESXi box. Might sound obvious but I did it and a purple screen of death greeted me.

  8. cubert says:


    Thanks for your post, it’s good to get feedback.

    I am trying to reproduce your #2 issue, In the monitor script at line 29 -32 there are several IF statments that are looking for false alarms and correct statuses. If found it should redirect failures to the Email otherwise skip.

    Line 32 says IF Status not = “OK – Server” then jum to EMAIL which is the only call that goes to Email. Not sure how email would go out on a OK status.

    If you could paste the full returned string from the probe here I may beable to figure out what it thinks it sees.

    As for the setups imports, not sure why they would not be grouped correctly in the right locations but thanks for the insight, that should help others get setup.

    I will need to dig around and see why they import incorrectly.



  9. dj says:

    I had the same issues with 1 and 3 as tfpvg. I suspect that the order you import the script matters? For me the VMWare script group was created, but all of the scripts were in the root and it didn’t attach the monitor to the group. No problems with 2 or 4. Also no issues with 6, I installed it on a 2008 R2 VM running on a VMWare 5.1 without issue.

    Verified the script by running it against two boxes, one running fine and one with one of the PSUs unplugged. Got the one expected alert.

    Thank you for this. We were previously deploying a small VM to each server to run a script to poll the info and email us on errors. This is 100x easier.

  10. Connor says:

    I am having similar issues.

    I believe I have the group set up correctly and the monitor script attached. However, attempting to run the ‘Install ESX Monitoring Applications” fails against a 2008 server in our DMZ:

    The script(6017) failed in the THEN section at step 8

    Start Install ESX Monitoring Applications V2-1
    IF File Check Parameter1: C:\Python25\ Parameter2: 1 Parameter3: Time Taken: 46235.3237295
    L1 Script Note Parameter1: First lets check, are we a win Parameter2: Parameter3: Time Taken: 46241.8271014
    L3 Script Note Parameter1: Did we get the correct input? Parameter2: Parameter3: Time Taken: 46242.8271586
    L4 Variable Check Parameter1: ESXHOSTNAME Parameter2: 2 Parameter3: Time Taken: 46243.3271872
    L5 Script Note Parameter1: Lets download our Python packa Parameter2: Parameter3: Time Taken: 46243.8272158
    L6 File Delete Parameter1: %ltsvcdir%\packages\esxi_monit Parameter2: Parameter3: Time Taken: 46244.3272444
    L7 Folder Delete Parameter1: %ltsvcdir%\packages\esxi_monit Parameter2: Parameter3: Time Taken: 46253.8287879
    L8 File Download Parameter1: Utilities\VMWare\esxi_monitor_ Parameter2: %ltsvcdir%\packages\esxi_monit Parameter3: Time Taken: 46260.3311598

  11. Cubert says:

    Looks like your dying at the file copy of the extra packages for Python

    Do you have this file?

  12. dj says:

    Script failed like that for me earlier today on one of the installs I was doing. Problem was that the %ltsvcdir%\packages\ folder did not already exist. Manually creating it fixed the problem. I edited the script to include Create Folder: %ltsvcdir%\Packages as line 8 before it started the download. That seemed to take care of the problem.when I tested it afterwards on another server that didn’t already have the directory.(after I remember to actually hit save on my open script window…)

  13. Jeremy says:

    Regarding tfpvg’s comment #6, Is there a reason why it shouldn’t run a VM on the box? I just set it up on one and ran it, without any troubles or blue screens. As others mentioned it didn’t add the folders or schedule the script, I had to configure that.

  14. Cubert says:


    Great that’s good to know, I will add that to version 2.2 coming out soon.


    Not sure what tfpvg is thinking but to each his own. I run this exclusively on VMs running on the hosts I want to monitor. I operate 70+ hosts and several hundred VMs with zero issues to date but that is my setups and managed systems and I would expect them to preform well.

    End the end it’s your choice.

  15. Jack says:

    I have tried importing all of the XML files and see that the VMWare scripts folder is created but it shows empty in my system. I have tried deleting it and reimporting the XML files but it just recreates the folder. Any ideas?

  16. Cubert says:

    Do a script search for “ESX Hardware Monitor” or “Install ESX Monitoring” these are the 2 main scripts. If you still can’t find them then I will send them to you individually if need be.

  17. Jack says:

    Found them, very odd, they weren’t even in the root, they were two folders down in my own custom folders for AV. odd… Thanks!

  18. Jack says:

    Is it possible to monitor more than one host from a single agent?

  19. Cubert says:

    not in V2, I am in prelease of V3 which adds a full plugin into the mix allowing for a single probe to mange all ESX hosts, support for multiple passwords per location, Graphical representation of statuses, select-able deployment of probes from plugin and a full CIM read out for each host.

    Some really cool stuff in coming in V3

  20. Just added update to the Version 2.1 up above just under download image.. everyone should upgrade to resolve a removal of probe typo in 2.1 not a huge fix but fixes a obviously broken function.

  21. Jack says:

    I don’t suppose you have a monitor install script for linux agents?

  22. Jack, Thats a good idea. Python is pretty much available to most linux distros LT supports so the rest maybe easy. I will look into that and Mac as well.

  23. ddovjr says:

    does this work with the free esxi 5 server?

  24. Alex says:

    How do I remove this version from my labtech server and disable the check boxes on the probes. I run version 3 which is good, so having version 2.2 is not needed. I tried to uncheck the check box “This system monitors a ESX host” but its not allowing me to do it.


  25. Aaron says:

    does this script only work with on prem labtech?

Leave a Reply