#win32_logicaldisk | Explore Tumblr posts and blogs

toborobot · 6 years ago

Text

PRTG Sensor Condensing With PowerShell

If you are an administrator in an enterprise environment there is a good change you know about PRTG Network Monitoring. This is a great application for monitoring all kinds of application data, resource usage, whatever you heart desires data for devices in a network. It has an auto-discovery feature that recommends sensors and discovers new devices. When PRTG recommends sensors they typically monitor one thing. The licensing is mostly based on how many sensors you have paid for. When you start reaching your limit and the budget is tight because the IT department is short on funds this may be a solution for you. The sensor I made for this purpose can be found on my GitHub page HERE.

The PRTG sensors that monitor CPU, Memory, and Disk Space use Windows Management Instrumentation (WMI). WMI is being replaced with the Common Information Model (CIM) in Windows devices. WMI was Microsofts original interpretation of CIMv2. CIM is a vendor-independent standard for describing the hardware and OS components of computer systems and providing tools that a program can use to both read and modify components. Remote Management using WMI is considered a security risk and should be avoided when possible. Info on that wil lbe for another blog. These are some of the many reasons I use CIM whenever possible. Why would Windows change the way they identify objects inside their Object Based Operating System you ask? Great question.

The only real thing the CIM cmdlets can’t do that WMI can is access amended qualifiers such as the class description. Many classes do not set this attribute which has not been a hardship for me at least. The way WMI is set up, combined with the length of time it has been around has caused the names of objects to be duplicated. This means different namespaces contain classes and instances with the same name which can get confusing and cause scripts to respond in unintended ways. CIM eliminates this issue as well as a few other bullet points I placed below.

Use of WSMAN for remote access (This means no more DCOM errors. You can drop back to DCOM for accessing systems with WSMAN2 installed)

Use of CIM sessions allows for accessing multiple machines

Get-CIMClass can be utilized for investigating WMI classes

Improves dealing with WMI associations

The phenomenally detailed documentation at PRTG for creating Custom Sensors can be found HERE. The way these sensors work with PRTG is a bat script or a ps1 script are run. The results are than placed into an XML format the PRTG Server interprets and displays for the admin monitoring the network devices. The sensor at my GitHub page is considered and EXE/Advanced Custom Sensor because it returns the XML output where as a Standard EXE sensor only returns a single true or false result. The PRTG sensors are usually only monitoring one thing because we do not want to overload a sensor with information. The max amount of sensor result fields allowed was somewhere between 50 and 60. That is an easy number to stay under however if CPU usage gets to high, inaccurate results may be produced.

In the code below what we are doing is creating a CIM Session to a remote device and running three commands inside that CIM Session as opposed to opening a session, issue the command, close the session three separate times. This will save us time and resources. We are using a CIM Session and not a PsSession because CIM sessions add the security of not allowing execution of arbitrary commands and return arbitrary objects. They also provide a unique benefit of taking up fewer system resources. CIM sessions stay dormant in the background of a Windows PowerShell session until an instruction is received.

$CimSessionOptions = New-CimSessionOption -UseSsl

$CIMSession = New-CimSession -ComputerName $Device -SessionOption $CimSessionOptions

$OS = Get-CimInstance -CimSession $CIMSession -ClassName "Win32_OperatingSystem"

$CPUs = Get-CimInstance -CimSession $CIMSession -ClassName "Win32_Processor"

$Disks = Get-CimInstance -CimSession $CIMSession -ClassName "Win32_LogicalDisk" | Where-Object -Property 'DriveType' -eq 3

SIDE NOTE: If your environment is not configured to use WinRM over HTTPS you should look at doing that. It allows you to use the -UseSsl parameter with ease and in many other cases where you want to ensure there is an extra layer of encryption protecting any information going over the wire.

You may have noticed above that the variable $Device is used in the -ComputerName parameter. If we were creating a PowerShell module it is best practice to use $ComputerName as the variable name. I did this because PRTG expects certain placeholder values to be set. If I renamed that variable to $ComputerName the PRTG sensor would fail to connect to the remote host. More info on that can be found HERE. When adding the custom sensor in PRTG we need to enter the place holder value in the following format.

'%device'

In the ps1 file, the $Device parameter is set and will be matched to the value of the device name. If you use Auto-Discover in PRTG you may need to rename some of the devices as Auto-Discover will name things with an extra extension such as [Windows SQL Server] or something along those lines. That entire name gets placed into the $Device variable which means the sensor is trying to contact a device that doesn't exist. An Example of how this is entered can be seen below.

'Write EXE result to disk' is selected as this is great for troubleshooting any issues that may be happening with the sensor. The latest result is always logged on the PRTG server in the following directory. C:\ProgramData\Paessler\PRTG Network Monitor\Logs (Sensors). This is extremely handy when trying to format your XML labels with the correct names and values. If you set a value of Bytes to become Gigabytes you will still see the Bytes value in this log file. This is because PRTG converts these values in their web application and not the XML parser.

Mutex Name is a great section they added. When you have a script running on multiple remote devices, you want there to be a limit on how many can run at once otherwise they might all run at once. Any devices that have a Mutex Name of R5 will run together. Any devices with a sensor that has a Mutex Value of DirkaDirka will run together. This way you are able to define how many instances of the script can be run at once.

After creating the EXE/Advanced sensor you will need to place it in the C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML directory. This way it will be available when you go to create the sensor and select it from a drop down menu inside the PRTG application. Once all is said and done my sensor will return results that look like the image below.

We are able to set the Warning and Alert values using the XML format defined by PRTG. The XML does need to be beautified in order for the sensor to work correctly. The below is a PowerShell function that I used to beautify the output.

There are a few fields that are commented out that can easily be added to the PRTG final sensor by just copying them from the comments inside the $XML variable between tags. I left out the below fields but feel free to add them and add your own Error and Warning limits if desired. It is very fun.

Read official blog post here: https://roberthosborne.com/f/prtg-sensor-condensing-with-powershell

0 notes