VMworld 2013: Successfully Virtualize Microsoft Exchange Server #VAPP5613

Alex Fontana, creator of the VMware documentation about virtualizing Microsoft Exchange products told all listeners about the best practices and pitfalls you can experience.

Some information was presented last year in Barcelona, but still provided useful information which I will pass on to my Exchange friends. My highlights of this session:

  • Use EagerZeroThick virtual disks instead of thin provisioned virtual disks. I believe this is only for the disks hosting mailbox databases. This due to the fact that there is a small performance penalty when writing new blocks to a thin provisioned disk.
  • When having multiple virtual disks in your virtual Exchange server, configure multiple vSCSI adapters (4 is the max, so when having 4 or more virtual disks, use them all and split the virtual disks among the vSCSI adapters). During testing, this has brought the Exchange latency from 60 to around 10ms.
  • Exchange latency should be under 10ms and should be no more then 20ms.
  • When using vMotion, make sure you use Jumbo Frames on the vMotion network. When this is not possible, configure the ‘SameSubnetDelay’ parameter to 2000ms instead of the default 1000ms on the DAG cluster.
  • Load balancing using the vCloud Networking & Security Edge is supported and works fine. No need to use a hardware or third-party load balancer.

A nice session and experienced speaker, thanks Alex!

Exchange 2013 DAG quorum lost

Today some maintenance had to be done on a Exchange 2013 mailbox server, which was in a 2-node cluster using a fileserver share as witness.

The particular Exchange server was disabled on our load balancer to drain connections. Next, the StartDagServerMaintenance.ps1 script was used to prevent new sessions and to failover the mailbox databases to the other Exchange server.

These actions were performed OK and the server was ready to be shut down and perform maintenance. After shutting down, the mailbox databases were dismounted on the second Exchange server and could not be mounted anymore. Uh-oh..

The reason for not being able to mount the mailbox databases was due to the fact that quorum was lost. I saw the following error when opening up the Microsoft Failover Cluster Manager:

The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk.
Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

The strange thing was, that the fileserver running the witness share was fine and reachable.
Because the offline Exchange server could not be brought online in a matter of minutes, I had to override the quorum safety and bring the Cluster Service back online using the ForceQuorum command:

net start clussvc /fq

I got this command from the following Microsoft TechNet Article: http://technet.microsoft.com/en-us/library/cc770620(v=ws.10).aspx

After running the command, the cluster was back online and mailbox databases were abled to be mounted again. Just before maintenance was completed on the Exchange server and before booting it up again, I disabled the Cluster Service on the secondary server because of the fact that this server was running in ForceQuorum state. This to prevent data loss or corruption.

When the server was booted up again, I started the Cluster Services on both servers and everything returned back to normal.

The reason for the lost quorum is probably due to the fact that the Cluster Service is configured with “Node Majority”, which isn’t a setting you want with 2 nodes =)
Tomorrow we will investigate if the “Node and File Share Majority” is a better choice, which probably is due to the fact that we are using a file server share as witness.

Exchange 2013 Management Shell from Windows 8

I’m testing out the new functionalities of Exchange 2013 in my testlab and get familiar with the product as we are probably going to use this in production.

While testing, I was wondering if it would be possible to manage Exchange 2013 remotely from my Windows 8 client.
Ofcourse you can use the ECP (Exchange Control Panel) but managing your environment with Powershell is something ‘more compliant’ with the management ways Microsoft sees it (And it’s cooler).

Installing the Exchange Management Shell on Windows 8 is not going to work (unless you are in the same AD domain as the Exchange server, correct me if I’m wrong).

So here I am, wanting to remotely manage Exchange 2013 and having a Windows 8 client in a workgroup.

Back in the office, my Exchange-guru colleague sees me stumble and mumble and quietly sent me a mail message with a script included. He created it on the fly and was hoping my cranky face would turn into a happy face =)
He succeeded! And that only by using 11 lines of code.. What a boss!

With all credits going to my colleague Jens Giessler, I am posting his created script on my blog, hoping other people’s faces will turn into happy ones.
Replace the bold parts with your own credentials and Exchange server FQDN, and save as a .ps1 file to run it with PowerShell.

Before running the script, you also need to enable Basic Authentication on the PowerShell virtual directory, using the ECP (Servers menu, virtual directories tab).

Oh; as with all my previous and future script postings; use them at your own risk.

#Functions
Function Query-Credentials
{
$Global:Cred = Get-Credential -Credential <b>domainuser</b>
}

Function Connect-Exchange
{
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://exchangeserverfqdn/powershell/ -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession $Session
}

#Establish connection
Query-Credentials
Connect-Exchange