Windows 2008 R2 cluster device not connecting to a cluster share
-
Friday, February 24, 2012 4:59 PM
Can you explain the difference behind the scene, when a connection is made in a Windows 2003 cluster versus the same connection in a 2008 cluster using either an IP address or a host name? I understand that the CAP doesn't like IP addresses anymore. I need to understand why a device can map correctly to cluster resource IP and share name in a 2003 cluster, and can also map to a server name and share in 2008, but not to a resource name and share in a 2008 cluster when DNS is working properly. The device allows for either an IP address or host name to make the connection, but does not use a typical path such as \\resourcename\share\subfolder. Instead it uses host name in one field , then another field for the share name, and yet another field for the path to the sub folder. Could it be the case that because the way 2008 cluster treats shares, since the actual sub folder is not shared out, I need to actually share out the subfolder. Although workstations and other devices can see the same subfolder just fine through the cluster.
On a 2008 server that is not a cluster the format below works:
servername
share name
subfolder
On the 2008 cluster I have tried without success:
virtual resourcename
sharename
subfolder
I understand the I might be able to use the physical name of the server that is one cluster node with a driver letter $, so this avoids the CAP, but we need failover to work and providing Admin level rights isn't an option.
All Replies
-
Friday, February 24, 2012 8:11 PMModerator
I've re-read this post a few times and I'm just not following what you are asking. Cluster has NEVER allowed you to connect to a share via \\resourcename\share unless the resourcename just happens to be named the same as the "Network Name" resource value for the group. So I'm not exactly sure what you are asking.
The answer to your question is likely related to the file share scoping behavior in Windows 2008 clustering. There is an excellent article that describes the differences between 2003 cluster file shares versus 2008 cluster fileservers found here:
If you have additional questions after reading the above article, please let us know.
- Proposed As Answer by JohnTonerMVP, Moderator Friday, March 02, 2012 8:26 PM
-
Friday, February 24, 2012 11:19 PM
Hi John,
Yes, sorry my network name(s) do match the name of each resource group, so users can map to \\resource01\share, that's how I set up my 2003 cluster. I recently did a migration using the 2008 migration wizard. Which brought over the same resource groups and shares, and we reused the SAN attached LUNs. Workstations had no issues and could connect as before. We had one department that is using a Xerox scanner that mapped to the IP address that matched the network name of the old cluster and one resource group (that worked fine in a 2003 cluster). Now however, they can no longer scan document to the same share as before on the new 2008 cluster.
I changed the scanner setting to a host name rather than an IP a couple of days ago but still no luck. I pointed the scanner to a 2008 server that is not clustered and created a share. That works fine so it's not SMB, but when I use the host name (network name) of the virtual resource group which is in DNS, we get an error and the scanner cannot connect to the same share as before when using the virtual network name. We also have some Canon scanners that use a UNC path and that works fine. The Xerox doesn't let you use a UNC path the same way and perhaps that is the root of the issue. You have to use the fields present in the web management console of the Xerox scanner. It does not accept a true UNC path, you can put in just the network name = "resource01" but not the UNC path directly = \\resource01\share\folder (see below).
Xerox Syntax
field 1 >Host name =resource01
field 2 >Share name = department share
field 3>Sub folder = ecopy\user (where the files need to go)
So may be the UNC path is being interpreted differently and it's not working. After reading other posts to your referenced article, I think the issue is that the Xerox printer is treating the host name entry as a "Cname" and not a UNC path. I understand the \\IP Address\I$\share\folder may work, the only question is what rights are needed, we can't give the copier equivalent Administrator rights to work through the admin $ share rather than the cluster share. Microsoft should include a registry fix that allows some devices to use an IP address when needed. It's a serious disadvantage in an enterprise environment to not allow IP addresses that match the network name to access a cluster share. I'll do a couple more tests with the scanner next week, but my guess is we will need to have a separate share on another non-cluster server for this to work like it did on our 2003 file cluster.
- Edited by Westcoasthd Friday, February 24, 2012 11:50 PM
- Edited by Westcoasthd Saturday, February 25, 2012 12:12 AM
- Edited by Westcoasthd Saturday, February 25, 2012 1:30 AM
- Edited by Westcoasthd Saturday, February 25, 2012 1:33 AM
- Edited by Westcoasthd Saturday, February 25, 2012 1:35 AM
-
Saturday, February 25, 2012 3:11 AMModerator
Ok, thought that might be what you were getting at. I've certainly read several posts regarding this issue. I can't speak to the necessary security access levels needed for the share, but I believe some people have worked around this issue by adding a record the local hosts file on the servers.
You might also see if the following KB helps:
http://support.microsoft.com/kb/979602
- Proposed As Answer by JohnTonerMVP, Moderator Friday, March 02, 2012 8:26 PM
.png)
