DanMcDermott
Guest
|
Posted:
Thu Nov 18, 2004 3:20 pm Post subject:
Problem Connecting to DFSRoot in another Domain |
|
|
Hi,
I currently have an issue connecting to a domain based DFSRoot in a child
domain in the same forest. I can connect to the Netlogon share and SYSVOL
share with ease, but when it comes to the DFSRoot, no luck.
If I type in the following from the Run prompt, \\child.domain.net , I see
the 3 shares, when I click on DFSRoot, the browser window hangs for a few
minutes, then pops up with a message saying that the DFSRoot is not
available. You might not have permission to this network resource. Contact
the administrator of this server to find out if you have access permission.
Configuration information could not be read from the domain controller, eith
because the machine is unavailbale, or access has been denied.
Clearly the DC's are available, as I can connect to SYSVOL and Netlogon, and
if I connect direct to the server that the DFSRoot link is pointing, I have
access. Is there some sort of permission that needs to be applied in Active
Directory for cross domain permissions, or a hotfix for this problem?
Domain is Windows 2003 Native and the the clients are WXP SP1 and SP2,
Windows 2000 SP4 and Server (Terminal Services).
I really would prefer not to use the link, but we are forced to by
colleagues who email word documents using a template that is opened from the
DFSRoot, and as it is referenced to in the Templates and Add Ins menu, it
tries to go there, freezes word for 10 minutes and causes a lot of grief !
Thanks
Danny |
|
Richard Chinn [MSFT]
Guest
|
Posted:
Wed Nov 24, 2004 2:03 am Post subject:
Re: Problem Connecting to DFSRoot in another Domain |
|
|
I'm not a DFS expert, but are you using fully qualified domain names
in the file links provided in the e-mails? For example, you need to
specify:
\\domainname.contoso.com\DfsRoot\SomePath\SomeFile.txt
as opposed to just
\\domainname\DfsRoot\SomePath\SomeFile.txt
I found this in the DFS FAQ that is available on
http://www.microsoft.com/dfs.
Q. How does DFS work across domains and forests?
A. The DFS client has a list of known domains that is used to
determine whether a Universal Naming Convention (UNC) path is a
domain-based DFS root. If the first part of the UNC path matches a
known domain name that the client has in this list, the path is
assumed to be a domain-based DFS path. This list of known domains
contains all domains in the client's forest and all domains trusted by
the client's domain or forest. The default buffer for the list of
known domains is 4 kilobytes (KB) (approximately 2,000 characters).
If the list of trusted domains is too large to fit into the 4-KB
cache, the following events take place:
• Clients running Windows 98 cannot access any domain-based DFS
namespaces. To notify you of this, DFS writes an entry with the ID
14537 in the system log in Event Viewer on the domain controller of
the client domain that enumerates the known domains.
• Computers running Windows NT 4.0, Windows 2000, Windows XP, and
Windows Server 2003 automatically increase their cache size to accept
the list of known domains, up to a maximum of 56 KB.
If the list of known domains exceeds 56 KB, DFS puts as many domains
in the cache as it can until the cache reaches 56 KB. DFS then writes
an entry with the ID 14536 in the system event log in Event Viewer to
notify you of this issue.
When populating the cache, DFS gives preference to local and
explicitly trusted domains by filling the cache with their names
first. Consequently, by creating explicit trust relationships with
domains that host important DFS namespaces, you can minimize the
possibility that those domain names might be dropped from the list
that is returned to the client.
Important: To make sure that clients can access link targets in other
trusted domains or trusted forests, you must use DNS names for all
link targets and configure DFS to use fully qualified domain names in
referrals. For more information, see How to Configure DFS to Use Fully
Qualified Domain Names in Referrals.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Thu, 18 Nov 2004 09:20:02 -0000, "DanMcDermott" <dant@na.na.com>
wrote:
| Quote: | Hi,
I currently have an issue connecting to a domain based DFSRoot in a child
domain in the same forest. I can connect to the Netlogon share and SYSVOL
share with ease, but when it comes to the DFSRoot, no luck.
If I type in the following from the Run prompt, \\child.domain.net , I see
the 3 shares, when I click on DFSRoot, the browser window hangs for a few
minutes, then pops up with a message saying that the DFSRoot is not
available. You might not have permission to this network resource. Contact
the administrator of this server to find out if you have access permission.
Configuration information could not be read from the domain controller, eith
because the machine is unavailbale, or access has been denied.
Clearly the DC's are available, as I can connect to SYSVOL and Netlogon, and
if I connect direct to the server that the DFSRoot link is pointing, I have
access. Is there some sort of permission that needs to be applied in Active
Directory for cross domain permissions, or a hotfix for this problem?
Domain is Windows 2003 Native and the the clients are WXP SP1 and SP2,
Windows 2000 SP4 and Server (Terminal Services).
I really would prefer not to use the link, but we are forced to by
colleagues who email word documents using a template that is opened from the
DFSRoot, and as it is referenced to in the Templates and Add Ins menu, it
tries to go there, freezes word for 10 minutes and causes a lot of grief !
Thanks
Danny
|
|
|