Главная Windows, Новое Групповые политики Windows Server 2008: Репликация SYSVOL
  • Групповые политики Windows Server 2008: Репликация SYSVOL

    Folder 2 Групповая политика важная часть доменной структуры Active Directory. Именно благодаря ней администраторы могут управлять сотнями и тысячами компьютеров, не тратя на это всё рабочее время. Не секрет, что источником применения групповой политики является контроллер домена. Когда контроллеров домена несколько, каждый контроллер хранит копию групповых политик и эти копии должны быть синхронизированы. В противном случае в сети возникнет хаос, клиенты, обратившиеся при загрузке к первому контроллеру, получат одни настройки, обратившиеся же ко второму, получат совершенно иные. В данной статье я расскажу о синхронизации (или более правильно репликации) групповых политик. Данная тема особенно актуальна в свете изменений произошедших с выходом Windows Server 2008.

     

    Каждая политика состоит из двух частей:

    1. Контейнер групповой политики (Group Policy Container или «GPC») – хранится в базе Active Directory и не содержит настроек и параметров, применяемых к клиентам. В контейнере групповой политики присутствует информация о названии политики, ее идентификатор («GUID»), дата создания, дата изменения, версия, используемая при синхронизации. А так же местоположение шаблона групповой политики.

    2. Шаблон групповой политики (Group Policy Template или «GPT») – находится в папке SYSVOL на контроллере домена. Но не в корне SYSVOL, а во вложенной папке, названной по «GUID»- у политики. Именно шаблон и несет те параметры, которые применяются на стороне клиента.

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

    В документации и работе вы можете встретить еще одно понятие «Объект Групповой Политики» или «Group Policy Object (GPO) ». Под ним подразумевается сама политика, т.е контейнер + шаблон.

    Репликация GPC и GPT осуществляется по-разному.

    1.Контейнер групповой политики (GPC) реплицируется средствами Active Directory и поэтому достаточно, чтобы репликация «Доменного» раздела Active Directory происходила регулярно (Поскольку GPC хранится в нем). Изменение любого параметра шаблона политики приводит к репликации контейнера. При отсутствии ошибок в работе AD, за репликацию GPC можно не переживать. Для решения проблем и мониторинга репликации AD используется утилита Replmon из комплекта Windows Server 2003 Support Tools. Несмотря на то, что комплект был выпущен для Windows Server 2003, он по-прежнему работает и на последней версии сервера.

    image

    Рис.1 Просмотр контейнера групповой политики через утилиту AdExplorer.

    image

    Рис.2 Просмотр шаблона групповой политики.

     

    2.Шаблон групповой политики (GPT) реплицируется с помощью службы File Replication service (или «FRS»), именно она отвечает за синхронизацию шаблонов. Запуск репликации SYSVOL не имеет расписания, а процесс репликации стартует автоматически после изменения шаблона групповой политики. Репликация является мульти-мастерной, т.е источником изменений может быть любой контроллер. Если изменения произошли на нескольких контроллерах, приоритет будет иметь изменение сделанное последним.

    Важно: Все что написано выше справедливо как для Windows Server 2003, так и для Windows Server 2008. Когда вы добавляете в ваш домен Active Directory, построенный на базе Windows Server 2003 новый контроллер Windows Server 2008, он использует для репликации групповой политики «File Replication service».

    Но: При создании нового домена Active Directory на базе Windows Server 2008 (режим работы домена Windows Server 2008), для репликации «Шаблонов групповой политики» используется «Distributed File System («DFS») Replication». Если вы обновили ваш домен с Windows Server 2003 до уровня 2008, то «DFS Replication» нужно включать дополнительно. Давайте разберемся, что это за технология, и какие преимущества она нам дает.

     

    Distributed File System (DFS) Replication это сервис, реплицирующий папку SYSVOL на всех контроллерах домена, работающего в функциональном режиме Windows Server 2008. Впервые DFS Replication появилась в Windows Server 2003 R2, но для репликации SYSVOL ее можно использовать только в Windows Server 2008.

     

    Какие преимущества имеет «DFS Replication»?

     

    · В Windows Server 2003 при изменении файла в SYSVOL служба «FRS» реплицировала весь файл целиком. При использовании «DFS Replication» измененный файл больше 64 KB реплицируется частично, т. е только изменения.

    · Масштабируемое решение. Размер папки SYSVOL может достигать нескольких терабайт.

    · Новая графическая оснастка "Управление DFS" для более удобного администрирования.

    · Улучшенная поддержка Read Only Domain Controllers.

    · Наличие встроенных средств мониторинга и утилиты для развертывания.

    · Технология, требующая минимального контроля и администрирования со стороны системного администратора.

     

    В процессе миграции на «DFS Replication» контроллеры домена последовательно проходят через четыре глобальных состояния. Каждое состояние это шаг в процессе миграции. При переходе на новый этап существует возможность протестировать успешность предыдущих действий и миграцию в целом. В случае возникновения трудностей вы можете «откатить» действия и вернуться на первоначальную репликацию через «FRS».

    Важно: Контроллер домена может находиться только в одном из глобальных состояний.

    states

    Табл.1 Основные состояния контроллеров домена при переходе на «DFS Replication»

     

    Каждое глобальное состояние подразумевает определенный алгоритм репликации папки SYSVOL.

    0. Состояние ‘START’. За репликацию папки SYSVOL отвечает служба «FRS», а «DFS Replication» контроллерами не используется. По умолчанию контроллеры домена уровня Windows Server 2003 находятся в этом состоянии.

    1. Состояние ‘PREPARED’. Репликация папки SYSVOL по-прежнему осуществляется через «FRS», этот механизм используется для работы, но на каждом контроллере запускается сервис «DFS Replication» и создается копия SYSVOL с именем ‘SYSVOL_DFSR’ для отдельной DFS репликации.

    2. Состояние ‘REDIRECTED’. Основным двигателем репликации становится «DFS Replication», для работы используется папка ‘SYSVOL_DFSR’. «FRS» по-прежнему реплицирует SYSVOL, но уже в качестве резервной системы. На этом этапе еще существует возможность отменить изменения и вернуть контроллеры к состоянию ‘START’.

    3. Состояние ‘ELIMINATED’. После того как администратор будет уверен в работоспособности новой системы репликации SYSVOL, контроллеры переводятся в состояние ‘ELIMINATED’. «DFS Replication» становится единственным механизмом, а «FRS» отключается.

     

    image

    Рис.3 Переход между состояниями контролеров домена.

    Процесс миграции запускается доменным администратором с помощью утилиты «dfsrmig.exe», которая осуществляет перевод контроллеров между глобальными состояниями. Эта утилита устанавливается одновременно с сервисом «DFS» и может запускаться на любом контроллере домена.

     

    Приступим к переходу на использовании «DFS Replication»:

    Для начала необходимо убедиться, что в вашем домене работают контроллеры домена исключительно под управлением Windows Server 2008. Если это так, то следующим шагом необходимо поднять режим работы домена до уровня "Windows Server 2008" и создать резервную копию Active Directory Domain Services. В Windows Server 2008 резервная копия создается средствами Windows Server Backup, вам будет достаточно сделать архив состояния системы контроллера владеющего ролями FSMO.

    Поскольку изначально контроллеры домена находятся в нулевом состоянии ‘START’, для запуска процесса миграции нужно на любом (не RODC) контроллере домена выполнить команду dfsrmig /SetGlobalState 1. Тем самым переведя контроллеры домена в состоянии ‘PREPARED’. Учтите, что изменения должны реплицироваться в рамках вашего домена и смена состояния может занять некоторое время. Проверить переход контроллеров домена в новое состояние можно, выполнив команду dfsrmig /GetMigrationState.

    Если репликация была завершена, вы получите сообщение, говорящее об успешности миграции в глобальное состояние ‘PREPARED’ и согласованности всех контроллеров.

    image

    Рис.5 Проверка перехода в основное состояние.

    В процессе перехода в глобальное состояние 1 (‘PREPARED’) каждый контроллер там же, где находится оригинальный SYSVOL, создает папку ‘SYSVOL_DFSR’ , устанавливая на нее разрешения оригинала. Используя robocopy.exe содержимое оригинальной папки SYSVOL копируется в ‘SYSVOL_DFSR’. Служба DFS Replication запускается и переходит в состояние запуска "Автоматически"

    Теперь все готово для перевода контроллеров во второе глобальное состояние ‘REDIRECTED’. Для этого выполняется команда dfsrmig /SetGlobalState 2.

    image

    Рис.6 Переход в состояние ‘REDIRECTED’

    Содержимое папки ‘SYSVOL_DFSR’ обновляется, на случай если вы меняли групповые политики с момента перехода в первое состояние. Папка общего доступа SYSVOL теперь указывает на ‘SYSVOL_DFSR’ , но реплицируются обе папки ‘SYSVOL_DFSR’ и 'SYSVOL' параллельно.

     

    image

    Рис.7 Местоположение папки общего доступа SYSVOL на втором состоянии.

     

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

    Если вы уверены в успешности функционирования DFS, остается выполнить команду dfsrmig /SetGlobalState 3 и перейти в состояние ‘ELIMINATED’

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

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

    Использование DFS бесспорно более совершенный способ репликации папки SYSVOL. Теоретический размер хранилища групповых политик может доходить до 4 терабайт, что с лихвой покрывает потребности даже крупных доменов Active Directory. Значительные преимущества данной технологии не должны пройти мимо администраторов Active Directory.

    image

    Рис.8 Отчет построенный оснасткой "Управление DFS".

    Рудь Илья

    MCSE/MCT

    me@rudilya.ru

    • Рубрика: Windows,Новое
    • Автор: Илья Рудь
    • Дата: Вторник 12 Май 2009

Комментарии

  1. Спасибо, как раз домен/лес были подняты до уровня 2008.

    Буду внедрять потихоньку.

    На сервер-коре , вообщем не важно на каком, вручную добавить роль: DFSR-Infrastructure-ServerEdition ?

  2. Для репликации SYSVOL ничего вручную добавлять не нужно. Просто следуйте инструкции. На Core или обыкновенном запускать процесс миграции роли не играет.

    Единственный нюанс: На контроллер домена, который инициирует миграцию (т.е там где вы запустите dfsrmig) оснастка «Управление DFS» ставится автоматически, если будете проводить мониторинг с других контроллеров, оснастку нужно установить из компонентов системы. Она входит в часть «Управление файловым сервером»

  3. pic.ipicture.ru/uploads/090515/hu1gSOcdLe.jpg

    в чем может быть проблема ?

  4. Log Name: DFS Replication

    Source: DFSR

    Date: 15.05.2009 13:37:26

    Event ID: 1302

    Task Category: None

    Level: Error

    Keywords: Classic

    User: N/A

    Computer: SRV009********

    Description:

    The DFS Replication service encountered an error while writing to the debug log file. Failure to write to the debug log file can occur because the disk is full, the disk is failing, or a quota limit has been reached for the folder where the logs are written. Logging will be disabled until this error is resolved.

    Additional Information:

    Error: 5 (Access is denied.)

    Debug Log File Path: C:\Windows\Debug\

    Max Debug Log Files: 999

    Debug Log Severity: 4

    Max Debug Log Messages: 10000

  5. Пришли те мне на мыло вашу аську или месенджер, формат коментариев к статье не подразумевает траблшутинг. 🙂 И Я попробую помочь. me@rudilya.ru

  6. 2 sterid

    Необходимо повышение (elevation) прав.

    Всё отработало, только прав не хватило на запись лога.

Опубликовать

Я не робот.