Failover Clustering and Network Load Balancing Team Blog
Starting with Windows Server 2008, SMB file shares on a Failover Cluster are scoped so that they are only accessible by valid UNC paths associated with the network name they are bound to. See this blog for more information:http://blogs.technet.com/b/askcore/archive/2009/01/09/file-share-scoping-in-windows-server-2008-failover-clusters.aspx
File Share Scoping delivered improved functionality that solved a number of issues, but introduced some side effects. Namely that you could no longer connect to SMB shares on a Failover Cluster by the IP address or in some scenarios you may wish to connect by a name other than the name associated with the cluster Network Name resource. For example, using DNS CNAME records to alias server names.
Now with Windows Server 2012 there is greater flexibility in connecting to clustered SMB file shares, where you can connect with the associated IP address and define aliases for the clustered shares to be available with. This can be helpful when dealing with applications that are hardcoded to specific names or directly to IP addresses.
Cluster Network Name resources have a dependency on one or more IP Address resources. Aliases will be automatically created in the cluster so that connecting using one of the IP Addresses will associate it with the network name that depends on it. You will be able to connect specifying the IP address with no additional configuration steps in the following format:\\10.10.10.10\Share
Note: File based storage with the new Windows Server 2012 Scale-out File Server for Application Data feature does not support connecting via IP address, as Scale-Out File Server does not use cluster IP Address resources with those types of configurations. For more information on Scale-Out File Server, see this document.
It is now possible to configure scoped SMB shares on a Clustered File Server to listen for aliases with Windows Server 2012. This is a two-step process involving both DNS and Failover Cluster configuration. The following steps outline how to configure an alias with an example name of “AliasName” for the Network Name resource called “MyClusterName” that is part of a highly available File Server role.
1. On the DNS server configure a CNAME record for AliasName. See this KB article for details: http://support.microsoft.com/kb/168322
Alternatively, provide some other name resolution mechanism that allows the client to resolve AliasName
2. On the Cluster open an elevated Windows PowerShell® prompt
3. View the currently configured aliases on the MyClusterName Network Name resource:Get-ClusterResource "MyClusterName" | Get-ClusterParameter Aliases
4. Add a new alias to the MyClusterName Network Name resource with the name of “AliasName”, type the following:Get-ClusterResource "MyClusterName" | Set-ClusterParameter Aliases AliasName
Note: For the setting to take effect it requires recycling (taking Offline then Online) the cluster Network Name resource. The new alias will now appear for the Network Name resource.
5. Connect to a share by specifying the alias \\AliasName\Share
Connecting to an SMB share by IP address, or an alias, on a clustered or stand-alone server does not support Kerberos authentication. Connections will be negotiated with NTLM. While connecting with aliases does bring flexibility, the security trade-offs should be taken into consideration.
Multiple aliases can also be configured for an individual Network Name resource. This can be configured by typing the following:Get-ClusterResource "MyClusterName" | Set-ClusterParameter Aliases "Alias1,Alias2"
Thanks!Elden ChristensenPrincipal Program Manager LeadClustering & High-AvailabilityMicrosoft
If a DNS A Record was used rather than a CNAME record, would the SMB alias negotiate using Kerberos rather than falling back to NTLM?
Great article. Helped out a lot.
One problem I am experiencing is with XP and Server 2003 R2 clients. They cannot connect to this 2012 cluster name or alias. I can only connect by IP or by using the node name that currently owns the cluster.
Windows 7 and 8 clients work fine.
We cannot get power shell to take multiple alias names. A single alias name works fine but we get a command parsing error when using multiple alias names (spaces only, commas only, comma followed by space, semicolons separating alias names). Any thoughts?
Is it possible to use the LanmanResName property on Windows 2008 R2 to disable scoping?
To answer Fred's question - I was scratching my head on that one too. Try putting the aliases within quotes, such as:
Get-ClusterResource "MyClusterName" | Set-ClusterParameter Aliases "Alias1,Alias2"
That worked for me.
But I have a question/problem about this.
When the clustered file server behind a NAT Router,
the client cann‘t connect to the file share through the cluster IP address.
But client can use UNC paths to connect Clustered SMB Share.
How can I fix it?
Does anyone know if that will work even with smb v1 version?
I tried to add alias names to CAP.
Get-ClusterResource "MyClusterName" | Set-ClusterParameter Aliases "15charactername,17characternameXX"
It seems to accept names longer than 15 characters too, which is great. We've had Win2003 clusters over 10 years and we're using FQDN names (CNAME or A record) when we're accessing the clustered shares. I'd like to upgrade to Win2012 cluster, because it supports aliasnames so we could keep the old naming convention which is tied to hundreds of applications.
First three work OK, but with the fourth I got "Network name not found"
I tried to access admin shares on the cluster with the above names and all of these work fine.
Sounds like a bug to me. Using FQDN's has been the recommended way as long as I remember.
Its not true that Kerberos will not work. If you properly set the SPN's for the alias clients will negotiate Kerberos to connect to the alias name.
I have verified this with Wireshark traces, and have also verified this by using the BCP utility with SQL. I can BCP a file into SQL from an aliased file server cluster with no issues. We verified Kerberos is used in the SQL session.
Forgot to mention, a DNS A record has to be used for it to be able to negotiate Kerberos.
can you explain exactly which SPN's should be add to let kerberos work?
This is how we added the SPN records:
setspn -A HOST/<alias shortname> <Cluster CAP account name>
setspn -A HOST/<alias fqdn> <Cluster CAP account name>
sorry to reply so late, but I need one clarification:
if I am not wrong, setspn requires an AD object as target, have you created AD object for alias before adding SPN record?
If yes, what type, Computer object?
Thank you John! I too verified via a network capture that Kerberos was indeed being used. I tested both without the SPN's and with, and could see the use of Kerberos only after the SPN was in place as John stated. Without the SPN's, you will see "KDC_ERR_S_PRINCIPAL_UNKNOWN" in the packet capture and it falls back to NTLM.