Archives for May 2012

I passed my TS: Windows Server 2008 R2, Server Virtualization (70-659) exam today. I have to say it  was the hardest Microsoft exam I have had to write because of the different types of exams questions that were presented. While I can’t really talk about the exam I can say that if I had to go back and do anything different during studying I would have spent even more time on High Availability and how it relates to Hyper-V as well as Remote Desktop Services (RDS).

Another thing that I plan on getting better at is Powershell. It’s amazing how much Microsoft is focusing on scripting and powershell commands. This is great and us Windows admins should get out of comfort zone and embrace scripting more as well.

I want to thank Microsoft for the training and free exam voucher. It was a nice kick in the rear end. A month to study and learn this stuff was very demanding and it was great to have my young family’s support. Thanks Delila and Micah!

From the Microsoft Exam website here is the skills being measured for this exam:

Skills Being MeasuredThis exam measures your ability to accomplish the technical tasks listed below.The percentages indicate the relative weight of each major topic area on the exam.The higher the percentage, the more questions you are likely to see on that content area on the exam.

The information after “This objective may include but is not limited to” is intended to further define or scope the objective by describing the types of skills and topics that may be tested for the objective. However, it is not an exhaustive list of skills and topics that could be included on the exam for a given skill area. You may be tested on other skills and topics related to the objective that are not explicitly listed here.

Installing and Configuring Host and Parent Settings

• Add the Hyper-V role on Windows Server 2008 R2.
• This objective may include but is not limited to: installing and configuring Hyper-V on Server Core, verifying BIOS settings (i.e. DEP), adding the Hyper-V role using Virtual Machine Manager, configuring Hyper-V Server R2, identifying hardware requirements
• Enable remote management.
• This objective may include but is not limited to: deploying Virtual Machine Manager Agent, configuring firewall rules, configuring Virtual Network Manager settings
• Configure virtual networks and VLAN security.
• This objective may include but is not limited to: configuring Media Access Control (MAC) address pools, configuring network locations, configuring VLAN tags, configuring VLAN security, configuring virtual networks
• Configure storage.
• This objective may include but is not limited to: configuring Multi Path Input Output (MPIO), executing the mpiocpl.exe command, dynamic I/O redirection, iSCSI initiator, executing the iscsicli.exe command

• Configure child resources.
• This objective may include but is not limited to: configuring disks, networks, CPU, and memory
• Configure child storage.
• This objective may include but is not limited to: configuring Dynamic VM storage, creating differencing disks, configuring pass-through disks, taking snapshots, managing GUIDs, managing logical unit numbers (LUNs), editing VHDs, copying physical disks to VHDs
• Configure child network adapters.
• This objective may include but is not limited to: creating synthetic and emulated network adapters, configuring MAC spoofing, configuring VLAN ID, configuring Jumbo frame, configuring TCP Offloading Engine (TOE)
• Create and deploy virtual machines.
• This objective may include but is not limited to: creating, cloning, deploying, and saving virtual machines using Virtual Machine Manager; creating virtual machines using Hyper-V Manager, configuring Self-Service Portal, scripting and deploying virtual machines using Windows PowerShell

Managing and Monitoring Virtual Environments

• Solve performance and resource issues.
• This objective may include but is not limited to: configuring Performance and Resource Optimization (PRO), monitoring the environment by using System Center Operations Manager 2007 R2, configuring event triggers, allocating resources by using Virtual Machine Manager, monitoring performance and diagnosing issues by using Performance Monitor or Resource Monitor
• Configure delegation of rights.
• This objective may include but is not limited to: creating user policies for Self Service Portal, creating and managing templates, managing and replicating libraries in Virtual Machine Manager
• Create roles and configure authorization rights.
• This objective may include but is not limited to: creating roles and delegating rights using Authorization Manager (AzMan), delegating rights manually
• Manage non-Hyper-V-aware virtualization hosts.
• This objective may include but is not limited to: managing ESX/VI3 VMware hosts by using Virtual Machine Manager, managing Virtual Server 2005 R2 hosts using Virtual Machine Manager

• Manage snapshots.
• This objective may include but is not limited to: taking, reverting, merging, deleting, and applying snapshots; configuring storage locations
• Manage backups.
• This objective may include but is not limited to: managing online and offline backups by using DPM, Windows Server Backup, or Volume Shadow Copy Service (VSS)
• Perform non-clustered migrations.
• This objective may include but is not limited to: performing a SAN migration of child partitions, performing a network migration of child partitions
• Configure quick and live migrations.
• This objective may include but is not limited to: configuring network and storage for clustered Hyper-V setup, enabling Cluster Shared Volumes (CSV), configuring dynamic I/0 redirection

• Perform physical-to-virtual (P2V) migration.
• This objective may include but is not limited to: configuring Virtual Machine Manager Intelligent Placement, performing online and offline migrations
• Perform virtual-to-virtual (V2V) migration.
• This objective may include but is not limited to: configuring Virtual Machine Manager Intelligent Placement, performing online and offline migrations
• Perform import/export migration.
• This objective may include but is not limited to: migrating virtual machines between Hyper-V hosts using the Export/Import feature in Hyper-V

• Configure RD session host.
• This objective may include but is not limited to: configuring session host settings, network-level authentication settings, license settings; restricting users to single remote session; allowing time zone redirection; configuring resource redirection, configuring encryption, configuring multi-monitor support
• Configure RD licensing.
• This objective may include but is not limited to: activating and deactivating Remote Desktop License Service, installing and revoking client access licenses (CALs), reporting on CAL usage
• Configure RD Connection Broker.
• This objective may include but is not limited to: installing the RD Connection Broker, configuring DNS for Connection Broker, configuring Connection Broker farms, integrating with RD Virtualization Host role service
• Configure RD Gateway.
• This objective may include but is not limited to: configuring RD Gateway, integrating RD Gateway with network access protection (NAP), configuring authentication authorization
• Configure RD Web Access.
• This objective may include but is not limited to: configuring RD Web Access, configuring authentication options (forms, single sign-on), configuring per-user RemoteApp program filtering, configuring public and private computer options

I am making a copy of this information because I can never find this KB. The original information can be found here:

Understanding Quorum Configurations in a Failover Cluster

This post contains the following sections:

• How the quorum configuration affects the cluster
• Quorum configuration choices
• Illustrations of quorum configurations
• Why quorum is necessary

For information about how to configure quorum options, see Select Quorum Options for a Failover Cluster.

How the quorum configuration affects the cluster

The quorum configuration in a failover cluster determines the number of failures that the cluster can sustain. If an additional failure occurs, the cluster must stop running. The relevant failures in this context are failures of nodes or, in some cases, of a disk witness (which contains a copy of the cluster configuration) or file share witness. It is essential that the cluster stop running if too many failures occur or if there is a problem with communication between the cluster nodes. For a more detailed explanation, see Why quorum is necessary later in this topic.

Important

In most situations, use the quorum configuration that the cluster software identifies as appropriate for your cluster. Change the quorum configuration only if you have determined that the change is appropriate for your cluster.

Note that full function of a cluster depends not just on quorum, but on the capacity of each node to support the services and applications that fail over to that node. For example, a cluster that has five nodes could still have quorum after two nodes fail, but the level of service provided by each remaining cluster node would depend on the capacity of that node to support the services and applications that failed over to it.

Quorum configuration choices

You can choose from among four possible quorum configurations:

Node Majority (recommended for clusters with an odd number of nodes)
Can sustain failures of half the nodes (rounding up) minus one. For example, a seven node cluster can sustain three node failures.

Node and Disk Majority (recommended for clusters with an even number of nodes)
Can sustain failures of half the nodes (rounding up) if the disk witness remains online. For example, a six node cluster in which the disk witness is online could sustain three node failures.

Can sustain failures of half the nodes (rounding up) minus one if the disk witness goes offline or fails. For example, a six node cluster with a failed disk witness could sustain two (3-1=2) node failures.

Node and File Share Majority (for clusters with special configurations)
Works in a similar way to Node and Disk Majority, but instead of a disk witness, this cluster uses a file share witness.

Note that if you use Node and File Share Majority, at least one of the available cluster nodes must contain a current copy of the cluster configuration before you can start the cluster. Otherwise, you must force the starting of the cluster through a particular node. For more information, see “Additional considerations” in Start or Stop the Cluster Service on a Cluster Node.

No Majority: Disk Only (not recommended)
Can sustain failures of all nodes except one (if the disk is online). However, this configuration is not recommended because the disk might be a single point of failure.

Illustrations of quorum configurations

The following illustrations show how three of the quorum configurations work. A fourth configuration is described in words, because it is similar to the Node and Disk Majority configuration illustration.

Note

In the illustrations, for all configurations other than Disk Only, notice whether a majority of the relevant elements are in communication (regardless of the number of elements). When they are, the cluster continues to function. When they are not, the cluster stops functioning.

As shown in the preceding illustration, in a cluster with the Node Majority configuration, only nodes are counted when calculating a majority.

As shown in the preceding illustration, in a cluster with the Node and Disk Majority configuration, the nodes and the disk witness are counted when calculating a majority.

Node and File Share Majority Quorum Configuration

In a cluster with the Node and File Share Majority configuration, the nodes and the file share witness are counted when calculating a majority. This is similar to the Node and Disk Majority quorum configuration shown in the previous illustration, except that the witness is a file share that all nodes in the cluster can access instead of a disk in cluster storage.

In a cluster with the Disk Only configuration, the number of nodes does not affect how quorum is achieved. The disk is the quorum. However, if communication with the disk is lost, the cluster becomes unavailable.

Why quorum is necessary

When network problems occur, they can interfere with communication between cluster nodes. A small set of nodes might be able to communicate together across a functioning part of a network but not be able to communicate with a different set of nodes in another part of the network. This can cause serious issues. In this “split” situation, at least one of the sets of nodes must stop running as a cluster.

To prevent the issues that are caused by a split in the cluster, the cluster software requires that any set of nodes running as a cluster must use a voting algorithm to determine whether, at a given time, that set has quorum. Because a given cluster has a specific set of nodes and a specific quorum configuration, the cluster will know how many “votes” constitutes a majority (that is, a quorum). If the number drops below the majority, the cluster stops running. Nodes will still listen for the presence of other nodes, in case another node appears again on the network, but the nodes will not begin to function as a cluster until the quorum exists again.

For example, in a five node cluster that is using a node majority, consider what happens if nodes 1, 2, and 3 can communicate with each other but not with nodes 4 and 5. Nodes 1, 2, and 3 constitute a majority, and they continue running as a cluster. Nodes 4 and 5, being a minority, stop running as a cluster. If node 3 loses communication with other nodes, all nodes stop running as a cluster. However, all functioning nodes will continue to listen for communication, so that when the network begins working again, the cluster can form and begin to run.