SQL 2012 cluster installation fails with disk resource can’t be moved error

When I was working with one of the customers on SQL server 2012 failover cluster installation, we came across a problem because of which cluster installations fails by throwing the below error

“The resource 'disk p' could not be movedfrom cluster group 'Available Storage' to cluster group 'SQL Server (MSSQLSERVER)' “

By looking at the error message we can infer that it’s something related to the inability of the installer to move clustered disk resource to the group/role created by the SQL installer in this case SQL Server (MSSQLSERVER).

Some of the errors in your detail.txt looks like below

01) 2013-12-02 09:20:57 Slp: The resource ‘Disk P’ could not be moved from cluster group 'Available Storage' to cluster group 'SQL Server (MSSQLSERVER)'. Error: There was a failure to call cluster code from a provider. Exception message: Generic failure . Status code: 183. Description: Cannot create a file when that file already exists.
(01) 2013-12-02 09:20:57 Slp: .
(01) 2013-12-02 09:20:57 Slp: HResult : 0x86d80035
(01) 2013-12-02 09:20:57 Slp: FacilityCode : 1752 (6d8)
(01) 2013-12-02 09:20:57 Slp: ErrorCode : 53 (0035)
(01) 2013-12-02 09:20:57 Slp: Data:
(01) 2013-12-02 09:20:57 Slp: resourceName = Disk P
(01) 2013-12-02 09:20:57 Slp: groupName1 = Available Storage
(01) 2013-12-02 09:20:57 Slp: groupName2 = SQL Server (MSSQLSERVER)
(01) 2013-12-02 09:20:57 Slp: errorMessage = There was a failure to call cluster code from a provider. Exception message: Generic failure. Status code: 183. Description: Cannot create a file when that file already exists.
.(01) 2013-12-02 09:20:57 Slp: WatsonData = Microsoft.SqlServer.Configuration.Cluster.ChangeClusterGroupOperationException@53

(01) 2013-12-02 09:20:57 Slp: SQL.Setup.FailureCategory = ConfigurationFailure

(01) 2013-12-02 09:20:57 Slp: WatsonConfigActionData = INSTALL@CONFIGNONRC@SQL_ENGINE_CORE_INST

(01) 2013-12-02 09:20:57 Slp: WatsonExceptionFeatureIdsActionData = System.String[]

(01) 2013-12-02 09:20:57 Slp: Stack:

(01) 2013-12-02 09:20:57 Slp: at Microsoft.SqlServer.Configuration.Cluster.ClusterResource.ChangeResourceGroup(ClusterGroup g)

(01) 2013-12-02 09:20:57 Slp: at Microsoft.SqlServer.Configuration.ClusterConfiguration.ClusterDiskPrivateConfigObject.MoveClusterDisksToGroup(ClusterDiskPublicConfigObject diskConfig)

(01) 2013-12-02 09:20:57 Slp: at Microsoft.SqlServer.Configuration.ClusterConfiguration.ClusterDiskPrivateConfigObject.Install(ConfigActionTiming timing, Dictionary`2 actionData, PublicConfigurationBase spcb)

(01) 2013-12-02 09:20:57 Slp: at Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.ExecuteAction(String actionId)

(01) 2013-12-02 09:20:57 Slp: at Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.Execute(String actionId, TextWriter errorStream)

(01) 2013-12-02 09:20:57 Slp: Inner exception type: Microsoft.SqlServer.Configuration.Cluster.ClusterProviderDetailedException

(01) 2013-12-02 09:20:57 Slp: Message:

(01) 2013-12-02 09:20:57 Slp: There was a failure to call cluster code from a provider. Exception message: Generic failure . Status code: 183. Description: Cannot create a file when that file already exists.

(01) 2013-12-02 09:20:57 Slp: .

(01) 2013-12-02 09:20:57 Slp: HResult : 0x86d70002

(01) 2013-12-02 09:20:57 Slp: FacilityCode : 1751 (6d7)

(01) 2013-12-02 09:20:57 Slp: ErrorCode : 2 (0002)

(01) 2013-12-02 09:20:57 Slp: Data:

(01) 2013-12-02 09:20:57 Slp: ExceptionMessage = Generic failure

(01) 2013-12-02 09:20:57 Slp: StatusCode = 183

(01) 2013-12-02 09:20:57 Slp: Description = Cannot create a file when that file already exists.

(01) 2013-12-02 09:20:57 Slp: WatsonData = Microsoft.SqlServer.Configuration.Cluster.ClusterProviderDetailedException@2

(01) 2013-12-02 09:20:57 Slp: Stack:

(01) 2013-12-02 09:20:57 Slp: at Microsoft.SqlServer.Configuration.Cluster.WmiClusterResource.ChangeResourceGroup(String group)

(01) 2013-12-02 09:20:57 Slp: at Microsoft.SqlServer.Configuration.Cluster.ClusterResource.ChangeResourceGroup(ClusterGroup g)

(01) 2013-12-02 09:20:57 Slp: Inner exception type: System.Management.ManagementException

(01) 2013-12-02 09:20:57 Slp: Message:

(01) 2013-12-02 09:20:57 Slp: Generic failure

(01) 2013-12-02 09:20:57 Slp: HResult : 0x80131501

(01) 2013-12-02 09:20:57 Slp: Data:

(01) 2013-12-02 09:20:57 Slp: WmiErrorCode = Failed

(01) 2013-12-02 09:20:57 Slp: WatsonData = Failed@183

(01) 2013-12-02 09:20:57 Slp: Description = Cannot create a file when that file already exists.

(01) 2013-12-02 09:20:57 Slp: ErrorType = 1

(01) 2013-12-02 09:20:57 Slp: Operation = ExecMethod

(01) 2013-12-02 09:20:57 Slp: ParameterInfo = MSCluster_Resource.Name="Disk S"

(01) 2013-12-02 09:20:57 Slp: ProviderName = WinMgmt

(01) 2013-12-02 09:20:57 Slp: StatusCode = 183

(01) 2013-12-02 09:20:57 Slp: Stack:

(01) 2013-12-02 09:20:57 Slp: at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)

(01) 2013-12-02 09:20:57 Slp: at System.Management.ManagementObject.InvokeMethod(String methodName, ManagementBaseObject inParameters, InvokeMethodOptions options)

(01) 2013-12-02 09:20:57 Slp: at Microsoft.SqlServer.Configuration.WMIInterop.Resource.MoveToNewGroup(String Group)

(01) 2013-12-02 09:20:57 Slp: at Microsoft.SqlServer.Configuration.Cluster.WmiClusterResource.ChangeResourceGroup(String group)

(01) 2013-12-02 09:20:57 Slp: Watson Bucket 2

Original Parameter Values

So we cancelled the installer and tried to move the disk resource (disk p) to the SQL role manually, through the failover cluster manager console. When I do a right click on the resource (disk) and click on the option move, the pop-up just goes away as if it has successfully moved the resource without throwing any errors but when I go and check in the resources tab, the disk which I tried to move still shows up under the ‘Available Storage’ instead of showing under the SQL resource group.

As I’m not a clustering expert, I didn’t do much research on this behaviour. But I observed this phenomenon when we use a disk resource that's having a LUN mounted as the base mount point and other LUNs mounted as folders inside it and dependencies setup among the mounted folders and the base mount point. The issue might be because of SQL installer tries to establish the dependencies at the install time, again, but as the dependencies are already there it fails to set them up (Again it’s based upon an assumption but not substantiated with any proofs).

So the workaround was,

1. End the setup

2. Go to the failover cluster manager

3. Create a role– Just click on the roles (left pane), and click “create empty role” on the right pane

4. A new role will be created with a name like “New Role”. Rename it to SQL Server (MSSQLSERVER) or whatever instance name you want

clip_image002

5. Move the disks using the command Move-ClusterResource "<DISK NAME>" "SQL Server (<SQL INSTANCE NAME>)" – MAKE SURE YOU LAUNCH POWERSHELL AS ADMINISTRATOR

Ref: https://technet.microsoft.com/en-us/library/ee461049.aspx

6. Launch the setup for the failover cluster installation and in the cluster resource group section select the pre-created role in the step 3 and continue with the setup (refer to the screen shot below)

clip_image004

As we already moved the resource to the new role installer will skip the disk movement action and setup will be completed successfully.

Another workaround using which i was able to move the installation forward is,

1. End the setup
2. Go to Control Panel/Programs and uninstall the database engine ONLY. Leave any other SQL Server installed components intact
3. Open the cluster Manager and remove the Virtual Server (You can find it under the resources section of the role created by SQL installer), but leave the rest of the SQL Server resource group intact
4. Move the disks using the command Move-ClusterResource "<DISK NAME>" "SQL Server (<SQL INSTANCE NAME>)" – MAKE SURE YOU LAUNCH POWERSHELL AS ADMINISTRATOR
5. Begin the SQL cluster install again, specifying only the database engine. The installer will find and use the resource group and rebuild the virtual server.

The issue is not occurring in every environment. But from what I noticed, it's occurring when we select disk resource that's having a LUN as the base mount point, point and other LUNs mounted as folders

As always, please feel free to pass your comments/feedback.

Thanks,

Chandra