Skip to main content

Extracting the Exchange 2010 version number for a server

 Extracting the Exchange 2010 version number for a server



I was asked 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:
Code:
$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.
Code:
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:
Code:
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.

Comments

Popular posts from this blog

Integration with vCloud Director failing after NSXT upgrade to 4.1.2.0 certificate expired

  Issue Clarification: after upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Issue Verification: after Upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Root Cause Identification: >>we confirmed the issue to be related to the below KB NSX alarms indicating certificates have expired or are expiring (94898)   Root Cause Justification:   There are two main factors that can contribute to this behaviour: NSX Managers have many certificates for internal services. In version NSX 3.2.1, Cluster Boot Manager (CBM) service certificates were incorrectly given a validity period of 825 days instead of 100 years. This was corrected to 100 years in NSX 3.2.3. However any environment originally installed on NSX 3.2.1 will have the internal CBM Corfu certs expire after 825 regardless of upgrade to the fixed version or not. On NSX-T 3.2.x interna...

Calculate how much data can be transferred in 24 hours based on link speed in data center

  In case you are planning for migration via DIA or IPVPN link and as example you have 200Mb stable speed so you could calculate using the below formula. (( 200Mb /8)x60x60x24) /1024/1024 = 2TB /per day In case you have different speed you could replace the 200Mb by any rate to calculate as example below. (( 5 00Mb /8)x60x60x24) /1024/1024 =  5.15TB  /per day So approximate each 100Mb would allow around 1TB per day.

Device expanded/shrank messages are reported in the VMkernel log for VMFS-5

    Symptoms A VMFS-5 datastore is no longer visible in vSphere 5 datastores view. A VMFS-5 datastore is no longer mounted in the vSphere 5 datastores view. In the  /var/log/vmkernel.log  file, you see an entry similar to: .. cpu1:44722)WARNING: LVM: 2884: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device shrank (actual size 18424453 blocks, stored size 18424507 blocks) A VMFS-5 datastore is mounted in the vSphere 5 datastores view, but in the  /var/log/vmkernel.log  file you see an entry similar to: .. cpu0:44828)LVM: 2891: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device expanded (actual size 18424506 blocks, stored size 18422953 blocks)   Purpose This article provides steps to correct the VMFS-5 partition table entry using  partedUtil . For more information see  Using the partedUtil command line utility on ESX and ESXi (1036609) .   Cause The device size discrepancy is caused by an incorrect ending sector for the VMFS-5 partition on the ...