Unable to add file shares in a Windows 2012 R2 Failover Cluster
My name is Chinmoy Joshi and I am a Support Escalation Engineer with the Windows Core team. I’m writing today to share information regarding an issue which I came across with multiple customers recently.
Consider a two node 2012 R2 Failover Cluster using shared disks to host a File Server role. To add shares to the File Server role, select the role and right-mouse click on it to get the Add File Share option. The Add File Share option is also available along the far right column. Upon doing this, you may receive an error “There were errors retrieving file shares” or the Add Share wizard gets stuck with, “Unable to retrieve all data needed to run the wizard”.
When starting the add share wizard, it is going to try and enumerate all current shares on the node and across the Cluster. There can be multiple reasons why Failover Cluster Manager would throw these errors. We will be covering two of the known scenarios that can cause this.
Scenario 1:
Domain Users/Admins can be part of nested groups; meaning, they are a in a group that is part of another group. As part of the security, there is a token header being passed and that header can be bloated. Bloated headers can occur when the user/admin is part of nested group or may be migrated from some domain to a new domain carrying older SID’s. In our case, the domain user was a part of large number of active directory groups. There can be three ways to resolve this:
A) Reduce the number of active directory groups the user is member of,
B) Clean up the SID History, or
C) Modify the Https service registry with the following registry values:
Caution: Please backup the registry before modifying in case you need to revert the changes.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
"MaxFieldLength"=dword:0000fffe
"MaxRequestBytes"=dword:00010000
Note that these keys may not be there, so they will need to be created.
Here, HTTPS protocol uses Kerberos for authentication and the token header generated was too large throwing an error. When this is the case, you will see the following event:
Log Name: Microsoft-Windows-FileServices-ServerManager-EventProvider/Operational
Source: Microsoft-Windows-FileServices-ServerManager-EventProvider
Event ID: 0
Level: Error
Description: Exception: Caught exception Microsoft.Management.Infrastructure.CimException: The WinRM client received an HTTP bad request status (400), but the remote service did not include any other information about the cause of the failure.
at Microsoft.Management.Infrastructure.Internal.Operations.CimSyncEnumeratorBase`1.MoveNext()
at Microsoft.FileServer.Management.Plugin.Services.FSCimSession.PerformQuery(String cimNamespace, String queryString)
at Microsoft.FileServer.Management.Plugin.Services.ClusterEnumerator.RetrieveClusterConnections(ComputerName serverName, ClusterMemberTypes memberTypeToQuery)
References:
Problems with Kerberos authentication when a user belongs to many groups
Scenario 2:
The second most popular reason for not able to get the file shares created is the WinRM policy being enabled for IPv4filter. When this is set, you will see this in the wizard:
To see if it is set on the Cluster nodes, go into the Local Security Policy from the Administrative Tools or Server Manager. Once there, follow down the path to:
If you go into the Group Policy Editor, it would be located at:
Local Computer Policy
Computer Configuration
Administrative Templates
Windows Components
Windows Remote Management (WinRM)
WinRM Service
Allow remote server management through WinRM
If it is enabled, open that policy up and check to see if the box for IPv6 has an asterisks in it.
You will run into this error if only IPv4 is selected. So to resolve this, you would need to either disable the policy or also add an asterisks for IPv6. For the change to take effect, you will need to reboot the system. After the reboot, go back into Group Policy Editor to see if it has been reverted back. If it has, you will need to check your domain policies and have this done there.
Hope this helps you save time in resolving the issue, Good Luck!!
Chinmoy Joshi
Support Escalation Engineer
Comments
- Anonymous
September 14, 2015
My name is Chinmoy Joshi and I am a Support Escalation Engineer with the Windows Core team. I’m