Cannot Access DFS Share from XP Clients, UNC is fine
I have been running DFS for a while now. There is a namespace \\XXXX\Public and underneath the folders Shared & Secure.
Up until a few days ago these were present on servers in 2 sites in London & Kent (and replicating). The Kent server was just a temp server, so I have recently added a new permanent server and effectively moved the DFS shares from the temp to the new permanent server using DFS replication. I have disabled the DFS folders on the old servers.
The trouble is whilst the 2003 terminal servers see the new DFS share fine, most of the XP clients do not. When you try and access the DFS share you get the following message:
"\\XXXX\Public\Shared is not accessible. You might not have permission to use this network resource....
Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied.
If you access the path using the true server UNC it works fine \\XXXXX\SharedDrive
I have tried using dfsutil with the following switches /pktflush, /spcflush, /purgemupcache with no success.
The results of dfsutil /pktinfo are as follows
Entry: \XXXXX\public
ShortEntry: \XXXXX\public
Expires in 0 seconds
UseCount: 1 Type:0x8081 ( REFERRAL_SVC DFS FAILBACK_ENABLED )
0:[\XXXXX\Public] State:0x119 ( ACTIVE TARGETSET )
Entry: \XXXXX\public\shared
ShortEntry: \XXXXX\public\shared
Expires in 0 seconds
UseCount: 0 Type:0x8010 ( OUTSIDE_MY_DOM FAILBACK_ENABLED )
0:[\XXXXX\SharedDrive] State:0x121 ( TARGETSET )
It may be worth adding that I have created a new DFS root on the new server and the clients can access it with no problems.
I really don't want to have to delete and recreate the dfs links if possible because the replication is tied into it and I'm worried it might break.
Any ideas would be greating appreciated.
Up until a few days ago these were present on servers in 2 sites in London & Kent (and replicating). The Kent server was just a temp server, so I have recently added a new permanent server and effectively moved the DFS shares from the temp to the new permanent server using DFS replication. I have disabled the DFS folders on the old servers.
The trouble is whilst the 2003 terminal servers see the new DFS share fine, most of the XP clients do not. When you try and access the DFS share you get the following message:
"\\XXXX\Public\Shared is not accessible. You might not have permission to use this network resource....
Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied.
If you access the path using the true server UNC it works fine \\XXXXX\SharedDrive
I have tried using dfsutil with the following switches /pktflush, /spcflush, /purgemupcache with no success.
The results of dfsutil /pktinfo are as follows
Entry: \XXXXX\public
ShortEntry: \XXXXX\public
Expires in 0 seconds
UseCount: 1 Type:0x8081 ( REFERRAL_SVC DFS FAILBACK_ENABLED )
0:[\XXXXX\Public] State:0x119 ( ACTIVE TARGETSET )
Entry: \XXXXX\public\shared
ShortEntry: \XXXXX\public\shared
Expires in 0 seconds
UseCount: 0 Type:0x8010 ( OUTSIDE_MY_DOM FAILBACK_ENABLED )
0:[\XXXXX\SharedDrive] State:0x121 ( TARGETSET )
It may be worth adding that I have created a new DFS root on the new server and the clients can access it with no problems.
I really don't want to have to delete and recreate the dfs links if possible because the replication is tied into it and I'm worried it might break.
Any ideas would be greating appreciated.
ASKER
Hi - the DFS folder share permissions were everyone - full control, so I'm not sure that's it.
I'm thinking I will need to recreate the namespace but it is a last resort as I will have to set up replication again and that has proved to be a bit shaky if there is existing data in a directory
I'm thinking I will need to recreate the namespace but it is a last resort as I will have to set up replication again and that has proved to be a bit shaky if there is existing data in a directory
Well, let's do a lookup to the namespace:
http://support.microsoft.com/kb/830578
Let's use this tool to troubleshoot the namespace connection. NBlookup troubleshoots netbios translation.
Do you have a WINS server?
http://support.microsoft.com/kb/830578
Let's use this tool to troubleshoot the namespace connection. NBlookup troubleshoots netbios translation.
Do you have a WINS server?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I would like to see if a few things may be the solution first off.
Since you can access one of the root servers, maybe your problem is more of a security component than a communications one. Do you have internet explorer enhanced security on the server and/or client. This would prevent you from running .exe,.bat, .xls, .vbs, .msi, and other operating system intrusive files. You could try to add the unc path as a trusted site in internet explorer to see if this is your issue.
Now that the security component is check and found to not be the problem, maybe we should check the permissions of the SHARE as well as the permissions of NTFS. When setting up the namespace, you will have to configure your namespace's share permissions. Those allow you access to the share. Like any other share, the share permissions allow you access to the folders and subfolders within the share from a remote location. Then, the NTFS share allows you access to the drive sectors the share resides on. With the inability to access the share, it sounds like your SHARE permissions are off, not the NTFS permissions. To redo this, you may have to recreate the namespace and edit the share permissions to full control. It's easiest to control the permissions at the NTFS level than the share level.