Unable to access Windows Server 2008 file shares through the UNC path to a virtual server name or virtual server IP Address.

Problem

  • Unable to access Windows Server 2008 file shares on local storage through the UNC path to the to the virtual server name created by the Storage Foundation for Windows High Availability (SFW-HA) 5.1 SP1 or 5.1 SP2 or 6.0 Lanman resource
  • Unable to access Windows Server 2008 administrative shares through the UNC path to the virtual server name created by the SFW-HA 5.1 SP1 or 5.1 SP2 or 6.0 Lanman resource
  • Unable to access SFW-HA 5.1 SP1 or 5.1 SP2 or 6.0 file shares that are created on shared storage through the UNC path to the physical server name
  • Unable to access SFW-HA 5.1 SP1 or 5.1 SP2 or 6.0 file shares that are created on shared storage through the UNC path to the IP address that is used for the virtual server name created by the SFW-HA 5.1 or 5.1 SP2 or 6.0 Lanman resource
  • Unable to access SFW-HA 5.1 SP1 or 5.1 SP2 or 6.0 file shares that are created on shared storage through the UNC path to the IP address that is used by the physical server (Administrative IP address) 

Cause

File shares on Windows Server 2003 are accessible through the UNC path to the physical server name, the virtual name created by the SFW-HA Lanman resource, the physical server IP address (Administrative IP address) or the virtual server IP address.

In Windows Server 2008 Failover Clustering and SFW-HA 5.1 SP1 or SP2 or 6.0 clusters, file share 'scoping' was introduced which changes the way the Cluster Service interoperates with the Server Service on a Cluster node. Because of this new functionality, end users must rethink file share access when those shares are hosted in a Failover Cluster. Accessing file shares in a Windows Server 2008 must be through the Network Name resource (virtual server name) which is part of a cluster Client Access Point (CAP). Methods that previously used IP addresses or DNS CNAME records no longer work.

Solution

Symantec has created an enhancement to the Lanman and FileShare resources that creates file shares without scoping which allows access to the file shares that are created on the physical node and by SFW-HA using the previous methods; UNC path to the physical node name, virtual server name, physical node IP address (Administrative IP address) or the virtual server name IP address. This enhancement also allows access to the administrative shares on the physical node through the UNC path to the virtual server name for the physical node that has the SFW-HA 5.1 SP1 or 5.1 SP2 or 6.0 service group online.

Please be aware that installation of this will be changing the default restriction set by Microsoft for Windows Server 2008. Any risk associated with the removal of this restriction should be considered by Cluster Administrator.

To obtain the private fix, contact Symantec Support and reference this TechNote during the call. A support representative will be available to assist in troubleshooting this issue. If it is determined that the private fix addresses the problem, the support representative will further assist in obtaining the private fix. For a complete list of Symantec Enterprise Technical Support contact numbers, go to http://www.symantec.com/business/support/index.jsp.

Note: This fix specifically addresses the problem identified above. It has not been fully tested and should be applied in a test environment before placing into production. If the systems are not critically impaired, it is recommended to delay the installation of this private fix until the next scheduled maintenance release. Before applying this private fix, systems may be required to be upgraded to the latest code base. The support representative will help in determining the best course of action.

 

Workaround:

This is a workaround to disable FileShare scooping without installing the patch.  Either the patch or the workaround is a supported resolution for this issue.  However, running the FileShare wizard and modifying the FileShare service group will remove this workaround and it will need to be reapplied.

  1. Offline the FileShare resource(s).
  2. Clear out the LanmanResName attribute from the FileShare resource(s).
  3. Online the FileShare resource(s).
  4. Test access to the share(s) as needed.

Terms of use for this information are found in Legal Notices.

Search

Survey

Did this article answer your question or resolve your issue?

No
Yes

Did this article save you the trouble of contacting technical support?

No
Yes

How can we make this article more helpful?

Email Address (Optional)