What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

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

Problem with Custom Script on Exchange 2013



Hi, I try tu run some simply check on my Exchange 2013 Database server. I have DAG and want to be alarmed, when my database is moved to another node. I wrote script in Powershell:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn;

$GlobalDBStat = 0
$AllDBs = Get-MailboxDatabase | Where-Object {$_.Name -like 'xxxxxx'}
foreach ($DB in $AllDBs)
    Write-Host $DB.Server
    If ($DB.Server -ne 'xxxxx')
        $GlobalDBStat = 1

Write-Host $GlobalDBStat,":" 

If I run the script locally on the server, it works of course like a charm and changes $GlobalDBStat param to 1 if any of the database is not on the particular server. But when I run it from the sensor, it always returns 0. I've tried different actions - ran the PRTG Probe Service as user, who definitely has permissions in Exchange Organization, put credentials in parent device, etc. It looks like the script (when run as a sensor) is not able to get Exchange object - the question is - why.

I'll be grateful for any help. Best Regards Marcin

custom-sensor exchange exe script

Created on Dec 22, 2016 2:59:53 PM

Last change on Dec 26, 2016 8:11:14 AM by  Stephan Linke [Paessler Support]

7 Replies



Hi Marcin,

Well, the first thing you need to keep in mind is that a script from a sensor is always executed via the probe it's located on. Given that it runs on the PRTG server, there is no remote server definition nor authentication against the remote server.

That said, did you already see our integrated Exchange DAG sensors? They might be what you're looking for :)

Created on Dec 26, 2016 8:42:54 AM by  Stephan Linke [Paessler Support]



Hi, thanks for the answer. I run this sensor exactly on this server, where the databases are (Exchange Mailbox role). There's PRTG Agent installed on the server, etc. So this is not the issue. I think how could I debug the problem, but have no idea.

Best Regards Marcin

Created on Dec 27, 2016 7:48:17 AM



Are you running it in the security context of the probe or as a certain user? If the former, you need to configure "Use credentials of parental device" within the sensor settings. How about the Exchange sensor I mentioned? :)

Created on Dec 28, 2016 12:28:46 PM by  Stephan Linke [Paessler Support]



I changed the "Security context" setting to "Use Windows Credential of parent device" and put proper credentials in parent device's properties and even in Remote Probe properties. But the result is the same. I made one more experiment: added the line to the script:

$TestVar = (Get-MailboxDatabase -Identity 'MDB1301').Server

I added the $TestVar to the message, which the sensor returns:

Write-Host $GlobalDBStat,":" + $TestVar

When I run the script locally, from Powershell console, I get the proper message obviously (the server name is visible). When I run it from PRTG, the server name is not displayed (empty space). It looks like the sensor either doesn't have access to Exchange data (what is rather not possible) or the Exchange commands (like "Get-MailboxDatabase") don't work for any reason (the question is - why).

Created on Dec 28, 2016 1:08:19 PM



Not sure either, seems to be a problem with the snapin. What about the PRTG internal Exchange DAG sensors? Did you try them already?

Created on Dec 28, 2016 1:20:03 PM by  Stephan Linke [Paessler Support]



Not yet, I have no remote management enabled on the server, but it looks like, I will have to...

Created on Dec 28, 2016 1:23:17 PM



Probably, yep :) Let me know if it worked :)

Created on Dec 28, 2016 1:29:23 PM by  Stephan Linke [Paessler Support]

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.