What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Getting version name/number as output

Votes:

0

Your Vote:

Up

Down

I wrote a script to get all the exchange server names you specify and it gets their version numbers. But I cannot get PRTG to display them. Rather have the names anyway but after reading multiple forum posts this is not possible I guess. Maybe someone with some insight into this would really help me.

powershell script:

param (
    	[string]$EXCHServers 		= ''
       )


$ExchangeServers = $EXCHServers.Split(",")
$Excharray = @()

ForEach  ($Server in $ExchangeServers) 
{
$Excharray += @(Invoke-Command -ComputerName $Server -ScriptBlock {Get-Command  Exsetup.exe | ForEach-Object {$_.FileversionInfo}})
}


$CompareArray = @()
$ResultArray = @()
$HTML = New-Object -Com "HTMLFile"
$WebResponse = Invoke-WebRequest "https://technet.microsoft.com/en-us/library/hh135098%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396" -UseBasicParsing
If ($WebResponse.StatusCode -eq '200') 
    {
    $HTML.IHTMLDocument2_write($WebResponse.RawContent)
    $HTMLperLine = @($HTML.all.tags("p") | % InnerText)


        ForEach  ($Server in $Excharray) 
            {
              ForEach ($line in $HTMLperLine) 
                {
                    if ($line -match $Server.ProductVersion)
                        {
                         [int]$lineindex = ([array]::IndexOf($HTMLperLine, $Server.ProductVersion))
                         $ResultArray += $Server.PSComputerName+";"+$HTMLperLine[($lineindex-2)]+";"+$Server.ProductVersion
                        }
                }
            }


    }
ELSE
    {
    write-host "no http 200 status"
    exit
    }


#####################
##Begin XML PRTG#####
#####################
write-host "<prtg>"

Foreach ($ResultServer in $ResultArray)
    {   
        $Servername,$ExchVersionText,$ExchProductVersion = $ResultServer.split(";")
        ##debug
        #write-host $Servername
        #write-host $ExchVersionText
        #write-host $ExchProductVersion
        
        If ($Servername -or $ExchVersionText)
         {
            write-host "<result>"
            write-host "<channel>$($Servername)</channel>"
			write-host "<value>$($ExchProductVersion)</value>"
			#write-host "<text>$($ExchVersionText)</text>"
			write-host "<float>1</float>" 
            write-host "</result>"
         }
    }


write-host "</prtg>"
#####################
##  End XML PRTG#####
#####################
Exit 0

sample result output:

<prtg>
	<result>
		<channel>EXCHSRV01</channel>
		<value>14.03.0361.001</value>
		<float>1</float>
	</result>
	<result>
		<channel>EXCHSRV02</channel>
		<value>14.03.0361.001</value>
		<float>1</float>
	</result>
</prtg>

Would be nice to see their version number, I dont need alerts just the numbers displayed and maybe make a report later with all the servers and their versions. But the sensor factory sensor should be sufficient for that.

custom-script-exe prtg-network-monitor-script script

Created on Jan 4, 2018 2:51:57 PM by  ArnoKattenpoel (0) 1

Last change on Jan 5, 2018 9:50:36 AM by  Luciano Lingnau [Paessler]



5 Replies

Accepted Answer

Votes:

0

Your Vote:

Up

Down

Hello there Arno,
we appreciate your KB-Post. That's a neat script!

The problem here is simply with the output. 14.03.0361.001 and 14.03.0361.001 are not valid Float numbers. A Float will look like this: 14.03

Since there are multiple "decimal separators", PRTG no longer considers it to be a valid float. PRTG currently displays a 0 as value when it is unable to parse the content of </value>, but this will change and soon to be released version 18.x.37 - In this version you would get an error telling you that the value is invalid.

So basically you need to change the way the value is parsed/outputed. You could strip out the dots, that would result in a large integer value like "14030361001". It should be possible to create a lookup-file in PRTG to map-back this number to text, something like this:

<?xml version="1.0" encoding="UTF-8"?>
  <ValueLookup id="prtg.customlookups.exchange,version" desiredValue="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PaeValueLookup.xsd" undefinedState="Warning">
    <Lookups>
      <SingleInt state="Ok" value="14030361001">Exchange Server 2010 SP3 Rollup 18</SingleInt>
      <SingleInt state="Ok" value="15011415002">Exchange Server 2016 CU8</SingleInt>
    </Lookups>
  </ValueLookup>

You would need to map every possible value to a text and state in the lookup, this way PRTG will display the state and according text for every version.

Note: Before doing the lookup, adjust your script to output an integer and re-create the sensor in PRTG since floats are not officially supported in lookups and the "type" of the channel is defined when it gets created.

To learn a bit more about lookups please have a look here:

Also, since this falls within the same scope/context, I encourage you to review the following post:

Edit: Also, regarding this line of your code:

#write-host "<text>$($ExchVersionText)</text>"

This does not really "work" because the sensor can only have one string/text for the whole sensor. Since you have two channels (EXCHSRV01 and EXCHSRV02) this is no longer practical. The text field should be used for a message/text relevant to the whole sensor.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jan 5, 2018 10:06:52 AM by  Luciano Lingnau [Paessler]

Last change on Jan 5, 2018 10:08:45 AM by  Luciano Lingnau [Paessler]



Votes:

0

Your Vote:

Up

Down

Heya Luciano,

Thank you for your thorough explanation, this is great! I was thinking of using the lookups but it very static, but since they consists of xml format I could make a update_lookup.ps1 on the prtg core server which parses the technet site into prtg compatible lookup xml.
As for the float to integer this makes perfect sense, and I was already going down this path.

But since my original vision can't be achieved I went back to the drawing board. I can go two way's now;

  • option 1 would be to make the lookup xml dynamic with some additional scripting on the prtg core server.
  • Options 2 would be to revisit the idea how this came to be, since all we want is to know when a Exchange server is out of date, I could parse all this allready in the script and simply return 1 or 0 to the sensor. Downside is we cannot make a report with all the versions (or maybe 1 extra channel with the version number as integer).

I figure something out, when it's finished i'll update the post, maybe some more folks who could use it.

Created on Jan 5, 2018 10:22:30 AM by  ArnoKattenpoel (0) 1

Last change on Jan 5, 2018 11:07:36 AM by  Luciano Lingnau [Paessler]



Votes:

1

Your Vote:

Up

Down

Hi Arno,

I think there will be a slight problem with a dynamic lookup xml, as all lookups are loaded into memory. Changing the lookup on disk will not have any effect until the core service gets restarted.

So yes, you can create a process that dynamically creates the lookup but you wil have to restart the core service afterwards.

Created on Jan 5, 2018 12:43:01 PM by  PRTG Tools Family [prtgtoolsfamily.com] (13,273) 3 4

Last change on Jan 8, 2018 7:15:35 AM by  Luciano Lingnau [Paessler]



Votes:

0

Your Vote:

Up

Down

As an alternative, the lookups can be reloaded by Setup / System Administration / Administrative Tool, function "Load Lookups".

There is also an API call availalbe

/api/loadlookups.htm

Created on Jan 5, 2018 3:29:35 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi Arno,
thank you for your reply.

Also thanks to PRTGToolsFamily for the contribution.

As pointed out, you will need to "re-load" lookups when a lookup file is updated, so that PRTG updates it internal lookup definition, this can be automated via /api/loadlookups.htm - But I wouldn't re-load lookups every 10 minutes, once a day shouldn't be a problem..

But I would go with the second option:

revisit the idea how this came to be, since all we want is to know when a Exchange server is out of date, I could parse all this allready in the script and simply return 1 or 0 to the sensor. Downside is we cannot make a report with all the versions (or maybe 1 extra channel with the version number as integer).

When I create custom sensors I attempt to avoid "named channels". Instead, I try to summarize the data in a way that I can easily get alerts when something is off and use the "Message" field of the sensor to point out which one of the "monitored" objects is causing issues or/and what the issue is. For example:

In both these cases, multiple hosts/devices are monitored, but only summarized data is provided in the channels (Number of Peers in State, Number of connected Access Points). Also, the first script (BGP) prints the identifier of the "offending" peer(s) when something is wrong with one of them:

Image Click to Enlarge

This approach is advantageous because you never get "Ghost" channels. If you think about your previous example again, you had two channels: EXCHSRV01 and EXCHSRV02.

If one of them gets "decommissioned", the sensor would forever report a channel with the former name and value 0. The only way to get rid of it would be to manually hide the channel or to re-create the whole sensor. With "summarized" sensors you don't have this problem, but I agree that reporting the "current state of affairs" becomes more difficult.

Maybe it makes more sense to leave PRTG to Monitoring and alerting and create a slightly different version of the powershell script for "version reporting/overview" that you can run as required..

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jan 8, 2018 7:14:28 AM by  Luciano Lingnau [Paessler]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.