AvantGuard - NinjaOne icon

AvantGuard - NinjaOne

AvantGuard - NinjaOne

Actions159

Overview

This node operation, "Get Pending Failed Rejected OS Patches," is designed to retrieve a list of operating system patches that are in pending, failed, or rejected states. It is useful for IT administrators and security teams who want to monitor patch compliance and identify problematic patches on devices managed within their environment. By fetching this data, users can prioritize remediation efforts, track patch deployment status, and ensure systems remain secure and up-to-date.

Practical examples include:

  • Automatically generating reports of failed or rejected OS patches for audit purposes.
  • Triggering alerts or workflows when critical patches fail to install.
  • Filtering patches by severity or type to focus on high-risk vulnerabilities.

Properties

Name Meaning
Additional Query Parameters Optional filters and pagination controls to refine the query results. Includes:
- Df (Device filter) Filter patches by specific device identifiers or names.
- Ts (Monitoring timestamp filter) Filter patches based on monitoring timestamps to get recent or historical data.
- Status (Patch Status filter) Filter patches by their status such as pending, failed, or rejected.
- Type (Patch Type filter) Filter patches by their type (e.g., security, feature update).
- Severity (Patch Severity filter) Filter patches by severity level (e.g., critical, important).
- Cursor (Cursor name) Used for pagination to specify the cursor position for the next set of results.
- Page Size (Limit number of records per page) Limits the number of patch records returned per API call.

Output

The node outputs JSON data representing the list of OS patches matching the specified filters. Each item typically includes details such as patch ID, status, type, severity, associated device, and timestamps related to monitoring or application.

If the node supports binary data output, it would generally represent attachments or files related to patches, but based on the provided code and properties, the output is primarily structured JSON data about patches.

Dependencies

  • Requires an API key credential for authentication with the AvantGuard NinjaOne service.
  • The base URL for the API must be configured in the node credentials.
  • Depends on the external AvantGuard NinjaOne API endpoint that provides patch information.
  • Uses standard HTTP headers for JSON content negotiation.

Troubleshooting

  • Common issues:
    • Incorrect or missing API credentials will cause authentication failures.
    • Invalid filter values may result in empty responses or errors from the API.
    • Pagination parameters like cursor and page size need to be handled carefully to avoid missing data or infinite loops.
  • Error messages:
    • Authentication errors usually indicate invalid or expired API keys; reconfigure credentials.
    • Validation errors on query parameters suggest incorrect filter formats; verify input values.
    • Network or timeout errors may require checking connectivity or API availability.

Links and References

Discussion