Hi, David Everett here again to discuss an issue where DFS clients connect to out-of-site targets when the IPv6 protocol has been partially disabled using an incorrect method.
The customer deployed a DFS link replicated by DFSR. An in-site DFS namespace (DFSN) target called ContosoFS1 was deployed in the branch site. It wasn’t long before branch site users started reporting slow performance access data on the DFS link.
The 1st step was to determine what Active Directory site the DFS clients resided, whether in-site targets existed in the DFS referral and if the in-site target was the Active Target of the DFS client.
To determine which site the client thought it belonged to in Active Directory, we ran this command from the client’s command prompt:
This returned the correct site name. Then in order to determine if the in-site target server was appearing in the list of servers we had the user connect to the DFS link and had the user run this command at the command prompt:
We found that the client was seeing the in-site DFS target server in the referral. As shown below the in-site DFS target server, which is also a DFS Root server, was at the top of the referral order for \contosodfsroot but ContosoFS1 was at the bottom of the referral order for the in-site folder target.
Microsoft(R) Windows(TM) Dfs Utility Version 4.2
Copyright (C) Microsoft Corporation 1991-2005. All Rights Reserved.
Expires in 0 seconds
UseCount: 3 Type:0x81 ( REFERRAL_SVC DFS )
0:[ContosoFS1DFSRoot] State:0x119 ( ACTIVE TARGETSET )
1:[ContosoFS2DFSRoot] State:0x09 ( )
2:[ContosoFS3DFSRoot] State:0x109 ( )
3:[ContosoFS4DFSRoot] State:0x09 ( )
4:[ContosoFS5DFSRoot] State:0x09 ( )
Expires in 0 seconds
UseCount: 0 Type:0x1 ( DFS )
0:[ContosoFS4TargetFolder] State:0x131 ( ACTIVE TARGETSET ) <- out of site IPv4-only W2K3 target that client is connected to
1:[ContosoFS3TargetFolder] State:0x21 ( ) <- out of site IPv4-only W2K3 target
2:[ContosoFS5TargetFolder] State:0x21 ( ) <- out of site IPv4-only W2K3 target
3:[ContosoFS1TargetFolder] State:0x121 ( ) <- In-site target that should be at top of list but isn’t because IPv6 is incorrectly disabled
Once we knew the client was determine its site correctly from active Directory and that the in-site DFS target server was appearing in the DFS referral the focus turned from the client to the Active Directory and the target server.
A quick glance at Active Directory Sites and Services snap-in suggested the IPv4 Site/Subnet logic was properly configured and correct site discovery by the client reinforced this. However, there were no Site/Subnet associations for IPv6 which is the preferred protocol for Windows Server 2008.
Since IPv6 is the preferred protocol for Vista and later Operating Systems I was going to implement an IPv6 Site/Subnet association in Active Directory Sites and Services and see if this would improve DFS referral ordering of the in-site DFS target server. I checked the configuration of IPv6 on ContosoFS1 and found the protocol had been unchecked; which is not a good practice.
It’s a common misconception that unchecking IPv6 disables the protocol when in fact all it does is introduce transient errors. Windows Vista and later operating systems heavily rely upon IPv6 for internal operation, which means the protocol cannot be disabled or uninstalled entirely. Unchecking IPv6 on the adapter settings only unbinds the protocol from the NIC and the OS can still attempt to send remote traffic to the NIC where it never hits the wire.
There are three solutions for this:
I. The preferred method is to place a check mark next to “Internet Protocol Version 6 (TCP /IPv6)” on the IP Properties of the Adapter and reboot the server.
II. Configure Static IPv6 addresses on your Windows Server 2008 DFS target servers and then define IPv6 Subnet/Site associations in Active Directory Sites and Services. See the following TechNet article on how to do this:
III. For those who have some aversion to having any IPv6 traffic hitting the wire there is a “supported” [not recommended by the Microsoft Product Group] way to disable outbound IPv6 using the DisabledComponents registry value as directed in KB929852. Contrary to what the article states, it is possible to simply use Group Policy Preferences to disable IPv6 domain-wide – there is no need for a custom ADMX.
NOTE: It is beyond the scope of this blog to determine which components of IPv6 should be disabled in a given environment using DisabledComponents. To completely disable all External use of IPv6 configure DisabledComponents to ffffffff. Also, if you find IPv6 remains checked in the UI after configuring DisabledComponents in the registry rest assured the protocol is disabled for all remote traffic.
For those interested in more about DFS Site Discovery and Target Selection please see the DFS FAQ.
-David “Dy-no-miiiite!” Everett