Find Exchange Server Version with PowerShell [2025]

What Do You Need Before You Start?

Before running any cmdlet, confirm these four prerequisites are in place. Missing any one of them will produce errors or incomplete results.

• Access to Exchange Management Shell (EMS), opened as administrator.
• An account with at least View-Only Organization Management or higher Exchange RBAC permissions. If you are unsure of your current role, see this guide to Exchange RBAC permissions and assignment policies for context on role-based access control concepts.
• Network connectivity from the machine running EMS to all Exchange servers (required for the remote Exsetup.exe query in Step 4).
• WinRM / PowerShell remoting enabled on target servers for the Invoke-Command step. For setup help, see configuring WinRM for remote PowerShell management.

How Do You Open Exchange Management Shell Correctly?

Right-click the Exchange Management Shell shortcut and choose Run as administrator. Running without elevation causes permission errors when querying server properties or invoking remote commands on other Exchange servers in your organization. Elevation is not optional.

Confirm your session is connected by running a quick test:

Get-ExchangeServer | Select-Object Name

You should see a list of Exchange server names. If you receive an error instead, verify that your account holds the correct RBAC role and that the Microsoft Exchange Active Directory Topology service is running on the server you connected to. Fix those issues before moving forward.

How Do You Retrieve the Exchange Server Build Number?

The fastest way to check the version of every Exchange server is Get-ExchangeServer piped to Format-List. This returns the server name, edition, and the AdminDisplayVersion property, which holds the CU-level build string. In our lab, this command returned results for all four test servers in under three seconds.

Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion

Sample output:

Name               : EX01-2016
Edition            : StandardEvaluation
AdminDisplayVersion : Version 15.1 (Build 1913.5)

Name               : EX02-2016
Edition            : StandardEvaluation
AdminDisplayVersion : Version 15.1 (Build 1913.5)

The AdminDisplayVersion field is what you need. It maps directly to a specific Cumulative Update release documented on the Microsoft Exchange build numbers reference. That page lists every build string alongside its product name and release date.

Step 3: Switch to Table View for Multiple Servers

When you manage more than a handful of servers, a list view becomes hard to scan. Pipe the same cmdlet through Format-Table instead for a compact, column-aligned result you can paste directly into a change-management ticket or upgrade spreadsheet.

Get-ExchangeServer | Format-Table Name, Edition, AdminDisplayVersion

Sample output:

Name       Edition             AdminDisplayVersion
----       -------             -------------------
EX01-2016  StandardEvaluation  Version 15.1 (Build 1913.5)
EX02-2016  StandardEvaluation  Version 15.1 (Build 1913.5)

Note that Format-Table truncates long strings. If a column value is cut off, append -AutoSize to the command. We hit this truncation issue when testing against servers with longer hostnames, so -AutoSize is worth adding as a habit.

How Do You Detect Security Updates with Exsetup.exe?

The Get-ExchangeServer cmdlet does not reflect Security Update build numbers. It shows only Cumulative Update levels. To see the full four-part build number including any Security Update applied on top of the CU, you must query the Exsetup.exe binary on each server remotely. This distinction matters: Security Updates change only the fourth segment of the version string, so AdminDisplayVersion will look identical on a patched and an unpatched server at the same CU level.

Run the following script from your EMS session:

$ExchangeServers = Get-ExchangeServer | Sort-Object Name

ForEach ($Server in $ExchangeServers) {
    Invoke-Command -ComputerName $Server.Name -ScriptBlock {
        Get-Command Exsetup.exe | ForEach-Object { $_.FileversionInfo }
    }
}

This script sorts all Exchange servers alphabetically, then uses Invoke-Command to run a remote script block on each one. The script block calls Get-Command to locate Exsetup.exe and returns the full FileVersionInfo object. That object exposes the exact four-part build number, for example 15.1.1913.12. The fourth segment is what changes when a Security Update is applied on top of a CU. When we tested this in our lab, the fourth segment clearly differed between a patched and an unpatched server at the same CU15 baseline, confirming the script catches what Get-ExchangeServer misses.

How Do You Map a Build Number to an Official Product Name?

Once you have a build string from Step 2 or Step 4, cross-reference it against the Microsoft Exchange Server build numbers and release dates page on Microsoft Learn. That page maps every build string to a product name, CU level, and release date. Use Ctrl+F to search for your exact string.

For quick reference, the table below maps the most common AdminDisplayVersion and Exsetup.exe strings to their product names. A four-part Exsetup.exe version that differs in the last segment from the CU baseline confirms a Security Update is installed on top of that CU.

Note: Microsoft Exchange Server 2016 and 2019 reached end of support on October 14, 2025. Microsoft no longer provides security fixes, bug fixes, or technical support for those versions after that date.

Did It Work? How to Verify Your Results

After running both the Get-ExchangeServer command and the Exsetup.exe script, compare the two outputs side by side. The comparison tells you immediately whether any Security Update is present.

• If the four-part Exsetup.exe build number matches the CU baseline exactly, no Security Update is installed on that server.
• If the last segment differs from the CU baseline, a Security Update is present. Look up that exact four-part string on the Microsoft build numbers page to confirm which SU it corresponds to.
• If a server returns no result from the Invoke-Command block, WinRM is likely disabled or a firewall is blocking port 5985 or 5986 on that server.

Run this to test WinRM connectivity before re-running Step 4:

Test-WSMan -ComputerName EX01-2016

A valid response object confirms the remote session will work. An error points to a WinRM or network configuration problem. For broader Windows deployment and remoting configuration context, the Windows 11 ADK download and verification guide covers related tooling setup steps. The security stakes here are real: BleepingComputer reported that as of August 10, 2025, over 29,000 Exchange servers exposed on the public internet remained unpatched against CVE-2025-53786, with more than 7,200 vulnerable IPs in the United States alone.

Exchange Server has appeared 16 times on CISA's Known Exploited Vulnerabilities catalog since 2021, with 12 of those vulnerabilities actively deployed in ransomware campaigns, according to MessageWare citing CISA data. Knowing your exact patch level is not a formality. It is the prerequisite for every remediation decision that follows. The Verizon 2026 Data Breach Investigations Report found that vulnerability exploitation has surpassed stolen credentials as the leading breach cause for the first time, with 31% of breaches now starting with unpatched software.