# Fixing macOS Managed Software Updates: Resolving Daemon Hangs and Token Errors

While pushing a remote operating system patch preference via Hexnode UEM is a clean action, target terminal states can cause Apple’s native background software engines to stall. This document outlines how to diagnose and clear update hangs on client endpoints using terminal tools.

Clearing the “Preparing…” Status Lock on Target Macs 
-----------------------------------------------------

**The Symptom**: An administrator deploys an OS update via Hexnode using either the **[Update OS](https://www.hexnode.com/mobile-device-management/help/how-enforce-os-updates-on-macos-devices-using-hexnode/)** remote action or an automated **[OS Updates](https://www.hexnode.com/mobile-device-management/help/how-to-schedule-macos-updates-using-hexnode-mdm/)** policy (under **Policies > macOS > Security > OS Updates**). Even though the action is configured to “Download and Install,” the target Mac successfully downloads the payload but stays indefinitely stuck in a “*Preparing…*” state within System Settings.

**The Underlying Logic**: Under the hood, Hexnode translates your UI selection into Apple’s native *ScheduleOSUpdate* command. It then relies on the Mac’s local update supervisor daemon (*softwareupdated*) to execute the installation. If this local daemon deadlocks or encounters a corrupted installation cache, the automatic installation loop fails to trigger, regardless of the instructions sent by Hexnode.

Resolution Workflow via Hexnode Live Terminal 
----------------------------------------------

Instead of forcing a hard user reboot or requiring physical touch intervention, administrators can resolve this issue by executing direct terminal actions down to the machine:

1. Log in to the Hexnode UEM portal and navigate to **Manage > Devices**.
2. Click into the problem macOS device.
3. From the **Device Summary** sub-tab, locate the **[Live Terminal](https://www.hexnode.com/mobile-device-management/help/how-to-enable-live-terminal-on-your-macos-devices/)** section and click the **Start SSH Session** button.  Note:On macOS 10.15+ devices, the Hexnode helper app requires Full Disk Access. You may need to click ‘**Grant Permission**‘ before starting the session for the first time.
4. Run the following string to check if the background execution daemon has frozen: Script to check if the background execution daemon has frozen on macOS devices
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    sudo launchctl list | grep softwareupdated
    
       1
    
    
    
      sudo launchctl list | grep softwareupdated
5. To clear the system deadlock and force Apple’s download controller to rebuild its active process thread pool, kill the execution daemon completely with this command: Script to clear the system deadlock and force Apple's download controller to rebuild its active process thread pool, kill the execution daemon completely
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    sudo killall softwareupdated
    
       1
    
    
    
      sudo killall softwareupdated
6. Re-issue the OS update command. You can do this by executing **Actions > Updates > Update OS** from the Hexnode dashboard, or by letting the assigned Hexnode OS update policy naturally re-sync.

Resolving Apple Silicon (M1/M2/M3) Update Authentication Failures 
------------------------------------------------------------------

**The Symptom**: Software update commands pushed to modern Macs running Apple Silicon chips fail instantly, throwing a silent error code or an unauthenticated execution alert inside your deployment status logs.

**The Underlying Logic**: Apple Silicon computers utilize a strict secure-boot matrix. Unlike legacy Intel architectures, an M-series chip requires a cryptographic Bootstrap Token to authenticate the silent, MDM-driven installation of OS updates. If a Mac was enrolled via an unverified method or the token failed to escrow, Hexnode’s *ScheduleOSUpdate* command will fail because the architecture lacks the token required to authorize the execution.

**Checking Escrow Status via Client Terminal**

To verify if a machine has safely handed its authorization token over to your server instance, run this check locally or via Hexnode’s Live Terminal:

Script to verify if the macOS device has safely handed its authorization token over to the server instance

sudo profiles status -type bootstraptoken 

   1

  sudo profiles status -type bootstraptoken 

   

 

  

### Understanding the Output Profiles Vector 

- If it returns: **profiles: Bootstrap Token escrowed to server: Yes** — The encryption pipeline is healthy. Your update failure is likely caused by a localized power connection or storage threshold failure.
- If it returns: **profiles: Bootstrap Token escrowed to server: No** — The update engine cannot authorize installation, and the machine will permanently block the MDM/UEM installation command.

**Force-Escrowing a Missing Token Remotely**
If a device has a missing token but is a supervised machine running macOS 10.15 or later, you can manually trigger an escrow connection to Hexnode by pushing the following shell instruction:

Script to force escrow the missing token

sudo profiles install -type bootstraptoken 

   1

  sudo profiles install -type bootstraptoken 

   

 

  

 Note: 
You may be asked to authenticate using admin credentials when running sudo commands on the Mac to validate authorization. Once completed, verify the escrow state by navigating to **Manage > \[Select Device\] > Device Info > Security Info > [Bootstrap Token](https://www.hexnode.com/mobile-device-management/help/fetching-bootstrap-token-of-already-enrolled-macs/)**. The status indicator will transition from “*Missing*” to “*Escrowed*,” clearing the way for secure automated patching workflows.