First published on TECHNET on Mar 27, 2006
Hi, this is Sanjoy Chatterjee, program manager for DFS Namespaces here to talk about client failback. Several branch office failure scenarios can result in client being bound indefinitely to a remote server even after availability to their local, preferred server is restored. Customers commonly deploy DFS for availability or for data protection. They will, for example, deploy DFS for software or document distribution with replicas in both the hubs and branches. Clients should access the local replica within their branch. When their branch server fails, they will failover to the hub. Normally, DFS employs a referral system known as “sticky referral”, i.e. DFS will stick to a referral once it has been established. This is an optimal scenario in most cases. However, in cases where the referral failed over to a remote server because the local server was down, this behavior causes the referral not to failback to the local site, resulting in poor experience for the end user as well as costly WAN bandwidth consumption. The lack of failback behavior is a common customer complaint.
In Windows 2003 R2 (and Windows XP SP2 clients), DFS introduced a feature called client failback. The client failback setting can be applied to a stand-alone root, a domain root, or a link. Links may either inherit or override the behavior of the root similar to the interaction of the Insite flag on roots and links.
As of XP SP2, clients refresh their link and root referrals when the referral TTL expires. When refreshing the referral for a link or root, the client will determine if it should attempt to failback to a preferred server.
If the failback policy is enabled per the inheritance rules listed above, the DFS server will set the failback bit in the referral response. If the failback bit is set in the referral, the client will attempt to failback to its local site, starting at the top of the referral list. If the client determines that it had earlier failed over to a client in the same cost bucket (as computed by the server considering site cost and priority), it will stick to the existing target.
On an XP+ client, any handles open at the time the failback occurs will not be broken. Handles which were created prior to the failback continue to access the previous link or root target. In Vista/Longhorn, if CSC is enabled, then the handle will be transferred over to the new target and CSC will ensure that the two targets are synchronized. This handle transfer is transparent to the user. If CSC is not enabled, the behavior is similar to XP.
To enable client failback in a namespace, refer to the instructions in the
DFS Management Help on TechNet
. You will also need to install a client failback hotfix as described in
KB article 898900
.
--Sanjoy
