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: A "What's New" page with version history. A release notes page containing: Version Release date Changes 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?Will Intune device-only subscription get additional value in FY27
Will the Intune device-only subscription (Microsoft Intune announces device-only subscription for shared resources | Microsoft Community Hub) get the additional features which Intune P1 will get in FY27 (Microsoft 365 adds advanced Microsoft Intune solutions at scale - Microsoft Intune Blog), Intune Remote Help, Intune Advanced Analytics and Intune P2? This would have a huge impact of our planning how to manage special purpose devices in production environments without any user affinity. Deploying security and configuration settings, Windows Autopilot for Windows IoT Enterprise LTSC kiosk deployment, Windows Autopatch (servicing), Remote Help and FOTA for Zebra devices would be drivers to add these production devices to Intune.[On demand] Secure helpdesk support using Intune Remote Help
Take a closer look at key features and functionalities of Microsoft Intune Remote Help for Windows, Android, and macOS devices so you can start utilizing it today. Watch Secure helpdesk support using Intune Remote Help – now on demand – and join the conversation at https://aka.ms/SecureHelpdeskSupport. For more free technical skilling on the latest in Windows, Windows in the cloud, and Microsoft Intune, view the full Microsoft Technical Takeoff session list.
Intune Remote Help roadmap question
I’ve been patiently waiting for Microsoft to grant Intune administrators the ability to access Intune-managed devices unattended via Microsoft Remote Help. As I’m on the verge of acquiring TeamViewer for Business licenses, I’m curious to know if anyone with direct knowledge of the Remote Help roadmap could shed light on whether Microsoft intends to incorporate this crucial functionality. As a sidenote, the TeamViewer licenses are much cheaper than current Intune Remote Help licenses and includes much more functionality.
