Skip to main content

Category filter

How to Check the .NET Versions Installed on Windows with Custom Scripts?

TL;DR

This guide provides ready-to-deploy PowerShell and Batch scripts to check the .NET versions installed on Windows, covering legacy 3.5, Framework 4.x, and modern .NET runtimes, remotely via Hexnode UEM. It outlines deployment procedures, runtime detection architecture, and troubleshooting steps to verify endpoint readiness before rolling out a new enterprise application.

Executive Summary

Auditing the .NET versions installed on Windows prevents launch failures, verifies software compatibility, and detects end-of-life (EOL) runtimes before rolling out new enterprise applications. However, devices frequently run multiple .NET versions side by side. Because each version family stores installation metadata in different locations, such as standalone registry keys and local filesystem paths, manually tracking them across an enterprise fleet is impractical.

Deployed through Hexnode UEM’s Execute Custom Script feature, the PowerShell and Batch scripts in this guide automate audit runtimes under the local NT AUTHORITY\SYSTEM context. They inspect native 64-bit registry keys, detect installed dotnet.exe runtimes, and returns a unified report straight back to the Hexnode UEM console without requiring external tools or user prompts.

Use Cases and Implementation Scenarios

  • Validating Environmental Dependencies for Applications: Verify that target endpoints have the required .NET runtime versions installed before pushing enterprise applications that rely on them.
  • Security and Compliance Auditing: Identify devices running older, unsupported .NET versions that require security patching or upgrades to comply with organizational security baselines.
  • OS Upgrade Readiness Assessments: Audit endpoints prior to major Windows OS migrations to record installed .NET versions, making it easy to identify and restore runtime dependencies required by critical applications post-upgrade.
  • Helpdesk Troubleshooting: Remotely inspect runtime versions from the Hexnode UEM console when troubleshooting third-party software installation failures or runtime crashes reported by end users.

Prerequisites for Executing the Scripts

To ensure the successful deployment of these .NET audit scripts, the target Windows endpoints must meet the following requirements.

  • Supported OS: Windows 10/11 (Home, Pro, Enterprise, Education) and Windows Server (2016, 2019, 2022, and 2025).
  • Architecture Support: Compatible with x64, x86, and ARM64 system architectures.
  • Management: Hexnode UEM agent must be installed and initialized.

PowerShell Script to Check Installed .NET Versions

This PowerShell script inspects Windows registry keys to map the active .NET Framework 4.x Release key to its corresponding release version, audits legacy .NET 3.5 version, and executes dotnet.exe to retrieve all modern .NET Core / 5+ runtimes.

Screenshot of Action History tab on the device details page of Hexnode UEM displaying .NET versions installed on the Windows endpoint using PowerShell script.

Batch Script to Check Installed .NET Versions

This Batch script uses native reg query commands to extract the active .NET Framework 4.x Release DWORD, converts hexadecimal value to decimal to map the release version, checks for legacy .NET 3.5 version, and executes dotnet.exe to list modern runtimes.

Screenshot of Action History tab on the device details page of Hexnode UEM displaying .NET versions installed on the Windows endpoint using Batch script.

How to Deploy the Script via Hexnode UEM?

  1. Save either the PowerShell script (as a .ps1 file) or the Batch script (as a .bat file) on your computer, depending on which script you intend to deploy.
  2. Log in to your Hexnode UEM portal.
  3. Navigate to Manage > Endpoints and select the target Windows device(s).
  4. Click Actions > Deployments > Execute Custom Script.
  5. Upload the saved script file and click Execute.

How to Verify Script Output in Hexnode UEM?

To check the execution status and view the script output:

  1. Navigate to Manage > Endpoints and select the target endpoint in the Hexnode UEM portal.
  2. Click the Action History tab to view the log of actions dispatched to the endpoint.
  3. Locate the Execute Custom Script entry in the action list.
    • If Status is “Success”: Click the Show Output button to inspect the formatted table displaying active .NET Framework releases, legacy .NET 3.5, and modern .NET runtimes.
    • If Status is “Failed”: Hover over the information icon (i) next to the status badge to review the execution error message and script error output.
    • If Status is “Pending/In progress”: The target endpoint is powered off, disconnected from the network, or sleeping. The script action remains queued in Hexnode UEM and will execute automatically when the device next checks in.

Key Technical Insights and Architecture Notes

  • .NET Framework 4.x Latest Version Reporting: .NET Framework 4.x updates install as in-place replacements. Because Windows stores .NET 4.x metadata in a single registry value that gets overwritten with every update, older 4.x entries no longer exist on the system. The script therefore reads and reports only the single active, highest version installed (such as 4.8.1).
  • Side-by-Side Modern Runtimes: Unlike .NET Framework, modern .NET (.NET Core and .NET 5+) versions run side-by-side in distinct installation folders. The script lists every installed major, minor, and patch release, as well as distinct workload packages (Microsoft.NETCore.App, Microsoft.WindowsDesktop.App, and Microsoft.AspNetCore.App) individually. Note that these scripts report globally installed shared runtimes and excludes private, self-contained application bundles.
  • Explicit Verification for Missing Runtimes: If modern .NET is not deployed on an endpoint, the script does not skip the validation or fail silently. It explicitly reports Modern .NET (dotnet.exe) Not Detected (or No Runtimes), providing administrators with affirmative confirmation that the check was performed.
  • Modern .NET Detection Across ARM64 Endpoints: On ARM64 devices (such as Microsoft Surface Pro X or Snapdragon X Elite endpoints), modern .NET can exist as a native ARM64 runtime or under an x64/x86 emulation directory. The scripts dynamically prioritize native 64-bit paths before checking architectural fallback locations, ensuring that installed runtimes are accurately reported without being misidentified by emulation layers.

Troubleshooting Common Issues

Issue Probable Cause Solution
Action History status shows “Pending” indefinitely. The target device is offline, powered off, or unable to reach the Hexnode UEM server. Ensure that the endpoint is connected to an active network. The action will be executed automatically once the device checks back in with Hexnode UEM.
Modern .NET packages appear in Installed Apps on the endpoint, but script output shows “Not Detected”. The installed runtime is inaccessible to the 64-bit SYSTEM audit context. This typically occurs under two conditions:
  • Architecture mismatch: A 32-bit (x86) runtime is installed on a 64-bit operating system. The script specifically inspects the native 64-bit directory (%ProgramFiles%\dotnet) to ensure 64-bit enterprise application compatibility.
  • Per-user installation: The runtime was installed within a specific user profile rather than machine-wide, leaving the dotnet.exe host unregistered in the system-level PATH environment variable.
  • Resolve architecture mismatches: Deploy the official 64-bit (x64) runtime package (e.g., dotnet-runtime-<version>-win-x64.exe or the x64 Windows Desktop Runtime) to the target endpoint.
  • Resolve per-user installations: Reinstall the modern .NET runtime system-wide or manually append the runtime directory to the system-level PATH variable. Once applied, re-execute the audit script to verify the detection.
Script output displays only legacy .NET (missing .NET 4.x). The registry key HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full is missing or corrupted on the target endpoint. The script runs successfully but cleanly skips .NET 4.x detection because the key cannot be read. On modern Windows operating systems, .NET Framework 4.x is an integrated OS component maintained by the Windows Component-Based Servicing (CBS) engine. Resolve the corruption by performing the following remediation workflow:
  • Repair the component store: Execute the following native commands on the affected endpoint to repair the underlying OS component store and restore the missing registry definitions:

    DISM.exe /Online /Cleanup-Image /RestoreHealth

    sfc /scannow

  • Restart the endpoint: Initiate a device reboot to ensure the repaired registry configurations and system files are fully applied.
  • Re-execute the script: Run the script again via Hexnode UEM to verify that the .NET Framework 4.x is successfully detected.

Frequently Asked Questions

What is the difference between .NET Framework and .NET Core?

.NET Framework is a Windows-exclusive runtime where 4.x versions install as in-place upgrades. .NET Core (and modern .NET 5+) is cross-platform and supports side-by-side installations, allowing multiple runtime versions to coexist on the same system simultaneously.

Why does Hexnode execute custom scripts under the SYSTEM account?

Executing custom scripts under the local SYSTEM context guarantees elevated privileges across all managed endpoints, allowing scripts to read protected registry keys and execute administrative commands without prompting the end user or requiring an active user login session.

Can these scripts be deployed to 32-bit (x86) Windows devices?

Yes. The scripts automatically detect the operating system architecture and query the appropriate native registry and filesystem locations on both 32-bit (x86) and 64-bit (x64) Windows devices.

Will the script detect the installed .NET versions if an endpoint is running specialized workloads, such as ASP.NET Core or Windows Desktop runtimes?

The modern .NET runtime check identifies all official Microsoft runtime packages associated with the native dotnet.exe host. This includes Microsoft.NETCore.App (base runtime), Microsoft.WindowsDesktop.App (WPF/Windows Forms desktop apps), and Microsoft.AspNetCore.App (web hosting components). Each detected package and its exact version string will appear on its own line in the script’s output.

Sample Script Repository