Microsoft Enterprise Platforms Support: Windows Server Core Team
EPS Team Blogs
Product Team Blogs
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.
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.
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.
At this point, a pop-up will appear warning that a removal of this resource could affect applications using this resource.
If you click ‘Yes’, both resources get removed.
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.
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.
Then I can right-click the resource and click ‘Remove from GroupName’
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’
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.
Now here’s where it gets fun. After I attempted to remove the mount point, ALL of my resources disappear from the group. ??????
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.
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.
Now we have all our resources back and we can follow the correct process of taking the mount point disk offline BEFORE removing it.
Jeff Hughes Senior Support Escalation Engineer Microsoft Enterprise Platforms Support
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:"
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.
I experienced this as well and used the command line to move everything back to the correct group, same as Alex M.
My question is this: Is this by design or is this a known bug in MS Clustering?
In my case, I also received the below error when trying to move a mounted disk (with no dependencies) to available storage from SQL Group:
The operation has failed
Failure removing storage resource
Details: Error code 0x800700b7
Cannot create a file when that file already exists
Thank You so much. Save my day.
Nice article, but the images are not displaying. Any chance of getting them restored?