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" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> 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]" <(E-Mail Removed)> wrote...


> 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

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Murali Brahmadesam [MSFT]" <(E-Mail Removed)> wrote...
> > 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
> >
>
> 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.
>
> Do you have any Idea how to automate the flushing in case of a failover in
the cluster?
>
> Thanks,
> Thomas
>

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

--
----------------------------------------------------------------------------
----------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
----------------------------------------------------------------------------
----------------------------------------
"Murali Brahmadesam [MSFT]" <(E-Mail Removed)> wrote in message
news:eFCq0q$(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >
> > "Murali Brahmadesam [MSFT]" <(E-Mail Removed)> wrote...
> > > 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
> > >
> >
> > 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.
> >
> > Do you have any Idea how to automate the flushing in case of a failover
in
> the cluster?
> >
> > Thanks,
> > Thomas
> >
>
>

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Murali Brahmadesam [MSFT]" <(E-Mail Removed)> wrote...
>
> > 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
>
> 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.
>
> More after the tests.
>
> Thomas