Archive for the ‘Exchange’ Category

Exchange Server 2013 Makes It Easier: Finding Database Storage Information

November 23rd, 2012 1 comment

Q:Why a post on this, topic?

Ans:In few of my Exchange automation and reporting scripts I have to figure out storage statistics of databases such as total capacity, free space, free space percentage etc. And I find it more easier to discover such information in Exchange 2013.

In this post, I will show some sample Powershell snippets I used to get the statistics on Exchange 2010 and later we will see how to get the same information from Exchange 2013.


Finding Exchange 2010 Mailbox Database Storage Information:

Note: All below Cmdlets have to be executed from Exchange Management Shell.  If you use native powershell.exe and PSSession method without using Exchange Remoting module it may behave differently due to Deserialization.

Scenario 1: Database is hosted on a Lun/Disk with Drive Letter Assigned


1) Getting Database Details

$DB = "MBX-DB01"
$Database = Get-MailboxDatabase $DB
$DBServer = $Database.Server.Name
$DBLun = $Database.EdbFilePath.DriveName


2) Calling WMI to get the volume information

#Below cmdlet should be run in one line
$Lun = Get-WmiObject -Class WIn32_Volume -Filter "DriveLetter='$DBLun'" `
-ComputerName $DBServer -Property DriveLetter,Capacity,FreeSpace

3) Composing the useful information

$DiskName = $Lun.DriveLetter
 $DiskCapacity = [math]::round(($Lun.Capacity/1GB),2)
 $DiskFreeSpace = [math]::round(($Lun.FreeSpace/1GB),2)

In above two lines, we are converting the byte value to GB and rounding it to two decimal point

4) Finding Percentage of Free Space

$FreePercentValue = [math]::round(($DiskFreeSpace * 100 / $DiskCapacity),2)

Use above cmdlet if you want to further use the value for operations such as comparison or sorting.

Use below if your purpose is just to print or report, the difference is nothing but, in above method the actual value if it is 82.10 will be shown as 82.1 and in below method it will still show as 82.10 but the difference is below will give you a string value and you cannot do mathematical operations with strings.

$FreePercentage = "{0:N2}" -f $FreePercentValue


Scenario 2: Database is hosted on a Lun/Disk with MountPoint Access Path

1) Getting Database Information

 $DB = "MBX-DB02" $Database = Get-MailboxDatabase
 $DB $DBServer = $Database.Server.Name
 #We are not using drive letter here as there is no -
 #drive letter assigned to the volume.
 $DBLun = $Database.EdbFilePath.PathName

Now we have to make a correct calculation to refer to the mount point. The mounted folder information is stored in two properties of win32_volume instance. Those are Caption and Name.  But how do you know dynamically what is the mount volume path from just the complete path of a database, not possible.  Here you should know the importance of having standards for naming convention, if you have a unique naming convention for your Database Luns and Mount Volumes , you can use something like this. In my scenario the total length of the Mount Volume from the Edbfile path was 24. So I extract a substring to match with the mount volume. Secondly I am replacing every back slash with two backslash, this is not a must but if you are using WMI Query you need to provide two slashes and not one.


$DBLun = $DBLun.Substring(0,24)
$DBLun = $DBLun.Replace("\","\\")
$Lun = Get-WmiObject -Class WIn32_Volume -Filter "Name='$DBLun'" `
-ComputerName $DBServer -Property Name,Capacity,FreeSpace

There is no drive letter, so we record only the mounted volume path from the Name property.

$DiskName = $Lun.Name
$DiskCapacity = [math]::round(($Lun.Capacity/1GB),2)
$DiskFreeSpace = [math]::round(($Lun.FreeSpace/1GB),2)


Calculating Percentage Value

$FreePercentValue = [math]::round(($DiskFreeSpace * 100 / $DiskCapacity),2)
[string]$FreePercentage = "{0:N2}" -f $FreePercentValue


From above you can see, such a task would be not easy but manageable in a single on-premise or SMB environment. What about a large distributed enterprise or even in hosting environments. Here Exchange 2013 comes to rescue. You don’t have to make a single WMI call to get above described information. Everything is available from Exchange 2013 Mailbox Database Cmdlets.


A Quick look at Exchange 2013 Improvements in this Context:

I will try to show the changes by using the practical approach here. we will only explore the possibilities, it can be used in different ways according to your need.

$DB = "MBX-DB03"
$Database = Get-MailboxDatabase $DB
$DBServer = $Database.Server.Name
$DBCopyStatus = Get-MailboxDatabaseCopyStatus -identity $DB\$DBServer


Above you see I have used Get-MailboxDatabase cmdlet, which will give me the server name where the DB is currently mounted. Next I use Get-MailboxDatabaseCopyStatus cmdlet with -identity parameter in a form of DBName\ServerName – that is how a database copy is identified in DAG.


#Mountpoint or Drive Letter


The property DatabasePathIsOnMountedFolder and LogPathIsOnMOuntedFolder will tell you if the files are hosted on a Volume mounted to a folder or assigned with a drive letter. This is something very useful as to you no longer need to manually identify if the Database is using a mounted folder or  disk drive.


DatabaseVolumeMountPoint gives you the exact mounted folder or the drive letter

#DB Volume Mount Point or Drive Letter (Ends with "\" )
$DiskName = $DBCopyStatus.DatabaseVolumeMountPoint


LogVolumeMountPoint gives the Logs location

#Log Volume Mount Point or Drive Letter (Ends with "\" )


Surprisingly, you can even get the physical Disk Volume Name.

#Physical Disk Name


Now lets collect other information we need for reporting or other automation scripts.

$DiskCapacity = $DBCopyStatus.DiskTotalSpace
$DiskFreeSpace = $DBCopyStatus.DiskFreeSpace
$DiskFreePercentage = $DBCopyStatus.DiskFreeSpacePercent


Unfortunately above three fields are only for DB Location, If you have DB and LOG on different LUN this cmdlet doesn’t give that ( at least as per my knowledge until I write this)

What I understand is most of the above information is added or useful for the new Autoreseed feature, and the three properties below as well.


#Properties relevant to Auto Reseed


Some information around the Numbers given by Exchange Cmdlet

DiskCapacity  and DiskFreeSpace are of  Microsoft.Exchange.Data.ByteQuantifiedSize Type, means which is a complete object with some methods and properties. So use Get-Member and look at it. By default the value is printed in a number + text format (a display friendly format) but that may not be what you always want to have.  there is a bit of calculation changes:

In My Lab Database:

!Assume DiskCapactiy is 26707226624 in Bytes.

$DiskCapacity.ToGB() will  give you 24

But if you do $DiskCapacity.ToBytes()  / 1GB will give you 24.87

For some calculations that .87 is not something you can avoid.

DiskFreeSpacePercentage is an integer (System.Int32) so nothing to worry there.


Few Tips:
 #Get a list of Active Database Copies on the currently connected server
 Get-MailboxDatabaseCopyStatus -Active
 #Get a list of All Active Database Copies on a particular server
 Get-MailboxDatabaseCopyStatus -Active -Server <ServerName>
 #To get some more useful Database Statistics `
 #Such as Physical size of the Database and `
 #AvailableNewMailboxSpace (This is not exactly the thing called whitespace) `
 #Below cmdlet is not new in Exchange 2013.
 Get-MailboxDatabase <DBName> -Status

I hope you got some insights, and this post was helpful.

I am happy to learn from you as well, please drop your feedback, comments, or suggestions in the comments area.

Enjoy Learning!

Exchange 2013 – New Attribute to verify AD Preparation

November 22nd, 2012 No comments

Exchange 2013 Introduced a new Attribute to verify your Active Directory preparation. The attribute is called msExchProductId (ms-Exch-Product-ID) on the Organization container.

The attribute is added in the schema preparation even from Exchange 2010 ( I didn’t explore on versions earlier than 2010). But it was not added to the Organization Container Object in Exchange 2010.

One of the Schema preparation ldf file contained the below entry:

dn: CN=ms-Exch-Product-ID,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDescription: ms-Exch-Product-ID
adminDisplayName: ms-Exch-Product-ID
attributeID: 1.2.840.113556.1.4.7000.102.50864
isMemberOfPartialAttributeSet: FALSE
isSingleValued: TRUE
lDAPDisplayName: msExchProductID
name: ms-Exch-Product-ID
oMSyntax: 64
objectCategory: CN=Attribute-Schema,<SchemaContainerDN>
objectClass: attributeSchema
rangeUpper: 100
schemaIdGuid:: oFi/HBJeeEq46kJlbfU5Jg==
searchFlags: 0


In Exchange 2010 if you see the Organization container properties, you wont find it:

Now this is what you see in Exchange 2013:


This attribute is updated only during PrepareAD execution.  So verify this attribute only after PrepareAD is completed, it will not be updated during PrepareSchema. In the same context if PrepareSchema and PrepareAD is executed in separate phases (which is normal in most of the Enterprises) you would still need to verify individual steps. You can refer below TechNet article for details:

An extract from the TechNet  Article:

Do the following to verify that Active Directory has been successfully prepared:

We can not complete anything nowadays without thinking of how to do it in Powershell



Categories: Exchange Tags:

Fix for Exchange 2013 Preview few /RecoverServer setup failures

September 30th, 2012 2 comments

I know you are already playing with Exchange 2013 Preview, so I am.  I had a failure on one of my server running on Windows Server 2012 RC.  Hence I had to rebuild the server and recover Exchange.

Note that whatever I write below on a pre-release version of Windows Server and Exchange Server.


Lets get started, the procedure remains same as for Exchange Server 2010.

  • Build a Windows Server with same OS, Service Pack and configuration
  • Configure Disks and Drives same as the broken Exchange Server
  • Add necessary windows feature for the server roles installed on the original server
  • Install Exchange Server pre-requisites
  • Reset AD Computer Account of the Exchange Server
  • Add the new server to Domain
  • Login with the Installation account for Exchange
  • Run Exchange setup /RecoverServer Switch
  • Restore Databases if required

My idea is to not run through the steps above, that would be logical to do when we have a documented instruction from Microsoft with a RTM version of Exchange 2013. Here I would like to share the issues I did run into while recovering and detail the solution I did apply.

First Error: Disaster Recovery setup needs access to log drive and mailbox database drive

  • Setup.exe /Mode:RecoverServer /IAcceptExchangeServerLicenseTerms

Fix: Its clear that there is no folder path exist (but the drive C exists), I have created the folder “C:\ExDBs\MBX-DB05” and ran the setup again.


Second Error: Setup is still looking for the mailbox database file not just the folder path

Fix : 

  1. Create a dummy edb file and restore the original edb file after the recovery setup is completed
  1. Restore the database files from backup (this has to be explored later)


Third Error: once the errors above were fixed setup did progress and the next error appeared during “Mailbox Role Component 2”“The AD configuration for virtual directory ‘Autodiscover’ already exist”, Please remove this AD configuration manually”

Fix: Delete the object as referred in the error message


Error Number Four: Unable to continue a failed RecoverServer Setup

Now setup says its already installed and doesn’t progress, and I did test accessing ecp and No – the installation is not complete.

If you do a normal setup /mode:install it says “Setup failed previously with action “DisasterRecovery” you can’t resume setup by performaing the action ‘Install’ “

The ‘already installed’ error could be fixed by cleaning the Setup Watermark or other registry cleanup, but I didn’t go that way.

Fix: So basically the fix was to restart the recovery process, I was on a hyper-v setup hence had to just apply the old snapshot so it was quit easy for me.


Error Five: Running setup after fixing all the above errors still threw below error, another AD Configuration for virtual directory exists and remove this AD configuration manually, this time the object was “Microsoft-Server-ActiveSync’ under same location as the previous Autodiscover virtual directory object.

Fix: Delete the object as referred in the error message.

A RecoverServer Setup after fixing all the above error did complete successfully:


Some analysis through the ExchangeSetup Log:

Its better to have a look at the setup logs and I could see setup is first trying to remove existing entries, but as we have seen above the objects were not really deleted by this command.

As seen from the setup log, there are other objects on which similar actions are performed and no errors thrown, such as Powershell, ecp, owa, oab , ews virtual directory objects

To Summarize:

The updated steps to perform RecoverServer setup on Exchange 2013 Preview combined Role server on a Windows Server 2012 is as follows:

  1. Build a Windows Server with same OS, Service Pack and configuration
  1. Configure Disks and Drives same as the broken Exchange Server
  1. Add necessary windows feature for the server roles installed on the original server
  1. Install Exchange Server pre-requisites
  1. Reset AD Computer Account of the Exchange Server
  1. Add the new server to Domain
  1. Login with the Installation account for Exchange
  1. Perform the below sub tasks to avoid any errors listed above:
    1. Make sure you have the LogFolder location created
    1. Make sure the .edb file exist in the EdbFilePath location before setup
      1. If you have any other Exchange Server then run Get-MailboxDatabase cmdlet to get LogFolderPath and EdbFilePath
      2. If it’s the only Exchange server you have, use ADSIEDI to find out the LogFolderPath and EdbFilePath
    2. Remove “CN=Autodiscover  (Exchange Back End)” and “CN=Microsoft-Server-ActiveSync (Exchange Back End)” from CN=HTTP Container of the CN=<ExchangeServerName>  Object in Configuration Partition of the Active Directory Domain
  2. Run Exchange setup /RecoverServer Switch (make sure you open cmd.exe or powershell.exe as Administrator before firing the setup command)
  3. Restart the Server
  4. Restore Databases if required


I hope you liked this post.

Please comment if you have any feedback.

Categories: Exchange Tags: ,