Note that the preferred owners list just places the preferred nodes at the start of the node list. It doesn't mean the resource can't run on a non-preferred node. For example, imagine you have four nodes: A,B,C, and D. Nodes A and C are made preferred, so our node list would look like A,C,B,D for the resource group. If the resource is currently running on C and it fails, it moves to the next node in the list so it would move to B and not A, since B is next on the list. This is explained in detail at http://support.microsoft.com/kb/299631. The next item of configuration is Possible Owners, which lets you configure which nodes in a cluster can host a resource. If a node is not a Possible Owner, then the resource group containing the resource will try all the Possible Owners first and only go to a non possible owner as a last resort; even then it will not come online. Possible Owners are set on a resource, such as a disk or name, and not a resource group. By default all nodes are set as Possible Owners, as the figure shows.
There is another factor. There may be resource groups that should not run on the same nodes as another resource group. A property, AntiAffinityClassNames, can be defined on a resource group. In the event of a failover, a node that has no resource groups that have any of the same AntiAffinityClassNames as the resource group being moved is chosen ahead of any other nodes, even those defined as preferred. Essentially, this lets us keep resource groups separated on different nodes. Let's say you virtualize two domain controllers (DCs). You wouldn't want them running on the same node, so you could set the AntiAffinityClassNames for each resource group hosting a DC VM to "DCVM," which would ensure the two VMs would not run on the same nodes unless there were no other options. To set AntiAffinityClassNames, use the command below: