Windows Server для самых маленьких. Часть 10: Второй контроллер и репликация
Все части серии «Windows Server для самых маленьких»Всё, что было в предыдущих шести частях, живёт на одном сервере. Сегодня появится второй, и каталог станет тем, чем он задуман: базой, у которой нет единственного хозяина. Любой контроллер принимает изменения, и они расходятся на остальные; любой контроллер можно выключить, и домен этого не заметит. Чтобы это работало, контроллеры должны уметь договариваться, что у кого новее, — это репликация, и она устроена интереснее, чем кажется по слову «копирование».
Сервер dc2 подготовлен как в части 1: имя dc2, адреса 192.168.1.11 и 2001:db8:1::11 (статический IPv6-адрес нужен ему, как и dc1 в части 9), время, обновления. Единственное отличие от того, что мы делали с dc1: DNS-клиент указывает на 192.168.1.10 — будущий контроллер должен найти домен.
Добавление контроллера
Роль та же, командлет другой:
PS C:\> Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
PS C:\> $dsrm = Read-Host -AsSecureString 'DSRM password'
PS C:\> $cred = Get-Credential CORP\alice.admin
PS C:\> Test-ADDSDomainControllerInstallation -DomainName corp.example.com -Credential $cred -InstallDns -SiteName Default-First-Site-Name -SafeModeAdministratorPassword $dsrm
PS C:\> Install-ADDSDomainController -DomainName corp.example.com -Credential $cred -InstallDns -SiteName Default-First-Site-Name -ReplicationSourceDC dc1.corp.example.com -SafeModeAdministratorPassword $dsrm -Force
Вступать в домен заранее не нужно: Install-ADDSDomainController на автономном сервере сам создаст учётную запись компьютера, если ему дать учётные данные администратора домена. Параметры, которых не было у Install-ADDSForest:
| Параметр | Что |
|---|---|
-Credential |
кто повышает: нужны права Domain Admins |
-SiteName |
в какой сайт поместить контроллер; без параметра — по подсети, а если подсетей нет, в сайт того контроллера, с которого идёт репликация |
-ReplicationSourceDC |
с кого брать начальную копию; без параметра выберет сам |
-NoGlobalCatalog |
не делать глобальным каталогом; по умолчанию делает |
-InstallationMediaPath |
путь к носителю IFM вместо репликации по сети |
-CriticalReplicationOnly |
реплицировать при установке только критичные объекты, остальное после перезагрузки в фоне |
-ReadOnlyReplica |
контроллер только для чтения, тема следующей части |
IFM (Install From Media) — способ не гонять базу по медленному каналу: на действующем контроллере делается снимок базы и SYSVOL, его везут на новый сервер диском или копируют заранее, и повышение берёт объекты оттуда, а по сети дотягивает лишь изменения, накопившиеся с момента снимка:
PS C:\> ntdsutil "activate instance ntds" ifm "create sysvol full C:\IFM" quit quit
Для контроллера в соседней стойке это не нужно; для филиала за каналом в 2 Мбит/с с базой в 2 ГБ — единственный разумный путь.
За те минуты, что идёт повышение, происходит следующее. На dc1 создаются объекты сервера и NTDS Settings для dc2 в разделе конфигурации, и с этого момента остальные контроллеры знают о новом. dc2 реплицирует с dc1 схему, конфигурацию, домен и, раз он глобальный каталог, частичные копии остальных доменов (которых у нас нет). Затем SYSVOL: dc2 становится членом группы репликации DFS-R и забирает содержимое с dc1. После перезагрузки Netlogon регистрирует SRV-записи, DFS-R сообщает о завершении начальной синхронизации (событие 4604 в журнале DFS Replication), dc2 публикует SYSVOL и NETLOGON и начинает объявлять себя клиентам.
PS C:\> Get-ADDomainController -Filter * | Format-Table HostName, IPv4Address, Site, IsGlobalCatalog, OperationMasterRoles -AutoSize
HostName IPv4Address Site IsGlobalCatalog OperationMasterRoles
-------- ----------- ---- --------------- --------------------
dc1.corp.example.com 192.168.1.10 Default-First-Site-Name True {SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster}
dc2.corp.example.com 192.168.1.11 Default-First-Site-Name True {}
Роли FSMO остались на dc1: они не переезжают сами, и об этом часть 17. Всё остальное у двух контроллеров одинаково.
Как устроена репликация
Репликация в Active Directory — многохозяйская (multi-master) и на уровне атрибутов: по сети едет не объект целиком, а изменившийся атрибут (у многозначных атрибутов вроде member — отдельное значение, это называется linked value replication). Три механизма делают это возможным.
USN и invocationID. У каждого контроллера есть счётчик USN (update sequence number), растущий с каждой записью в базу, — тот самый highestCommittedUSN из RootDSE в части 5. Каждое изменение помечается парой «кто сделал, с каким USN»: контроллер идентифицируется invocationID — GUID, который он получает при повышении и меняет при восстановлении из резервной копии (чтобы старые USN не перепутались с новыми). Изменение, сделанное клиентом на этом контроллере, — originating write; полученное по репликации — replicated write, и у него сохраняется originating-пара с того контроллера, где оно родилось.
Водяной знак и вектор актуальности. Для каждого партнёра контроллер помнит high-watermark — до какого USN партнёра он уже всё получил. Запрос репликации звучит как «дай всё, что у тебя изменилось после USN 41237». Кроме того, у каждого контроллера есть up-to-dateness vector: для каждого контроллера леса — наибольший originating USN, который он уже видел. Вектор отправляется партнёру вместе с запросом, и партнёр не присылает изменения, которые запрашивающий уже получил другим путём. Так два контроллера, у которых три партнёра, не получают одно изменение трижды — это называется гашением распространения (propagation dampening).
PS C:\> Get-ADReplicationUpToDatenessVectorTable -Target dc2 -Partition 'DC=corp,DC=example,DC=com' | Format-Table Partner, UsnFilter, LastReplicationSuccess -AutoSize
Partner UsnFilter LastReplicationSuccess
------- --------- ----------------------
CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp… 41290 15.10.2026 11:02:14
CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp… 12811 15.10.2026 11:02:14
Конфликты. Один атрибут изменили на двух контроллерах до того, как они реплицировались. Побеждает изменение с большей версией атрибута (она растёт при каждой originating-записи, мы видели её в Get-ADReplicationAttributeMetadata); при равных версиях — с более поздней меткой времени; при равных и тех, и других решает invocationID контроллера, где изменение родилось. Проигравшее изменение теряется без следа, и это нормально для каталога, где конфликты редки. Два особых случая: объект создан с одним именем в одном контейнере на двух контроллерах — проигравший получает к имени суффикс \0ACNF:<GUID>, и их видно фильтром (name=*\0ACNF:*); объект перенесён в контейнер, который на другом контроллере удалили, — попадает в CN=LostAndFound.
Срочная репликация. Обычная репликация внутри сайта идёт с задержкой уведомления 15 секунд. Некоторые изменения не ждут: блокировка учётной записи (но не разблокировка), изменение политик блокировки и паролей домена, смена пароля доверия и пароля учётной записи контроллера, смена владельца роли RID master уведомляют партнёров немедленно. Отдельно — пароли пользователей: при смене пароля контроллер, кроме обычной репликации, сразу отправляет его на PDC-эмулятор по RPC, и когда пользователь входит на другом контроллере, у которого пароль ещё старый, тот перед отказом переспрашивает PDC. Поэтому новый пароль работает везде сразу, хотя до части контроллеров он доедет через четверть часа.
KCC и топология
Кто с кем реплицируется, решает KCC (Knowledge Consistency Checker) — процесс на каждом контроллере, запускающийся каждые 15 минут и строящий объекты соединений (nTDSConnection) под NTDS Settings каждого контроллера: входящие связи, по которым этот контроллер забирает изменения. Соединение всегда одностороннее; для двух контроллеров KCC создаёт два.
Внутри сайта KCC строит кольцо: каждый контроллер реплицируется с двумя соседями по кольцу, а если контроллеров больше семи, добавляет связи так, чтобы между любыми двумя было не больше трёх шагов. Внутри сайта репликация идёт по уведомлению: контроллер, принявший изменение, через 15 секунд сообщает партнёрам, и они забирают его; без сжатия, через RPC.
Между сайтами всё иначе. В каждом сайте один контроллер назначается ISTG (Inter-Site Topology Generator) и строит связи с другими сайтами по графу связей сайтов (siteLink), выбирая в каждом сайте серверы-плацдармы (bridgehead). Межсайтовая репликация идёт по расписанию связи, со сжатием, и уведомлений по умолчанию нет.
PS C:\> Get-ADReplicationConnection -Filter * | Format-Table Name, ReplicateFromDirectoryServer, ReplicateToDirectoryServer, AutoGenerated -AutoSize
Name ReplicateFromDirectoryServer ReplicateToDirectoryServer AutoGenerated
---- ---------------------------- -------------------------- -------------
3b1a2c4d-5e6f-4a70-8b91-c2d3e4f5a6b7 CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,… CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,… True
7c8d9e0f-1a2b-4c3d-9e4f-5a6b7c8d9e0f CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,… CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,… True
AutoGenerated: True — построено KCC. Соединения можно создавать руками, и KCC их не тронет, но ручные соединения — почти всегда ошибка: они остаются, когда топология меняется, и KCC перестаёт отвечать за этот участок. Правильный способ управлять топологией — сайты и связи сайтов, а KCC пусть строит соединения сам. Заставить его пересчитать сейчас: repadmin /kcc.
Сайты
Сайт — набор подсетей с быстрой связью между ними; по замыслу — одна площадка. Сайты нужны трём вещам: репликации (внутри — быстро и по уведомлению, между — по расписанию и со сжатием), DC Locator (клиент ищет контроллер своего сайта, часть 3) и приложениям, которые знают о сайтах (Exchange, DFS, SCCM). Принадлежность клиента к сайту определяется его адресом по объектам подсетей.
Лес создаётся с одним сайтом, Default-First-Site-Name, без подсетей. Приведём в порядок и добавим второй сайт для филиала 192.168.2.0/24, где в следующей части появится контроллер:
PS C:\> Get-ADReplicationSite 'Default-First-Site-Name' | Rename-ADObject -NewName Office
PS C:\> New-ADReplicationSubnet -Name 192.168.1.0/24 -Site Office -Location 'Главный офис'
PS C:\> New-ADReplicationSubnet -Name 2001:db8:1::/64 -Site Office
PS C:\> New-ADReplicationSite -Name Branch
PS C:\> New-ADReplicationSubnet -Name 192.168.2.0/24 -Site Branch -Location 'Филиал'
PS C:\> Get-ADReplicationSubnet -Filter * | Format-Table Name, Site, Location -AutoSize
Name Site Location
---- ---- --------
192.168.1.0/24 CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com Главный офис
192.168.2.0/24 CN=Branch,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com Филиал
2001:db8:1::/64 CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
Подсети нужны все: клиент из подсети, которой нет ни в одном сайте, попадает в случайный сайт и ходит к контроллеру за океаном, а контроллер пишет об этом событие 5807 в журнал System («клиенты из незарегистрированных подсетей», список в %SystemRoot%\debug\netlogon.log).
Связь сайтов описывает канал между ними: стоимость, интервал репликации и расписание. При создании леса появляется одна, DEFAULTIPSITELINK, со стоимостью 100 и интервалом 180 минут. Сайт, созданный New-ADReplicationSite, ни в одну связь не входит (мастер в оснастке просит выбрать связь сразу), и пока его туда не добавят, контроллеры в нём ни с кем не реплицируются, а ISTG пишет событие 1865. Добавим Branch и заодно сократим интервал — три часа слишком долго для современных каналов:
PS C:\> Set-ADReplicationSiteLink -Identity DEFAULTIPSITELINK -ReplicationFrequencyInMinutes 15 -Cost 100 -SitesIncluded @{Add='Branch'}
PS C:\> Get-ADReplicationSiteLink -Filter * | Format-Table Name, Cost, ReplicationFrequencyInMinutes, SitesIncluded -AutoSize
Name Cost ReplicationFrequencyInMinutes SitesIncluded
---- ---- ----------------------------- -------------
DEFAULTIPSITELINK 100 15 {CN=Office,…, CN=Branch,…}
Пятнадцать минут — минимум для расписания. Если каналы позволяют, межсайтовую репликацию переводят на уведомления, как внутри сайта: бит 1 в атрибуте options связи (Set-ADReplicationSiteLink DEFAULTIPSITELINK -Replace @{options=1}); тогда изменения доходят до филиала за секунды, а не по расписанию. -Replace перезаписывает весь атрибут: если в options уже стоят другие биты (например, 4 — без сжатия), новое значение собирают через -bor. При нескольких сайтах и каналах стоимость связей определяет, через что пойдёт репликация, когда прямого пути нет: KCC считает кратчайший путь по сумме стоимостей, а мосты связей (site link bridges) по умолчанию делают все связи транзитивными.
Есть два транспорта, IP и SMTP; SMTP — для сайтов без постоянной связи, он реплицирует только схему, конфигурацию и глобальный каталог, в современных сетях не используется, и Microsoft предупреждает, что в будущих версиях его поддержки не будет.
Перенести контроллер в другой сайт — Move-ADDirectoryServer -Identity dc3 -Site Branch. Сайт без глобального каталога может включить кеширование членства в универсальных группах (Set-ADReplicationSite Branch -UniversalGroupCachingEnabled $true), чтобы вход не зависел от доступности GC в другом сайте, но проще сделать GC каждый контроллер.
repadmin
Главный инструмент. Четыре подкоманды покрывают почти всё.
/replsummary — сводка по всем контроллерам леса, с ней начинают:
PS C:\> repadmin /replsummary
Replication Summary Start Time: 2026-10-15 11:10:02
Beginning data collection for replication summary, this may take awhile:
.....
Source DSA largest delta fails/total %% error
DC1 08m:12s 0 / 5 0
DC2 08m:12s 0 / 5 0
Destination DSA largest delta fails/total %% error
DC1 08m:12s 0 / 5 0
DC2 08m:12s 0 / 5 0
largest delta — сколько прошло с последней успешной репликации самого отставшего раздела; fails/total — сколько связей из скольких в ошибке. Пять связей на два контроллера — пять разделов: схема, конфигурация, домен, DomainDnsZones, ForestDnsZones. Здоровый лес — нули в столбце fails и дельты меньше интервала расписания.
/showrepl — все входящие связи одного контроллера, с результатом последней попытки:
PS C:\> repadmin /showrepl dc2
Office\DC2
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 8e1f2a3b-4c5d-4e6f-9a7b-8c9d0e1f2a3b
DSA invocationID: 8e1f2a3b-4c5d-4e6f-9a7b-8c9d0e1f2a3b
==== INBOUND NEIGHBORS ======================================
DC=corp,DC=example,DC=com
Office\DC1 via RPC
DSA object GUID: 2f3e4d5c-6b7a-4899-8a7b-6c5d4e3f2a1b
Last attempt @ 2026-10-15 11:02:14 was successful.
CN=Configuration,DC=corp,DC=example,DC=com
Office\DC1 via RPC
DSA object GUID: 2f3e4d5c-6b7a-4899-8a7b-6c5d4e3f2a1b
Last attempt @ 2026-10-15 11:02:14 was successful.
CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com
Office\DC1 via RPC
DSA object GUID: 2f3e4d5c-6b7a-4899-8a7b-6c5d4e3f2a1b
Last attempt @ 2026-10-15 11:02:14 was successful.
...
Когда связь в ошибке, вместо was successful будет код и число неудач подряд: Last attempt @ … failed, result 8524 (0x214c): The DSA operation is unable to proceed because of a DNS lookup failure. 3 consecutive failure(s). Коды, которые встречаются чаще других:
| Код | Что |
|---|---|
| 8524 | партнёр не найден по DNS: его CNAME <GUID>._msdcs или A-запись не разрешаются; почти всегда DNS-клиент одного из контроллеров |
| 1722 | RPC недоступен: партнёр выключен, файрвол между сайтами закрыл 135 или динамические порты |
| 1256 | удалённая система недоступна: вторичный статус, настоящую причину показывают ошибки других разделов того же партнёра |
| 8453 | отказано в доступе к репликации: учётная запись контроллера, время или права на раздел |
| 8606 | недостаточно атрибутов для создания объекта: lingering objects, часть 18 |
| 8614 | контроллер не реплицировался дольше tombstone lifetime; репликация с ним заблокирована, часть 18 |
| -2146893022 | имя целевого принципала неверно: чаще всего у KDC устаревший пароль учётной записи контроллера-источника, реже — неверная запись DNS или SPN |
/syncall — запустить репликацию всего со всеми: repadmin /syncall /AdeP (A — все разделы, d — показывать имена вместо GUID, e — через границы сайтов, P — push: отправить партнёрам, а не только забрать). Выполнять, когда нужно, чтобы изменение разошлось сейчас, а не через расписание. Точечно — /replicate dc2 dc1 DC=corp,DC=example,DC=com: подтянуть один раздел с одного контроллера на другой.
/showobjmeta — метаданные объекта, те же, что Get-ADReplicationAttributeMetadata, но утилитой, которая есть везде:
PS C:\> repadmin /showobjmeta dc2 "CN=Alice Smith,OU=Sales,OU=Departments,DC=corp,DC=example,DC=com" | Select-String 'pwdLastSet| mail$'
12790 Office\DC1 41190 2026-10-15 09:30:11 3 pwdLastSet
12702 Office\DC1 40955 2026-10-14 16:21:07 2 mail
Столбцы: локальный USN на этом контроллере, где родилось изменение, его USN там, время originating-записи, версия, атрибут. У mail originating USN 40955 на dc1 и локальный 12702 на dc2 — разные счётчики, как и было сказано.
В PowerShell то же самое: Get-ADReplicationPartnerMetadata -Target dc2 -Scope Server, Get-ADReplicationFailure -Target dc1, dc2, Sync-ADObject -Object $dn -Source dc1 -Destination dc2 для одного объекта.
SYSVOL и DFS-R
SYSVOL реплицируется не каталогом, а службой DFS Replication: группа репликации Domain System Volume, папка SYSVOL Share, членами которой становятся все контроллеры. Это файловая репликация на уровне блоков со сжатием (RDC, remote differential compression), по своему расписанию (у SYSVOL — непрерывно) и с собственной базой состояния в C:\System Volume Information\DFSR.
Проверка и диагностика — утилитой dfsrdiag и модулем DFSR:
PS C:\> dfsrdiag replicationstate /member:dc2
Summary
Active inbound connections: 0
Updates received: 0
Active outbound connections: 0
Updates sent out: 0
Operation Succeeded
PS C:\> @(Get-DfsrBacklog -GroupName 'Domain System Volume' -FolderName 'SYSVOL Share' -SourceComputerName dc1 -DestinationComputerName dc2).Count
0
Get-DfsrBacklog перечисляет файлы, которые ещё не доехали с одного члена до другого, — только в одну сторону и не больше 100 (с -Verbose — и их общее число); пустой список — всё доехало. dfsrdiag pollad заставляет службу перечитать конфигурацию из каталога, что нужно после изменения членства. События, по которым судят о здоровье: 4614 — SYSVOL инициализирован и ждёт начальной синхронизации с партнёра (нормально у нового контроллера первые минуты), 4604 — начальная синхронизация завершена; если за 4614 часами не следует 4604, партнёр недоступен или сам не синхронизирован. У первого контроллера домена вместо этой пары одно 4602: ему не с кем синхронизироваться, и его копия считается исходной. И одно, с которым встречаются после сбоя питания: 2213 — база DFS-R была закрыта некорректно, и служба остановила репликацию тома, пока её не возобновят. В тексте события стоит команда wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="…" call ResumeReplication (в PowerShell условие where берут в одинарные кавычки), но WMIC в Windows Server 2025 — устаревший компонент по требованию, и то же самое делает PowerShell: Get-CimInstance -Namespace root\MicrosoftDFS -ClassName DfsrVolumeConfig -Filter "VolumeGuid='…'" | Invoke-CimMethod -MethodName ResumeReplication. После этого в журнале появляются 2212 и 2214. Это защита от репликации повреждённых данных, и в части про резервное копирование мы увидим её старшего брата — авторитетное восстановление SYSVOL.
Расхождение версий политики между каталогом и SYSVOL проверяет gpotool из старых комплектов или dcdiag /test:sysvolcheck /test:advertising; главный инструмент тут — Get-GPO с его DSVersion и SysvolVersion, к которым мы придём в части про групповые политики.
DNS-клиент контроллера
Теперь самое важное из практических правил этой части. При повышении мастер сам правит список DNS-серверов: первому контроллеру леса оставляет только 127.0.0.1, а дополнительному дописывает его в конец списка. Нужно иначе:
PS C:\> Set-DnsClientServerAddress -CimSession dc1 -InterfaceAlias Ethernet -ServerAddresses 192.168.1.11, 192.168.1.10
PS C:\> Set-DnsClientServerAddress -CimSession dc2 -InterfaceAlias Ethernet -ServerAddresses 192.168.1.10, 192.168.1.11
Первым — партнёр, вторым — сам. Причина в порядке старта. Служба каталога при запуске должна найти партнёров и выполнить начальную синхронизацию, прежде чем объявит себя готовой (isSynchronized); для этого ей нужен DNS. Служба DNS при запуске загружает зоны из каталога, и пока каталог не готов, зон у неё нет — она ждёт (событие 4013 из части 7). Контроллер, чей DNS-клиент указывает только на себя, после перезагрузки оказывается в кольце: каталог ждёт DNS, DNS ждёт каталог. Через таймаут каталог сдаётся, запускается без синхронизации, DNS загружает зоны, и всё работает — но первые попытки репликации записаны ошибкой 8524, и в repadmin /showrepl эта ошибка будет висеть до следующего успешного цикла, пугая того, кто смотрит. С партнёром на первом месте контроллер при старте разрешает имена через него и синхронизируется сразу.
Второй адрес — свой — нужен на случай, когда партнёр недоступен. Microsoft допускает и такую схему, и обратную (свой первым, партнёр вторым), а на свой DNS новый контроллер советует переключать только после того, как репликация прошла в обе стороны. Свой адрес можно указать и как 127.0.0.1 — анализатор BPA требует лишь, чтобы loopback не стоял первым, — но не дважды: свой IP и 127.0.0.1 в одном списке — это один и тот же сервер. В сайте с одним контроллером, где партнёра нет, остаётся только свой адрес, и на первом месте, и это тот редкий случай, когда ошибка 8524 после перезагрузки неизбежна и безвредна.
Заодно доделаем то, что отложили в прошлых частях: форвардеры на dc2, второй DNS в опции DHCP, роль DHCP на dc2 с failover из части 8. Настройки уровня сервера failover не реплицирует, поэтому опции DNS и домена и параметры регистрации в DNS задаются на dc2 отдельно:
PS C:\> Set-DnsServerForwarder -ComputerName dc2 -IPAddress 192.168.1.1
PS C:\> Install-WindowsFeature -ComputerName dc2 -Name DHCP -IncludeManagementTools
PS C:\> Add-DhcpServerSecurityGroup -ComputerName dc2
PS C:\> Invoke-Command dc2 { Restart-Service DHCPServer; Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\ServerManager\Roles\12' -Name ConfigurationState -Value 2 }
PS C:\> Add-DhcpServerInDC -DnsName dc2.corp.example.com -IPAddress 192.168.1.11
PS C:\> Set-DhcpServerDnsCredential -ComputerName dc2 -Credential (Get-Credential CORP\svc-dhcp-dns)
PS C:\> Set-DhcpServerv4DnsSetting -ComputerName dc2 -DynamicUpdates OnClientRequest -DeleteDnsRROnLeaseExpiry $true -UpdateDnsRRForOlderClients $true
PS C:\> foreach ($s in 'dc1', 'dc2') { Set-DhcpServerv4OptionValue -ComputerName $s -DnsServer 192.168.1.10, 192.168.1.11 -DnsDomain corp.example.com }
PS C:\> Add-DhcpServerv4Failover -ComputerName dc1 -PartnerServer dc2 -Name Office-failover -ScopeId 192.168.1.0 -LoadBalancePercent 50 -SharedSecret (Read-Host 'Shared secret') -Force
-Force в последней команде нужен потому, что с -SharedSecret командлет иначе переспрашивает подтверждение.
Для IPv6 — три команды из раздела «Два сервера без failover» части 9: та же область на dc2 и оба контроллера в опции DNS на обоих серверах.
Все эти команды выполнены на dc1 против другого сервера через -ComputerName: модули DnsServer и DhcpServer умеют это сами, через WinRM, и в части 15 мы разберём, как.
Смотрим руками
Репликация одного изменения, по шагам. Меняем атрибут на dc2 и смотрим, как он появляется на dc1:
PS C:\> Set-ADUser alice -Server dc2 -OfficePhone '+1 555 0101'
PS C:\> Get-ADUser alice -Server dc1 -Properties OfficePhone | Select-Object OfficePhone
OfficePhone
-----------
PS C:\> Start-Sleep 20; Get-ADUser alice -Server dc1 -Properties OfficePhone | Select-Object OfficePhone
OfficePhone
-----------
+1 555 0101
PS C:\> repadmin /showobjmeta dc1 "CN=Alice Smith,OU=Sales,OU=Departments,DC=corp,DC=example,DC=com" | Select-String telephoneNumber
41305 Office\DC2 12840 2026-10-15 11:20:33 1 telephoneNumber
Пятнадцать секунд задержки уведомления плюс сама репликация. В метаданных на dc1 изменение помечено как родившееся на dc2 с USN 12840 и записанное локально под USN 41305. Если бы в эти 15 секунд тот же атрибут поменяли на dc1, у обоих изменений была бы версия 1 и победило бы более позднее по времени.
Сам обмен в пакетах. Репликация идёт по RPC: клиент (контроллер, который забирает изменения, здесь dc1) спрашивает у Endpoint Mapper на порту 135 партнёра, где слушает интерфейс DRSUAPI (e3514235-4b06-11d1-ab04-00c04fc2dcd2), и соединяется с динамическим портом. В Wireshark с захвата на dc1:
No. Source Destination Protocol Info
1 192.168.1.10 192.168.1.11 EPM Map request: drsuapi
2 192.168.1.11 192.168.1.10 EPM Map response, Tower: ncacn_ip_tcp:192.168.1.11[49668]
3 192.168.1.10 192.168.1.11 DCERPC Bind: call_id: 2, DRSUAPI V4.0, auth: Kerberos, level: Packet privacy
4 192.168.1.11 192.168.1.10 DCERPC Bind_ack
5 192.168.1.10 192.168.1.11 DRSUAPI DsBind request [encrypted]
6 192.168.1.10 192.168.1.11 DRSUAPI DsGetNCChanges request [encrypted]
7 192.168.1.11 192.168.1.10 DRSUAPI DsGetNCChanges response [encrypted]
DsGetNCChanges — «дай изменения раздела после такого-то USN» — и есть репликация; всё содержимое зашифровано на уровне RPC (packet privacy) с аутентификацией Kerberos. Порт 49668 — из динамического диапазона, и для файрвола между сайтами его можно зафиксировать:
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'TCP/IP Port' -Value 50000 -Type DWord
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -Name 'DCTcpipPort' -Value 50001 -Type DWord
После перезагрузки репликация будет ходить на 50000, Netlogon — на 50001. У DFS-R, который реплицирует SYSVOL, свой динамический порт, его фиксирует Set-DfsrServiceConfiguration -RPCPort 50002. Тогда между сайтами хватит открыть 135, 50000–50002 и остальное из таблицы портов части 3.
Кто в каком сайте с точки зрения клиента:
PS C:\> nltest /dsgetdc:corp.example.com /site:Branch
DC: \\dc1.corp.example.com
Address: \\192.168.1.10
...
Dc Site Name: Office
Our Site Name: Branch
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST FULL_SECRET WS DS_8 DS_9 DS_10 DS_13 KEYLIST
Сайт Branch есть, контроллеров в нём пока нет, и Locator отдал ближайший по стоимости связи — из Office, без флага CLOSE_SITE. В следующей части там появится свой.
События журнала Directory Service, по которым узнают о проблемах репликации до того, как их увидит repadmin:
| Id | Что |
|---|---|
| 1311 | KCC не смог построить топологию: сайт без связи с остальными, нет доступного плацдарма |
| 1865 | сайт не соединён ни с одним другим: нет связи сайтов, включающей его |
| 2087 | партнёр не найден по DNS, и репликация не прошла (та же 8524 со стороны журнала): с подробным списком, что именно не разрешилось |
| 2088 | партнёр не найден по DNS, но репликация прошла по NetBIOS-имени или FQDN: DNS всё равно нужно чинить |
| 1925 | не удалось установить связь репликации с партнёром |
| 2042 | с партнёром не было репликации дольше tombstone lifetime; дальнейшая репликация с ним запрещена |
| 1988 | обнаружен lingering object у партнёра |
Источники
- Install Active Directory Domain Services и Install-ADDSDomainController — повышение дополнительного контроллера и параметры командлета;
- ifm (Ntdsutil) — носитель для установки IFM;
- Active Directory Replication Concepts и How the Active Directory Replication Model Works — USN, invocationID, векторы, конфликты, срочная репликация;
- How Active Directory Replication Topology Works — KCC, кольцо и правило трёх шагов, ISTG, плацдармы, связи и мосты связей, транспорт SMTP;
- Introduction to Active Directory Replication and Topology Management Using Windows PowerShell и Advanced Active Directory Replication and Topology Management Using Windows PowerShell — командлеты
*-ADReplication*; - Set-ADReplicationSiteLink и Determining the Interval — интервал, стоимость и уведомления на связи сайтов;
- Repadmin — подкоманды
repadmin; - Troubleshooting Active Directory Replication Problems и Troubleshoot common Active Directory replication errors — события журнала и коды ошибок, по ссылке на каждую ошибку;
- Active Directory replication error 8524 — ошибка DNS при репликации;
- Recommendations for DNS client settings — DNS-клиент контроллера и «острова» DNS;
- Force synchronization for DFSR replicated sysvol и Troubleshoot missing SYSVOL and Netlogon shares — события 4614, 4604 и 4602,
dfsrdiag pollad; - DFSR event ID 2213 и Get-DfsrBacklog — остановка репликации после сбоя и отставание;
- Restrict Active Directory RPC traffic to a specific port, Set-DfsrServiceConfiguration и Configure firewall for AD domain and trusts — фиксированные порты и файрвол;
- MS-DRSR: IDL_DRSGetNCChanges — вызов, который и есть репликация;
- Deploy DHCP Using Windows PowerShell и DHCP failover — роль DHCP на втором контроллере.
Два контроллера, два сайта, и во втором сайте — пока никого. В филиале с десятью сотрудниками, одним шкафом без замка и каналом, который падает раз в месяц, полноценный контроллер ставить не хочется: на нём лежат пароли всех пользователей домена. Для этого есть особый вид контроллера.
Дальше — часть 11: контроллер только для чтения. Чем RODC отличается от обычного, как работает политика репликации паролей и что происходит, когда пользователь филиала входит в первый раз, какие атрибуты на RODC не попадают никогда, кто такой делегированный администратор, и как на RODC живёт DNS.
Оставить комментарий могут только зарегистрированные пользователи.
Войдите на сайт или зарегистрируйтесь, чтобы оставить комментарий.