Automating Dell System Updates​

Managing updates for Dell systems can be a time-consuming task, especially across multiple devices. To address this, I’ve developed a PowerShell script that integrates Dell Command Update (DCU) with NinjaOne, automating the process from installation to execution. This post walks through what it does, how it works, and how you can deploy it in your environment.

Purpose and Features​

Dell Command Update is a powerful tool for keeping Dell systems current with the latest BIOS, firmware, drivers, and applications. My script takes it a step further by automating key operations within NinjaOne, an RMM platform I use extensively. Here’s what it offers:

• System Validation: Confirms the device is a Dell system and removes conflicting "Dell Update" applications that could interfere with DCU.
• Dynamic Installation: Downloads and installs the latest DCU version directly from Dell’s support site, ensuring you’re always up to date.
• Customizable Scans: Supports general scans for all updates or targeted BIOS/firmware scans, with results logged to NinjaOne custom fields (except for general scans, which output to CLI).
• Flexible Updates: Options to install all updates, exclude BIOS/firmware, or focus solely on BIOS/firmware, all triggered via a single NinjaOne variable.
• NinjaOne Integration: Updates custom fields (DCU1 for status, DCU2 for details) to streamline monitoring and reporting.

Configuration​

The script is controlled through a NinjaOne dropdown variable named pleaseSelectAnOptionToRun. You’ll need to set this up with the following options:

• Install: Installs DCU after removing incompatible apps.
• Remove Incompatible Versions: Cleans up conflicting Dell Update software.
• Run Scan: Performs a full update scan, outputting results to the CLI.
• Run BIOS and Firmware Scan: Scans for BIOS/firmware updates, logging to NinjaOne fields.
• Run Scan And Install All: Scans and applies all available updates.
• Run Scan And Install Excluding BIOS and Firmware: Applies updates, skipping BIOS/firmware.
• Run Scan And Install BIOS and Firmware ONLY: Targets only BIOS/firmware updates.

Technical Overview​

Here’s a breakdown of the script’s core functionality:

• Pre-Installation Checks: Scans the registry (HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) to uninstall incompatible Dell Update apps silently, ensuring a clean slate for DCU.
• DCU Download: Uses Invoke-RestMethod to scrape Dell’s support page for the latest DCU .exe, then downloads it with Invoke-WebRequest—no manual URL hunting required.
• Execution Logic: Leverages dcu-cli.exe with tailored arguments (e.g., -silent, -updateType) to scan or apply updates. Exit codes are mapped to descriptive statuses in NinjaOne fields:
  • 0: Updates available.
  • 500: No updates found.
  • 1, 5: Reboot required.
  • Full mapping in the script’s Handle-DCUExitCode function.
• Error Handling: Wraps operations in try-catch blocks, logging failures to NinjaOne for easy troubleshooting.

The full script is available on my GitHub: Public-Ninja-One-Scripts.

Benefits​

• Efficiency: Automates repetitive update tasks across Dell fleets.
• Visibility: Integrates with NinjaOne’s custom fields for real-time status tracking.
• Control: Offers granular options to suit different update strategies.
• Open Source: Released under the MIT License—free to use, modify, and distribute.

Deployment Steps​

1. Download: Grab the script from GitHub.
2. Configure NinjaOne: Add the pleaseSelectAnOptionToRun dropdown with the listed options.
3. Run: Deploy it via NinjaOne’s script engine and monitor results in your custom fields.

Notes and Disclaimer​

This script is provided under the MIT License—use it freely, but at your own risk. I’m not liable for any issues that arise; see the full license at opensource.org/licenses/MIT for details. It’s been tested in my environment, but always validate in yours before going full throttle.

Feedback Welcome​

Have thoughts or suggestions? Reach out on GitHub or Discord. I’m considering enhancements like automatic version checks or expanded error reporting—let me know what you’d like to see!

Thanks for reading—happy automating!

Spencer Heath, 10 March 2025

This guide explains how to create scripts for the NinjaOne system tray and configure some to run exclusively for administrators, using a checkbox within NinjaOne to control access. This approach enhances security and oversight for script execution. However, this method is best suited for restricting scripts that you’d prefer end users not interact with, rather than for critical security measures. It’s ideal for minor administrative tasks where accidental access wouldn’t pose a significant security risk, not for safeguarding highly sensitive operations.

Disclaimer: I am not responsible for any actions you take based on this guide or the outcomes that result from implementing these configurations. Use at your own discretion and ensure they align with your organization’s security policies.

Resources and Credits:

• All icons and fonts referenced in this guide can be found at Google Fonts - Symbols & Icons.
• Special thanks to the NinjaOne Stream for inspiration and insights.
• Shoutout to JT (MrDrProfessorJT) and Trevor (StrikerTS) for sharing that resource, and to Joseph for the inspiration!

Step 1: Access Global Custom Fields​

Navigate to Settings > Administration > Global Custom Fields in the NinjaOne interface to begin setting up the necessary configurations.

Step 2: Define a New Global Custom Field​

Set up a global custom field with the following details to track admin status:

Configure Permissions​

Assign the appropriate permissions to control access to this field:

Restricting System Tray Scripts​

Incorporate the following PowerShell code into any system tray script you want to limit to admin users only:

$AdminStatusFieldName = "AdminStatus"
$MessageTitle = "Access Denied"
$MessageBody = "This script requires administrative privileges. Contact your admin for assistance."

$AdminStatus = Ninja-Property-Get $AdminStatusFieldName
if ($AdminStatus -ne 1) {
    $Session = Get-CimInstance -ClassName Win32_ComputerSystem | Select-Object -ExpandProperty UserName
    if ($Session) {
        $Username = $Session.Split('\')[1]
        Invoke-Expression "msg $($Username) /TIME:30 '$MessageTitle - $MessageBody'"
        Write-Output "Message sent to $($Username): Admin access required."
    } else {
        Write-Output "No active user session detected to notify."
    }
} else {
    ## Insert Script to run here!
    Write-Output "Admin access granted. Running admin script."
}

Safeguarding the Admin Restriction​

To prevent the AdminStatus field from being left enabled accidentally, set up an automated process to enforce its restricted state. Depending on your preferences, configure this as an automation policy or a scheduled task. Execute the following script hourly to automatically disable the field if it’s been overlooked:

$AdminStatusFieldName = "AdminStatus"
$AdminStatus = Ninja-Property-Get $AdminStatusFieldName
if ($AdminStatus -ne 0) {
    Ninja-Property-Set $AdminStatusFieldName 0
    Write-Output "AdminStatus has been successfully disabled."
}
else {
    Write-Output "AdminStatus is already in a disabled state."
}

Configuring the System Tray for Admin-Only Scripts​

Next, let’s configure the NinjaOne system tray to clearly distinguish and organize scripts reserved for admin use. This setup ensures they’re both easily recognizable and securely managed.

Steps:​

1. Go to Administration > Branding > Systray in the NinjaOne interface.
2. Either create a new system tray configuration or edit an existing one.
3. Add the following elements to structure your admin-only scripts:

Explanation:​

• Separator: Inserts a dividing line in the tray menu to enhance visual separation.
• Group: Establishes a labeled section titled "Admin Only Scripts" to categorize restricted scripts.
• Automation: Nest your admin-only automations (e.g., scripts with the AdminStatus check) under the "Admin Only Scripts" group. This nesting ensures these scripts appear as submenu items beneath the group label, keeping them organized and clearly tied to their admin-only purpose.

This configuration not only isolates admin scripts visually in the system tray but also reinforces their restricted access through the AdminStatus check, providing a seamless experience for technicians.

See below for a visual guide on the systray setup, and the message a user will see if they dont have the permissions to run this.