Failing reconnect to clustered DFS

  • Thread starter Thread starter Thomas Kratz
  • Start date Start date
T

Thomas Kratz

Hi,

I'm having Problems with clustered standalone DFS.

Config:
W2K Cluster (SP3) with SAN Disks
DFS Root in Cluster Group A
Shares in Cluster Group B
DFS replicas pointing to virtual network name of Group B

Both Groups reside on Node 1. After Moving the groups to Node 2 the XP(SP1) clients cannot reconnect to the shares. They still see part of the directory structure in Explorer, but only a reboot of the client machine (logout/-in doesn't help either) lets them see the shares again.

Any ideas?

Thomas
 
Hi Thomas,
This is a known issue. Try dfsutil.exe /purgemupcache on the clients, this
is solve the issue without requiring a reboot.
dfsutil.exe is an IDW tool

Thanks
Murali

--
----------------------------------------------------------------------------
----------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
----------------------------------------------------------------------------
----------------------------------------
Thomas Kratz said:
Hi,

I'm having Problems with clustered standalone DFS.

Config:
W2K Cluster (SP3) with SAN Disks
DFS Root in Cluster Group A
Shares in Cluster Group B
DFS replicas pointing to virtual network name of Group B

Both Groups reside on Node 1. After Moving the groups to Node 2 the
Click to expand...
XP(SP1) clients cannot reconnect to the shares. They still see part of the
directory structure in Explorer, but only a reboot of the client machine
(logout/-in doesn't help either) lets them see the shares again.
 
Murali Brahmadesam said:
Hi Thomas,
This is a known issue. Try dfsutil.exe /purgemupcache on the clients, this
is solve the issue without requiring a reboot.
dfsutil.exe is an IDW tool
Click to expand...

Thanks for the quick answer.

The dfsutil I have says:
unrecognized option "purgemupcache"

What version do I have to use?
I have Beta 2.2 (Win2000 SP3)

Thanks
Thomas
 
I am seeing that XP dfsutil.exe did not have this "purgemupcache" option.
this option is present in the new dfsutil.exe released with W2K3.

dfsutil /pktflush is to flush the information shown in dfsutil /pktinfo.
It is normal to see some of the entries having expiry of 0 seconds. This
is not the cause of your problem.You will see a non-zero value when
you access the DFS path again.

Thanks
Murali
--
----------------------------------------------------------------------------
----------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
----------------------------------------------------------------------------
----------------------------------------
Thomas Kratz said:
Hi Murali,

I installed the XP Support Tools on a client and played a bit around with DFSUTIL.
Did you mean "dfsutil /pktflush" ?

When I run "dfsutil /pktinfo", I see the connected DFS shares with an
Click to expand...
expiry of 0 seconds. Am I right in assuming this to be the problem? The
Expiry is set to 60 seconds on the DFS shares server side.
 
Hi Thomas,
Since you cannot automate the use of dfsutil /purgemupcache
on failover, here is a workaround that I used to overcome this issue.

While configuring the Cluster group make the following dependency:
A->B denotes that resource B is dependent on A.

(InternalIPAddress) -> (InternalNetworkName) -> (DfsRoot) ->
(ExternalIPAddress)->(ExternalNetworkName)

Another dependency (SharedDisk) -> (DfsRoot)

ExternalNetworkName is the name that will be used by the users to
access this dfsroot. InternalNetworkName is the name used by
DfsRoot to come online.

The additional requirement for this setup is an additional static IP
address.
But this will solve your problem on failovers and users need not reboot
their machines to access DFSRoots.

Thanks
Murali
 
Hi Thomas,
I was not able to understand your repro without clusters. For standalone
dfsroot you cannot have multiple
replicas. If possible post your DFS configuration and your accesses, please
also attach the output
of dfsutil /pktinfo, /spcinfo taken from the client after access. This will
give a clear picture of the problem.
The mupcache i was mentioning to you has a timeout of 15 mins, after this
period of inactivity the cache will
expire and users will succeed in connecting to DFS roots.

Thanks
Murali

--
----------------------------------------------------------------------------
----------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
----------------------------------------------------------------------------
----------------------------------------
Thomas Kratz said:
Ok, I'll have to look for it on the W2K3 CDs.

But perhaps this is another problem altogether. I tested this a bit more systematically:

Giving the user local admin rights on the client results in successful
Click to expand...
reconnection. After revoking the rights again, the ability to reconnect
isn't lost (didn't test new shares after revoking the rights).
I suspect, that a user process tries to add some keys or values to the
Click to expand...
local machine part of the registry, which is not allowed by default.
I will check this with regmon or similar tools to isolate the part of the
Click to expand...
registry. Could be files also, but I think it is less likely.
I was also able to reproduce the problem without a cluster, but with two
Click to expand...
shares on different machines bound as two replicas on a new standalone DFS
root. After having stopped the sharing of the connected share the client was
not able to reconnect to the second replica.
 
Back
Top