Failing reconnect to clustered DFS

[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

 

[Murali Brahmadesam [MSFT]]

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.
----------------------------------------------------------------------------
----------------------------------------

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.

 

[Thomas Kratz]

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 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

 

[Murali Brahmadesam [MSFT]]

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.
----------------------------------------------------------------------------
----------------------------------------

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

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.

 

[Murali Brahmadesam [MSFT]]

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

 

[Murali Brahmadesam [MSFT]]

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.
----------------------------------------------------------------------------
----------------------------------------

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

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

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

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

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.