In this article

If Roaming Clients have auto-updates enabled but are not auto-updating, there may be a few different causes. This article outlines known issues and troubleshooting steps.

Auto-updates aren't at 100%

• Cause: All Production channel releases are performed in a cadence that may be incomplete at this time
• Agents update at random, so it's possible some of your Organization's Roaming Clients have updated where others have not
• This is also true if a release never hit 100% auto-update status: if a bug is discovered it's possible a new version gets released before the release cadence completes, e.g. macOS 2.2.0 held at 5%, never reaching 100% of devices with auto-updates enabled
• Fix: Perform the upgrade ahead of the auto-update or wait for the release to reach 100% 

macOS agent version is lower than 1.8.6

• Impact: Only affects macOS Roaming Client versions 1.8.4 and lower and the OS has updated to Sequoia
• Cause: New security settings released with macOS 15 limited the agent's ability to auto-update
• Fix: Manually update to the latest agent version to regain auto-update capabilities

Windows agent version is 1.11.0 or 1.12.0 

• Impact: Only affects branded Windows Roaming Client versions 1.11.0 and 1.12.0
• Cause: A bug in certificate validation logic prevented these versions from updating after the original installation certificate expired
• Fix: Manual update is required to the latest version to restore auto-update functionality
• Note: The non-branded (whitelabel) version of the WinRC was not affected

Windows beta agent version is 3.0.0

• Impact: Only affects Windows Roaming Client beta version 3.0.0
• Cause: A bug in the installer auto-update function prevents the agent from automatically updating as new beta version come available
• Fix: Manual update via command or RMM/MDM deployment is required to the latest beta version to restore auto-update functionality

Architecture mismatch (x86 → x64/ARM64)

• Cause: Starting with version 2.x, the Windows Roaming Client is only available in x64 and ARM64 builds
• If the client is installed on a 32-bit (x86) system, it cannot auto-update to 2.x
• Fix: Update the device hardware to 64-bit and manually install the correct version. There is no upgrade path from 32-bit to 64-bit

Locked DLL files during update

• Cause: During update, the Windows installer may need to replace DLL files that are in use
• If these files can’t be unloaded, the upgrade process reverts
• Fix: Rebooting the machine usually releases the locked files so the update can succeed

Antivirus or ASR Rule Interference

• Cause: Aggressive antivirus (AV) settings or Microsoft Attack Surface Reduction (ASR) rules can block the Windows MSI installer
• This is a false positive—our MSI is digitally signed—but overly strict rules can still block it
• Fix: Whitelist the MSI in your AV or adjust ASR rules to allow the update

Windows installer blocked after download

• Impact: Affects Windows Roaming Clients where the update file downloads successfully but the installer does not run
• Cause: Windows or local environmental factors prevent the staged installer from executing. Common causes include:
  • Security software quarantining or locking the installer
  • Insufficient permissions for the Windows SYSTEM account or Administrators group
  • Issues with the Windows temp directory (full, encrypted, or restricted)
• The installer is typically staged in C:\Windows\SystemTemp\ before execution
• Fix:
  • Review antivirus or endpoint protection logs for actions against files in C:\Windows\SystemTemp\
  • Confirm the Windows SYSTEM account and Administrators group have access to C:\Windows\SystemTemp\
  • Check that the temp directory is not full, encrypted, or restricted by local policy
  • If possible, attempt to run the installer manually from C:\Windows\SystemTemp\ to confirm whether the block persists
• These checks help identify whether security tools, permissions, or environmental issues are preventing the installer from running