48 docs tagged with "Custom Fields"

Audits BitLocker encryption status and TPM hardware details, populating detailed HTML reports into NinjaRMM custom fields.

This solution provides a comprehensive auditing framework for BitLocker encryption and Trusted Platform Module (TPM) security status on Windows endpoints within NinjaOne. It eliminates the need for manual checks by automatically collecting granular encryption data and hardware security details, formatting them into easy-to-read HTML reports stored directly in NinjaRMM Custom Fields.

This compound condition performs BitLocker and TPM audit once per day on Windows servers where auditing is enabled from cPVAL Enable BitLocker Audit custom field. If set to Disable, the audit will not be performed.

This compound condition performs BitLocker and TPM audit once per day on Windows workstations where auditing is enabled from cPVAL Enable BitLocker Audit custom field. If set to Disable, the audit will not be performed.

Evaluates the BitLocker compliance status of an endpoint against policies defined in NinjaRMM Custom Fields.

Automates BitLocker initialization on Windows devices using NinjaOne custom fields, including encryption method selection, key protector configuration, and secure execution with logging.

This script is used to show the FileVault status on macOS devices by updating the NinjaRMM custom field `cPVAL FileVault Status` to indicate whether FileVault is enabled or not.

Detects whether the installed Windows OS is a Home edition and updates the NinjaOne custom field with the result.

This document provides detailed instructions on how to store and use the parameter for installing the Cisco Secure Client package through a company-level custom field. It includes dependencies, sample values, and outcomes for various installation configurations.

Defines whether TPM initialization or reboot is allowed during BitLocker setup.

This field controls whether the AutoElevate deployment process should run on the selected devices. When set to Enable, the deployment script will execute and install configure the AutoElevate agent using the defined parameters (License Key, Elevation Mode, and Blocker Mode). When set to Disable, the deployment will be skipped. Accepted values: Enable or Disable.

License Key is a required parameter used during the AutoElevate agent deployment. It authorizes the agent to register with the correct AutoElevate tenant.

Indicates whether BitLocker initialization needs to run on this device. Used for BitLocker initialization logic and compound conditions.

A boolean flag indicating if the Operating System drive is actively encrypted and protected by BitLocker. Useful for conditions and reporting compliance.

Stores an HTML inventory of BitLocker volumes, including mount points, algorithms, protection status, and key protector types. Populated automatically by the BitLocker automation script.

Choose the operating system to activate the auto deployment of the BlackPoint Agent. Auto deployment can be enabled for Windows machines only or for both Windows and Macintosh computers.

Blocker Mode is a required parameter that needs to be passed during the AutoElevate agent deployment. This parameter is used to set the Blocker Mode configuration for the end user at the time of installation

Stores the unique Blackpoint Account UID used to identify and link endpoints to the correct Blackpoint account.

Holds the Blackpoint macOS authorization token for agent deployment.

It holds the company exe value for BlackPoint endpoint for each client.

Elevation Mode is a configuration parameter used during the AutoElevate agent deployment. It determines how privilege elevation requests are handled on the device once the agent is installed

Select the operating system for which BitLocker auditing should be enabled. Use this setting to specify the OS where auditing policies will apply.

Choose the encryption algorithm BitLocker will apply to the selected volume. Use one of the supported options: Aes128, Aes256, XtsAes128, or XtsAes256.

This custom field stores the FileVault status on macOS devices fetched by the automation "Check FileVault Status" to indicate whether it is enabled or not.

Defines which BitLocker key protector method (TPM, PIN, Password, Recovery, or AD Account) will be applied during encryption.

The drive or mount point targeted for BitLocker encryption. Use a drive letter (e.g., C:) or a valid path to ensure the correct volume is selected.

Organization Name is used during the AutoElevate agent deployment to ensure that the installed agent appears under the correct organization within the AutoElevate portal.

Option for specifying the file path or Active Directory account required by certain BitLocker key protector types.

PIN or password used for BitLocker key protectors that require user authentication at startup.

This custom field stores the list of roles detected on a Windows server.

Mark this checkbox to enable BitLocker without forcefully validating the hardware.

This custom field stores the most recent results of the Soji automation

Stores a detailed HTML report of the Trusted Platform Module (TPM) status, including Manufacturer, Version, Ready State, and Lockout counters. Populated via automation.

This custom field is used show available video output ports on the system (HDMI, DisplayPort, VGA, DVI, etc.). Detect which ports are actively used by connected monitors.

This custom field checks the OS Caption value to determine whether the installed Windows operating system is a home edition. It displays True if the OS name contains Home otherwise it displays False.

This document provides a comprehensive guide on deploying, monitoring, and auditing the Cyrisma sensor application, including associated tasks, custom fields, and monitoring strategies.

This is a compound condition that triggers the bitlocker initialization on windows servers.

This is a compound condition that triggers the BitLocker initialization on windows Workstations.

This document outlines a script designed to reboot endpoints based on specific custom fields that define the reboot window. It includes detailed instructions for implementation, sample runs, dependencies, and deployment steps, ensuring that reboots only occur within the designated time frames.

This document outlines a script designed to reboot workstation endpoints based on specified reboot windows defined by custom fields. It includes implementation steps, sample runs, and detailed script logic to ensure reboots occur only within the designated timeframes.

This script is used to get the local admin data from each machine and output it over a UDF

Automates BitLocker initialization on Windows via Ninja RMM custom fields. Validates parameters, sets mount point, encryption method, key protector, PIN/password, and AD/path, downloads a helper script, executes it, and logs output for auditing.

This script is used to update the Custom filed with the leneovo warranty end date

This Custom filed is used to show the warranty expiration date of any lenovo machine

This document outlines the process for scheduling a forced reboot of a server on specific days based on an approved window check. It includes a sample run, user parameters, dependencies, and detailed implementation steps for creating and managing the task in ConnectWise RMM.

This document details the procedure for categorizing servers into suitable groups according to their installed roles.

Detect all available video output ports on the system (HDMI, DisplayPort, VGA, DVI, etc.). Detect which ports are actively used by connected monitors.

Retrieves installed Windows Server roles, additional services, and FSMO roles (if applicable).