“Combining Exchange 2010 high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers, is now supported.”

But I don’t believe it’s quite as straightforward as that statement makes it sound.

To quote the ‘Best Practices for Virtualizing Exchange Server 2010 with Windows Server® 2008 R2 Hyper V™’ whitepaper:

“Exchange server virtual machines, including Exchange Mailbox virtual machines that are part of a Database Availability Group (DAG), can be combined with host-based failover clustering and migration technology as long as the virtual machines are configured such that they will not save and restore state on disk when moved or taken offline. All failover activity must result in a cold start when the virtual machine is activated on the target node. All planned migration must either result in shut down and a cold start or an online migration that utilizes a technology such as Hyper-V live migration.”

In a nutshell it means that something like Hyper-V ‘Live Migration’ is supported but something like Hyper-V ‘Quick Migration’ is not, since ‘Quick Migration’ saves, moves and restores the virtual machine; ‘Live Migration’ does not. To quote the ‘Windows Server 2008 R2 Hyper-V™ Live Migration’ whitepaper:

“Live migration and Quick Migration both move running VMs from one Hyper-V™ physical computer to another, the primary difference is that Quick Migration saves, moves and restores a VM which results in some downtime. The live migration process uses a different mechanism for moving the running VM to the new physical computer. This process will be explained in greater detail in the Live Migration Architecture section of this document. Below is a summary of the live migration process:

1.  All VM memory pages are transferred from the source Hyper-V™ physical host to the destination Hyper-V™ physical host. While this is occurring, any VM modifications to its memory pages are tracked.
2.  ™Pages that were modified while step 1 was occurring are transferred to the destination physical computer.
3.  The storage handle for the VM’s VHD files are moved to the destination physical computer.
4.  The destination VM is brought online on the destination Hyper-V™ server.

Live migration produces significantly less downtime for the VM being migrated.”

Since VMware VMotion technology is broadly similar in terms of application as ‘Hyper-V Live Migration’ that too would be supported.

This change in the support stance is significant for two reasons in my opinion. Firstly it will mean more Exchange deployments on Hyper-V where previously the choice appeared to be virtualise Exchange Server on a VMWare solution or don’t virtualise at all; and secondly it means a lot more choice for deploying Exchange 2010, which I think is a good thing.

What it doesn’t mean is that virtualising Exchange will always make sense. The most successful Exchange Server 2010 solutions in the enterprise that I have been involved in have not as yet featured Exchange running on hardware virtualisation software since it has not made sense to do so.. However the case for virtualising Exchange Server specifically is increasingly compelling.

As always check vendor participation in the  Windows Server Virtualization Validation Program and continue to keep up with the ‘Exchange 2010 System Requirements’ specific to ‘Hardware Virtualization’.

“You have unique experiences, skills and passions—and we believe you can bring them all to Microsoft for a rich, rewarding career and lifestyle that will surprise you with its breadth and potential. Just imagine the excitement and satisfaction of what you can do, where you can go, and the difference you can make with the resources of Microsoft behind you.

Here at Microsoft U.K., we help change the way the world lives, works and plays. Explore our job opportunities and, if you like what you see, consider joining us—our people are some of the most extraordinary people you’ll ever meet.”

I’ve been at Microsoft for about 6 years now and can’t recommend it highly enough.

Please let me know if you are interested..

(..or take a look at Careers at Microsoft)

Exchange Online – the first place to start (includes some useful screenshots)…

Office 365 Beta BLOG and WIKI…  An RSS feed off the blog is a useful source of Office 365 news. (Take a look at the Microsoft Online Services Team Blog also…)

If you’re interested in the coexistence between Exchange Server ‘On-Premise’ and Office 365 then use the Exchange Server Deployment Assistant – this is updated for Exchange 2003, Office 365 coexistence only at the moment – Exchange Server 2007 and 2010 to follow… (You need some Exchange 2010 infrastructure on-premise for coexistence with Exchange Server 2003 and Office 365 by the way.)

Check out the ‘Infrastructure Planning and Design Guides for Microsoft Online Services’; in particular the ‘IPD Guide for Exchange Online – Evaluating Software-Plus-Services’ (The download includes a spreadsheet, presentation and document - go for the Word doc. to start with.)

The ‘Office 365 Beta Service Descriptions’ are available on the Microsoft Download Center.  I would definitely recommend a read of these. They’re not a difficult read and even if you skim read them they’ll give you more than a feel for what you can and can’t do with Office 365 before you get there.

A couple of articles it is worth reading:

• Office 365 Beta: Completing provisioning of archive in the cloud from your on-premises Exchange 2010 server
• Office 365 Sneak Peak Content and Code event on the 8th February..

A couple of non-Microsoft resources: ‘Office365Answers.com’ and ‘Office365Rocks’

Fond of a tweet? @office365 @msonline (@me) (#office365 #exchangeonline #bpos #cloud)

Or even Facebook

Can also recommend a couple of books about cloud computing in general which I’ve enjoyed:

• ‘Management Strategies for the Cloud Revolution: How Cloud Computing Is Transforming Business and Why You Can't Afford to Be Left Behind’ by Charles Babcock
• ‘The Big Switch: Rewiring the World from "Edison" to "Google"’ by Nicholas Carr

And if you happen to live in the UK and need to purchase some stationery…!@?!

Have a look on TechNet for more information about Jetstress 2010…

Using Cmdlet Extension Agents to cause automatic events to occur in Exchange 2010 - life just got simpler! by Pat Richard.

Cmdlet Extension Agents are something that will be very new to most Exchange administrators but is something that could make life a lot easier..

To quote TechNet:

“Cmdlet extension agents are components in Microsoft Exchange Server 2010 called by Exchange 2010 cmdlets when the cmdlets run. As the name implies, cmdlet extension agents extend the capabilities of the cmdlets that call them by assisting in processing data or performing additional actions based on the requirements of the cmdlet.”

In other words use extension agents to trigger a cmdlet to run every time another cmdlet runs; either before or after it..

At one of my customers these will be used to enable single item recovery for every mailbox each time a new one is created using the new-mailbox cmdlet.  The only other way to do it is to schedule a regular task to set this for every mailbox where it is not currently set – still works but not nearly so neat.

Have a look here for information about Cmdlet Extension Agents on TechNet:

Understanding Cmdlet Extension Agents

As some of you will be aware they recently held a LiveMeeting on the subject, however this will be a chance to dive deeper into the new changes and to bring questions along to discuss in person.
The event is being sponsored by Redgate Software. Alongside their software products they run the Simple-Talk sysadmin website which Jaap Wesselius and Nathan Winters have both written for. Jaap will be the guest speaker for the evening and between Jaap and Nathan, they will cover both the new elements of Exchange Server 2010 SP1 and also answer questions about the process of upgrading from previous Exchange versions.

For more information and to sign up please use the following link: https://www.mmmug.co.uk/3-15th_July_2010_-_Exchange_2010_SP1_26_Migration

Also have a look at the MMMUG Facebook site...

Well it’s not a problem to get it to work.  It just means you’re likely compelled to introduce a layer of complexity into the solution.

To illustrate this I’ll use an example where there are 4 nodes of a single DAG with 3 copies of every mailbox database and to make it simple I’ll be deploying a single database on each disk (JBOD), using volume mount points.

What’s the problem?

On every DAG member you create a directory structure; c:\data\mbxdb01, c:\data\mbxdb02…up to c:\data\mbxdb06 (since you have 6 disks).  You deploy mbxdb01on nodes 1, 2 and 3 since but now on node 4 you have c:\data\mbxdb01 which you can’t use because each database has to have the same path – so c:\data\mbxdb01 can only be used by mbxdb01.

At first glance you have 2 choices – don’t use the disk (!$@&?!) or change your design to 4 copies (equally unpalatable).

One Solution

..but there is a way around this with this particular example and that is to deploy a directory structure which is different on each node.

The above design works very nicely I think (..and of course the creation of this directory structure can be scripted using diskpart for example) but it does mean that you need to be careful when you lose a disk for example or when you are rebuilding a failed server (again both scriptable with the right skills).  Or perhaps more importantly when you decide to add a node to the design at some point in the future.  It could mean quite a lot of rejigging and downtime – the worst case might be changing the directory structure across all servers in the DAG.  (…ouch?!)

Managing a large DAG is easy?

I’m of the opinion that one of the areas of Exchange Server 2010 which needs time and effort to get right is managing large DAG’s with swarms of databases housing multitudes of big mailboxes.  You’re going to have to get good at scripting to make things run smoothly.  Scripts like the Exchange 2010 Database Redundancy Check Script will make or break a big deployment and should prevent a beautiful design descending into chaos.  ..and the more straightforward the design the more straightforward its management will be in most cases.

So 3 into 4 can go  …but proceed with caution.

First – work out if the loss is permanent.  If it’s not it might be worth waiting until the data centre is back – that way you can probably avoid the risk of split brain since you can shutdown the remaining DAG members and wait for a managed recovery.  If it is permanent then you have to do a bit of work – nothing that is going to take you too long but it’s not as simple as running a couple of PowerShell commandlets; and you have to consider what happens if you cannot manage the recovery of the lost DAG members – it is likely that you will have to do a full seed as opposed to an incremental reseed as at a minimum there is likely to be divergence which the store may not be able to recover from.  The steps that worked for me in our test rig are as follows:

• Bring the cluster online - “net start clussvc /forcequorum”
• Evict the lost cluster nodes (I used cluster manager)
• Update the DAG membership by removing the failed servers - “Remove-DatabaseAvailabilityGroupServer –id <DAG> -mailboxserver <server> -configurationonly>”
• Create a new Witness Directory - “Set-DatabaseAvailabilityGroup –id <DAG> -witnesserver <server>”
• Reboot the remaining DAG members (might get away with restarting the cluster service and\or the information store and mounting the database)
• Databases should mount automatically according to AutoDatabaseMountDial

“DAC mode has been extended to support DAGs that have all members deployed in a single Active Directory site, including Active Directory sites that have been extended to multiple locations.”

(https://blogs.technet.com/scottschnoll/archive/2010/04/10/new-high-availability-features-in-exchange-2010-sp1.aspx)

Take notice of the note that accompanies the blog though:

“But a quick note: everything in this post is based on pre-release software and preliminary information that is subject to change.  These are things we are working on or are about to work on.  The feature names, behaviors and descriptions used below might not be the final names, behaviors and descriptions.  The behvaiors described may or may not make it into the final shipping version of SP1 or a future version of the product.  Standard disclaimers apply regarding pre-Beta software and content.”

The other idea that was given to me to avoid split brain and the need for a full seed in the event of failback is to mark the databases not to mount at startup.   This means that where you cannot manage the startup of the lost DAG members the databases will not mount. Unfortunately this prevents automated failover where there is data loss but where the lost logs are within AutoDatabaseMountDial since the replicas will not be activated and get left in a failed state.  Nice idea but didn’t work in my testing..

Happy Christmas to all…

Also a quick note to congratulate all those who passed the qualification this time around – and good luck to those who still have a few more bits to do…

“Microsoft Certified Master : Exchange 2007 - A survivors guide…”

..and if you want more information about the program see the MCM blog and TechNet:

The Master Blog

Microsoft Certified Master Program