none
Unable to view namespaces, add namespace servers, etc. in DFS Managment

    Pregunta

  • This may be a simple network config issue, but it only seems to give me trouble in DFS management, so I decided to post here...

    Here's the story:  We have two Windows Server 2008 Standard boxes on the same VLAN running Active Directory at the 2008 domain functional level.  Both are domain controllers (globals), and both run the Distributed File System role with DFS Namespaces and DFS Replication installed.  Until recently, they were both namespace servers for a couple of domain-based namespaces hosting replicated content.

    Now, I can see the namespaces in one of the domain controllers (DC1) using the DFS Management snap-in, but when I try to view that same information on DC2 I receive the following error:

    \\domain\namespace: Delegation information for the namespace cannot be queried.  The specified domain either does not exist or could not be contacted.

    I find that perplexing, because DC2 is a domain controller for that domain and I'm receiving no errors Active Directory Domain Services.  I can ping between both domain controllers using their FQDNs and the DNS information appears to be correct.  I can make changes to the Group Policy settings in the Active Directory from either domain controller and the changes show up on both boxes.   The problems seem to only exist inside DFS management.

    Even though I cannot view the information about the existing namespaces on DC2, users can still access the namespaces and use them normally.

    Additionally, from either domain controller, I cannot create, change, or remove a namespace involving DC2.  Same goes for editing or creating replication groups involving data on DC2.  I receive an error similar to "the specified domain either does not exist or could not be contacted."  But if I, for example, create a namespace using DC1 and specify DC1 as the only namespace server, I can successfully create the namespace, but it will not appear in the list on DC2.

    The circumstances regarding what is working and what isn't working has me dazed and confused about what troubleshooting steps to take next.  Any suggestions?
    martes, 18 de noviembre de 2008 22:59

Respuestas

  • Hi Rowan,

     

    1. Would you please verify that the following services are started on both of the DFS member server?

     

    Remote Procedure Call

    Remote Registry

    DFS Namespace

    DFS Replication

     

    2. Please also make sure that the DNS settings are correct and the DNS is pointed to the current one in your domain. You may test on the problematic secondary server (VMSVR3) to ping the other domain controller to see if you can ping through it.

     

    3. Meanwhile, please also check if the logon credential has the delegated management permission on this namespace. If possible, please logon as the domain admin's account to check if the issue still exist

     

    4. If possible, please run the following commands on the problematic server to dump the AD configuration settings and service-wide configuration of DFS replication, and post back the result here for the further research.

     

    Dfsrdiag dumpADcfg

     

    Dfsrdiag dumpMachinecfg

     

    Hope it helps.


    David Shen - MSFT
    • Marcado como respuesta David Shen miércoles, 03 de diciembre de 2008 5:53
    martes, 02 de diciembre de 2008 9:52
  • Hi,

     

    According to the research, the DFS Management console depends on RPC end mapped to remotely manage the DFS Namespace and DFS Replication. The error message may be occurred if the RPC 135 is blocked by any Firewall between the 2 DCs. Because the server has to connect to the PDC to access the DFS information in the Active Directory, if there is anything configured on the firewall which blocks the connectivity to the PDC, this maybe cause the error message that you mentioned. To troubleshoot the issue, would you please logon the DC with domain administrator centennial to follow the steps to test?

     

    Troubleshooting Steps:

     

    1. First, you may check the Event Viewer to see if there is any Error message or Warning message about DFS Replication at the time of the issue occurs. If possible, you may post the corresponding error or warning here.

     

    2. Please check the firewall to verify that TCP port 135 is not blocked between domain controllers. If possible, please turn off the Windows Firewall on both the DCs to check if the error message will re-occur.

     

    3. Please verify that the "DFS Replication" Service and "DFS Namespace" Service are "Started" on both of the domain controllers.

     

    4. Please verify that the TCP port that is used by the DFS Replication Service on the replication partner can be accessed.

     

    You may refer to the following procedure to verify both TCP port 135 and connectivity to the DFS Replication RCP endpoint at the same time.

     

    Please use rpcdump.exe to verify port 135 connectivity and RPC endpoint connectivity.

     

    Use rpcdump.exe to query the endpoint mapper database and the DFS Replication endpoint.

     

    c:\> rpcdump.exe /s <DFS Replication partner> /v /i > C:\endpoints.txt

     

    Open the endpoints.txt file, and look for the endpoint that uses ncacn_ip_tcp ProtSeq and has a UUID of 897e2e5f-93f3-4376-9c9c-fd2277495c27. The output should look similar to the following:

     

    ProtSeq:ncacn_ip_tcp

    Endpoint:1049

    NetOpt:

    Annotation:Frs2 Service

    IsListening:YES

    StringBinding:ncacn_ip_tcp:10.1.1.2[1049]

    UUID:897e2e5f-93f3-4376-9c9c-fd2277495c27

    ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT

     

    VersMajor 1 VersMinor 0

     

    If the value of IsListening is YES, then both port 135 and the port being used by the DFS Replication interface can be accessed. The port that is used by the DFS Replication interface is indicated by the Endpoint value. In the above case, the TCP port being used by DFS Replication is TCP port 1049.

     

    If the value of IsListening is NO, the problem is related to port blocking issues for the Endpoint port. Gather a network monitor trace and consult with a networking support engineer.

     

    If the first lines in the endpoints.txt file indicate a failure to query endpoints on the replication partner, I suspect an issue with TCP port 135 connectivity to that server.

     

    The first few lines of the endpoints.txt file should look similar to the following:

     

    Querying Endpoint Mapper Database...

    137 registered endpoints found.

     

    You may download the rpcdump.exe from the following link

    http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

     

    Hope it helps.


    David Shen - MSFT
    • Propuesto como respuesta David Shen viernes, 21 de noviembre de 2008 16:04
    • Marcado como respuesta David Shen lunes, 24 de noviembre de 2008 2:08
    • Desmarcado como respuesta brandonksu martes, 25 de noviembre de 2008 20:41
    • Marcado como respuesta David Shen viernes, 28 de noviembre de 2008 1:55
    viernes, 21 de noviembre de 2008 9:20
  • Hi,

     

    Thanks for the reply.

     

    You may need to verify that the second DC has been added as a server for the root of the namespace that you created.

     

    You can try to perform the operation on the working DC1.

     

    1. Please check it in the DFS Management console, select the name of the root of the namespace you created, under "NameSpaces" on the left pane, and select "NameSpace servers" tab on the middle pane. The two DCs should be present. 

     

    You may also use ADSIedit.msc to check the following attribute on both of the DCs.

     

    a. Open ADSIedit.msc.

     

    b. Connect to Default Naming Context (the domain name)

     

    c. Expand and locate the container, which show the DFS root information

     

    CN=<name_of_the_root_of_the_namespace>,CN=Dfs-Configuration,CN=System,DC=<name_of_your_domain>

     

    d. In the middle area of the ADSIedit console, right-click on the namespace that you created and select Properties, check the attribute "remoteservername" of the object to see if both of the 2 members name is in the value. If so, the namespace should be launched.

     

    2. Since the DFS configuration information is stored in Active Directory database, when we launch the DFS management console, it will try to retrieve the DFS configuration from AD. However, after we just configure the DFS Replication in DFS management console, the DFS replication won't begin immediately. Replication will not begin until the configuration is picked up by the members of the replication group. The amount of the time this taken depends on the Active Directory Replication latency and the polling interval. So we will have to wait for that DC to replicate to the ones being used by the other DFSR members.

     

    Meanwhile, we can use Active Directory Sites and Services snap-in to force replicate AD replica at once.

     

    Steps:

     

    a. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.

     

    b. Expand the Sites container in the left pane. Expand the container that represents the name of the site containing the target server that needs to be synchronized with its replication partners.

     

    c. Expand the Servers container, and then expand the target server to display the NTDS Settings object

     

    d. Click the NTDS Settings object. The connection objects in the right pane represent the target server's direct replication partners.

     

    e. Right-click a connection object in the right pane, and then click Replicate Now. Domain Controller initiates replication of any changes from the source server (the server represented by the connection object) to the target server for all directory partitions the target server is configured to replicate from the source server.

     

    We can run "Dfsrdiag Pollad" on both of the members to force them to pick up this DFS configuration change as soon as possible.

     

    Dfsrdiag Pollad

     

    Please note:

    "Dfsrdiag Pollad" just tells the DFSR service to check its local DC for configuration changes.

     

    Hope it helps.


    David Shen - MSFT
    • Marcado como respuesta David Shen viernes, 28 de noviembre de 2008 1:56
    miércoles, 26 de noviembre de 2008 11:30

Todas las respuestas

  • Hi,

     

    According to the research, the DFS Management console depends on RPC end mapped to remotely manage the DFS Namespace and DFS Replication. The error message may be occurred if the RPC 135 is blocked by any Firewall between the 2 DCs. Because the server has to connect to the PDC to access the DFS information in the Active Directory, if there is anything configured on the firewall which blocks the connectivity to the PDC, this maybe cause the error message that you mentioned. To troubleshoot the issue, would you please logon the DC with domain administrator centennial to follow the steps to test?

     

    Troubleshooting Steps:

     

    1. First, you may check the Event Viewer to see if there is any Error message or Warning message about DFS Replication at the time of the issue occurs. If possible, you may post the corresponding error or warning here.

     

    2. Please check the firewall to verify that TCP port 135 is not blocked between domain controllers. If possible, please turn off the Windows Firewall on both the DCs to check if the error message will re-occur.

     

    3. Please verify that the "DFS Replication" Service and "DFS Namespace" Service are "Started" on both of the domain controllers.

     

    4. Please verify that the TCP port that is used by the DFS Replication Service on the replication partner can be accessed.

     

    You may refer to the following procedure to verify both TCP port 135 and connectivity to the DFS Replication RCP endpoint at the same time.

     

    Please use rpcdump.exe to verify port 135 connectivity and RPC endpoint connectivity.

     

    Use rpcdump.exe to query the endpoint mapper database and the DFS Replication endpoint.

     

    c:\> rpcdump.exe /s <DFS Replication partner> /v /i > C:\endpoints.txt

     

    Open the endpoints.txt file, and look for the endpoint that uses ncacn_ip_tcp ProtSeq and has a UUID of 897e2e5f-93f3-4376-9c9c-fd2277495c27. The output should look similar to the following:

     

    ProtSeq:ncacn_ip_tcp

    Endpoint:1049

    NetOpt:

    Annotation:Frs2 Service

    IsListening:YES

    StringBinding:ncacn_ip_tcp:10.1.1.2[1049]

    UUID:897e2e5f-93f3-4376-9c9c-fd2277495c27

    ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT

     

    VersMajor 1 VersMinor 0

     

    If the value of IsListening is YES, then both port 135 and the port being used by the DFS Replication interface can be accessed. The port that is used by the DFS Replication interface is indicated by the Endpoint value. In the above case, the TCP port being used by DFS Replication is TCP port 1049.

     

    If the value of IsListening is NO, the problem is related to port blocking issues for the Endpoint port. Gather a network monitor trace and consult with a networking support engineer.

     

    If the first lines in the endpoints.txt file indicate a failure to query endpoints on the replication partner, I suspect an issue with TCP port 135 connectivity to that server.

     

    The first few lines of the endpoints.txt file should look similar to the following:

     

    Querying Endpoint Mapper Database...

    137 registered endpoints found.

     

    You may download the rpcdump.exe from the following link

    http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

     

    Hope it helps.


    David Shen - MSFT
    • Propuesto como respuesta David Shen viernes, 21 de noviembre de 2008 16:04
    • Marcado como respuesta David Shen lunes, 24 de noviembre de 2008 2:08
    • Desmarcado como respuesta brandonksu martes, 25 de noviembre de 2008 20:41
    • Marcado como respuesta David Shen viernes, 28 de noviembre de 2008 1:55
    viernes, 21 de noviembre de 2008 9:20
  • Hi David,

    Thanks for taking the time to help troubleshoot this with me.  Sorry for the delayed reply - I didn't receive notification that you had responded and just saw your message today.

    I performed the troubleshooting steps you proposed.  Here are the results:

    1.  I see nothing out of the ordinary in the event viewer relevant to any DFS Replication or Namespace errors/warnings around the time the problems started.  I did have a disk member of a RAID0 array on DC1 die about a week prior, and obviously that caused some replication errors, but I seem to recall the management of both namespace and replication services was still possible after that event occurred.

    2.  There doesn't seem to be any issue with firewall rules blocking TCP port 135 between the domain controllers.  To confirm, I temporarily disabled firewalls and antivirus services on both domain controllers, but there was no change in behavior.

    3.  DFS Replication and DFS Namespace services are running on both machines.  I tried restarting the services on each domain controller server and eventually restarted the entire system on both servers to no avail.

    4.  I performed the rpcdump.exe command from both domain controllers following your instructions.  The output I received on DC1 made no reference to the UUID you mentioned.  The output I received on DC2 listed the following:

    ProtSeq:ncacn_ip_tcp
    Endpoint:5722
    NetOpt:
    Annotation:Frs2 Service
    IsListening:YES
    StringBinding:ncacn_ip_tcp:DC1[5722]
    UUID:897e2e5f-93f3-4376-9c9c-fd2277495c27
    ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT
    VersMajor 1  VersMinor 0


    For what it's worth, I've found I can now create DFS Replication Groups involving both domain controllers, and replication seems to be occurring normally.  I'm not sure if something changed to allow it to start working again, or if I simply troubleshooted something incorrectly late one night and wrongly thought it wasn't working.  In any case, the "replication" part seems to be working now, but the "namespace management" part is still broken.  Any other troubleshooting ideas?

    Thanks in advance!
    martes, 25 de noviembre de 2008 20:41
  • Hi,

     

    Thanks for the reply.

     

    You may need to verify that the second DC has been added as a server for the root of the namespace that you created.

     

    You can try to perform the operation on the working DC1.

     

    1. Please check it in the DFS Management console, select the name of the root of the namespace you created, under "NameSpaces" on the left pane, and select "NameSpace servers" tab on the middle pane. The two DCs should be present. 

     

    You may also use ADSIedit.msc to check the following attribute on both of the DCs.

     

    a. Open ADSIedit.msc.

     

    b. Connect to Default Naming Context (the domain name)

     

    c. Expand and locate the container, which show the DFS root information

     

    CN=<name_of_the_root_of_the_namespace>,CN=Dfs-Configuration,CN=System,DC=<name_of_your_domain>

     

    d. In the middle area of the ADSIedit console, right-click on the namespace that you created and select Properties, check the attribute "remoteservername" of the object to see if both of the 2 members name is in the value. If so, the namespace should be launched.

     

    2. Since the DFS configuration information is stored in Active Directory database, when we launch the DFS management console, it will try to retrieve the DFS configuration from AD. However, after we just configure the DFS Replication in DFS management console, the DFS replication won't begin immediately. Replication will not begin until the configuration is picked up by the members of the replication group. The amount of the time this taken depends on the Active Directory Replication latency and the polling interval. So we will have to wait for that DC to replicate to the ones being used by the other DFSR members.

     

    Meanwhile, we can use Active Directory Sites and Services snap-in to force replicate AD replica at once.

     

    Steps:

     

    a. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.

     

    b. Expand the Sites container in the left pane. Expand the container that represents the name of the site containing the target server that needs to be synchronized with its replication partners.

     

    c. Expand the Servers container, and then expand the target server to display the NTDS Settings object

     

    d. Click the NTDS Settings object. The connection objects in the right pane represent the target server's direct replication partners.

     

    e. Right-click a connection object in the right pane, and then click Replicate Now. Domain Controller initiates replication of any changes from the source server (the server represented by the connection object) to the target server for all directory partitions the target server is configured to replicate from the source server.

     

    We can run "Dfsrdiag Pollad" on both of the members to force them to pick up this DFS configuration change as soon as possible.

     

    Dfsrdiag Pollad

     

    Please note:

    "Dfsrdiag Pollad" just tells the DFSR service to check its local DC for configuration changes.

     

    Hope it helps.


    David Shen - MSFT
    • Marcado como respuesta David Shen viernes, 28 de noviembre de 2008 1:56
    miércoles, 26 de noviembre de 2008 11:30
  • Hi There David,

    I am having this exact same problem, but my config is slightly different.

    My two DFS root servers are NOT Domain Controllers, but they are BOTH 2008 Datacentre x64 editions (one has Hyper-V on a multi-Xeon box) other is just a simple x64 chip.

    One can fully administer the DFS, and the other just gives a message "delegation information for the namespace cannot be queried. The service did not respond."

    I have checked with RPCDump.. .and found that all of my RPC ports are "Not Pinged" status...... This makes no sense!

    Your comments about using ADSIEdit are great, except the attribute that you list "remoteservername" does not exist at any level in my object:

    CN=fs, CN=Dfs-Configuration,CN=System,DC=DC2

    Aside from this, replication appears to be working correctly. I Just want/ need to be able to manipulate the DFS from the currently secondary server (VMSVR3), which will become the primary when all replication has completed.

    You input and comments are much appreciated!

    TIA

    Rowan
    RWS!
    lunes, 01 de diciembre de 2008 6:11
  • Hi Rowan,

     

    1. Would you please verify that the following services are started on both of the DFS member server?

     

    Remote Procedure Call

    Remote Registry

    DFS Namespace

    DFS Replication

     

    2. Please also make sure that the DNS settings are correct and the DNS is pointed to the current one in your domain. You may test on the problematic secondary server (VMSVR3) to ping the other domain controller to see if you can ping through it.

     

    3. Meanwhile, please also check if the logon credential has the delegated management permission on this namespace. If possible, please logon as the domain admin's account to check if the issue still exist

     

    4. If possible, please run the following commands on the problematic server to dump the AD configuration settings and service-wide configuration of DFS replication, and post back the result here for the further research.

     

    Dfsrdiag dumpADcfg

     

    Dfsrdiag dumpMachinecfg

     

    Hope it helps.


    David Shen - MSFT
    • Marcado como respuesta David Shen miércoles, 03 de diciembre de 2008 5:53
    martes, 02 de diciembre de 2008 9:52
  • Hi David,

    Unfortunately, I have had to re-install windows on this hardware earlier today due to an unrelated fault that damaged the boot sector of my hard-drive.

    However, I can point out that DFS root delegation was on DC2, DC1 (the other DC!) VMSVR2 and VMSVR3, but the files were only on the 2 VMSVR's.....

    All files were accessable from either server, and replication WAS occurring. It appeared to be that the MMC was not properly communicating with the service.....

    Manual removal of VMSVR3, and then rebuilding the DFS referrals to this server after OS re-installation has however, solved the issue......

    IF this raises its ugly little head again... I will be sure to post again.

    Thanks for your input.

    Regards

    Rowan
    RWS!
    miércoles, 03 de diciembre de 2008 11:18