Using Multiple Client Access Points (CAP) in a Windows Server 2008 (R2) Failover Cluster
Quite a while back I wrote a blog on a new functionality in Windows Server 2008 Failover Clusters called ‘file share scoping’ (https://blogs.technet.com/b/askcore/archive/2009/01/09/file-share-scoping-in-windows-server-2008-failover-clusters.aspx). I was informed recently that our Networking Support Team refers to this blog frequently when working with customers who are migrating to Windows Server 2008 Failover Clusters and discover that CNAME (Canonical Names) records in DNS, that had been in-place to support their Windows Server 2003 File Server clusters, no longer work with Windows Server 2008 Failover Clusters. Users keep asking if there is a way to disable this functionality or if it can be changed by adding a registry key or something. At this time, there is no disabling this behavior and our Product Team has been made aware of the feedback we have been receiving on this. No official plans have been announced with respect to making any changes in future releases of the Operating System.
While we wait and see what the future holds, I have been asked to write a short blog on how users can better work within the constraints of this functionality. In a File Server Resource Group you typically have a Client Access Point (CAP), a File Server Resource, a Physical Disk resource and some Shared Folders (Figure 1).
Figure 1
Suppose, in a Windows Server 2003 cluster environment, there were several CNAME records created in DNS that pointed to the same File Server Cluster so users from various organizations within a company could access their data files. For example, suppose we had CNAME records for OPS-FS1, Academics-FS1 and Executive-FS1. After completing a migration to a Windows Server 2008 R2 File Server cluster, these CNAME records no longer work and end users can no longer access their data. How can we fix that?
To remedy the situation, create additional CAPs in the File Server Resource group that contains the shared folders that contain the data the users need to access. To do this will require stepping outside of the normal wizard-based process that was used to create the original highly available File Server resource group and instead use the procedures described in KB 947050.
Start by selecting the File Server resource group and in the Right-hand Actions pane select Add a resource (Figure 2).
Figure 2
From the list of available resources, select Client Access Point (Figure 3).
Figure 3
Provide the requested information and complete the wizard. Do this for all required Client Access Points. When completed, bring all the CAPs Online. Here is my result (Figure 4).
Figure 4
At this point, decide which shared folders need to be available to users when each Client Access Point connection is made. Then, create the shared folders in the correct context. Figure 5 shows the selections available when executing the Add shared folder action in the Actions pane.
Figure 5
As an example, in my 2-Node cluster, all folders shown in Figure 1 were shared in the context of CONTOSO-FS1. After adding the additional Client Access Points that were needed, a decision was made that the Academics share was needed in the Academics-FS1 context, the Executive and Archive folders were needed in the Executive-FS1 context and finally the Operations folder was needed in the OPS-FS1 context. When sharing folders in multiple contexts, the display can start getting a little cluttered (Figure 6).
Figure 6
When all File Server resources are Online, all shared folders associated with those resources are displayed. If a multiple File Server resources are associated with the same shared folder, multiple entries are displayed (Figure 6). This is in addition to the administrative share for the associated physical disk resource.
To help clarify some of the confusion, modify the Description on the Sharing tab for the Property page of the shared folder to reflect its associated File Server resource (Figure 7).
Figure 7
This provides some organization to what can be a cluttered display (Figure 8).
Figure 8
Additional administrative overhead is incurred here as well because multiple Access Control List (ACLs) entries must be maintained on the same set of folders. Depending on the tools used to migrate the data to a windows Server 2008 Failover cluster, that information could already be present on the storage and not be an issue.
I hope this helps provide a solution for you organization. See you next time.
Chuck Timon
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support
Comments
- Anonymous
August 26, 2010
The comment has been removed - Anonymous
September 02, 2010
The comment has been removed - Anonymous
September 03, 2010
We are using this for our recently deployed File Server Cluster. I have one question though... how do I enumerate who is connecting to each share? We have two shares which are pointing at one folder. The GUI indicates how many sessions there are for each share but I can't figure out how to tell which clients/users are connected to each share. - Anonymous
December 28, 2010
We have migrated our WS03 File Cluster to a 2008 Failover cluster. This has in effect broken our SCCM server since it can no longer go to \fsc$ which was a virtual server in a resource group on WS03.Is it possible to have the underlying administrative shares (C$, ADMIN$) show up under the virtual servers? - Anonymous
February 14, 2011
I have a question are we able to use the same IP addresses for the new CAPs we're creating? As IPs use is already near its limits for us. - Anonymous
April 01, 2011
Due to CAPs we had to recreate every share on every virtual name (a tedious process but it only took the creation of 150-200 extra shares by hand) since we couldn't verify, apart from login scripts, that the user wasn't connecting on another virtual name. We had also instituted within IT the knowledge of the workings of virtual names and our 2003->08 R2 conversion created the above issue as drives could be mapped as CAP1Share, CAP2Share, etc. and not be in the login script. Now we're trying to limit the number of CAPs and duplicate share names across CAPs and are trying to measure it. Using Power Shell we've tried to enumerate various Win32 WMI classes to trace usage. The closest we've gotten is a gwmi -class Win32_ServerConnection; however, it looks like server connections via this class get duplicated across every virtual name (err, CAP). How can I manage access, or cleanup, to these when I can't verify that there's some script a developer left off of a legacy CAP name? I've tried various other WMI classes like ServerSession using the CAP name as an argument, LoggedonUser, etc. and none of it provides an answer to the question-What user is logged onto what share on what CAP?! Any help please? Yes, I know I can see it in the GUI but I need to be able to capture this data long-term for analysis given the scenarios above. - Anonymous
April 27, 2011
The comment has been removed - Anonymous
August 23, 2011
You say there is no way to disable this functionality, but Symantec seem to have created a work around: www.symantec.com/.../TECH144432 - Anonymous
August 31, 2011
Should just fix the cname/cap issue if creating so many calls. So much for the customer. - Anonymous
October 19, 2011
Is there also a way of doing this for SQL Server, I need to share files and host a SQL Server on the server using aliasses and for SQL Server it doesn't seem to work.RegardsAxel - Anonymous
April 14, 2014
Sure, you can use Client Access Points, but what if Your CNAME record included more than 15 characters? Then you are out of look. Try creating a Client Access Point that har more characters than 15 in its name, you won't be able to do so.