MICROSOFT 70-412: OBJECTIVE 1.3 Manage Failover Clustering Roles

MCSA 70-412: 1.3 Configure Failover Clustering

It’s Friday, and there isn’t a terribly large amount of content for this portion of Failover Clusters. This post may be the smallest of the series, but time will tell!


Table of Contents:
1) Configure role-specific settings, including continuously available shares
2) Configure virtual machine (VM) monitoring
3) Configure failover and preference settings
4) Configure guest clustering



1) Configure role-specific settings

A number of critical Windows roles are cluster aware and can take advantage of the high availability that a failover cluster provides.
The list of cluster-aware Windows components is as follows:
DFS Namespace server
DHCP Server
Distributed Transaction Coordinator
File Server
Hyper-V Replica Broker
iSNS server
Message Queuing
Print Server
RDC Broker
Virtual Machine
WINS Server


In the right Action pane of the Failover Cluster manager, select ‘Configure Role’:
Microsoft 70-412 Certification Exam Blueprint Walkthrough Study Failover Cluster

You can select the server role/feature that you want to cluster in the High Availability Wizard:
Microsoft 70-412 Certification Exam Blueprint Walkthrough Study Failover Cluster
Special note on clustered File Servers.
If you selected that option, you would see this screen next:
70-412 1.3.3

I’ve seen stuff on Scale-Out vs General File Server in every practice test. Here’s what you need to know:

File Server for General Use: The default for a reason, this is usually what you think of when you imagine a file server. The servers that present this clustered role act as an active-passive cluster, so only one server is providing the file shares and the remainder are there for high availability.

Scale out File Server for Application Data: Not intended for user use, this role is useful for IIS configuration and web site information, Hyper-V virtual disk stores, SQL Server databases, and the Virtual Machine Manager. Can’t handle a lot of metadata edits, hence the recommendation to not be used for users. Presents shares as active-active, aggregates node bandwidth and has a read cache. They ONLY use Clustered Shared Volumes for storage. Can’t use Branch Cache, DFS or File Resource Manager.

Continuously Available File Shares provide transparent filesharing failover ability for file shares. CAFS is available for either scale out or general fileserver.

This is an excellent article on the set up and requirements for CAFS:

Back to Table of Contents

2) Configure virtual machine (VM) monitoring

Windows Server 2012 introducing Hyper-V VM monitoring for the first time, but it has some setup requirements:

  • Both the Hyper-V host and its guest VM must be running Windows Server 2012 or Windows Server 2012 R2.
  • The guest VM must belong to a domain that trusts the host’s domain.
  • The Failover Clustering feature must be installed on the Hyper-V host. The guest VM must also be configured as a role in a failover cluster on the Hyper-V host.
  • The administrator connecting to the guest through Failover Cluster Manager must be a member of the local administrators group on that guest.
  • All of the windows firewall settings for ‘Virtual Machine Monitoring’ need to be enabled on the VM.

You can configure VM monitoring in the Failover Cluster Manager interface by right-clicking the virtual machine and selecting ‘Configure Monitoring’. You then select which services to monitor:
70-412 1.3.4

You will only see services listed that run on their own process e.g. SQL, Exchange. The IIS and Print Spooler services are exempt from this rule. You can setup monitoring for any NT service using Windows PowerShell using the
Add-ClusterVMMonitoredItem cmdlet – with no restrictions:
Add-ClusterVMMonitoredItem –VirtualMachine TestVM -Service spooler

My service failed and wasn’t restarted- what now?

1)      Event ID 1250 is logged on the host
2)      The virtual machine status in Failover Cluster Manager will indicate that the virtual machine is in an “Application Critical” state.
3)      Recovery action is taken on the virtual machine in “Application Critical” state
a.       The virtual machine is first restarted on the same node
b.      On the second failure, the virtual machine restarted and failed over to another node in the cluster.

Back to Table of Contents

3) Configure failover and preference settings

I’ve seen Role Startup priority and preferred owner mentioned on practice tests so things to know:
Role Startup: Four priorities- High, Medium, Low or No Auto. In the event of a node failure, roles are started on the next node in the order set- all Highs start before Medium roles start. The default is Medium. No Auto is a bit different: The role will be failed over last, but not started.

Preferred Owner: The role will prefer to run on the preferred owner. If that owner is unavailable, the role will migrate to the next node. If the preferred node comes back online and the role is not running on a preferred node, it will begin to fail back to the preferred host

Possible Owner: Just like it sounds- Possible owners of a role are nodes that can run the clustered role. A role cannot run on a server that is not listed as a possible owner.

Back to Table of Contents

4) Configure guest clustering

I can’t describe guest clustering better than Technet did, so study this page:

Back to Table of Contents


One comment

Comments are closed.