Removing a Mount Point Disk from a Cluster Group

Hello everyone. Today’s post is going to cover the steps needed to follow should you ever have to remove a ‘Physical Disk’ resource from a clustered service or application where that disk is configured as a mount point. Removing a disk from a group may be needed if the application no longer requires the storage and there’s a need to utilize the disk in some other group or decommission it entirely.

First, I wanted to talk a little about dependencies and their function. Resource dependencies are created between one or more resources in a cluster group in order to determine the order in which resources in the group are taken online/offline. Take for instance a SQL Server resource that’s dependent on the ‘Physical Disk’ resources where SQL’s data is stored. A dependency should be established so that the SQL Server resource is dependent on the disk resource. This dependency will make sure the disk comes online first, and then SQL Server. Same thing when taking those things offline, except in reverse. The SQL Server resource will come offline before the disk comes offline. Obviously, we would not want to have SQL Server attempt to start until all the disks it was using was online first.

Once resources in a cluster group are linked with dependencies, you have to be careful when deleting resources out of a group. If you don’t remove dependencies properly, you may end up inadvertently removing other resources as well.

In this example, I have two resources in a cluster group, Resource A and Resource B. I establish dependencies between them so that Resource B is dependent on Resource B.

clip_image001

This means that when the group is brought online, Resource B will not be brought online until Resource A is online.

Here is what the dependency report looks like.

clip_image002

Now that these two resources are linked, you have to be careful when deleting these resources. If I were to delete Resource A from the group without first removing the dependency, BOTH resources will get removed.

clip_image003

At this point, a pop-up will appear warning that a removal of this resource could affect applications using this resource.

clip_image004

If you click ‘Yes’, both resources get removed.

clip_image005

Lesson learned. If the resource you are deleting is dependent on any other resources, remove the dependency first.

Now, we get to the main point of this post. The above process is fine for deleting resources from a cluster group unless the resource you are deleting is configured as a “Physical Disk’ resource, and it a mount point disk. The process differs slightly and you must follow this process or you could find yourself unintentionally moving every resource in the group into ‘Available Storage’.

First, lets cover proper way to remove a mount point disk from a cluster group. In this example, I have a plain File Server group with a Network Name, IP Address, File Server, and three disks. A root disk (Disk X:) and two mount points using folders on the root of X: called X:\MountPointA and X:\MountPointB.

clip_image006

Since I don’t have any shares located on X:\MountPointB, I want to remove that disk so I can use it in some other application. The FIRST thing I need to do is take the resource offline.

clip_image007

Then I can right-click the resource and click ‘Remove from GroupName’

clip_image008

When you remove a ‘Physical Disk’ resource from a cluster group, it doesn’t actually remove the cluster resource altogether, it moves the disk resource into the ‘Available Storage’ group.  This is so that you can reallocate the resource to another group if needed.

As you can see, the resource now shows in ‘Available Storage’

clip_image009

At this point, you can remove the mount point configuration, or change it to a lettered drive so you can use for some other application.

Now let’s go over what can happen if you don’t take the mount point offline before removing it. The main reason in going over this is to show you how to recover so that there’s no adverse impact to the Cluster.

In this example, I am removing the same resource from the File Server group following the same process above WITHOUT taking it offline first. First, I verified there were no dependencies on the ‘DiskX:\MountPointB’ resource.

clip_image010

Now here’s where it gets fun. After I attempted to remove the mount point, ALL of my resources disappear from the group. ??????

clip_image011

Time to panic? No, all is not lost. What happened is that because we had a mount point configured, and a mount point is not usable unless there’s a root disk, ALL of the resources moved to ‘Available Storage’ because the rest of the resources DO have dependencies.

It may appear all of the resources disappeared. Because in the UI, we only show ‘Physical Disk’ resources, if any other resources get put in that group, they don’t show up in the UI. However, if we run a command line to display all resources and their groups, we can see that the resources are still there.

clip_image012

To get the resources back into the right group, just move the disks back to the original File Server group. Right click the disk, More actions, and select Move this resource to another service or application. The same dependency tree will cause the resources to move back.

clip_image013

Now we have all our resources back and we can follow the correct process of taking the mount point disk offline BEFORE removing it.

Cheers!

Jeff Hughes
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Comments

  • Anonymous
    January 01, 2003
    I think there is a typo at the end of the third paragraph.  It says "I establish dependencies between them so that Resource B is dependent on Resource B" and I think that it should say  " I establish dependencies between them so that Resource B is dependent on Resource A."By the way, great post as always.
  • Anonymous
    January 01, 2003
    @dj
    we are aware of the issues with the images and is a problem through out the TechNet blog sites. Our internal people are working on it, but no eta.
  • Anonymous
    January 15, 2013
    Great Post. I was confronted with the same issue.All the resources [IP Address, Network Name. SQL Server] were moved to Available Storage. In my case, the resources couldn't be moved via GUI.The solution was to move the resources via cluster.exe. "cluster res "Resource Name" /moveto:"
  • Anonymous
    November 18, 2013
    The comment has been removed
  • Anonymous
    January 31, 2014
    Thank You so much. Save my day.
  • Anonymous
    February 18, 2014
    Nice article, but the images are not displaying. Any chance of getting them restored?
  • Anonymous
    August 12, 2014
    We encountered this exact issue on a SQL Server 2008R2 failover cluster instance on Win2k8 and this article was a lifesaver. We were able to bring the disks back into the group through the GUI but only after using the FailoverClusters PowerShell cmdlets to offline every resource associated with the group that was now in Available Storage.

    For reference, the PowerShell cmdlets to get the

    import-failoverclusters
    get-clustergroup "available storage" | get-clusterresource

    Use Stop-ClusterResource to offline each resource as needed.

    Great post - thank you so much for sharing John!!
  • Anonymous
    November 23, 2014
    Saved my a** today~ I saw all my disk disappear from sql.
    Added it all back in. Then found this post to do it the right way.
  • Anonymous
    August 31, 2016
    I've this exact behavior in my two-nodes file server cluster... Except that I don't have any mount points! I've not found any other dependencies. Any guess? Thanks!
    • Anonymous
      September 07, 2017
      (just found this one year later... So I'll update)Dependencies Report doesn't report all dependencies, as I'd some Storage Reports depending on the disk I wanted to remove, but they were not reported. So be sure to check Dependencies Report AND jobs on Storage Reports.
  • Anonymous
    March 24, 2017
    I'm having a similar issue on Windows 2012 R2 cluster, where I added a disk to an existing cluster resource.The disk had not drive letter assigned yet.When removing the disk from the cluster resources, it removed all resources as well.however the disk itself has no dependencies neither is anything dependent on this resource ?As a workaround you can indeed put the resource offline first.But when adding all the resources again to their original resource, this disk is added automatically as well.It seems to be glued to other resources for some reason.The issue occurs when you mount a disk under a mountpoint root which is already present in the cluster, but you do not have any dependencies defined at the cluster level.Adding the disk to the cluster will work, but if you remove it from the cluster it will take away all resources.