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