Retrieve file version with custom sensor

Since this isn't a float value, you have to change the script output: 1.1:Current version is $return_fileversion

You could also output this: 1.156537. Otherwise, it's not really possible to graph the version number correctly - sorry!

Thank you Stephen. I'll give this a shot and see what happens. The actual goal is to create a Map for each of our environments that just displays the whole version number (which is a text string) so we can easily, at a glance, tell what version each environment is on.

We don't actually need to graph the response. Is it possible to have PRTG see this value as text (nvarchar) as opposed to a float or integer? (I'm unable to change the structure of the build numbers unless you're aware of a way of having Powershell do some kind of filtering or modification of the output?)

Thanks again for your help! It'll be huge if we can get this going. Right now, it's a nightmare keeping track of the versions out in production...

Hi Stephan, Thank you for the reply. After a few iterations, the only change I've been able to observe is instead of the "OK" message, the PRTG console is returning the text portion of the value side. IE: "Current version is" but no version number even though the value is definitely returning on the probe machine when executed in powershell.

Here's where I am at this point: $return_fileversion = (Get-Command "\\Server\path\file.dll").FileVersionInfo.Fileversion echo ":Current version is$return_fileversion"

I've tried placing various values ahead of the : with the same result (including the $return_fileversion variable).

Does PRTG have a problem pulling in a returned text value like this?

Unfortunately, unless you know how I could filter within powershell itself, I can't manipulate how the version numbers are generated from visual studio. Thanks again for your help!

- William

How about this:

$Version = "1.4.12.5467.4" -Split "\."
Write-Host ("{0}.{1}{2}{3}{4}" -f $string[0],$string[1],$string[2],$string[3],$string[4])

Puts out 1.41254674. This can then be evaluated properly as a float value by PRTG :)

I've actually realized what's going on now. As it turns out, when I run the original script against a LOCAL file on the probe server, PRTG has no problem displaying the version number in the message section. (It would be better if it was passed as the value, but I can live with this for now.)

However, when pointing at a UNC path, or even a mapped drive letter, the exact same script returns "OK" in the message section instead of the version text.

I have verified that the sensor is running as my own domain admin account (for testing only) which is what I am logged in as on the probe server when testing the script locally which works properly.

Any guesses about why PRTG wouldn't like executing the script when it is pointing at a network path. I could write something clunky that copies the dll file in question to the local probe server and then evaluates its version but that would be horribly inefficient...

Thanks so much for your help. I'll be sure to document the complete solution here once it's worked out so that other forum users can recycle the technique.

Thanks!

So, this script works perfectly and even respects passing in a parameter from the Sensor settings gui. The last stumbling block is that it only works for files local to the probe server.

<# Pass in the full path and file name in the parameter section of the sensor Settings.#>

$fileName =$args[0]

function get-fileversion {
  param([System.IO.FileInfo] $fileItem)
  $verInfo = $fileItem.VersionInfo
  "{0}.{1}" -f
  $verInfo.FileBuildPart,
  $verInfo.FilePrivatePart
}

$version = (get-fileversion $fileName)

echo $version": $version"

Any thoughts about what would cause PRTG to be unable to use a UNC path? On the physical probe server, executing the script locally with a UNC path in the same user context as PRTG works fine. I'm diving into security & system logs

Thanks a lot.

Hm, do you access the file like this:

\\host\C$\Windows\system32.dll

Or do you use a share that is mounted on the PRTG server? Because the latter one wont work, no matter if it's mounted as the same user that executes the script.