BitLocker and TPM Audit
Audits BitLocker encryption status and TPM hardware details, populating detailed HTML reports into NinjaRMM custom fields.
Documents discussing the use and management of custom fields in applications
View all tagsAudits 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 task is used to run the script to update the Autopilot hash under the Custom Filed.
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.
This field stores the Windows Autopilot hardware hash value.
This group shows machines where Autopilot Hash is not updated.
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.
This field controls the Windows Update Branch Readiness Level. Select the appropriate channel to determine which feature update builds the device will receive.
Controls script execution logic for Network Adapter validation.
This custom field is used to store the values for DeferFeatureUpdates. It contains two possible values: Enabled or Disabled.
Specifies the number of days to defer Windows feature updates. Accepts values between 0 and 365 days.
Displays whether DHCP is enabled or disabled on the active network adapter.
Displays the DNS server address configured on the active network adapter.
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 Fields Controls the Configuration of Feature update deferral on the machine based on the selected operating system. Choose Disabled to skip applying this setting to the current Client, Location, or Computer.
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.
Displays the DNS server address configured on the active network adapter.
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 filed is used to show the installed remote applications on the machine
This custom field stores the list of roles detected on a Windows server.
This custom field shows whether Secure Boot is enabled on the device.
Devices with Secure Boot disabled for compliance and security monitoring.
This task checks and records the SecureBoot status on devices, including SecureBoot certificates.
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 shows the status of the Windows Secure Boot Database (DB) certificate.
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 custom field displays the status of the Windows Key Exchange Key (KEK) certificate.
This custom field indicates the current telemetry (diagnostic data) level on Windows. Shows whether Windows telemetry is enabled and its level (Basic, Enhanced, Full)
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 fetches the device Autopilot Hardware Hash using CIM/WMI from the MDM namespace. Once retrieved, it validates the hash format and updates the cPValAutopilotHash custom field with the value. Must be run with Administrator privileges.
The purpose of the soultion to update the check and update the Autopilot Hash into the Custom filed.
This script identifies the first active network adapter that is up, has an IPv4 address, and a default gateway. It outputs the DHCP enabled status, IP configuration type (DHCP or Static), and the comma-separated list of DNS servers.
This script identifies remote access tools currently installed on the machine.
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 solution gathers active network adapter details and updates custom fields with DHCP status, IP type, and DNS server information for accurate visibility and reporting.
This solution checks the Secure Boot status and validates the associated certificates. If the system is using older Secure Boot certificates, the custom fields are updated accordingly. If the system is using updated certificates. The custom fields are updated to reflect the compliant status.
This script evaluates whether a Windows device is prepared for the upcoming Microsoft Secure Boot certificate transition scheduled for 2026.
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).