Я пытался решить некоторые проблемы синхронизации времени, связанные с двумя контроллерами домена, и, похоже, столкнулся с более серьезной проблемой. Это ужасно.
Обе они являются виртуальными машинами (одна находится на Amazon EC2), что, как мне кажется, может усложнить ситуацию с серверами времени.
Основной контроллер домена со всеми ролями FSMO находится в локальной сети. Я сбрасываю его конфигурацию сервера времени следующим образом (по памяти):
net stop w32time
w23tm /unregister
shutdown /r /t 0
w32tm /register
w32tm /config /manualpeerlist:”0.uk.pool.ntp.org,1.uk.pool.ntp.org,2.uk.pool.ntp.org,3.uk.pool.ntp.org” /syncfromflags:manual /reliable:yes /update
W32tm /config /update
net start w32time
reg QUERY HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v AnnounceFlags
Я проверил, установлен ли он на 0x05, что и было. Выход для ...
w32tm /query /status
Индикатор скачка: 0 (без предупреждения) Уровень: 1 (первичная ссылка - синхронизируется по радиочасам) Точность: -6 (15,625 мс за такт) Задержка корня: 0,0000000 с Распространение корня: 10,0000000 с ReferenceId: 0x4C4F434C (имя источника: "LOCL" ) Время последней успешной синхронизации: 10.04.2012 15:03:27 Источник: Local CMOS Clock Интервал опроса: 6 (64 с)
Хотя это было не то, что было задумано, я подумал, что разберусь с этим после того, как убедился, что удаленный контроллер домена сначала синхронизируется с ним. На контроллере домена удаленной реплики Amazon EC2 (Windows Server 2008 R2 Core) ...
net stop w32time
w32tm /unregister
shutdown /r /t 0
w32time /register
net start w32time
Здесь все идет не так
Произошла системная ошибка 1290.
Не удалось запустить службу, поскольку одна или несколько служб в одном процессе имеют несовместимый параметр типа SID службы. Служба с ограниченным типом SID службы может сосуществовать только в одном процессе с другими службами с ограниченным типом SID. Если тип SID службы для этой службы был только что настроен, необходимо перезапустить процесс размещения, чтобы запустить эту службу.
Я не могу запустить службу w32time. Я попытался сбросить настройки времени и попытался отменить то, что сделал.
Служба Ec2Config также не может запуститься, так как она зависит от службы w32time.
Все решения, которые я видел, связаны с настройками реестра службы телефонии, но поскольку это Server Core, у него нет этой роли, и я не вижу связи между этим и службой времени. w32time работает в группе LocalService, а эта служба телефонии, которой нет в Core, работает в группе NetworkService.
Может ли это иметь какое-то отношение к тому, что процесс (svchost.exe) не может быть запущен как учетная запись домена, поскольку теперь он является контроллером домена, но изначально он работал как локальная группа пользователей или что-то в этом роде?
Кажется, есть много случаев, когда у людей возникает эта проблема, но единственное решение связано с услугой телефонии (не существующей в Core). Кто вообще этим пользуется?
Привет, у меня была точно такая же проблема.
Я использовал сервис fixit от: http://support.microsoft.com/kb/816042
Скопируйте его в установку PDC ядра сервера, щелкните правой кнопкой мыши блок msi и unclicked (в противном случае вы получите доступ к отказам при попытке запустить его).
Запустил msi из основной консоли и перезагрузился.
Затем я установил свои часы как можно точнее (чтобы обеспечить синхронизацию с допустимой разницей во времени между временем локального сервера и временем удаленного сервера времени) и снова ввел свои настройки:
w32tm /config /manualpeerlist:0.europe.pool.ntp.org,0x1 /syncfromflags:manual /reliable:yes /update
Net stop w32time & net start w32time
w32tm /resync
w32tm /query /status
w32tm /monitor
Проблема для меня в том, что я делаю при перезагрузке, настройки возвращаются к состоянию месяц назад !!
С уважением
На серверах, отличных от рабочих групп, вы можете изменить пусковые триггеры
проверьте триггер запуска для w32time:
sc qtriggerinfo w32time
включить его в сети:
sc triggerinfo w32time start/networkon stop/networkoff
больше информации: https://support.microsoft.com/en-us/help/2385818/windows-time-service-doesn-t-start-automatically-on-a-workgroup-comput