Ошибка netlogon код события 5719

Добрый день господа. В логах рабочих станций стали появляться записи

Netlogon 5719

И еще одна с кодом 135:

«NTP-клиенту не удалось задать настроенный вручную узел в качестве источника времени из-за ошибки дублирования на «dc01.vdk1.local,0x9». Тот же источник времени «dc01.vdk1.local» был задан как настроенный вручную узел
на NTP-сервере или выбран как узел домена. NTP-клиент повторит попытку через 15 мин., а затем удвоит интервал между попытками. Ошибка: Элемент уже существует. (0x800706E0)»

Сетвые карты Wi-FI и обычные проводные.

Рабочие станции:

Win 7 Prof SP1 с актуальными обновлениями.

Win 8.1 Prof с актуальными обновлениями.

Серверы:

DC01- 2008R2 SP1 с актуальными обновлениями.

DC02- 2008R2 SP1 с актуальными обновлениями.

Ошибок в логах нет, DNS работает корректно.

Ipconfig клиента win 8.1

Microsoft Windows [Version 6.3.9600]
(c) Корпорация Майкрософт (Microsoft Corporation), 2013. Все права защищены.

C:Windowssystem32>ipconfig /all

Настройка протокола IP для Windows

   Имя компьютера  . . . . . . . . . : admin
   Основной DNS-суффикс  . . . . . . : vdk1 . local
   Тип узла. . . . . . . . . . . . . : Гибридный
   IP-маршрутизация включена . . . . : Нет
   WINS-прокси включен . . . . . . . : Нет
   Порядок просмотра суффиксов DNS . : vdk1 . local

Адаптер беспроводной локальной сети Подключение по локальной сети* 3:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : Виртуальный адаптер Wi-Fi Direct (Майкрос
офт) #2
   Физический адрес. . . . . . . . . : 1A-1A-67-A6-96-15
   DHCP включен. . . . . . . . . . . : Да
   Автонастройка включена. . . . . . : Да

Адаптер беспроводной локальной сети Беспроводная сеть:

   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : Беспроводной сетевой адаптер Qualcomm Ath
eros AR9287
   Физический адрес. . . . . . . . . : F8-1A-67-A6-96-15
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да
   Локальный IPv6-адрес канала . . . : fe80::30af:fc57:4aab:7e38%7(Основной)
   IPv4-адрес. . . . . . . . . . . . : 192.168.1.3(Основной)
   Маска подсети . . . . . . . . . . : 255.255.0.0
   Основной шлюз. . . . . . . . . : 192.168.1.1
   IAID DHCPv6 . . . . . . . . . . . : 83368551
   DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-1A-3A-16-35-94-DE-80-43-61-C0

   DNS-серверы. . . . . . . . . . . : 192.168.1.6
                                       192.168.1.5
   NetBios через TCP/IP. . . . . . . . : Включен

Ethernet adapter VMware Network Adapter VMnet1:

   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
1
   Физический адрес. . . . . . . . . : 00-50-56-C0-00-01
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да
   Локальный IPv6-адрес канала . . . : fe80::fc2c:1a35:aa54:ab30%9(Основной)
   IPv4-адрес. . . . . . . . . . . . : 172.16.132.1(Основной)
   Маска подсети . . . . . . . . . . : 255.255.255.0
   Основной шлюз. . . . . . . . . :
   IAID DHCPv6 . . . . . . . . . . . : 352342102
   DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-1A-3A-16-35-94-DE-80-43-61-C0

   DNS-серверы. . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBios через TCP/IP. . . . . . . . : Включен

Ethernet adapter VMware Network Adapter VMnet8:

   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
8
   Физический адрес. . . . . . . . . : 00-50-56-C0-00-08
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да
   Локальный IPv6-адрес канала . . . : fe80::94c7:573c:233d:ebb%11(Основной)
   IPv4-адрес. . . . . . . . . . . . : 172.16.61.1(Основной)
   Маска подсети . . . . . . . . . . : 255.255.255.0
   Основной шлюз. . . . . . . . . :
   IAID DHCPv6 . . . . . . . . . . . : 385896534
   DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-1A-3A-16-35-94-DE-80-43-61-C0

   DNS-серверы. . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBios через TCP/IP. . . . . . . . : Включен

Туннельный адаптер isatap.{4D325365-7CC9-442A-BA4E-8DC0146FC830}:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP #2
   Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да

Туннельный адаптер isatap.{F82DCF34-2B40-447C-957F-31DC5779D863}:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP #3
   Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да

Туннельный адаптер isatap.{EAEEC36C-6122-4181-81ED-0988245AE9AB}:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP #4
   Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да

Туннельный адаптер isatap.{DAA8D103-5AB1-406E-A9F9-55CF96813317}:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP #5
   Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да

C:Windowssystem32>

Ipconfig DC01 

Настройка протокола IP для Windows

   Имя компьютера  . . . . . . . . . : dc01
   Основной DNS-суффикс  . . . . . . : vdk1 . local
   Тип узла. . . . . . . . . . . . . : Гибридный
   IP-маршрутизация включена . . . . : Нет
   WINS-прокси включен . . . . . . . : Нет
   Порядок просмотра суффиксов DNS . : vdk1.local

Ethernet adapter Подключение по локальной сети:

   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : Сетевое подключение Intel(R) PRO/1000 MT
   Физический адрес. . . . . . . . . : 00-15-17-D4-83-90
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да
   IPv4-адрес. . . . . . . . . . . . : 192.168.1.6(Основной)
   Маска подсети . . . . . . . . . . : 255.255.0.0
   Основной шлюз. . . . . . . . . : 192.168.1.1
   DNS-серверы. . . . . . . . . . . : 192.168.1.5
                                       192.168.1.6
   NetBios через TCP/IP. . . . . . . . : Включен

Туннельный адаптер isatap.{CA09F9A2-183C-401A-8A9B-C6E7FA22EF3C}:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP
   Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да

Туннельный адаптер Подключение по локальной сети* 2:

   Состояние среды. . . . . . . . : Среда передачи недоступна.
   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да

DCDIAG ошибок не выдает.

Изменил параметры реестра

После чего ошибка стала появляться только при перезагрузке ПК. При запуске выключенного ПК ошибок в логах нет.

Подскажите куда копать? Все явные решения я уже испробывал.

При запуске члена домена регистрируется событие входа в систему с кодом 5719 или событие групповой политики 1129.

В этой статье описываются методы устранения события Netlogon с кодом 5719 или события групповой политики 1129, регистрируемые при запуске члена домена.

Исходная версия продукта: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер статьи базы знаний: 938449

Симптомы

Точно следуйте всем указаниям из этого раздела. Внесение неправильных изменений в реестр может привести к возникновению серьезных проблем. Прежде чем приступить к изменениям, создайте резервную копию реестра для восстановления на случай возникновения проблем.

Рассмотрим следующий сценарий:

• У вас есть компьютер под управлением Windows 10 или Windows Server 2012 R2.
• Компьютер присоединен к домену.
• Справедливо одно из следующих условий:
  • На компьютере установлен гигабитный сетевой адаптер.
  • Для безопасного доступа к сети используйте защиту доступа к сети (NAP), сетевую проверку подлинности (с помощью 802,1x) или другой способ.

В этом сценарии в системном журнале регистрируется следующее событие при запуске компьютера в каждой версии Windows до Windows 8,1 включительно. В Windows 10 и более новых версиях событие 5719 больше не записывается в эту ситуацию. Вместо этого в журнале Netlogon записываются следующие строки:

НАИБОЛЕЕ [960] CONTOSO: Нлсессионсетуп: Настройка сеанса: не удается выбрать доверенный контроллер домена
СМ [960] IP-адреса не указаны, пропуск журнала событий DC

После этого компьютеру назначается IP-адрес:

СМ [960] V6 addr Winsock addr: FE80:: 5faf: 632a: f22c: 644a %2 (1) V6WinsockPnpAddresses list пуст.
СМ [960] Winsock Addrs: 10.1.1.80 (1) список пуст.

В Windows 10 и более поздних версиях в зависимости от подключения контроллера домена (например, групповой политики) отображаются только события по компонентам. В журнале отладки групповой политики регистрируется следующее:

Кгпаппликатионсервице:: Мачинеполицистартедваитингоннетворк.
Кгпмачинестартупконнективити:: Калкулатеваиттимеаутфромхистори: СРЗНАЧ — 388. Кгпмачинестартупконнективити:: Калкулатеваиттимеаутфромхистори: Current равно-1. Кгпмачинестартупконнективити:: Калкулатеваиттимеаутфромхистори: требуется минимум 776 и 30000.
Ожидание Самсс с временем ожидания 776

Нлакуеринетсигнатурес возвращает 1 сети
Сведения о НСИ (GUID сети): <395DB3C8-CE45-11E5-9739-806E6F6E6963>
Сведения о НСИ (CompartmentId): 1
Сведения о НСИ (идентификатор сайта): 134217728
Сведения о НСИ (сетевое имя):
Сбой Нлажетинтранеткапабилити с 0x15
Отсутствует секция домена
Процессгпос (Machine): сбой Мижетусернаме с 1355.
Успешно открытый запрос NLA
Нлажетинтранеткапабилити вернул ошибку «не готов». Рассмотрите его как не поддерживающий интрасеть.

ГПСВК (530. ae0) 13:32:28:728 нет подключения
ГПСВК (530.8 E0) 13:32:28:728 Апплиграупполици: подготовка к созданию фонового потока Гпосреад.

В первом разделе показан расчет времени ожидания, используемого для подключения к сети. Это может быть основано на предыдущих быстрых запусках.

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

Причина

Эта проблема может возникнуть по одной из следующих причин:

• Служба Netlogon запускается до готовности сети. Стек сети и инициализация адаптера часто начинаются в то же время. Некоторые сетевые адаптеры и коммутаторы имеют арбитраж ссылок и проверки уникальности MAC-адресов, которые выполняются дольше, чем время ожидания, установленное для службы Netlogon для обнаружения сетевого подключения.
• Решения, проверяющие работоспособность нового члена сети, задерживает сетевое подключение и возможность доступа к контроллерам домена. Если у вас включено автоматическое подключение по каналу прямого доступа, для этого может потребоваться больше времени, чем разрешено службой Netlogon.
• Процесс проверки подлинности 802.1 X задерживает подключения к контроллерам домена.
• Клиент испытывает задержку для получения IP-адреса от DHCP-сервера. Это задерживает отображение сетевого интерфейса.

Групповая политика в Windows Vista и более поздних версиях предназначена для согласования состояния сети с включенной поддержкой сетевого расположения (NLA) и ожидает сети с подключением к контроллеру домена. Однако групповая политика может начаться преждевременно из-за применения политики. Это особенно важно, если задержка поиска сети между запусками заключается в разных случаях.

При неправильном изменении реестра с использованием редактора реестра или другого способа могут случиться серьезные проблемы. Для решения этих проблем может потребоваться переустановка операционной системы. Компания Microsoft не может гарантировать, что эти проблемы могут быть решены. Вносите изменения в реестр на ваш страх и риск.

Решение 1

Чтобы устранить эту проблему, установите самый актуальный драйвер для гигабитного сетевого адаптера. Или включите параметр портфаст в разделе Сетевые коммутаторы.

Решение 2

Чтобы устранить эту проблему, используйте реестр для изменения связанных параметров, влияющих на подключение к контроллеру домена. Для этого выполните указанные ниже действия.

Способ 1

Настройте параметры брандмауэра или политики IPSEC, которые были изменены, чтобы разрешить подключение к контроллеру домена. Эти изменения вносятся в то время, когда клиент получает IP-адрес, но ему требуется больше времени для доступа к контроллеру домена (например, после успешной проверки через Cisco НАК или службы NPS).

Способ 2

Настройте Netlogon для параметра реестра значение, которое будет безопасно за пределами требуемого времени, чтобы разрешить подключение к контроллеру домена.

Это действие является эффективным только в том случае, если у компьютера уже есть IP-адрес. Это относится к сценариям, в которых решение NAP помещает компьютер в сеть карантина. Используйте следующие параметры в качестве рекомендаций.

Подраздел реестра: HKEY_LOCAL_MACHINE Системкуррентконтролсетсервицеснетлогонпараметерс
Имя значения: Експектеддиалупделай
Тип данных: REG_DWORD
Значение данных в секундах (по умолчанию = 0)
Диапазон данных находится в пределах от 0 до 600 секунд (10 минут)

Способ 3

Стек IP пытается проверить IP-адрес, используя широковещательный пакет ARP. Это задерживает время, в течение которого IP-адрес переходит в оперативный режим. Для записи реестра Арпретрикаунт можно задать значение 1, поэтому дожидаться уникальности будет укорочено. Для этого выполните следующие действия:

Откройте редактор реестра.

Выберите следующий подраздел:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpIpParameters

В меню Правка наведите указатель на пункт создатьи выберите значение DWORD.

Щелкните правой кнопкой мыши ArpRetryCount запись реестра и выберите команду изменить.

В поле значение введите 1и нажмите кнопку ОК.

Диапазон данных находится в пределах от 0 до 3 (по умолчанию используется 3).

Закройте редактор реестра.

Способ 4

Уменьшите отрицательный период кэширования Netlogon, изменив NegativeCachePeriod запись реестра в следующем подразделе:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParametersNegativeCachePeriod

После внесения этого изменения служба Netlogon работает неправильно, если контроллеры домена находятся в автономном режиме в течение 45 секунд. Событие 5719 по-прежнему заносится в журнал. Однако это событие не приводит к возникновению каких – либо других существенных проблем. Этот параметр позволяет члену попытаться попытаться использовать контроллеры домена, если процесс завершился сбоем ранее.

Предложение: попробуйте установить небольшое значение (например, три секунды). В средах ЛВС можно использовать значение 0, чтобы отключить отрицательный кэш.

Дополнительные сведения об этом параметре приведены в разделе параметры для минимизации периодического трафика глобальной сети.

Способ 5

Настройте Kerberos для параметра реестра значение, которое будет безопасно за пределами требуемого времени, чтобы разрешить подключение к контроллеру домена. Используйте следующие параметры в качестве рекомендаций.

Этот параметр применяется только к Windows XP и Windows Server 2003 или более ранним версиям этих систем. В Windows Vista и Windows Server 2008 и более поздних версиях используется значение по умолчанию ( 0). Это значение выключает функции протокола UDP для клиента Kerberos.

Подраздел реестра: HKEY_LOCAL_MACHINE Системкуррентконтролсетконтроллсакербероспараметерс
Имя значения: Макспаккетсизе
Тип данных: REG_DWORD
Данные значения: 1
Значение по умолчанию: (зависит от версии системы)

Метод 6

Отключите датчик сетевого подключения для TCP/IP. Для этого добавьте следующее значение в Tcpip подраздел реестра:

Подраздел реестра: HKEY_LOCAL_MACHINE Системкуррентконтролсетсервицесткпиппараметерс
Имя значения: Дисабледхкпмедиасенсе
Тип данных: REG_DWORD
Данные значения: 1
Диапазон значений: Boolean (0 = false, 1 = true)
Значение по умолчанию: 0 (false)

Метод 7

Групповая политика имеет параметры политики для управления временем ожидания обработки политики запуска:

Корпоративная сеть или WLAN:

Папка политики: «Конфигурация компьютера административные шаблоны групповая политика»»
Имя политики: «указать время ожидания при обработке политики запуска»

Внешняя локальная сеть или WLAN:

Папка политики: «Конфигурация компьютера административные шаблоны групповая политика»»
Имя политики: «укажите время ожидания подключения к рабочей области» для обработки политики «

Время, затраченное службой Netlogon для получения рабочего IP-адреса, может быть основой для этого параметра. Для сценариев прямого доступа вы можете измерять типичную задержку, которую ваша база пользователей имеет до установки подключения.

Способ 8

Если DisabledComponents параметр реестра установлен и имеет неправильное значение 0xFFFFFFF, удалите ключ или измените его на предполагаемое значение 0xFF.

Протокол IP версии 6 (IPv6) является обязательной частью Windows Vista и более поздних версий Windows. Мы не рекомендуем отключить IPv6 и его компоненты. В противном случае некоторые компоненты Windows могут работать неправильно. Кроме того, при запуске системы в течение пяти секунд будет выполняться задержка при неправильном отключении протокола IPv6 путем установки DisabledComponents для параметра реестра значения 0xFFFFFFF. Правильным значением является 0xFF.

Способ 9

Это может быть вызвано состоянием гонки между инициализацией сети, поиском контроллера домена и обработки групповой политики. Если сеть недоступна, контроллер домена не будет найден, а обработка групповой политики завершится с ошибками. После загрузки операционной системы и согласования и установки подключения к сети фоновое обновление групповой политики будет успешным.

Вы можете задать значение реестра, чтобы отложить применение групповой политики.

Откройте редактор реестра.

Выберите следующий подраздел:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

В меню Правка наведите указатель на пункт создатьи выберите значение DWORD.

Щелкните правой кнопкой мыши GpNetworkStartTimeoutPolicyValue запись реестра и выберите команду изменить.

В разделе базовыйвыберите десятичное.

В поле значение введите 60, а затем нажмите кнопку ОК.

Выйдите из редактора реестра и перезагрузите компьютер.

Если сценарий запуска групповой политики не запускается, увеличьте значение параметра GpNetworkStartTimeoutPolicyValue реестра.

Дополнительная информация

Если вы можете войти в домен без проблемы, можно спокойно проигнорировать событие с кодом 5719. Так как служба Netlogon может запускаться до готовности сети, компьютер может не иметь возможности определить контроллер домена для входа в систему. Таким образом, в журнале регистрируется событие с ИДЕНТИФИКАТОРом 5719. Однако после того, как сеть будет готова, компьютер повторит попытку найти контроллер домена для входа в систему. В этом случае операция должна быть успешной.

В файле Нетогон. log записи, похожие на приведенные ниже, могут быть занесены в журнал.

DateTime [Critical] : Нлдисковердк: не удается найти DC. DateTime [Critical] : Нлсессионсетуп: Настройка сеанса: не удается выбрать доверенный DC DateTime [прочие параметры] журнал событий: 5719 (1) » » 0xc000005e. DateTime [Session] Впнг: Нлсетстатусклиентсессион: Set Connection Status to c000005e. DateTime [Session] девице NetBT_Tcpip_ <4A47AF53-40D3-4F92-ACDF-9B5E82A50E32>: транспорт добавлен (10.0.64.232) — > ПОЛУЧАЕМый IP-адрес берет >15 секунд.

Другие компоненты, для правильной работы которых требуется подключение контроллера домена, могут сообщать о подобных ошибках. Например, групповая политика не может применяться при запуске системы. В этом случае стартовые сценарии не запускаются. Сбои групповой политики могут относиться к отказу службы Netlogon для обнаружения контроллера домена. Вы можете настроить групповую политику для более быстрого реагирования на Последнее получение сетевого подключения.

Источник

Все новые темы

При запуске члена домена регистрируется событие входа в систему с кодом 5719 или событие групповой политики 1129.

В этой статье описываются методы устранения события Netlogon с кодом 5719 или события групповой политики 1129, регистрируемые при запуске члена домена.

Исходная версия продукта: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер статьи базы знаний: 938449

Симптомы

Точно следуйте всем указаниям из этого раздела. Внесение неправильных изменений в реестр может привести к возникновению серьезных проблем. Прежде чем приступить к изменениям, создайте резервную копию реестра для восстановления на случай возникновения проблем.

Рассмотрим следующий сценарий:

• У вас есть компьютер под управлением Windows 10 или Windows Server 2012 R2.
• Компьютер присоединен к домену.
• Справедливо одно из следующих условий:
  • На компьютере установлен гигабитный сетевой адаптер.
  • Для безопасного доступа к сети используйте защиту доступа к сети (NAP), сетевую проверку подлинности (с помощью 802,1x) или другой способ.

В этом сценарии в системном журнале регистрируется следующее событие при запуске компьютера в каждой версии Windows до Windows 8,1 включительно. В Windows 10 и более новых версиях событие 5719 больше не записывается в эту ситуацию. Вместо этого в журнале Netlogon записываются следующие строки:

НАИБОЛЕЕ [960] CONTOSO: Нлсессионсетуп: Настройка сеанса: не удается выбрать доверенный контроллер домена
СМ [960] IP-адреса не указаны, пропуск журнала событий DC

После этого компьютеру назначается IP-адрес:

СМ [960] V6 addr Winsock addr: FE80:: 5faf: 632a: f22c: 644a %2 (1) V6WinsockPnpAddresses list пуст.
СМ [960] Winsock Addrs: 10.1.1.80 (1) список пуст.

В Windows 10 и более поздних версиях в зависимости от подключения контроллера домена (например, групповой политики) отображаются только события по компонентам. В журнале отладки групповой политики регистрируется следующее:

Кгпаппликатионсервице:: Мачинеполицистартедваитингоннетворк.
Кгпмачинестартупконнективити:: Калкулатеваиттимеаутфромхистори: СРЗНАЧ — 388. Кгпмачинестартупконнективити:: Калкулатеваиттимеаутфромхистори: Current равно-1. Кгпмачинестартупконнективити:: Калкулатеваиттимеаутфромхистори: требуется минимум 776 и 30000.
Ожидание Самсс с временем ожидания 776

Нлакуеринетсигнатурес возвращает 1 сети
Сведения о НСИ (GUID сети): <395DB3C8-CE45-11E5-9739-806E6F6E6963>
Сведения о НСИ (CompartmentId): 1
Сведения о НСИ (идентификатор сайта): 134217728
Сведения о НСИ (сетевое имя):
Сбой Нлажетинтранеткапабилити с 0x15
Отсутствует секция домена
Процессгпос (Machine): сбой Мижетусернаме с 1355.
Успешно открытый запрос NLA
Нлажетинтранеткапабилити вернул ошибку «не готов». Рассмотрите его как не поддерживающий интрасеть.

ГПСВК (530. ae0) 13:32:28:728 нет подключения
ГПСВК (530.8 E0) 13:32:28:728 Апплиграупполици: подготовка к созданию фонового потока Гпосреад.

В первом разделе показан расчет времени ожидания, используемого для подключения к сети. Это может быть основано на предыдущих быстрых запусках.

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

Причина

Эта проблема может возникнуть по одной из следующих причин:

• Служба Netlogon запускается до готовности сети. Стек сети и инициализация адаптера часто начинаются в то же время. Некоторые сетевые адаптеры и коммутаторы имеют арбитраж ссылок и проверки уникальности MAC-адресов, которые выполняются дольше, чем время ожидания, установленное для службы Netlogon для обнаружения сетевого подключения.
• Решения, проверяющие работоспособность нового члена сети, задерживает сетевое подключение и возможность доступа к контроллерам домена. Если у вас включено автоматическое подключение по каналу прямого доступа, для этого может потребоваться больше времени, чем разрешено службой Netlogon.
• Процесс проверки подлинности 802.1 X задерживает подключения к контроллерам домена.
• Клиент испытывает задержку для получения IP-адреса от DHCP-сервера. Это задерживает отображение сетевого интерфейса.

Групповая политика в Windows Vista и более поздних версиях предназначена для согласования состояния сети с включенной поддержкой сетевого расположения (NLA) и ожидает сети с подключением к контроллеру домена. Однако групповая политика может начаться преждевременно из-за применения политики. Это особенно важно, если задержка поиска сети между запусками заключается в разных случаях.

При неправильном изменении реестра с использованием редактора реестра или другого способа могут случиться серьезные проблемы. Для решения этих проблем может потребоваться переустановка операционной системы. Компания Microsoft не может гарантировать, что эти проблемы могут быть решены. Вносите изменения в реестр на ваш страх и риск.

Решение 1

Чтобы устранить эту проблему, установите самый актуальный драйвер для гигабитного сетевого адаптера. Или включите параметр портфаст в разделе Сетевые коммутаторы.

Решение 2

Чтобы устранить эту проблему, используйте реестр для изменения связанных параметров, влияющих на подключение к контроллеру домена. Для этого выполните указанные ниже действия.

Способ 1

Настройте параметры брандмауэра или политики IPSEC, которые были изменены, чтобы разрешить подключение к контроллеру домена. Эти изменения вносятся в то время, когда клиент получает IP-адрес, но ему требуется больше времени для доступа к контроллеру домена (например, после успешной проверки через Cisco НАК или службы NPS).

Способ 2

Настройте Netlogon для параметра реестра значение, которое будет безопасно за пределами требуемого времени, чтобы разрешить подключение к контроллеру домена.

Это действие является эффективным только в том случае, если у компьютера уже есть IP-адрес. Это относится к сценариям, в которых решение NAP помещает компьютер в сеть карантина. Используйте следующие параметры в качестве рекомендаций.

Подраздел реестра: HKEY_LOCAL_MACHINE Системкуррентконтролсетсервицеснетлогонпараметерс
Имя значения: Експектеддиалупделай
Тип данных: REG_DWORD
Значение данных в секундах (по умолчанию = 0)
Диапазон данных находится в пределах от 0 до 600 секунд (10 минут)

Способ 3

Стек IP пытается проверить IP-адрес, используя широковещательный пакет ARP. Это задерживает время, в течение которого IP-адрес переходит в оперативный режим. Для записи реестра Арпретрикаунт можно задать значение 1, поэтому дожидаться уникальности будет укорочено. Для этого выполните следующие действия:

Откройте редактор реестра.

Выберите следующий подраздел:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpIpParameters

В меню Правка наведите указатель на пункт создатьи выберите значение DWORD.

Щелкните правой кнопкой мыши ArpRetryCount запись реестра и выберите команду изменить.

В поле значение введите 1и нажмите кнопку ОК.

Диапазон данных находится в пределах от 0 до 3 (по умолчанию используется 3).

Закройте редактор реестра.

Способ 4

Уменьшите отрицательный период кэширования Netlogon, изменив NegativeCachePeriod запись реестра в следующем подразделе:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParametersNegativeCachePeriod

После внесения этого изменения служба Netlogon работает неправильно, если контроллеры домена находятся в автономном режиме в течение 45 секунд. Событие 5719 по-прежнему заносится в журнал. Однако это событие не приводит к возникновению каких – либо других существенных проблем. Этот параметр позволяет члену попытаться попытаться использовать контроллеры домена, если процесс завершился сбоем ранее.

Предложение: попробуйте установить небольшое значение (например, три секунды). В средах ЛВС можно использовать значение 0, чтобы отключить отрицательный кэш.

Дополнительные сведения об этом параметре приведены в разделе параметры для минимизации периодического трафика глобальной сети.

Способ 5

Настройте Kerberos для параметра реестра значение, которое будет безопасно за пределами требуемого времени, чтобы разрешить подключение к контроллеру домена. Используйте следующие параметры в качестве рекомендаций.

Этот параметр применяется только к Windows XP и Windows Server 2003 или более ранним версиям этих систем. В Windows Vista и Windows Server 2008 и более поздних версиях используется значение по умолчанию ( 0). Это значение выключает функции протокола UDP для клиента Kerberos.

Подраздел реестра: HKEY_LOCAL_MACHINE Системкуррентконтролсетконтроллсакербероспараметерс
Имя значения: Макспаккетсизе
Тип данных: REG_DWORD
Данные значения: 1
Значение по умолчанию: (зависит от версии системы)

Метод 6

Отключите датчик сетевого подключения для TCP/IP. Для этого добавьте следующее значение в Tcpip подраздел реестра:

Подраздел реестра: HKEY_LOCAL_MACHINE Системкуррентконтролсетсервицесткпиппараметерс
Имя значения: Дисабледхкпмедиасенсе
Тип данных: REG_DWORD
Данные значения: 1
Диапазон значений: Boolean (0 = false, 1 = true)
Значение по умолчанию: 0 (false)

Метод 7

Групповая политика имеет параметры политики для управления временем ожидания обработки политики запуска:

Корпоративная сеть или WLAN:

Папка политики: «Конфигурация компьютера административные шаблоны групповая политика»»
Имя политики: «указать время ожидания при обработке политики запуска»

Внешняя локальная сеть или WLAN:

Папка политики: «Конфигурация компьютера административные шаблоны групповая политика»»
Имя политики: «укажите время ожидания подключения к рабочей области» для обработки политики «

Время, затраченное службой Netlogon для получения рабочего IP-адреса, может быть основой для этого параметра. Для сценариев прямого доступа вы можете измерять типичную задержку, которую ваша база пользователей имеет до установки подключения.

Способ 8

Если DisabledComponents параметр реестра установлен и имеет неправильное значение 0xFFFFFFF, удалите ключ или измените его на предполагаемое значение 0xFF.

Протокол IP версии 6 (IPv6) является обязательной частью Windows Vista и более поздних версий Windows. Мы не рекомендуем отключить IPv6 и его компоненты. В противном случае некоторые компоненты Windows могут работать неправильно. Кроме того, при запуске системы в течение пяти секунд будет выполняться задержка при неправильном отключении протокола IPv6 путем установки DisabledComponents для параметра реестра значения 0xFFFFFFF. Правильным значением является 0xFF.

Способ 9

Это может быть вызвано состоянием гонки между инициализацией сети, поиском контроллера домена и обработки групповой политики. Если сеть недоступна, контроллер домена не будет найден, а обработка групповой политики завершится с ошибками. После загрузки операционной системы и согласования и установки подключения к сети фоновое обновление групповой политики будет успешным.

Вы можете задать значение реестра, чтобы отложить применение групповой политики.

Откройте редактор реестра.

Выберите следующий подраздел:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

В меню Правка наведите указатель на пункт создатьи выберите значение DWORD.

Щелкните правой кнопкой мыши GpNetworkStartTimeoutPolicyValue запись реестра и выберите команду изменить.

В разделе базовыйвыберите десятичное.

В поле значение введите 60, а затем нажмите кнопку ОК.

Выйдите из редактора реестра и перезагрузите компьютер.

Если сценарий запуска групповой политики не запускается, увеличьте значение параметра GpNetworkStartTimeoutPolicyValue реестра.

Дополнительная информация

Если вы можете войти в домен без проблемы, можно спокойно проигнорировать событие с кодом 5719. Так как служба Netlogon может запускаться до готовности сети, компьютер может не иметь возможности определить контроллер домена для входа в систему. Таким образом, в журнале регистрируется событие с ИДЕНТИФИКАТОРом 5719. Однако после того, как сеть будет готова, компьютер повторит попытку найти контроллер домена для входа в систему. В этом случае операция должна быть успешной.

В файле Нетогон. log записи, похожие на приведенные ниже, могут быть занесены в журнал.

DateTime [Critical] : Нлдисковердк: не удается найти DC. DateTime [Critical] : Нлсессионсетуп: Настройка сеанса: не удается выбрать доверенный DC DateTime [прочие параметры] журнал событий: 5719 (1) » » 0xc000005e. DateTime [Session] Впнг: Нлсетстатусклиентсессион: Set Connection Status to c000005e. DateTime [Session] девице NetBT_Tcpip_ <4A47AF53-40D3-4F92-ACDF-9B5E82A50E32>: транспорт добавлен (10.0.64.232) — > ПОЛУЧАЕМый IP-адрес берет >15 секунд.

Другие компоненты, для правильной работы которых требуется подключение контроллера домена, могут сообщать о подобных ошибках. Например, групповая политика не может применяться при запуске системы. В этом случае стартовые сценарии не запускаются. Сбои групповой политики могут относиться к отказу службы Netlogon для обнаружения контроллера домена. Вы можете настроить групповую политику для более быстрого реагирования на Последнее получение сетевого подключения.

Источник

NETLOGON 5719

Все новые темы

event id 5719

Здравствуйте коллеги, есть доменная сеть организации состоящая из 1 леса active directory (назовем ее для понимания CORP1). Локальная сеть соединена с сетью другой (не через инет), территориально рядом расположенной организации, которая в свою очередь тоже состоит из домена ad и леса (CORP2). Раньше оба домена функционировали на 2003 уровне и все это хозяйство администрировалось одними людьми между доменами были настроены доверительные отношения. Теперь сети разграничили, и админятся разными ит отделами и похоже доверительные отношения «упали». На контроллере домена CORP1 периодически бегает ошибка с event id 5719:

Компьютер не может установить безопасный сеанс связи с контроллером домена CORP2 по следующей причине: Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть.
Это может затруднить проверку подлинности. Убедитесь, что компьютер подключен к сети. Если ошибка повторится, обратитесь к администратору домена.
Дополнительные сведения
Если данный компьютер является контроллером указанного домена, он устанавливает безопасный сеанс связи с эмулятором основного контроллера этого домена. В противном случае компьютер устанавливает безопасный сеанс связи с произвольным контроллером данного домена.

Доверительные отношения сейчас снова стали нужны. Есть подозрения что проблема на сетевом уровне т.к. домены не пингуются между собой. Какие порты нужно открыть, что бы все заработало?

Восстановление доверительных отношений в домене

Бывает такая ситуация, что компьютер не может пройти проверку подлинности в домене. Вот несколько примеров:

• После переустановки ОС на рабочей станции машина не может пройти проверку подлинности даже с использованием того же имени компьютера. Поскольку в процессе новой установки ОС генерируется SID-идентификатор и компьютер не знает пароль учетной записи объекта компьютера в домене, он не принадлежит к домену и не может пройти проверку подлинности в домене.
• Компьютер полностью восстановлен из резервной копии и не может пройти проверку подлинности. Возможно, после архивации объект компьютера изменил свой пароль в домене. Компьютеры изменяют свои пароли каждые 30 дней, а структура Active Directory помнит текущий и предыдущий пароль. Если была восстановлена резервная копия компьютера с давно устаревшим паролем, компьютер не сможет пройти проверку подлинности.
• Секрет LSA компьютера давно не синхронизировался с паролем, известным домену. Т.е. компьютер не забыл пароль — просто этот пароль не соответствует реальному паролю в домене. В таком случае компьютер не может пройти проверку подлинности и безопасный канал не будет создан.

Основные признаки возможных неполадок учетной записи компьютера:

• Сообщения при входе в домен указывают, что компьютеру не удалось установить связь с контроллером домена, отсутствует учетная запись компьютера, введен неправильный пароль учетной записи компьютера или потеряно доверие (безопасная связь) между компьютером и доменом.
• Сообщения или события в журнале событий, указывающие аналогичные ошибки или предполагающие неполадки паролей, доверительных отношений, безопасных каналов либо связи с доменом или контроллером домена. Одна из таких ошибок — отказ проверки подлинности с кодом ошибки 3210 в журнале событий компьютера.
• Учетная запись компьютера в Active Directory отсутствует.

Необходимо переустановить учетную запись компьютера. В сети есть рекомендации по такой переустановки: удалить компьютер из домена, чтобы потом повторно присоединить его. Да, это работает, но данный вариант не рекомендуется делать по причине того, что теряется SID-идентификатор и членство компьютера в рабочей группе.

Поэтому необходимо сделать так :

Открыть оснастку Active Directory, выбрать «Пользователи и компьютеры», щелкнуть объект компьютера правой кнопкой мыши и применить команду «Переустановить учетную запись». После этого компьютер следует заново присоединить к домену и перезагрузиться.

Чтобы перезагрузка после сброса безопасного канала не требовалось, нужно использовать либо команду Netdom, либо Nltest.

C помощью учетной записи, относящейся к локальной группе «Администраторы»:

netdom reset Имя_машины /domain Имя_домена /Usero Имя_пользователя /Passwordo

Добрый день! Стоит сервер 2003, который является сервером баз данных в домене. Перестал пинговать как компьютеры в домене по dns-имени, пропал инет, при этом по ip-адресу пинг идет, сеть тоже видит. Но в домен обратно завести нельзя (поддержка сети не установлена или не настроена должным образом). Переустанавливал TCP/IP-протокол, фиксил Winsock ничего не помогает. Проверял программами на вирусы, тоже чисто.:(

Ты не сказал ничего конкретного.
Что есть в списке в св-вах сетевого интерфейса? Протокол TCP/IP, клиент для сетей MS и т.п.
Далее, что в ipconfig /all
Что в netdiag?
Что в nslookup?
Что в tracert?
Что в эвентах?

1.Свойства сетевого интерфейса: клиент для сети Microsoft, балансировка сетевого интерфейса, служба доступа к файлам и принтерам, протокол TCP/IP (IP-адрес, адреса DNS-серверов, WINS-серверов назначены вручную). NETBioS — включенMicrosoft

Настройка протокола IP для Windows

Имя компьютера . . . . . . . . . : sqlrko
Основной DNS-суффикс . . . . . . : udp.org
Тип узла. . . . . . . . . . . . . : гибридный
IP-маршрутизация включена . . . . : нет
WINS-прокси включен . . . . . . . : нет
Порядок просмотра суффиксов DNS . : udp.org

Подключение по локальной сети — Ethernet адаптер:

DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : Intel(R) 82559 Fast Ethernet сетевой
адаптер интегрированный на материнской плате
Физический адрес. . . . . . . . . : 00-30-48-22-79-73
DHCP включен. . . . . . . . . . . : нет
IP-адрес . . . . . . . . . . . . : 172.16.12.5
Маска подсети . . . . . . . . . . : 255.255.0.0
Основной шлюз . . . . . . . . . . : 172.16.11.11
DNS-серверы . . . . . . . . . . . : 172.16.12.1
172.16.12.2
Основной WINS-сервер . . . . . . : 172.16.12.1
Дополнительный WINS-сервер. . . . : 172.16.12.2

3.При использовании команды tracert вот такая лажа:

C:Documents and SettingsАдминистратор>tracert ya.ru
Не удается разрешить системное имя узла ya.ru.

4.Команда netdiag выдает следующее:

C:Documents and SettingsАдминистратор>netdiag /d:DC1

Computer Name: SQLRKO
DNS Host Name: sqlrko.udp.org
System info : Microsoft Windows Server 2003 (Build 3790)
Processor : x86 Family 6 Model 11 Stepping 1, GenuineIntel
List of installed hotfixes :
Q147222

Netcard queries test . . . . . . . : Passed
GetStats failed for ‘╧Ё ьющ ярЁрыыхы№э√щ яюЁЄ’. ERROR_NOT_SUPPORTED
WARNING The net card ‘╠шэшяюЁЄ WAN (PPTP)’ may not be working because it
as not received any packets.
WARNING The net card ‘╠шэшяюЁЄ WAN (PPPoE)’ may not be working because it
has not received any packets.
WARNING The net card ‘╠шэшяюЁЄ WAN (IP)’ may not be working because it ha
not received any packets.
GetStats failed for ‘╠шэшяюЁЄ WAN (L2TP)’. ERROR_NOT_SUPPORTED

Per interface results:

Adapter : ╧юфъы■ўхэшх яю ыюъры№эющ ёхЄш

Netcard queries test . . . : Passed

Host Name. . . . . . . . . : sqlrko
IP Address . . . . . . . . : 172.16.12.5
Subnet Mask. . . . . . . . : 255.255.0.0
Default Gateway. . . . . . : 172.16.11.11
Primary WINS Server. . . . : 172.16.12.1
Secondary WINS Server. . . : 172.16.12.2
Dns Servers. . . . . . . . : 172.16.12.1
172.16.12.2

AutoConfiguration results. . . . . . : Passed

Default gateway test . . . : Passed

NetBT name test. . . . . . : Passed
WARNING At least one of the ‘WorkStation Service’, ‘Messeng
r Service’, ‘WINS’ names is missing.

WINS service test. . . . . : Passed

Domain membership test . . . . . . : Passed

NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_
1 NetBt transport currently configured.

Autonet address test . . . . . . . : Passed

IP loopback ping test. . . . . . . : Passed

Default gateway test . . . . . . . : Passed

NetBT name test. . . . . . . . . . : Passed
WARNING You don’t have a single interface with the ‘WorkStation Serv
ce’, ‘Messenger Service’, ‘WINS’ names defined.

Winsock test . . . . . . . . . . . : Passed

DNS test . . . . . . . . . . . . . : Passed

Redir and Browser test . . . . . . : Failed
List of NetBt transports currently bound to the Redir
NetBT_Tcpip_
The redir is bound to 1 NetBt transport.

List of NetBt transports currently bound to the browser
NetBT_Tcpip_
The browser is bound to 1 NetBt transport.
FATAL Cannot send mailslot message to ‘DC1*MAILSLOTNETNETLOGON’ via
edir. ERROR_BAD_NETPATH

DC discovery test. . . . . . . . . : Passed

DC list test . . . . . . . . . . . : Failed
‘DC1’: Cannot find DC to get DC list from test skipped.
‘UDP’: No DCs are up.

Trust relationship test. . . . . . : Failed
‘UDP’: No DCs are up (Cannot run test).
FATAL Secure channel to domain ‘UDP’ is broken. ERROR_NO_LOGON_SERVERS

Kerberos test. . . . . . . . . . . : Skipped

LDAP test. . . . . . . . . . . . . : Failed
Cannot find DC to run LDAP tests on. The error occurred was: ╙ърчрээ√щ фюьх
эх ёє∙хёЄтєхЄ шыш ъ эхьє эхтючьюцэю яюфъы■ўшЄ№ё .

This computer cannot be joined to the DC1 domain because of one of the
following reasons.

1. The DNS SRV record for DC1 is not registered in DNS; or

2. A zone from the following list of DNS zones does not include delegation
to its child zone.

Such zones can include _ldap._tcp.dc._msdcs.DC1, and root zone.

Ask your network/DNS administrator to perform the following actions: To
find out why the SRV record for DC1 is not registered in the DNS,
run the dcdiag command prompt tool with the command RegisterInDNS on the
domain controller that did not perform the registration.
WARNING Cannot find DC in domain ‘DC1’. ERROR_NO_SUCH_DOMAIN
WARNING Failed to query SPN registration on DC ‘dc2.udp.org’.
WARNING Failed to query SPN registration on DC ‘dc1.udp.org’.

Bindings test. . . . . . . . . . . : Passed

WAN configuration test . . . . . . : Skipped
No active remote access connections.

Modem diagnostics test . . . . . . : Passed

IP Security test . . . . . . . . . : Skipped

Note: run «netsh ipsec dynamic show /?» for more detailed information

The command completed successfully

5.Команда nslookup
C:Documents and SettingsАдминистратор>nslookup dc1
Server: dc1.udp.org
Address: 172.16.12.1

Name: dc1.udp.org
Address: 172.16.12.1

C:Documents and SettingsАдминистратор>nslookup ya.ru
Server: dc1.udp.org
Address: 172.16.12.1

Non-authoritative answer:
Name: ya.ru
Addresses: 87.250.250.3, 87.250.250.203, 87.250.251.3, 93.158.134.3
93.158.134.203, 213.180.193.3, 213.180.204.3, 77.88.21.3

Проверку работоспособности DNS-сервера проходит

6.В событиях ничего особенного, периодически вываливается ошибка с кодом 5719:
Компьютер не может установить безопасный сеанс связи с контроллером домена UDP по следующей причине:
Сервер RPC недоступен.

Также падают перманентно службы, причем разные как сервера SQL, так и такие Сервер, Обозреватель компьютеров и т.д.

1. перезапустите службы на dc1 netlogon, dns
2. Проверьте SRV записи в DNS на DC.
3. Проверьте на зверей sql сервер, раз периодически падают службы, они могли там поселиться.

Тебя не смущает, что нет связи с контроллером домена? Как правило, днсом настраивают его, а уже на нём организуют пересылку на провайдерские днс-сервера.

Компьютер не может установить безопасный сеанс связи с контроллером домена код 5719

Сообщения: 11
Благодарности: 0

Добрый день!
Раз в сутки начинает глючить интернет. Страницы грузятся через раз, в браузере появляется сообщение
http://s017.radikal.ru/i414/1411/a2/06c57e25fa30.jpg
На сервере с TMG в логах системы все начинается с появления ошибки:
Компьютер не может установить безопасный сеанс связи с контроллером домена GROUP по следующей причине:
Сервер RPC недоступен.
Это может затруднить проверку подлинности. Убедитесь, что компьютер подключен к сети. Если ошибка повторится, обратитесь к администратору домена.
Дополнительные сведения
Если данный компьютер является контроллером указанного домена, он устанавливает безопасный сеанс связи с эмулятором основного контроллера этого домена. В противном случае компьютер устанавливает безопасный сеанс связи с произвольным контроллером данного домена.

Все это происходит примерно в один период времени первый день:
Microsoft Forefront TMG Web Proxy
14198 — в 11-50
Ошибка фильтра веб-прокси при создании сетевого сокета из-за отсутствия доступных портов на компьютере. Forefront TMG уже установил максимальное количество портов равным 65535. Убедитесь, что это значение установлено в ключе HKLMSystemCurrentControlSetServicesTcpIpParametersMaxUsePort, и перезагрузите компьютер для вступления изменений в силу.
NETLOGON 5719 в 12-00
Microsoft Forefront TMG Web Proxy
31524 в 12-03
При попытке подключиться к серверу Microsoft Reputation Service произошла ошибка. Если этот сервер Forefront TMG соединен с вышестоящим сервером, убедитесь, что для веб-прокси WinHTTP задано значение «localhost». Если эта ошибка повторится, проверьте подключение к Интернету.

2й- Microsoft Forefront TMG Web Proxy в 11:55
14198
Ошибка фильтра веб-прокси при создании сетевого сокета из-за отсутствия доступных портов на компьютере. Forefront TMG уже установил максимальное количество портов равным 65535. Убедитесь, что это значение установлено в ключе HKLMSystemCurrentControlSetServicesTcpIpParametersMaxUsePort, и перезагрузите компьютер для вступления изменений в силу.
Microsoft Forefront TMG Web Proxy в 11:59
При попытке подключиться к серверу Microsoft Reputation Service произошла ошибка. Если этот сервер Forefront TMG соединен с вышестоящим сервером, убедитесь, что для веб-прокси WinHTTP задано значение «localhost». Если эта ошибка повторится, проверьте подключение к Интернету.
NETLOGON 5719 в 12:06
Schannel 36888 в 12:17
GroupPolicy 1058 — 12:18

3й- NETLOGON 5719 в 12:29
Microsoft Forefront TMG Web Proxy 31524 — 12:36

4-й — Microsoft Forefront TMG Web Proxy 14198 в 12:11
Ошибка фильтра веб-прокси при создании сетевого сокета из-за отсутствия доступных портов на компьютере. Forefront TMG уже установил максимальное количество портов равным 65535. Убедитесь, что это значение установлено в ключе HKLMSystemCurrentControlSetServicesTcpIpParametersMaxUsePort, и перезагрузите компьютер для вступления изменений в силу.
Schannel 36888 — 12:15
Microsoft Forefront TMG Web Proxy 31524 в 12:16
NETLOGON 5719 в 12:16

Делаю rpcping до домена, проходит тоже через раз, когда не проходит пишет следующий ответ:
http://s004.radikal.ru/i205/1411/c5/ab8ed6698d2c.jpg
В TMG выдает ошибку синхронизации:
http://s61.radikal.ru/i171/1411/f0/70bd9b7ee62a.jpg
но через 2-3 минуты все синхронизируется, но инет так же глючит
При попытке сохранить какие либо изменения в TMG выпадает ошибка:
http://s019.radikal.ru/i632/1411/7d/a9267ffa0f92.jpg
Если пару раз нажать «Продолжить», то сохраняет.

Помогает только перезагрузка, после нее все работает нормально никаких ошибко нет и интернет не глючит, но все это примерно на сутки , потом ситуация повтоярется
Может быть кто-нибудь знает , как это исправить?

Пропадают доверия между доменами

После долгого поиска по интернету решил написать сюда.

Вообщем ситуация такая:
Есть главный офис (к примеру office.contora.com) и есть доп офисы (к примеру dop_office.contora.com).
На контроллере в главном офисе сыпятся ошибки (NETLOGON 5719 ) :»Компьютер не может установить безопасный сеанс связи с контроллером домена dop_office.contora.com по следующей причине: Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть. Это может затруднить проверку подлинности. Убедитесь, что компьютер подключен к сети. Если ошибка повторится, обратитесь к администратору домена.
Дополнительные сведения
Если данный компьютер является контроллером указанного домена, он устанавливает безопасный сеанс связи с эмулятором основного контроллера этого домена. В противном случае компьютер устанавливает безопасный сеанс связи с произвольным контроллером данного домена.»

В такие моменты,как правило, сетевые ресурсы расположенные в главном офисе не доступны из доп офисов. Оно и понятно. Если проверить в данный момент доверия то получаю 2 типа ошибок:
— «Локальному администратору безопасности не удаётся получить подключение RPC к контроллеру домена Active Directory dop_office.contora.com Убедитесь что имя можно разрешить и что сервер доступен «

Доверительные отношения между доменами
Приветствую. Сложилась ситуация: имеется домен под именем 005.027.xxx.ru (единственный домен в.

Настройка репликации между доменами
Здравствуйте)) Хочу задать вопрос и если можно то подскажите что можно сделать)) Опишу ситуацию. У.

Доверительные отношения между доменами
Есть три домена со следующей схемой доверительных отношений. Вопрос: можно ли вручную настроить.

Различие между доменами
Всем привет! Интересует такой вопрос, это разные домены или считаются как один.

Обмен данными между доменами
Как осуществить обмен данными между вкладками с разными доменами. Допустим: На site1.ru в.

Не ходит почта между доменами
Есть 2 домена /D1 и /D2 . Не ходит почта между ними . что я еще не настроил . что еще смотреть.

Связь между доменами (bind)
Добрый день, есть проблема: Есть подсеть 10.0.2.0/24, и в ней есть 3 компьютера 10.0.2.1.

Передача сессии между доменами
Есть два домена: example.com auth.example.com как сделать чтобы сессию созданную на.

title	description	ms.date	author	ms.author	manager	audience	ms.topic	ms.prod	localization_priority	ms.reviewer	ms.custom	ms.technology
Netlogon event ID 5719 or Group Policy event 1129	Event ID 5719 or Group Policy event 1129 is logged if you have a Gigabit network adapter installed on a Windows-based compute. Provides a resolution.	9/24/2021	Deland-Han	delhan	dcscontentpm	itpro	troubleshooting	windows-server	medium	kaushika, herbertm, v-jomcc	sap:problems-applying-group-policy-objects-to-users-or-computers, csstroubleshoot	windows-server-group-policy

Netlogon event ID 5719 or Group Policy event 1129 is logged when you start a domain member

This article solves the Netlogon event ID 5719 or Group Policy event 1129 that’s logged when you start a domain member.

Applies to:   Windows 10 — all editions, Windows Server 2012 R2
Original KB number:   938449

Symptoms

[!IMPORTANT]
Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you modify it, back up the registry for restoration in case problems occur.

Consider this scenario:

• You have a computer that’s running Windows 10 or Windows Server 2012 R2.
• The computer is joined to a domain.
• One of these conditions is true:
  • The computer has a Gigabit network adapter installed.
  • You secure the network access by using Network Access Protection (NAP), network authentication (by using 802.1x), or another method.

In this scenario, the following event is logged in the System log when you start the computer in Windows 8.1 and earlier versions. In Windows 10 and later versions, event 5719 is no longer logged in this situation. The following lines are recorded in Netlogon.log instead:

[CRITICAL] [960] CONTOSO: NlSessionSetup: Session setup: cannot pick trusted DC  
[SESSION] [960] No IP addresses present, skipping No DC event log

After this issue occurs, the computer is assigned an IP address:

[SESSION] [960] V6 Winsock Addrs: fe80::5faf:632a:f22c:644a%2 (1) V6WinsockPnpAddresses List used to be empty.  
[SESSION] [960] Winsock Addrs: 10.1.1.80 (1) List used to be empty.

On Windows 10 and later versions, you’ll see only events by components, depending on the Domain Controller connectivity (such as Group Policy). The following entries are recorded in the group policy debug log:

CGPApplicationService::MachinePolicyStartedWaitingOnNetwork.  
CGPMachineStartupConnectivity::CalculateWaitTimeoutFromHistory: Average is 388.
CGPMachineStartupConnectivity::CalculateWaitTimeoutFromHistory: Current is -1.
CGPMachineStartupConnectivity::CalculateWaitTimeoutFromHistory: Taking min of 776 and 30000.  
Waiting for SamSs with timeout 776

NlaQueryNetSignatures returned 1 networks  
NSI Information (Network GUID) : {395DB3C8-CE45-11E5-9739-806E6F6E6963}  
NSI Information (CompartmentId) : 1  
NSI Information (SiteId) : 134217728  
NSI Information (Network Name) :  
NlaGetIntranetCapability failed with 0x15  
There is no domain compartment  
ProcessGPOs(Machine): MyGetUserName failed with 1355.  
Opened query for NLA successfully  
NlaGetIntranetCapability returned Not Ready error. Consider it as NOT intranet capable.  

GPSVC(530.ae0) <DateTime> There is no connectivity  
GPSVC(530.8e0) <DateTime> ApplyGroupPolicy: Getting ready to create background thread GPOThread.

The first section shows the calculation for the time-out to use to bring up the network. It can be based on previous fast startups.

The second section shows that Network Location Awareness (NLA) fails to report a working network within the wait interval that’s allowed, and group policy startup processing fails. The third section shows that the Group Policy engine starts a background procedure, and then waits for one minute after a network becomes available.

Cause

This issue may occur for any of these reasons:

• The Netlogon service starts before the network is ready. The network stack and adapter initialization often start at about the same time. Some network adapters and switches have link arbitration and MAC address uniqueness checks that take longer to complete than the wait time that is set for Netlogon to detect network connectivity.
• Solutions that verify the health of the new network member delay the network connection and your ability to access domain controllers. If you have an automatic Direct Access channel connection enabled, it may also require more time to do than Netlogon allows.
• The 802.1X authentication process delays connections to the domain controllers.
• The client experiences a delay to retrieve an IP address from the DHCP server. It delays the display of the network interface.

Group Policy in Windows Vista and later versions is written to negotiate the network status that has NLA enabled. And it waits for a network that has DC connectivity. However, Group Policy may start prematurely because of a policy application. This situation is especially true when the delay in finding a network alternates between startups.

[!WARNING]
Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

Resolution 1

To resolve this issue, install the most current driver for the Gigabit network adapter. Or, enable the PortFast option on the network switches.

Resolution 2

To resolve this issue, use the registry to change the related settings that affect DC connectivity. To do it, use the following methods.

Method 1

Adjust the firewall settings or IPSEC policies that are changed to allow DC connectivity. These changes are made when the client receives an IP address but requires more time to access a domain controller, for example, after a successful verification through Cisco NAC or Microsoft NPS Services.

Method 2

Configure the Netlogon registry setting to a value that is safely beyond the time that is required allow DC connectivity.

[!NOTE]
This is only effective if the machine already has an IP address. This applies to scenarios where a NAP solution puts the machine into a quarantine network. Use the following settings as guidelines.

Registry subkey: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetlogonParameters
Value Name: ExpectedDialupDelay
Data Type: REG_DWORD
Data Value is in seconds (default= 0 )
Data Range is between 0 and 600 seconds (10 minutes)

For more information, see Settings for minimizing periodic WAN traffic.

Method 3

The IP stack tries to verify the IP address using an ARP broadcast. It delays the time that the IP takes to come online. You can set the ArpRetryCount registry entry to one (1), so the wait for uniqueness is shortened. To do it, follow these steps:

1. Start Registry Editor.

2. Locate and select the following subkey:
   HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpIpParameters

3. On the Edit menu, point to New, and then select DWORD Value.

4. Type ArpRetryCount.

5. Right-click the ArpRetryCount registry entry, and then select Modify.

6. In the Value data box, type 1, and then select OK.

   [!NOTE]
   The Data Range is between 0 and 3 (3 is default).

7. Exit Registry Editor.

Method 4

Reduce the Netlogon negative cache period by changing the NegativeCachePeriod registry entry in the following subkey:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParametersNegativeCachePeriod

After you make this change, the Netlogon service doesn’t behave as if the domain controllers are offline for 45 seconds. The event 5719 is still logged. However, the event doesn’t cause any other significant problems. This setting allows member to try domain controllers earlier if the process failed previously.

Suggestion: Try to set a low value, such as three seconds. In LAN environments, you can use a value of 0 to turn off the negative cache.

For more information about this setting, see Settings for minimizing periodic WAN traffic.

Method 5

Configure the Kerberos registry setting to a value that is safely beyond the time that is required allow DC connectivity. Use the following settings as guidelines.

[!NOTE]
This setting applies only to Windows XP and Windows Server 2003 or earlier versions of these systems. Windows Vista and Windows Server 2008 and later versions use a default value of 0. This value turns off User Datagram Protocol (UDP) functionality for the Kerberos client.

Registry subkey: HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaKerberosParameters
Value name: MaxPacketSize
Data Type: REG_DWORD
Value Data: 1
Default: (depends on the system version)

For more information, see How to force Kerberos to use TCP instead of UDP in Windows.

Method 6

Disable media sense for TCP/IP by adding the following value to the Tcpip registry subkey:

Registry subkey: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters
Value Name: DisableDHCPMediaSense
Data Type: REG_DWORD
Value Data: 1
Value Range: Boolean ( 0 =False, 1 =True)
Default: 0 (False)

For more information, see How to disable the Media Sensing feature for TCP/IP in Windows.

Method 7

Group Policy has policy settings to control the wait time for startup policy processing:

1. Corporate LAN or WLAN:

   Policy Folder: «Computer ConfigurationAdministrative TemplatesSystemGroup Policy»
   Policy Name: «Specify startup policy processing wait time»

2. External LAN or WLAN:

   Policy Folder: «Computer ConfigurationAdministrative TemplatesSystemGroup Policy»
   Policy Name: «Specify workplace connectivity wait time for policy processing»

The time it takes Netlogon to acquire a working IP can be the basis for the setting. For Direct Access scenarios, you can measure the typical delay your user base has until the connection is established.

Method 8

If DisabledComponents registry setting is in place and has an incorrect value of 0xfffffff, either delete the key or change it to the intended value of 0xff.

[!IMPORTANT]
Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and later versions of Windows. We do not recommend that you disable IPv6 or its components. If you do, some Windows components may not function. Additionally, system startup will be delayed for five seconds if IPv6 is disabled incorrectly by setting the DisabledComponents registry setting to a value of 0xfffffff. The correct value is 0xff.

Method 9

The behavior may be caused by a race condition between network initialization, locating a Domain Controller and processing Group Policy. If the network isn’t available, a Domain Controller won’t be located, and Group Policy processing will fail. Once the operating system has loaded and a network link is negotiated and established, background refresh of Group Policy will succeed.

You can set a registry value to delay the application of Group Policy:

1. Start Registry Editor.

2. Locate and select the following subkey:
   HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

3. On the Edit menu, point to New, and then select DWORD Value.

4. Type GpNetworkStartTimeoutPolicyValue.

5. Right-click the GpNetworkStartTimeoutPolicyValue registry entry, and then select Modify.

6. Under Base, select Decimal.

7. In the Value data box, type 60, and then select OK.

8. Exit Registry Editor, and then restart the computer.

9. If the Group Policy startup script doesn’t run, increase the value of the GpNetworkStartTimeoutPolicyValue registry entry.

More information

If you can log on to the domain without a problem, you can safely ignore event ID 5719. Because the Netlogon service may start before the network is ready, the computer may be unable to locate the logon domain controller. Therefore, event ID 5719 is logged. After the network is ready, the computer will try again to locate the logon domain controller. In this situation, the operation should be successful.

In a Netogon.log, entries that resemble the following example may be logged:

DateTime [CRITICAL] <domain>: NlDiscoverDc: Cannot find DC. DateTime [CRITICAL] <domain>: NlSessionSetup: Session setup: cannot pick trusted DC DateTime [MISC] Eventlog: 5719 (1)"<domain>" 0xc000005e ... DateTime [SESSION] WPNG: NlSetStatusClientSession: Set connection status to c000005e ... DateTime [SESSION] DeviceNetBT_Tcpip_{4A47AF53-40D3-4F92-ACDF-9B5E82A50E32}: Transport Added (10.0.64.232) -> Getting a proper IP address takes >15 seconds.

Similar errors might be reported by other components that require Domain Controller connectivity to function correctly. For example, the Group Policy may not be applied at system startup. In this case, startup scripts don’t run. The Group Policy failures may be related to the failure of Netlogon to locate a domain controller. You can set Group Policy to be more responsive to late network connectivity arrival.