Windows Vista Tips

Windows Vista Tips > Newsgroups > Windows Server > File Systems > SPC cache

Reply
 
 
RW
Guest
Posts: n/a

 
      11-17-2009
We have recently implemented DFS domain based while for most part all works
well there is one problem we are facing and have no idea how to work around
this. Here is what's happening which BTW is unacceptable when A user starts
up laptop offline with cached credentials then after X minutes connects VPN
at first all shared drives based on DFS are not accessible and user have to
wait sometimes up to 15 minutes and then she or he can access drives, I found
these 2 articles which describes how DFS works and this also explains 100%
why we having this issue, it is not a bug but it is by design! which is even
more frustrating knowing that this is how it works, so my question for others
is how do you live with that, is this acceptable for your organization that
end user connecting VPN have to wait up to 15 minutes (most, sometimes less)
to get to resources.
BTW this can be reproduce in the LAN too if I start up PC disconnected from
network, login with cached credentials, wait 5 minutes then connect PC to LAN
same outcome
Here are 2 KB from Microsoft describing this issue

http://support.microsoft.com/default.aspx/kb/835261

http://support.microsoft.com/kb/291377/

 
Reply With Quote
 
 
 
 
DaveMills
Guest
Posts: n/a

 
      11-17-2009

The first article applies only to pre-sp2 systems. Are you system pre-xp SP2. If
so why not apply the SP.

On Tue, 17 Nov 2009 14:13:01 -0800, RW <> wrote:

>We have recently implemented DFS domain based while for most part all works
>well there is one problem we are facing and have no idea how to work around
>this. Here is what's happening which BTW is unacceptable when A user starts
>up laptop offline with cached credentials then after X minutes connects VPN
>at first all shared drives based on DFS are not accessible and user have to
>wait sometimes up to 15 minutes and then she or he can access drives, I found
>these 2 articles which describes how DFS works and this also explains 100%
>why we having this issue, it is not a bug but it is by design! which is even
>more frustrating knowing that this is how it works, so my question for others
>is how do you live with that, is this acceptable for your organization that
>end user connecting VPN have to wait up to 15 minutes (most, sometimes less)
>to get to resources.
>BTW this can be reproduce in the LAN too if I start up PC disconnected from
>network, login with cached credentials, wait 5 minutes then connect PC to LAN
>same outcome
>Here are 2 KB from Microsoft describing this issue
>
>http://support.microsoft.com/default.aspx/kb/835261
>
>http://support.microsoft.com/kb/291377/

--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
 
Reply With Quote
 
RW
Guest
Posts: n/a

 
      11-18-2009
all our clients are XP SP3 and this is still happening, I have case open for
this with Microsoft and they pretty much confirmed this is how it works, I
just can't belive that other people who use DFS and experiancing samething
are OK with hwo it works. I'm waiting for Microsoft support to give me some
work around meanwhile I'm posting here to see how others are dealing with
this?
For people were majority of clients are desktop in LAN this might not be a
problem but for those who have lot of mobile clients and users accesing VPN
this is a problem and in my case it is unacceptable that this works like this.

I can see 2 ways to work this around 1) modify in registry or GPO how often
client checks and builds SPC cache table, well this one won't work because
min valid timeframe is 15 minutes
option 2) I need some sort of script to run at VPN logon to force SPC cache
to be update when VPN is established. So far did not find one.

is there anyone else who have this problem?

"DaveMills" wrote:

> The first article applies only to pre-sp2 systems. Are you system pre-xp SP2. If
> so why not apply the SP.
>
> On Tue, 17 Nov 2009 14:13:01 -0800, RW <> wrote:
>
> >We have recently implemented DFS domain based while for most part all works
> >well there is one problem we are facing and have no idea how to work around
> >this. Here is what's happening which BTW is unacceptable when A user starts
> >up laptop offline with cached credentials then after X minutes connects VPN
> >at first all shared drives based on DFS are not accessible and user have to
> >wait sometimes up to 15 minutes and then she or he can access drives, I found
> >these 2 articles which describes how DFS works and this also explains 100%
> >why we having this issue, it is not a bug but it is by design! which is even
> >more frustrating knowing that this is how it works, so my question for others
> >is how do you live with that, is this acceptable for your organization that
> >end user connecting VPN have to wait up to 15 minutes (most, sometimes less)
> >to get to resources.
> >BTW this can be reproduce in the LAN too if I start up PC disconnected from
> >network, login with cached credentials, wait 5 minutes then connect PC to LAN
> >same outcome
> >Here are 2 KB from Microsoft describing this issue
> >
> >http://support.microsoft.com/default.aspx/kb/835261
> >
> >http://support.microsoft.com/kb/291377/

> --
> Dave Mills
> There are 10 types of people, those that understand binary and those that don't.
> .
>

 
Reply With Quote
 
DaveMills
Guest
Posts: n/a

 
      11-19-2009
I have VPN clients (a few) and am not aware of this issue. I also use a VPN
client to connect to the LAN. I have not had a noticeable problem. If I log in
then no mapped drives are able to connect because the shares are not available.
This is expected. If I then connect the VPN the mapped drives remain
disconnected but the become available if I use them by double clicking the
drive.

I have seen once or twice a difficulty is re-connecting but is quite rare and I
have never worked out why as the problem went away.

I will look out for further occupancies to see if it fits your description.
Mostly though I connect from a home PC and use the UNC/DFS names directly rather
than via mapped drives.



On Wed, 18 Nov 2009 09:01:01 -0800, RW <> wrote:

>all our clients are XP SP3 and this is still happening, I have case open for
>this with Microsoft and they pretty much confirmed this is how it works, I
>just can't belive that other people who use DFS and experiancing samething
>are OK with hwo it works. I'm waiting for Microsoft support to give me some
>work around meanwhile I'm posting here to see how others are dealing with
>this?
>For people were majority of clients are desktop in LAN this might not be a
>problem but for those who have lot of mobile clients and users accesing VPN
>this is a problem and in my case it is unacceptable that this works like this.
>
>I can see 2 ways to work this around 1) modify in registry or GPO how often
>client checks and builds SPC cache table, well this one won't work because
>min valid timeframe is 15 minutes
>option 2) I need some sort of script to run at VPN logon to force SPC cache
>to be update when VPN is established. So far did not find one.
>
>is there anyone else who have this problem?
>
>"DaveMills" wrote:
>
>> The first article applies only to pre-sp2 systems. Are you system pre-xp SP2. If
>> so why not apply the SP.
>>
>> On Tue, 17 Nov 2009 14:13:01 -0800, RW <> wrote:
>>
>> >We have recently implemented DFS domain based while for most part all works
>> >well there is one problem we are facing and have no idea how to work around
>> >this. Here is what's happening which BTW is unacceptable when A user starts
>> >up laptop offline with cached credentials then after X minutes connects VPN
>> >at first all shared drives based on DFS are not accessible and user have to
>> >wait sometimes up to 15 minutes and then she or he can access drives, I found
>> >these 2 articles which describes how DFS works and this also explains 100%
>> >why we having this issue, it is not a bug but it is by design! which is even
>> >more frustrating knowing that this is how it works, so my question for others
>> >is how do you live with that, is this acceptable for your organization that
>> >end user connecting VPN have to wait up to 15 minutes (most, sometimes less)
>> >to get to resources.
>> >BTW this can be reproduce in the LAN too if I start up PC disconnected from
>> >network, login with cached credentials, wait 5 minutes then connect PC to LAN
>> >same outcome
>> >Here are 2 KB from Microsoft describing this issue
>> >
>> >http://support.microsoft.com/default.aspx/kb/835261
>> >
>> >http://support.microsoft.com/kb/291377/

>> --
>> Dave Mills
>> There are 10 types of people, those that understand binary and those that don't.
>> .
>>

--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
 
Reply With Quote
 
RW
Guest
Posts: n/a

 
      01-08-2010
What VPN client are you using? In our case this is pretty much consistent
when ANY user connects via VPN map drives are not accessible for up to 15
minutes and then all start working. I might repeat myself but this can be
reproduce in LAN as well where if I unplug PC from network she is shut down
and boot up still unplug from LAN, login with cache credential, wait 5
minutes then connect to LAN _ same issue drives not accessible for up to 15
minutes so I think my question about vpn client is not going to help here but
was just courious



"DaveMills" wrote:

> I have VPN clients (a few) and am not aware of this issue. I also use a VPN
> client to connect to the LAN. I have not had a noticeable problem. If I log in
> then no mapped drives are able to connect because the shares are not available.
> This is expected. If I then connect the VPN the mapped drives remain
> disconnected but the become available if I use them by double clicking the
> drive.
>
> I have seen once or twice a difficulty is re-connecting but is quite rare and I
> have never worked out why as the problem went away.
>
> I will look out for further occupancies to see if it fits your description.
> Mostly though I connect from a home PC and use the UNC/DFS names directly rather
> than via mapped drives.
>
>
>
> On Wed, 18 Nov 2009 09:01:01 -0800, RW <> wrote:
>
> >all our clients are XP SP3 and this is still happening, I have case open for
> >this with Microsoft and they pretty much confirmed this is how it works, I
> >just can't belive that other people who use DFS and experiancing samething
> >are OK with hwo it works. I'm waiting for Microsoft support to give me some
> >work around meanwhile I'm posting here to see how others are dealing with
> >this?
> >For people were majority of clients are desktop in LAN this might not be a
> >problem but for those who have lot of mobile clients and users accesing VPN
> >this is a problem and in my case it is unacceptable that this works like this.
> >
> >I can see 2 ways to work this around 1) modify in registry or GPO how often
> >client checks and builds SPC cache table, well this one won't work because
> >min valid timeframe is 15 minutes
> >option 2) I need some sort of script to run at VPN logon to force SPC cache
> >to be update when VPN is established. So far did not find one.
> >
> >is there anyone else who have this problem?
> >
> >"DaveMills" wrote:
> >
> >> The first article applies only to pre-sp2 systems. Are you system pre-xp SP2. If
> >> so why not apply the SP.
> >>
> >> On Tue, 17 Nov 2009 14:13:01 -0800, RW <> wrote:
> >>
> >> >We have recently implemented DFS domain based while for most part all works
> >> >well there is one problem we are facing and have no idea how to work around
> >> >this. Here is what's happening which BTW is unacceptable when A user starts
> >> >up laptop offline with cached credentials then after X minutes connects VPN
> >> >at first all shared drives based on DFS are not accessible and user have to
> >> >wait sometimes up to 15 minutes and then she or he can access drives, I found
> >> >these 2 articles which describes how DFS works and this also explains 100%
> >> >why we having this issue, it is not a bug but it is by design! which is even
> >> >more frustrating knowing that this is how it works, so my question for others
> >> >is how do you live with that, is this acceptable for your organization that
> >> >end user connecting VPN have to wait up to 15 minutes (most, sometimes less)
> >> >to get to resources.
> >> >BTW this can be reproduce in the LAN too if I start up PC disconnected from
> >> >network, login with cached credentials, wait 5 minutes then connect PC to LAN
> >> >same outcome
> >> >Here are 2 KB from Microsoft describing this issue
> >> >
> >> >http://support.microsoft.com/default.aspx/kb/835261
> >> >
> >> >http://support.microsoft.com/kb/291377/
> >> --
> >> Dave Mills
> >> There are 10 types of people, those that understand binary and those that don't.
> >> .
> >>

> --
> Dave Mills
> There are 10 types of people, those that understand binary and those that don't.
> .
>

 
Reply With Quote
 
DaveMills
Guest
Posts: n/a

 
      01-09-2010
On Fri, 8 Jan 2010 09:43:01 -0800, RW <> wrote:

>What VPN client are you using? In our case this is pretty much consistent
>when ANY user connects via VPN map drives are not accessible for up to 15
>minutes and then all start working. I might repeat myself but this can be
>reproduce in LAN as well where if I unplug PC from network she is shut down
>and boot up still unplug from LAN, login with cache credential, wait 5
>minutes then connect to LAN _ same issue drives not accessible for up to 15
>minutes so I think my question about vpn client is not going to help here but


You are probably correct it is not a VPN issue but something else. I simply use
the built in XP client to connect.

>was just courious
>
>
>
>"DaveMills" wrote:
>
>> I have VPN clients (a few) and am not aware of this issue. I also use a VPN
>> client to connect to the LAN. I have not had a noticeable problem. If I log in
>> then no mapped drives are able to connect because the shares are not available.
>> This is expected. If I then connect the VPN the mapped drives remain
>> disconnected but the become available if I use them by double clicking the
>> drive.
>>
>> I have seen once or twice a difficulty is re-connecting but is quite rare and I
>> have never worked out why as the problem went away.
>>
>> I will look out for further occupancies to see if it fits your description.
>> Mostly though I connect from a home PC and use the UNC/DFS names directly rather
>> than via mapped drives.
>>
>>
>>
>> On Wed, 18 Nov 2009 09:01:01 -0800, RW <> wrote:
>>
>> >all our clients are XP SP3 and this is still happening, I have case open for
>> >this with Microsoft and they pretty much confirmed this is how it works, I
>> >just can't belive that other people who use DFS and experiancing samething
>> >are OK with hwo it works. I'm waiting for Microsoft support to give me some
>> >work around meanwhile I'm posting here to see how others are dealing with
>> >this?
>> >For people were majority of clients are desktop in LAN this might not be a
>> >problem but for those who have lot of mobile clients and users accesing VPN
>> >this is a problem and in my case it is unacceptable that this works like this.
>> >
>> >I can see 2 ways to work this around 1) modify in registry or GPO how often
>> >client checks and builds SPC cache table, well this one won't work because
>> >min valid timeframe is 15 minutes
>> >option 2) I need some sort of script to run at VPN logon to force SPC cache
>> >to be update when VPN is established. So far did not find one.
>> >
>> >is there anyone else who have this problem?
>> >
>> >"DaveMills" wrote:
>> >
>> >> The first article applies only to pre-sp2 systems. Are you system pre-xp SP2. If
>> >> so why not apply the SP.
>> >>
>> >> On Tue, 17 Nov 2009 14:13:01 -0800, RW <> wrote:
>> >>
>> >> >We have recently implemented DFS domain based while for most part all works
>> >> >well there is one problem we are facing and have no idea how to work around
>> >> >this. Here is what's happening which BTW is unacceptable when A user starts
>> >> >up laptop offline with cached credentials then after X minutes connects VPN
>> >> >at first all shared drives based on DFS are not accessible and user have to
>> >> >wait sometimes up to 15 minutes and then she or he can access drives, I found
>> >> >these 2 articles which describes how DFS works and this also explains 100%
>> >> >why we having this issue, it is not a bug but it is by design! which is even
>> >> >more frustrating knowing that this is how it works, so my question for others
>> >> >is how do you live with that, is this acceptable for your organization that
>> >> >end user connecting VPN have to wait up to 15 minutes (most, sometimes less)
>> >> >to get to resources.
>> >> >BTW this can be reproduce in the LAN too if I start up PC disconnected from
>> >> >network, login with cached credentials, wait 5 minutes then connect PC to LAN
>> >> >same outcome
>> >> >Here are 2 KB from Microsoft describing this issue
>> >> >
>> >> >http://support.microsoft.com/default.aspx/kb/835261
>> >> >
>> >> >http://support.microsoft.com/kb/291377/
>> >> --
>> >> Dave Mills
>> >> There are 10 types of people, those that understand binary and those that don't.
>> >> .
>> >>

>> --
>> Dave Mills
>> There are 10 types of people, those that understand binary and those that don't.
>> .
>>

--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can't disable write cache for USB drive Lina Windows Vista Hardware 1 10-14-2007 01:50 PM
large system cache netsavy006 Windows Vista Performance 0 05-26-2007 04:53 PM
Readyboost Thomas - Ungfar.dk Windows Vista Performance 6 04-10-2007 02:46 AM
Readyboost cache not created Tim Windows Vista Performance 1 12-15-2006 05:26 PM
Readyboost cache disappears! Dave Johnson Windows Vista Performance 4 12-07-2006 04:25 AM



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59