Note: Read is the default share permission in 2003 and later. Subinacl /share \\2003-02\root /grant=everyone=r Or it could be altered remotely with the following. To fix this we could connect to the server and add the permissions. In small environments, connecting to the server and examining the share permissions is an acceptable method, however in large environments this can prove cumbersome. This can be observed locally usingĬomparing this to the same output of 2003-01, we see the problem: The root cause of the issue was actually incorrect share permissions on the “root” share of 2003-02. This will cause differencing results for each time the client requests a referral. DFS referrals are retuned in a random order for servers in the site of the client. This behavior accounts for the entries in the referral cache for paths to each root (i.e. , the DFS service on 2003-dc1 then responded with a new DFS root referral for the path \\2003-dc1\root. When connecting to a root DFS share, the DFS service returns referrals for all of the participants on the root target set. When connecting to the path \\2003-02\root, we were instead accessing the root share on 2003-01, as detailed in the trace: The DFS service returned the following (note that ‘TargetPath: Index:1’ is not 2003-02 but another server): To illustrate this, I have several screenshots of the referral network traffic. Looking further in the network trace, we noticed that we received a new referral when we attempted to connect to 2003-02 server directly. I would have actually expected this to get an “access is denied” too. When we attempt to do this, we received more unexpected results: Normal troubleshooting would be to attempt to connect to the share \\2003-02\root. This was represented in the pktinfo as follows:Īt this point we attempted to create a connection to the first server returned in the referral. We were returned four targets for the root. The first thing we attempted was to request a DFS referral for \\\root , we took a trace to see what we can find. Then we ran theĬommands again that returned different results: If we could reach each target, why were getting random “access is denied” when attempting to get a directory listing of the root?Ĭommand to purge the referral cache thus forcing a request for new referrals. I would have expected that we would get access denied to all of the targets. This was to test the access to the DFS root and connectivity to the root shares.Īt this point, each target appeared accessible. When we began troubleshooting the issue, we started to look at the output of “ When using the “DFS Management” MMC from 2003 R2, The display is different, but the behavior is the same: When the MMC was checked later (or the user logged off and then back on) the results changed: In this picture, it appears that three of the four root targets are inaccessible. Using the "Distributed File System" MMC to check the status of the root would provide differing results at different times. For reference, I have included a picture of what it should look like when all is ok. Investigating the issue, it was noticed that the "Distributed File System" MMC would change as time passed. After a random period of time, users could access the DFS root, would later lose access, and users who did not work before would start working. Prior to calling Microsoft support, the customer was able to successfully connect to the NETLOGON and SYSVOL share of the domain without issue (\\\sysvol and \\\netlogon) Rebooting the client machine or having the client logoff would at times alleviate the problem. A DFS root has one of the following formats: \\ The DFS root must reside on an NTFS volume. A root maps to one or more root targets, each of which corresponds to a shared folder on a separate server. The root is often used to refer to the namespace as a whole. When first presented with this issue, I was asked to help determine the nature of users getting prompted to connect to a DFS root. While the root of this is issue is easy to remediate, it can be difficult to find the offending servers. Today we are going to discuss some confusing behavior that I’ve observed regarding inconsistent DFS access. Hi, this is Bobby from the Microsoft Directory Services support team. First published on TechNet on Jun 04, 2009
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |