Эта страница похоже, подразумевает, что Wireshark может начать захват только после загрузки, но похоже кто-то еще сталкивался с этой проблемой раньше и никуда не денешься.
Это не обязательно должен быть Wireshark, мне просто нужно выяснить, почему некоторые входы в AD в моей сети такие медленные, и для этого, я считаю, мне нужно посмотреть, что на самом деле происходит в сети.
Сбор информации для входа в систему может быть сложной задачей. Есть несколько способов получить эту информацию, но отчасти это зависит от того, насколько воспроизводима проблема. Если это широко распространено, раскрутка виртуальной машины и выполнение сниффинга на хост-машине даст вам то, что вам нужно. Если он ограничен определенными областями или определенными машинами, вам, вероятно, придется настроить span-порт на вашем сетевом коммутаторе и прослушивать с другой машины на том же коммутаторе. Я сделал это обоими способами.
Возможен другой метод - запустить сниффер на все контроллеров домена с фильтром захвата IP-адреса рассматриваемого компьютера. Это не так оптимально, как использование span-порта, но это, по крайней мере, профилирует связь между машиной и DC.
Microsoft Netmon - довольно мощный инструмент для обнаружения проблем со входом в систему Microsoft, хотя, на мой взгляд, пакет декодирования Wireshark в целом оснащен лучше.
Сосредоточение захвата на стороне клиента, вероятно, принесет наибольшие плоды, поскольку захват на стороне контроллера домена будет означать выполнение операций захвата на всех контроллерах домена в сети. (Если у вас только один DC, вам может быть лучше захватить на конце DC, если проблема с клиентами является прерывистой.)
Запуск Wireshark во время загрузки на клиенте кажется мне неподходящим инструментом для работы. Запуск программного обеспечения на клиенте потенциально нарушает конфигурацию клиентского компьютера и может повлиять на результаты. Я бы попытался захватить трафик, не оказывая влияния на поведение клиентского компьютера.
Если у вас есть административный доступ к коммутатору, клиент подключается для настройки сеанса «монитора» («зеркало порта», порта «SPAN» и т. Д.) И захвата с другого компьютера на выделенный порт монитора.
Если у вас нет административного доступа к коммутатору, рассмотрите возможность подключения выделенного компьютера захвата между клиентским компьютером и локальной сетью. Вашему выделенному компьютеру захвата потребуются два физических интерфейса, которые вы должны связать. Затем вы выполняете захват либо на виртуальном интерфейсе моста, либо на одной из физических сетевых адаптеров на выделенной машине захвата.
Сделать такой захват на машине под управлением Windows или Linux довольно просто. На машине Windows это просто включает в себя установку двух сетевых адаптеров в машину захвата, их соединение с помощью встроенной функции моста в графическом интерфейсе Windows и захват на интерфейсе моста. Ситуация похожа на Linux, хотя и без красивого графического интерфейса во многих дистрибутивах.
Я склонен думать, что вы найдете что-то обнюхивающее, но вам нужно понимать, что происходит во время загрузки и входа в систему (DNS используется для обнаружения DC, как членство в сайте AD влияет на запросы DNS и LDAP, как выглядит приложение групповой политики вроде и т. д.), чтобы интерпретировать результаты. Сравнение «рабочей» машины с «нерабочей» является допустимой стратегией, если разница между «рабочим» и «неработающим» не слишком сильно искажает результаты (т. Е. На разных сайтах AD разные OU с применение различных GPO и т. д.).
Не сбрасывайте со счетов возможность выполнения несетевых трассировок на проблемных клиентских компьютерах с помощью инструмента Microsoft / SysInternals «Process Monitor». Его можно настроить для запуска при загрузке и предоставить очень подробный журнал. Если у вас возникла проблема в результате задержки клиентского расширения групповой политики, например, трассировка ProcMon, вероятно, даст вам более точную информацию, чем захват сети.
Вполне возможно, что вы не найдете ответов, наблюдая за трафиком. Хотя существует ряд причин, по которым вход в систему может быть медленным, я обнаружил, что в большинстве случаев это связано с различными видами сетевых сопоставлений, которые недоступны при входе в систему. Чаще всего это сетевой ресурс, который больше не существует. Хотя вы можете наблюдать это через сниффер, это будет очень сложно распознать. Тем не менее, я желаю вам удачи в решении этой слишком распространенной проблемы.
http://blogs.technet.com/b/askds/archive/2009/09/23/so-you-have-a-slow-logon-part-1.aspx
Также есть вторая часть, если вы выполните поиск в этом блоге, вы найдете ее. Не могу разместить здесь две ссылки.
Если клиентами являются Windows XP, я бы рекомендовал включить ведение журнала отладки пользовательской среды. Если клиенты - это Windows Vista или Windows 7, я бы посоветовал посмотреть журнал событий групповой политики.