VPN, cached credentials and GPs not applying

[Darren G]

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

 

[Steven L Umbach]

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.

 

[Guest]

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

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.

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

 

[Ken B]

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

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

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.

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

 

[Steven L Umbach]

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

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

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.

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

 

[Guest]

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

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

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

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.


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

 

[Steven L Umbach]

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

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

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

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

:

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.


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