I would like to monitor hosts and virtual machines that are managed by a Microsoft SCVMM. In previous PRTG versions there were the sensor types SCVMM Host sensor and SCVMM Virtual Machine sensor. As announced in PRTG version 16.1.23 these sensor types are deprecated and removed with version 16.x.25.
Is there still a way to include SCVMM hosts and SCVMM VMs into my monitoring with PRTG?
Created on Mar 10, 2016 1:47:21 PM by
This article applies to PRTG Network Monitor 16.x.23 or later
The SCVMM Host sensor and the SCVMM Virtual Machine sensor are two sensor types that we remove in context of The PRTG Sensor Cleanup. You could use these sensors to monitor hosts and virtual machines (VM) managed by a Microsoft System Center Virtual Machine Manager (SCVMM) like Hyper-V, VMware, or XenServer hosts and VMs. As of PRTG version 16.1.23 you cannot add these sensors anymore and running SCVMM sensors are removed from PRTG with version 16.x.25 which is expected in May 2016.
Nevertheless, you can still continue (or start) monitoring your SCVMM. For example, you can use an EXE/Script sensor that runs an according PowerShell (ps1) script.
We provide a custom script for SCVMM monitoring for download, plus you can use a device template to add SCVMM sensors automatically to an SCVMM device. Please follow the steps below to add sensors to your PRTG installation which monitor SCVMM hosts and SCVMM virtual machines.
Using the PowerShell script you can monitor the following values on a SCVMM host:
For an SCVMM virtual machine the custom sensor can show the following values:
To use the custom sensors for SCVMM monitoring, you need to fulfill the following requirements. These are the same as for the SCVMM sensors which were available out of the box in previous PRTG versions:
C:\Program Files\Microsoft System Center 2012\Virtual Machine Manager\bin\psModules\virtualmachinemanager\virtualmachinemanager
Import-Module C:\Program Files\Microsoft System Center 2012\Virtual Machine Manager\bin\psModules\virtualmachinemanager\virtualmachinemanager Use the command Set-ExecutionPolicy (we recommend RemoteSigned).
Please see also this Knowledge Base article: PowerShell Sensors: FAQ
When you enter the data in the script directly, you can also test it on the fly. Initially, it will look like the attached screenshot #1, consequential runs will look like #2. Note that the sensors may not have data directly after the first run. This is due to the startup of the sensors taking some time and the script may push values prior to that.
Verbose output of the sensor when initially executed / adding new hosts or VMs
Verbose output of the sensor when executed with existing GUID file
Custom SCVMM Sensor Monitoring a Virtual Machine
| Parameter | Description |
|---|---|
| prtgHostName | The URL of your PRTG webinterface, e.g. http://prtg.acme.com or https://prtg.acme.com |
| prtgPort | The port used by your PRTG webinterface, e.g. 80 or 443 |
| prtgUserName | A user with read/write permissions to the device, or a PRTG administrator |
| prtgPassHash | The passhash of the above user |
| prtgPushPort | The push port you configured in the template HTTP Push Advanced sensor |
| prtgScvmmDeviceId | This is the ID of the device that resembles your SCVMM server Recommended value %deviceid |
| prtgTemplateSensor | This is the ID of the HTTP Push Data (Advanced) template sensor(not the sensor token, but the PRTG ID) |
| Userdomain | The domain of the user that will be used for remote powershell access Recommended value %windowsdomain |
| Username | The username that will be used for remote powershell access Recommended value %windowsuser |
| Password | The password of the user that will be used for remote powershell access Recommended value %windowspassword |
| Verbose | When this is set, the script will output debug messages. This can always be enabled as it doesn't bother PRTG. |
| Version | Release Notes |
|---|---|
| 1.3 | [Changed] Switched to HTTP Push Sensor based system. No device templates needed, better for large environments. [Notes] It's an simple EXE/Script sensor now, no longer EXE/Script Advanced. Device templates are no longer needed, as the sensor automatically creates new sensors for new hosts and VMs with each run. With every run, we only run Get-VMHost and Get-VM once on the SCVMM host, receiving all objects at once, not once for every VM. A GUID file is maintained for every SCVMM host that will prevent sensor duplicates. Performance wise, it should be way easier and faster. Three VMs and one host take 2s to scan. Better, more verbose script output to see what the script actually does, receives and evaluates. |
| 1.21 | [Changed] Device template now has a timeout of 5min, for large environments. [Changed] Default VMsensor interval set to 10m (since they're 10m averages) |
| 1.2 | [Improved] naming conventions of the sensor [Fixed] auto discovery now works with stable |
| 1.1 | [Improved] documentation [Fixed] Values weren't retrieved correctly when multiple VMs were present. [Fixed] Values weren't retrieved correctly due to lookup bug |
| 1.0 | Initial Release |
For going through countless tests and bugfixing with me, and improvement ideas - Thanks! :)
Attention This will not work if your PRTG server uses HTTPS with an unsigned SSL certificate due to PowerShell being picky and only accepting signed ones.
Created on Mar 10, 2016 2:07:11 PM by
Last change on Feb 6, 2017 6:58:01 AM by
How do we get this to work on Server 2012 R2 SCVMM?
I've installed a remote probe on my SCVMM box and tell it to use the custom discovery like the guide above says. Finds 0.
When I try to run the PRTG-SCVMM-HyperV.ps1 from the machine with the probe I get (regardless of PowerShell running as Administrator or not):
**[NAME.DOMAIN.COM] Connecting to remote server NAME.DOMAIN.COM failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (NAME.DOMAIN.COM:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken**
If I run the PS1 from my PRTG server to the SCVMM server NAME.DOMAIN.COM it works. I get a list of HyperVs back.
It looks like as long as I'm not localhost the PS1 file will work.
How can I make this work in PRTG?
Created on Sep 14, 2016 2:10:33 AM by
Last change on Sep 14, 2016 6:05:55 AM by
This is probably due to remote powershell not being properly enabled. Please check this for further instructions. Make sure to download the latest version of the sensor from the initial reply as I posted a new version :)
Created on Sep 14, 2016 2:00:27 PM by
Hi Team,
The sensor is succesfully seeing my SCVMM, however i am getting this error when running the script
3/07/2017 12:16:40 AM] error Could not create sensor for SYDAWSDC01. [3/07/2017 12:16:40 AM] information Starting sensor creation for AWSMELDC01 (GUID: 70d40a8d-4dd4-476d-9b50-e9c6783f5be3) [3/07/2017 12:16:40 AM] error Could not create sensor for AWSMELDC01. [3/07/2017 12:16:40 AM] information Starting sensor creation for MMOSRVAPP02 (GUID: 6a812734-e453-4c7f-9c0e-ea37b5dd23c7) [3/07/2017 12:16:40 AM] error Could not create sensor for MMOSRVAPP02. [3/07/2017 12:16:40 AM] information Starting sensor creation for SYDSRVHUB01 (GUID: 64c9431b-a628-4afc-be0a-ead1b10fad21) [3/07/2017 12:16:40 AM] error Could not create sensor for SYDSRVHUB01. [3/07/2017 12:16:40 AM] information Starting sensor creation for MRN-CAS2 (GUID: cb3f169a-383a-4a06-ba54-ec283343d1fa) [3/07/2017 12:16:40 AM] error Could not create sensor for MRN-CAS2. [3/07/2017 12:16:40 AM] information Starting sensor creation for GuestWifiTestVM (GUID: 7d65b3ac-7108-491a-91ab-f2f30fd91a91) [3/07/2017 12:16:40 AM] error Could not create sensor for GuestWifiTestVM. [3/07/2017 12:16:40 AM] information Starting sensor creation for Boot (GUID: 5856c590-6cf1-4afc-9750-facb68271205) [3/07/2017 12:16:40 AM] error Could not create sensor for Boot. [3/07/2017 12:16:40 AM] information Starting sensor creation for AUSSRVMON01 (GUID: fbf1e27f-fbd5-4b17-bc62-fbd724622360) [3/07/2017 12:16:40 AM] error Could not create sensor for AUSSRVMON01. [3/07/2017 12:16:40 AM] information Starting sensor creation for MELSRVDC01 (GUID: caa3b009-3451-43f1-8420-fcdc60c0bcf9) [3/07/2017 12:16:40 AM] error Could not create sensor for MELSRVDC01. [3/07/2017 12:16:40 AM] information Starting sensor creation for AWSSRVAPP01 (GUID: 574d52cd-3c89-4f4b-b339-fff0e8fe8118) [3/07/2017 12:16:40 AM] error Could not create sensor for AWSSRVAPP01. [3/07/2017 12:16:40 AM] information 0 new Virtual Machines have been added to PRTG. [3/07/2017 12:18:20 AM] error Couldn't push the data to the configured PRTG server using the specified token (57be3832-f68c-478d-888f-162b2f546c03). [3/07/2017 12:20:00 AM] error Couldn't push the data to the configured PRTG server using the specified token (84e73668-f434-4930-8481-5664321f6220). [3/07/2017 12:20:02 AM] error Couldn't push the data to the configured PRTG server using the specified token (da74ed95-0c77-4081-9461-86bef65dbf2e). [3/07/2017 12:20:03 AM] error Couldn't push the data to the configured PRTG server using the specified token (e81b1ddd-3b73-4284-aaa4-c2341d2423d1). [3/07/2017 12:20:04 AM] error Couldn't push the data to the configured PRTG server using the specified token (f47a588e-e547-4728-99bc-d7b22b4bd280). [3/07/2017 12:20:05 AM] error Couldn't push the data to the configured PRTG server using the specified token (bd83524c-e46f-45f2-807c-0fa2147d6f90). [3/07/2017 12:20:06 AM] error Couldn't push the data to the configured PRTG server using the specified token (df53ed60-4561-432f-827c-53273045b3ef). [3/07/2017 12:20:07 AM] error Couldn't push the data to the configured PRTG server using the specified token (c314a559-7d30-47b2-bcdb-9249fa7877a5). [3/07/2017 12:20:08 AM] error Couldn't push the data to the configured PRTG server using the specified token (0ac01dca-ebcd-40a0-a53e-a335f5a7c75e). [3/07/2017 12:20:18 AM] error Couldn't push the data to the configured PRTG server using the specified token (dcff2afb-fbea-4ead-b6bb-04951f111e0d). [3/07/2017 12:20:19 AM] error Couldn't push the data to the configured PRTG server using the specified token (b3aedd08-81a9-4a16-a1d8-0509d717114a). [3/07/2017 12:20:20 AM] error Couldn't push the data to the configured PRTG server using the specified token (43708edf-6b88-4090-80ff-0a263c1e97b5). [3/07/2017 12:20:21 AM] error Couldn't push the data to the configured PRTG server using the specified token (2c286efa-c241-4db3-a1da-0cd0d22891d2). [3/07/2017 12:20:22 AM] error Couldn't push the data to the configured PRTG server using the specified token (73eefe2d-8bbc-4689-9f33-0cf4db718913). [3/07/2017 12:20:23 AM] error Couldn't push the data to the configured PRTG server using the specified token (dabe90f5-4c55-40c6-b052-11e363cdac3c). [3/07/2017 12:20:24 AM] error Couldn't push the data to the configured PRTG server using the specified token (13b00809-d765-4252-a41e-153dfd857b1e).
I am running SCVMM 2016, however looks more like an issue getting the data into PRTG.
Any ideas or tips would be great.
Cheers Matt
Created on Jul 2, 2017 2:21:41 PM by
Last change on Jul 3, 2017 5:01:15 AM by
Dear MacquarieMedia
Did you manually create the HTTP Push Data Advanced sensor before you ran the script?
Created on Jul 3, 2017 2:01:31 PM by
This seems overly complicated. PRTG has always allowed me to quickly monitor simple and complicated things in an "easier to setup" way then other monitoring applications. This is why I recommend PRTG to other users. But this is not simple.
The instructions could use some more detailed, "example based" instructions for setting up the parameters for the script. This custom sensor should be reworked so that is select-able with the parameters in the web gui vs doing it this way. This would mimic the previous sensor, but require the powershell modules. I recognize that VMWare is probably easier to monitor. Sensors for HyperV and System Center Virtual Machine Manager should be something that PRTG makes easier to setup and monitor then the other monitoring companies.
Thanks for a great product and for listening. DB
Created on Jul 5, 2017 6:34:38 PM by
Dear davbujn17
Yes, this custom sensor solution is rather complicated. But custom sensors cannot be made select-able in the web gui. We don't want to re-add this sensor to the web gui as we deprecated it just last years because of its little overall usage.
It surely appears counter-intuitive how we make the software better if we remove existing features. The idea is two-fold: One, we keep PRTG simple. Second, we reduce the source code, making it easier to rework and easier for new developers to get into it. That means, that we try to not implement little-used features in the first place, and last year we even removed existing, but little-used sensors.
While SCVMM monitoring is now admittedly more complex, we used our development resources to make other things better.
Created on Jul 6, 2017 1:03:03 PM by
We've got more than 8000 VM's in Hyper-V and I'm very pro-PRTG, so I've tried to sell PRTG in our organization. Because of this issue they've decided to not buy the unlimited license.
Created on Jul 24, 2018 9:59:37 AM by
While the script was tested with around 300 VMs, this surely is over the top and we cannot test this with such large environments :( It's rather possible that the script will take a loooong time to retrieve the host servers and virtual machines, running into Windows' 20 minute child process timeout rather than working correctly.
For environments that large, you're probably better off with Microsoft SCOM :)
Kind regards,
Stephan Linke, Tech Support Team
Created on Jul 24, 2018 11:36:19 AM by
Last change on Jul 24, 2018 11:40:25 AM by
Hello Stephan,
We've got an environment with more than 8000 vm's. We're currently monitoring using PRTG the yper-V hosts only. We would like to buy the unlimited sensor suite of PRTG, but only if PRTG can measure VM's in Hyper-V cluster aware, and directly on the Hyper-V node without SCVMM.
Are you basically saying that PRTG is not a good product for our sizing when it comes to live migrating VM's in Hyper-V?
Created on Jan 21, 2019 1:41:50 PM by
In that case, I'd recommend against it, yes. The HTTP Push Sensors used in this approach are putting less strain on either system (target host and PRTG). It's unfortunately a chicken and the egg case. We can't monitor moving VMs moving on HyperV clusters; even if we could, it would be 8,000 WMI queries against the systems. The script approach above is querying Hyper-V directly, querying all VMs and hosts at once. However, it has not been tested with that amount of VMs - the most we had were about 400, and it took quite a bit to get the values (took about 2-3 minutes to get them).
PRTG Scheduler |
PRTGapi |
Feature Requests |
WMI Issues |
SNMP Issues
Kind regards,
Stephan Linke, Tech Support Team
Created on Jan 21, 2019 7:10:40 PM by
Please log in or register to enter your reply.
Add comment