При наличии Active Directory с несколькими сайтами возникают проблемы с медленными объектами групповой политики обнаружения ссылок. Мы хотим использовать обнаружение медленного соединения на ноутбуках, которые подключаются через согласованную WAN (MPLS 4-Мбит / с) к основному сайту (с DC). Проблема в том, что обнаружение медленного соединения не работает должным образом, поэтому медленное соединение не распознается. Клиентская машина - Windows 7, DC - Win Server 2008 R2.
Обнаружение медленного соединения настраивается для компьютера и пользователя с помощью политик:
Computer Configuration\Policies\Administrative Templates\System\Group Policy\Group Policy slow link detection
User Configuration\Policies\Administrative Templates\System\Group Policy\Group Policy slow link detection
Оба активированы и установлены на 15000 кбит / с. Этот параметр активирован на клиентах и работает нормально. Но, похоже, расчет пропускной способности делает что-то странное.
При анализе загрузки через xbootmgr / xperf я вижу, что для Компьютерный GPO обнаружен медленный канал связи с 12618 кбит / с (<15000 кбит / с), поэтому IsSlowLink верен -> все в порядке.
Но для Пользовательские GPO обнаруженная полоса пропускания 228711 кбит / с. Там есть нет медленной ссылки обнаружен и, например, "Перенаправление папки" обрабатывается.
Я не нашел причин для этой огромной разницы, сетевой маршрут не меняется между обработкой политики компьютера и обработки политики пользователя. Возможно ли, что NLA использует какой-либо кэшированный контент для определения доступной полосы пропускания? У нас есть Wan-Optimizer русла между двумя точками, возможно ли, что он оптимизирует обнаружение полосы пропускания NLA? Есть идеи, где посмотреть, как рассчитывалась возвращенная пропускная способность?
Есть Статья в TechNet описывающий, как рассчитывается пропускная способность. Это немного устарело, но я сомневаюсь, что существенно изменилось.
Новый механизм принимает форму измерения времени ответа от последовательности эхо-запросов TCP / IP от клиентского компьютера к серверу для определения средней скорости передачи в килобитах в секунду (кбит / с). Клиент проверяет сервер трижды с 0 байтами и трижды с 2048 байтами. Если время ответа на любой из эхо-запросов составляет менее 10 миллисекунд (мс), ссылка автоматически считается быстрой. В противном случае средняя скорость передачи рассчитывается путем усреднения разницы между первым (0 байт) и вторым (2048 байт) временами проверки связи. Если скорость передачи ниже, чем значение по умолчанию или значение, определенное администратором, соединение считается медленным.
Windows 2000 использует следующую формулу: LinkSpeed = 32000 / ulTotal.
В этой формуле ulTotal - это среднее значение разницы между временем первого и второго эхо-запросов.
Таблица в качестве примера, которую они показывают в статье, получена из USERENV, показывающая фактическое время приема-передачи. Это заставляет меня думать, что эта информация, вероятно (все еще) регистрируется, если вы включите ведение журнала USERENV. Это может не решить вашу проблему, но, по крайней мере, вы сможете увидеть, на каких цифрах Windows основывает обнаружение медленного соединения.
Включение ведения журнала USERENV в Windows Vista / 7 не сильно изменилось со времен XP. Инструкции можно найти Вот. Я предупреждаю вас, что этот журнал очень многословен (думаю, -vvvvvvvvvvv) и исторически сложен для понимания. Простой поиск в Google по этой теме даст множество советов по ее продвижению.
Надеюсь, это поможет вам начать работу!