Разное

Репликация sysvol: Перенос репликации SYSVOL в репликацию DFS

Содержание

Перенос репликации SYSVOL в репликацию DFS

  • Чтение занимает 2 мин

В этой статье

Обновлено: 25 августа 2010 г.Updated: August 25, 2010

Область применения. Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 и Windows Server 2008Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, and Windows Server 2008

Контроллеры домена используют специальную общую папку с именем SYSVOL для репликации скриптов входа в систему и файлов объекта групповой политики на другие контроллеры домена.Domain controllers use a special shared folder named SYSVOL to replicate logon scripts and Group Policy object files to other domain controllers.

Windows 2000 Server и Windows Server 2003 используют для репликации SYSVOL службу репликации файлов (FRS), тогда как Windows Server 2008 использует более новую службу «Репликация DFS» в доменах с режимом работы Windows Server 2008, или FRS для доменов с более старыми режимами работы.Windows 2000 Server and Windows Server 2003 use File Replication Service (FRS) to replicate SYSVOL, whereas Windows Server 2008 uses the newer DFS Replication service when in domains that use the Windows Server 2008 domain functional level, and FRS for domains that run older domain functional levels.

Чтобы использовать репликацию DFS для репликации папки SYSVOL, вы можете создать новый домен с режимом работы Windows Server 2008 либо выполнить описанную в этом документе процедуру, которая обновит существующий домен и перенесет репликацию в службу «Репликация DFS».To use DFS Replication to replicate the SYSVOL folder, you can either create a new domain that uses the Windows Server 2008 domain functional level, or you can use the procedure that is discussed in this document to upgrade an existing domain and migrate replication to DFS Replication.

В этом документе предполагается, что у вас есть базовые знания о доменных службах Active Directory (AD DS), FRS и репликации DFS (репликация распределенной файловой системы).This document assumes that you have a basic knowledge of Active Directory Domain Services (AD DS), FRS, and Distributed File System Replication (DFS Replication). Дополнительные сведения см. в статьях Обзор доменных служб Active Directory, Обзор FRS и (или) Обзор репликации DFS.For more information, see Active Directory Domain Services Overview, FRS Overview, or Overview of DFS Replication

В данном руководствеIn this guide

Концептуальные сведения о миграции SYSVOLSYSVOL Migration Conceptual Information

Процедура миграции SYSVOLSYSVOL Migration Procedure

Устранение неполадок при миграции SYSVOLTroubleshooting SYSVOL Migration

Справочная информация о миграции SYSVOLSYSVOL Migration Reference Information

Дополнительная справкаAdditional references

Серия о миграции SYSVOL. Часть 1. Общие сведения о процессе миграции SYSVOLSYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process

Серия о миграции SYSVOL. Часть 2. Dfsrmig.exe: средство миграции SYSVOLSYSVOL Migration Series: Part 2 – Dfsrmig.exe: The SYSVOL migration tool

Серия о миграции SYSVOL. Часть 3. Переход в состояние PREPAREDSYSVOL Migration Series: Part 3 — Migrating to the ‘PREPARED’ state

Серия о миграции SYSVOL. Часть 4 Переход в состояние REDIRECTEDSYSVOL Migration Series: Part 4 – Migrating to the ‘REDIRECTED’ state

Серия о миграции SYSVOL. Часть 5 Переход в состояние ELIMINATEDSYSVOL Migration Series: Part 5 – Migrating to the ‘ELIMINATED’ state

Пошаговое руководство. Использование распределенной файловой системы в Windows Server 2008Distributed File Systems Step-by-Step Guide for Windows Server 2008

Технический справочник по FRSFRS Technical Reference

Устранение неполадок, отсутствующих в папках SYSVOL и Netlogon для репликации распределенной файловой системы (DFS) — Windows Server

  • Чтение занимает 9 мин

В этой статье

В этой статье данная статья содержит действия по устранению неполадок отсутствующих и обойм в SYSVOL Netlogon Windows Server 2012 R2.

Исходная версия продукта:

  Windows Server 2012 R2, Windows Server 2008 R2 Пакет обновления 1
Исходный номер КБ:   2958414

Симптомы

SYSVOL и Netlogon общий доступ не делиться на контроллере домена. Также могут возникать следующие симптомы или состояния:

  • Папка sysvol пуста.
  • Недавно был повышен затронутый контроллер домена.
  • Среда содержит контроллеры домена под управлением более ранних версий Windows, чем Windows Server 2012 R2.
  • Репликация DFS используется для репликации реплицируемых SYSVOL папок.
  • Служба репликации DFS контроллера домена верхнего уровня находится в состоянии ошибки.

Причина

Контроллеры домена без общего не могут реплицировать входящие из-за того, что контроллеры домена верхнего уровня (исходные) в состоянии SYSVOL ошибки. Часто (но не ограничив его) на серверах с последующим потоком репликация останавливается из-за «грязных» отключений (ид события 2213).

Решение

В этом разделе представлены рекомендуемые методы устранения неполадок и устранения отсутствующих данных и их устранения на контроллерах домена, которые реплицируется с помощью службы SYSVOL Netlogon репликации DFS.

Этот процесс повторно ициализирует репликацию DFS, если она не является общей для контроллеров домена в соответствии с тем, как принудительно принудительно синхронизировать до полномочная или ненужную синхронизацию для SYSVOL с репликацией SYSVOL DFSR (например, «D4/D2» для FRS). В большинстве случаев он не является нужным и может привести к потере данных, если сделать это неправильно. Кроме того, он не позволяет определить причину проблемы и предотвратить ее дальнейшее возникновение.

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

Удаление базы данных репликации DFS из тома не требуется и не рекомендуется. При репликации DFS все локальные данные на сервере считаются неавториативными. Позволяя репликации DFS корректно восстанавливать базу данных (как было подано в событии 2213), последний писатель по-прежнему получит все конфликтующие версии SYSVOL данных.

Шаг 1. Оценка состояния репликации DFS на всех контроллерах домена

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

  • Проверка на факте SYSVOL делиться

    Можно вручную проверить, является ли общий доступ или можно проверить каждый контроллер домена с помощью команды SYSVOL net view:

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo

  • Проверка состояния репликации DFS

    Чтобы проверить состояние репликации DFS на контроллерах домена, можно запросить WMI. Вы можете запросить реплицированную папку для всех контроллеров домена в домене SYSVOL с помощью WMI следующим образом:

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state

    Значения state могут быть любыми из:
    0 = неинициализировано
    1 = инициализировано
    2 = начальная синхронизация
    3 = автоматическое восстановление

    4 = обычный
    5 = Ошибка

    Примечание

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

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

    Если какие-либо контроллеры домена не сообщают о том, что реплицированная папка Share находится в состоянии 4 (обычное), проверьте журнал событий этих контроллеров домена, чтобы оценить SYSVOL их состояние. Просмотрите каждый контроллер домена на предмет последних ошибок или предупреждений в журнале событий репликации DFS, таких как предупреждение с ид 2213, которое указывает, что репликация DFS приостановлена.

  • Проверка конфигурации «Свежесть содержимого»

    Определите, активирует ли репликация DFS защиту свежести содержимого на затронутых контроллерах домена. Обновление содержимого включено на контроллерах домена Windows Server 2012 (и более поздних версий) по умолчанию. Однако его также можно включить вручную на Windows Server 2008 R2 серверах.

    Чтобы оценить, включена ли свежесть содержимого, устанавливается параметр MaxOfflineTimeInDays 60. Если свежесть содержимого отключена, MaxOfflineTimeInDays будет установлено 0. Чтобы MaxOfflineTimeInDays проверить, запустите следующую команду:

    wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

    Чтобы запросить все контроллеры домена в домене, запустите следующую команду:

    For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

    Для каждого контроллера домена, для которых включена свежесть содержимого, оцените, занес ли репликация DFS в журнал событие с ид 4012, которое указывает, что репликация папки остановлена, так как репликация не удалась дольше, чем

    MaxOfflineTimeInDays параметр.

Шаг 2. Подготовка контроллеров домена, которые находятся в состоянии ошибки

  • Установка соответствующих обновлений

    Для всех контроллеров домена, на Windows Server 2008 R2, сначала установите обновления репликации DFS, чтобы предотвратить потерю данных и устранить известные проблемы. Лучше всего использовать последнюю версию репликации DFS. См. список текущих доступных в настоящее время для технологий распределенной файловой системы (DFS) для последней версии репликации DFS.

  • Back up SYSVOL data

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

    В зависимости от ситуации файлы политики могут быть перемещены в папку «Предварительнаяexisting» или «Конфликт» и «Удалено». Предварительное и конфликтное и удаленное содержимое будет удалено, если первоначальная синхронизация проводится несколько раз на сервере. Во избежание потери данных следует сделать их в этих расположениях.

Шаг 3. Восстановление репликации DFS на контроллерах домена в состоянии ошибки

В зависимости от количества контроллеров домена в домене выберите соответствующий метод для восстановления службы репликации DFS.

Для сред с двумя контроллерами домена

Определите, было ли обнаружено «грязный» завершение работы (ид события 2213) на любом контроллере домена. Возможно, второй контроллер домена ожидает завершения инициализации. SYSVOL Причина заключается в том, что после повышения оно регистрирует событие 4614, которое указывает, что репликация DFS ожидает первоначальной репликации. Кроме того, он не будет занося в журнал событие 4604, сигнализируемый о том, что репликация DFS инициализирована. SYSVOL

  • Если на обоих контроллерах домена включена свежесть содержимого

    Если второй контроллер домена ждет начальной синхронизации (событие 4614, зарегистрированное без события 4604), выполните окне «Принудительное принудительное принудительное и недоверяние» для репликации DFSR SYSVOL (например, «D4/D2» для FRS), чтобы установить первый контроллер домена в качестве до полномочного. Второй контроллер домена не нужно настраивать как неавториативный, так как он уже ожидает начальной синхронизации.

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

    1. Back up all SYSVOL contents of the first domain controller.

    2. Оцените, устарели ли данные второго контроллера SYSVOL домена. В этом случае может потребоваться скопировать обновленные файлы на второй контроллер SYSVOL домена с первого контроллера домена. В противном случае все существующие данные, присутствующие на первом контроллере домена, не присутствуют на втором, будут перенаходить в папки «Предэкспресс-система», «Конфликт» и «Удаленные».

    3. Установите первый контроллер домена как неавториативный, отключив членство в how to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like «D4/D2» for FRS). Подтвердим, что событие с ид 4114 занося в журнал, чтобы указать, что членство отключено.

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

  • Если свежесть содержимого не включена или не активна на обоих контроллерах домена

    Если первый контроллер домена находится в состоянии события СД 2213, а второй контроллер домена никогда не завершал инициализацию после его продвижения, а свежесть содержимого не активна. Чтобы сделать следующее:

    1. Запустите ResumeReplication метод WMI на первом контроллере домена, как было подано в событии 2213.

    2. После возобновления репликации она занося в журнал событие 4602, которое указывает, что репликация DFS инициализировала реплицированную папку и указала ее в качестве основного SYSVOL члена.

    3. Выполните команду на втором контроллере домена, чтобы запустить ее для завершения начальной синхронизации dfsrdiag pollad (ид события 4614). После завершения начальной синхронизации регистрируется событие с ИД 4604, инициализация SYSVOL сигналов завершена.

    Или, если первый контроллер домена находится в состоянии 2213, а второй контроллер домена работает (является общим), запустите метод WMI на первом SYSVOL ResumeReplication контроллере домена. По завершении «грязных» отключений будет занося в журнал событие с ид 2214.

Для сред с тремя или более контроллерами домена

Определите, было ли обнаружено «грязный» завершение работы и приостановлена ли репликация DFS на каких-либо контроллерах домена (ид события 2213). Вы можете обнаружить, что контроллер домена ожидает завершения инициализации SYSVOL после повышения. Он регистрирует событие 4614, которое указывает, что репликация DFS ожидает первоначальной репликации. Он также не будет занося в журнал событие 4604, сигнализируемый о том, что репликация DFS инициализирована. SYSVOL

  • Если включена свежесть контента и в домене есть три или более контроллеров домена.

    При защите свежести содержимого занося в журнал событие с ид 4012, которое указывает, что репликация остановлена, так как репликация в папке не удалась дольше, чем MaxOfflineTimeInDays параметр. Чтобы повторно ициализировать репликацию DFS на затронутых контроллерах домена, следуйте инструкциям в инструкциях по принудительной достоверной и не достоверной синхронизации для репликации DFSR SYSVOL (например, «D4/D2» для FRS).

    Если все контроллеры домена занося в журнал событие 4012 и их состояние 5, следуйте инструкциям в инструкции по принудительной инициализации полномочного и не до полномочного синхронизации для репликации DFSR SYSVOL (например, «D4/D2» для FRS). SYSVOL Единственный способ сделать сервер репликации DFS до полномочного сервера. Убедитесь, что контроллер домена, настроенный как полномочная, имеет наиболее последние копии всего SYSVOL содержимого.

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

    1. Back up all SYSVOL contents of the domain controller(s). Обычно изменения политики внося в эмулятор PDC, но это не гарантируется. Все данные, присутствующие на восстановленных контроллерах домена, не совпадающих с партнерами, будут перейти в папку «Предэкспресс-конфликт» или «Удаленные» или оба.

    2. Установите контроллер домена как неавториативный, отключив членство, как описано в описании принудительной достоверной и ненадежной синхронизации для репликации DFSR SYSVOL (например, «D4/D2» для FRS). Необходимо иметь в виду топологию репликации, и необходимо развясти ее из правильного контроллера домена, выбрав прямых партнеров, а затем восстановив последующие контроллеры домена и так далее. Событие с ид 4144 регистрируется для подтверждения отключения членства. Убедитесь, что все контроллеры домена, для которых требуется журнал восстановления события. Может потребоваться принудительно выполнить репликацию Active Directory, а затем выполнить команду на каждом контроллере домена, чтобы быстро определить dfsrdiag pollad отключенное членство.

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

  • Если свежесть контента не включена или не активна, а в домене есть три или более контроллеров домена

    Если защита свежести содержимого не активна, запустите метод WMI на ResumeReplication затронутых контроллерах домена. Необходимо иметь в виду топологию репликации, и необходимо развясти ее из правильного контроллера домена, выбрав прямых партнеров, а затем восстановив последующие контроллеры домена и так далее. После возобновления репликации репликация DFS регистрирует события 2212, 2218, а затем 2214 (указывая, что репликация DFS инициализировала реплицированную SYSVOL папку).

Предотвращение будущих возникновений проблемы

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

Диспетчер управления службами (SCM) использует время простоя по умолчанию , 20 секунд для остановки службы. В некоторых сложных реализациях репликации DFS это значение может быть слишком коротким, и репликация DFS останавливается до закрытия соответствующей базы данных. При перезапуске службы репликация DFS обнаруживает это условие, а затем делает восстановление базы данных. WaitToServiceTimeout можно использовать для предоставления репликации DFS большего времени для фиксации изменений в базе данных во время завершения работы. Дополнительные сведения о том, как перезапустить службу DFSR, можно найти в статье С ИД события DFSR 2212.

После восстановления репликации DFS необходимо тщательно отслеживать состояние репликации DFS в среде, чтобы предотвратить SYSVOL этот сценарий. Рекомендуется регулярно проверять журналы событий репликации DFS, собирать отчеты о состоянии репликации DFS и состояние репликации (с помощью запроса WMI в разделе «Проверка состояния репликации DFS» действия 1 «Оценкасостояния репликации DFS на всех контроллерах домена»).

Репликация Active Directory. Часть 1

Еще в 2014 году я начал писать статью о репликации Active Directory, так как тема важная и требует обязательного понимания для работы со службами каталогов. Увы, тогда работа не была завершена. Сегодня же увидел две статьи по данной тематике на ресурсе itband.ru и, с разрешения автора, делаю репост первой статьи.

Репликация Active Directory: Разговор на «Ты»

Одна из главных рекомендаций Microsoft касательно Active Directory Domain Services (ADDS) говорит о необходимости развертывания в производственной среде минимум двух контроллеров домена. Реальная же жизнь показывает, что в средних и крупных компаниях количество контроллеров может достигать нескольких десятков и даже сотен. Когда системный администратор начинает работать в крупной сети на базе ADDS одной из самых важных забот становится репликация Active Directory.

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

Впервые появившись в Windows Server 2000 технология Active Directory (это прежде всего транзакционная база данных содержащая информацию об объектах вашей сети и глубоко интегрированная с системой безопасности Windows) более чем за 9 лет претерпела некоторые изменения, но даже в Windows Server 2008 R2 работает на хорошо зарекомендовавшем себя движке Extensible Storage Engine ( ESE ). Если верить расчетам масштабируемости, данного решения должно хватить даже сетям с несколькими миллионами объектов, а вырасти база, может до 16 террабайт. Сердцем Active Directory является файл NTDS.DIT в котором, собственно говоря, вся информация и хранится. При добавлении второго и последующих контроллеров домена происходит создание копии данного файла, и размещение ее на введенном в строй новом контроллере. Т.е можно сделать четкий вывод: каждый контроллер домена хранит свою версию файла NTDS.DIT.

Важно понимать, что при открытии оснастки для работы с Active Directory, а это может быть Active Directory Пользователи и Компьютеры или как вариант Active Directory Сайты и Сервисы, вы всегда подключаетесь к конкретному контроллеру домена и при желании можете выбрать с каким контроллером работать – это означает, что выработаете с конкретной версией базы данных, которая в данный момент может отличаться от других копий. Естественно создавая учетную запись либо меняя конфигурацию, изменения вносятся только в один файл NTDS. DIT, который находится на контроллере, куда подключена оснастка (или любой другой инструмент управления). После внесения изменений критически важно оповестить другие контроллеры об изменениях и новых данных и как можно скорее произвести синхронизацию. В Active Directory этот процесс синхронизации называется репликацией и в дальнейшем я буду использовать именно этот термин. Особенно важно помнить эти факты, когда вы занимаетесь решением проблем с репликацией Active Directory и вносите изменения в контекст конфигурации AD. Это происходит тоже на конкретном контроллере и с конкретным файлом NTDS.DIT.

Физически NTDS.DIT это просто один файл, но логически он состоит из нескольких разделов (иногда их называют контекстами именования или контекстами репликации), каждый из которых содержит определенную информацию и реплицируется по-своему.

Раздел «Schema» – хранит в себе схему ActiveDirectory, которая описывает, какие объекты могут быть созданы, и что они из себя будут представлять. Меняется реже всего, как правило, при переходе контроллеров на новую операционную систему либо при установке в организации почтовой системы Exchange. Процесс изменения базы данных в контексте схемы чаще всего называют расширением схемы и это не случайно, т.к. отменить эти изменения (например, удалить созданные в этом контексте объекты) невозможно. Репликация раздела осуществляется на все контроллеры домена в лесу Active Directory. Единственный раздел, чья репликация не является мультимастерной. Репликация раздела «Schema» всегда односторонняя и выполняется от контроллера домена, владеющего ролью FSMO Хозяин Схемы, на все оставшиеся контроллеры домена. (Впоследствии оставшиеся контроллеры домена реплицируют информацию своим репликационным партнерам, но источником обновления в этой цепочке репликации всегда будет Хозяин схемы)

Рис. 1 Разделы базы Active Directory

Раздел «Configuration» – содержит информацию о конфигурации Active Directory, в частности описывает, какие и сколько доменов создано, как они между собой связанны, сколько существует сайтов, какие сервисы доступны в организации и просто системные настройки службы каталогов такие как квоты, политики LDAP-запросов, правила неточного поиска, разрешения имен объектов и т. п.. Раздел реплицируется между всеми контроллерами доменов в лесу и может быть изменен на любом контроллере домена. Изменения данного раздела связаны с конфигурированием и настройкой самой Active Directory.

Раздел «Domain» – или доменный. Все учетные записи пользователей, группы безопасности, организационные подразделения, объекты компьютеров и принтеров создаются и хранятся в данном разделе. Реплицируется раздел только между контролерами домена в том домене к которому принадлежит контроллер. Получается, что в организациях, имеющих несколько доменов, в каждом домене будет свой раздел «Domain».

Разделы «Application» – опциональные разделы. Зона репликации зависит от настройки. Как правило, создается два Application раздела, это ForestDNSZones и DomainDNSZones.

· ForestDNSZones – хранит SRV и CNAME записи для Леса AD и реплицируется на все контроллеры домена в лесу, являющиеся DNS серверами.

· DomainDNSZones – содержит DNS записи для зоны домена. Реплицируется на все контроллеры домена с установленным на них DNS сервером.

Посмотреть на каждый раздел каталога и данные в нем хранящиеся можно через утилиты ADSI Edit AdExplorer и LDP.exe. Утилиту (AdExplorer) можно скачать с сайта Microsoft, она входит в комплект утилит Sysinternals. А LDP.exe становится доступна после установки на контроллер домена Windows Support Tools. Следует отметить, что данный комплект не потерял своей актуальности и после выхода Windows Server 2008.

Рис. 2 Выбор раздела для подключения в утилите LDP.exe

Теперь важно уяснить следующее, когда клиент аутентифицируется на контроллере домена, и применяются групповые политики, образуется трафик (85 Кб на вход станции в домен (с Default Domain Policy) и 75Кб на вход пользователя (тоже с Default Domain Policy)). Более того репликация изменений между контроллерами доменов порождает свой репликационный трафик. Этим трафиком нужно управлять, представьте себе, что организация и естественно ваш домен Active Directory располагается в двух городах связанных WAN каналом и однажды все пользователи филиала в Ростове-на-Дону начнут обращаться к контроллеру, расположенному в центральном Московском офисе. А контроллеры домена начнут реплицировать информацию в любое время и по первому желанию. Минимум с чем Вам придется столкнуться это высокая утилизация WAN канала и медленный вход пользователей в домен.

Поэтому в Active Directory введено понятие Сайтов. Сайт это логическое объединение контроллеров домена и клиентов для управления служебным трафиком службы каталогов. Если ваш Лес Active Directory не распространяется за пределы одного сегмента локальной сети, следовательно, вы работаете с односайтовой структурой. Именно она является дефолтной и именно с неё мы начнем разговор.

При создании Active Directory и поднятии (имеется ввиду процедура dcpromo) первого контроллера домена формируется сайт по-умолчанию с именем «Default-First-Site-Namе». Если не создавать дополнительных сайтов и придерживаться односайтовой структуры, все новые контроллеры будут попадать в данных сайт. После появления второго и последующих контроллеров должны образоваться Репликационные связи (connection objects), указывающие на то какой контроллер и откуда должен реплицировать изменения. Посмотреть эти связи можно через оснастку «Active Directory Сайты и Службы».

На Рис.3 открыта оснастка «ActiveDirectoryСайты и Службы» и по имеющейся информации можно сказать, что в данном примере имеется единственный сайт по-умолчанию, в котором находится два контроллера домена Server1 и Server2. А так же, что Server1 имеет партнера по репликации Server2 и реплицирует с него изменения. Без наличия данных связей репликации между контроллерами работать не будет.

Нередки случаи когда системные администраторы, установив новый контроллер домена, не находят у него данных связей и начинают создавать их руками. Это распространенная ошибка. За создание связей, базируясь на определенной логике, отвечает служба KCC (Knowledge Consistency Checker). Созданию связей самостоятельно чревато возникновением ошибок и дальнейшей путаницей. Для тех же, кто не хочет ждать, пока KCC справится с задачей, существует способ ее поторопить.

Рис. 3 Свойства Репликационной связи.

Для этого необходимо использовать утилиту Repadmin с ключом kcc. Синтаксис будет выглядеть следующим образом:

repadmin /kcc server1.itband.ru (Вместо server1.itband.ru вы укажете FQDN вашего сервера)

Если нужно запустить генерацию связей на всех контроллерах домена в сайте, то команда Repadmin принимает вид:

repadmin /kccsite: «Default-First-Site-Name» (Если имя сайта было изменено «Default-First-Site-Name» заменяется реальны именем)

Можно так же запустить процесс генерации топологии на всех контроллерах леса командой repadmin /kcc *. Большинство опций команды repadmin поддерживают ключ /async, который дает задание контроллеру домена и при этом не ожидает его завершения.

Без административного вмешательства служба KCC стартует на каждом контроллере домена раз в 15 минут и в случае необходимости добавляет или удаляет лишние репликационные связи (учтите, что связи, созданные вручную, не управляются KCC). Логика создания связей в рамках одного сайта кажется довольно простой, каждый контроллер не реплицируется с каждым, служба KCC всегда пытается создать кольцо репликации, причем по мере добавления новых контроллеров кольцо будет расширяться. Расширение не бесконечно, при создании связей существует «правило трех прыжков». Это значит, что между двумя контроллерами домена при репликации не может быть больше трех посредников.

Рис. 4 Принцип создание связей репликации службой KCC

Как только число контроллеров достигнет 8 штук, правило «трех прыжков» приведет к тому, что служба KCC выполнит «ход конем» и добавит дополнительные прямые связи, тем самым сокращая расстояние между двумя любыми контроллерами до допустимого значения «максимум в три прыжка». Данная ситуация хорошо проиллюстрирована на рисунке 4. Создание связей между контроллерами расположенными в разных сайтах выполняется с учетом топологии сайтов, сайт-линков и мостов между сайт-линками. Подробнее о построении межсайтовой репликации читайте в разделе «межсайтовая репликация». Следует отметить, что кольцо при построении топологии репликации строиться независимо для каждого контекста репликации (раздела Active Directory) далее эти кольца накладываются друг на друга и выясняется, где можно вместо нескольких репликационных связей – обойтись одной.

Внутрисайтовая репликация начинается, когда в Active Directory происходит изменение, это может быть изменение атрибута или создание учетной записи. Контроллер домена, в базе которого произошли изменения, ожидает 15 секунд, а затем отправляет ближайшему партнеру репликации уведомление о том, что на нем произошло какое-то обновление. При наличии двух и более партнеров по репликации, последующие уведомления отправляются каждому партнеру с 3-секундной задержкой (Верно для уровня леса Windows 2003 и выше, для Windows 2000 первичная задержка составляет 300 секунд, а последующие 45 секунд). После получения уведомления об изменении партнер репликации проверяет возможность репликации и список обновлений и выполняет процесс репликации с тем контроллером, который прислал уведомление. Трех секундная задержка предотвращает чрезмерную загрузку из-за одновременных запросов обновлений от множества партнеров по репликации. Периоды нотификаций можно настроить командой repadmin /notifyopt.

Следует обратить особое внимание читателей, что процесс репликации ВСЕГДА происходит в режиме pull, т.е. «стягивания» изменений и новых объектов, но не в режиме push. Это связано с тем, что только контроллер хозяин файла NTDS.DIT имеет право в нем что-то изменять и отвечает за целостность своей БД. Из этого так же следует, что ВСЕ линки репликации которые, создаются в ручную или службой KCC имеют однонаправленную природу, т.е. логически обозначают входящий поток репликационной информации.

Некоторые изменения реплицируются без 15-секундной задержки. Такая репликация, называемая срочной (urgent replication). В события ее вызывающие входят блокировки учетных записей, изменение пароля учетной записи. В официальных документах присутствует путаница. По сути это не репликация вовсе и механизм передачи этих изменений в коре отличается от процесса репликации. Хотя в качестве транспорта используется тоже протокол RPC. Такая репликация выполняется не обычным механизмом репликации, а специальными вызовами RPC. По сути это запросы аналогичные изменению объектов через ADSI. В зависимости от режима работы леса список событий может меняться.

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

Рис. 5 Расписание репликации

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

При возникновении трудностей с репликацией можно используя утилиту replmon вручную запустить процесс репликации не дожидаясь расписания:

repadmin /replicate server2.itband.ru server1. itband.ru dc=itband,dc=ru

С ключем /replicate необходимо задать куда (server2.itband.ru ) и с какого контроллера (server1.itband.ru ) должны реплицироваться данные, а также какой раздел каталога нужно реплицировать (dc=itband,dc=ru).

Запустить репликацию всех разделов Active Directory в рамках всего леса (в рамках существующей топологии) довольно легко, для это следует выполнить: Repadmin /syncall /AeS. Учтите, что в крупных сетях такой запуск репликации может вызвать серьезный поток трафика, который пойдет не только по скоростным каналам.

Алгоритм распространения изменений

Теперь необходимо разобраться, как после получения репликационного уведомления от партнера контроллер домена решит: Есть или нет изменения необходимые для репликации ? Если есть то, какие объекты или их отдельные атрибуты должны быть прореплицированы. Алгоритм выглядит следующим образом.

Любой контроллер домена ведет некий счетчик называемый «highestCommittedUSN», который увеличивается на единицу при любом атомарном изменении базы Active Directory. При этом у каждого контроллера домена этот счетчик свой и между контроллерами его значения не совпадают. Например, в 9 утра значение «highestCommittedUSN» у контроллера DC1 было равно 14879, а в 6 вечера 14896. Это значит, что за прошедшее время в базе этого контроллера произошло 17 изменений. Посмотреть значение «highestCommittedUSN» можно с помощью утилиты ldp просто подключившись к нужному контроллеру домена. При подключении выводиться состояние динамического системного объекта RootDSE, среди атрибутов которого как раз и присутствует «highestCommittedUSN».

Рис. 6 Просмотр значения «highestCommittedUSN» на контроллере домена.

После проведенной репликации каждый контроллер домена кэширует значения «highestCommittedUSN» своих репликационных партнеров. И когда в последствии контроллер домена DC1 получит уведомление от контроллера DC2 в нем будет информация о текущем «highestCommittedUSN» DC2. Контроллеру DC1 останется только сравнить текущий «highestCommittedUSN» с тем, который он закэшировал во время прошлой репликации. Если он вырос : значит в базе DC2 произошли изменения и необходимо произвести репликацию. Если остался прежним, то в ней нет необходимости.

Таблица, в которой хранится информация о «highestCommittedUSN» репликационных партнеров называется вектором обновления или «up-to-date vector». Посмотреть ее можно с помощью утилиты repadmin.

repadmin /showutdvec dc1 dc=lab,dc=itband,dc=ru

Default-First-Site-NameDC2 @ USN 16667 @ Time 2009-09-21 01:24:15

Default-First-Site-NameDC1 @ USN 20704 @ Time 2009-09-21 01:31:25

В данном примере результатом будет вывод значений «highestCommittedUSN» репликационных партнеров DC1 (а также актуальный USN его самого), при этом это будут значения, о которых DC1 знает, в действительности уже они могли вырасти по причине внесения изменения в базу на тех контроллерах. Следует помнить, что «highestCommittedUSN» увеличивается как после изменений внесенных в базу непосредственно на контроллере, так и после изменений прореплицированных с других контроллеров.

Рис. 7 Просмотр вектора обновлений на контроллере DC1.

Есть одно но, сам по себе «up-to-date vector» отвечает на вопрос «Были ли изменения?». Этого недостаточно, необходимо вычислить что изменилось. Давайте рассмотрим данный механизм на примере.

В нашей сети находится два синхронизированных контроллера домена (DC1и DC2 ). До изменений «highestCommittedUSN» у DC1 равен 20902, а у DC2 16940. На контроллере DC1 создается учетная запись пользователя Федя Рашпин. После создания учетной записи «highestCommittedUSN» на DC1 стал показывать 20909. Это говорит о том, что было произведено 7 изменений. Напоминаю, что считаются атомарные изменения, т.е создание учетной записи можно разложить на само создание плюс изменение ряда атрибутов, которые выполняет оснастка Active Directory Users and Computers.

Если подключиться через LDP.exe к нашему объекту пользователь, то можно увидеть два атрибута uSNCreated и uSNChanged.

Рис. 8 Просмотр атрибутов uSNCreated и uSNChanged для учетной записи.

uSNCreated будет говорить, какой «highestCommittedUSN» был в момент создания объекта на данном контроллере, а uSNChanged в момент последнего изменения. Получается, что первый показатель (uSNCreated) будет оставаться неизменным, а второй в свою очередь (uSNChanged) по мере обновлений объекта будет расти. Важно понимать, что uSNCreated и uSNChanged на каждом контроллере домена у объекта будут свои.

Посмотрим на пользователя Федя через утилиту repadmin. Для получения служебной информации, используемой при репликации задействуем ключ /showmeta.

repadmin /showmeta “CN=Федя Рашпин,OU=testou,DC=lab,DC=itband,DC=ru”

При этом нас интересует информация с каждого контроллера. Но начнем с DC1.

Рис. 9 Вывод метаданных о созданном пользователе на DC1.

Какую же информацию нам дает repadmin (Рис. 9). Данный список не что иное, как объект пользователя, разложенный по атрибутам.

По каждому атрибуту можно увидеть:

· Loc.USN это «highestCommittedUSN» контроллера DC1 в момент внесения последних изменений.

· Originating DC говорит о том, на каком контроллере были произведены последние действия с этим атрибутом, т.е откуда пошло распространение.

· Org.Usn это «highestCommittedUSN» контроллера автора изменений в момент внесения последних.

· Ver – версия атрибута, растет на единицу при каждом его изменении (локально или в результате репликации).

· Attribute – непосредственно название самого атрибута.

Взглянув на эту таблицу можно сделать вывод, что пользователь «Федя Рашпин» был создан (или изменен) на контроллере домена DC1, при этом увидеть, что «highestCommittedUSN» DC1 в процессе создания учетной записи рос от 20904 до 20909. (Org.USN)

Совпадение колонок Loc.USN и Org.USN говорит о том, что запуск repadmin /showmeta произведен на контроллере домена, который был автором изменений. Если выполнить тоже самое на втором контроллере, результат будет несколько другой.

Рис. 10 Вывод метаданных о созданном пользователе на DC2.

На DC2 четко просматривается, что автором всех изменений (кроме одного) был DC1 и его «highestCommittedUSN» (Org.Usn) в момент изменения каждого атрибута. А также «highestCommittedUSN» в момент внесения обновлений в базу контроллера DC2. (Loc.USN)

А вот теперь пора сделать небольшой вывод:

Когда контроллер домена рассылает репликационным партнерам уведомления об обновлении базы, он сообщает свой текущий «highestCommittedUSN». Партнер, получивший это уведомление, сравнивает этот «highestCommittedUSN» с тем, что он запомнил с прошлой процедуры репликации. Если он вырос, значит необходимо запускать репликацию. Например: DC2 получил от DC1 уведомление и текущий «highestCommittedUSN» равный 20912, он сравнивает с известным ему значением 20850. Делает вывод о необходимости репликации и запрашивает изменения, произошедшие в период роста «highestCommittedUSN» с 20850 до 20912.

DC1 осуществляет выборку из своей базы. Для этого просматривается Loc.USN и те атрибуты, которые менялись в заданном диапазоне «highestCommittedUSN» реплицируются на DC2.

Решение конфликтов

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

Правило первое: Можно было заметить в метаданных репликации параметр Ver. Как уже было сказано, он увеличивается на единицу каждый раз при изменении атрибута. Если сразу на двух контроллерах происходит изменение атрибута, в первую очередь будет произведено сравнение номера версии. Атрибут, имеющий более высокий номер версии, является приоритетным. И именно его значение будет использоваться.

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

В такой ситуации будет задействован скрытый контейнер LostAndFound, получить доступ, к которому можно только переключив оснастку «Active Directory – пользователи и компьютеры» в расширенный режим.

Рис. 11 Контейнер LostAndFound.

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

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

Настройка репликации виртуальных машин в Hyper-V на Windows Server 2016

Функционал репликации в Hyper-V позволяет настроить отказоустойчивость ВМ за счет постоянной синхронизации изменений виртуальной машины, запущенной на одном сервере Hyper-V на другой сервер (сервер-партнер по репликации может даже находится в другом датаценте). Репликации в гипервизоре Microsoft Hyper-V реализуется с помощью встроенных средств (никаких дополнительных средств или плагинов устанавливать не нужно). Рассмотрим, как настроить репликацию виртуальной машины между двумя хостами с Windows Server 2016 Hyper-V.

Как включить репликацию ВМ в Windows Server 2016 Hyper-V

Чтобы настроить репликацию конкретной ВМ в Hyper-V Windows Server 2016, просто щелкните правой кнопкой мыши по нужной виртуальной машине и выберите пункт меню Enable Replication.

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

У меня имеется один отдельностоящий хост Hyper-V на Windows Server 2016, одну из виртуальных машин которого я хочу реплицировать на созданный ранее кластер Hyper-V. При реплицаии ВМ на кластер нужно указать имя сервера-брокера — Hyper-V Replica Broker. Это особая кластерная роль, которую нужно настроить на кластере перед настройкой репликации. При попытке настроить репликацию с кластером, у которого отсутствует эта роль, появится ошибка (“The specified replica server is part of a failover cluster”).

Установка роли Hyper-V Replica Broker

Чтобы настроить роль Hyper-V Replica Broker, нужно открыть консоль управления кластером Failover Cluster Manager. Щелкните ПКМ по имени кластера и выберите опцию Configure Role.

Выберите роль Hyper-V Replica Broker.

Нужно указать имя кластерной службы и IP адрес.

На этом все. В Active Directory появится новое имя, а на кластере новая роль.

Настройка репликации виртуальной машины

Еще раз включаем репликацию для ВМ. Указываем имя сервера-брокера репликации Hyper-V. У меня появилось предупреждение:

“The specified Replica server is not configured to receive replication from this server”

В этом случае нужно нажать на кнопку Configure Server для запуска окна настройки брокера в кластере.

Включите опции:

  • Enable this cluster as a Replica server
  • Use Kerberos (HTTP) (либо можно настроить HTTPS аутентификацию — Use certificate-based authentication (HTTPS))
  • Allow replication from any authenticated server (для более безопасного развертывания можно использовать опцию Allow replication from the specified servers. В этом случае можно указать от каких серверов можно принимать репликацию)

Убедитесь, что ваш файервол разрешает входящий трафик по порту 80 — правило Hyper-V Replica HTTP Listener (TCP-In).

Вернемся в окно настройки репликации. Как вы видите, все предупреждения пропали.

Для единообразия с брокером, выберем тип аутентификации Use Kerberos authentication (HTTP).

Затем нужно указать vhdx файлы виртуальной машины, который нужно реплицировать (в моем случае он один).

Выберите частоту выполнения репликации (каждые 30 секунд, 5 или 15 минут).

На следующем шаге можно настроить параметры создания дополнительных снапшотов ВМ.

Затем нужно выбрать метод первичной репликации файла виртуальной машины (Initial replication Method). Можно вручную перенести файлы ВМ на целевой сервер с помощью внешнего диска (если канал между серверами недостаточно быстрый), либо скопировать файл прямо по сети.

Наконец, появится экран с выбранными опциями.

Нажимаем Finish и видим сообщение «Replication is enabled successfully».

Возвращаемся в консоль Hyper-V Manager нашего отдельного хоста (источника репликации) и видим, что для него запущен процесс создания контрольной точки и в статусе ВМ появилась надпись Sending Initial Replication и процент выполнения репликации.

На целевом хосте откроем Failover Cluster Manager. Как вы видите, на нем появилась новая виртуальная машина – реплика исходной ВМ.

Итак, репликации ВМ между двумя хостами Hyper-V в Windows Server 2016 настраивается крайне просто. Благодаря этой возможности можно довольно легко и прозрачно обеспечить катастрофоустойчивость критических виртуальных машин.

 

Debian 10: Установка и настройка Samba Active Directory

Актуализировал тему по настройке Samba 4 в качестве контроллера домена. Ранее я разворачивал Samba в Docker, но в версии 4.11 возникли нюансы с диапазоном пробрасываемых портов со стороны iptables, поэтому использовал классическую установку.

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

Службы каталогов

В любой организации наступает период, когда появляется множество клиентов, серверов, сервисов – всё это требует сложности администрирования: разделение прав, создание\удаление учетных записей. Чем больше народу приходит в компанию, тем больше болит голова у админа. Очевидным решением становится использование службы каталогов – средства иерархического представления ресурсов с централизованным управлением. К сведению, первые службы каталогов появились ещё в 1984 году и продолжили своё развитие в различных вариациях. А когда Microsoft выпустила NTDS  (в дальнейшем переименован в Active Directory), то данный инструмент стал негласным стандартом и одним из самых распространенных в своём классе.

LDAP – протокол, который лёг в основу служб каталогов и используется в различных LDAP-совместимых реализациях служб каталогов. К примеру, таковыми являются (самые популярные и известные):

  • Active Directory;
  • OpenLDAP;
  • Samba Domain;
  • И прочие другие коммерческие.

Все записи LDAP представляются атрибутами в следующем виде:

cn=petrov,ou=office,dc=example,dc=com

где “petrov” – уникальная запись в Object Unit “office” домена example.com

Samba как DC

Но за всё надо платить, ибо самый популярный для таких целей Windows Server с Active Direcory на борту не бесплатный, а потому в последнее время с развитием пакета программ Samba 4 есть возможность использования Samba в качестве контроллера домена с применением групповых политик. О Samba 4 и последующей настройке и будет дальнейшее содержание данной статьи.

По своей сути Samba 4 есть Open-Source реализация Active Directory и, согласно документации, является стабильным вариантом применения в качестве домен-контроллера в production-среде.

Одним из минусов является отсутствие поддержки репликации Sysvol через DFS-R (условно говоря, sysvol – это директория с параметрами групповых политик, сценариев входа\выхода из системы и при использовании нескольких контроллеров домена, должна быть реплицирована на все имеющиеся контроллеры в домене). Samba пока что так не умеет, а потому есть решения с использованием rsync или более сложные и гибкие варианты. Но об этом в данном материале рассказано не будет.

В ранних версиях было ограничение размера БД до 4 гб в Samba при использовании в качестве контроллера домена, но данный вопрос был решён в версии 4.9 – реализован бэкенд LDB (экспериментальный), основанный на библиотеке LMDB, что в итоге позволяет создавать базы данных объемом свыше 4 гб. Для включения данного параметра нужно использовать ключ –backend-store=mdb. В данной статье, дабы не усложнять материал, обойдемся без данного ключа.

Перед установкой

Наименование домена

Перед началом инсталляции необходимо определиться с именем сервера и домена. В рамках данной статьи сервер с Samba на борту будет иметь полное имя (FQDN) dc0.ad.rmn-lux.ru, а сам домен – ad.rmn-lux.ru.

Кратко поясню, почему выбран именно такой формат именования.

  • Никаких названий а-ля PDC или BDC использовать не стоит – это пережитки прошлого;
  • Также не стоит использовать test.local и т.п. домены:
    • подобные имена противоречат rfc 6762
    • для такого домена не получится получить публичный TLS-сертификат
    • такое имя будет недоступно из внешней сети
  • Можно было бы назвать AD домен также, как основной домен сайта. Для примера, в таком случае имя домена было бы как и домен моего сайта – it-lux.ru. Это правильно, но в таком случае пришлось бы следить за публичной и внутренней зоной DNS, что не всегда удобно, т.к. может возникнуть рассинхрон.
  • В качестве имени можно выбрать домен из другой зоны, который не будет конфликтовать с основным доменом. В моём случае это может быть, например, it-lux.online или аналогичный домен в другой доменной зоне.

Исходя из вышесказанного, наиболее правильным, как мне кажется, использовать поддомен ad.rmn-lux.ru для названия домена AD, т.к. это будет консолидировано в рамках одного домена.

AD Schema

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

Информация с оф. сайта Samba по поддержке AD схем:

Windows Server VersionDirectory Schema Version
Windows Server 201687
Windows Server 2012R269
Windows Server 201256
Windows Server 2008R247
Samba VersionHighest Supported Schema Version
4.11 and later69
4. 5 – 4.1069 *
4.0 – 4.447

Последняя стабильно поддерживаемая AD схема в Samba на момент написания данного материала – 69, а подходящая версия Samba для этого – 4.11 и выше.

Одним из нюансов является то, что в стабильных репозиториях Debian 10 доступна Samba версии только 4.9. Но хотелось бы использовать последние доступные возможности схемы домена, поэтому я на свой страх и риск подключил тестовые репозитории и произвёл дальнейшую установку Samba 4.11.3 из них:

Нажмите для раскрытия sources.list
deb http://ftp.ru.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.ru.debian.org/debian/ testing main contrib non-free

deb http://ftp.ru.debian.org/debian/ testing-updates main contrib non-free
deb-src http://ftp.ru.debian.org/debian/ testing-updates main contrib non-free

deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security. debian.org/ testing/updates main contrib non-free

DNS

Для домена необходимо использование DNS-сервера. Я остановился на распространённом варианте – использование встроенного в Samba DNS Internal. Допустимо использование BIND, но в рамках данной статьи его применение рассматриваться не будет.

Samba Internal DNS имеет следующие недостатки:

  • нельзя использовать как кеширующий сервер
  • не поддерживает рекурсивные запросы
  • нет shared-key transaction signature (TSIG)
  • нет зоны-заглушки
  • не поддерживает zone transfers
  • нет Round Robin балансировки между DC’s

Не смотря на вышеперечисленное, на практике это не доставляет проблем.

Подразумевается, что в сети, где разворачивается Samba AD, уже используется один или более DNS-серверов (например, тот же BIND, который не связан с Samba или внешние гугл\яндекс сервера). На этот DNS-сервер будут перенаправляться запросы клиентов Samba, т. е. он будет выбран в качестве forwarder.

Настройка hosts

Также сервер dc0.ad.rmn-lux.ru должен иметь статический IP-адрес и файл /etc/hosts со следующим содержимым:

127.0.0.1     localhost
172.16.0.16     dc0.ad.it-lux.ru     dc0

Удаление существующих файлов

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

mv /etc/samba/smb.conf /tmp && mv /etc/krb5.conf /tmp

Запущенные экземпляры Samba и сервисов

Перед началом установки надо проверить, что не запущена samba и её сервисы после установки пакетов:

ps ax | egrep "samba|smbd|nmbd|winbindd"

Если под фильтр попадает что-то из запущенного, нужно остановить:

systemctl stop samba-ad-dc smbd nmbd winbind

Скрыть юниты, чтобы они не могли быть запущены:

systemctl mask samba-ad-dc smbd nmbd winbind

И отключить:

systemctl disable samba-ad-dc smbd nmbd winbind

Установка

Для своих серверов я всегда использую Centos, но здесь пришлось сделать исключение и выбрать Debian, т.к. Samba, доступная из основных пакетов в Centos, не может выступать в роли AD.

Вариантов установки на Centos было несколько: собрать из пакетов (что на продуктивном сервере совсем некошерно) или установить из сторонних репозиториев (например, tissamba), но решил попробовать Debian, т.к. не хотелось искать обходные пути.

Но и с Debian оказался нюанс, т.к. в основных стабильных репозиториях не было нужной мне версии. Тем не менее, вариант установки из официальных репозиториев, пусть и тестовых, меня более чем устроил.

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

Зависимости, необходимые для Samba AD в Debian:

apt-get install acl attr autoconf bind9utils bison build-essential \
  debhelper dnsutils docbook-xml docbook-xsl flex gdb libjansson-dev krb5-user \
  libacl1-dev libaio-dev libarchive-dev libattr1-dev libblkid-dev libbsd-dev \
  libcap-dev libcups2-dev libgnutls28-dev libgpgme-dev libjson-perl \
  libldap2-dev libncurses5-dev libpam0g-dev libparse-yapp-perl \
  libpopt-dev libreadline-dev nettle-dev perl perl-modules pkg-config \
  python-all-dev python-crypto python-dbg python-dev python-dnspython \
  python3-dnspython python-markdown python3-markdown \
  python3-dev xsltproc zlib1g-dev liblmdb-dev lmdb-utils

В оф. документации указаны пакеты python-gpgme python3-gpgme для зависимостей, но в Debian 10 его больше нет, так что его я не устанавливал.

Настройка домена:

Для установки Samba в Debian 10 нужны следующие пакеты:

apt-get install acl attr samba samba-dsdb-modules samba-vfs-modules winbind libpam-winbind libnss-winbind libpam-krb5 krb5-config krb5-user

Напоминаю, что мне нужна была версия 4.11, поэтому после установки нужно убедиться, что будет использоваться пакет нужной версии:

samba-tool --version

4.11.3-Debian

Теперь непосредственно настройка домена:

samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=SAMBA_INTERNAL --realm=AD.IT-LUX.RU --domain=AD --adminpass=Password

Указывается роль – domain controller, использование необходимого rfc2307, согласно оф. документации – для возможности хранения атрибутов Unix в AD, встроенный DNS, имя домена – обязательно заглавными буквами и NetBIOS имя домена одним словом без точки, а также указание админского пароля.

Теперь надо сконфигурировать /etc/resolv.conf, чтобы в качестве резолвера использовался DNS из Samba (по идее, можно было бы сделать до создания домена):

Нажмите, чтобы раскрыть /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp0s3
allow-hotplug enp0s3
iface enp0s3 inet static
address 172.16.0.16/24
gateway 172.16.0.1
dns-nameservers 127.0.0.1

/etc/resolv.conf:

search ad.it-lux.ru
nameserver 127.0.0.1

На всякий случай уточню, что файл resolve.conf может затираться NetworkManager`ом или установленной утилитой resolvconf после рестарта, стоит это иметь ввиду.

Kerberos

Kerberos – это сетевой протокол, который будет использоваться для аутентификации.

В самом начале выпиливался стандартный конфиг kerberos – теперь нужно вернуть его назад с новыми настройками, сделав следующее:

cp /var/lib/samba/private/krb5.conf /etc/krb5.conf

И проверить его содержимое (на всякий случай):

cat /etc/krb5.conf

[libdefaults]
        default_realm = AD.IT-LUX.RU
        dns_lookup_realm = false
        dns_lookup_kdc = true

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

systemctl enable samba-ad-dc

Synchronizing state of samba-ad-dc.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable samba-ad-dc
Failed to enable unit: Unit file /etc/systemd/system/samba-ad-dc.service is masked.

Симлинк, ведущий в /dev/null, нужно удалить и выполнить перезагрузку сервисов systemd:

rm /etc/systemd/system/samba-ad-dc.service && systemctl daemon-reload

И запустить самбу, которая подтянет уже всё остальное, что ей нужно:

systemctl enable --now samba-ad-dc

Правка конфигурационного файла Samba

После установки конфиг выглядит примерно так:

# Global parameters
[global]
        dns forwarder = 127.0.0.1
        netbios name = DC0
        realm = AD.IT-LUX.RU
        server role = active directory domain controller
        workgroup = AD-IT-LUX
        idmap_ldb:use rfc2307 = yes

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No

[netlogon]
        path = /var/lib/samba/sysvol/ad.it-lux.ru/scripts
        read only = No

Но по своему опыту скажу, что штатный конфиг нужно поправить, местами упростив настройки. Ниже кратко опишу опции конфигурационного файла /etc/samba/smb.conf:

Нажмите, чтобы посмотреть полный конфиг
# Global parameters
[global]
        dns forwarder = 127.0.0.1
        netbios name = DC0
        realm = AD.IT-LUX.RU
        server role = active directory domain controller
        workgroup = AD-IT-LUX
        idmap_ldb:use rfc2307 = yes

        bind interfaces only = yes # слушать только на указанных интерфейсах
        interfaces = 127.0.0.1 172.16.0.16

        dns forwarder = 8.8.8.8 # вышестоящий DNS-сервер
        allow dns updates = nonsecure and secure # разрешает nonsecure  запросы

        ldap server require strong auth = no # необходимо для авторизации
        domain master = yes # Для указания того, что данный КД является мастером при наличии других 
        local master = yes
        preferred master = yes

        vfs objects = acl_xattr # для настройки share используя ACL на Unix. По умолчанию включен, но всё равно прописал для наглядности
        map acl inherit = yes
        store dos attributes = yes

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No

[netlogon]
        path = /var/lib/samba/sysvol/ad.it-lux.ru/scripts
        read only = No

После внесения изменений в конфиг, нужно выполнить рестарт сервиса:

systemctl restart samba-ad-dc

Проверка настроек

Теперь, когда всё настроено, нужно выполнить ряд проверок, чтобы убедиться в корректной работе всех компонентов Samba.

Общая проверка выполняется командой testparm:

Нажмите для раскрытия…
testparm

Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_ACTIVE_DIRECTORY_DC

Press enter to see a dump of your service definitions

# Global parameters
[global]
        allow dns updates = nonsecure and secure
        bind interfaces only = Yes
        dns forwarder = 8.8.8.8
        domain master = Yes
        interfaces = 127.0.0.1 172.16.0.16
        ldap server require strong auth = No
        passdb backend = samba_dsdb
        preferred master = Yes
        realm = AD.IT-LUX.RU
        server role = active directory domain controller
        workgroup = AD-IT-LUX
        rpc_server:tcpip = no
        rpc_daemon:spoolssd = embedded
        rpc_server:spoolss = embedded
        rpc_server:winreg = embedded
        rpc_server:ntsvcs = embedded
        rpc_server:eventlog = embedded
        rpc_server:srvsvc = embedded
        rpc_server:svcctl = embedded
        rpc_server:default = external
        winbindd:use external pipes = true
        idmap_ldb:use rfc2307 = yes
        idmap config * : backend = tdb
        map acl inherit = Yes
        map archive = No
        vfs objects = acl_xattr


[sysvol]
        path = /var/lib/samba/sysvol
        read only = No


[netlogon]
        path = /var/lib/samba/sysvol/ad.it-lux.ru/scripts
        read only = No

Посредством команд hosts и wbinfo можно провести ряд проверок, результат выполнения которых должен быть без ошибок:

host -t A dc0.ad.it-lux.ru
dc0.ad.it-lux.ru has address 172.16.0.16

host -t A ad.it-lux.ru
ad.it-lux.ru has address 172.16.0.16

wbinfo -t
checking the trust secret for domain AD-IT-LUX via RPC calls succeeded

wbinfo -p
Ping to winbindd succeeded

wbinfo -P
checking the NETLOGON for domain[AD-IT-LUX] dc connection to "dc0.ad.it-lux.ru" succeeded

Прочие проверки, которые могут пригодиться для отладки:

Проверка БД Samba
samba-tool dbcheck

Исправление ошибок с БД
samba-tool dbcheck --fix

Проверка прав доступа к sysvol
samba-tool ntacl sysvolcheck

При наличии ошибок с sysvol - исправление
samba-tool ntacl sysvolreset

Администрирование

Если все проверки пройдены и никаких ошибок не возникло, можно приступать к использованию домена.

Можно посмотреть общую информацию о домене:

samba-tool domain info dc0.ad.it-lux.ru

Forest           : ad.it-lux.ru
Domain           : ad.it-lux.ru
Netbios domain   : AD-IT-LUX
DC name          : dc0.ad.it-lux.ru
DC netbios name  : DC0
Server site      : Default-First-Site-Name
Client site      : Default-First-Site-Name

Проверить список дефолтных юзеров через wbinfo или samba-tool:

wbinfo -u

AD-IT-LUX\administrator
AD-IT-LUX\guest
AD-IT-LUX\krbtgt
samba-tool user list

И список групп:

wbinfo -g

AD-IT-LUX\cert publishers
AD-IT-LUX\ras and ias servers
AD-IT-LUX\allowed rodc password replication group
AD-IT-LUX\denied rodc password replication group
AD-IT-LUX\dnsadmins
AD-IT-LUX\enterprise read-only domain controllers
AD-IT-LUX\domain admins
AD-IT-LUX\domain users
AD-IT-LUX\domain guests
AD-IT-LUX\domain computers
AD-IT-LUX\domain controllers
AD-IT-LUX\schema admins
AD-IT-LUX\enterprise admins
AD-IT-LUX\group policy creator owners
AD-IT-LUX\read-only domain controllers
AD-IT-LUX\dnsupdateproxy
samba-tool group list

А также список компьютеров (пока что только один КД):

samba-tool computer list

DC0$

Создание пользователя:

samba-tool user create newuser

Задать ему пароль:

samba-tool user setpassword newuser

Деактивировать пользователя:

samba-tool user disable newuser

Прочие команды можно посмотреть, выполнив:

samba-tool --help

через samba-tool также настраивается DNS.

Настройку и управление также можно осуществлять посредством RSAT, т.е. классическими виндовыми оснастками, но мне больше нравится консольный вариант непосредственно с самого сервера Samba.

Бэкап

В официальной документации подробно всё описано, поэтому первоначально стоит ознакомиться с информацией там.

После настройки благоразумно будет обеспечить резервное копирование Samba. Есть несколько типов резервирования: “Online” и “Offline”.

Online делает копию работающей базы DC:

samba-tool domain backup online --targetdir=<output-dir> --server=<DC-server> -UAdministrator

Offline создает резервные копии файлов Samba:

samba-tool domain backup offline --targetdir=<output-dir>

Каждая команда создает файл резервной копии .tar.bz2, который содержит полную резервную копию домена (на основе данного DC). Затем файл резервной копии можно использовать для восстановления домена с помощью команды «samba-tool domain backup restore».

Использовать ту или иную схему бэкапа нужно в зависимости от ситуации. В обычных случаях Online-бэкап самый простой и быстрый, но в случае каких-то неполадок и для их расследования и устранения лучше подойдёт Offline-бэкап, т.к. содержит в себе дополнительные данные.

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

Заключение

Теперь, когда имеется установленный и настроенный контроллер домена, можно найти ему применение. Например, завести все рабочие станции офиса в домен и централизованно ими управлять. Или же настроить RADIUS для авторизации на VPN-сервере через доменную учётную запись.

Перенести репликацию SYSVOL в репликацию DFS

  • 2 минуты на чтение

В этой статье

Обновлено: 25 августа 2010 г.

Применимо к: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 и Windows Server 2008

Контроллеры домена используют специальную общую папку SYSVOL для репликации сценариев входа в систему и файлов объектов групповой политики на другие контроллеры домена.Windows 2000 Server и Windows Server 2003 используют службу репликации файлов (FRS) для репликации SYSVOL, тогда как Windows Server 2008 использует более новую службу репликации DFS в доменах, которые используют функциональный уровень домена Windows Server 2008, и FRS для доменов, которые работают с более старым функциональным доменом. уровни.

Чтобы использовать репликацию DFS для репликации папки SYSVOL, вы можете либо создать новый домен, который использует функциональный уровень домена Windows Server 2008, либо вы можете использовать процедуру, описанную в этом документе, для обновления существующего домена и переноса репликации в DFS. Репликация.

В этом документе предполагается, что у вас есть базовые знания о доменных службах Active Directory (AD DS), FRS и репликации распределенной файловой системы (репликация DFS). Дополнительные сведения см. В разделах Обзор доменных служб Active Directory, Обзор FRS или Обзор репликации DFS

.

В этом руководстве

Концептуальная информация о миграции SYSVOL

Процедура миграции SYSVOL

Устранение неполадок миграции SYSVOL

Справочная информация по миграции SYSVOL

Дополнительные ссылки

Серия миграции SYSVOL: Часть 1. Введение в процесс миграции SYSVOL

Серия миграции SYSVOL: Часть 2 — Dfsrmig.exe: средство миграции SYSVOL

Серия миграции SYSVOL: Часть 3 — Переход в состояние «ПОДГОТОВЛЕН»

Серия миграции SYSVOL: часть 4 — Переход в состояние «ПЕРЕНАПРАВЛЕННОЕ»

Серия миграции SYSVOL: часть 5 — Переход в состояние «УСТРАНЕНО»

Пошаговое руководство по распределенным файловым системам

для Windows Server 2008

Технический справочник FRS

Перенастройте синхронизацию SYSVOL с помощью DFRS — Tech Trainer

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

После глубокого исследования мы обнаружили, что это проблема с репликацией DFS папки SYSVOL. Несколько месяцев назад клиент успешно переместил репликацию с FRS на DFSR, но понижение уровня старого контроллера домена внесло путаницу в их среду.

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

Шаги для этого процесса приведены ниже.

  1. Остановить службу репликации DFS на основном контроллере домена;
  2. Откройте ADSI Edit в контексте именования по умолчанию , перейдите к CN = подписка SYSVOL, CN = системный том домена, CN = DFSR-LocalSettings, CN = <имя сервера для репликации>, OU = домен Контроллеры, DC = , и измените следующие атрибуты:
    • мс DFSR-Enabled = FALSE
    • мсDFSR-опции = 1
  3. На ВСЕ других контроллерах домена измените атрибут msDFSR-Enabled на False;
  4. Принудительная репликация AD
    • repadmin / syncall primary_dc_name / APed;
  5. Запустите репликацию DFS. резервного копирования на основном контроллере домена;
  6. Откройте средство просмотра событий и перейдите к Журналам приложений и служб -> Репликация DFS .Убедитесь, что вы видите идентификатор события 4114 ;
  7. Вернитесь к следующему пункту в ADSI CN = подписка SYSVOL, CN = системный том домена, CN = DFSR-LocalSettings, CN = <имя сервера для репликации>, OU = контроллеры домена, DC = <домен> и изменить следующие атрибуты:
  8. Выполните следующее с помощью командной строки с повышенными привилегиями DFSRDIAG POLLAD ;
  9. Принудительная репликация AD
    • repadmin / syncall primary_dc_name / APed
  10. Подождите несколько минут, и вы должны увидеть идентификатор события 2002 и 4602
  11. На ВСЕХ других контроллерах домена изменить атрибут
  12. Выполните следующее с помощью командной строки с повышенными привилегиями DFSRDIAG POLLAD ;
  13. Убедитесь, что вы видите идентификатор события 2002 и 4602 на всех остальных контроллерах домена.

После этого действия все проблемы с обработкой GPO и репликацией SYSVOL исчезнут.

Ура!

Следите за нами и ставьте лайки:

Переход SYSVOL с FRS на DFSR, шаг за шагом

Если у вас есть среда Контроллера домена, которая является Windows server 2003, 2008 или 2008 R2, пора обновить вашу среду до последней версии Windows Server. Однако, если вы в настоящее время используете указанную выше операционную систему ИЛИ если вы ранее выполняли обновление из устаревшей среды контроллера домена, такой как 2003, вам может потребоваться выполнить некоторые дополнительные действия перед обновлением или переходом на новые контроллеры домена Windows Server 2016+.

Вот предыстория истории.

Служба репликации файлов

(FRS) появилась в Windows Server 2000. Microsoft использовала FRS для репликации SYSVOL между членами своего контроллера домена. Позже, с Windows Server 2008, Microsoft представила репликацию распределенной файловой системы (DFSR), которая могла реплицировать SYSVOL.

Однако среды, которые были перенесены с устаревших контроллеров домена 2003, как правило, используют FRS. Однако при обновлении контроллеров домена необходимо учитывать одну вещь — повышение функциональных уровней леса и домена.

Например, Windows server 2008 R2 с функциональным уровнем леса и домена Windows Server 2003 может по-прежнему использовать FRS в качестве метода репликации SYSVOL по умолчанию. В этой среде, если вы хотите обновить контроллеры домена до Windows Server 2016, у вас возникнут проблемы с FRS.

Windows Server версии 1709 больше нельзя добавить в качестве контроллера домена Active Directory (DC) в существующий домен, который все еще использует службу репликации файлов (FRS) для репликации общего ресурса SYSVOL.

При попытке добавить сервер под управлением Windows Server версии 1709 в качестве контроллера домена появляется следующее сообщение об ошибке:

  • Указанный домен% 1 все еще использует службу репликации файлов (FRS) для репликации общего ресурса SYSVOL. FRS устарел.
  • Продвигаемый сервер не поддерживает FRS и не может быть повышен как реплика в указанном домене.
  • Перед продолжением НЕОБХОДИМО выполнить миграцию указанного домена для использования репликации DFS с помощью команды DFSRMIG.

Как это побороть? Что ж, есть только один способ — перенести метод репликации SYSVOL в DFSR. Давайте посмотрим, как выполнить перенос.

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

dfsrmig / GetGlobalState

dfsrmig / GetMigrationState

Что вам нужно, чтобы сосредоточиться на результате, так это упомянутое состояние Global state (‘’).

  • В большинстве случаев вы увидите «START» как состояние, вы используете FRS и требуется для выполнения миграции.
  • Если у вас есть состояние «ELIMINATED», вам не о чем беспокоиться, так как он будет использовать DFSR.

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

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

В процессе миграции вы шаг за шагом будете переходить на следующие уровни;

0 Начальное состояние

1 Состояние готовности

2 Перенаправленное состояние

3 Исключенное состояние

Для следующих нескольких шагов мы будем использовать команду «dfsrmig / SetGlobalState », где состояние может быть выбрано из указанного выше числового значения 0–3.

Состояние готовности

Как мы видели ранее, будет показано, что вы находитесь в «Начальном состоянии». Наша задача — перевести состояние DFSR в состояние «Подготовлено». Для этого откройте командную строку от имени администратора и выполните следующую команду;

dfsrmig / SetGlobalState 1

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

dfsrmig / GetMigrationState

Как видите, на трех моих серверах состояние по-прежнему «Пуск». Что вы можете сделать, чтобы ускорить процесс:

  1. Подождите, пока он завершится сам
  2. Запустите repadmin / syncall / AdeP , чтобы вручную запустить репликацию на каждый контроллер домена.

После завершения миграции вы получите следующее сообщение; Обратите внимание, что в нем указано состояние « Подготовлено »

Также обратите внимание, что у вас будет новая папка внутри NTDS для SYSVOL;

Перенаправленное состояние

Как мы видели ранее, будет показано, что вы находитесь в «Начальном состоянии».Наша задача — перевести состояние DFSR в состояние «Подготовлено». Для этого откройте командную строку от имени администратора и выполните следующую команду;

dfsrmig / SetGlobalState 2

После выполнения команды подождите 15 минут и выполните приведенную ниже команду, чтобы просмотреть состояние процесса миграции.

dfsrmig / GetMigrationState

Как видите, на трех моих серверах состояние по-прежнему «Пуск».Что вы можете сделать, чтобы ускорить процесс:

  1. Подождите, пока он завершится сам
  2. Запустите repadmin / syncall / AdeP , чтобы вручную запустить репликацию на каждый контроллер домена.

После завершения миграции вы получите следующее сообщение; Обратите внимание: в нем говорится, что теперь состояние « перенаправлено »

.

Исключенное состояние

После выполнения вышеуказанной задачи будет показано, что вы находитесь в «состоянии перенаправления». Следующей задачей будет последняя задача — перевести состояние DFSR в «Устранено».Для этого откройте командную строку от имени администратора и выполните следующую команду;

dfsrmig / SetGlobalState 3

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

dfsrmig / GetMigrationState

Как видите, на трех моих серверах состояние по-прежнему «Пуск». Что вы можете сделать, чтобы ускорить процесс:

  1. Подождите, пока он завершится сам
  2. Запустите repadmin / syncall / AdeP , чтобы вручную запустить репликацию на каждый контроллер домена.

После завершения миграции вы получите следующее сообщение; Обратите внимание, что в нем указано состояние « исключено»

На этом мы завершаем миграцию SYSVOL в DFSR.Вы можете некоторое время следить и проверять наличие ошибок с помощью DCDIAG и REPADMIN.

Очень признателен за все ваши комментарии, особенно если я что-то пропустил или сделал ошибку при установке. 🙂

(c) Авторские права защищены! Не делитесь и не используйте какой-либо контент без разрешения автора!

Быстрый совет по автоматическому восстановлению DFSR при подготовке к обновлению домена AD — блог Azure Cloud & AI

Когда в январе 2020 года Windows Server 2008 R2 подошел к концу, многие организации перенесли свои рабочие нагрузки на Windows Server 2016 или новее.К сожалению, с Active Directory (AD) попытка внедрить первый контроллер домена (DC) Windows Server 2019 или версии 1709 в домен, который все еще использует механизм службы репликации файлов (FRS) для репликации содержимого SYSVOL, терпит неудачу. Прекращение поддержки FRS намеренно блокирует установку. По этой причине перед обновлением AD требуется миграция на службу репликации распределенной файловой системы (DFSR). Моя цель в этом сообщении блога — выделить изменение, которое было введено в Windows Server 2008 R2 и 2012 (не R2), которое может вызвать головную боль, если не учтено в вашем плане обновления.То есть, как служба DFSR восстанавливается после грязного или неожиданного завершения работы (вручную или автоматически).

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

Переход с FRS на DFSR

Процесс перехода с FRS на DFSR довольно прост и не рассматривается в данной публикации.Тем не менее, следующая серия дает хорошее руководство по переходу на новый уровень:

  • Серия по миграции SYSVOL: Часть 1. Введение в процесс миграции SYSVOL
  • Серия миграции SYSVOL: часть 2 — Dfsrmig.exe: средство миграции SYSVOL
  • Серия миграции SYSVOL: Часть 3 — Переход в состояние «ПОДГОТОВЛЕН»
  • Серия миграции SYSVOL: часть 4 — Переход в состояние «ПЕРЕНАПРАВЛЕН»
  • Серия миграции SYSVOL: Часть 5 — Переход в состояние «УСТРАНЕНО»

Тестовая среда

Перед запуском в производственную среду всегда рекомендуется тестировать любые изменения в выделенной изолированной тестовой среде.В моем случае я использую один из шаблонов быстрого запуска Azure (https://azure.microsoft.com/en-us/resources/templates/), чтобы создать лабораторию в моей подписке Azure с помощью всего нескольких щелчков мыши:

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

Для целей этого блога я создал однодоменный лес с контроллерами домена под управлением Windows Server 2012.

DFSR Восстановление после грязного отключения

Сообщение в блоге «Понимание DFSR грязного (неожиданного) завершения работы» отлично объясняет, как DFSR восстанавливается после неожиданного завершения работы. Этот документ также указывает на изменение службы репликации DFS (DFSR) для Windows Server 2008 R2 посредством исправления 2663685. Изменение заключается в том, что служба DFSR больше не выполняет автоматическое восстановление базы данных Extensible Storage Engine после «грязного» завершения работы базы данных.Вместо этого при запуске нового поведения DFSR в журнал DFSR заносится событие с идентификатором 2213. Администратор должен вручную возобновить репликацию после того, как DFSR обнаружит неправильное завершение работы. Это изменение в поведении также применимо к Windows Server 2012, но не к более поздним версиям Windows Server.

Поведение по умолчанию

Взглянув на контроллер домена Windows Server 2012, использующий DFSR для репликации содержимого SYSVOL, это то, что по умолчанию будет в реестре — ключ StopReplicationOnAutoRecovery установлен в 1 (автоматическое восстановление отключено):

HKLM \ SYSTEM \ CurrentControlSet \ Services \ DFSR \ Parameters

Неожиданное отключение

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

Шаги ручного восстановления

Событие 2213 предполагает, что администратор выполняет следующие действия для восстановления:

  1. Создайте резервную копию файлов во всех реплицированных папках на томе. Невыполнение этого требования может привести к потере данных из-за неожиданного разрешения конфликта во время восстановления реплицированных папок.
  2. Чтобы возобновить репликацию для этого тома, используйте WMI-метод ResumeReplication класса DfsrVolumeConfig. Например, в командной строке с повышенными привилегиями введите следующую команду:

wmic / namespace: \\ root \ microsoftdfs путь dfsrVolumeConfig, где volumeGuid = ”< GUID >” вызовите ResumeReplication

Шаг 1 не требует пояснений. Для второго шага просто скопируйте и вставьте команду, указанную в событии 2213, в командную строку следующим образом:

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

После того, как это будет выполнено, будет зарегистрировано следующее событие (2212), указывающее, что служба репликации DFS обнаружила неожиданное завершение работы тома. В этом событии также указано, что служба восстановит базу данных, если определит, что восстановление невозможно.

Если все прошло успешно, то за этим последуют два информационных события:

  • Событие 2218 — Служба репликации DFS находится на втором этапе проверки целостности базы данных репликации после неожиданного завершения работы.База данных будет перестроена, если ее невозможно восстановить.
  • Событие 2214 — служба репликации DFS успешно восстановлена ​​после неожиданного завершения работы тома. Это может произойти, если служба завершилась ненормально (например, из-за потери питания) или произошла ошибка тома.

Рекомендации для контроллеров домена

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

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

HKLM \ SYSTEM \ CurrentControlSet \ Services \ DFSR \ Parameters

Как только это будет установлено, DFSR автоматически восстановится после неожиданных отключений.

Добавить комментарий

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