Windows - Software Lifecycle - Update Microsoft Azure Storage Explorer with Notifications

What the Azure Storage Explorer updater does

This Automox Worklet™ updates Microsoft Azure Storage Explorer on Windows endpoints from any prior version to the latest release published by Microsoft on GitHub. The Worklet calls https://api.github.com/repos/microsoft/AzureStorageExplorer/releases/latest, parses the tag name, and compares it against the installed version reported by the Automox Windows Detection Kit. Endpoints already on the latest release report compliant. Endpoints behind a release are flagged for remediation.

Remediation begins with a user-facing notification before any installer runs. The Worklet sends a Yes/No prompt to the active console session with a configurable title, message, and timeout (default 60 seconds). If the user clicks Yes, the Worklet stops StorageExplorer.exe processes and uninstalls the existing build. It then downloads the latest StorageExplorer.exe (Inno Setup) installer from the GitHub release asset URL into the Automox cache and runs a silent install with /VERYSILENT /ALLUSERS, so the new build lands at C:\Program Files\Microsoft Azure Storage Explorer\ for every profile on the endpoint.

The Worklet recognizes both per-machine and per-user installations of Azure Storage Explorer. When it finds a per-user copy (the legacy %LocalAppData%\Programs\Microsoft Azure Storage Explorer path), it uninstalls under the active user context, then reinstalls system-wide. After remediation the installation is consistent across user profiles, which simplifies every subsequent update cycle and removes the per-user uninstall edge case that breaks unattended patching.

Why keep Azure Storage Explorer current at fleet scale

Azure Storage Explorer is the desktop client your cloud and data teams use to browse Blob containers, ADLS Gen2 file systems, queues, tables, and Cosmos DB collections. Microsoft pushes regular releases that bundle Azure SDK updates, Electron security patches, and authentication library refreshes for OAuth and managed identity. Endpoints stuck on older builds eventually fail Entra ID conditional access, misread newer storage account features, or sit exposed to known Electron CVEs that the Worklet replaces in one pass.

Azure Storage Explorer ships frequent point releases that pick up Electron and Node security fixes, yet the in-app updater frequently stalls on locked binaries when a developer is mid-transfer. The notification-first design of this Worklet respects the engineer who is moving a large blob against a production storage account, while still pulling the rest of your Windows fleet forward on the next policy cycle. Cloud services update themselves on the server side, but the laptop touching Azure storage does not, and that is the gap this Worklet closes.

How the Azure Storage Explorer upgrade works

1. Evaluation phase: The Worklet imports the Automox Windows Detection Kit and calls Get-Win32App with a name match on Microsoft Azure Storage Explorer to read DisplayVersion from both HKLM and HKCU uninstall registry hives. It then runs Invoke-RestMethod against the GitHub releases API with a User-Agent header set, parses the tag name (for example v1.36.0), and compares the two with [version] casting. Endpoints with no installation exit not applicable. Endpoints on the latest release exit compliant with code 0. Endpoints behind report non-compliant and queue remediation.

2. Remediation phase: The Worklet displays a Yes/No toast using the Automox notification helper with a configurable title, body, and timeout. On Yes, it calls Stop-Process -Name StorageExplorer -Force, then runs the uninstaller located through the QuietUninstallString or UninstallString registry value (per-user path runs under the active user context via Invoke-AsCurrentUser). It downloads the StorageExplorer.exe Inno Setup installer from the release asset to C:\Windows\Temp\, executes it with /VERYSILENT /ALLUSERS, and waits for exit code 0. On No or timeout the Worklet writes a deferral note to stdout and exits cleanly so the next policy run retries.

Azure Storage Explorer update requirements

• Windows 10, Windows 11, or Windows Server endpoint with PowerShell 5.1 or later and the Automox agent installed

• Outbound HTTPS to api.github.com and github.com (and objects.githubusercontent.com for the release asset CDN) for both API lookup and installer download

• TLS 1.2 enabled in [Net.ServicePointManager]::SecurityProtocol (the Worklet sets this defensively at the top of the script for older Server SKUs)

• An active logged-in user when the notification step runs; if the endpoint is unattended the Worklet treats the lack of a session as a deferral and re-evaluates on the next policy

• Configurable Worklet variables: notification title, notification message, and timeout in seconds (default 60)

• .NET Framework 4.7.2 or later on the endpoint (the Azure Storage Explorer installer itself enforces this for older builds; Windows 10 1803 and Windows 11 already include it)

Expected state after the Azure Storage Explorer upgrade

After successful remediation, Microsoft Azure Storage Explorer is installed at C:\Program Files\Microsoft Azure Storage Explorer\StorageExplorer.exe on the endpoint, available from every user profile, and reporting the version returned by the GitHub releases API at the time the policy ran. Validate by running Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' | Where-Object DisplayName -like 'Microsoft Azure Storage Explorer' | Select-Object DisplayName, DisplayVersion, InstallLocation in an elevated PowerShell, or by re-running the Worklet evaluation, which should now exit code 0 compliant. The Automox activity log records the new DisplayVersion alongside the GitHub tag the Worklet matched against.

If the user clicked No or the prompt timed out, no files are changed on the endpoint, and the Automox activity log shows a user deferral with the timestamp. The next policy run repeats the evaluation and re-prompts. If the install fails, the Worklet surfaces the msiexec or Inno Setup exit code (1602 user cancel, 1603 fatal install error, 3010 reboot required) so you can triage from the activity log without RDP to the endpoint.