Заметки SCCM

Cкрипт ConfigMgr Prerequisites Tool от Nickolaj Andersen. Отличная утилита, которая установит все необходимые системные компоненты.

 

Решение проблемы установки клиента SCCM
Ошибка:
Произошла ошибка DCOM "2147944122" на компьютере PC при попытке активации сервера:
{8BC3F05E-D86B-11D0-A075-00C04FB68820}

Нужно изменить настройки firewall, например через GPO

Section: Computer Configuration\Administrative Templates\Network\

Network Connections\Windows Firewall\Domain Profile\

Policy: Windows Firewall: Allow inbound remote administration exception

Решение различных проблем

При тестировании Active Directory иногда возникает ошибка

Не удалось запросить журнал событий File Replication Service на сервере dc.contoso.com, ошибка 0x6ba
 "Сервер RPC недоступен."
 ......................... DC - не пройдена проверка FrsEvent
 Не удалось запросить журнал событий Directory Service на сервере dc.contoso.com, ошибка 0x6ba
 "Сервер RPC недоступен."
 ......................... DC - не пройдена проверка KccEvent
 Не удалось запросить журнал событий System на сервере dc.contoso.com, ошибка 0x6ba "Сервер RPC недоступен."
 ......................... DC - не пройдена проверка SystemLog

Решение, на контролёре в настройках брандмауэра разрешить:

Удаленное управление журналом событий (RPC)
Удаленное управление журналом событий (RPC-EPMAP)

Устранение неполадок производительности дополнительные сетевые возможности как RSS и NetDMA

 Проверка возможности RSS
  PowerShell---Get-NetAdapterRss

Включение RSS

При загрузке по сети получаем ошибку:

PXE-T04: Illegal operation error.
PXE-E36: Error received from TFTP server

В логах WDS следующая ошибка Microsoft-Windows-Deployment-Services-Diagnostics ID 4101:

The Following Client failed TFTP Download:
Client IP: 192.168.0.17
Filename: smsboot\x86\wdsnbp.com
ErrorCode: 1460
File Size: 30832
Client Port: 2071
Server Port: 58084
Variable Window: false

Оказалось, что MTU для моих интерфейсов по каким-то причинам был изменён на 1300. Изменить MTU:

netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface «имя сетевого подключения» mtu=1500 store=persistent

После изменения MTU на значение по умолчанию — 1500 — установка по сети началась.

Srv.sys should be set to start on demand

NOTE: This BPA message is erroneously produced when the SMB 1.0 feature has been removed from Windows Server 2012.  SMB 1.0 is required for older clients, such as Windows XP.
Set Srv.sys to start on demand. This can be achieved by running the following command from an elevated command prompt:

sc config srv start=demand

 Тем самым вы запрещаете использование Драйвер сервера Server SMB 1.xxx клиенты XP и Server2003 не получат доступ к Общим папкам

Для отмены изменений:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\srv\
REG_DWORD=Start меняем на 2
Get-service srv -проверка состояния
Перезагружаем сервер или  Start-Service srv

Некоторые подразделения в этом домене не защищены от случайного удаления

To protect all existing OUs in your domain from accidental deletion by using the Get-ADOrganizationalUnit and Set-ADOrganizationalUnit cmdlets

1. Click Start, click Administrative Tools, right-click Модуль Active Directory для Windows PowerShell , and then click Run as administrator.
   
2. At the Модуль Active Directory command prompt, type the following command to check with OUs are not protected, and then press ENTER:
   
   Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | ft
   

3. At the Модуль Active Directory command prompt, type the following command to protect the OUs that you identified in Step 2, and then press ENTER:
   
   Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true
   

4. Run the command in Step 2 again to verify the OUs are protected.
   For more information about the Get-ADOrganizationalUnit and Set-ADOrganizationalUnit cmdlets, at the Модуль Active Directory command prompt, type Get-Help Get-ADOrganizationalUnit or Get-Help Set-ADOrganizationalUnit, and then press ENTER.
   

 

 

AD – заметки на память

Узнать какой КД в данный момент используется вашей системой

set logonserver

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

Test-ComputerSecureChannel -Server $DC -Credential $DOMAIN\$USERNAME -Repair

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

 netdom renamecomputer PC-OLDNAME /NewName:NEW-NAME /UserD:domain\administrator /passwordd:* /reboot:15

Проверка сертификатов на контролёре домена
certutil -dcinfo verify

Восстанавливаем состояние GPO по умолчанию

 Dcgpofix /Target:Domain --восстановление Default Domain Policy

 Dcgpofix /Target:DC  --восстановление Default Domain Controllers Policy

Dcgpofix /Target: Both(Оба)

Если в домене присутствуют разные версии Active Directory (например при наличии контроллеров домена с различными версиями Windows)

  

Dcgpofix /ignoreschema

Поиск пользователей в группе.

Get-ADGroupMember "group" -Recursive | Select Name

Поиск пользователей в OU

Get-ADUser -SearchBase 'OU=UNIT,DC=domain,DC=loc' -filter * 

Настройка ведения журнала диагностики событий службы каталогов Active Directory

 Ведение журнала диагностики событий службы каталогов Active Directory

Записи реестра, управляющих ведения журнала диагностики для службы каталогов Active Directory, хранятся в следующем разделе реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Каждый следующие значения REG_DWORD в подразделе диагностики представляет тип события, который может быть записан в журнал событий:

1 Проверка согласованности знаний (KCC)
2 события безопасности
3 ExDS события интерфейса
4 события интерфейса MAPI
5 события репликации
6 мусора
7 внутренней настройки
Доступ к каталогу 8
9 Внутренняя обработка
10 счетчиков производительности
11 инициализации и завершения
12 службы управления
Разрешение имен 13
14 резервного копирования
15 Наладка
16 события интерфейса LDAP
17 установки
18 глобального каталога
19 сообщений между сайтами
20 кэширование групп
21 репликация связанного значения
Клиент RPC 22 DS
Сервер RPC 23 DS
24 DS схемы
Новое в Windows Server 2012:

Уровни ведения журнала

Каждая запись может быть присвоено значение от 0 до 5, и это значение определяет уровень детализации данных события, которые регистрируются. Уровни ведения журнала называются:

• 0 (нет): только критические события и события ошибки заносятся на этом уровне. Это значение по умолчанию для всех операций, и должен быть изменен только в том случае, если возникает проблема, нужно исследовать.
• 1 (минимальная): высокоуровневые события записываются в журнал событий на этом уровне. События могут включать одно сообщение для каждой основной задачи, выполняемой службой. Используйте этот параметр для запуска расследования, когда не известно расположение проблемы.
• 2 (basic)
• 3 (расширенное): этот уровень записи более подробные сведения, чем более низких уровней, например действия, которые выполняются для завершения задачи. Этот параметр следует используйте, если еще проблемы службы или группы категорий.
• 4 (подробный журнал)
• 5 (внутренний): этот уровень заносит в журнал все события, включая строки отладки и изменения конфигурации. Полный журнал службы записывается. Этот параметр следует используйте, если отследить проблему для определенной категории небольшой набор категорий.

Восстанавливаем состояние GPO по умолчанию

В каждом домене Active Directory по умолчанию создаются два объекта групповой политики (Group Policy Object, GPO): Default Domain Policy и Default Domain Controllers Policy. Default Domain Policy назначается на весь домен и определяет в нем политику паролей и учетных записей, а Default Domain Controllers Policy связан с OU Domain Controllers и обеспечивает повышенный уровень безопасности для контроллеров домена.

Эти GPO очень важны, поэтому не рекомендуется вносить в них изменения без крайней необходимости. Так Default Domain Policy рекомендуется использовать только для управления настройками учетных записей, политиками паролей и Керберос, а Default Domain Controllers Policy GPO — для настройки пользовательских прав и политик аудита.
Однако на тот случай, если они повреждены или изменены до полной неработоспособности, есть возможность вернуть их в исходное состояние. Для этого в состав каждой серверной операционной системы начиная с Windows Server 2003 включена утилита Dsgpofix.exe, позволяющая восстановить состояние этих GPO на момент установки.
Чтобы запустить восстановление, достаточно в командной строке выполнить команду Dsgpofix. Запущенная без параметров, она отменяет все изменения объектов групповой политики Default Domain Policy и Default Domain Controllers Policy, причем даже если они были переименованы. Параметр /target позволяет указать, какую из GPO восстанавливать — DC, Domain или Both (оба).
Если в домене присутствуют разные версии Active Directory (например при наличии контроллеров домена с различными версиями Windows), то для совместимости следует использовать ключ /ignoreschema, который игнорирует номер версии схемы AD. В противном случае команда сработает только для одной версии схемы — той, которая используется на контроллере домена с которого ее запустили.
В качестве примера восстановим изменения в Default Domain Policy в домене с разными версиями AD следующей командой:
Dcgpofix /ignoreschema /Target:Domain


И еще один важный момент, который надо учесть при восстановлении Default Domain Controllers Policy GPO. При использовании Dcgpofix некоторые параметры безопасности могут отличаться исходных (создаваемых в процессе установки). В связи с этим сразу после восстановления с помощью Dcgpofix необходимо проверить параметры безопасности вручную. Подробнее о данной проблеме можно узнать здесь.
В заключение скажу, что Microsoft рекомендует использовать Dcgpofix только в аварийных ситуациях, при полном отсутствии резервных копий. Рекомендованный вариант восстановления GPO с помощью резервного копирования описан в этой статье.

Пример делегирование административных полномочий

1. Для начала следует на контроллере домена открыть оснастку «Active Directory – пользователи и компьютеры». Здесь необходимо создать глобальную группу безопасности, члены которой смогут присоединять компьютеры пользователей к домену. Другими словами, эта группа будет выглядеть следующим образом:
   
   
   Рис. 1. Свойства группы, отвечающей за присоединение компьютеров к домену
2. Следующим делом необходимо указать, что компьютеры присоединять к домену могут только лишь пользователи, входящие в созданную на предыдущем этапе глобальную группу безопасности. Для этого следует открыть оснастку «Управление групповой политикой» и перейти к редактору GPME для созданного по умолчанию объекта GPO «Default Domain Controllers Policy», который располагается в подразделении «Domain Controllers».
   В отобразившейся оснастке следует перейти к узлу «Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Локальные политики\Назначение прав пользователей» и локализовать параметр политики, который называется «Добавление рабочих станций к домену». Открыв диалоговое окно данного параметра политики, вы сразу сможете обнаружить, что по умолчанию там указана группа «Прошедшие проверку», благодаря которой присоединять компьютеры к домену может каждый пользователь. Теперь, для того, чтобы разрешить присоединять к домену компьютеры только пользователям из группы безопасности «Поддержка», следует удалить группу, указанную в этом параметре политики по умолчанию, а затем при помощи кнопки «Добавить пользователя или группу» и диалога поиска объектов Active Directory, следует добавить созданную ранее глобальную группу безопасности. Процесс добавления такой группы изображен на следующей иллюстрации:
   
   
   Рис. 2. Изменение группы, отвечающей за присоединение компьютеров к домену
3. Теперь несмотря на то, что немного ранее было описано, в каких сценариях выполняется делегирование, и что в большинстве случаев делегирование выполняется на уровне подразделений, в данном случае для предоставления возможности присоединения компьютеров к домену, нам следует в оснастке «Active Directory – пользователи и компьютеры» вызвать мастер делегирования непосредственно для уровня всего домена. Следовательно, в оснастке «Active Directory – пользователи и компьютеры» необходимо в области дерева самой оснастки вызвать контекстное меню для домена и выбрать опцию «Делегирование управления», как показано ниже:
   
   
   Рис. 3. Вызов мастера делегирования управления
4. На первой странице мастера можно просто ознакомиться с основной задачей данного средства и, ввиду того, что на первой странице нельзя выполнять какие-либо действия, следует просто нажать на кнопку «Далее». На второй странице мастера, странице «Пользователи и группы», нужно локализовать группу, для которой необходимо делегировать управление. В данном примере следует нажать на кнопку «Добавить» и при помощи соответствующего диалога выбрать группу «Поддержка», как показано на следующей иллюстрации:
   
   
   Рис. 4. Добавление группы, для которой выполняется делегирование управления
   После того, как группа будет добавлена, для перехода к следующей странице мастера следует нажать на кнопку «Далее».
5. Страница «Делегируемые задачи» позволяет вам определить конкретные операции, которые должны выполнять в доменных службах Active Directory пользователи или группы пользователей, которые были добавлены на предыдущей странице мастера. Так как в данном примере делегируется задача присоединения компьютеров к домену и такую задачу можно найти в предоставленном списке распространенных задач, следует напротив задачи «Присоединение компьютера к домену» установить флажок и нажать на кнопку «Далее». Стоит обратить внимание на то, что данный мастер позволяет делегировать не только те задачи, которые фигурируют в данном списке, и в том случае, если вы не смогли здесь сразу найти конкретную задачу, нужно будет создавать особую задачу для делегирования. Создание особой задачи будет показано далее в этой статье, а делегирование задачи присоединения компьютера к домену изображено на следующей иллюстрации:
   
   
   Рис. 5. Делегирование задачи присоединения компьютеров к домену для членов группы «Поддержка»
6. На последней странице мастер повторно проинформирует о том, что работа мастера была успешно выполнена и определенной группе пользователей было передано управление для присоединения компьютеров к домену, что, собственно, и являлось поставленной перед нами задачей:
   
   
   Рис. 6. Завершение процесса делегирования управления

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

Пользователь рабочей станции в роли администратора, удаляем через GPO

Идем в AD, выбираем контейнер с нужными нам компьютерами и заходим в его политику. Конфигурация компьютера - Конфигурация Windows - Параметры безопасности.

Выбираем "группы с ограниченным доступом" и добавляем туда доменную группу "Администраторы" . 

В которую мы добавляем группу Администраторы домена, пользователя Администратор, на случай если машина выпадет из домена, то можно будет зайти под локальным администратором. И группу технической поддержки Tech Support, которой не нужны права на домен, но нужны админские права на локальные машины.

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

В связи с примененной нами политикой нам необходимо дать группе "Пользователи" разрешение "Изменить" на папку Program Files. Для этого переходим в параметр "Файловая система" и добавляем папку Program Files. Даем "Пользователям" право на изменение и применяем политику.

При следующей загрузке политика применяться и безобразий в сети будет на порядок меньше.

Удаление “потерявшихся” доменов

Имеется ситуация – в AD домен, 2 контроллера домена. Было настроено давно. С тех пор куда всё это делось непонятно. В общем пропало и не доступно. В связи с этим куча ошибок при репликации о несуществующем домене. Удалить через dcpromo такой домен не получится, так как физического доступа к “пропавшим” контроллерам домена нет. Решается эта проблема довольно просто с помощью ntdsutil.
1. Сначала удаляем “потерявшиеся” контроллеры домена.
2. Потом удаляем “потерявшийся” домен.
3. Удаляем в DNS записи о “потерявшемся” домене.
У меня между шагом 1 и 2 возникла проблема. При попытке удалить домен выскочила ошибка “DsRemoveDsDomainW error 0x2015″. Как это лечить описано здесь.

Дубликаты интегрированных в AD DNS-зон

С проблемой озвученной в заголовке столкнулся в процессе поиска решения проблемы с регистрациями рабочих станций во внутренней DNS-зоне домена. При вводе сервера в домен всё проходило штатно. Через некоторое время сервер переставал пинговаться, а его имя разрешаться в ip-адрес. При просмотре DNS имя сервера не находилось, хотя оно там должно было бы быть. Неприятная ситуация.
Теперь немного теории. Начиная с Windows Server 2003 доступны три варианта репликации DNS-зон с Active Directory:

• “To all DNS servers in the AD forest”. DNS-зона при таком выборе будет реплицироваться на все DNS-серверы леса. Сам объект зоны с записями будет располагаться в разделе ForestDnsZones (полное имя – CN=MicrosoftDNS,DC=ForestDNSZones,DC=domain,DC=com). Репликация зоны будет происходить в рамках всего леса.
• “To all DNS servers in the AD domain”. DNS-зона при таком выборе будет реплицироваться на все DNS-серверы домена. Сам объект зоны с записями будет располагаться в разделе DomainDnsZones (полное имя – CN=MicrosoftDNS,DC=DomainDNSZones,DC=domain,DC=com). Репликация зоны будет происходить в рамках домена.
• “To all domain controllers in the AD domain”. DNS-зона при таком выборе будет реплицироваться на все контроллеры домена в домене. Сам объект зоны с записями будет располагаться в разделе Default Naming Context (полное имя – CN=MicrosoftDNS,CN=System,DC=domain,DC=com). Репликация зоны будет происходить между контроллерами конкретного домена. Этот вариант используется в домене, в котором присутствуют контроллеры домена на базе Windows 2000 Server. Последние не знают о наличии разделов ForestDnsZones/DomainDnsZones, соответственно не могут с ними работать.

Возникает вопрос – а что будет, если некоторая интегрированная с AD DNS-зона будет присутствовать в нескольких разделах приложений:

• У нас имеется домен на базе Windows 2000 Server (которые не знают о наличии разделов ForestDnsZones/DomainDnsZones). При вводе нового контроллера домена на базе Windows Server 2003 мы можем указать для DNS-зоны тип репликации, который не поддерживается старыми контроллерами домена.
• При создании зоны вручную, мы можем выбрать любой из первых двух вариантов репликации. Затем, на другом контроллере домене, не дождавшись пока эта DNS-зона отреплицируется, создать её тоже вручную.
• При вводе нового контроллера домена, автоматически может ставиться роль DNS-сервера. При этом, существующие зоны, находящиеся в разделах ForestDnsZones/DomainDnsZones, будут среплицированы на новый контроллер домена. Ничто не мешает нам, не дождавшись завершения такой репликации, вручную создать эти зоны.

Стоит заметить, что все эти варианты возникают из-за человеческого фактора и они более чем возможны. Таким образом мы можем относительно легко задублировать зоны, что как раз приведёт к эффекту пропадания записей в задублированной зоне. В ADSI Edit выглядеть задублированная зона будет примерно следующим образом:

Записи, начинающиеся с ..InProgress-[GUID], указывают на зоны, репликация которых не смогла завершиться успешно из-за наличия дубликатов с другим номером USN. Записи, содержащие CNF:[GUID], указывают на зоны, содержащие дубликаты в базе AD.
Что с этим делать? Дубликаты необходимо удалить. Проще всего это сделать через ADSI Edit, удалив записи, которые содержат ..InProgress-[GUID] и CNF:[GUID].

Полное тестирование Active Directory на ошибки

1. Первым делом нужно запустить общий тест:

netdom query fsmo

dcdiag /e /v /q

dcdiag /n:local /e /v /f:c:\adtest.log

Ключи /q можно убрать если нужна информация не только об ошибках.
2. Проверим здоровье DNS серверов. Выполним команду на одном из контроллеров домена:



DCDiag /Test:DNS /e /v /s:controller.contoso.com >DcdiagDNS.txt

дальше полученный отчет открываем:

notepad dcdiagdns.txt

Если всё хорошо то увидим везде слово PASS:

Если полученные ошибки ручками не получается поправить - пробуем:

DCDiag /Test:DNS /e /v /s:controller.contoso.com /fix

А также ipconfig /registerdns на контроллерах.

3. Теперь проверим здоровье репликации Active Directory.

Запускаем общую проверку статуса репликации на контроллере:

repadmin /replsum

Получаем:

 Если значение наиб. дельты не боле часа - с репликацией всё в порядке. Количество сбоев должно быть равно 0.

Если же возникли ошибки то можно использовать следующую команду чтобы посмотреть какой контекст наименования не реплицируется:

repadmin /showreps

Получим такой вывод:

4. Диагностика службы времени.

Общая проверка синхронности часов на контроллерах:

w32tm /monitor

Получим:

Смещение не должно быть больше или меньше 0 целых на всех контроллерах. В нашем случае +2 секунды на одном из них. Как это исправить читаем тут.

5. Диагностика групповых политик.

Сначала проверим расшаренные папки SYSVOL и Netlogon. Через них распространяются групповые политики.

Проверим расшарены ли эти папки. На каждом контроллере домена:

net share

Получаем такой результат:

Всё в порядке шАры на месте.

Теперь тест dcdiag:

dcdiag /test:netlogons

Если тест пройден увидим следующее:

В этом случае с шарами всё в порядке.

Чтобы проверить применяются ли GPO можно запустить мастер результатов групповой политики из оснастки Управление групповой политикой (GPMC). Либо выполнить следующую команду:

gpresult /user domainuser /z >gpresult.txt поправить тут

notepad gpresult.txt

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

Миграция главного контроллера домена с Windows Server 2008 R2 на Windows Server 2012 R2

Узнать кто у нас кто в домене можно командой:

netdom query /domain:%userdomain% fsmo

Как переносить роли контроллеров домена:

Делается это с помощью команды ntdsutil. Запускать ее мы будем на %servername%, т.е. сервере, который хотим сделать самым главным.

После запуска утилиты вводим заклинания:
1.roles - будем управлять владельцами NTDS ролей
2.connections - будем подключаться к какой AD DS
3.connect to server %servername% - подключаемся к серверу %servername%.
4.q - выходим из режима подключений
5.? - смотрим что мы можем делать
6.transfer infrastructure master
7.transfer naming master
8.transfer PDC
9.transfer RID master
10.transfer schema master
11.выходим из утилиты набрав два раза q.


Перенос контроллера домена с 2008 R2 на 2012 Core

1. Сначала присоединим компьютер к домену.

Логинимся в командную строку и выполняем команду:
netdom join localhost /Domain:domen.ru /UserD:domainadmin /PasswordD:[password] /Reboot:0

Или тоже самое но на Powershell

Add-computer -DomainName Contoso.com -Credential Contoso\Administrator -Restart

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

Set-ExecutionPolicy remotesigned

2. Теперь как простой вариант - через удаленный Server Manager запускаем установку ролей



3. Выбираем роль AD DS.



4. После установки выполнеяем команду PowerShell (можно удаленно):

Install-ADDSDomainController -DomainName domain.com -InstallDNS:$True –Credential (Get-Credential)

Эта команда заменяет dcpromo из 2008 версии сервера и старее. В процессе спросят пароль восстановления и учетные данные администратора домена.



Ждем сообщения о том что всё окончено



5. Перезагружаем сервер и переносим все пять ролей FSMO одной командой:

Move-ADDirectoryServerOperationMasterRole -Identity "NEWDOMAINCONTROLLERNAME" –OperationMasterRole 0,1,2,3,4

Избранные же роли можно перенести этой же командой исходя из того что цифры значат:

Operation Master Role Name Number

PDCEmulator 0

RIDMaster 1

InfrastructureMaster 2

SchemaMaster 3

DomainNamingMaster 4

6. Проверить что роли перенеслись как надо можно локально на любом котроллере в этом домене командой:

netdom query fsmo

7. Чтобы перенсти глобальный каталог в ServerManager открыть сайты и службы сервера:



8. Дальше действовать как описано тут http://support.microsoft.com/kb/313994/ru

9. Не забыть реплицировать DNS если они хранились не в Active Directory.

10. Погасить старый домен контроллер и проверить как будет сеть функционировать без него.

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

Конфигурация NTP-сервера на корневом PDC

Конфигурирование сервера времени (NTP-сервера) может осуществляться как с помощью утилиты командной строки w32tm, так и через реестр.

1.Включение синхронизации внутренних часов с внешним источником
♦[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
"Type"="NTP"
♦w32tm /config /syncfromflags:manual

2.Объявление NTP-сервера в качестве надежного
♦[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config] "AnnounceFlags"=dword:0000000a
♦w32tm /config /reliable:yes

3.Включение NTP-сервера
NTP-сервер по умолчанию включен на всех контроллерах домена, однако его можно включить и на рядовых серверах.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer]
"Enabled"=dword:00000001

4.Задание списка внешних источников для синхронизации
♦[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
"NtpServer"="time.nist.gov,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8"
♦w32tm /config /manualpeerlist:"time.nist.gov,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8"


Все одной строкой

w32tm.exe /config /manualpeerlist:"time.nist.gov,0x8 time.windows.com,0x8 ntp1.vniiftri.ru,0x8 ntp21.vniiftri.ru,0x8 pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update

Полезные команды
•Применение внесенных в конфигурацию службы времени изменений
w32tm /config /update
•Принудительная синхронизация от источника
w32tm /resync /rediscover
•Отображение состояния синхронизации контроллеров домена в домене
w32tm /monitor
•Отображение текущих источников синхронизации и их статуса
w32tm /query /peers

Ну и на крайний случай :(
w32tm /unregister — удаляет службу времени с компьютера.
w32tm /register – регистрирует службу времени на компьютере. При этом создается заново вся ветка параметров в реестре.


Особенности виртуализированных контроллеров домена

Контроллеры домена, работающие в виртуализированной среде, требуют к себе особенного отношения.
•Средства синхронизации времени виртуальной машины и хостовой ОС должны быть выключены. Во всех адекватных системах виртуализации (Microsoft, vmWare и т. д.) присутствуют компоненты интеграции гостевой ОС с хостовой, которые значительно повышают производительность и управляемость гостевой системой. Среди этих компонентов всегда есть средство синхронизации времени гостевой ОС с хостовой, которое очень полезно для рядовых машин, но противопоказано для контроллеров домена. Потому как в этом случае весьма вероятен цикл, при котором контроллер домена и хостовая ОС будут синхронизировать друг друга. Последствия печальны.
•Для корневого PDC синхронизация с внешним источником должна быть настроена всегда. В виртуальной среде часы не настолько точны как в физической, потому как виртуальная машина работает с виртуальным процессором и прерываниями, для которых характерно как замедление, так и ускорение относительно «обычной» частоты. Если не настроить синхронизацию виртуализированного корневого PDC с внешним источником, время на всех компьютерах предприятия может убегать/отставать на пару часов в сутки. Не трудно представить неприятности, которые может принести такое поведение.