Verify automount settings for Failover Clustering

 

This post is part of the Failover Cluster Checklist series.

 What to do

For Windows 2008 automount should be disabled, for 2012 it should be enabled by default. If you have drive letter assignment problems, try disabling automount.

You can check and change this setting from an elevated command prompt:

  • Diskpart
  • Automount
  • Automount disable/enable

Sample from Windows 2012:

clip_image001

Why

Automount can cause several issues in failover clusters, mostly related to drive letter and mount point mappings. The issues are more prevalent when using iSCSI storage due to the way iSCSI volumes are mounted. If you have FC storage where the LUN IDs are different on the cluster nodes, similar problems may occur. FC LUN IDs are configured in the SAN interface, not on the server.

  • I have experienced issues on Win 2008 and 2008R2 where the drive letter mappings of cluster disks change on failover if automount is enabled. I have seen volumes that are configured with a mount point suddenly being assigned a driveletter instead on failover, thus resulting in a failed resource. Cluster services may fail or behave erratically, as there are settings and configuration items who are bound to drive letters.
  • When you add storage to a cluster, automount could assign a driveletter to the new volume that is already in use on another node. This may lie dormant for quite some time, until you try to fail over the two drives to the same node. Failover cluster validation will spot this error.

I have yet to experience any automount related issues on Windows 2012, thus the reccomendation to keep automount enabled. The default setting is enabled, both on Win2008 and Win2012.

Author: DizzyBadger

SQL Server DBA, Cluster expert, Principal Analyst

3 thoughts on “Verify automount settings for Failover Clustering”

  1. Disabling Automount does pose any problem in case of failover cluster such as volumes doesnt get mounted on the target server in case of failover or else this wont posses any problem as disk signatures for all disks in cluster are known all the cluster nodes?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.