Upgrade Mimecast for Outlook

What the Mimecast for Outlook upgrader does

This Automox Worklet™ upgrades the Mimecast for Outlook add-in on Windows endpoints to a version you pin in the policy. The Worklet reads Add/Remove Programs (ARP) registry entries to find the installed Mimecast for Outlook product, compares its DisplayVersion to your target, and triggers an MSI upgrade only when the installed version is lower.

Mimecast ships separate 32-bit and 64-bit MSI installers because the add-in must match the bitness of the Outlook process it loads into, not the bitness of Windows. The evaluation script walks both ARP hives so a 64-bit Outlook on a 64-bit Windows endpoint is recognized, as is a 32-bit Outlook on a 64-bit Windows endpoint. You upload both MSI files to the Automox console payload and configure $AppVersion, $32bitFilename, and $64bitFilename as policy variables.

The evaluation phase reads two registry trees: HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall and HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall. The Worklet filters DisplayName entries that match "Mimecast for Outlook" and parses the DisplayVersion value as a System.Version object so semantic comparison works correctly (7.10.0.5 is correctly treated as newer than 7.9.0.79). Endpoints already on the target version or newer exit compliant, and endpoints without Mimecast for Outlook exit as not applicable.

The remediation phase launches the matching MSI with Start-Process -FilePath "$ScriptDir\$64bitFilename" -ArgumentList "/quiet" -Wait (substituting $32bitFilename for 32-bit Outlook). The /quiet argument suppresses the installer UI, and -Wait blocks the script until the MSI returns. After remediation, the ARP DisplayVersion reflects the new version, and Outlook loads the upgraded add-in on its next launch.

Why keep the Mimecast for Outlook add-in current

Mimecast for Outlook is the surface where end users actually interact with Mimecast's email security stack: large file send, attachment protection, URL inspection, and the report-phish button users click when a suspicious email lands in their inbox. When the add-in drifts behind, those controls degrade quietly. Older add-in builds lose compatibility with new Outlook builds on the Microsoft 365 monthly enterprise channel, the report-phish button stops returning telemetry to the Mimecast tenant, and end users see plug-in load errors that route directly to the help desk instead of to security.

Running the upgrade through Automox handles the bitness branching automatically. The same policy covers a 32-bit Outlook on a 64-bit Windows endpoint, a 64-bit Outlook on a Windows 11 workstation, and any 32-bit Outlook installs that remain after an Office migration. The /quiet MSI run does not show installer UI to the user, and the upgrade applies the next time Outlook restarts so the report-phish button keeps reporting to the Mimecast tenant without a help-desk ticket.

How Mimecast for Outlook upgrades work

1. Evaluation phase: The Worklet reads both ARP registry trees (HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall and the WOW6432Node mirror) and filters DisplayName entries matching "Mimecast for Outlook". For each match, it parses DisplayVersion as a System.Version and compares against the $AppVersion target. Endpoints with no match exit not applicable. Endpoints already at or above the target exit compliant. Anything below is flagged for remediation.

2. Remediation phase: The Worklet branches on which ARP hive holds the Mimecast entry, then runs the matching MSI with Start-Process -FilePath "$ScriptDir\$64bitFilename" -ArgumentList "/quiet" -Wait (or $32bitFilename for 32-bit Outlook). A successful install increments $success and the Worklet exits 0 with "Successfully patched Mimecast for Outlook". If Start-Process throws, the catch block writes "Installation failed" and exits 1 so the failure surfaces in Automox activity logs.

Mimecast for Outlook upgrade requirements

• Windows 10 or later with Microsoft Outlook installed (Microsoft 365 Apps, Outlook 2019, or Outlook 2021)

• Mimecast for Outlook already installed; this Worklet upgrades existing installations and does not perform first-time installs

• Both 32-bit and 64-bit Mimecast for Outlook MSI files uploaded to the Automox console payload

• $AppVersion set to the target version string (for example, 7.10.0.5) – used for the System.Version comparison

• $32bitFilename and $64bitFilename set to the exact MSI filenames as uploaded; the script does not glob or auto-discover

• Download the matching installers from the Mimecast Community portal (community.mimecast.com), pinning the same build for the 32-bit and 64-bit MSI pair

• Schedule outside heavy Outlook hours, or accept that an actively running Outlook process may force the installer to defer the file replacement until the next Outlook restart

Expected Mimecast add-in state after upgrade

After a successful remediation, the ARP DisplayVersion for Mimecast for Outlook matches the $AppVersion you pinned, and the next Outlook launch loads the new add-in DLL from C:\Program Files\Mimecast\Mimecast for Outlook\ (or the WOW6432Node Program Files (x86) path for 32-bit Outlook). The Mimecast ribbon, report-phish button, and large file send entry point are present in the user's Outlook window, and the add-in registers with the Mimecast tenant on first send. Subsequent Automox policy runs report the endpoint as compliant without re-running remediation, because the evaluation phase finds DisplayVersion at or above the target.

Validate by running Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object DisplayName -like "Mimecast for Outlook" | Select-Object DisplayName, DisplayVersion against a pilot endpoint, and confirm the returned DisplayVersion matches the target. For 32-bit Outlook on 64-bit Windows, point the same query at HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* instead. If installation fails, the Worklet exits 1 with "Installation failed" in stdout – the common causes are an incorrect $32bitFilename or $64bitFilename string, a missing MSI in the policy payload, or Outlook locking add-in DLLs because the process is running. Close Outlook on the endpoint, rerun the policy, and re-check DisplayVersion to confirm the upgrade applied.