3 posts tagged with "NinjaOne"

When using Proofpoint for email filtering, you may notice that automatic forwarding rules stop working. Proofpoint no longer supports automatic forwarding, which means messages sent from your support address to NinjaOne can be blocked or dropped. To resolve this, you can create a connector and mail flow rule in Exchange Online that securely bypass outbound Proofpoint scanning for messages sent to NinjaOne’s ticketing system.

Overview​

You’ll create two items:

1. A connector that routes messages directly to Microsoft 365, bypassing Proofpoint outbound scanning.
2. A mail flow rule that redirects NinjaOne ticketing messages through that connector.

Step 1: Create the Connector​

1. Open the Exchange Admin Center (EAC) at https://admin.exchange.microsoft.com

2. Go to Mail Flow → Connectors

3. Click Add a connector

   • From: Office 365
   • To: Partner organization

4. Configure the connector as shown below:

   

5. Use the following configuration:

   • Name: Bypass Proofpoint Connector
   • Status: On
   • Use of connector: Only when a transport rule redirects messages to this connector
   • Routing: Use the MX record associated with the partner’s domain
   • Security restrictions: Require TLS and connect only if the recipient’s email server certificate is issued by a trusted CA

6. When prompted to validate the connector, use the inbound email address provided by NinjaOne Ticketing.

7. After validation completes successfully, click Finish.

Step 2: Create the Mail Flow Rule​

1. In the Exchange Admin Center, go to Mail Flow → Rules

2. Click Add a rule → Create a new rule

3. Configure it as shown below:

   

   • Name: Bypass Proofpoint for NinjaOne Ticketing
   • Apply this rule if: The recipient domain is rmmservice.com
   • Do the following: Redirect the message to the following connector → Bypass Proofpoint Connector

4. Under Settings, configure as shown:

   

   • Priority: As high as possible
   • Rule mode: Enforce
   • Severity: Low
   • Stop processing more rules: Checked
   • Match sender address in message: Header

5. Save the rule.

Step 3: Test and Verify​

Send a test email or trigger a ticket notification from NinjaOne.
If configured correctly:

• The message should bypass Proofpoint filtering.
• The message should still use TLS encryption.
• Delivery should complete successfully to the target mailbox.

You can confirm successful routing by reviewing Message Trace in the Exchange Admin Center.

Why Proofpoint Blocks Forwarding​

Proofpoint Essentials discontinued support for email auto-forwarding due to abuse and spoofing risks. Automatic forwarding is often used by threat actors to exfiltrate sensitive data or redirect messages externally. As a result, Proofpoint enforces this block by design even for legitimate use cases like helpdesk systems.

By creating a targeted connector and mail flow rule, you maintain secure message handling while allowing legitimate ticketing messages to pass.

Security Notes​

• Only use this bypass for known, trusted systems such as NinjaOne.
• Keep TLS and certificate validation enabled.
• Avoid using wildcard or broad domain rules.
• Regularly review mail flow logs to confirm that only intended messages are being routed through the connector.

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.