RemoteHelp.exe reports FileVersion 10.4.10008.1000 while the product version is 5.2.1037.0

Problem 1 - File Version

Because RemoteHelp.exe reports FileVersion 10.4.10008.1000 while the product version is 5.2.1037.0, this makes Intune detection, packaging, inventory reporting, and supersedence unnecessarily difficult.

Remote Help publishes release versions such as 5.2.1037.0, but the primary executable reports a different FileVersion (10.4.10008.1000). This prevents administrators from using standard file-version detection methods in Intune, Configuration Manager, and software inventory solutions. Administrators must instead enumerate uninstall registry entries and distinguish between the Burn bundle and MSI entries. Aligning the executable FileVersion/ProductVersion with the published release version would significantly simplify enterprise application management.

Remote Help combines both common enterprise packaging mistakes:

• The executable version doesn't match the advertised product version.
• The installer creates two uninstall entries with the same DisplayName.

Neither issue is fatal, but together they make what should be a trivial Intune detection rule far more complicated than it needs to be.

From an enterprise management perspective, this causes several problems:

• Application detection scripts become more complicated.
• Supersedence rules are harder to create.
• Administrators waste time investigating apparent version mismatches.
• Software inventory reports show different versions depending on which source is queried.
• Automated packaging systems cannot simply use file versioning.
• Documentation has to explicitly state "do not use the EXE version".

Problem 2 - Duplicate Uninstall entries

The Burn bootstrapper situation makes it even more confusing because there are two uninstall entries, both called

Remote Help, both reporting version 5.2.1037.0, but representing two different installer components.

This isn't unique to Remote Help unfortunately. Microsoft has a history of doing similar things with:

• Company Portal
• Teams (various generations)
• Edge WebView2
• Visual Studio bootstrapper installers
• Azure VPN Client
• Some Defender components

where the executable version represents the underlying codebase rather than the product release version that administrators actually deploy.

The file version should be treated as an API contract with administrators. Once an application is broadly managed by enterprises, changing versioning schemes or exposing an internal build number instead of the published product version makes lifecycle management considerably harder than it needs to be.

Problem 3 - Unversioned download URL

The URL to download the latest version https://aka.ms/downloadremotehelp is only a redirect link, not a versioned artefact.

The download URL itself does not expose any metadata about:

• The current Remote Help version
• The release date
• When the installer was last updated
• Previous versions
• A changelog

Microsoft's documentation simply points administrators to the download link for installation.

When you download the 'latest version' you always receive whatever Microsoft currently considers the latest installer, but the URL itself provides no version information.

For enterprise deployment scenarios, the ideal solution would be one of:

1. A "What's New" page with version history.
2. A release notes page containing:
   • Version
   • Release date
   • Changes
3. Versioned download URLs, for example:
   • RemoteHelp-5.2.1037.0.exe
   • RemoteHelp-5.2.1037.0.msi

Please can these three issues be resolved to ease some of the unnecessary burden placed on Intune Administrators?