У меня много проблем с нашими машинами с Windows XP SP3 (их около пяти, но каждую неделю на подножку этой проблемы попадает еще одна). Им требуется бесконечно (15 минут) для применения пользовательских настроек после того, как наши сотрудники вводят свое имя пользователя и пароль для входа в наш домен. Это происходит только в том случае, если пользователь перезагрузил компьютер, а затем, когда он снова войдет в систему, он зависает навсегда. Перезагрузка и перезагрузка - вот ключевые слова, которые я точно заметил в этой проблеме.
Вот что я тестировал:
Убедитесь, что DNS был настроен так, чтобы указывать на два наших сервера (Server01 и Server02 - контроллеры домена DNS, 01 - основной, а 02 - резервный).
Никаких серьезных изменений в нашей сети не произошло.
Все профили являются локальными, поэтому я удалил локальные профили, которые не используются на тех машинах, которые работают медленно.
Также я попытался включить и отключить функцию «Включить быстрый вход» в GP на локальных машинах. Он не был настроен изначально, и когда я тестировал оба, он заставил компьютер зависнуть при «применении настроек компьютера» примерно на 15 минут. Когда, наконец, добрался до экрана входа в систему, вход в домен был выполнен очень быстро. Однако это не решает мою проблему, и, что еще более неприятно, когда он снова не настроен, теперь все еще требуется навсегда, чтобы применить настройки компьютера.
Я включил журнал userenv, и вот что я вижу, но мой опыт ограничен, и я не уверен, как его точно читать. (см. журнал ниже, это еще не все, потому что он очень длинный)
USERENV (2ec.2f0) 10: 50: 41: 843 LoadUserProfile: LoadUserProfileP успешно
USERENV (2ec.2f0) 10: 50: 41: 843 LoadUserProfile: Успешный возврат. Окончательная информация:
USERENV (2ec.2f0) 10: 50: 41: 843 lpProfileInfo-> Имя пользователя =
USERENV (2ec.2f0) 10: 50: 41: 843 lpProfileInfo-> lpProfilePath = <>
USERENV (2ec.2f0) 10: 50: 41: 843 lpProfileInfo-> dwFlags = 0x0
USERENV (2ec.2f0) 10: 50: 41: 843 LoadUserProfile: Возвращает TRUE. hProfile = <0x818>
USERENV (2ec.2f0) 10: 50: 41: 984 IsSyncForegroundPolicyRefresh: синхронно, причина: NonCachedCredentials
USERENV (2ec.248) 10: 50: 41: 984 IsSyncForegroundPolicyRefresh: синхронно, причина: NonCachedCredentials USERENV (3c4.3dc) 10: 51: 26: 166 LibMain: Имя процесса:
C: \ WINDOWS \ system \ wbem \ wmiprvse.exeUSERENV (2ec.5cc) 11: 05: 08: 741 ProcessGPOs: имя сети 192.168.49.0
USERENV (4a8.888) 11: 05: 08: 804 GetProfileType: Профиль уже загружен.
USERENV (4a8.888) 11: 05: 08: 804 LoadProfileInfo: не удалось запросить центральный профиль с ошибкой 2
USERENV (4a8.888) 11: 05: 08: 804 GetProfileType: ProfileFlags равно 0
Также этой ошибки в файле довольно много:
USERENV (328.5bc) 11: 05: 29: 733 GetUserDNSDomainName: не удалось выдать себя за пользователя
USERENV (328.834) 11: 05: 29: 733 ImpersonateUser: не удалось выдать себя за пользователя с помощью 5.
Я действительно не знаю, что еще делать с моим ограниченным опытом, но я надеюсь, что кто-то может мне помочь. Я чувствую, что имею дело с проблемой, которая намного выше моего уровня, и любые знания, которые я могу получить, исправляя эту проблему, будут потрясающими.
Взгляните на следующий ресурс, он может помочь: http://blogs.technet.com/b/askds/archive/2008/11/11/understanding-how-to-read-a-userenv-log-part-2.aspx
Похоже, это указывает на то, что сторонний инструмент безопасности может вмешиваться. Вы меняли антивирус или брандмауэр?
Сообщаются ли какие-либо ошибки в журнале событий? Особенно после запуска из командной строки "gpupdate / force"?
Сначала я бы попробовал параметр реестра, известный как «BufferPolicyReads».
Этот параметр включен по умолчанию в Windows 7, но должен быть включен в Windows XP.
Если проблема не в этом, следующим шагом будет захват сетевого пакета с помощью Microsoft Network Monitor.
Задержки входа в систему происходят из-за медленного соединения, если гибкая блокировка не предоставляется для файла политики в Windows
http://support.microsoft.com/kb/319440
Registry subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Entry: BufferPolicyReads
Type: DWORD
Value: 1
Проверьте общие сетевые ресурсы или устройства, такие как принтеры, которые больше не существуют или недоступны. Элементы в «Сетевом окружении» также могут быть проблемой. Как указывает @ HopelessN00b, эти вещи создают длительные таймауты и, следовательно, долгое ожидание.
У нас была эта проблема с пользователями, которые подключались к принтерам и / или общим ресурсам в домашних сетях или на клиентских сайтах.
Удалите эти элементы, если они существуют, и снова проверьте время входа в систему.
Это похоже на проблему с DNS. Вы упомянули, что клиенты были настроены на использование контроллеров домена. Вы проверили, что контроллеры домена отвечают на запросы DNS и что все соответствующие записи DNS, как прямые, так и обратные, верны?