У нас есть домен 2008 R2, расположенный на многих сайтах по всему миру, и мы уже довольно давно используем встроенную службу w32tm. Мы обнаружили, что время между устройствами в домене является неточным (порядка секунд).
Что еще более важно, у нас есть некоторые устройства (коммутаторы Cisco), которые помечают серверы времени контроллеров домена как ненормальные и вообще не синхронизируют их время. Cisco заявляет, что insane is used отклоняет серверы NTP с большими смещениями - однако мы и другие пользователи в Интернете обнаружили, что это также делается для сервера SNTP в Windows 2xxx.
Итак, мы начали экспериментировать с заменой службы W32TM настоящей службой NTP, как это статья от Microsoft подразумевает, что это разрешено. Я говорю «подразумевается», поскольку в нем конкретно не упоминаются контроллеры домена, но это статья о том, как работает вся иерархия.
Службу времени Windows (W32Time) можно полностью отключить. Если вы решите реализовать сторонний продукт синхронизации времени, который использует NTP ...
Это избавляет от необходимости перенаправлять наших клиентов
Однако теперь мы получаем ошибки от DCdiag - некоторые из них, вероятно, можно назвать ложноположительными, например, «Служба времени не может быть обнаружена» и ожидаемый результат для этого сообщения «Служба 32Time отключена». Однако мы также получаем в локаторе проверяет сообщение "Сервер, выполняющий роль PDC, не работает"
Итак, мои вопросы: делал ли кто-нибудь такую замену, знает ли кто-нибудь, действительно ли эмулятор PDC полагается на W32Tm. В качестве альтернативы, есть ли лучший способ сделать это? Альтернатива, как мне кажется, - запустить отдельную иерархию NTP, у которой есть проблема с тем, куда я ее помещаю, и тогда у меня есть два известных разных источника часов в домене, и мне нужно перенаправить наши клиентов или дождитесь обновления до 2016.
Это указано как известная ошибка Cisco CSCed13703
http://www.cisco.com/c/en/us/support/docs/ip/network-time-protocol-ntp/108076-ntp-troubleshoot.html
Общие проблемы
Синхронизация со службой времени на основе W32 (большинство реализаций Windows)
W32Time использует простой сетевой протокол времени (SNTP - подсеть NTP) для синхронизации времени. SNTP и NTP используют один и тот же формат сетевых пакетов. Основное различие между SNTP и NTP заключается в том, что SNTP не предоставляет функций проверки ошибок и фильтрации, которые предоставляет NTP. Маршрутизатор и коммутаторы Cisco используют NTP и позволяют выполнять все функции проверки ошибок и фильтрации, предоставляемые NTP v3.
Известная ошибка: CSCed13703 - NTP не синхронизируется, помечает сервер как ненормальный, недействительный
Система IOS может быть неспособна синхронизироваться с NTP-сервером, несмотря на то, что она может передавать и получать пакеты от сервера. Это можно увидеть в системе Windows, в которой запущена служба w32time.
"показать детали ассоциаций ntp" покажет, что сервер помечен как "безумный, недопустимый". Значение "корневой дисперсии" будет рассматриваться как превышающее 1000 мс, что приведет к тому, что реализация IOS NTP отклонит ассоциацию.
Обходной путь: вместо запуска службы w32time в системе Windows используйте NTP 4.x - см. http://www.eecis.udel.edu/~mills/ntp/html/hints/winnt.html
Примечание: ошибка помечена как спам, потому что поведение является нормальным и фактически не может быть «разрешено» как таковое. Другой обходной путь может заключаться в использовании SNTP, поскольку он не связан со значением дисперсии корня, однако это не рекомендуется.
http://www.cisco.com/c/en/us/support/docs/ip/network-time-protocol-ntp/108076-ntp-troubleshoot.html
Windows W32Time показывает, что это реализация SNTP внутри (скорее заявляющая себя NTP). Cisco IOS-NTP, который пытается синхронизироваться с W32Time, получает собственное значение корневой дисперсии, которое отправляет в W32Time, и это оказывается дорогостоящим для синхронизации Cisco IOS-NTP. Поскольку значение корневой дисперсии Cisco IOS-NTP превышает 1000 мс, оно самосинхронизируется (процедура выбора часов). Поскольку маршрутизаторы на базе Cisco IOS выполняют полную RFC-реализацию NTP, они не синхронизируются с сервером SNTP. В этом случае выходные данные команды show ntp association detail показывают, что сервер помечен как ненормальный, недопустимый. Значение корневой дисперсии превышает 1000 мс, что приводит к тому, что реализация Cisco IOS NTP отклоняет ассоциацию. Маршрутизаторы, работающие под управлением Cisco IOS, могут быть неспособны синхронизироваться с сервером NTP, если это система Windows, в которой работает служба W32Time. Если сервер не синхронизирован, маршрутизаторы не могут передавать и получать пакеты от сервера.
Чтобы обойти эту проблему и синхронизировать маршрутизатор на базе Cisco IOS, используйте авторитетный сервер NTP в Интернете, UNIX-сервер, который запускает NTPD или GPS на определенных платформах. В качестве альтернативы вы можете отказаться от запуска службы W32Time в системе Windows. Вместо этого вы можете использовать NTP 4.x. Все версии Windows 2000 и более поздние могут выступать в качестве сервера NTP. Затем другие машины в сети могут использовать сервер NTP для синхронизации своего времени.
Я бы предложил настроить устройства Cisco для синхронизации с time.windows.com вместо того, чтобы реализовывать альтернативный протокол NTP для домена Windows, чтобы переключатели оставались довольными ...
У меня есть некоторый опыт работы с это программное обеспечение. Это портирование GNU NTP на Windows. Он успешно заменил службу W32Time на сервере Windows. Ящики Linux и ПК с W32time настроены на получение источника синхронизации с этого сервера без проблем (у меня их было много, когда ящики Linux должны были синхронизироваться с сервером с W32Time).
Заменить собственный сервис на новый так же просто, как включить GNU NTP и отключить W32Time.
Замена W32Tm на контроллерах домена означает, что домен теряет присутствие серверов 32TM, объявляющих себя доступными - DCDiag будет сообщать об ошибках, и, по крайней мере, некоторые из этих ошибок являются реальными, поэтому невозможно просто заменить W32TM на совместимый со стандартами сервер NTP.
Также все рядовые серверы должны быть перенастроены, это действительно работает, но было обременительным - я не исследовал вручную имитацию рекламы, чтобы устранить необходимость настройки каждого клиента, и мы не используем DHCP, поэтому это также не исследовалось, но, вероятно, возможно.
Альтернатива, которую мы использовали, - развернуть параллельную систему времени NTP. Мы перенастроили контроллеры домена для использования ВСЕХ источников часов (DOMHEIR и NTO) и добавили локальные системы NTP с флагом 8, чтобы указать использование клиентского режима.
Контроллеры домена выбирают локальные источники NTP, а не домен в качестве источника времени, и измеренный джиттер контроллеров домена снизился с 500 мс до 10 мс.
Первоначально мы использовали иерархию NTP с использованием сиротского режима для обработки отключений, а затем переключились на набор аппаратных часов. Поведение домена Windows не изменилось, хотя долгосрочное дрожание домена при использовании аппаратных часов еще предстоит проверить.