How Do You Deploy the Netskope Client via JumpCloud on Windows and macOS?

You deploy the Netskope Client via JumpCloud in two phases: first push an MDM Custom Profile to macOS devices to pre-approve the Netskope network extension, then run a JumpCloud Command — PowerShell on Windows, bash on macOS — that downloads the installer and passes your tenant, domain and enrollment token so the client auto-enrolls without user interaction. Skipping the first phase on macOS is the single most common cause of a deployment that appears to succeed but never steers traffic.

Overview

A silent, zero-touch Netskope Client rollout has two distinct requirements, and they must happen in order:

• Configuration (pre-install): approving system extensions on macOS so the user is never prompted.

• Installation: pushing the installer with the correct host and token arguments so the client auto-enrolls into your specific tenant.

This guide is for endpoint and security administrators who manage Windows and macOS fleets through JumpCloud and are rolling out Netskope as their SSE/SWG agent.

Expected outcome: the Netskope Client installed on every in-scope device, enrolled to the correct tenant, showing Enabled and Connected, with the logged-in user's identity detected automatically — and no end-user prompts at any point.

Prerequisites

Confirm your tenant name and domain suffix before you start. Almost every failed enrollment traces back to one of those two values being wrong.

Part 1: macOS Preparation (Do This First)

Before installing the app on Macs, you must deploy a configuration profile to approve the Netskope Network Extension. If you skip this, users are bombarded with "Netskope would like to filter network content" pop-ups, or the agent installs but fails to steer traffic — which is the worse outcome, because the fleet looks compliant while it is not.

Step 1: Obtain the Netskope configuration profile

Netskope provides a standard .mobileconfig for MDMs, available through the Netskope Support Portal. It approves Netskope's system and network extension by developer Team ID.

Verify the current Team ID against Netskope's own documentation for your client version before deploying. The value previously used in this guide was 24W52P9M7W. An incorrect or outdated Team ID produces a profile that installs cleanly and approves nothing.

Step 2: Upload the profile to JumpCloud

JumpCloud Admin Console → Device Management → Policy Management → (+) → Mac → MDM Custom Profile

• Upload the Netskope .mobileconfig file.

• Name: Security - Netskope System Extensions

• Scope: bind to your "All Mac Workstations" device group.

• Save.

Step 3: Wait for the profile to land

Allow 15–30 minutes for the profile to reach devices before pushing the application. Do not queue the install command in the same maintenance window — if the install runs first, you get the prompts you were trying to avoid, and on some macOS versions you will need to remove and reinstall the client to recover cleanly.

Confirm arrival on a test Mac before proceeding:

bash

# Confirm the profile has landed on the device
profiles show -type configuration | grep -i netskope

Part 2: Deploying to Windows (PowerShell Command)

The most reliable way to install Netskope with arguments on Windows is via a JumpCloud Command.

JumpCloud Admin Console → Device Management → Commands → Create New Command → Windows

• Name: Install - Netskope Client (Windows)

• Launch Type: Run once, or bind to a "New Computers" group for ongoing enrollment.

• Command: paste the script below, replacing the placeholder values.

powershell

# Define the download URL and destination path
$downloadUrl = "https://download-YOUR_TENANT.YOUR_DOMAIN/dlr/win/get"
$msiPath = "C:\Windows\Temp\NSClient.msi"

# Download the file
Invoke-WebRequest -Uri $downloadUrl -OutFile $msiPath

# Verify if the downloaded file is a valid MSI
if (Test-Path $msiPath) {
    Write-Output "File downloaded successfully. Checking file type..."

    # Get the file extension to verify it's an MSI
    $fileExtension = [System.IO.Path]::GetExtension($msiPath)

    if ($fileExtension -eq ".msi") {
        Write-Output "Valid MSI detected. Proceeding with installation..."

        # Install the MSI package using msiexec
        Start-Process -FilePath "msiexec.exe" -ArgumentList "/I `"$msiPath`" installmode=IDP tenant=YOUR_TENANT domain=YOUR_DOMAIN mode=peruserconfig enrollauthtoken=YOUR_ENROLMENT_TOKEN /quiet /norestart /l*v C:\Windows\Temp\ns_install.log" -Wait

        Write-Output "Installation complete."

        # Clean up the downloaded file (optional)
        Remove-Item -Path $msiPath -Force
    } else {
        Write-Output "Downloaded file is NOT an MSI. Please check the URL."
    }
} else {
    Write-Output "Download failed. Check network connectivity and URL."
}

What each MSI parameter does

Change note: /l*v C:\Windows\Temp\ns_install.log is the one addition to the original script. The previous version's troubleshooting section told readers to check that log file, but nothing in the script created it. This flag only writes a log; it does not alter install behaviour.

Part 3: Deploying to macOS (Bash Command)

As on Windows, the installer is downloaded and run with installer, with parameters supplied through configuration files. The script below is the current method for newer Netskope Clients in IdP mode.

JumpCloud Admin Console → Device Management → Commands → Create New Command → Mac

• Name: Install - Netskope Client (macOS)

• Run as: Root

• Command:

bash

#!/bin/bash
#Script for installing Netskope Client on OSX machines
#function will install Netskope Client

function Ins_NSClient(){
ag="NSClient.pkg"
spDomain="YOUR_DOMAIN"
spTenant="YOUR_TENANT"
perusermode=0 # put 0 for normal installation, put 1 for per user config
echo "Downloading NsAgent..."
curl -o /tmp/$ag  https://download.goskope.com/dlr/mac/get
echo "will now add config file..."
mkdir -p "/Library/Application Support/Netskope/STAgent"
NSIDPCONFIG_FILE_PATH="/Library/Application Support/Netskope/STAgent/nsidpconfig.json"
echo "{ \"serviceProvider\": { \"domain\": \"$spDomain\", \"tenant\": \"$spTenant\" } }" > "${NSIDPCONFIG_FILE_PATH}"
if [ $perusermode -eq 1 ]
then
NSUSERCONFIG_JSON_FILE="/Library/Application Support/Netskope/STAgent/nsuserconfig.json"
echo "{\"nsUserConfig\":{\"enablePerUserConfig\": \"true\", \"configLocation\": \"~/Library/Application Support/Netskope/STAgent\", \"token\": \"\", \"host\": \"\",\"autoupdate\": \"true\"$fail_close_option}}" > "${NSUSERCONFIG_JSON_FILE}"
fi
echo "Installing Agent..."
installer -dumplog -pkg /tmp/$ag -target / && rm /tmp/$ag
}
# Function to create JSON file with provided tokens
Create_Json() {
    # Create directory if it doesn't exist
    mkdir -p $TEMP_BRANDING_DIR
    # Delete previous enroll.conf if it exists
    if [[ -f "$TEMP_ENROLLMENT_TOKEN_FILE" ]]; then
        rm "$TEMP_ENROLLMENT_TOKEN_FILE"
    fi 
    local a=$1 #auth token
    local b=$2 #encryption token
    # Check if parameters are 32 characters hexadecimal
    if ! [[ "$a" =~ ^[a-fA-F0-9]{32}$ ]] && [[ "$a" != "0" ]]; then
        echo "Invalid auth token: must be 32 hexadecimal characters"
        return 1
    fi
    if ! [[ "$b" =~ ^[a-fA-F0-9]{32}$ ]] && [[ "$b" != "0" ]]; then
        echo "Invalid encryption token: must be 32 hexadecimal characters"
        return 1
    fi
    # Start the JSON structure
    echo "{" > $TEMP_ENROLLMENT_TOKEN_FILE
    #if both token is present
    if [[ "$a" != "0" && "$b" != "0" ]]; then
        echo "\"enrollauthtoken\": \"$a\"," >> $TEMP_ENROLLMENT_TOKEN_FILE
        echo "\"enrollencryptiontoken\": \"$b\"" >> $TEMP_ENROLLMENT_TOKEN_FILE
    # only encryption token present
    elif [[ "$a" == "0" && "$b" != "0" ]]; then
        echo "\"enrollencryptiontoken\": \"$b\"" >> $TEMP_ENROLLMENT_TOKEN_FILE
    #only authtoken present
    elif [[ "$b" == "0" && "$a" != "0" ]]; then
          echo "\"enrollauthtoken\": \"$a\"" >> $TEMP_ENROLLMENT_TOKEN_FILE
    else
         echo "Unsupported use case"
    fi
    # End the JSON structure
    echo "}" >> $TEMP_ENROLLMENT_TOKEN_FILE
    chmod 700 "$TEMP_ENROLLMENT_TOKEN_FILE"
    echo "enroll.conf created with provided tokens."
}

# Main script execution

#update these tokens to valid tokens
enrollencryptiontoken=0
enrollauthtoken=YOUR_ENROLLMENT_TOKEN
TEMP_BRANDING_DIR="/tmp/nsbranding"
TEMP_ENROLLMENT_TOKEN_FILE="$TEMP_BRANDING_DIR/enroll.conf"

# Check if atleast one of the token is present, then create enroll.conf
if [[ "$enrollencryptiontoken" != "0" || "$enrollauthtoken" != "0" ]]; then
    echo "Using secure enrollment"
    Create_Json "$enrollauthtoken" "$enrollencryptiontoken"
else
    echo "Not using secure enrollment"
    # Delete previous enroll.conf if it exists
    if [[ -f "$TEMP_ENROLLMENT_TOKEN_FILE" ]]; then
        rm "$TEMP_ENROLLMENT_TOKEN_FILE"
    fi
fi
Ins_NSClient
#end script

What the script creates

Token format: both enrollauthtoken and enrollencryptiontoken must be exactly 32 hexadecimal characters, or 0 to omit. The script validates this and exits with Invalid auth token: must be 32 hexadecimal characters rather than producing a broken install — a useful guardrail, since a token pasted with a trailing space or newline is the most common input error.

Validation: How to Verify Success

After the command runs, check all three layers. A visible icon does not mean traffic is steering.

1. Visual check The Netskope icon (grey or blue logo) appears in the System Tray (Windows) or Menu Bar (macOS).

2. Connection check Right-click the icon → Configuration. Expect:

• Status: Enabled and Connected

• Email address matching the logged-in user — this confirms IdP auto-detection worked

If status shows Enabled but not Connected, the client installed but cannot reach the tenant. If the email is blank or wrong, IdP mode did not resolve the identity and your installmode=IDP parameters or nsidpconfig.json values need checking.

3. JumpCloud Console Confirm the software is present via the Software tab in the device's Device Details view.

4. macOS extension approval

bash

# Confirm the system extension is actually enabled, not just installed
systemextensionsctl list | grep -i netskope

An extension listed as [activated waiting for user] means the MDM profile from Part 1 did not apply. The client is installed and not protecting the device.

Troubleshooting

Problem: Mac user is prompted for a password, or sees "would like to filter network content". Cause: The MDM profile from Part 1 was not installed, or did not cover the correct developer Team ID. Fix: Verify the profile with profiles show -type configuration | grep -i netskope, confirm the Team ID against Netskope's current documentation, then re-push the profile and allow 15–30 minutes before reinstalling the client.

Problem: Windows install reports "Installation Failed". Cause: Most often the enrollment token was pasted with extra spaces or a line break, or the tenant/domain values are wrong. Fix: Check the verbose log at C:\Windows\Temp\ns_install.log (created by the /l*v flag in the script above). Search it for enrollauthtoken and tenant to confirm the values that were actually passed.

Problem: "Downloaded file is NOT an MSI. Please check the URL." Cause: The download endpoint returned an HTML error page rather than the installer — usually a wrong tenant-specific download host, or the URL requires authentication from that network. Fix: Test the URL manually from a device on the same network. Host the installer on an internal share if the endpoint is not reliably reachable.

Problem: macOS script exits with "Invalid auth token: must be 32 hexadecimal characters". Cause: The token contains whitespace, a newline, or non-hex characters. Fix: Re-copy the token from MDM Distribution and paste it without surrounding quotes or spaces.

Problem: Client installed, icon present, but no traffic is steering on macOS. Cause: System extension approved on install prompt only, or not approved at all. Fix: Run systemextensionsctl list | grep -i netskope. If it shows as waiting for user, the profile is the problem, not the client.

Problem: Devices enroll into the wrong tenant. Cause: tenant / domain values in the Windows arguments do not match spTenant / spDomain in the macOS script. Fix: Standardise both from a single source of truth before deploying. See the flags section — this has happened in this document itself.

Security and Best Practices

• Treat the enrollment token as a credential. It permits a device to enroll into your tenant. Store it in JumpCloud's command body only as long as the rollout needs, and rotate it in MDM Distribution when the deployment window closes or if the command is ever exported or shared.

• Never publish real tenant names or tokens in documentation. Internal runbooks included. Use placeholders and keep live values in your secret store.

• Use secure enrollment. Supplying enrollauthtoken (and optionally enrollencryptiontoken) prevents arbitrary devices from enrolling into your tenant with just the tenant name.

• Pilot before fleet-wide. Bind the command to a pilot device group of 5–10 machines spanning your actual OS versions. macOS system-extension behaviour changes between major releases, and a profile that worked last year may not this year.

• Sequence the profile before the install, always. Bind the MDM profile to the device group first, verify on a test Mac, and only then enable the install command. Reversing the order on a large fleet generates helpdesk volume you cannot easily undo.

• Scope mode=peruserconfig deliberately. Per-user configuration suits shared or multi-user devices; single-user corporate laptops usually do not need it, and it adds a configuration path to maintain.

• Plan the uninstall. Know how to remove the client cleanly before you deploy it to 500 machines. Netskope's tamper protection may require an uninstall password or admin token — retrieve it now, not during an incident.

When to Handle This Internally, and When to Bring in Help

A pilot of ten machines with one OS version each is straightforward — the scripts above are the whole job.

The work gets harder in specific, predictable places:

• Mixed macOS versions across a fleet. System-extension and network-extension approval behaviour differs by major release, and a single profile rarely covers everything cleanly.

• Netskope coexisting with another endpoint agent. Running an SSE client alongside EDR, another VPN client, or a second network extension requires exclusion planning on both sides. This is where deployments break in ways that look like network faults.

• Steering configuration, not just installation. Getting the client installed is the easy half. Deciding what to steer, what to bypass, and where to apply SSL inspection — without breaking certificate-pinned applications — is the half that determines whether users trust the rollout.

• Rollout to a fleet already in production use. Staged deployment, rollback plan, helpdesk briefing and a real pilot matter more than the script.

• No documented uninstall or recovery path. If you cannot cleanly remove the agent from a machine that is misbehaving, you are not ready for fleet-wide deployment.

NetNXT deploys and manages SSE and secure web gateway agents across mixed Windows and macOS estates — staged rollouts, coexistence with existing endpoint agents, steering and inspection policy design, and the exclusions that stop a deployment generating tickets. If you are moving from a pilot to a fleet, that is the right point for a conversation.

FAQs

1) How do you deploy the Netskope Client using JumpCloud?

Deploy in two stages. First, push an MDM Custom Profile to macOS devices via Device Management → Policy Management → (+) → Mac → MDM Custom Profile to pre-approve the Netskope network extension, and allow 15–30 minutes for it to land. Then create a JumpCloud Command under Device Management → Commands — PowerShell for Windows using msiexec.exe with installmode=IDP, tenant, domain and enrollauthtoken arguments; bash for macOS, run as Root, writing nsidpconfig.json before calling installer.

2) Why does macOS prompt users to allow Netskope to filter network content?

Because the system-extension approval profile was not deployed before the client, or it references the wrong developer Team ID. macOS requires MDM pre-approval of the network extension; without it the user is prompted, and if they decline, the agent installs but never steers traffic. Verify with systemextensionsctl list | grep -i netskope — [activated waiting for user] confirms the profile did not apply.

3) What parameters does the Netskope MSI need for silent enrollment?

Pass installmode=IDP, tenant=YOUR_TENANT, domain=YOUR_DOMAIN, mode=peruserconfig and enrollauthtoken=YOUR_TOKEN, along with /quiet /norestart, to msiexec.exe. Add /l*v C:\Windows\Temp\ns_install.log for a verbose log — without it there is nothing to diagnose a failed install from. The enrollment token comes from Netskope Admin Console → Settings → Security Cloud Platform → Netskope Client → MDM Distribution.

4) Where do you find the Netskope enrollment token, and what format must it be?

In the Netskope Admin Console under Settings → Security Cloud Platform → Netskope Client → MDM Distribution. Both enrollauthtoken and enrollencryptiontoken must be exactly 32 hexadecimal characters, or 0 to omit. The macOS install script validates this and aborts with "Invalid auth token: must be 32 hexadecimal characters" rather than producing a half-enrolled client.

5) How do you verify the Netskope Client installed and enrolled correctly?

Check three layers. The Netskope icon should appear in the Windows System Tray or macOS Menu Bar; right-clicking it and opening Configuration should show Enabled and Connected with the logged-in user's email detected via IdP mode. Confirm the software appears in the device's Software tab in JumpCloud. On macOS, run systemextensionsctl list | grep -i netskope to confirm the extension is actually activated rather than waiting for user approval.