VPN, cached credentials and GPs not applying

G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

Hi folks, wonder if this rings any bells ...

We have a large mobile workforce who log onto their laptops locally
using cached credentials and then connect into the network over a Cisco-
based VPN (I.e. no explicit network logon). These users virtually never
come into the office, so we need to make any config changes remotely.

We are trying to push out updated IE homepages through new group
policies. As it is not possible to use policies aligned to groups to do
this (unless someone knows how to update the group membership of cached
credentials?) we were planning to do it via moving the users into new
OUs with the new policies (we need to move from one default homepage to
a number of different ones).

To my understanding this should work over the VPN, with the policies
applying either via periodic refresh or forced gpupdates. However, not
so!

A GPresult shows the correct policies having been applied (and not
applied as appropriate) but the actual verbose gpresult detail shows
that the contents of the new policies have not actually been
incorporated into the users active settings. It will even show active
settings for policies that have been disabled since the laptops were
last on the LAN. Although I'm pretty sure these are asynch changes,
we've tried logging in/out but to no avail.

When these laptops are logged directly into the LAN the policies then do
apply successfully.

This is driving my crazy and causing the business a lot of pain. Can
anyone help out?

many thanks
Darren


--
Darren
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

A couple things to be aware of and some things to try.

How and if Group Policies are applied can be affected by "slow link
detection" that will come into effect on a VPN connection. The link below
explains this more and how to change the settings for it.

http://support.microsoft.com/default.aspx?scid=kb;en-us;227260
http://support.microsoft.com/default.aspx?scid=kb;en-us;227369

The other problem is that user/computer policy may take up to two hours to
refresh and depending on the length of time a user is connected, they may
not have the policy refreshed while logged on. You can change the default
refresh and random period offset for both computer and user configuration
under computer or use configuration administrative templates/system/group
policy. You may want to shorten that significantly [at lease temporally] for
VPN users. Also you will notice other settings under Group Policy [same
place - system/group policy] that you may want to try to implement such as
"registry policy processing" and "IE maintenance policy processing" where
you may want to enable both for "process even is Group Policy objects have
not changed". You may want to run the gpresult and netdiag support tools on
one of the computers after logging on via VPN [over actual wan connection]
to see what it reports. Also when using the built in VPN client there is the
option to logon to the domain under properties/options - include Windows
logon domain which may be worth trying to see if that makes a difference if
that is not being used. Hopefully some of these changes will help. ---
Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;321709 -- gpresult.


"Darren G" <ng@gillman.org.uk> wrote in message
news:MPG.1c0884e5a56c8d479897d9@news.individual.de...
> Hi folks, wonder if this rings any bells ...
>
> We have a large mobile workforce who log onto their laptops locally
> using cached credentials and then connect into the network over a Cisco-
> based VPN (I.e. no explicit network logon). These users virtually never
> come into the office, so we need to make any config changes remotely.
>
> We are trying to push out updated IE homepages through new group
> policies. As it is not possible to use policies aligned to groups to do
> this (unless someone knows how to update the group membership of cached
> credentials?) we were planning to do it via moving the users into new
> OUs with the new policies (we need to move from one default homepage to
> a number of different ones).
>
> To my understanding this should work over the VPN, with the policies
> applying either via periodic refresh or forced gpupdates. However, not
> so!
>
> A GPresult shows the correct policies having been applied (and not
> applied as appropriate) but the actual verbose gpresult detail shows
> that the contents of the new policies have not actually been
> incorporated into the users active settings. It will even show active
> settings for policies that have been disabled since the laptops were
> last on the LAN. Although I'm pretty sure these are asynch changes,
> we've tried logging in/out but to no avail.
>
> When these laptops are logged directly into the LAN the policies then do
> apply successfully.
>
> This is driving my crazy and causing the business a lot of pain. Can
> anyone help out?
>
> many thanks
> Darren
>
>
> --
> Darren
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

Steven, thanks for the thoughts, but unfortunately I'd already been through a
similar thought process. The problem occurs both with and without a slow
connection. (for general info, are IE maintenance settings affected by slow
links? My understanding is that they aren't.)

And as well as giving policies time to apply through refresh, they have also
been forced via gpupdate (with & without the force option). All to no avail.

My gut feel is that it is something to with either using cached credentials
(seeing as it work when on LAN), but again my understanding is that GPs
should still apply even with cached credentials?

Anybody else any ideas?

Thanks
D

"Steven L Umbach" wrote:

> A couple things to be aware of and some things to try.
>
> How and if Group Policies are applied can be affected by "slow link
> detection" that will come into effect on a VPN connection. The link below
> explains this more and how to change the settings for it.
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;227260
> http://support.microsoft.com/default.aspx?scid=kb;en-us;227369
>
> The other problem is that user/computer policy may take up to two hours to
> refresh and depending on the length of time a user is connected, they may
> not have the policy refreshed while logged on. You can change the default
> refresh and random period offset for both computer and user configuration
> under computer or use configuration administrative templates/system/group
> policy. You may want to shorten that significantly [at lease temporally] for
> VPN users. Also you will notice other settings under Group Policy [same
> place - system/group policy] that you may want to try to implement such as
> "registry policy processing" and "IE maintenance policy processing" where
> you may want to enable both for "process even is Group Policy objects have
> not changed". You may want to run the gpresult and netdiag support tools on
> one of the computers after logging on via VPN [over actual wan connection]
> to see what it reports. Also when using the built in VPN client there is the
> option to logon to the domain under properties/options - include Windows
> logon domain which may be worth trying to see if that makes a difference if
> that is not being used. Hopefully some of these changes will help. ---
> Steve
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;321709 -- gpresult.
>
>
> "Darren G" <ng@gillman.org.uk> wrote in message
> news:MPG.1c0884e5a56c8d479897d9@news.individual.de...
> > Hi folks, wonder if this rings any bells ...
> >
> > We have a large mobile workforce who log onto their laptops locally
> > using cached credentials and then connect into the network over a Cisco-
> > based VPN (I.e. no explicit network logon). These users virtually never
> > come into the office, so we need to make any config changes remotely.
> >
> > We are trying to push out updated IE homepages through new group
> > policies. As it is not possible to use policies aligned to groups to do
> > this (unless someone knows how to update the group membership of cached
> > credentials?) we were planning to do it via moving the users into new
> > OUs with the new policies (we need to move from one default homepage to
> > a number of different ones).
> >
> > To my understanding this should work over the VPN, with the policies
> > applying either via periodic refresh or forced gpupdates. However, not
> > so!
> >
> > A GPresult shows the correct policies having been applied (and not
> > applied as appropriate) but the actual verbose gpresult detail shows
> > that the contents of the new policies have not actually been
> > incorporated into the users active settings. It will even show active
> > settings for policies that have been disabled since the laptops were
> > last on the LAN. Although I'm pretty sure these are asynch changes,
> > we've tried logging in/out but to no avail.
> >
> > When these laptops are logged directly into the LAN the policies then do
> > apply successfully.
> >
> > This is driving my crazy and causing the business a lot of pain. Can
> > anyone help out?
> >
> > many thanks
> > Darren
> >
> >
> > --
> > Darren
>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

I believe that the slow link detection is coming into play... I forget the
default setting (was it 500k?), but if the connection is detected as less
than the 'threshhold link speed', the link is detected as slow. The
sure-fire way of getting the policies to take effect over what would be
considered a slow link would be to change the default slow link speed to a
lower number, if not 0. That will mean that all links are detected as fast.
But if you're deploying software via GPO, and you happen to come across a
dialup user, the software install process will take as long as it takes to
transfer the msi package over a phone line---tedious!.

I would double check the slow link detection speed first--that may solve the
problem, but then again, it might not.

HTH

Ken

"Darren G" <Darren G@discussions.microsoft.com> wrote in message
news:5CC0E5B0-BBDE-442C-9215-2EF4C5722275@microsoft.com...
> Steven, thanks for the thoughts, but unfortunately I'd already been
> through a
> similar thought process. The problem occurs both with and without a slow
> connection. (for general info, are IE maintenance settings affected by
> slow
> links? My understanding is that they aren't.)
>
> And as well as giving policies time to apply through refresh, they have
> also
> been forced via gpupdate (with & without the force option). All to no
> avail.
>
> My gut feel is that it is something to with either using cached
> credentials
> (seeing as it work when on LAN), but again my understanding is that GPs
> should still apply even with cached credentials?
>
> Anybody else any ideas?
>
> Thanks
> D
>
> "Steven L Umbach" wrote:
>
>> A couple things to be aware of and some things to try.
>>
>> How and if Group Policies are applied can be affected by "slow link
>> detection" that will come into effect on a VPN connection. The link below
>> explains this more and how to change the settings for it.
>>
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;227260
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;227369
>>
>> The other problem is that user/computer policy may take up to two hours
>> to
>> refresh and depending on the length of time a user is connected, they may
>> not have the policy refreshed while logged on. You can change the default
>> refresh and random period offset for both computer and user configuration
>> under computer or use configuration administrative templates/system/group
>> policy. You may want to shorten that significantly [at lease temporally]
>> for
>> VPN users. Also you will notice other settings under Group Policy [same
>> place - system/group policy] that you may want to try to implement such
>> as
>> "registry policy processing" and "IE maintenance policy processing" where
>> you may want to enable both for "process even is Group Policy objects
>> have
>> not changed". You may want to run the gpresult and netdiag support tools
>> on
>> one of the computers after logging on via VPN [over actual wan
>> connection]
>> to see what it reports. Also when using the built in VPN client there is
>> the
>> option to logon to the domain under properties/options - include Windows
>> logon domain which may be worth trying to see if that makes a difference
>> if
>> that is not being used. Hopefully some of these changes will help. ---
>> Steve
>>
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;321709 --
>> gpresult.
>>
>>
>> "Darren G" <ng@gillman.org.uk> wrote in message
>> news:MPG.1c0884e5a56c8d479897d9@news.individual.de...
>> > Hi folks, wonder if this rings any bells ...
>> >
>> > We have a large mobile workforce who log onto their laptops locally
>> > using cached credentials and then connect into the network over a
>> > Cisco-
>> > based VPN (I.e. no explicit network logon). These users virtually
>> > never
>> > come into the office, so we need to make any config changes remotely.
>> >
>> > We are trying to push out updated IE homepages through new group
>> > policies. As it is not possible to use policies aligned to groups to
>> > do
>> > this (unless someone knows how to update the group membership of cached
>> > credentials?) we were planning to do it via moving the users into new
>> > OUs with the new policies (we need to move from one default homepage to
>> > a number of different ones).
>> >
>> > To my understanding this should work over the VPN, with the policies
>> > applying either via periodic refresh or forced gpupdates. However, not
>> > so!
>> >
>> > A GPresult shows the correct policies having been applied (and not
>> > applied as appropriate) but the actual verbose gpresult detail shows
>> > that the contents of the new policies have not actually been
>> > incorporated into the users active settings. It will even show active
>> > settings for policies that have been disabled since the laptops were
>> > last on the LAN. Although I'm pretty sure these are asynch changes,
>> > we've tried logging in/out but to no avail.
>> >
>> > When these laptops are logged directly into the LAN the policies then
>> > do
>> > apply successfully.
>> >
>> > This is driving my crazy and causing the business a lot of pain. Can
>> > anyone help out?
>> >
>> > many thanks
>> > Darren
>> >
>> >
>> > --
>> > Darren
>>
>>
>>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

OK. If you have not tried this, I would logon to a computer with cached
credentials and then logon to the VPN [via it's lan IP address] with domain
credentials, but through the LAN to see how policy is applied. That would
certainly rule out a slow link. Also try logging in to the computer with
local credentials and then connect to the VPN via domain credentials
[possibly with a domain user account that does not have cached credentials
on that computer] to see what happens which would bypass using cached domain
credentials. --- Steve


"Darren G" <Darren G@discussions.microsoft.com> wrote in message
news:5CC0E5B0-BBDE-442C-9215-2EF4C5722275@microsoft.com...
> Steven, thanks for the thoughts, but unfortunately I'd already been
> through a
> similar thought process. The problem occurs both with and without a slow
> connection. (for general info, are IE maintenance settings affected by
> slow
> links? My understanding is that they aren't.)
>
> And as well as giving policies time to apply through refresh, they have
> also
> been forced via gpupdate (with & without the force option). All to no
> avail.
>
> My gut feel is that it is something to with either using cached
> credentials
> (seeing as it work when on LAN), but again my understanding is that GPs
> should still apply even with cached credentials?
>
> Anybody else any ideas?
>
> Thanks
> D
>
> "Steven L Umbach" wrote:
>
>> A couple things to be aware of and some things to try.
>>
>> How and if Group Policies are applied can be affected by "slow link
>> detection" that will come into effect on a VPN connection. The link below
>> explains this more and how to change the settings for it.
>>
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;227260
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;227369
>>
>> The other problem is that user/computer policy may take up to two hours
>> to
>> refresh and depending on the length of time a user is connected, they may
>> not have the policy refreshed while logged on. You can change the default
>> refresh and random period offset for both computer and user configuration
>> under computer or use configuration administrative templates/system/group
>> policy. You may want to shorten that significantly [at lease temporally]
>> for
>> VPN users. Also you will notice other settings under Group Policy [same
>> place - system/group policy] that you may want to try to implement such
>> as
>> "registry policy processing" and "IE maintenance policy processing" where
>> you may want to enable both for "process even is Group Policy objects
>> have
>> not changed". You may want to run the gpresult and netdiag support tools
>> on
>> one of the computers after logging on via VPN [over actual wan
>> connection]
>> to see what it reports. Also when using the built in VPN client there is
>> the
>> option to logon to the domain under properties/options - include Windows
>> logon domain which may be worth trying to see if that makes a difference
>> if
>> that is not being used. Hopefully some of these changes will help. ---
>> Steve
>>
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;321709 --
>> gpresult.
>>
>>
>> "Darren G" <ng@gillman.org.uk> wrote in message
>> news:MPG.1c0884e5a56c8d479897d9@news.individual.de...
>> > Hi folks, wonder if this rings any bells ...
>> >
>> > We have a large mobile workforce who log onto their laptops locally
>> > using cached credentials and then connect into the network over a
>> > Cisco-
>> > based VPN (I.e. no explicit network logon). These users virtually
>> > never
>> > come into the office, so we need to make any config changes remotely.
>> >
>> > We are trying to push out updated IE homepages through new group
>> > policies. As it is not possible to use policies aligned to groups to
>> > do
>> > this (unless someone knows how to update the group membership of cached
>> > credentials?) we were planning to do it via moving the users into new
>> > OUs with the new policies (we need to move from one default homepage to
>> > a number of different ones).
>> >
>> > To my understanding this should work over the VPN, with the policies
>> > applying either via periodic refresh or forced gpupdates. However, not
>> > so!
>> >
>> > A GPresult shows the correct policies having been applied (and not
>> > applied as appropriate) but the actual verbose gpresult detail shows
>> > that the contents of the new policies have not actually been
>> > incorporated into the users active settings. It will even show active
>> > settings for policies that have been disabled since the laptops were
>> > last on the LAN. Although I'm pretty sure these are asynch changes,
>> > we've tried logging in/out but to no avail.
>> >
>> > When these laptops are logged directly into the LAN the policies then
>> > do
>> > apply successfully.
>> >
>> > This is driving my crazy and causing the business a lot of pain. Can
>> > anyone help out?
>> >
>> > many thanks
>> > Darren
>> >
>> >
>> > --
>> > Darren
>>
>>
>>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

Thanks for the ideas guys. As originally suggested, and contrary to my
original response, it was a slow link issue, but was not quite that straight
forward. In case it helps anybody else in future, this is a sumamry of my
findings...

The problem occured on a machine that, according to GPResult & GPMC, was not
on a slow link and on a policy that from all docuementation I could find is
not meant to be affected by slow links. However as soon as it was put on a
faster LAN connection (after havinbg logged in locally with cached
credentials) or slow link detection disabled, the problem disappeared. QED.

I think the moral to this story (once again) is to ignore what the tools are
reporting and verify things yourself! I really should know better by now!!

Thanks again for the help.

Darren

"Ken B" wrote:

> I believe that the slow link detection is coming into play... I forget the
> default setting (was it 500k?), but if the connection is detected as less
> than the 'threshhold link speed', the link is detected as slow. The
> sure-fire way of getting the policies to take effect over what would be
> considered a slow link would be to change the default slow link speed to a
> lower number, if not 0. That will mean that all links are detected as fast.
> But if you're deploying software via GPO, and you happen to come across a
> dialup user, the software install process will take as long as it takes to
> transfer the msi package over a phone line---tedious!.
>
> I would double check the slow link detection speed first--that may solve the
> problem, but then again, it might not.
>
> HTH
>
> Ken
>
> "Darren G" <Darren G@discussions.microsoft.com> wrote in message
> news:5CC0E5B0-BBDE-442C-9215-2EF4C5722275@microsoft.com...
> > Steven, thanks for the thoughts, but unfortunately I'd already been
> > through a
> > similar thought process. The problem occurs both with and without a slow
> > connection. (for general info, are IE maintenance settings affected by
> > slow
> > links? My understanding is that they aren't.)
> >
> > And as well as giving policies time to apply through refresh, they have
> > also
> > been forced via gpupdate (with & without the force option). All to no
> > avail.
> >
> > My gut feel is that it is something to with either using cached
> > credentials
> > (seeing as it work when on LAN), but again my understanding is that GPs
> > should still apply even with cached credentials?
> >
> > Anybody else any ideas?
> >
> > Thanks
> > D
> >
> > "Steven L Umbach" wrote:
> >
> >> A couple things to be aware of and some things to try.
> >>
> >> How and if Group Policies are applied can be affected by "slow link
> >> detection" that will come into effect on a VPN connection. The link below
> >> explains this more and how to change the settings for it.
> >>
> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;227260
> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;227369
> >>
> >> The other problem is that user/computer policy may take up to two hours
> >> to
> >> refresh and depending on the length of time a user is connected, they may
> >> not have the policy refreshed while logged on. You can change the default
> >> refresh and random period offset for both computer and user configuration
> >> under computer or use configuration administrative templates/system/group
> >> policy. You may want to shorten that significantly [at lease temporally]
> >> for
> >> VPN users. Also you will notice other settings under Group Policy [same
> >> place - system/group policy] that you may want to try to implement such
> >> as
> >> "registry policy processing" and "IE maintenance policy processing" where
> >> you may want to enable both for "process even is Group Policy objects
> >> have
> >> not changed". You may want to run the gpresult and netdiag support tools
> >> on
> >> one of the computers after logging on via VPN [over actual wan
> >> connection]
> >> to see what it reports. Also when using the built in VPN client there is
> >> the
> >> option to logon to the domain under properties/options - include Windows
> >> logon domain which may be worth trying to see if that makes a difference
> >> if
> >> that is not being used. Hopefully some of these changes will help. ---
> >> Steve
> >>
> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;321709 --
> >> gpresult.
> >>
> >>
> >> "Darren G" <ng@gillman.org.uk> wrote in message
> >> news:MPG.1c0884e5a56c8d479897d9@news.individual.de...
> >> > Hi folks, wonder if this rings any bells ...
> >> >
> >> > We have a large mobile workforce who log onto their laptops locally
> >> > using cached credentials and then connect into the network over a
> >> > Cisco-
> >> > based VPN (I.e. no explicit network logon). These users virtually
> >> > never
> >> > come into the office, so we need to make any config changes remotely.
> >> >
> >> > We are trying to push out updated IE homepages through new group
> >> > policies. As it is not possible to use policies aligned to groups to
> >> > do
> >> > this (unless someone knows how to update the group membership of cached
> >> > credentials?) we were planning to do it via moving the users into new
> >> > OUs with the new policies (we need to move from one default homepage to
> >> > a number of different ones).
> >> >
> >> > To my understanding this should work over the VPN, with the policies
> >> > applying either via periodic refresh or forced gpupdates. However, not
> >> > so!
> >> >
> >> > A GPresult shows the correct policies having been applied (and not
> >> > applied as appropriate) but the actual verbose gpresult detail shows
> >> > that the contents of the new policies have not actually been
> >> > incorporated into the users active settings. It will even show active
> >> > settings for policies that have been disabled since the laptops were
> >> > last on the LAN. Although I'm pretty sure these are asynch changes,
> >> > we've tried logging in/out but to no avail.
> >> >
> >> > When these laptops are logged directly into the LAN the policies then
> >> > do
> >> > apply successfully.
> >> >
> >> > This is driving my crazy and causing the business a lot of pain. Can
> >> > anyone help out?
> >> >
> >> > many thanks
> >> > Darren
> >> >
> >> >
> >> > --
> >> > Darren
> >>
> >>
> >>
>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

Cool, glad you got it sorted out. Thanks for reporting back your success as
this seems to be a common problem with VPN domain clients and I agree that
things do not always quite work as documentation says it should and the
ultimate test is to try it yourself. --- Steve


"Darren G" <DarrenG@discussions.microsoft.com> wrote in message
news:C7CEE9E1-A205-4FB7-87CB-2E1113A899E1@microsoft.com...
> Thanks for the ideas guys. As originally suggested, and contrary to my
> original response, it was a slow link issue, but was not quite that
> straight
> forward. In case it helps anybody else in future, this is a sumamry of
> my
> findings...
>
> The problem occured on a machine that, according to GPResult & GPMC, was
> not
> on a slow link and on a policy that from all docuementation I could find
> is
> not meant to be affected by slow links. However as soon as it was put on
> a
> faster LAN connection (after havinbg logged in locally with cached
> credentials) or slow link detection disabled, the problem disappeared.
> QED.
>
> I think the moral to this story (once again) is to ignore what the tools
> are
> reporting and verify things yourself! I really should know better by
> now!!
>
> Thanks again for the help.
>
> Darren
>
> "Ken B" wrote:
>
>> I believe that the slow link detection is coming into play... I forget
>> the
>> default setting (was it 500k?), but if the connection is detected as less
>> than the 'threshhold link speed', the link is detected as slow. The
>> sure-fire way of getting the policies to take effect over what would be
>> considered a slow link would be to change the default slow link speed to
>> a
>> lower number, if not 0. That will mean that all links are detected as
>> fast.
>> But if you're deploying software via GPO, and you happen to come across a
>> dialup user, the software install process will take as long as it takes
>> to
>> transfer the msi package over a phone line---tedious!.
>>
>> I would double check the slow link detection speed first--that may solve
>> the
>> problem, but then again, it might not.
>>
>> HTH
>>
>> Ken
>>
>> "Darren G" <Darren G@discussions.microsoft.com> wrote in message
>> news:5CC0E5B0-BBDE-442C-9215-2EF4C5722275@microsoft.com...
>> > Steven, thanks for the thoughts, but unfortunately I'd already been
>> > through a
>> > similar thought process. The problem occurs both with and without a
>> > slow
>> > connection. (for general info, are IE maintenance settings affected by
>> > slow
>> > links? My understanding is that they aren't.)
>> >
>> > And as well as giving policies time to apply through refresh, they have
>> > also
>> > been forced via gpupdate (with & without the force option). All to no
>> > avail.
>> >
>> > My gut feel is that it is something to with either using cached
>> > credentials
>> > (seeing as it work when on LAN), but again my understanding is that GPs
>> > should still apply even with cached credentials?
>> >
>> > Anybody else any ideas?
>> >
>> > Thanks
>> > D
>> >
>> > "Steven L Umbach" wrote:
>> >
>> >> A couple things to be aware of and some things to try.
>> >>
>> >> How and if Group Policies are applied can be affected by "slow link
>> >> detection" that will come into effect on a VPN connection. The link
>> >> below
>> >> explains this more and how to change the settings for it.
>> >>
>> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;227260
>> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;227369
>> >>
>> >> The other problem is that user/computer policy may take up to two
>> >> hours
>> >> to
>> >> refresh and depending on the length of time a user is connected, they
>> >> may
>> >> not have the policy refreshed while logged on. You can change the
>> >> default
>> >> refresh and random period offset for both computer and user
>> >> configuration
>> >> under computer or use configuration administrative
>> >> templates/system/group
>> >> policy. You may want to shorten that significantly [at lease
>> >> temporally]
>> >> for
>> >> VPN users. Also you will notice other settings under Group Policy
>> >> [same
>> >> place - system/group policy] that you may want to try to implement
>> >> such
>> >> as
>> >> "registry policy processing" and "IE maintenance policy processing"
>> >> where
>> >> you may want to enable both for "process even is Group Policy objects
>> >> have
>> >> not changed". You may want to run the gpresult and netdiag support
>> >> tools
>> >> on
>> >> one of the computers after logging on via VPN [over actual wan
>> >> connection]
>> >> to see what it reports. Also when using the built in VPN client there
>> >> is
>> >> the
>> >> option to logon to the domain under properties/options - include
>> >> Windows
>> >> logon domain which may be worth trying to see if that makes a
>> >> difference
>> >> if
>> >> that is not being used. Hopefully some of these changes will
>> >> elp. ---
>> >> Steve
>> >>
>> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;321709 --
>> >> gpresult.
>> >>
>> >>
>> >> "Darren G" <ng@gillman.org.uk> wrote in message
>> >> news:MPG.1c0884e5a56c8d479897d9@news.individual.de...
>> >> > Hi folks, wonder if this rings any bells ...
>> >> >
>> >> > We have a large mobile workforce who log onto their laptops locally
>> >> > using cached credentials and then connect into the network over a
>> >> > Cisco-
>> >> > based VPN (I.e. no explicit network logon). These users virtually
>> >> > never
>> >> > come into the office, so we need to make any config changes
>> >> > remotely.
>> >> >
>> >> > We are trying to push out updated IE homepages through new group
>> >> > policies. As it is not possible to use policies aligned to groups
>> >> > to
>> >> > do
>> >> > this (unless someone knows how to update the group membership of
>> >> > cached
>> >> > credentials?) we were planning to do it via moving the users into
>> >> > new
>> >> > OUs with the new policies (we need to move from one default homepage
>> >> > to
>> >> > a number of different ones).
>> >> >
>> >> > To my understanding this should work over the VPN, with the policies
>> >> > applying either via periodic refresh or forced gpupdates. However,
>> >> > not
>> >> > so!
>> >> >
>> >> > A GPresult shows the correct policies having been applied (and not
>> >> > applied as appropriate) but the actual verbose gpresult detail shows
>> >> > that the contents of the new policies have not actually been
>> >> > incorporated into the users active settings. It will even show
>> >> > active
>> >> > settings for policies that have been disabled since the laptops were
>> >> > last on the LAN. Although I'm pretty sure these are asynch changes,
>> >> > we've tried logging in/out but to no avail.
>> >> >
>> >> > When these laptops are logged directly into the LAN the policies
>> >> > then
>> >> > do
>> >> > apply successfully.
>> >> >
>> >> > This is driving my crazy and causing the business a lot of pain.
>> >> > Can
>> >> > anyone help out?
>> >> >
>> >> > many thanks
>> >> > Darren
>> >> >
>> >> >
>> >> > --
>> >> > Darren
>> >>
>> >>
>> >>
>>
>>
>>