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

Cannot get Dfsr powershell module to work in custom script

Votes:

0

Hi

Below is my script where I want to count backlog files on a host The script runs perfectly as my user and as my PRTG user (running the PRTG service) as long as it's done in a powershell window When I try to run it through PRTG as a Custom script (Custom EXE/Script Sensor) it seems that the module gets loaded but the functionalty does not work

Anyone got a hint?

---o0o---

Call to powershell: script.ps1 'ip address'

script:
Param(
	$hosttransfere=$args[0]
)

import-module Dfsr

$computername = [System.Net.Dns]::GetHostByAddress($hosttransfere).hostname
$computername = $computername.Replace(".mtc-maersk.com","")
$testDFSBacklog = Get-DfsrBacklog -computername $computername

$count = -1
ForEach($Item in $testDFSBacklog)
{	
	$count += $Item.Backlog
}
Write-host $count,":OK"

dfsr powershell wmi-custom-sensor

Created on Feb 3, 2016 1:55:15 PM

Last change on Feb 3, 2016 3:12:11 PM by  Torsten Lindner [Paessler Support]



Best Answer

Accepted Answer

Votes:

2

Thanks Luciano. Your test scripts were fantastic and gave me good insight into how to troubleshoot this and potentially other PowerShell sensors. I really appreciate it. I was able to get similiar results and then narrow the issue down to Local Admin rights as per your last suggestion. Our PRTG Probe was running as the Local System Account and in most cases for us this seemed to be sufficient and where I needed to I would introduce using "Parent Device credentials" which was typically a Windows box and I had setup a Domain Admin AD Account for this.

But in this case with DFSR and the fact that the two servers involved in the replication happen to also be Domain Controllers (we run a very small network) the Local System account was the key. I stopped the Probe service and reconfigured it to use an AD Service Account that is also a Domain Admin and restarted the Probe Service. This resulted in the scripts working as predicted.

I did have one other slight difference in that when using %dp0 in the scripts to get the current execution path it already had a "\" appended. So I had to make slight change to Luciano's Invoke BATch script.

For anyone looking here is the final scripts. I left Luciano's text in the PRTG Output as a reminder on how to troubleshoot.

Invoke Sensor C:\windows\sysnative\windowspowershell\v1.0\powershell.exe -file "%~dp0Get-DFSR-Count.ps1" %1 %2

PowerShell Sensor

Param(	
  $source=$args[0],
  $target=$args[1]
)

$identity = [Security.Principal.WindowsIdentity]::GetCurrent()
$principal = New-Object Security.Principal.WindowsPrincipal $identity
if ( $principal.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)) {$accessLvel = "Elevated"} else {$accessLvel = "Not Elevated"}
if ([Environment]::Is64BitProcess) {$64bits =  "This is 64bits"} else {$64bits =  "This is 32bits"}

$count = (Get-DfsrBacklog -SourceComputerName $source -DestinationComputerName $target).count

Write-Output "$($count):$($count) Files in Backlog between $($source) and $($target): $($accessLvel): $($64bits)"

Extra Notes The only other thing I can add is that I also turned on the Sensor Setting to Write EXE result to disk This then caused PRTG to create two log files in the Logs (sensors) directory. The one of most value to me was Result of Senosr xxxx.txt because PowerShell's various output streams scan get swallowed and in my case I was not seeing the "Access Denied" error being generated by the Get-DFSRBackLog cmdlet and the result of the COUNT method I was using was zero (0). So it looked fine in the PRTG Sensor UI but I knew the count was wrong. So once I found the Access Denied entry in the log and the rest of the text I was able to confirm that running the probe as a Local Admin was the problem.

The log entry was similiar to

C:\Windows\system32>C:\windows\sysnative\windowspowershell\v1.0\powershell.exe -file "C:\tgm\bin\prtg\Custom Sensors\EXE\Get-DFSR-Count.ps1" SVRAP01 SVRDC01  
Get-DfsrBacklog : Could not retrieve the backlog information. Replication 
group: "*" Replicated folder: "*" Source computer: SVRAP01 Destination 
computer: SVRDC01 Confirm that you are running in an elevated Windows 
PowerShell session and are a member of the local Administrators group on the 
destination computer. The destination computer must also be accessible over 
the network, and have the DFSR service running. This cmdlet does not support 
WMI calls for the following or earlier operating systems: Windows Server 2012. 
Details: Access is denied.
At C:\tgm\bin\prtg\Custom Sensors\EXE\Get-DFSR-Count.ps1:11 char:11
+ $count = (Get-DfsrBacklog -SourceComputerName $source -DestinationCom ...
+           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ProtocolError: (SVRAP01:String) [Get-DfsrBac 
   klog], DfsrException
    + FullyQualifiedErrorId : Get-DfsrBacklog.CimException,Microsoft.Distribut 
   edFileSystemReplication.Commands.GetDfsrBacklogCommand
 
0:0 Files in Backlog between SVRAP01 and SVRDC01: Elevated: This is 64bits

Note the output was returning 0:0 Files in Backlog between SVRAP01 and SVRDC01: Elevated: This is 64bits when I was expecting 4:4 Files in Backlog between SVRAP01 and SVRDC01: Elevated: This is 64bits as I knew how many files were backlogged at the time.

Sorry for the long winded explanation but I had spent some time chasing this and thanks to the clean and concise script from Luciano I was able to overcome the issue.

Thanks again

Created on Apr 3, 2017 1:37:23 AM



11 Replies

Votes:

0

Additional info:

  • %host is sent as parameter in the PRTG call to the powershell script
  • PRTG version: 16.1.21.1422
  • Windows 8 R2 fully updated
  • Powershell 3.0
  • Dfsr module placed both in "C:\Windows\System32\WindowsPowerShell\v1.0\Modules" and "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules"

Created on Feb 4, 2016 7:54:04 AM



Votes:

0

Hello

Please enable the EXE Result/Write EXE result to disk within the sensor's settings, as it may provide further details to why the script isn't providing the expected output.

Please also perform the following:
Set the Security Context to Use security context of probe service and configure the PRTG Probe Service to run with an user account with sufficient rights for the operations performed by the script.

Please share the outcome of these procedures. If there's an error in the sensor's exe result, please share it as well. The Sensor's Log/result will be stored on "C:\ProgramData\Paessler\PRTG Network Monitor" on the Probe System were the sensor was placed.

Best Regards,

Created on Feb 4, 2016 1:37:12 PM by  Luciano Lingnau [Paessler]



Votes:

0

All recommendations done

Probe is functional as it does return a valid result, but…..

  • When run in a Powershell window with my PRTG user the value “$testDFSBacklog“ get’s populated as expected
  • But when run from PRTG “$testDFSBacklog“ does not get populated and the ForEach loop never get’s activated

Created on Feb 4, 2016 2:24:19 PM



Votes:

1

Could it be that the module you're importing only works with the 64-bit version of Powershell? Please review the following:

Best Regards,

Created on Feb 5, 2016 11:44:35 AM by  Luciano Lingnau [Paessler]



Votes:

1

Hello, I am attempting a very similar (almost identical) sensor - DFSR Backlog count although my script and approach has been slightly different to overcome the x32 vs x64 Powershell issue.

I am still having issues and would appreciate any help. Thanks

My experience has been that I can get the same script to run via an x32 PowerShell instance as the same user as the Sensor Parent and results are returned in the value:text format expected by PRTG EXE. I have also set the execution policy to Unrestricted for both environments for the PRTG Sensor Parent User Context (which is a Domain Admin service account).

My approach based on other KB articles is to create a sensor that calls a parent Powershell script that PRTG will execute as an x32 instance. it in turn evokes x64 PowerShell instance calling the sensor script.

Please keep in mind that this combination of scripts works 100% outside of PRTG being evoked from a x32 PS interactive Shell as the same user that the sensor parent context. However, IT MUST BE WITH ELEVATED PRIVILEGES. I suspect that PRTG is not doing this and thus all of the errors in the Sensor Debug log are red-herrings and are the result of the lack of elevated privileges.

The FINAL Error I now get is...

The term 'Get-DfsrBacklog' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct

However the sensor data log has numerous errors starting with the following.

Import-Module : The specified module 'Microsoft.PowerShell.Management' was not loaded because no valid module file was found in any module directory.

The PARENT PS1 Script called by the Sensor is...

c:\windows\sysnative\windowspowershell\v1.0\powershell.exe -file "C:\tgm\bin\prtg\Custom Sensors\EXE\Get-DFSR-Count.ps1" 10.0.1.44 SVR-DC1

The CHILD PS1 sensor script is as follows...

Param(	
  $sourceIP=$args[0],
  $targetName=$args[1]
)

import-module DFSR

$count = -1
$msg = "Unknown Error"
$computername = [System.Net.Dns]::GetHostByAddress($sourceIP).hostname
$computername = $computername.Replace(".domain.local","")

Try
{
  $oDFSBacklog = Get-DfsrBacklog -SourceComputerName $computername -DestinationComputerName $targetName -ErrorAction Stop
  $count = $oDFSBacklog.Count
  if ($count -eq 0)
  {
    $msg = "All files have been replicated"
  }
  else
  {
    $msg = "Files waiting to be replicated"
  }
}
Catch
{
    $msg = $_.Exception.Message.SubString(0, 200)
    $failedItem = $_.Exception.ItemName
}

"{0}:{1}" -f $count, $msg

Created on Mar 31, 2017 3:27:57 AM

Last change on Mar 31, 2017 4:40:19 AM by  Sven Roggenhofer [Paessler Technical Support]



Votes:

0

Hello tgm,
thank you for your KB-Post.

While I'm unable to explain why your script/sensor behaves like this, I did some testing. I've started with the following:

Custom Test PS64.ps1
 $identity = [Security.Principal.WindowsIdentity]::GetCurrent()
 $principal = New-Object Security.Principal.WindowsPrincipal $identity

 if ( $principal.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)) {$accessLvel = "Elevated"} else {$accessLvel = "Not Elevated"}
 if ([Environment]::Is64BitProcess) {$64bits =  "This is 64bits"} else {$64bits =  "This is 32bits"}
 
 Write-Output "1:$($accessLvel): $($64bits)"

It produces the following output in PRTG:

Elevated: This is 32bits

Then I've created and used this to call this script:

Custom Test InvokePS64.bat
C:\windows\sysnative\windowspowershell\v1.0\powershell.exe -file "%~dp0\Custom Test PS64.ps1"

This resulted in the following in PRTG:

Elevated: This is 64bits

Which matches what you've described but allows me to confirm that the session is actually elevated. If I run the script interactively without using the Run as Administrator to call powershell or the ISE, I get "Not Elevated:..."

I may be using one configuration different than yours. When deploying the sensor, I've used the following setting:

Security ContextUse security context of probe service

And the PRTG Probe Service is configured to run with a valid domain account (that is a local admin on the server that runs the Probe and also on remote monitored systems). The service's configuration (services.msc) looks as follows:

NameStatusStartup TypeLog On As
PRTG Probe ServiceRunningAutomaticpaessler.com\johndoe

Impersonation is in general a very tricky subject, but running the service with a regular (admin) account usually works a lot better than using the default LOCAL_SYSTEM, which is only local.

I hope the information above helps. And if you're not using it already, please check the following free tools from Sysiternals (a division from Microsoft) as it can provide valuable troubleshooting information:

Created on Mar 31, 2017 1:42:18 PM by  Luciano Lingnau [Paessler]



Accepted Answer

Votes:

2

Thanks Luciano. Your test scripts were fantastic and gave me good insight into how to troubleshoot this and potentially other PowerShell sensors. I really appreciate it. I was able to get similiar results and then narrow the issue down to Local Admin rights as per your last suggestion. Our PRTG Probe was running as the Local System Account and in most cases for us this seemed to be sufficient and where I needed to I would introduce using "Parent Device credentials" which was typically a Windows box and I had setup a Domain Admin AD Account for this.

But in this case with DFSR and the fact that the two servers involved in the replication happen to also be Domain Controllers (we run a very small network) the Local System account was the key. I stopped the Probe service and reconfigured it to use an AD Service Account that is also a Domain Admin and restarted the Probe Service. This resulted in the scripts working as predicted.

I did have one other slight difference in that when using %dp0 in the scripts to get the current execution path it already had a "\" appended. So I had to make slight change to Luciano's Invoke BATch script.

For anyone looking here is the final scripts. I left Luciano's text in the PRTG Output as a reminder on how to troubleshoot.

Invoke Sensor C:\windows\sysnative\windowspowershell\v1.0\powershell.exe -file "%~dp0Get-DFSR-Count.ps1" %1 %2

PowerShell Sensor

Param(	
  $source=$args[0],
  $target=$args[1]
)

$identity = [Security.Principal.WindowsIdentity]::GetCurrent()
$principal = New-Object Security.Principal.WindowsPrincipal $identity
if ( $principal.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)) {$accessLvel = "Elevated"} else {$accessLvel = "Not Elevated"}
if ([Environment]::Is64BitProcess) {$64bits =  "This is 64bits"} else {$64bits =  "This is 32bits"}

$count = (Get-DfsrBacklog -SourceComputerName $source -DestinationComputerName $target).count

Write-Output "$($count):$($count) Files in Backlog between $($source) and $($target): $($accessLvel): $($64bits)"

Extra Notes The only other thing I can add is that I also turned on the Sensor Setting to Write EXE result to disk This then caused PRTG to create two log files in the Logs (sensors) directory. The one of most value to me was Result of Senosr xxxx.txt because PowerShell's various output streams scan get swallowed and in my case I was not seeing the "Access Denied" error being generated by the Get-DFSRBackLog cmdlet and the result of the COUNT method I was using was zero (0). So it looked fine in the PRTG Sensor UI but I knew the count was wrong. So once I found the Access Denied entry in the log and the rest of the text I was able to confirm that running the probe as a Local Admin was the problem.

The log entry was similiar to

C:\Windows\system32>C:\windows\sysnative\windowspowershell\v1.0\powershell.exe -file "C:\tgm\bin\prtg\Custom Sensors\EXE\Get-DFSR-Count.ps1" SVRAP01 SVRDC01  
Get-DfsrBacklog : Could not retrieve the backlog information. Replication 
group: "*" Replicated folder: "*" Source computer: SVRAP01 Destination 
computer: SVRDC01 Confirm that you are running in an elevated Windows 
PowerShell session and are a member of the local Administrators group on the 
destination computer. The destination computer must also be accessible over 
the network, and have the DFSR service running. This cmdlet does not support 
WMI calls for the following or earlier operating systems: Windows Server 2012. 
Details: Access is denied.
At C:\tgm\bin\prtg\Custom Sensors\EXE\Get-DFSR-Count.ps1:11 char:11
+ $count = (Get-DfsrBacklog -SourceComputerName $source -DestinationCom ...
+           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ProtocolError: (SVRAP01:String) [Get-DfsrBac 
   klog], DfsrException
    + FullyQualifiedErrorId : Get-DfsrBacklog.CimException,Microsoft.Distribut 
   edFileSystemReplication.Commands.GetDfsrBacklogCommand
 
0:0 Files in Backlog between SVRAP01 and SVRDC01: Elevated: This is 64bits

Note the output was returning 0:0 Files in Backlog between SVRAP01 and SVRDC01: Elevated: This is 64bits when I was expecting 4:4 Files in Backlog between SVRAP01 and SVRDC01: Elevated: This is 64bits as I knew how many files were backlogged at the time.

Sorry for the long winded explanation but I had spent some time chasing this and thanks to the clean and concise script from Luciano I was able to overcome the issue.

Thanks again

Created on Apr 3, 2017 1:37:23 AM



Votes:

0

Hello tgm,
thank YOU for the awesome reply!

I've marked it as best answer. :)

Cheers!

Created on Apr 3, 2017 5:15:58 AM by  Luciano Lingnau [Paessler]



Votes:

0

I'm having the same problem. This is my code below

$identity = [Security.Principal.WindowsIdentity]::GetCurrent()
$principal = New-Object Security.Principal.WindowsPrincipal $identity
if ( $principal.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)) {$accessLvel = "Elevated"} else {$accessLvel = "Not Elevated"}
if ([Environment]::Is64BitProcess) {$64bits =  "This is 64bits"} else {$64bits =  "This is 32bits"}


Import-Module DFSR
$DFSReplicationGroup = Get-DfsrReplicationGroup -ComputerName srvdfs
$Output = “<prtg>"
#For Each
$replicationGroup = Get-DfsrReplicationGroup -Name $DFSReplicationGroup.Name[0]
#$replicationGroup = Get-DfsrReplicationGroup -Name "dujardin-foods.com\dfs_shares\djb_data"
$Backlog = Get-DfsrBacklog -ReplicationGroup $replicationGroup
$Folder = $Backlog.Folder
$Count = $Backlog.backlog
$ReceivingMember = $backlog.ReceivingMember
$SendingMember = $backlog.SendingMember
#Write-Output $count[0]
#Write-Output $count[1]
#Write-Output $Folder[0] $Count[0] $ReceivingMember[0] $SendingMember[0]
$Channel0 = $Folder[0] + " from " + $SendingMember[0] + " to " + $ReceivingMember[0]
$Channel1 = $Folder[1] + " from " + $SendingMember[1] + " to " + $ReceivingMember[1]
$Value0 = $Count[0]
$Value1 = $Count[1]
$Output += “<result>        
<channel>$Channel0</channel>
<value>$Value0</value>
</result>
<result>        
<channel>$Channel1</channel>
<value>$Value1</value>
</result>
</prtg>
$accessLvel $64bits”
Write-Output $Output

This is the output i get.

C:\Windows\system32>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -file "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-Count.ps1" 
Import-Module : The specified module 'DFSR' was not loaded because no valid mod
ule file was found in any module directory.
At C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-C
ount.ps1:7 char:1
+ Import-Module DFSR
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (DFSR:String) [Import-Modul 
   e], FileNotFoundException
    + FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Comm 
   ands.ImportModuleCommand
 
Get-DfsrReplicationGroup : The term 'Get-DfsrReplicationGroup' is not recognize
d as the name of a cmdlet, function, script file, or operable program. Check th
e spelling of the name, or if a path was included, verify that the path is corr
ect and try again.
At C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-C
ount.ps1:8 char:24
+ $DFSReplicationGroup = Get-DfsrReplicationGroup -ComputerName srvdfs
+                        ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Get-DfsrReplicationGroup:String 
   ) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
 
Cannot index into a null array.
At C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-C
ount.ps1:11 char:1
+ $replicationGroup = Get-DfsrReplicationGroup -Name $DFSReplicationGroup.Name[
0]
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray
 
Get-DfsrBacklog : The term 'Get-DfsrBacklog' is not recognized as the name of a
 cmdlet, function, script file, or operable program. Check the spelling of the 
name, or if a path was included, verify that the path is correct and try again.
At C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-C
ount.ps1:13 char:12
+ $Backlog = Get-DfsrBacklog -ReplicationGroup $replicationGroup
+            ~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Get-DfsrBacklog:String) [], Com 
   mandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
 
Cannot index into a null array.
At C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-C
ount.ps1:21 char:1
+ $Channel0 = $Folder[0] + " from " + $SendingMember[0] + " to " + $ReceivingMe
mbe ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray
 
Cannot index into a null array.
At C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-C
ount.ps1:22 char:1
+ $Channel1 = $Folder[1] + " from " + $SendingMember[1] + " to " + $ReceivingMe
mbe ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray
 
Cannot index into a null array.
At C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-C
ount.ps1:23 char:1
+ $Value0 = $Count[0]
+ ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray
 
Cannot index into a null array.
At C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-C
ount.ps1:24 char:1
+ $Value1 = $Count[1]
+ ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray
 
<prtg><result>        
<channel></channel>
<value></value>
</result>
<result>        
<channel></channel>
<value></value>
</result>
</prtg>
Elevated This is 32bits

Created on Jul 5, 2018 9:15:40 AM

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



Votes:

0

Hello JeroenDeckers,
thank you for your reply.

The main issue appears to be that this is failing:

C:\Windows\system32>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -file "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DFSR-Count.ps1" Import-Module : The specified module 'DFSR' was not loaded because no valid mod

ule file was found in any module directory.|

As a result, all following commands fail as well, because the cmdlet wasn't loaded. Does it get loaded when you run this interactively with the x86 powershell version? In that case, the most likely cause is that the probe runs the powershell script under LOCAL_SYSTEM, maybe the cmdlet isn't available under this user account.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jul 6, 2018 11:41:45 AM by  Luciano Lingnau [Paessler]

Last change on Jul 6, 2018 11:41:57 AM by  Luciano Lingnau [Paessler]



Votes:

1

Hi. I think you will find that DFSR cmdlets only load in a x64 powershell and because PRTG evokes a x32 bit environment the cmdlet modules will not load.

If you refer to the earlier posts you will see an invoke sensor section. In my case this was a standard command line batch file that in turn evokes a x64 powershell environment from where the DFSR modules will load.

To test your script outside of PRTG you have to do it in x64 powershell cli and once tested use the invoke sensor sample in the posts above to call the script from the 32bit platform that PRTG calls script sensors from.

Created on Jul 6, 2018 12:06:02 PM




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.