Upgrade FileCloud Sync Classic

What the FileCloud Sync upgrader does

This Automox Worklet™ upgrades the FileCloud Sync Classic client on Windows endpoints to a build you specify. The evaluation script reads the installed DisplayVersion from HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall, locates the FileCloudSync entry, and compares it against the $AppVersion parameter you configure on the policy.

When the installed version is lower than the target, the remediation script invokes msiexec with the FileCloud Sync MSI staged in C:\Program Files\FileCloud or shipped alongside the Worklet, runs it silently, and lets Automox roll the result up into the activity log. Endpoints already on the target version exit as compliant. Endpoints with no FileCloud Sync install at all exit as not applicable, so the policy is safe to scope broadly across a Windows fleet.

The Worklet handles both 32-bit and 64-bit Uninstall keys, so it finds FileCloud Sync Classic regardless of which architecture the original installer landed in. It also passes through msiexec arguments you set in $InstallerArgs, so you can pin /qn for fully silent runs, /norestart to suppress reboot prompts, or /l*v %TEMP%\filecloud-upgrade.log to capture a verbose MSI log when troubleshooting a stubborn endpoint.

Why upgrade FileCloud Sync clients at fleet scale

FileCloud Sync clients that fall behind the server build are the quiet cause of half the sync tickets that hit IT. Older clients break against tightened TLS settings, lose the ability to authenticate after a server token format change, and stop honoring conflict-resolution rules that newer builds enforce. Users see files stuck in a pending state, duplicated copies under a (1) suffix, or credential prompts that never go away. The only consistent fix is to get every endpoint onto the same client version as the server.

FileCloud Sync clients drift across a Windows fleet because the in-app updater is easy for end users to dismiss, and an out-of-date sync agent can lose authentication tokens or stall on a back-end protocol bump. This Worklet reads the uninstall registry on each Windows endpoint, decides whether the installed version is behind the target, and runs msiexec with the silent switches only where the upgrade is needed. The result is fleet-level enforcement of a single FileCloud Sync build with no manual installer hand-offs and no chasing the last 10% of laptops by hand.

How the FileCloud Sync upgrade works

1. Evaluation phase: PowerShell enumerates HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall, filters for entries whose DisplayName starts with FileCloudSync, and reads the DisplayVersion value. The script parses both the installed version and the $AppVersion target into [version] objects so the comparison handles four-segment builds like 21.1.1.5892. If the installed version is lower than the target, the script writes the gap to stdout and exits 1, which Automox interprets as needing remediation. An installed version equal to or greater than the target exits 0 (compliant). No FileCloudSync entry at all exits 0 with a not-applicable message, so the policy is safe to broadcast.

2. Remediation phase: The remediation script resolves the installer path (either the MSI uploaded to the Automox console and dropped into the Worklet working directory, or the staged copy in C:\Program Files\FileCloud) and calls msiexec.exe /i "<installer>" $InstallerArgs (default /qn /norestart). Start-Process -Wait holds the script open until msiexec returns, and the exit code is captured. Exit code 0 reports a clean upgrade. Exit code 3010 is treated as success with a pending reboot, which the Worklet logs but does not force. Any other non-zero code re-emits stderr from msiexec into the Activity Log so the admin sees the underlying MSI error directly.

FileCloud Sync upgrade requirements

• Windows 10, Windows 11, or Windows Server 2016 or later with PowerShell 5.1 available to the Automox agent

• FileCloud Sync Classic already installed on the endpoint (the Worklet upgrades existing installs only; first-time installs need a separate deployment Worklet)

• FileCloud Sync MSI staged in the policy: either upload the installer to the Automox console so it lands in the Worklet working directory, or pre-stage it at C:\Program Files\FileCloud\FileCloudSync.msi

• $AppVersion set to the target build in four-segment form (e.g., 21.1.1.5892); the script uses System.Version semantics so 21.1.1.10 is correctly greater than 21.1.1.9

• $InstallerName set to the exact filename of the staged MSI (case-sensitive on Windows network shares)

• Optional: $InstallerArgs to override the msiexec defaults (e.g., /qn /norestart /l*v %TEMP%\filecloud-upgrade.log for a verbose MSI trace)

• Administrator context on the endpoint (the default Automox agent context already meets this requirement)

Expected state after the FileCloud Sync upgrade

After remediation, the FileCloudSync entry under HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall (or its WOW6432Node sibling) reports a DisplayVersion equal to your $AppVersion target, and the FileCloud Sync system tray icon shows the same build after the user signs in. The user’s existing sync folders, server URL, account credentials, and bandwidth settings persist through the upgrade because msiexec runs in upgrade mode rather than uninstall-then-install. The next Automox policy evaluation finds the endpoint compliant and skips remediation, so the Worklet is safe to run on a recurring schedule.

Validate by running Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object DisplayName -like 'FileCloudSync*' on a pilot endpoint and confirming DisplayVersion matches the target. Confirm the client still syncs by touching a file inside the FileCloud Sync local folder and watching it appear on the server within the configured sync interval. If msiexec returns 3010, schedule a reboot in a separate maintenance window. FileCloud Sync continues running the previous client until the reboot completes the file-replacement step. If msiexec returns 1603 or 1618, inspect %TEMP%\filecloud-upgrade.log (with /l*v enabled) for the underlying MSI error before rerunning the policy.