First published on TECHNET on Mar 24, 2006
In 2004 we released the File Server Migration toolkit along with a new DFS feature known as consolidation roots (described in
this KB article
). In the FSMT documentation we specifically state that Windows 9x clients cannot access consolidation roots. A customer recently asked why, and I thought the response from our DFS developer, Dan Lovinger, was as an interesting explanation.
--Jill
----
DFS consolidation roots rely on a specific behavioral pattern on clients running Windows 2000, Windows XP, and Windows Server 2003 (that is, clients running the NT codeline). That pattern was extremely convenient because it allowed us to do server consolidation with DFS without shipping a new version of the client, and we latched onto it. However, that behavior was a lucky implementation choice on the part of folks who wrote the NT codeline DFS client in the mid '90s – now that we’ve taken advantage of it, of course, it’s required.
When a client is opening a path, the DFS client engine requests a root referral from the server to test whether it is a DFS share or not. If it gets a response, it’s a DFS share. However, prior to consolidation roots, it wasn't strictly necessary for the engine to look at the target of that root referral because all DFS shares were actual shares:
\serverroot
->
\serverroot
. The subsequent open should "of course" still go to
\serverroot
.
NOTE: there is an interesting detail here. DFS domain roots definitely do require the client to look at the target of the root referral. However, in that case the client engine already knows it is handling a domain root because 1) it knows all of the domains it can reach and 2) in order to get that domain root referral, it had to go to a DC in that domain, which is a distinct code path. In the case above, the client already knows that it isn’t a domain root and therefore it was an open design choice whether the target mattered, or simply the fact the client got a response.
Consolidation roots took advantage of the fact that the NT codeline’s DFS client engine did use the target of the root referral in all cases. For consolidation, the consolidation server does not actually host the share. The name “oldserver” is assigned to the consolidation server, which just responds:
\oldservershare
->
\newservershare
(or, in fact, pretty much anything you want:
\newserverdifferentshare
,
\newserver123share
, etc.).
If you look at what's in your PKT cache (dfsutil /pktinfo) after accessing a consolidation root, this should become clear ...
Entry: server-15mydocs1
ShortEntry: server-15mydocs1
Expires in 289 seconds
UseCount: 0 Type:0x0 ( )
0:[redmond-0315mydocs1] State:0x10 ( ACTIVE )
The Windows 9x DS client, which contains a DFS client implementation, does not use the target of the root referral. For consolidation roots, this behavior causes Windows 9x clients to be unable to access the target of a consolidation root, because the Windows 9x client will attempt to access
\oldservershare
instead of the target
\newservershare
. There really was no other way to do what we were trying to do ... it was either new clients for all, or a bullet point that mentioned the 9x DS client was not supported. Since 9x is well into end-of-life the choice at the time was fairly straightforward.
So that’s why consolidation roots aren’t supported on Windows 9x.
--Dan
