< Back
New-SensorParameters
Post
NAME New-SensorParameters
SYNOPSIS
Creates a new set of sensor parameters for creating a brand new sensor under a device.
SYNTAX
New-SensorParameters [-Type] {ExeXml | WmiService | SqlServerDB | Http | Factory} [[-First] <object>] [[-Second]
<object>] [<CommonParameters>]
New-SensorParameters [-RawParameters] <Hashtable> [-DynamicType <SwitchParameter>] [<CommonParameters>]
New-SensorParameters -Device <Device> -RawType <string> [-DynamicType <SwitchParameter>] [-QueryParameters
<Hashtable>] [-QueryTarget <SensorQueryTarget>] [-Target <string>] [-Timeout <int>] [<CommonParameters>]
New-SensorParameters [-Empty <SwitchParameter>] [<CommonParameters>]
DESCRIPTION
The New-SensorParameters cmdlet creates a set of parameters for adding a brand new sensor to PRTG. All sensor
types supported by PRTG can be added with New-SensorParameters, however certain types are "natively" supported.
For types that are not are natively supported, New-SensorParameters is capable of either dynamically generating
the required set of parameters, or creating a completely custom set of parameters from a collection of values
manually crafted by hand.
Natively supported sensor types allow interfacing with strongly typed properties of a well known object deriving
from NewSensorParameters. When a supported type is created, the name to give the sensor can be optionally
specified. If a name is not specified, New-SensorParameters will automatically assign the sensor the default name
PRTG would assign a sensor of the specified type (e.g. EXE/Script Advanced sensors by default are named "XML
Custom EXE/Script Sensor").
In addition to the sensor name, certain sensor types contain additional mandatory fields that must be populated
before attempting to add the sensor (such as the ExeFile of an EXE/Script Advanced sensor). New-SensorParameters
optionally allows you to specify the value of the primary mandatory field of the specified type using the -Value
parameter. Fields that require values contain a value of $null by default, however not all fields that are $null
are necessarily mandatory. If you attempt to add a natively supported type with missing mandatory fields, PrtgAPI
will catch this and alert you that the value that was missing.
Beyond type safety, PrtgAPI does not perform any validation that the values you specify to fields are "correct"
(e.g. for an EXE/Script Advanced sensor, that the specified file exists). In the event invalid values are
specified, PRTG will usually handle the error gracefully, however you are responsible for confirming that any
values that are used to create a new sensor as are as correct as possible.
For sensor types that are not natively supported, PrtgAPI provides the ability to dynamically generate the set of
parameters required to add the specified sensor type. Dynamically generated sensor parameters operate as a hybrid
of a both a Dictionary and a PSObject, allowing you to interface with these types as if they are a native object.
For sensor types that require additional information be provided before retrieving their sensor parameters, a
-QueryTarget or a set of -QueryParameters must be specified. New-SensorParameters will automatically advise you
what should be provided for these parameters if it determines these values are required by the specified sensor
type.
For sensor types that require Sensor Targets, a dictionary of all identified sensor targets can be found under the
dynamic sensor parameter's Targets property. Parameters that appear to contain sensor targets will automatically
be wrapped as a GenericSensorTarget, and by default will contain the first target from the list of available
candidates.
By default, dynamically sensor parameters are "locked", as to prevent additional parameters from being added to
the object in the event a typo is made. If you do wish to add additional parameters however, this can be performed
by calling the Unlock method on the specified DynamicSensorParameters and then setting the value via the
parameter's indexer or via the dynamic property name. Note that DynamicSensorParameters dynamic properties will
always show parameters as not containing a trailing underscore as to provide a "cleaner" interface. The raw
CustomParameter objects of the parameters can be viewed however by specifying Custom to the object's indexer.
If you wish to create your parameters yourself, this can either be done by creating an -Empty set of parameters
for you to manually populate, or by defining a hashtable listing all the parameters that are required to create
the specified sensor along with their raw associated values. The parameters for creating a specific type of sensor
can be discovered via a web debugger such as Fiddler or by inspecting the underlying parameters generated by a set
of DynamicSensorParameters.
When accessing RawSensorParameters and DynamicSensorParameters via their indexers, by default PowerShell will
suppress any exceptions thrown when trying to access non-existent properties, instead simply returning $null. This
is due to the default Strict Mode the PowerShell engine runs under. To enable exceptions on accessing invalid
paramters, the strict mode must be set to version 3 or higher. For more information, see Get-Help Set-StrictMode.
Great care should be taken when adding sensors using raw parameters. As there is no type safety, the possibility
of making errors is high. As most raw parameter names end in an underscore, it is critical to ensure these
parameters have been named properly. In the event a sensor is added improperly, it can easily be corrected or
deleted in the PRTG UI. When specifying a hashtable parameter set to New-SensorParameters, PrtgAPI will validate
that at a minimum the 'name_' and 'sensortype' parameters are specified. If either of these two are missing,
New-SensorParameters will generate an exception.
When sensor parameters are created via the Add-Sensor cmdlet, if the -Resolve parameter is specified PrtgAPI will
attempt to resolve the resultant sensors based on the sensor type specified in the sensor parameters. If the
resulting sensor type is capable of changing based on the specified parameters, you can instruct PrtgAPI to
broaden its sensor resolution search by specifying the -DynamicType parameter when creating your parameters
object. DynamicType property can also be modified on the resulting NewSensorParameters object that is returned
from the New-SensorParameters cmdlet.
All sensor parameter types support specifying common sensor parameters (Inherit Triggers, Interval, Priority, etc)
via well typed properties. If these properties are not set, PRTG will automatically use the default values for
these fields based on the type of sensor being created.
PARAMETERS
-Type <SensorType>
The type of sensor to create.
Possible values: ExeXml, WmiService, SqlServerDB, Http, Factory
Required? true
Position? 0
Default value ExeXml
Accept pipeline input? false
Accept wildcard characters? false
-First <object>
The name to give the new sensor. If no value is specified, the default name of the specified sensor type will
be used. If the specified sensor type does not support specifying a name, this field is used for any mandatory
values required by the sensor type.
Required? false
Position? 1
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Second <object>
A mandatory value required by the specified sensor type.
Required? false
Position? 2
Default value
Accept pipeline input? false
Accept wildcard characters? false
-RawParameters <Hashtable>
A collection of raw parameters for adding an unsupported sensor type.
Required? true
Position? 0
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Device <Device>
The device to create a set of DynamicSensorParameters from.
Required? true
Position? named
Default value
Accept pipeline input? true (ByValue)
Accept wildcard characters? false
-RawType <string>
The raw name of the sensor type to create.
Required? true
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Target <string>
Wildcard used to specify the sensor targets to assign to a set of DynamicSensorParameters.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Timeout <int>
Duration (in seconds) to wait for dynamic sensor parameters to resolve.
Required? false
Position? named
Default value 60
Accept pipeline input? false
Accept wildcard characters? false
-QueryTarget <SensorQueryTarget>
A sensor query target to use when retrieving dynamic sensor parameters. Can include wildcards.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-qt <SensorQueryTarget>
A sensor query target to use when retrieving dynamic sensor parameters. Can include wildcards.
This is an alias of the QueryTarget parameter.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-QueryParameters <Hashtable>
A set of sensor query target parameters to use when retrieving dynamic sensor parameters.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-qp <Hashtable>
A set of sensor query target parameters to use when retrieving dynamic sensor parameters.
This is an alias of the QueryParameters parameter.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Empty <SwitchParameter>
Specifies that an empty set of RawSensorParameters should be returned to allow constructing a parameter set
manually.
Required? false
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
-DynamicType <SwitchParameter>
Specifies whether the resulting sensor type is dynamically determined by the parameters included in the
request. If this property is true, PrtgAPI will relax its sensor resolution mechanism to ensure the resultant
object is retrieved.
Required? false
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug,
ErrorAction, ErrorVariable, WarningAction, WarningVariable,
OutBuffer, PipelineVariable, and OutVariable. For more information, see
about_CommonParameters (https:/go.microsoft.com/fwlink/?LinkID=113216).
INPUTS
PrtgAPI.Device
The device to create a set of DynamicSensorParameters from.
OUTPUTS
---------- EXAMPLE 1 ----------
C:\\> $params = New-SensorParameters ExeXml "Custom Script" "CustomScript.ps1"
C:\\> Get-Device dc-1 | Add-Sensor $params
Create a new EXE/Script Advanced sensor on the device dc-1 using the name "Custom Script", that executes the file
"CustomScript.ps1", specifying the script name in the optional -Value parameter
---------- EXAMPLE 2 ----------
C:\\> $params = New-SensorParameters ExeXml "Custom Script"
C:\\> $params.ExeFile = "CustomScript.ps1"
C:\\> Get-Device dc-1 | Add-Sensor $params
Create a new EXE/Script Advanced sensor on the device dc-1 using the name "Custom Script", that executes the file
"CustomScript.ps1", specifying the script name after the object has been created
---------- EXAMPLE 3 ----------
C:\\> $params = New-SensorParameters ExeXml
C:\\> $params.ExeFile = "CheckStatus.ps1"
C:\\> Get-Device -Id 1001 | Add-Sensor $params
Create a new EXE/Script Advanced sensor on the device with ID 1001 using the name "XML Custom EXE/Script Sensor"
that executes the file "CheckStatus.ps1"
---------- EXAMPLE 4 ----------
C:\\> $params = Get-Device esxi-1 | New-SensorParameters -RawType vmwaredatastoreextern
C:\\> $params.datafieldlist__check = $params.Targets["datafieldlist__check"]
C:\\> $params | Add-Sensor
Dynamically create a new set of VMware Datastore credentials for the device named esxi-1 targeting all datastores
that exist on the device.
---------- EXAMPLE 5 ----------
C:\\> $params = Get-Device esxi-1 | New-SensorParameters -RawType vmwaredatastoreextern
C:\\> $params[[PrtgAPI.Parameter]::Custom]
View the raw set of CustomParameters defined on an object.
---------- EXAMPLE 6 ----------
C:\\> $params = Get-Device esxi-1 | New-SensorParameters -RawType exchangepsdatabase
C:\\> $params.Unlock()
C:\\> $params.customparam_ = "some value"
Create a new parameter named "customparam" on a set of Exchange Database sensor parameters.
---------- EXAMPLE 7 ----------
C:\\> $params = New-SensorParameters -Empty
C:\\> $params["name_"] = "My Sensor"
C:\\> $params["sensortype"] = "exexml"
Create an empty set of sensor parameters to manually insert all raw parameters.
---------- EXAMPLE 8 ----------
C:\\> $raw = @{
>> name_ = "my raw sensor"
>> tags_ = "xmlexesensor"
>> priority_ = 4
>> exefile_ = "CustomScript.ps1|CustomScript.ps1||
>> exeparams_ = "arg1 arg2 arg3"
>> environment_ = 1
>> usewindowsauthentication_ = 1
>> mutexname_ = "testMutex"
>> timeout_ = 70
>> writeresult_ = 1
>> intervalgroup = 0
>> interval_ = "30|30 seconds"
>> errorintervalsdown_ = 2
>> sensortype = "exexml"
>> }
C:\\> $params = New-SensorParameters $raw
C:\\> Get-Device dc-1 | Add-Sensor $params
Add a new EXE/Script Advanced sensor to the device named dc-1 using a hashtable containing its raw parameters.
---------- EXAMPLE 9 ----------
C:\\> $params = New-SensorParameters $raw -DynamicType
Create a set of parameters for creating a sensor with a dynamic type (such as snmplibrary).
---------- EXAMPLE 10 ----------
C:\\> Set-StrictMode -Version 3
Set the Strict Mode to version 3 for the current PowerShell session.
---------- EXAMPLE 11 ----------
C:\\> $params = Get-Device -Id 1001 | New-SensorParameters -RawType snmplibrary -qt *ups*
Create a set of parameters for creating a SNMP Library sensor utilizing a wildcard expression that matches the
sensor query target "APC UPS.oidlib".
---------- EXAMPLE 12 ----------
C:\\> $target = (Get-SensorType snmplibrary -Id 1001).QueryTargets | where Value -like *ups*
C:\\> $params = Get-Device -Id 1001 | New-SensorParameters -RawType snmplibrary -qt $target
Create a set of parameters for creating a SNMP Library sensor utilizing the sensor query target "APC UPS.oidlib".
---------- EXAMPLE 13 ----------
C:\\> $params = Get-Device -Id 1001 | New-SensorParameters -RawType ipmisensor -qp @{ username = "admin"; password
= "password" }
Create a set of parameters for creating an IPMI Sensor specifying the query target parameters required to
authenticate to IPMI.
RELATED LINKS
Online version: https://github.com/lordmilko/PrtgAPI/wi ... parameters
Get-Help SensorParameters
Add-Sensor
Get-Device
Set-StrictMode
SYNOPSIS
Creates a new set of sensor parameters for creating a brand new sensor under a device.
SYNTAX
New-SensorParameters [-Type] {ExeXml | WmiService | SqlServerDB | Http | Factory} [[-First] <object>] [[-Second]
<object>] [<CommonParameters>]
New-SensorParameters [-RawParameters] <Hashtable> [-DynamicType <SwitchParameter>] [<CommonParameters>]
New-SensorParameters -Device <Device> -RawType <string> [-DynamicType <SwitchParameter>] [-QueryParameters
<Hashtable>] [-QueryTarget <SensorQueryTarget>] [-Target <string>] [-Timeout <int>] [<CommonParameters>]
New-SensorParameters [-Empty <SwitchParameter>] [<CommonParameters>]
DESCRIPTION
The New-SensorParameters cmdlet creates a set of parameters for adding a brand new sensor to PRTG. All sensor
types supported by PRTG can be added with New-SensorParameters, however certain types are "natively" supported.
For types that are not are natively supported, New-SensorParameters is capable of either dynamically generating
the required set of parameters, or creating a completely custom set of parameters from a collection of values
manually crafted by hand.
Natively supported sensor types allow interfacing with strongly typed properties of a well known object deriving
from NewSensorParameters. When a supported type is created, the name to give the sensor can be optionally
specified. If a name is not specified, New-SensorParameters will automatically assign the sensor the default name
PRTG would assign a sensor of the specified type (e.g. EXE/Script Advanced sensors by default are named "XML
Custom EXE/Script Sensor").
In addition to the sensor name, certain sensor types contain additional mandatory fields that must be populated
before attempting to add the sensor (such as the ExeFile of an EXE/Script Advanced sensor). New-SensorParameters
optionally allows you to specify the value of the primary mandatory field of the specified type using the -Value
parameter. Fields that require values contain a value of $null by default, however not all fields that are $null
are necessarily mandatory. If you attempt to add a natively supported type with missing mandatory fields, PrtgAPI
will catch this and alert you that the value that was missing.
Beyond type safety, PrtgAPI does not perform any validation that the values you specify to fields are "correct"
(e.g. for an EXE/Script Advanced sensor, that the specified file exists). In the event invalid values are
specified, PRTG will usually handle the error gracefully, however you are responsible for confirming that any
values that are used to create a new sensor as are as correct as possible.
For sensor types that are not natively supported, PrtgAPI provides the ability to dynamically generate the set of
parameters required to add the specified sensor type. Dynamically generated sensor parameters operate as a hybrid
of a both a Dictionary and a PSObject, allowing you to interface with these types as if they are a native object.
For sensor types that require additional information be provided before retrieving their sensor parameters, a
-QueryTarget or a set of -QueryParameters must be specified. New-SensorParameters will automatically advise you
what should be provided for these parameters if it determines these values are required by the specified sensor
type.
For sensor types that require Sensor Targets, a dictionary of all identified sensor targets can be found under the
dynamic sensor parameter's Targets property. Parameters that appear to contain sensor targets will automatically
be wrapped as a GenericSensorTarget, and by default will contain the first target from the list of available
candidates.
By default, dynamically sensor parameters are "locked", as to prevent additional parameters from being added to
the object in the event a typo is made. If you do wish to add additional parameters however, this can be performed
by calling the Unlock method on the specified DynamicSensorParameters and then setting the value via the
parameter's indexer or via the dynamic property name. Note that DynamicSensorParameters dynamic properties will
always show parameters as not containing a trailing underscore as to provide a "cleaner" interface. The raw
CustomParameter objects of the parameters can be viewed however by specifying Custom to the object's indexer.
If you wish to create your parameters yourself, this can either be done by creating an -Empty set of parameters
for you to manually populate, or by defining a hashtable listing all the parameters that are required to create
the specified sensor along with their raw associated values. The parameters for creating a specific type of sensor
can be discovered via a web debugger such as Fiddler or by inspecting the underlying parameters generated by a set
of DynamicSensorParameters.
When accessing RawSensorParameters and DynamicSensorParameters via their indexers, by default PowerShell will
suppress any exceptions thrown when trying to access non-existent properties, instead simply returning $null. This
is due to the default Strict Mode the PowerShell engine runs under. To enable exceptions on accessing invalid
paramters, the strict mode must be set to version 3 or higher. For more information, see Get-Help Set-StrictMode.
Great care should be taken when adding sensors using raw parameters. As there is no type safety, the possibility
of making errors is high. As most raw parameter names end in an underscore, it is critical to ensure these
parameters have been named properly. In the event a sensor is added improperly, it can easily be corrected or
deleted in the PRTG UI. When specifying a hashtable parameter set to New-SensorParameters, PrtgAPI will validate
that at a minimum the 'name_' and 'sensortype' parameters are specified. If either of these two are missing,
New-SensorParameters will generate an exception.
When sensor parameters are created via the Add-Sensor cmdlet, if the -Resolve parameter is specified PrtgAPI will
attempt to resolve the resultant sensors based on the sensor type specified in the sensor parameters. If the
resulting sensor type is capable of changing based on the specified parameters, you can instruct PrtgAPI to
broaden its sensor resolution search by specifying the -DynamicType parameter when creating your parameters
object. DynamicType property can also be modified on the resulting NewSensorParameters object that is returned
from the New-SensorParameters cmdlet.
All sensor parameter types support specifying common sensor parameters (Inherit Triggers, Interval, Priority, etc)
via well typed properties. If these properties are not set, PRTG will automatically use the default values for
these fields based on the type of sensor being created.
PARAMETERS
-Type <SensorType>
The type of sensor to create.
Possible values: ExeXml, WmiService, SqlServerDB, Http, Factory
Required? true
Position? 0
Default value ExeXml
Accept pipeline input? false
Accept wildcard characters? false
-First <object>
The name to give the new sensor. If no value is specified, the default name of the specified sensor type will
be used. If the specified sensor type does not support specifying a name, this field is used for any mandatory
values required by the sensor type.
Required? false
Position? 1
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Second <object>
A mandatory value required by the specified sensor type.
Required? false
Position? 2
Default value
Accept pipeline input? false
Accept wildcard characters? false
-RawParameters <Hashtable>
A collection of raw parameters for adding an unsupported sensor type.
Required? true
Position? 0
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Device <Device>
The device to create a set of DynamicSensorParameters from.
Required? true
Position? named
Default value
Accept pipeline input? true (ByValue)
Accept wildcard characters? false
-RawType <string>
The raw name of the sensor type to create.
Required? true
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Target <string>
Wildcard used to specify the sensor targets to assign to a set of DynamicSensorParameters.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Timeout <int>
Duration (in seconds) to wait for dynamic sensor parameters to resolve.
Required? false
Position? named
Default value 60
Accept pipeline input? false
Accept wildcard characters? false
-QueryTarget <SensorQueryTarget>
A sensor query target to use when retrieving dynamic sensor parameters. Can include wildcards.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-qt <SensorQueryTarget>
A sensor query target to use when retrieving dynamic sensor parameters. Can include wildcards.
This is an alias of the QueryTarget parameter.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-QueryParameters <Hashtable>
A set of sensor query target parameters to use when retrieving dynamic sensor parameters.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-qp <Hashtable>
A set of sensor query target parameters to use when retrieving dynamic sensor parameters.
This is an alias of the QueryParameters parameter.
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
-Empty <SwitchParameter>
Specifies that an empty set of RawSensorParameters should be returned to allow constructing a parameter set
manually.
Required? false
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
-DynamicType <SwitchParameter>
Specifies whether the resulting sensor type is dynamically determined by the parameters included in the
request. If this property is true, PrtgAPI will relax its sensor resolution mechanism to ensure the resultant
object is retrieved.
Required? false
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug,
ErrorAction, ErrorVariable, WarningAction, WarningVariable,
OutBuffer, PipelineVariable, and OutVariable. For more information, see
about_CommonParameters (https:/go.microsoft.com/fwlink/?LinkID=113216).
INPUTS
PrtgAPI.Device
The device to create a set of DynamicSensorParameters from.
OUTPUTS
---------- EXAMPLE 1 ----------
C:\\> $params = New-SensorParameters ExeXml "Custom Script" "CustomScript.ps1"
C:\\> Get-Device dc-1 | Add-Sensor $params
Create a new EXE/Script Advanced sensor on the device dc-1 using the name "Custom Script", that executes the file
"CustomScript.ps1", specifying the script name in the optional -Value parameter
---------- EXAMPLE 2 ----------
C:\\> $params = New-SensorParameters ExeXml "Custom Script"
C:\\> $params.ExeFile = "CustomScript.ps1"
C:\\> Get-Device dc-1 | Add-Sensor $params
Create a new EXE/Script Advanced sensor on the device dc-1 using the name "Custom Script", that executes the file
"CustomScript.ps1", specifying the script name after the object has been created
---------- EXAMPLE 3 ----------
C:\\> $params = New-SensorParameters ExeXml
C:\\> $params.ExeFile = "CheckStatus.ps1"
C:\\> Get-Device -Id 1001 | Add-Sensor $params
Create a new EXE/Script Advanced sensor on the device with ID 1001 using the name "XML Custom EXE/Script Sensor"
that executes the file "CheckStatus.ps1"
---------- EXAMPLE 4 ----------
C:\\> $params = Get-Device esxi-1 | New-SensorParameters -RawType vmwaredatastoreextern
C:\\> $params.datafieldlist__check = $params.Targets["datafieldlist__check"]
C:\\> $params | Add-Sensor
Dynamically create a new set of VMware Datastore credentials for the device named esxi-1 targeting all datastores
that exist on the device.
---------- EXAMPLE 5 ----------
C:\\> $params = Get-Device esxi-1 | New-SensorParameters -RawType vmwaredatastoreextern
C:\\> $params[[PrtgAPI.Parameter]::Custom]
View the raw set of CustomParameters defined on an object.
---------- EXAMPLE 6 ----------
C:\\> $params = Get-Device esxi-1 | New-SensorParameters -RawType exchangepsdatabase
C:\\> $params.Unlock()
C:\\> $params.customparam_ = "some value"
Create a new parameter named "customparam" on a set of Exchange Database sensor parameters.
---------- EXAMPLE 7 ----------
C:\\> $params = New-SensorParameters -Empty
C:\\> $params["name_"] = "My Sensor"
C:\\> $params["sensortype"] = "exexml"
Create an empty set of sensor parameters to manually insert all raw parameters.
---------- EXAMPLE 8 ----------
C:\\> $raw = @{
>> name_ = "my raw sensor"
>> tags_ = "xmlexesensor"
>> priority_ = 4
>> exefile_ = "CustomScript.ps1|CustomScript.ps1||
>> exeparams_ = "arg1 arg2 arg3"
>> environment_ = 1
>> usewindowsauthentication_ = 1
>> mutexname_ = "testMutex"
>> timeout_ = 70
>> writeresult_ = 1
>> intervalgroup = 0
>> interval_ = "30|30 seconds"
>> errorintervalsdown_ = 2
>> sensortype = "exexml"
>> }
C:\\> $params = New-SensorParameters $raw
C:\\> Get-Device dc-1 | Add-Sensor $params
Add a new EXE/Script Advanced sensor to the device named dc-1 using a hashtable containing its raw parameters.
---------- EXAMPLE 9 ----------
C:\\> $params = New-SensorParameters $raw -DynamicType
Create a set of parameters for creating a sensor with a dynamic type (such as snmplibrary).
---------- EXAMPLE 10 ----------
C:\\> Set-StrictMode -Version 3
Set the Strict Mode to version 3 for the current PowerShell session.
---------- EXAMPLE 11 ----------
C:\\> $params = Get-Device -Id 1001 | New-SensorParameters -RawType snmplibrary -qt *ups*
Create a set of parameters for creating a SNMP Library sensor utilizing a wildcard expression that matches the
sensor query target "APC UPS.oidlib".
---------- EXAMPLE 12 ----------
C:\\> $target = (Get-SensorType snmplibrary -Id 1001).QueryTargets | where Value -like *ups*
C:\\> $params = Get-Device -Id 1001 | New-SensorParameters -RawType snmplibrary -qt $target
Create a set of parameters for creating a SNMP Library sensor utilizing the sensor query target "APC UPS.oidlib".
---------- EXAMPLE 13 ----------
C:\\> $params = Get-Device -Id 1001 | New-SensorParameters -RawType ipmisensor -qp @{ username = "admin"; password
= "password" }
Create a set of parameters for creating an IPMI Sensor specifying the query target parameters required to
authenticate to IPMI.
RELATED LINKS
Online version: https://github.com/lordmilko/PrtgAPI/wi ... parameters
Get-Help SensorParameters
Add-Sensor
Get-Device
Set-StrictMode