Общий ресурс NETLOGON отсутствует после установки доменные службы Active Directory на новом полном или доступном только для чтения контроллере домена Windows Server 2008. — Windows Server
Twitter LinkedIn Facebook Адрес электронной почты
- Статья
- Чтение занимает 2 мин
В этой статье описывается временное решение проблемы, возникающее после установки доменные службы Active Directory на новом контроллере домена windows Server 2008 с полным доступом или только для чтения.
Важно!
В статье содержатся сведения об изменении реестра. Перед внесением изменений рекомендуется создать резервную копию реестра. и изучить процедуру его восстановления на случай возникновения проблемы. Для получения дополнительной информации о том, как создать резервную копию, восстановить и изменить реестр, см. Сведения о резервном копировании и восстановлении реестра Windows.
Применяется к: Windows Server 2012 R2
Исходный номер базы знаний: 947022
Симптомы
После установки доменные службы Active Directory на новом полном или доступном только для чтения контроллере домена Windows Server 2008 в существующем домене присутствует общий ресурс SYSVOL. Однако общий ресурс NETLOGON отсутствует на новом контроллере домена.
Примечание.
Эта статья не применяется, если отсутствуют общие папки NETLOGON и SYSVOL.
Причина
Эта проблема возникает, когда служба Netlogon очень быстро считывает флаг SysvolReady в реестре. Затем служба Netlogon пытается поделиться папкой \Windows\SYSVOL\domain\scripts, прежде чем служба репликации файлов NT (NTFRS) создаст эту папку.
Обходной путь
Примечание.
При неправильном изменении реестра с использованием редактора реестра или другого способа могут случиться серьезные проблемы. Для решения этих проблем может потребоваться переустановка операционной системы. Компания Microsoft не может гарантировать, что эти проблемы могут быть решены. Вносите изменения в реестр на ваш страх и риск.
Чтобы обойти эту проблему, задайте для реестра флага SysvolReady значение 0, а затем в реестре снова установите значение 1. Для этого выполните следующие действия:
Щелкните Пуск, затем Выполнить и введите regedit. Затем нажмите ОК.
Найдите следующий подраздел в редакторе реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\ParametersВ области сведений щелкните правой кнопкой мыши флаг SysvolReady и выберите команду «Изменить».
В поле данных «Значение » введите 0 и нажмите кнопку «ОК».
Снова в области сведений щелкните правой кнопкой мыши флаг SysvolReady и выберите команду «Изменить».
В поле Значение введите 1 и нажмите кнопку ОК.
Примечание.
Это приведет к тому, что Netlogon будет совместно использовать SYSVOL, и папка скриптов будет присутствовать.
Проблема, описанная в разделе «Симптомы «, возникает в следующем сценарии:
Сначала NTFRS помещает изменения в следующее расположение:
\Windows\SYSVOL\domain\DO_NOT_REMOVE_NtFrs_PreInstall_DirectoryЗатем NTFRS уведомляет Netlogon о совместном доступе к SYSVOL, задав для записи реестра флага SysvolReady значение 1.
Затем NTFRS перемещает и переименовывает файлы из расположения, упомянутого на шаге 1, в следующую папку:
\Windows\SYSVOL\domainОднако если служба Netlogon очень быстро считывает запись флага SysvolReady в реестре, служба Netlogon попытается поделиться папкой \Windows\SYSVOL\domain\scripts, прежде чем NTFRS создаст эту папку.
Поэтому общий ресурс NETLOGON не создается.
Netlogon где находится папка
Netlogon где находится папка
Где я найду адрес netlogon на контроллере домена Window 2003?
3 ответа
C: WINDOWS SYSVOL домен скрипты
папка сценариев используется совместно с именем NETLOGON
- это по умолчанию установка
- yourdomain – это имя вашего домена.
, если у вас есть DFS, это C:WindowsSYSVOL_DFSRdomainscripts .
Где я найду адрес netlogon на контроллере домена Window 2003?
3 ответа
C: WINDOWS SYSVOL домен скрипты
папка сценариев используется совместно с именем NETLOGON
- это по умолчанию установка
- yourdomain – это имя вашего домена.
, если у вас есть DFS, это C:WindowsSYSVOL_DFSRdomainscripts .
vampoit
Обнаружил, что на главном контроллере домена отсутствуют шары SYSVOL и NETLOGON.
И хорошо что они были на резервном контроллере домена и все пользователи логинились через него.
Видимо какой-то косяк был еще тогда, когда мы восстанавливали погибший контроллер одной из ночей.
На обоих контроллерах Windows Server 2008.
А вчера я менял режим работы леса и домена на 2008, пытаясь решить другую проблему и проблема вскрылась – в «Управлении групповыми политиками» при наведении на любую из политик в «Объекте групповых политик» появлялась ошибка «Не найдено сетевое имя». Новые политики не создавались, отчеты не показывались.
Нашел инструкцию по восстановлению, которая мне и помогла.
Найдена здесь: http://liond.livejournal.com/4293.html
Правда в статье случаи с 2000 и 2003, но вариант для 2003 подходит и для 2008
Копирую сюда авторский текст в немного сокращенном виде и с моими ремарками для моего случая (оригинальный текст можете посмотреть по ссылке):
Итак, чтобы восстановить SYSVOL службы NTFRS я делал следующие шаги:
1. Останавливаем службу ntfrs на всех контроллерах домена.
net stop ntfrs
2. Проверяем наличие папок на всех контроллерах домена.
Если этих папок нет, то создайте их вручную.
На рабочем, резервном контроллере у меня все папки были, а у того у которого отвалились шары отстутствовали вот эти:
SYSVOLdomainPolicies
SYSVOLdomainscripts
Проверка первой ссылки:
linkd “%systemroot%SYSVOLSYSVOLdomain.local”
где domain.local нужно заменить именем своего домена.
Если команда выполнится успешно, то будет выдано сообщение:
Source C:WINDOWSSYSVOLSYSVOLdomain.local is linked to С:WINDOWSSYSVOLdomain
Проверка второй ссылки:
linkd “%systemroot%SYSVOLstaging areasdomain.local”
Если команда выполнится успешно, то будет выдано сообщение:
C:WINDOWSSYSVOLstagingdomain
Если проверка обоих ссылок прошла успешно, то переходим к пункту 5, иначе производим восстановление ссылок на пункте 4.
На «сбойном» контроллере обе ссылки были кривые. У одной доп. буква а в конце, у второй символ -.
На «рабочем» была также с доп.символом одна из ссылок, вторая была нормальная.
Тем не менее внимательно выполнил пункт 4 для обоих контроллеров
4. Восстанавливаем ссылки с помощью утилиты linkd.
linkd “C:WINDOWSsysvolsysvoldomain.local” %systemroot%sysvoldomain
linkd “C:WINDOWSsysvolstaging areasdomain.local” %systemroot%sysvolstagingdomain
и снова повторяем пункт 3.
5. Редактируем ключи в реестре контроллеров домена.
Для корневого контроллера домена:
создаём параметры типа DWord с именем BurFlags и со значением D4 в разделах:
HKEY_LOCAL_MACHINESYSTEMCurrentControl SetServicesNtFrsParametersCumulative Replica SetsGUID
HKEY_LOCAL_MACHINESYSTEMCurrentControl SetServicesNtFrsParametersReplica SetsGUID
где вместо GUID у вас имеется своя последовательность букв и цифр, разделённых дефисами.
Для вспомогательных контроллеров домена заходим в разделы:
создаём параметры типа DWord с именем BurFlags и со значением D2 в разделах:
HKEY_LOCAL_MACHINESYSTEMCurrentControl SetServicesNtFrsParametersCumulative Replica SetsGUID
HKEY_LOCAL_MACHINESYSTEMCurrentControl SetServicesNtFrsParametersReplica SetsGUID
HKEY_LOCAL_MACHINESYSTEMCurrentControl SetServicesNtFrsParametersBackup/Res toreProcess atStartup
где вместо GUID у вас имеется своя последовательность букв и цифр, разделённых дефисами.
В некоторых разделах ключи уже присутствовали, но с нулевым значением, там просто меняем, в остальных создавал.
6. Переносим содержимое папок в любое другое место.
Здесь у меня было немного по-другому чем у автора.
У рабочего контроллера была куча подпапок в
C:WINDOWSSYSVOLdomainpolicies
каждая из подпапок отвечала за свою групповую политику. В нерабочем контроллере никаких подпапок не было.
А еще копировал свои драгоценные скрипты из:
SYSVOLdomainscripts
7. Запускаем службы ntfrs на всех контроллерах.
Запуск служб нужно начинать сначала на корневом контроллере домена, а затем на дополнительных контроллерах домена.
net start ntfrs
8. Копируем обратно содержимое папок.
Здесь я тоже схитрил – спасенные политики из 6-го пункта я копирнул на главный контроллер и они потом реплицировались на резервный.
Ну и спасенные скрипты копирнул тоже на главный, они тоже потом среплицировались
9. Проверяем результат на всех контроллерах домена.
net share
Если в результате выполнения команды net share видно наличие расшаренных папок Netlogon и Sysvol, значит восстановление NTFRS успешно завершено.
__
Спасибо liond за статью.
Всё реплицровалось, шары появились. Единственное в «Управлении групповыми политиками» все политики прежде чем подгрузиться требовали согласиться с новыми разрешениями.
Netlogon где находится папка
Общий случай со службой репликации
Первое попавшееся русскоязычное переложение «тыкайте по моему гуайду и будет вам счастье»
Все они говорят в принципе об одном. Тормозните службу, снесите папки, поправьте реестр, чтоб было понятно, кто источник, а кто реплики, и наполнив источник, включите службу.
Добавлено:
И забудьте вы слова основной контроллер, первичный, вторичный. Это было на NT, когда вы еще девочек за косички дёргали. Все контроллеры равнозначны.
Устранение неполадок в пропавших акциях SYSVOL и Netlogon
В этой статье данная статья содержит действия по устранению неполадок, которые необходимо устранить, а также Windows Server 2012 SYSVOL Netlogon R2.
Применяется к: Windows Server 2012 R2, Windows 2008 R2 Пакет обновления 1
Исходный номер КБ: 2958414
Симптомы
SYSVOL и Netlogon на контроллере домена не делятся общими акциями. Также могут возникать следующие симптомы или условия:
- Папка sysvol пуста.
- Недавно был повышен затронутый контроллер домена.
- Среда содержит контроллеры домена, которые запускают версии Windows более ранних Windows Server 2012 R2.
- Репликация DFS используется для репликации реплицируемых SYSVOL папок Share.
- Служба репликации DFS контроллера домена вверх по течению находится в состоянии ошибки.
Причина
Контроллеры домена без общего не могут реплицировать входящие из-за того, что контроллеры домена верхнего потока (источника) в состоянии SYSVOL ошибки. Часто (но не ограничивается) серверы upstream прекратили репликацию из-за грязного отключения (event ID 2213).
Решение
В этом разделе содержатся рекомендуемые методы устранения неполадок и устранения недоставок, а также их доли на контроллерах домена, которые реплицируется с помощью службы SYSVOL Netlogon репликации DFS.
Этот процесс повторно передает репликацию DFS, если она не передается контроллерам домена в соответствии с процедурой принудительной или неавтуальной синхронизации для реплицируемых SYSVOL DFSR SYSVOL (например, «D4/D2» для FRS). В большинстве случаев это не нужно, и это может привести к потере данных, если сделано неправильно. Кроме того, он предотвращает определение причины проблемы и предотвращение будущих возникновений проблемы.
Следующие действия — общие действия по расследованию недостающих акций. Определите, вызвана ли проблема разово возникновением или контроллер домена вверх по течению не может поддерживать репликацию с помощью репликации DFS.
Удаление базы данных репликации DFS из тома не требуется и не рекомендуется. В результате репликации DFS все локальные данные на сервере считаются неавториативными. Позволяя репликации DFS восстанавливать базу данных изящно (как поручено в событии 2213), последний писатель по-прежнему выигрывает любые противоречивые версии SYSVOL данных.
Шаг 1 . Оценка состояния репликации DFS для всех контроллеров домена
Оцените, сколько контроллеров домена не имеют общего доступа, недавно зарегистрировали событие ошибки и сколько контроллеров домена находятся SYSVOL в состоянии ошибки. Выполните указанные ниже действия.
Проверка на SYSVOL долю
Вы можете вручную проверить, является ли общий или вы можете проверить каждый контроллер домена SYSVOL с помощью команды чистого представления:
Проверка состояния репликации DFS
Чтобы проверить состояние репликации DFS на контроллерах домена, можно запросить WMI. Вы можете запрашивать все контроллеры домена в домене для реплицируемых папок Share с SYSVOL помощью WMI следующим образом:
Значения state могут быть любыми из:
0 = Униниализированный
1 = инициализирован
2 = начальная синхронизация
3 = автоматическое восстановление
4 = Нормальный
5 = Ошибка
В зависимости от состояния контроллера домена он может не сообщить о значении состояния и указать отсутствие экземпляра(ы).
Проверка журналов событий на случай недавних ошибок или предупреждений
Если какие-либо контроллеры домена не сообщают, что реплицированная папка Share находится в состоянии 4 (нормальная), проверьте журнал событий этого контроллера SYSVOL домена(ы), чтобы оценить их состояние. Просмотрите каждый контроллер домена на предмет недавних ошибок или предупреждений в журнале событий репликации DFS, таких как ID события предупреждения 2213, который указывает, что репликация DFS в настоящее время приостановлена.
Проверка конфигурации свежести контента
Определите, вызвала ли репликация DFS защиту свежести контента на затронутых контроллерах домена. Свежесть контента включена на Windows Server 2012 (и более поздних версиях) контроллеров домена по умолчанию. Однако он также может быть включен вручную на Windows серверов Server 2008 R2.
Чтобы оценить, включена ли свежесть контента, будет MaxOfflineTimeInDays установлено 60. Если свежесть контента отключена, MaxOfflineTimeInDays будет установлено 0.
Чтобы MaxOfflineTimeInDays проверить, запустите следующую команду:
Чтобы запросить все контроллеры домена в домене, запустите следующую команду:
Для каждого контроллера домена, включенного для свежести контента, оцените, занес ли репликация DFS в журнал ID события 4012, который указывает на то, что репликация папки остановлена, так как репликация не удалась дольше, чем MaxOfflineTimeInDays параметр.
Шаг 2 . Подготовка контроллеров домена, которые находятся в состоянии ошибки
Установка соответствующих обновлений
Для всех контроллеров домена, работающих Windows Server 2008 R2, сначала установите обновления репликации DFS, чтобы предотвратить потерю данных и устранить известные проблемы. Лучше всего использовать последнюю версию репликации DFS. Список доступных в настоящее время hotfixes для технологий распределенной файловой системы (DFS) для последней версии репликации DFS.
Back up SYSVOL data
Резервное копирование SYSVOL данных (если они присутствуют) на каждом контроллере домена.
Резервное копирование может быть копией файла содержимого в безопасное расположение или SYSVOL резервной копией, использующей резервное программное обеспечение.
В зависимости от ситуации файлы политик могут быть перемещены в preExisting или Conflict и Deleted. Предварительное и конфликтное и удаленное содержимое будет удалено, если первоначальная синхронизация будет проделана несколько раз на сервере. Чтобы избежать потери данных, необходимо личные данные в этих местах.
Шаг 3 . Восстановление репликации DFS на контроллерах домена в состоянии ошибки
На основе количества контроллеров домена в домене выберите подходящий метод для восстановления службы репликации DFS.
Для сред с двумя контроллерами домена
Определите, было ли обнаружено грязное отключение (ID события 2213) на любом контроллере домена. Возможно, второй контроллер домена ожидает завершения инициализации SYSVOL . Причина заключается в том, что после продвижения по службе он будет входить в журнал события 4614, которое указывает на то, что репликация DFS ожидает первоначальной репликации.
Кроме того, он не будет входить в журнал событий 4604, сигнализируемых о том, что репликация DFS инициализирована. SYSVOL
Если свежесть контента включена на обоих контроллерах домена
Если второй контроллер домена ждет начальной синхронизации (событие 4614 в журнале без антиимнеяна 4604), выполните статью How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like «D4/D2» for FRS) to set the first domain controller as authoritative. Не нужно настраивать второй контроллер домена как неавториативный, так как он уже ожидает первоначальной синхронизации.
Или, если второй контроллер домена здоров и имеет общий SYSVOL доступ, примите следующие действия:
Поддержим все SYSVOL содержимое первого контроллера домена.
Оцените, устарели ли данные второго контроллера SYSVOL домена. Если нет, может потребоваться скопировать обновленные файлы на второй контроллер домена SYSVOL из первого контроллера домена. В противном случае все существующие данные, представленные на первом контроллере домена, не присутствующие на втором, будут переходить в папки PreExisting и Conflict и Deleted.
Установите первый контроллер домена как неавторитивный, отключив членство в how to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like «D4/D2» for FRS). Подтверждение того, что в журнал вошел ID события 4114, чтобы указать, что членство отключено.
Встрой членство первого контроллера домена и дождись событий 4614 и 4604, которые сообщают о завершении начальной синхронизации. При необходимости восстановим все обновленные файлы из предварительной версии в исходное расположение.
Если свежесть контента не включена или не запускается на обоих контроллерах домена
Если первый контроллер домена находится в состоянии ID события 2213, а второй контроллер домена никогда не завершил инициализацию после его продвижения, и свежесть контента не была вызвана. Предпринять следующие действия:
Запустите ResumeReplication метод WMI на первом контроллере домена, как поручено в событии 2213.
После возобновления репликации он будет входить в журнал ID события 4602, который указывает, что репликация DFS инициализировала реплицированную папку и указала ее в качестве SYSVOL основного участника.
Запустите команду на втором контроллере домена, чтобы запустить ее для завершения начальной синхронизации dfsrdiag pollad (event ID 4614). После завершения начальной синхронизации регистрируется ИД события 4604, SYSVOL инициализация сигналов завершена.
Или, если первый контроллер домена находится в состоянии 2213, а второй контроллер домена является здоровым (общий), запустите метод WMI на первом SYSVOL ResumeReplication контроллере домена. После завершения восстановления грязного отключения он будет входить в журнал event ID 2214.
Для сред с тремя или более контроллерами домена
Определите, было ли обнаружено грязное отключение и приостановлена ли репликация DFS на любых контроллерах домена (event ID 2213). Вы можете найти контроллер домена ждет завершения инициализации после SYSVOL продвижения по службе. Он будет входить в журнал события 4614, которое указывает, что репликация DFS ожидает, чтобы сделать первичная репликация. Он также не будет входить в журнал события 4604, сигнализируемый о том, что репликация DFS инициализирована.
SYSVOL
Если включена свежесть контента и в домене есть три или более контроллеров домена.
Защита свежести контента занесет в журнал ID события 4012, который указывает на то, что репликация остановлена, так как репликация в папке не удалась дольше, чем MaxOfflineTimeInDays параметр. Чтобы реинтициализировать репликацию DFS на затронутом контроллере домена (s), следуйте инструкциям в Инструкции по принудительной и неавтуальной синхронизации для SYSVOL, реплицируемых DFSR (например, «D4/D2» для FRS).
Если все контроллеры домена зарегистрировали событие 4012 и их состояние составляет 5, выполните инструкции в Инструкции по принудительной и неавтной синхронизации для реплицируемых DFSR SYSVOL (например, «D4/D2» для FRS) для полной инициализации SYSVOL . Это единственная ситуация, когда сервер репликации DFS является авторитетным. Убедитесь, что контроллер домена, настроенный как авторитетный, имеет самые последние копии всего SYSVOL содержимого.
Или, если один или несколько контроллеров домена блокируют репликацию из-за свежести контента, каждый из них должен быть неавтитарно восстановлен.
Выполните приведенные ниже действия.
Back up SYSVOL all contents of the domain controller (s). Как правило, изменения политики в PDC Emulator, но это не гарантируется. Все данные, представленные на восстановленном контроллере домена(ы), не совпадающие с партнерами, будут переходить в папку PreExisting или Conflict и Deleted или оба.
Установите контроллер домена (s) как неавториативное, отключив членство, как описано в описании Как заставить авторитетную и неавториативную синхронизацию для репликации DFSR SYSVOL (например, «D4/D2» для FRS). Вы должны знать топологию репликации, и вы должны выйти из здорового контроллера домена, выбрав ее прямых партнеров, а затем восстановив контроллеры домена ниже по течению и так далее. Для подтверждения отключения членства будет в журнале event ID 4144. Убедитесь, что все контроллеры домена, требующие журнала восстановления события. Может потребоваться принудительное копирование Active Directory, а затем выполнить команду на каждом контроллере домена, чтобы быстро обнаружить dfsrdiag pollad отключенное членство.
Включить членство и дождаться событий 4614 и 4604, чтобы сообщить о завершении начальной синхронизации. Восстановление необходимых файлов из резервного копирования или из предварительного и конфликтного и удаленных по мере необходимости.
Если свежесть контента не включена или не запускается, в домене есть три или более контроллеров домена.
Если защита свежести контента не запускается, запустите метод WMI на ResumeReplication затронутых контроллерах домена. Вы должны знать топологию репликации, и вы должны выйти из здорового контроллера домена, выбрав ее прямых партнеров, а затем восстановив контроллеры домена ниже по течению и так далее. После возобновления репликации репликация DFS регистрирует события 2212, 2218 и 2214 (что указывает на то, что репликация DFS инициализировала реплицированную SYSVOL папку).
Предотвращение возникновения проблемы в будущем
Проверьте, часто ли журналы событий приложений и систем сообщают о операциях восстановления базы данных ESENT, проблемах производительности диска или обоих.
Журналы событий обычно совпадают с неожиданными отключениями системы, при этом репликация DFS не останавливается изящно, или сбоями подсистемы диска. Рассмотрите возможность обновления драйверов системы, установки соответствующих обновлений в подсистему диска или контакта с производителем оборудования системы для дальнейшего изучения. Вы также можете обратиться в службы поддержки клиентов Майкрософт, чтобы помочь оценить состояние системы и поведение репликации DFS.
Диспетчер управления службами (SCM) использует время простоя по умолчанию в 20 секунд для остановки службы. В некоторых сложных реализациях репликации DFS это значение может быть слишком коротким, и репликация DFS прекращается до закрытия соответствующей базы данных. При перезапуске службы репликация DFS обнаруживает это условие, а затем делает восстановление базы данных. WaitToKillServiceTimeout может использоваться для предоставления репликации DFS больше времени для фиксации изменений в базе данных во время остановки работы.
Дополнительные сведения можно найти в статье Вы получаете ID событий DFSR 2212после перезапуска службы DFSR.
После восстановления репликации DFS для предотвращения этого сценария необходимо тщательно отслеживать состояние репликации SYSVOL DFS в среде. Рекомендуется регулярно проверять журналы событий репликации DFS, собирать отчеты о состоянии репликации DFS и собирать состояние репликации (с помощью запроса WMI в разделе Проверка репликации DFS в разделе Шаг 1 — Оценка состояния репликации DFSдля всех контроллеров домена).
Что такое папка Netlogon в Active Directory?
Active Directory
Trending
Vipan Kumar24 ноября 2019 г. — Последнее обновление: 3 февраля 2023 г.
5 619 2 минуты чтения
Привет всем,
Надеюсь, что этот пост застанет вас в добром здравии и духе.
Что такое папка Netlogon в Active Directory?
Сегодня мы расскажем о папке netlogon, что она содержит и для чего предназначена папка netlogon..jpg)
Папка Netlogon — это общая папка, содержащая файлы сценария входа в систему групповой политики, а также другие исполняемые файлы.
Сценарии входа обычно хранятся на контроллере домена в общем ресурсе Netlogon, расположенном в папке %systemroot%\System32\Repl\Imports\Scripts. После размещения этого сценария в общем ресурсе Netlogon он автоматически реплицируется на все контроллеры домена в домене.
NetlogonNetlogon Общий ресурс не является папкой с именем Netlogon на контроллере домена .
, если вы пройдете по папке sysvol и выполните поиск в папке netlogon, вы не найдете ее в sysvol, потому что в sysvol нет папки с именем папки netlogon. Как мы уже говорили, это не папка с именем Netlogon, но если вы откроете свойство папки сценариев и перейдете на вкладку «Общий доступ», вы найдете имя общего ресурса как Netlogon.
Всегда помните, что папка Script в папке sysvol будет действовать как общий ресурс Netlogon .
Вы также можете проверить папку netlogon, выполнив следующие шаги:
- Войдите в консоль контроллера домена.
- Откройте командную строку CMD.EXE.
- Введите net share и нажмите Enter.
- Вы получите сообщение, похожее на следующее:
Расположение общего ресурса NETLOGON по умолчанию на контроллере домена:
%SystemRoot%\sysvol\sysvol\\scripts
Вы можете просмотреть действия, связанные с процессом Netlogon, введя следующую команду в поле ‘ Диалоговое окно «Выполнить».
%SYSTEMROOT%\debug\netlogon.log
Следующие коды можно использовать для понимания действия LOGON, зарегистрированного в файле журнала пользователя.
| Код журнала | Описание |
|---|---|
| 0x0 | Успешный вход в систему |
| 0xC000006D | Неудачная попытка входа из-за неправильного имени пользователя |
| 0xC0000072 | Отключенная учетная запись пользователя |
| 0xC000006F | Неудачная попытка входа в систему из-за ограничений по времени |
| 0xC0000071 | Срок действия пароля учетной записи истек |
| 0xC000006A | Введен неверный пароль |
| 0xC000006C | Политика паролей не соблюдена |
| 0xC0000224 | Пароль необходимо изменить перед первой попыткой входа в систему |
| 0xC000006E | Ошибка входа из-за ограничений учетной записи пользователя |
| 0xC0000193 | Срок действия учетной записи пользователя истек |
| 0xC0000234 | Учетная запись пользователя была автоматически заблокирована |
| 0xC0000064 | Пользователь не существует |
Также проверьте это.
Как включить журнал отладки сетевого входа в систему для контроллера домена
Итак, в этом блоге все. Я скоро встречусь с вами с некоторыми другими вещами. Хорошего дня !!!
Рекомендуемое содержимое
DCDIAG /Test: Netlogons
Как включить журнал отладки netlogon для контроллера домена
Руководство по установке RODC — Пошаговое руководство по установке контроллера домена только для чтения
Набор фильтрованных атрибутов контроллера домена только для чтения
Установка и настройка контроллера домена только для чтения в Windows Server-2012
Как найти GUID контроллера домена
Понимание групповой политики Предпочтения групповой политики
Средство проверки групповой политики GPOTool Exe
Проверка работоспособности групповой политики на конкретном контроллере домена
Что такое папка Netlogon в Active Directory
Как создавать настраиваемые атрибуты в Active Directory
Как проверить время жизни надгробия моего леса Active Directory
Как определить сайт AD компьютеров из командной строки
Как проверить целостность базы данных Active Directory
Как проверить целостность базы данных Active Directory
Отключение и включение исходящей репликации
Служба репликации DFS остановила репликацию
Что такое строгая согласованность репликации
Операция репликации завершилась неудачно из-за несоответствия схемы между вовлеченными серверами
Устранение ошибки репликации объявлений 8418 операция репликации завершилась неудачно из-за несоответствия схемы между серверами
Как экспортировать информацию о репликации в текстовый файл
Repadmin Replsummary
Включение исходящей репликации
Ребята, не забудьте поставить лайк и поделиться публикацией.
Вы также можете поделиться своим мнением по указанному ниже идентификатору электронной почты Windows Techno.
Если у вас есть какие-либо вопросы, не стесняйтесь обращаться к нам по телефону [электронная почта защищена] также следите за нами по [адрес электронной почты защищен] , чтобы получать обновления о новых сообщениях в блоге.
Насколько полезен был этот пост?
Нажмите на звездочку, чтобы оценить!
Связанные статьи
Проверьте также
Закрывать
Идентификатор вызова в Active Directory
2 июля 2020 г. — Последнее обновление: 7 декабря 2022 г.
Кнопка «Вернуться к началу»
windows — Храните сценарии групповой политики в папке Netlogon или политики?
спросил
Изменено 3 года, 10 месяцев назад
Просмотрено 30 тысяч раз
Лучше всего хранить сценарии входа в систему централизованно в \\DOMAIN\Netlogon или в папке политики, в которую они помещаются по умолчанию, например.
\\DOMAIN\SysVol\DOMAIN\Policies\{DE22B6FB-315E-4C55-BF06-A7709913CD9E}\User\Scripts\Logon ?Каковы последствия (если таковые имеются) выбора одного места вместо другого?
Я склоняюсь к тому, чтобы оставить их все в Netlogon для простоты доступа/обзора… Сценарии входа — это общий ресурс NETLOGON, который по умолчанию реплицируется на все контроллеры домена в вашем лесу и физически находится в:
%SystemRoot%\SYSVOL\sysvol\ .
или
%SystemRoot%\SYSVOL_DFSR\sysvol\ (для службы FRS на основе DFS, поскольку это рекомендуется начиная с Server 2012R2+)
User > Properties > Logon > Logon-Script > hello.cmd), выполняется из NETLOGON.
«Официальная» рекомендация:
- хранить их вместе с объектом групповой политики, если вы устанавливаете его через объект групповой политики.
- сохраните их в NETLOGON, если вы установите его как свойство пользователя в AD.
1
Оба местоположения синхронизируются между контроллерами домена, поэтому для меня это только личный выбор.
Мое личное мнение состоит в том, что после определенного количества GPO становится трудно управлять всем, что находится в сети. (например, когда вы удаляете объект групповой политики, сценарий не будет стерт в примере)
Не уверен, что это «лучшая практика», но я видел несколько сообщений в блогах, рекомендующих это, и я предпочитаю это:
У нас есть общая папка, содержащая все вспомогательные файлы для наших объектов групповой политики, включая сценарии. Все сценарии проверены системой контроля версий.
Общий файловый ресурс настроен с DFS, поэтому это \domain.com\DFS\GPO-Files
Сценарии находятся в подкаталоге \domain.com\DFS\GPO-Files\Scripts
В GPO вы назовите скрипт «powershell.exe» и для параметров, которые вы делаете — File PathToScript.
Мне нравится этот подход, потому что файлы и сценарии GPO находятся в известном месте, а не скрыты в папке с именем GUID.