So this is an interesting topic… Server virtualization technologies have become so simple and efficient for most organizations.. Using the advanced technologies to provide high availability like ( Hyper-V Live and Quick migration or VMWare VMotion ) had make things easier to keep your VMs HA and retain your SLA. Although that using Clustering technologies have some recommendations based on the used technology.. MS Exchange team already published recommendations for running Exchange in the Virtualization Environments.
Part of it was “We recommend using the built-in Exchange Server high availability solutions for virtualized Exchange servers instead of hypervisor-provided clustering or portability solutions (such as Hyper-V’s quick migration feature). The features found in Exchange Server (in particular, cluster continuous replication (CCR)) provide greater benefits than those found in hypervisor solutions that move virtual machines between physical root machines.
We do not recommend using hypervisor-based virtual machine migration (such as Hyper-V’s quick migration) for virtualized Exchange servers. In a virtual machine migration configuration, an unscheduled outage can result in data loss. In a CCR environment, this type of data loss is largely mitigated by a feature called transport dumpster. The transport dumpster takes advantage of the redundancy in the environment to reclaim some of the data affected by the failover.”
So what about the rest of technologies like File Server clusters or DHCP. What if you want to implement DHCP and File Server Clusters ( Guest Clustering ) over Hyper-V hosts Cluster ( Cluster over Cluster ) ?
is that supported ? Do we have any limitations or well known problem with that ?
It takes some search and some support from Microsoft and hereunder the answer
This would be a combination of guest clustering and host clustering. This scenario would be working as long as you pass the cluster validation report.
Here are some tips for combing guest and host clustering for your information.
• Affinity – It is recommended that the nodes of a guest cluster should reside on different hosts to achieve the highest levels of availability. If a host were to crash, having VM’s associated with the same guest cluster distributed across multiple hosts will enable applications to recover faster. To accomplish this, configure the cluster group property AntiAffinityClassName. The host cluster will attempt to keep VM’s with a consistent string value (such as the VM name) off the same host. See this KB for additional details: http://support.microsoft.com/kb/296799
• Heartbeat Thresholds – It may be necessary to increase the cluster heartbeat thresholds of a guest cluster when a mobile guest VM node is being moved to a new host, through a process such as live migration. During the migration of the VM it will be temporarily unavailable for a brief period of time which cluster health detection may detect, increasing the thresholds will mitigate clustering assuming the node is down and incorrectly taking recovery actions. This can be accomplished by increasing the SameSubnetThreshold and SameSubnetDelay cluster common properties. See this document for additional details: http://technet.microsoft.com/en-us/library/dd197562(WS.10).aspx
So you can provide more redundancy for your VMs by providing a combination of host and guest clustering and get rid of your down time.
Some useful links
Hyper-V Guest Clustering Step-by-Step Guide
Failover Clustering & NLB Documents and Resources
Hyper-V: Using Hyper-V and Failover Clustering
This one was new for me, We are working on an Exchange 2007 implementation which serve remote users. During the testing phase we discovered that when users change their password using the OWA they will be able to logon using their OLD and NEW password. !!!!
after some googling we had nothing. MS newsgroups helped us to figure this out.
This behavior is by design. We can change the password in AD, and it will work immediately, but there will be a 15 minutes delay before OWA changing this password. Which means that during this 15 minutes period, we can log on OWA by using both old password and new password.
For the detailed information of this topic, we can refer to this article:
Old password still works after you change it through Outlook Web Access
There is also a method provided by KB267568 to change this default interval.