locked
Problems with connect to a share on a cluster 2008 with ip address RRS feed

 > 

  • General discussion

  • Discussion
    Sign in to vote
    0
    Sign in to vote
    Hello,

    I have built a new Cluster 2008 an copied solle Files via robocopy to the new cluster. Now I have the following problem.

    Connect via \\IP-address\share --> does not work
    Connect via \\servername\share --> does work

    Has somebody an idea what this could be?

    Cluster: 2 nodes, activ, activ

    Connect via \\ip-address\c$ --> does work

    Greetz
    QuentinT
    Wednesday, December 17, 2008 8:14 AM

All replies

  • Discussion
    Sign in to vote
    0
    Sign in to vote
    Sure.  This no longer works becasue of the changes that were made in W2K8 clusters.  We now work differently with the server service.  We now 'scope' shares in the context of a Network Name, so now when you browse using a UNC, for example \\<network_name_in _cluster\ you will see al the shares associated with that name.  In previous versions of cluster, that same output would also show all the shares on the cluster node...not anymore.  Additionally, we only scope in the context of the network name, we do not scope in the context of the IP address that the NN resource depends on.

    Impact?  Scripts or apps that use IP addresses as part of their UNC path to avoid, perhaps, the additional time it takes for DNS\WINS name resolution, will not work against W2K8 clusters.  They will have to be changed to use the NN resource.  And, OBTW, do not use CNAME records in DNS for a cluster NN, that will not work.

    Thanks.
    Chuck Timon Senior Escalation Engineer (SEE) Microsoft corporation
    Wednesday, December 17, 2008 4:38 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    Sure.  This no longer works becasue of the changes that were made in W2K8 clusters.  We now work differently with the server service.  We now 'scope' shares in the context of a Network Name, so now when you browse using a UNC, for example \\<network_name_in _cluster\ you will see al the shares associated with that name.  In previous versions of cluster, that same output would also show all the shares on the cluster node...not anymore.  Additionally, we only scope in the context of the network name, we do not scope in the context of the IP address that the NN resource depends on.

    Impact?  Scripts or apps that use IP addresses as part of their UNC path to avoid, perhaps, the additional time it takes for DNS\WINS name resolution, will not work against W2K8 clusters.  They will have to be changed to use the NN resource.  And, OBTW, do not use CNAME records in DNS for a cluster NN, that will not work.

    Thanks.
    Chuck Timon Senior Escalation Engineer (SEE) Microsoft corporation

    Is there any work around to this?  We have major issues with Xerox network scanners not working with this.

    The problem is the network scanning we have.  They are multi function
    devices that have the ability to scan to and then copy the scan to network
    shares.

    The problem is that although the devices can be configured to use dns all
    they essentially do is lookup the ip address and try to connect to it.  So
    instead of goign \\clustername\share which they should do they go
    \\clusterip\share which does not appear to work in server 2008.  When I
    browse to \\clusterip from my pc I just see teh shares on the active node
    not the cluster.

    I have confirmed this bahaviour by doing network traces between the
    printer/scanner and the active cluster node.

    This to my knowledge is different to 2003 and I need to fix it.

    Is there any solution I can put in place before I tell Xerox they need to
    rewite their firmware!
    Wednesday, November 18, 2009 1:32 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    Is there any work around to this?  We have major issues with Xerox network scanners not working with this.

    The problem is the network scanning we have.  They are multi function
    devices that have the ability to scan to and then copy the scan to network
    shares.

    The problem is that although the devices can be configured to use dns all
    they essentially do is lookup the ip address and try to connect to it.  So
    instead of goign \\clustername\share which they should do they go
    \\clusterip\share which does not appear to work in server 2008.  When I
    browse to \\clusterip from my pc I just see teh shares on the active node
    not the cluster.

    I have confirmed this bahaviour by doing network traces between the
    printer/scanner and the active cluster node.

    This to my knowledge is different to 2003 and I need to fix it.

    Is there any solution I can put in place before I tell Xerox they need to
    rewite their firmware!
    Did you ever find a solution for this problem? I am running into the same issue when trying to dump over SMB on a WorkCentre Pro 7436 to a Windows 2008 R2 cluster file share. Any help would be greatly appreciated.

    Thanks,
    Chris.


    Wednesday, January 20, 2010 12:29 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    Running into the same issue with Ricoh Copier/Scanner devices accessing network cluster shares from Windows 2K8 : \\clusterip\share --> does not work. But it used to work with Windows 2K3. What change and what would be the work around or permanent resolution for this?

    Ricoh copier/scanner does not resolve \\clustername\share and using the net-name or name resolution would not solve the issue either.

    Thank you,
    TMoe

    Wednesday, January 27, 2010 2:21 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    We have a similar issue where this Win2008 change is not allowing the previous DNS entry for DWGWEB to access the share.  My workaround is to start telling people to no longer use DWGWEB for the UNC share.  Instead they will have to use the net-name.  Possible, but annoying.  I just don't understand why the IP-address\share no longer works in Win2008.
    Sunday, May 2, 2010 8:13 PM
  • Discussion
    Sign in to vote
    1
    Sign in to vote

    Try to connect using

    \\clusterip\x$\share  or  \\clustername\x$\share

    where x$ is the default share. Works with Sharp copier\scanner

    /AB

     

    Saturday, July 17, 2010 5:24 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    Is there a registry key that will re-enable this?  We got hit by this today when we upgraded to Win2008R2 on our production servers.  Certainly there must be many others that have run up against this?
    Tuesday, October 26, 2010 10:58 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Did you get any solution? OptionalNames and DisableStrictNameChecking might be a solution but I dont know what happens if I will give both nodes the same OptionalNames with the cluster ressource name. I believe it should work because the cluster ressource IP links to the right node. Isnt it? I set up this keys during the server configuration on the first node before the cluster feature was installed to provide the old share name. Now I recognized that I can access the cluster share over IP when the first node is the cluster owner.

    Who can test? My CEO wants to use the IP address... 

    Best regards

    Christian

    Tuesday, March 15, 2011 8:17 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    Christian,

    Have you found a solution?  I'm stuck in the middle of a migration because of this.  I have an unfortunate amount of legacy apps that rely on IP addressing for the UNC paths. 

     

    Tuesday, July 5, 2011 3:06 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    I am experiencing the same thing with XEROX scanner.  the share is accessible via regular windows explorer, for MAC computer I need to put the full fqdn plus the 139 port.  but with XEROX nothing works.  Any suggestions? Thanks

     

    Friday, October 14, 2011 1:55 PM
  • Discussion
    Sign in to vote
    1
    Sign in to vote

    ok it seems this works 

    \\clusterip\x$\share 


    Wednesday, November 23, 2011 4:50 PM
  • Discussion
    Sign in to vote
    2
    Sign in to vote

    In Windows Server 2008 the way that SMB File Shares work on a cluster has changed.  Shares are now scoped to their valid UNC paths, and there is a new SHARE_INFO_503 structure for SMB shares to enable this.

    In the past, a user could access a clustered file share through any path...  be it the local node name or any Network Name resource currently only on that node.  This was great, until you failed over the share to another node in the cluster... and the invalid UNC path share mappings were all broken.  This was a major source of support calls, and a feature request of customers to address this and not publish shares via invalid paths.  See this blog for more information on the new share scoping functionality:
    http://blogs.technet.com/b/askcore/archive/2009/01/09/file-share-scoping-in-windows-server-2008-failover-clusters.aspx

    Because the shares are bound to the name, they are only accessible via the name.  This has had some some other side effects.  Such as connecting to the shares directly via IP Address of the machine or with a DNS alias via a CNAME record.  In general, it is not recommended to connect to shares via IP or CNAME because of the security trade-off.  Namely, that you cannot do Kerberos authentication.  So this flexibility, comes at the cost of reduced security.

    Not all of the issues discussed in this thread, are addressed by connecting via IP.  For example some versions of the Mac OS do not understand the new 503 structure.  Connecting via IP really isn't the magical answer there.

    Hardcoding applications to the IP is not necessarily the best deployment model.  For example, it locks in the server location to the subnet, and you are unable to relocate it.  So there are many reasons why this should not be done.  But I understand that sometimes people made poor decisions in the past, and there is a legacy app that you are unable to change.

    So as a piece of good news, we have heard the customer feedback in this thread and responded.  In "Windows Server 8" we have enhanced this functionality and enabled connecting to clustered shares via CNAMES and IP's, through SMB alias support.  This is available in the Developers Preview today, and I encourage you to try it out and give us feedback if it meets your needs.  One disclaimer... you still will not use Kerberos via IP or CNAME, so in general it is recommended to stay with connecting to the cluster name.

    Thanks!
    Elden 

    Thursday, November 24, 2011 4:44 AM
  • Discussion
    Sign in to vote
    1
    Sign in to vote
     


    While I'm happy to hear Microsoft is trying to be responsive and has addressed this issue in Server 2012, that's not good enough! We can't turn on a dime and put up new cluster infrastructure (which is not generally available yet for production use). Any chance can this code be made available as a hotfix for Windows Server 2008 R2? Please?

    We have seen this issue with Ricoh MFP today, the morning after migration of data from Server 2003 clusters to Server 2008 R2 clusters.

    I see 4 potential solutions.

    1. Microsoft offer a hotfix for Server 2008 R2.

    2. Ricoh address customer requirements like ours to enable the Ricoh MFP to work with Windows Server 2008 R2 cluster network shares. (Probably would require that the Ricoh MFP use SMB v2 to access network shares?) We are asking Ricoh to respond.

    3. Mentioned in the article is a work-around using the server hidden administrative share. This was configured this morning, is working for us temporarily, but it is a serious security backdoor flaw because an administrative password is hardcoded in the Ricoh MFP setup. (In short the temporary work-around was to update the Ricoh MFP configuration from "\\172.17.123.456\Share" to "\\172.17.123.456\W$\Share" and also add the Ricoh MFP account to local Administrator's group on all nodes of the Win2k8r2 cluster. This is a security flaw far worse than the original "defect" Microsoft claims to be fixing in Windows Server 2008 R2 Cluster!   

    4. Rewrite our custom backend off our cluster share and use a Windows 2003 network share. This is a redevelopment effort and possibly procedural changes for end-users. It is also puts our data onto a non-High Availability solution since it would not be clustered. Thanks Microsoft.

    I'll post to this forum if Ricoh comes through on item #2. I am not holding my breath.  I would love it if Elden Christensen has happier news from Microsoft for us and provide solution #1. I am guessing we'll wind up having to do the effort of #4, long-term. Meanwhile, we're limping along with #3 to keep production from breaking.

    Thanks to all who have contributed to this forum thread.

    Sincerely,
    George Perkins

    Monday, August 13, 2012 6:37 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    Using option #2 now able to write from Ricoh MFP to our Win2k8r2 cluster. We are not using an IP address in the UNC path. 

    To get this to work there were a couple of simple settings changes on the Ricoh MFP. Also updated the Ricoh MFP firmware which may have helped matters. Our Ricoh MFP is writing scanned and faxed files to \\server\share (where the "server" is a Cluster Group and the "share" is a Cluster Fileshare Resource).

    Kudos to Ricoh, their support was very responsive.

    Monday, August 27, 2012 9:30 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    Also wondering if there will be a fix for this for 2008 clusters as we are experiencing this problem with scanners.
    Friday, September 21, 2012 5:12 PM
  • Discussion
    Sign in to vote
    2
    Sign in to vote

    **For people having issues scanning to clusters**

    In Server 2008 R2 HA clusters cant be accessed via IP. We had this issue in our environment where we couldnt workflow scan to our cluster with any Xerox products. Xerox by default resolves hostnames to IP which in turn makes it unable to access HA clusters.

    This setting can be turned off on newer Xerox machines (7545, 7535 etc) with a hidden feature. Access the feature by typing in:                                                      

    h ttp://YourXeroxIP/diagnostics/resolveHostname.php (resolveHostname.php is case sensitive). Uncheck "Enabled" on the resolve hostname option. Your xerox machines can now access HA clusters by name. If your machine does not have this hidden feature, contact your Xerox support.

    **important** ... When setting up scanning to HA clusters through the Xerox you must use the FQDN. For instance, hostname will be HAClusterName.contoso.com (replace contoso with your domain).

    Regards,

    Glenn

    Tuesday, March 5, 2013 5:54 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    I can confirm Glenn's solution worked for us..

    Cheers Richard

    Tuesday, May 14, 2013 3:33 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    **For people having issues scanning to clusters**

    In Server 2008 R2 HA clusters cant be accessed via IP. We had this issue in our environment where we couldnt workflow scan to our cluster with any Xerox products. Xerox by default resolves hostnames to IP which in turn makes it unable to access HA clusters.

    This setting can be turned off on newer Xerox machines (7545, 7535 etc) with a hidden feature. Access the feature by typing in:                                                      

    h ttp://YourXeroxIP/diagnostics/resolveHostname.php (resolveHostname.php is case sensitive). Uncheck "Enabled" on the resolve hostname option. Your xerox machines can now access HA clusters by name. If your machine does not have this hidden feature, contact your Xerox support.

    **important** ... When setting up scanning to HA clusters through the Xerox you must use the FQDN. For instance, hostname will be HAClusterName.contoso.com (replace contoso with your domain).

    Regards,

    Glenn


    Works great, thanks!
    Tuesday, August 13, 2013 7:39 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    For us, this is a really bad solution.  Does not appear that we can use the Administrative shares without making the scanning account an Administrator on the cluster.  We have other critical resources on the cluster, and that is really poor security.  If there is any other way around this, please let me know.  For now I am planning on us moving all of our scanning(hundreds) off the the cluster when business slows down.  If the cluster was accessable by an IP address to a non-admin resouce, it would be a lot better.

    Dave


    • Edited by DaveBryan37 Friday, December 19, 2014 8:25 PM
    Friday, December 19, 2014 8:25 PM