11 results found

1. Monitor primary storage platforms

   Expand PRTG sensors for primary storage platforms.

   Help us with our survey!
   https://forms.office.com/e/dSRZd1J0rX

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   
   

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   
   

   After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:

   • It doesn't align with our current product roadmap or strategic priorities.
   • The resources required for implementation outweigh the current projected benefits for our user base.
   • There are technical limitations that prevent us from moving forward.
   • A similar feature is already available or planned in a different way.

   
   

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   
   

   Thanks for your understanding and for helping us shape the future of Paessler.

   
   

   Best regards,

   The Paessler Product Team

2. Microsoft Defender Sensor that informs about events in Defender and successful updates

   As a PRTG user I want to get events from Microsoft Defender for single servers to be aware if threats are detected and action is required. As an addition information about successful security updates would be great.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   
   

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   
   

   After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:

   • It doesn't align with our current product roadmap or strategic priorities.
   • The resources required for implementation outweigh the current projected benefits for our user base.
   • There are technical limitations that prevent us from moving forward.
   • A similar feature is already available or planned in a different way.

   
   

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   
   

   Thanks for your understanding and for helping us shape the future of Paessler.

   
   

   Best regards,

   The Paessler Product Team

3. More granular refined user roles

   As a technical PRTG user I want more granular refined user roles. I want to be able to define which time periods are available when doing "Pause" or "Acknowledge" of an alarm. For example, some users should not have the right to select "indefinitely" based on their role.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   
   

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   
   

   After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:

   • It doesn't align with our current product roadmap or strategic priorities.
   • The resources required for implementation outweigh the current projected benefits for our user base.
   • There are technical limitations that prevent us from moving forward.
   • A similar feature is already available or planned in a different way.

   
   

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   
   

   Thanks for your understanding and for helping us shape the future of Paessler.

   
   

   Best regards,

   The Paessler Product Team

4. Monitor firmware revisions for known vulnerabilities

   As a PRTG user I want to monitor firmware revisions for known vulnerabilities.

   Validating existing firmware revisions or whether or not there is an existing vulnerability that needs to be mitigated by firmware upgrades.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   
   

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   
   

   After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:

   • It doesn't align with our current product roadmap or strategic priorities.
   • The resources required for implementation outweigh the current projected benefits for our user base.
   • There are technical limitations that prevent us from moving forward.
   • A similar feature is already available or planned in a different way.

   
   

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   
   

   Thanks for your understanding and for helping us shape the future of Paessler.

   
   

   Best regards,

   The Paessler Product Team

5. Monitoring of local certificate stores in an internal PKI

   It occasionally happens that self-signed certificates in a private PKI expire and cannot be monitored "out of the box" by Paessler. While certificate monitoring on bound ports works well, I would be delighted if, in the future, I could select which certificates (days until expiration, revocation status) I want to monitor in my certificate store.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   
   

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   
   

   After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:

   • It doesn't align with our current product roadmap or strategic priorities.
   • The resources required for implementation outweigh the current projected benefits for our user base.
   • There are technical limitations that prevent us from moving forward.
   • A similar feature is already available or planned in a different way.

   
   

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   
   

   Thanks for your understanding and for helping us shape the future of Paessler.

   
   

   Best regards,

   The Paessler Product Team

6. Monitor virtualization platforms

   Expand PRTG sensors for virtualization platforms.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   
   

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   
   

   After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:

   • It doesn't align with our current product roadmap or strategic priorities.
   • The resources required for implementation outweigh the current projected benefits for our user base.
   • There are technical limitations that prevent us from moving forward.
   • A similar feature is already available or planned in a different way.

   
   

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   
   

   Thanks for your understanding and for helping us shape the future of Paessler.

   
   

   Best regards,

   The Paessler Product Team

7. Template editor

   As a technical PRTG user I would like a default value (recommendation) in percent, which is based on the maximum available memory for my custom sensor. If the memory is increased, the value entered by default remains the same, although it could be much higher due to the larger available memory. A button for switching between absolute value and percentage value can also be added if users use both.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Hi there,

   
   

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   
   

   After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:

   • It doesn't align with our current product roadmap or strategic priorities.
   • The resources required for implementation outweigh the current projected benefits for our user base.
   • There are technical limitations that prevent us from moving forward.
   • A similar feature is already available or planned in a different way.

   
   

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   
   

   Thanks for your understanding and for helping us shape the future of Paessler.

   
   

   Best regards,

   The Paessler Product Team

8. Monitoring a (Windows) DHCP server

   As I PRTG user I would like to monitor the number of remaining leases and usage of available leases.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   Monitoring your Windows DHCP server in PRTG to track remaining leases and usage of available leases is crucial for proactive network management. Here's how you can achieve this, leveraging different PRTG sensor types:

   Methods for Monitoring DHCP Lease Usage in PRTG

   There are a few primary ways to monitor DHCP lease usage in PRTG on a Windows server:

   1. SNMP Custom Sensor (Recommended for direct lease count)
   2. EXE/Script Advanced Sensor with PowerShell (Most flexible and detailed)
   3. PRTG DHCP Sensor (Basic availability check)

   Let's break down each method:

   Method 1: SNMP Custom Sensor (for specific OIDs)

   Windows DHCP servers expose information about their scopes and lease usage via SNMP. This is often the simplest way to get direct numbers for available/used leases per scope.

   Prerequisites:

   • SNMP Service enabled on your Windows DHCP Server: Make sure the SNMP service is installed and running on your DHCP server, and configure a community string that PRTG can use.
   • PRTG Probe: Your PRTG probe needs network access to the DHCP server over SNMP (UDP port 161).

   Steps:

   1. Identify DHCP OIDs: The key to using an SNMP Custom sensor is knowing the correct Object Identifiers (OIDs) for the data you want. For Windows DHCP, common OIDs relate to:

   • Total Addresses in Scope: 1.3.6.1.4.1.311.1.3.2.1.1.2.<DHCP_Scope_Network_ID>
   • Addresses Available (Free) in Scope: 1.3.6.1.4.1.311.1.3.2.1.1.3.<DHCP_Scope_Network_ID>
   • Addresses Used (In Use) in Scope: 1.3.6.1.4.1.311.1.3.2.1.1.4.<DHCP_Scope_Network_ID>

   1. Important: Replace <DHCP_Scope_Network_ID> with the actual network ID of your DHCP scope. For example, if your scope is 192.168.1.0, the OID for available addresses would be 1.3.6.1.4.1.311.1.3.2.1.1.3.192.168.1.0.
   2. Tip: You can use an SNMP walk tool (like snmpwalk.exe) from a machine with network access to the DHCP server to discover available OIDs and their values for your specific server and scopes.
   3. Add a Device in PRTG: If you haven't already, add your Windows DHCP server as a device in PRTG.
   4. Add an SNMP Custom Sensor:

   • Right-click on your DHCP server device in PRTG and select Add Sensor.
   • Search for "SNMP Custom" and select it.
   • Sensor Name: Give it a descriptive name, e.g., "DHCP Scope 192.168.1.0 - Available Leases".
   • OID: Enter the specific OID you identified (e.g., 1.3.6.1.4.1.311.1.3.2.1.1.3.192.168.1.0).
   • SNMP Credentials: Ensure you're using the correct SNMP community string configured on your DHCP server.
   • Data Type: Set the data type (e.g., "Integer" or "Float").
   • Unit: You can set the unit to "Leases" or "IPs".
   • Repeat this process for each scope and for "Used Leases" if you want separate sensors for those.

   1. Calculate Usage Percentage (Optional, via Custom Sensor Calculation):

   • To get the usage percentage, you'll likely need two SNMP Custom sensors (one for "Addresses Available" and one for "Total Addresses").
   • Then, you can create a Custom Sensor (Calculated) in PRTG that uses the values from these two sensors to calculate the percentage: (Total Addresses - Available Addresses) / Total Addresses * 100.

   Method 2: EXE/Script Advanced Sensor with PowerShell

   This method offers the most flexibility as you can write a PowerShell script to gather highly specific DHCP information, including lease usage, and then output it in a format PRTG can understand.

   Prerequisites:

   • PowerShell Remoting (or local execution on probe): The PRTG probe needs to be able to execute PowerShell scripts on the DHCP server. This often means enabling PowerShell Remoting on the DHCP server and configuring appropriate permissions for the PRTG agent or user context. Alternatively, if the PRTG probe is running on the DHCP server itself, the script can be executed locally.
   • DHCP Server Tools (PowerShell Module): Ensure the "DHCP Server Tools" feature (which includes the DHCP PowerShell module) is installed on the machine where the script will run (either the PRTG probe or the DHCP server itself). You can add this feature with Add-WindowsFeature RSAT-DHCP.

   Steps:

   1. Create a PowerShell Script:
   2. Here's an example PowerShell script to get DHCP scope utilization. You'll need to save this script (e.g., Get-DhcpScopeUsage.ps1) in the Custom Sensors folder on your PRTG probe.
   3. PowerShell
   4. 
      

   # Get-DhcpScopeUsage.ps1 param( [string]$DHCPServer = $env:COMPUTERNAME # Defaults to local machine if not specified ) try { Import-Module DhcpServer -ErrorAction Stop $scopes = Get-DhcpServerv4Scope -ComputerName $DHCPServer foreach ($scope in $scopes) { $scopeID = $scope.ScopeId.ToString() $totalAddresses = ($scope.EndRange - $scope.StartRange).ToString() $addressesInUse = $scope.Leases.Count.ToString() # This might vary depending on exact PowerShell version and objects $addressesFree = $scope.FreeLeases.ToString() $percentageUsed = [math]::Round(($addressesInUse / $totalAddresses) * 100, 2) # PRTG expects output in the format: ChannelName:Value|ChannelName:Value... # For each scope, you can output multiple channels. Write-Host "DHCP_Scope_$($scopeID)_Used:$addressesInUse`r`n" Write-Host "DHCP_Scope_$($scopeID)_Free:$addressesFree`r`n" Write-Host "DHCP_Scope_$($scopeID)_Total:$totalAddresses`r`n" Write-Host "DHCP_Scope_$($scopeID)_UsagePercent:$percentageUsed`r`n" } } catch { Write-Error "Error retrieving DHCP scope information: $($_.Exception.Message)" # Exit with a non-zero code to indicate an error to PRTG exit 1 }

   • Refinement for AddressesInUse: The way Leases.Count is accessed might vary slightly depending on your Windows Server version. A more robust way to get used addresses might involve Get-DhcpServerv4Lease -ScopeId $scope.ScopeId -ComputerName $DHCPServer | Measure-Object | Select-Object -ExpandProperty Count.
   • Dynamic Server Name: The $DHCPServer parameter allows you to specify the DHCP server name. If the sensor is on the DHCP server itself, $env:COMPUTERNAME will work. If the sensor is on a separate probe, you can pass %host in PRTG as a parameter to use the device's IP/DNS name.
   • Output Format: The Write-Host lines generate the PRTG-specific output. Each ChannelName:Value pair creates a new channel in the PRTG sensor. \r\n ensures a new line for each channel.

   1. Add an EXE/Script Advanced Sensor in PRTG:

   • Right-click on your DHCP server device in PRTG and select Add Sensor.
   • Search for "EXE/Script Advanced" and select it.
   • Sensor Name: "DHCP Lease Usage (PowerShell)".
   • Program File: Select your PowerShell executable (e.g., C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe).
   • Parameters:To execute your script: -ExecutionPolicy Bypass -File "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-DhcpScopeUsage.ps1" -DHCPServer %host
   • Adjust the path to your script if you saved it elsewhere.
   • %host will automatically pass the IP address or DNS name of the parent device (your DHCP server) to the script.
   • Security Context: Choose "Use Windows credentials of parent device" and ensure the account configured for the device has permissions to run DHCP PowerShell cmdlets. You might need to add the user to the "DHCP Users" Active Directory group.

   1. Configure Channels and Notifications:

   • Once the sensor runs successfully, PRTG will automatically detect the channels (e.g., DHCP_Scope_192.168.1.0_Used, DHCP_Scope_192.168.1.0_UsagePercent).
   • You can then configure limits and notifications on these channels to alert you when usage reaches a certain threshold (e.g., 80% used).

   Method 3: PRTG DHCP Sensor (Basic Availability)

   PRTG includes a built-in DHCP sensor. While useful for verifying if a DHCP server is responding and offering IP addresses, it does not directly provide the number of remaining leases or usage percentage for specific scopes. Its primary function is to:

   • Send a broadcast message requesting an IP address.
   • Report the response time of the DHCP server.
   • Show the IP address offered and its lease duration.
   • Confirm if any DHCP server is responding.

   When to use it:

   • To check the basic health and responsiveness of your DHCP service.
   • To ensure DHCP is allocating addresses.

   How to add:

   1. Right-click on a probe device (not directly on your DHCP server if it's not the probe itself).
   2. Select Add Sensor.
   3. Search for "DHCP Sensor" and select it.
   4. Configure the sensor by choosing the network card on the probe that will send the broadcast.

   Key Considerations for DHCP Monitoring

   • SNMP vs. PowerShell:SNMP: Simpler to set up for basic counts if the OIDs are readily available and consistent across your DHCP servers. Less overhead.
   • PowerShell: More powerful and flexible. Allows for custom calculations, filtering, and gathering of more granular data. Requires more configuration for remoting/permissions.
   • Permissions: Ensure the PRTG probe or the Windows credentials used by the sensor have the necessary permissions to query DHCP server information. For PowerShell, this typically means the user needs to be in the "DHCP Users" group in Active Directory.
   • Thresholds and Notifications: Set appropriate warning and error thresholds for your lease usage percentages (e.g., warning at 80% used, error at 90% used). Configure notifications (email, SMS, push) to alert you well before you run out of IP addresses.
   • Historical Data and Trending: PRTG will automatically collect historical data, allowing you to visualize trends in DHCP lease usage over time. This is invaluable for capacity planning.
   • Multiple Scopes: If you have multiple DHCP scopes on a single server, you'll need to set up individual sensors (either SNMP Custom or tailor your PowerShell script) for each scope to get detailed usage information per scope.

   By implementing one or a combination of these methods, you'll gain excellent visibility into your Windows DHCP server's lease utilization and be able to proactively address potential IP address exhaustion issues.

   
   

   Monitoring your Windows DHCP server in PRTG to track remaining leases and usage of available leases is crucial for proactive network management. Here's how you can achieve this, leveraging different PRTG sensor types:

   Methods for Monitoring DHCP Lease Usage in PRTG

   There are a few primary ways to monitor DHCP lease usage in PRTG on a Windows server:

   1. SNMP Custom Sensor (Recommended for direct lease count)
   2. EXE/Script Advanced Sensor with PowerShell (Most flexible and detailed)
   3. PRTG DHCP Sensor (Basic availability check)

   Let's break down each method:

   Method 1: SNMP Custom Sensor (for specific OIDs)

   Windows DHCP servers expose information about their scopes and lease usage via SNMP. This is often the simplest way to get direct numbers for available/used leases per scope.

   Prerequisites:

   • SNMP Service enabled on your Windows DHCP Server: Make sure the SNMP service is installed and running on your DHCP server, and configure a community string that… more

9. Monitoring a Citrix environment

   As a PRTG user I would like to monitor in a Citrix environment the number of login errors in the last few hours, unregistered machines that are turned on and therefore should be registered.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

   This is already possible and we'd need more info before accepting this idea.

   
   

   Monitoring a Citrix environment effectively with PRTG to track login errors and unregistered machines requires a combination of built-in sensors, custom scripts, and a good understanding of Citrix's monitoring capabilities.

   Here's a breakdown of how you can achieve this:

   1. Monitoring Login Errors

   Citrix environments generate various events related to user logins, including successful, failed, and slow logins. To monitor login errors in PRTG, you'll primarily leverage Windows Event Log sensors and potentially custom PowerShell scripts that query Citrix-specific performance counters or the Citrix API.

   Methods:

   • Windows Event Log Sensor (Recommended for basic errors):Concept: Citrix components (Delivery Controllers, StoreFront servers, VDAs) log events in the Windows Event Log. Failed logins often generate specific Event IDs.

   1. Implementation:Identify relevant Event IDs: Research Citrix documentation for common Event IDs related to failed logins (e.g., in Application or System logs, or Citrix-specific logs if available). You might need to test failed logins to see what events are generated in your environment.

   • Create a PRTG Windows Event Log Sensor:Add a new sensor to your Citrix Delivery Controllers or StoreFront servers.
   • Select the "Windows Event Log (System, Application, Security, etc.)" sensor type.
   • Configure the sensor to monitor the relevant log(s) and filter by the specific Event IDs associated with login failures.
   • Set up thresholds to trigger warnings or errors when the count of these events exceeds a certain number within a defined timeframe (e.g., "in the last few hours").
   • You can use the "Count" channel to see the number of errors.
   • Custom PowerShell Script (For advanced insights/Citrix API):Concept: Citrix provides PowerShell cmdlets and APIs (e.g., Citrix Director API, Citrix Cloud APIs) that can provide more granular information about user sessions, including login failures and their causes (e.g., unavailable resources, licensing issues).
   • Implementation:Develop a PowerShell script:The script would connect to your Citrix environment (e.g., using Add-PSSnapin Citrix.* or Import-Module Citrix.PowerShell.Sdk).
   • Query for failed login attempts within your desired timeframe using cmdlets like Get-BrokerSession or Get-BrokerConnection and filtering by status or error codes.
   • Output the count of login errors in a PRTG-compatible XML format.
   • Create a PRTG EXE/Script Advanced Sensor:Deploy your PowerShell script to the PRTG probe server.
   • Create an "EXE/Script Advanced" sensor on a relevant Citrix server (e.g., a Delivery Controller).
   • Configure the sensor to execute your PowerShell script.
   • PRTG will parse the XML output from your script to create channels for the number of login errors.
   • Set up appropriate thresholds and notifications.
   • Considerations: This method offers more flexibility but requires scripting knowledge and proper permissions for the service account running the PRTG probe.

   2. Monitoring Unregistered Machines

   Unregistered machines in a Citrix environment are VDAs (Virtual Delivery Agents) that are turned on but not registered with the Delivery Controller. This means they are unavailable to users.

   Methods:

   • Custom PowerShell Script with Get-BrokerMachine (Recommended):Concept: The Get-BrokerMachine PowerShell cmdlet is the most effective way to identify the registration status of your VDAs.
   • Implementation:Develop a PowerShell script:Connect to your Citrix Delivery Controller.
   • Use Get-BrokerMachine -RegistrationState Unregistered -PowerState On to retrieve a list of machines that are powered on but unregistered.
   • Count these machines.
   • Output the count in PRTG-compatible XML format. You could also include the names of the unregistered machines in the output message for better context.
   • Create a PRTG EXE/Script Advanced Sensor:Deploy the script to your PRTG probe.
   • Create an "EXE/Script Advanced" sensor on a Delivery Controller.
   • Configure the sensor to run your script and parse the XML output.
   • Set thresholds to alert you when the number of unregistered machines exceeds zero, or a predefined acceptable number.
   • Citrix Director Alerts (as a supplementary method):Concept: Citrix Director itself has alerting capabilities for unregistered machines. While not directly integrated into PRTG, you could configure Director to send email alerts, and then set up PRTG to monitor the mailbox for those specific alerts (less ideal, but an option if direct scripting is challenging).

   1. Implementation:Configure alerts in Citrix Director for "Unregistered machines (%)" or similar metrics.
   2. Set up email notifications within Director.
   3. Configure a PRTG "IMAP/POP3 Sensor" or "SMTP Sensor" to monitor the mailbox that receives these alerts, looking for specific subject lines or content.

   General PRTG Setup Considerations:

   • Credentials: Ensure the PRTG probe has the necessary credentials to access the Citrix environment. This typically means a domain user account with read-only permissions within Citrix Studio and local administrator rights on the Citrix servers for event log access or running PowerShell scripts.
   • Remote PowerShell: If running scripts on a remote machine from the PRTG probe, ensure PowerShell remoting is enabled and configured correctly.
   • Probe Placement: Place your PRTG probe strategically. For Citrix monitoring, it's often best to have a probe near or on a Delivery Controller or a server that can access the Citrix environment without excessive network latency.
   • Scanning Intervals: Adjust the scanning interval of your sensors to balance between real-time monitoring and system load. For critical alerts like unregistered machines, a shorter interval (e.g., 1-5 minutes) is appropriate. For login errors, it depends on how quickly you need to react.
   • Notifications: Configure PRTG notifications (email, SMS, push notifications, etc.) to alert the relevant IT team members when thresholds are breached.
   • Dashboards and Reports: Create custom dashboards in PRTG to visualize the number of login errors and unregistered machines over time. This helps in trend analysis and identifying recurring issues. Generate reports to share with management or for compliance purposes.
   • Error Handling in Scripts: If using custom scripts, include robust error handling to ensure the script doesn't fail silently and provides meaningful error messages to PRTG.

   By combining these approaches, you can build a comprehensive PRTG monitoring solution for login errors and unregistered machines in your Citrix environment, allowing for proactive issue detection and faster resolution.

   
   

   This is already possible and we'd need more info before accepting this idea.

   
   

   Monitoring a Citrix environment effectively with PRTG to track login errors and unregistered machines requires a combination of built-in sensors, custom scripts, and a good understanding of Citrix's monitoring capabilities.

   Here's a breakdown of how you can achieve this:

   1. Monitoring Login Errors

   Citrix environments generate various events related to user logins, including successful, failed, and slow logins. To monitor login errors in PRTG, you'll primarily leverage Windows Event Log sensors and potentially custom PowerShell scripts that query Citrix-specific performance counters or the Citrix API.

   Methods:

   • Windows Event Log Sensor (Recommended for basic errors):Concept: Citrix components (Delivery Controllers, StoreFront servers, VDAs) log events in the Windows Event Log. Failed logins often generate specific Event IDs.

   1. Implementation:Identify relevant Event IDs: Research Citrix documentation for common Event IDs related to failed logins (e.g., in Application or System logs, or… more

10. Snapshot monitoring (primarily VMware, HyperV)

    We often encounter customer environments where snapshots remain after updates or are not cleaned up by the backup software in use. This leads to cluster volumes filling up and impacts machine performance.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

    There are other ways to solve this as there is not a lot of demand.

    
    

    PRTG is an excellent tool for implementing your snapshot monitoring idea, as it's highly flexible and supports custom sensors.1 While PRTG has built-in sensors for VMware and Hyper-V, they don't natively provide detailed snapshot age and size information out-of-the-box for every VM. This is where Custom Sensors (specifically EXE/Script Advanced sensors) come into play.

    Here's how you can achieve snapshot monitoring in PRTG for both VMware and Hyper-V:

    General Approach for PRTG Custom Sensors

    The core idea is to use PowerShell scripts (for both VMware and Hyper-V) that connect to your virtualization environment, query snapshot information, and then output that data in a format that PRTG can understand (PRTG XML or simple numeric output).

    PRTG XML Format:

    PRTG expects XML output for advanced custom sensors, allowing you to create multiple channels (e.g., snapshot count, oldest snapshot age, total snapshot size) from a single script execution.

    A basic PRTG XML output looks like this:

    XML

    
    

    <prtg> <result> <channel>Snapshot Count</channel> <value>5</value> <unit>Count</unit> </result> <result> <channel>Oldest Snapshot Age (Days)</channel> <value>7</value> <unit>Days</unit> <float>0</float> </result> <result> <channel>Total Snapshot Size (GB)</channel> <value>150.25</value> <unit>Gigabyte</unit> <float>1</float> </result> <text>Successfully queried snapshot data.</text> </prtg>

    1. VMware Snapshot Monitoring with PRTG

    For VMware, you'll leverage VMware PowerCLI and a PowerShell script.

    Prerequisites:

    1. PRTG Probe: Ensure your PRTG probe (local or remote) has network access to your vCenter Server (or individual ESXi hosts if not using vCenter).
    2. VMware PowerCLI: Install VMware PowerCLI on the PRTG probe server where the sensor will run. You can install it via PowerShell Gallery: Install-Module -Name VMware.PowerCLI -Scope AllUsers
    3. Credentials: Have a VMware user account with read-only permissions to view VM and snapshot information.

    Steps:

    1. Create the PowerShell Script:
    2. You'll need a PowerShell script that:

    • Connects to your vCenter Server.
    • Iterates through all VMs or specific VMs.
    • For each VM, checks for snapshots.
    • If snapshots exist, retrieves their creation time and size.
    • Calculates the age of the oldest snapshot and the total size of all snapshots for that VM.
    • Outputs this data in PRTG XML format.

    1. Example (Conceptual) PowerShell Snippet:
    2. PowerShell
    3. 
       

    # PRTG-VMware-Snapshot-Monitor.ps1 param( [string]$vCenterServer, [string]$VMUser, [string]$VMPassword ) Add-PSSnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue try { Connect-VIServer -Server $vCenterServer -User $VMUser -Password $VMPassword -WarningAction SilentlyContinue | Out-Null $output = "<prtg>" $vms = Get-VM | Where-Object { $_.PowerState -eq "PoweredOn" } # Or filter as needed foreach ($vm in $vms) { $snapshots = Get-Snapshot -VM $vm if ($snapshots.Count -gt 0) { $oldestSnapshotAgeDays = ($snapshots | Measure-Object -Property Created -Minimum).Minimum | ForEach-Object { (New-TimeSpan -Start $_ -End (Get-Date)).Days } $totalSnapshotSizeGB = ($snapshots | Measure-Object -Property SizeGB -Sum).Sum $output += "<result>" $output += "<channel>" + $vm.Name + " - Snapshot Count</channel>" $output += "<value>" + $snapshots.Count + "</value>" $output += "<unit>Count</unit>" $output += "</result>" $output += "<result>" $output += "<channel>" + $vm.Name + " - Oldest Snapshot Age (Days)</channel>" $output += "<value>" + [int]$oldestSnapshotAgeDays + "</value>" $output += "<unit>Days</unit>" $output += "</result>" $output += "<result>" $output += "<channel>" + $vm.Name + " - Total Snapshot Size (GB)</channel>" $output += "<value>" + [math]::Round($totalSnapshotSizeGB, 2) + "</value>" $output += "<unit>Gigabyte</unit>" $output += "<float>1</float>" $output += "</result>" } } $output += "</prtg>" Write-Output $output } catch { Write-Host "<prtg><error>1</error><text>Error: $($_.Exception.Message)</text></prtg>" } finally { Disconnect-VIServer -Confirm:$false | Out-Null }

    1. Important: You can find existing community scripts on GitHub (like Jannos-443/PRTG-VMware-Snapshot) that do exactly this.2 Search for "PRTG VMware snapshot powershell script" to find reliable examples and adapt them to your needs.
    2. Place the Script:
    3. Save the .ps1 script in the C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML folder on your PRTG probe.
    4. Create the Sensor in PRTG:

    • In PRTG, navigate to the device (your vCenter server or an ESXi host).
    • Click "Add Sensor".
    • Search for "EXE/Script Advanced".
    • Sensor Name: Give it a descriptive name (e.g., "VMware Snapshot Overview").
    • EXE/Script: Select your PRTG-VMware-Snapshot-Monitor.ps1 from the dropdown.
    • Parameters: Provide the required parameters, for example: -vCenterServer "your_vcenter_fqdn" -VMUser "your_vmware_username" -VMPassword "your_vmware_password" (Note: It's better practice to use PRTG's built-in credential system. You can configure the parent device's credentials and then use placeholders like %host, %username, %password in the script parameters if the script supports it or adapts it.)
    • Scanning Interval: Set an appropriate interval (e.g., 30 minutes or 1 hour).
    • Timeout: Increase the timeout significantly (e.g., 300 seconds) if you have a large environment, as PowerCLI cmdlets can be slow.
    • Click "Create Sensor".

    1. Configure Thresholds:
    2. Once the sensor starts collecting data, go into its settings. For each channel (e.g., "VM Name - Snapshot Count", "VM Name - Oldest Snapshot Age (Days)", "VM Name - Total Snapshot Size (GB)"), you can set:

    • Warning Limits: (e.g., "Snapshot Count > 1", "Oldest Snapshot Age (Days) > 3")
    • Error Limits: (e.g., "Snapshot Count > 2", "Oldest Snapshot Age (Days) > 7", "Total Snapshot Size (GB) > 100") This will trigger PRTG notifications when thresholds are breached.

    2. Hyper-V Snapshot (Checkpoint) Monitoring with PRTG

    For Hyper-V, you'll use PowerShell and WMI.

    Prerequisites:

    1. PRTG Probe: Ensure your PRTG probe has network access and appropriate permissions (WMI access) to your Hyper-V hosts.
    2. Credentials: A Windows user account with administrator privileges on the Hyper-V hosts (or sufficient permissions to query Hyper-V WMI namespaces).

    Steps:

    1. Create the PowerShell Script:
    2. This script will connect to each Hyper-V host, query for VMs, and then for checkpoints (snapshots) associated with those VMs.
    3. PowerShell
    4. 
       

    # PRTG-HyperV-Checkpoint-Monitor.ps1 param( [string]$HyperVHost # Can be an IP or FQDN of the Hyper-V host ) $output = "<prtg>" try { $vms = Get-VM -ComputerName $HyperVHost -ErrorAction Stop foreach ($vm in $vms) { $checkpoints = Get-VMCheckpoint -VM $vm -ComputerName $HyperVHost -ErrorAction SilentlyContinue if ($checkpoints.Count -gt 0) { # Calculate oldest checkpoint age $oldestCheckpointAgeDays = ($checkpoints | Measure-Object -Property CreationTime -Minimum).Minimum | ForEach-Object { (New-TimeSpan -Start $_ -End (Get-Date)).Days } # Calculate total checkpoint size (this is trickier for Hyper-V) # Hyper-V checkpoint files (.avhdx) are in the VM's snapshot folder. # You'd need to get the VM's path and then sum the sizes of .avhdx files related to that VM. # This requires more complex logic, potentially searching the VM's configuration for checkpoint paths. # For simplicity, you might initially just monitor count and age, or look for specific avhdx files. # A more robust script would enumerate the .avhdx files associated with the VM and sum their sizes. # Example (simplified, may need refinement for nested checkpoints): $vmPath = (Get-VM $vm.Name -ComputerName $HyperVHost).Path # This usually gives the VM config path # Need to find the actual .avhdx files. This is not directly exposed as 'size' like VMware. # A common approach is to find the .avhdx files in the VM's virtual hard disk folder # or where the checkpoints are configured to be stored. # Let's assume for now we just get the count and age due to complexity of reliable size calculation via WMI/PowerShell. $output += "<result>" $output += "<channel>" + $vm.Name + " - Checkpoint Count</channel>" $output += "<value>" + $checkpoints.Count + "</value>" $output += "<unit>Count</unit>" $output += "</result>" $output += "<result>" $output += "<channel>" + $vm.Name + " - Oldest Checkpoint Age (Days)</channel>" $output += "<value>" + [int]$oldestCheckpointAgeDays + "</value>" $output += "<unit>Days</unit>" $output += "</result>" # If you can implement reliable size calculation, add it here: # $output += "<result>" # $output += "<channel>" + $vm.Name + " - Total Checkpoint Size (GB)</channel>" # $output += "<value>" + [math]::Round($totalCheckpointSizeGB, 2) + "</value>" # $output += "<unit>Gigabyte</unit>" # $output += "<float>1</float>" # $output += "</result>" } } $output += "</prtg>" Write-Output $output } catch { Write-Host "<prtg><error>1</error><text>Error: $($_.Exception.Message)</text></prtg>" }

    1. Note on Hyper-V Checkpoint Size: Hyper-V doesn't expose checkpoint size as readily as VMware via standard cmdlets. To get accurate sizes, you'd typically need to find the .avhdx files associated with the VM and its checkpoints and sum their sizes. This often involves parsing the VM's configuration XML or traversing the file system where the VM's VHDX and AVHDX files are stored. This can make the script more complex.
    2. Place the Script:
    3. Save the .ps1 script in the C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML folder on your PRTG probe.
    4. Create the Sensor in PRTG:

    • In PRTG, navigate to the Hyper-V host device.
    • Click "Add Sensor".
    • Search for "EXE/Script Advanced".
    • Sensor Name: "Hyper-V Checkpoint Overview".
    • EXE/Script: Select your PRTG-HyperV-Checkpoint-Monitor.ps1.
    • Parameters: -HyperVHost "%host" (assuming the parent device is the Hyper-V host and its IP/FQDN is used). Ensure the device credentials have WMI access.
    • Scanning Interval: Set an appropriate interval.
    • Timeout: Adjust as needed.
    • Click "Create Sensor".

    1. Configure Thresholds:
    2. Similar to VMware, configure warning and error limits for "Checkpoint Count" and "Oldest Checkpoint Age (Days)" channels.

    Best Practices and Considerations

    • Dedicated Probe: For large virtual environments, consider running these custom sensors on a dedicated PRTG remote probe that has PowerCLI/PowerShell access and resources to execute the scripts without impacting your core PRTG server.
    • Permissions: Ensure the user account PRTG uses for the probe (or the credentials configured on the device) has the necessary permissions to query VMware vCenter/ESXi (read-only for PowerCLI) and Hyper-V hosts (WMI access, usually local administrator or a dedicated monitoring user).
    • Error Handling: Include robust error handling in your PowerShell scripts to provide meaningful error messages to PRTG, rather than just script failures.
    • Logging: Add logging within your PowerShell scripts to help troubleshoot if a sensor isn't working as expected.
    • Performance Impact: Be mindful of the performance impact of frequent script execution on your vCenter/ESXi hosts and Hyper-V hosts, especially in large environments. Adjust scanning intervals accordingly.
    • Exclusions/Inclusions: If you have certain VMs that are intentionally snapshotted for longer periods (e.g., test environments, VDI master images), consider adding logic to your scripts to exclude them from alerts or to have separate thresholds for them.
    • Datastore/Volume Monitoring: Complement snapshot monitoring with direct monitoring of your datastores (VMware) and cluster shared volumes (Hyper-V) for free space. PRTG has built-in sensors for this (e.g., VMware Datastore (SOAP), Windows Disk Free for CSVs). This helps identify if snapshot bloat is actually causing storage issues.
    • Backup Software Integration: While a PRTG custom sensor won't directly "integrate" with backup software, you can set up alerts in PRTG that coincide with your backup windows. If a snapshot persists after a backup window, it's a strong indicator of a backup issue.

    By combining PRTG's custom sensor capabilities with robust PowerShell scripting, you can build a powerful and proactive snapshot monitoring solution that addresses the common issues you've identified.

    
    

    There are other ways to solve this as there is not a lot of demand.

    
    

    PRTG is an excellent tool for implementing your snapshot monitoring idea, as it's highly flexible and supports custom sensors.1 While PRTG has built-in sensors for VMware and Hyper-V, they don't natively provide detailed snapshot age and size information out-of-the-box for every VM. This is where Custom Sensors (specifically EXE/Script Advanced sensors) come into play.

    Here's how you can achieve snapshot monitoring in PRTG for both VMware and Hyper-V:

    General Approach for PRTG Custom Sensors

    The core idea is to use PowerShell scripts (for both VMware and Hyper-V) that connect to your virtualization environment, query snapshot information, and then output that data in a format that PRTG can understand (PRTG XML or simple numeric output).

    PRTG XML Format:

    PRTG expects XML output for advanced custom sensors, allowing you to create multiple channels (e.g., snapshot count, oldest… more

11. Monitor quota used vs. quota assigned in the MS365 sensor

    As a PRTG user I would like to be able to monitor if a mailbox is getting to it’s assigned limit. This would help me prevent outages because if full mailboxes.

    Data might be available via the Graph API.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    Declined  ·  AdminJonah Kowall (SVP Product and Design, Paessler) responded

    There are too many specifics and use cases around this. Is this across the origanization or a single user. You can build a custom sensor approach for this one. Here are the details.

    
    

    Proactively Monitor Microsoft 365 Mailbox Quotas with PRTG to Prevent Outages

    Stay ahead of mailbox capacity issues and prevent disruptive service outages by leveraging the power of the Microsoft Graph API and custom PRTG sensors. This guide will walk you through the process of monitoring individual mailbox usage against their assigned quotas, providing you with the visibility needed to take preemptive action.

    Microsoft 365 administrators can now transition from reactive responses to proactive management of mailbox storage. By closely tracking the percentage of used storage against the assigned quota for each user, you can identify mailboxes nearing their limit and intervene before users are unable to send or receive emails. This is achievable through a combination of the Microsoft Graph API, which provides detailed mailbox usage data, and a custom sensor within your existing PRTG Network Monitor setup.

    Unlocking Mailbox Quota Data with the Microsoft Graph API

    The key to this monitoring solution lies within the Microsoft Graph API, specifically the getMailboxUsageDetail report. This powerful reporting tool provides a comprehensive breakdown of mailbox statistics, including the crucial data points for our purpose:

    • Storage Used (Byte): The current size of a user's mailbox.
    • Issue Warning Quota (Byte): The storage limit at which a user will receive a warning notification.
    • Prohibit Send Quota (Byte): The storage limit at which a user will be prevented from sending new emails.
    • Prohibit Send/Receive Quota (Byte): The hard limit at which a user can no longer send or receive emails.

    To access this data, you will need to make a GET request to the following Graph API endpoint:

    https://graph.microsoft.com/v1.0/reports/getMailboxUsageDetail(period='D7')

    The period parameter can be set to 'D7', 'D30', 'D90', or 'D180' to retrieve data over different timeframes. The response from this endpoint is a CSV file containing the detailed mailbox usage statistics for all users in your tenant.

    Essential Permissions for Graph API Access

    To authorize your monitoring script to access this data, you will need to create an application registration in Azure Active Directory and grant it the necessary API permissions. The required permission for accessing the getMailboxUsageDetail report is:

    • Reports.Read.All

    This permission can be granted for either delegated or application-level authentication, depending on your security policies and scripting approach.

    Integrating with PRTG: The Custom Sensor Approach

    While PRTG offers a built-in "Microsoft 365 Mailbox Sensor," its functionality is primarily focused on monitoring email counts and age rather than storage quotas. Therefore, a custom sensor is the recommended and most effective solution for this specific monitoring need.

    You can create a custom PRTG sensor using a PowerShell script. This script will be responsible for:

    1. Authenticating with the Microsoft Graph API: Using the credentials of your Azure AD application registration.
    2. Making the GET request to the getMailboxUsageDetail endpoint.
    3. Parsing the returned CSV data.
    4. Identifying specific mailboxes to monitor.
    5. Calculating the percentage of used storage against the "Prohibit Send/Receive Quota".
    6. Returning the results to PRTG in the required format.

    Step-by-Step Guide to Creating a Custom PRTG Sensor for Mailbox Quotas

    Here is a high-level overview of the steps involved in setting up your custom monitoring solution:

    1. Create an Azure AD App Registration:

    • In the Azure portal, navigate to Azure Active Directory > App registrations > New registration.
    • Give your application a descriptive name, such as "PRTG Mailbox Quota Monitor."
    • Under "Supported account types," select the option that best suits your organization's needs.
    • You do not need to configure a Redirect URI for this script-based approach.
    • Once created, take note of the Application (client) ID and Directory (tenant) ID.
    • Under Certificates & secrets, create a new client secret and securely store its value.

    2. Grant API Permissions:

    • In your newly created app registration, go to API permissions > Add a permission.
    • Select Microsoft Graph and then choose Application permissions.
    • Search for and select Reports.Read.All.
    • Click Add permissions.
    • Finally, click on Grant admin consent for [Your Tenant Name].

    3. Develop the PowerShell Script:

    • Create a new PowerShell script (.ps1) that will be executed by your PRTG custom sensor.
    • This script will need to handle authentication with the Graph API using the stored credentials.
    • It will then call the getMailboxUsageDetail endpoint and process the CSV data.
    • The script should be designed to accept the user principal name (UPN) of the mailbox to monitor as a parameter.
    • For the specified mailbox, it will calculate the used storage percentage.
    • The script must output the result in a format that PRTG can understand (e.g., value:message). For example: 85:Mailbox usage is at 85%.

    4. Configure the Custom Sensor in PRTG:

    • Place your PowerShell script in the C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML folder on your PRTG probe server.
    • In the PRTG web interface, add a new device or select an existing one where you want to add the sensor.
    • Choose Add Sensor and select the EXE/Script Advanced sensor type.
    • Give the sensor a descriptive name, such as "Mailbox Quota - [email protected]."
    • From the EXE/Script dropdown, select your PowerShell script.
    • In the Parameters field, pass the UPN of the mailbox you wish to monitor.
    • Configure the scanning interval and other sensor settings as needed.
    • Set thresholds for "Warning" and "Down" states based on the returned percentage value to trigger alerts.

    By following these steps, you will have a robust and automated system for monitoring Microsoft 365 mailbox quotas directly within your PRTG environment. This proactive approach will empower you to prevent service disruptions and ensure a seamless email experience for your users.

    
    

    There are too many specifics and use cases around this. Is this across the origanization or a single user. You can build a custom sensor approach for this one. Here are the details.

    
    

    Proactively Monitor Microsoft 365 Mailbox Quotas with PRTG to Prevent Outages

    Stay ahead of mailbox capacity issues and prevent disruptive service outages by leveraging the power of the Microsoft Graph API and custom PRTG sensors. This guide will walk you through the process of monitoring individual mailbox usage against their assigned quotas, providing you with the visibility needed to take preemptive action.

    Microsoft 365 administrators can now transition from reactive responses to proactive management of mailbox storage. By closely tracking the percentage of used storage against the assigned quota for each user, you can identify mailboxes nearing their limit and intervene before users are unable to send or receive emails. This is achievable through a combination of… more