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:
$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://$(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.


Popular posts from this blog

Recreating a missing VMFS datastore partition in VMware vSphere 5.x and 6.x

    Symptoms A datastore has become inaccessible. A VMFS partition table is missing.   Purpose The partition table is required only during a rescan. This means that the datastore may become inaccessible on a host during a rescan if the VMFS partition was deleted after the last rescan. The partition table is physically located on the LUN, so all vSphere hosts that have access to this LUN can see the change has taken place. However, only the hosts that do a rescan will be affected.   This article provides information on: Determining whether this is the same problem Resolving the problem   Cause This issue occurs because the VMFS partition can be deleted by deleting the datastore from the vSphere Client. This is prevented by the software, if the datastore is in use. It can also happen if a physical server has access to the LUN on the SAN and does an install, for example.   Resolution To resolve this issue: Run the  partedUtil  command on the host with the issues and verify if your output

ما هى ال FSMO Roles

  بأختصار ال FSMO Roles هى اختصار ل Flexible Single Operation Master و هى عباره عن 5 Roles فى ال Active Directory و هما بينقسموا لقسمين A - Forest Roles 1- Schema Master Role و هى ال Role اللى بتتحكم فى ال schema و بيكون فى Schema Master Role واحد فى ال Forest بيكون موجود على Domain Controller و بيتم التحكم فيها من خلال ال Active Directory Schema Snap in in MMC بس بعد ما يتعمل Schema Register بواسطه الامر التالى من ال Cmd regsvr32 schmmgmt.dll 2-Domin Naming Master و هى ال Role المسئوله عن تسميه ال Domains و بتتأكد ان مفيش 2 Domain ليهم نفس الاسم فى ال Forest و بيتم التحكم فيها من خلال ال Active Directory Domains & Trusts B- Domain Roles 1-PDC Emulator و هى ال Role اللى بتتحكم فى ال Password change فى ال domain و بتتحكم فى ال time synchronization و هى تعتبر المكان الافتراضى لل GPO's و هى تعتبر Domain Role مش زى الاتنين الاولانيين و بيتم التحكم فيها من خلال ال Active directory Users & Computers عن طريق عمل كليك يمين على اسم الدومين و نختار operations master فى تاب ال PDC Emu

Unlock the VMware VM vmdk file

  Unlock the VMware VM vmdk file Kill -9 PID Sometimes a file or set of files in a VMFS become locked and any attempts to edit them or delete will give a device or resource busy error, even though the vm associated with the files is not running. If the vm is running then you would need to stop the vm to manipulate the files. If you know that the vm is stopped then you need to find the ESX server that has the files locked and then stop the process that is locking the file(s). 1. Logon to the ESX host where the VM was last known to be running. 2.  vmkfstools -D /vmfs/volumes/path/to/file  to dump information on the file into /var/log/vmkernel 3.  less /var/log/vmkernel  and scroll to the bottom, you will see output like below: a. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)FS3: 130: <START vmware-16.log> b. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)Lock [type 10c00001 offset 30439424 v 21, hb offset 4154368 c. Nov 29 15:49:17 vm22 vmkernel: gen 664