|
Thanks
Steve! That comes closer than anything I have seen and I did not find the
article in previous searches. Some things are still amiss:
- The article was reviewed in November 2003 and only
shows as being applicable to Windows 2000, but we are seeing the problems on XP
clients
- If the first ping with a zero byte payload is successful, the
rest of the checks are skipped. This caused some confusion during analysis since
test machines in the office were not experiencing the same problems (there first
ping was less than 10 ms).
- We didn't see any 4,096 ping packets being generated. Perhaps
this doesn't apply to XP or the ping failures were disrupting the planned
routine.
- It doesn't describe the weird Site GPO processing that we
observed.
Hopefully Microsoft will update the article in the future to expand on
the behavior and make it applicable to XP clients.
For
those with Cisco VPN Concentrators - on our VPN 3000 series concentrator we
found the setting here:
Configuration->Policy Management->Traffic
Management->Filters->Private
Select Modify Filter and make sure that the Fragments (i.e.
- allow fragmented packets) options is enabled. It was not on our Concentrator.
I cannot confirm that the default is not-enabled since the box has been in
production use for over 4 years now and someone could have modified it. The
Public filter has the same options, but it already had Fragments
enabled.
Jeff
----- Original Message -----
Sent: Wednesday, June 02, 2004 10:32
PM
Subject: RE: [ActiveDir] Group Policy
at the Site Level With Remote VPN Us ers - Wrong Site Applied
Darren - Thanks very much for your suggestion. It didn't solve the
issue, but it did provide some keywords that helped in further Google
searches.
Part of the cause ended up being discarding of large ICMP packets by
our Cisco VPN Concentrator. In preparation for processing Group Policy,
workstations send a series of ping packets to a domain controller that
have payloads of both 0 and 2048 bytes. The 0 byte packets got through fine,
but the 2048 byte packets got dropped because they are larger than the MTU
and are thus fragmented. These pings are used to determine if you have a
slow link or fast link. Enabling fragmented packets to pass the VPN
Concentrator did the trick, and now Site GPs are being applied along with
other GPs.
I
still have no clue why the GP processing ended up pulling the logon script
from a different site. My suspicion is that the slow link processing code
doesn't know how to cleanly deal with failed responses from only some of the
ping packets. Whoever coded this section may have assumed that either all
would succeed and return a response time value or none would succeed. This
is only speculation because the Userenv.log file didn't reflect any
processing of group policy even though it clearly had
occurred.
When I have a few minutes I plan on submitting a detailed write-up to
MyITForum so that others will hopefully benefit from our research. Even
knowing most of the answers I couldn't find anything covering this situation
in the KB articles. Thanks again!
Jeff
Jeff-
It's hard to say what is going on here. Group Policy uses whatever
site information is cached on the workstation to determine which
site-linked GPOs to process. In other words, the issue is that when this
machine connects to the corp. network, it is not following the normal site
affinity process to locate a DC to authenticate with. Given the random
nature of what you're seeing, I suspect this means that the workstation's
subnet is not being correctly associated with a site, and so its querying
any available DC.
I would check the registry under
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName
to see what site is being cached there after you VPN into the
network. This could be a timing issue where the site information is
not correctly populated on the workstation by the time GPO processing
cycle kicks off.
-----Original Message-----
From:
[EMAIL PROTECTED] on behalf of Jeff Salisbury
Sent: Fri 5/28/2004 2:51 PM
To:
'[EMAIL PROTECTED]'
Cc:
Subject:
[ActiveDir] Group Policy at the Site Level With Remote VPN Users - Wrong
Site Applied
We have our logon scripts in GPOs tied to AD Sites in
our Win2K domain, with each site having its own GPO that calls a script
tailored to the locally available file shares. This has worked
exceedingly well, until...
Based on some great input from another
list reader we started testing a feature in the Cisco VPN Client that
forces a user to log off his/her system as soon as the VPN is
established. When the user logs back on to the machine then she/he is
authenticating with the domain. We want this functionality so that the
cached copy of the user's password is updated if he/she changed it
recently, and so that the user's logon script runs to map drives, check
A-V signatures, etc.
When I tried this from my home network
(192.168.2.0/24) I connected to our corporate network in L.A. (Compton)
and my notebook was assigned an IP address from the L.A. facility's
internal network (172.16.0.0/21), which is the IP subnet associated with
the Compton-Site in AD. After the logoff, I would have expected the
Compton-Site logon script to run and map my drives. Instead, Group
Policy was applied from a domain controller in Shanghai China
(172.16.56.0/22) and my drives were mapped by their logon script to
their servers. My colleague had a similar experience, except that he
received policy from and was mapped to drives in the Singapore AD Site
(172.16.48.0/22).
I ran GPResult to see if I could figure out
what was happening:
RSOP results for BELKIN\<my user name>
on <my machine name> : Logging
Mode
------------------------------------------------------------
OS
Type:
Microsoft Windows XP Professional
OS
Configuration:
Member Workstation
OS
Version:
5.1.2600
Domain
Name:
BELKIN
Domain
Type:
Windows 2000
Site
Name:
compton-site <-- This is what I expected
Roaming
Profile:
Local
Profile:
C:\Documents and Settings\<my user name>
Connected over a slow
link?: No
COMPUTER
SETTINGS
------------------
CN=<my machine
name>,OU=Notebooks,OU=Compton,OU=US,OU=NA,DC=belkin,DC=com
Last time Group Policy was applied: 5/27/2004 at 9:18:37
PM
Group Policy was applied
from: shanghai.belkin.com <--
This DC is in the Shanghai China Site!
Group
Policy slow link threshold: 500
kbps
Applied Group Policy
Objects
-----------------------------
Default Domain Policy
Local Group Policy
The following GPOs were not
applied because they were filtered out
-------------------------------------------------------------------
Shanghai Site Logon Scripts <- There are not logon
scripts tied to the
computer
Filtering: Not Applied (Empty)
The
computer is a part of the following security
groups:
--------------------------------------------------------
<SNIP>
USER
SETTINGS
--------------
CN=<my user
name>,OU=Information
Services,OU=Compton,OU=US,OU=NA,DC=belkin,DC=com
Last time Group Policy was applied: 5/27/2004 at 9:20:20
PM
Group Policy was applied
from: shanghai.belkin.com <--
This DC is in the Shanghai China Site!
Group
Policy slow link threshold: 500
kbps
Applied Group Policy
Objects
-----------------------------
Default Domain Policy
Shanghai Site Logon Scripts <- Here is what mapped the
drives to Shanghai servers
The following GPOs
were not applied because they were filtered out
-------------------------------------------------------------------
Local Group
Policy
Filtering: Not Applied (Empty)
The user
is a part of the following security groups:
----------------------------------------------------
<SNIP>
I looked through Jeremy Moskowitz's great book
(Group Policy, Profiles, and Intellimirror) and on his web site
(www.gpanswers.com), but I can't find any reference to this mystery. My
understanding is that the notebook's IP address would determine what
Site's GP is applied. If the internal address assigned by VPN is used,
then it should apply the Compton-Site policy. It looks like it DID
determine that I was in the Compton site, but went off and
pulled/applied GP from a different site. I have verified that the sites
in AD have the correct subnets assigned to them, with no
overlap.
Has anyone else seen this happen or see what I am
missing? Thanks!
Jeff Salisbury
Network Infrastructure and
Security Manager
Belkin Corporation
Information
Services
310 604-2061
310 604-2022
fax
www.belkin.com
Confidential
This e-mail and any files transmitted with
it are the property
of Belkin Corporation and/or its affiliates, are
confidential,
and are intended solely for the use of the individual
or
entity to whom this e-mail is addressed. If you are not one
of
the named recipients or otherwise have reason to believe
that you have
received this e-mail in error, please notify the
sender and delete this
message immediately from your computer.
Any other use, retention,
dissemination, forwarding, printing
or copying of this e-mail is strictly
prohibited.
|
