I was asked me the other day what the best method is to retrieve information about the build version for Exchange 2010 that’s installed on a server. There are two ways of approaching the problem. You can either fetch the information that’s stored on the server itself or you can interrogate the Active Directory to fetch the version information that’s stored for each server in the Microsoft Exchange container in the configuration naming context. Build information is updated by the Exchange Setup program each time it successfully runs on a server.

The first place to look is on the server itself. The Exchange Setup program updates the system registry with build information and I had this piece of PowerShell code floating around – I have no doubt that its genesis is somewhere in an email discussion – and thought that it would be good to share. The code to fetch the build information from the registry is as follows:

$RegExSetup = 'Software\\Microsoft\\ExchangeServer\\v14\\Setup'

$Server = (Get-Content env:ComputerName)

$Registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $Server)

$RegKey = $Registry.OpenSubKey($RegExSetup)

$V1 = "MsiBuildMajor"

$V2 = "MsiBuildMinor"

$BuildMajor = ($RegKey.GetValue($V1)) –as [String]

$BuildMinor = ($RegKey.GetValue($V2)) –as [String]

$ExVersion = $BuildMajor + “.” + $BuildMinor

Write-Host $Server “runs version” $ExVersion

Exchange 2010 server versions are reported in terms of a major build number and a minor build number. Exchange 2010 SP1 is major build 218 and minor build 15, so if you meet a server that reports a build number of 218.15, you know that it runs Exchange 2010 SP1.As proven in the screen shot, this code works. However, it’s probably not the most elegant code in the world, so feel free to improve it.

Interrogating the system registry to return Exchange server version data

Moving to how to extract Exchange server version data from Active Directory, you can run these commands to fetch and report the version number for a server. This is actually how Microsoft describe how to retrieve a server version in TechNet. The AdminDisplayVersion property is displayed with the Get-ExchangeServer cmdlet and in the About menu in EMC. However, you will see other versions reported elsewhere in the product. For example, the Mailbox Replication Service (MRS) faithfully reports that it runs version 218.0 in its mailbox move reports.

PS> Get-ExchangeServer -Identity ExServer1 | Format-Table Name, AdminDisplayVersion

Returning the version data for an Exchange 2010 server

To fetch build information for all servers in the organization, just omit the -Identity parameter and the name of the specific server as used in the example, which is what I do in the screen shot below. You can see that the build information is different to what’s reported from the registry in that Exchange tells you its “administrative display version” and then its major and minor build numbers. The administrative build in this instance is 14.1 for all servers, meaning that they are Exchange 2010 SP1 servers (Exchange 2010 is version 14). The difference between the reported major and minor builds is accounted for because two of the servers run the RTM version of SP1 while the other (an edge server that I haven’t gotten around to upgrading) runs an earlier build that Microsoft released during the SP1 development process.

Returning version data for all servers in the organization

I’ve also seen examples of code that use an LDAP lookup to fetch the same information:

PS> [ADSI]"LDAP://contoso.com/$(Get-ExchangeServer ExServer1| Select-Object -Expand dis*)" | Format-Table SerialNumber

Using LDAP to fetch the Exchange server version data from Active Directory

As you can see, the values reported for the serialNumber property of the server object include version 14.1, so that’s consistent, but the value of the build is 30218.15! I’m not suspicious (just paranoid), so I checked the property with ADSIEdit (below) and the same values are present. I guess that the Get-ExchangeServer cmdlet must trim the first two characters from the build number before it reports the data in AdminDisplayVersion.

Viewing server properties with ADSIEdit

All of this proves that the information is available and a range of solutions are available to extract it from a server or Active Directory – and that you can comfortably waste several hours poking around to discover information like this. Sometimes you will want to run code on a server and sometimes you’ll want to collate information from a range of servers, so it’s good to have the choice of approaches.

– Tony

More stuff like this can be found scattered throughout my Microsoft Exchange Server 2010 Inside Out book.