Windows Server 2019 DFS Failure RRS feed

  • Question

  • Hi 

    Cannot seem to find a Server category here:

    Issue.  DFS runs fine and syncs to PDC.  The minute you create a 6to4 adapter it fails.  It seems there are allot of of unresolved issues posted regarding "The namespace on domain cannot be enumerated.  The system cannot open the device or file specified."  I tested this with a reinstall and it seems the DFS switches to IPV6 once the adapter is created.  There is no netbios (which DFS uses for some bizarre reason) for IPV6 and fails.  I'm certain there are no DNS or PDC misconfiguration, it happens instantly.  I cannot find a way to mitigate this as even after removing the adapter, and route the DFS stays broken.  You're welcome to set up a Hurricane Electric free IPV6 tunnel to enable IPV6.  DFS breaks instantly.  I noticed that the dfsrs service is now bonded to the internal IPV6 loopbacks.

    Can anyone help to DFS working again? Preferably with 6to4?

    Thank you


    • Edited by Johanbar Sunday, August 23, 2020 3:53 PM
    Sunday, August 23, 2020 3:51 PM

All replies

  • Hi maybe this will will help some Server Ops:

    When adding a 6to4 adapter, the hidden adapter has no IPv4 address/interface, it is bonded to a physical adapters IPV4 interface.  When doing this with a DC with smb/DFS installed - used for PDC coms Server 2019 (and I suspect the older versions also), when adding the adapter with

    netsh interface ipv6 add v6v4tunnel interface=IP6Tunnel for example, the server adds a phantom adapter with a blank IP address in the {} format.  This breaks the PDC and also DFS.  Nasty.

    View the SMB interfaces with Get-SmbServerNetworkInterface.  I did not try to remove the phantom interface, as it's not listed as a valid interface with Get-NetAdapter -IncludeHidden.  Or check if this is the case when adding the adapter with Powershell, I suspect the same will happen.  Registry surgery might be an option to search for the interface and see if it restores FDS and the PDC.

    Workaround: install the 6to4 adapter and configure it first, finalize the network before promoting to DC.  Adapter works fine and DFS works.

    Good luck.


    • Edited by Johanbar Tuesday, August 25, 2020 1:59 PM
    Tuesday, August 25, 2020 1:58 PM
  • reHi

    Should also mention that this has knock-on effect in that NPS also falls over, as it tries to bind, with the invalid 6to4 IP you get a Cannot bind sockets error and the service will not start.  You can point NPS to a IP with the protocols page i.e.,1813 etc as a workaround.  There's also a bug it seems in Server 2019 in that NPS causes Routing and Remote to fail if NPS has the tick box to drop failed log attempts to the log file. Best is still to finalize adapter prior to promoting.

    Kind regards


    Thursday, August 27, 2020 12:48 PM
  • You can use the following tests to verify connectivity.

    Determine whether the client was able to connect to a domain controller for domain information by using the DFSUtil.exe /spcinfo command. The output of this command describes the trusted domains and their domain controllers that are discovered by the client through DFSN referral queries. This is known as the "Domain Cache."

    In the following example, both the DNS domain name "" and the NetBIOS domain name "CONTOSO" are discovered by the client. Two domain controllers were identified for the domain name "CONTOSO": 2003server2 and 2003server1. If the client accesses the DNS name "" in a request, the entries are displayed under the "" entry.
    Entries that are marked by an asterisk (*) were obtained through the Workstation service. The other entries were obtained through referrals by the DFSN client. The entries that are marked by a plus sign (+) are the domain controllers that are currently used by the client. For more information about referral processes, visit the following Microsoft Web site:
    How DFS Works
    To evaluate connectivity, try a simple network connection to the active domain controller by using its IP address. For example, type either of the following commands:
    start \\
    net view \\
    A successful connection lists all shares that are hosted by the domain controller.

    If the connection is successful, determine whether a valid DFSN referral is returned to the client after it accesses the namespace. You can do this by viewing the referral cache (also known as the PKT cache) by using the DFSUtil.exe /pktinfo command.

    The following output details the expected entries within the client's referral cache after the client accesses the DFSN path "\\\dfsroot\link." The root has two targets ("rootserver1" and "rootserver2"). The link has a single target ("fileserver").
    Entry: \\dfsroot
    ShortEntry: \\dfsroot
    Expires in 300 seconds
    UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
       0:[\ROOTSERVER1\dfsshare] State:0x119 ( ACTIVE )
       1:[\ROOTSERVER2\dfsshare] State:0x09 ( )

    Entry: \\dfsroot\link
    ShortEntry: \\dfsroot\link
    Expires in 1800 seconds
    UseCount: 0 Type:0x1 ( DFS )
       0:[\fileserver\data] State:0x131 ( ACTIVE )
    If you cannot find an entry for the desired namespace, this is evidence that the domain controller did not return a referral. DFSN service failures are discussed later in this article.

    If you see an entry for the namespace (that is, "\\dfsroot"), the entry proves that the client was able to contact a domain controller, but then did not reach any DFSN namespace targets. If not any of the namespace targets that are listed are designated as "ACTIVE," that indicates that all targets were unreachable.

    Try to access to each namespace server by using IP addresses. For this test, you must specify only the IP address of the server, and you must not include the namespace share (that is, "net view \\" but not "net view \\\dfsroot"). Otherwise, you may unknowingly be referred to another DFS root server. If this occurs, you will receive misleading results. Note any error messages that are reported during these actions.
    Thursday, August 27, 2020 1:57 PM