Asked by:
Problems with connect to a share on a cluster 2008 with ip address

-
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- Changed type Elden ChristensenMicrosoft employee, Owner Thursday, November 24, 2011 4:45 AM
- Changed type Elden ChristensenMicrosoft employee, Owner Thursday, November 24, 2011 4:45 AM Discussion
General discussion
All replies
-
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 -
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! -
Is there any work around to this? We have major issues with Xerox network scanners not working with this.
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.
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!
Thanks,
Chris. -
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 -
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.
-
Try to connect using
\\clusterip\x$\share or \\clustername\x$\share
where x$ is the default share. Works with Sharp copier\scanner
/AB
-
-
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
-
-
-
-
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.aspxBecause 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 -
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.
-
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.
-
-
**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
-
-
**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! -
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