Inexplicable policy application

  • Thread starter Thread starter Mykhaylo Khodorev
  • Start date Start date
M

Mykhaylo Khodorev

Hi, all
I've met strange GP behaviour. I have several remote branches. Branches
are connected to HQ by VPN. Connection speed are no so high. So, gpresult
shows group policies were applied recently (e.g. 5 minutes ago or later),
but settings are same like were before group policies modification 2 months
ago. When I run gpupdate it shows policies are applied successfully. But
settings don't apply. It's not depend on branch because such situation
occurs with random computers in random branches. I suspect this connected to
slow connection. How to fix it?
Thanks.
Mykhaylo
 
It does sound like slow link detection is causing the problem.

Here are some things you can try:

1. You can enable the "Group Policy slow link detection" settings in GPO
under both locations and set it to 0. This basically add the
GroupPolicyMinTransferRate value to the registry and disabled slow link
detection. This setting is located in GPO under these locations:

(Computer Configuration\Administrative Templates\System\Group Policy)
(User Configuration\Administrative Templates\System\Group Policy)

2. You could manually add the GroupPolicyMinTransferRate Reg_DWORD value
and set it to 0 under HKLM\Software\Policies\Microsoft\Windows\System and
HKCU\Software\Policies\Microsoft\Windows\System.

3. If you enable the GPO settings and this fails to correct the problem
(because GPO still fails to apply this setting to the registry) then it
could be due to ICMP packets being blocked. We need Ping to apply GPO.

4. If ICMP works it could be the default packet that is sent for slow link
detection is being fragmented and the routers are dropping the fragment.
The default packet size is 2048 bytes. If the routers are dropping ICMP
fragments then GPO will fail to apply. If you suspect the routers might be
dropping fragmented ICMP packets then try adding the "PingBufferSize"
REG_DWORD value with a size (in decimal) that is slightly smaller than the
max you can ping without fragmenting. This setting is discussed in Q816045.

816045 A Fast Link May Be Detected as a Slow Link Because of Network ICMP
http://support.microsoft.com/?id=816045
 
It really helped :-) Thanks a lot
Mykhaylo

David Everett said:
It does sound like slow link detection is causing the problem.

Here are some things you can try:

1. You can enable the "Group Policy slow link detection" settings in GPO
under both locations and set it to 0. This basically add the
GroupPolicyMinTransferRate value to the registry and disabled slow link
detection. This setting is located in GPO under these locations:

(Computer Configuration\Administrative Templates\System\Group Policy)
(User Configuration\Administrative Templates\System\Group Policy)

2. You could manually add the GroupPolicyMinTransferRate Reg_DWORD value
and set it to 0 under HKLM\Software\Policies\Microsoft\Windows\System and
HKCU\Software\Policies\Microsoft\Windows\System.

3. If you enable the GPO settings and this fails to correct the problem
(because GPO still fails to apply this setting to the registry) then it
could be due to ICMP packets being blocked. We need Ping to apply GPO.

4. If ICMP works it could be the default packet that is sent for slow
link
detection is being fragmented and the routers are dropping the fragment.
The default packet size is 2048 bytes. If the routers are dropping ICMP
fragments then GPO will fail to apply. If you suspect the routers might
be
dropping fragmented ICMP packets then try adding the "PingBufferSize"
REG_DWORD value with a size (in decimal) that is slightly smaller than the
max you can ping without fragmenting. This setting is discussed in
Q816045.

816045 A Fast Link May Be Detected as a Slow Link Because of Network ICMP
http://support.microsoft.com/?id=816045

--
David Everett
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no
rights.
Click to expand...
 
Back
Top