Назад | Перейти на главную страницу

Ожидание службы профилей пользователей - навсегда

У меня есть два сервера AD, разделенных T1.

Местоположение A, в котором находится основной сервер AD / DNS / Roaming Profiles, - это подсеть 192.168.0.

Местоположение B, которое является вторичным сервером AD (я пытаюсь настроить, но ...) находится в подсети 192.168.1.

Я понимаю, что это может быть проблема с DNS. Единственный DNS-сервер, который я назначил этой подсети через DHCP на Sonicwall, - это сервер AD в Location A. Я получил положительные результаты тестов DNS в ping и nslookup.

Я присоединился, не присоединился, снова присоединился к домену.

All Event Viewer сообщает мне, что вход в систему занимает слишком много времени, это заняло 931 секунду, требуется много времени, чтобы выйти из системы, и не удается загрузить ресурс csc ...

Просто профиль слишком велик для Т1? Я включил перенаправление папок - все еще длится вечность, застрял в «ожидании службы профиля пользователя».

Обратите внимание, что это происходит как в Win2k8R2, так и в обычной Windows 7 в Location B.

Теперь происходит и в Location A ... [Возможно, исправлено - это может быть просто необработанный размер профиля, даже при включенном перенаправлении папок]

Как лучше всего решить эту проблему?

Я бы не стал делать никаких предположений о причине, пока вы не получите более подробную информацию о том, что на самом деле происходит. Если вы видите медленный вход в систему в обоих местах, тогда сложно полностью винить инфраструктуру WAN (хотя я уверен, что в этом есть некоторая вина ... T1 привык чувствовать так быстро ... теперь мне просто больно).

Любой, кто меня знает, сможет подпевать здесь: возьмите сниффер и посмотрите, что передается по сети. Наблюдение за тем, какой объем трафика перемещается во время этих сценариев медленного входа в систему (неважно, каков состав трафика - просто общее количество), расскажет вам массу о проблеме. Если вы видите небольшой поток трафика, вы можете начать расследование. Зачем вы видите только тонкую струйку. Если вы видите наводнение, вы можете начать выяснять, как уменьшить размер отправляемых данных. Однако, пока вы не узнаете, что происходит за кулисами, вы просто наносите удары в темноте. На мой взгляд, журналы событий на клиенте и сервере не особенно полезны в этом сценарии.

Мне не ясно, работает ли ваш сервер, на котором размещен общий ресурс перемещаемых профилей, W2K8 (или новее) или нет. Если это ваша Windows 7 / W2K8R2, клиенты должны использовать SMB2 и выполнять операции конвейерной обработки для лучшего использования T1. Сказав это, перемещаемые профили любого размера (особенно если каталог AppData заполнен мусором, который Flash Player и Java Runtime Environment любят складывать туда) будет проблематично синхронизировать через T1. Вы можете перенаправить вещи из профиля и сделать его довольно маленьким, но это все равно может быть болезненно.

Возьмите копию Wireshark, выполните зеркальное отображение порта коммутатора, к которому подключен тестовый клиент, и приступайте к сниффингу. Вы сразу сможете получить некоторую информацию об общем объеме трафика. Затем вы можете начать углубляться в детали.