АйТи Фреш
Главная / Статьи / Windows и рабочие места
Windows и рабочие места

DHCP failover в Windows Server 2025: что не едет само

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~23 мин чтения
DHCP failover в Windows Server 2025: что не едет само
Иллюстрация к статье «DHCP failover в Windows Server 2025: что не едет само».

Знакомый сценарий: настроили DHCP failover, увидели одинаковые активные аренды на двух серверах и решили, что вся конфигурация теперь синхронизируется автоматически. Через несколько месяцев на основном сервере добавили резервации для МФУ, терминалов и камер, но не отправили изменения партнёру. Стоило основному DHCP надолго уйти на обслуживание, как первое же новое устройство получило адрес из динамического пула. Ниже я разберу, что Windows Server передаёт автоматически, что нужно реплицировать вручную, почему направление команды важнее её синтаксиса и как обнаружить расхождение до аварии.

Failover автоматически синхронизирует аренды, но не последующие правки области

В DHCP failover действительно существуют два разных механизма обмена, и смешивать их нельзя. Первый обслуживает состояния аренд. Партнёры поддерживают TCP-соединение, передают обновления привязок и хранят две отдельные, синхронизированные базы аренд. Microsoft использует для этого TCP-порт 647. Клиент может получить адрес у одного сервера, а продлить ту же аренду у второго: именно поэтому списки активных адресов на партнёрах обычно выглядят одинаково даже после длительной эксплуатации.

Второй механизм переносит конфигурацию DHCPv4-области. При создании отношения failover исходная область создаётся на партнёре вместе с её настройками. В дальнейшем изменения диапазона, исключений, срока аренды, резерваций, значений опций и политик области сами не отправляются. Для этого администратор должен явно запустить репликацию. В документации Microsoft это вынесено в предупреждение: изменения failover-области нужно вручную скопировать на партнёрский сервер.

Репликация конфигурации не выполняет двустороннее сравнение и не объединяет изменения. Настройки копируются с сервера, указанного источником операции, на его партнёра и перезаписывают соответствующую конфигурацию там. Дата изменения объекта не помогает, автоматического разрешения конфликтов нет. Если на обоих серверах независимо добавили разные резервации, одна из версий при следующей репликации будет потеряна.

Из-за этого оснастка DHCP создаёт опасную иллюзию порядка. Администратор открывает на партнёре область 192.168.10.0, видит знакомый пул и больше сотни активных аренд, после чего закрывает консоль. Но одинаковые аренды подтверждают только работу протокола failover. Они ничего не говорят о том, совпадают ли узлы Reservations, Scope Options и Policies. Я всегда проверяю их отдельно.

Быстрая проверка числа резерваций выглядит так: ```powershell (Get-DhcpServerv4Reservation -ComputerName 'dc01.zarechye.local' ` -ScopeId 192.168.10.0).Count (Get-DhcpServerv4Reservation -ComputerName 'dc02.zarechye.local' ` -ScopeId 192.168.10.0).Count ``` Совпавшее количество ещё не доказывает идентичность записей, но разные числа уже подтверждают расхождение.
Памятка: Failover автоматически синхронизирует аренды, но не последующие правки области — схема
Памятка: Failover автоматически синхронизирует аренды, но не последующие правки области. Открыть схему в полном размере

Разбор практики: агрохолдинг «Заречье», 140 сотрудников, 5 площадок

Условный клиент из этого разбора — агрохолдинг «Заречье», 140 сотрудников, 5 площадок. Площадки соединены корпоративной сетью, DHCP-запросы удалённых VLAN передаются через relay. Роль DHCP установлена на двух контроллерах домена с Windows Server 2025. Между DC01 и DC02 создано отношение DC01-DC02 в режиме load balance 50/50. Для него явно включили автоматический переход состояния, задали StateSwitchInterval один час и оставили MaxClientLeadTime, или MCLT, равным одному часу.

В отношении находились пять DHCPv4-областей — по одной для каждой площадки. Инцидент затронул область 192.168.10.0/24 центральной площадки. Её фактический диапазон был 192.168.10.30–192.168.10.250, а адреса 192.168.10.240–192.168.10.250 исключили из динамической выдачи. В Windows Server резервация внутри исключённого диапазона остаётся работоспособной: исключение запрещает обычную динамическую выдачу, но не выдачу зарезервированного адреса назначенному клиенту. Поэтому для сотрудников динамический пул заканчивался на .239, а МФУ было зарезервировано .240. Срок обычной аренды составлял восемь дней, в рабочее время в области было около 118 активных аренд.

Отношение настраивали за полтора года до инцидента. Исходная конфигурация тогда корректно создалась на DC02. Позже внутренний администратор работал только с DC01 и добавил 14 резерваций: два МФУ, семь терминалов сбора данных, терминал весов, три камеры и контроллер СКУД. Он также изменил опцию 006 после ввода третьего DNS-сервера, поправил срок аренды в гостевой области и создал политику области для терминалов по vendor class. Все изменения были технически корректны, но ручную репликацию после них никто не запускал.

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

В субботу DC01 вывели на плановое обслуживание. Из-за дополнительных работ с питанием и обновлением прошивки DHCP-сервис оставался недоступен дольше двух часов. DC02 сначала перешёл в COMMUNICATION INTERRUPTED, через заданный StateSwitchInterval — в PARTNER DOWN, а после дополнительного ожидания MCLT получил возможность использовать оставшуюся часть свободного пула. В понедельник впервые включили подготовленный заранее МФУ: очередь на его будущий адрес 192.168.10.240 уже была развёрнута на 34 рабочих станциях, но активной аренды у устройства ещё не было. На DC02 резервации не оказалось, .240 входил в исключение, поэтому сервер выдал устройству 192.168.10.87 из динамического пула. Одновременно вернулись из ремонта два терминала, чьи старые аренды уже истекли, и возник тот же симптом.

На разбор ушло около двадцати минут, ещё сорок минут я проверял направление будущей репликации. За время работы DC02 успел выдать примерно полсотни новых и продлённых аренд, но это не мешало операции: командлет репликации переносит конфигурацию области, а не заменяет базу действующих аренд. После экспорта DC02 я запустил копирование с DC01. На партнёре появились все 14 резерваций, новое значение опции 006 и политика. Затем на МФУ вручную инициировали обновление DHCP-аренды; к 10:20 очереди снова печатали по подготовленному адресу.

Краткий отказ партнёра не обязан немедленно сломать старые аренды. Отложенная опасность возникает у новых клиентов, устройств после ремонта и техники, которая включается редко. Именно поэтому проверять резервации нужно до окна обслуживания, а не ждать первого изменившегося адреса.
DHCP failover в Windows Server 2025: что не едет само — схема
Схема к статье. Открыть схему в полном размере

Три уровня репликации и точный синтаксис командлета

Microsoft описывает три уровня охвата. Server replication копирует конфигурацию всех failover-областей выбранного сервера соответствующим партнёрам. Relationship replication обрабатывает все области указанного отношения. Scope replication ограничивается перечисленными идентификаторами областей. В оснастке DHCP им соответствуют команды Replicate Failover Scopes на узле IPv4, Replicate Relationship на failover-области и Replicate Scope на конкретной области.

В PowerShell все три операции выполняет командлет Invoke-DhcpServerv4FailoverReplication из модуля DhcpServer. У него два набора параметров: Name и ScopeId. Если передать ScopeId, копируются перечисленные области, состоящие в отношениях failover. Если передать Name, копируются все области указанных отношений. Если не передать ни Name, ни ScopeId, команда охватывает все failover-области исходного DHCP-сервера и может обратиться сразу к нескольким партнёрам.

Параметр ComputerName обозначает DHCP-сервер, чья конфигурация станет источником. При его отсутствии источником будет локальный сервер. Force убирает интерактивное подтверждение, WhatIf показывает предполагаемую операцию без её выполнения. Имя параметра в справке записано как ScopeId; регистр букв для PowerShell несущественен, но в скриптах я придерживаюсь написания из документации.

Справка командлета точно перечисляет содержимое репликации: свойства области, резервации, значения опций области и политики области. Экспортировать каждую резервацию в CSV и затем создавать её отдельной командой не требуется. После выполнения нужно проверить выведенные идентификаторы областей и затем прочитать конфигурацию уже с партнёра. Отсутствие исключения PowerShell доказывает только то, что вызов завершился, но не заменяет проверку ожидаемого охвата.

Для повседневной работы я выбираю уровень отношения и всегда указываю Name. Вызов без Name и ScopeId шире: он отправит все failover-области сервера их партнёрам, в том числе области других филиалов и отношений.

Направление репликации: сначала резервная копия, затем перезапись

Самая дорогая ошибка здесь — перепутать источник и получателя. Репликацию разрешено инициировать с любого из двух партнёров, но настройки всегда движутся от сервера, на котором запущена операция, к партнёру. Если новые резервации находятся на DC02, а команду запустили с ComputerName, равным DC01, конфигурация DC01 перезапишет DC02. Никакой встроенной процедуры слияния не появится, даже если объекты на DC02 созданы позже.

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

В следующем примере административная консоль PowerShell открыта непосредственно на принимающем сервере DC02. Поэтому путь C:\ITfresh\DHCP относится однозначно к локальному диску DC02. Команда создаёт каталог, экспортирует всю конфигурацию DHCPv4 и DHCPv6 вместе с арендами, после чего запускает репликацию отношения с источника DC01. Параметр Leases у Export-DhcpServer действительно добавляет данные аренд, а Force разрешает перезаписать файл с совпавшим именем; метка времени делает такое совпадение маловероятным.

Если партнёры работают под разными версиями Windows Server, Microsoft рекомендует изменять настройки и инициировать репликацию с сервера под более новой ОС. Это правило особенно важно при поэтапной миграции. Например, в паре Windows Server 2022 и Windows Server 2025 временным источником конфигурации должен стать сервер 2025. Текущая обзорная документация указывает, что оба партнёра должны работать как минимум под Windows Server 2016, хотя отдельная инструкция по репликации всё ещё содержит более старую предпосылку Windows Server 2012. Для новой пары я ориентируюсь на актуальное требование обзорной статьи.

Безопасная последовательность на DC02: ```powershell $backupDirectory = 'C:\ITfresh\DHCP' $backupStamp = Get-Date -Format 'yyyyMMdd-HHmmss' $backupFile = Join-Path $backupDirectory "dc02-$backupStamp.xml" New-Item -Path $backupDirectory -ItemType Directory -Force | Out-Null Export-DhcpServer ` -File $backupFile ` -Leases ` -Force Invoke-DhcpServerv4FailoverReplication ` -ComputerName 'dc01.zarechye.local' ` -Name 'DC01-DC02' ` -Force ``` Если этот блок запускается не на DC02, заранее решите, на каком компьютере должен оказаться экспортный файл, и проверьте его наличие до репликации.
Порядок действий: Направление репликации: сначала резервная копия, затем перезапись — схема
Порядок действий: Направление репликации: сначала резервная копия, затем перезапись. Открыть схему в полном размере

Что репликация областей не переносит

Командлет репликации работает с конфигурацией DHCPv4-областей. Настройки уровня сервера находятся за этой границей. К ним относятся значения опций, заданные без ScopeId, списки MAC-фильтров Allow и Deny, включённое состояние этих списков, серверные политики, пользовательские классы и vendor classes. Их нужно развернуть на обоих партнёрах отдельно либо перенести контролируемым экспортом и импортом. Я не называю обычную репликацию области средством синхронизации этих объектов, потому что справка командлета такого поведения не обещает.

Особенно внимательно я проверяю учётные данные динамических обновлений DNS. Если DHCP регистрирует A- и PTR-записи за клиентов, оба партнёра должны использовать одну и ту же учётную запись. Microsoft объясняет причину через владение DNS-записью: запись, созданную одним DHCP-сервером, второй сервер с другими учётными данными обновить не сможет. Учётные данные задаются командлетом Set-DhcpServerDnsCredential отдельно на каждом сервере и передаются параметром Credential как объект PSCredential.

Для фильтров нужны две проверки. Get-DhcpServerv4Filter возвращает сами MAC-адреса из списков Allow и Deny; без параметра List возвращаются оба списка. Get-DhcpServerv4FilterList показывает, включены ли эти списки. Одинаковые записи при разном состоянии фильтрации всё равно означают разное поведение серверов. При переходе обслуживания на партнёра выключенный Allow-лист способен допустить устройства, которым основной сервер адрес не выдавал.

DHCPv6-области в DHCP failover не поддерживаются. Для stateless DHCPv6 Microsoft допускает два сервера с одинаковой конфигурацией опций, а для stateful-развёртываний называет split scope возможным вариантом высокой доступности. Это отдельная архитектура, а не параметр рассматриваемого командлета. Новая DHCPv4-область тоже не становится failover-областью от обычной репликации: её сначала добавляют в существующее отношение командлетом Add-DhcpServerv4FailoverScope, причём область должна существовать на исходном сервере и не должна заранее существовать у партнёра.

Для работы failover партнёры должны синхронизировать время. Если во время настройки разница превышает одну минуту, мастер останавливается с критической ошибкой. В рабочих сообщениях протокола также передаётся UTC-время; при расхождении больше минуты принимающий сервер регистрирует критическое событие. Соединение партнёров использует TCP 647, а при установке роли DHCP Server Windows добавляет правила Microsoft-Windows-DHCP-Failover-TCP-In и Microsoft-Windows-DHCP-Failover-TCP-Out. Правила нужно проверять, если между серверами появился локальный или сетевой межсетевой экран.

Сводная проверка серверных настроек: ```powershell $dhcpServers = 'dc01.zarechye.local','dc02.zarechye.local' foreach ($dhcpServer in $dhcpServers) { $dnsCredential = Get-DhcpServerDnsCredential -ComputerName $dhcpServer $filterState = Get-DhcpServerv4FilterList -ComputerName $dhcpServer [pscustomobject]@{ Server = $dhcpServer DnsCredential = $dnsCredential.UserName ServerOptionCount = @( Get-DhcpServerv4OptionValue -ComputerName $dhcpServer -All ).Count FilterEntryCount = @( Get-DhcpServerv4Filter -ComputerName $dhcpServer ).Count AllowListEnabled = $filterState.Allow DenyListEnabled = $filterState.Deny } } ``` Количество объектов — только индикатор. При несовпадении нужно сравнить сами значения, а при совпадении количества всё равно остаётся проверить их содержимое.

Автоматизация: ежедневная сверка без слепой репликации

После инцидента хочется поставить ежечасный запуск репликации и больше о проблеме не думать. Я не считаю такую задачу безопасной. Она превращает выбранный сервер в безусловный источник истины и регулярно стирает всё, что кто-то законно изменил на партнёре. Если направление не закреплено организационно, автоматизация лишь ускорит ошибку.

Я начинаю с ежедневной сверки. Скрипт ниже получает отношение с DC01, проверяет его состояние, затем сравнивает резервации и все значения опций каждой области. Параметр All у Get-DhcpServerv4OptionValue важен: без него возвращаются стандартные значения указанного уровня, а class-specific и policy-specific варианты можно пропустить. Для резерваций в сигнатуру включены IPAddress, ClientId, Name, Type и Description.

Строковое представление объектов перед сравнением отсортировано. Благодаря этому разный порядок выдачи командлетов не создаёт ложную тревогу. Скрипт не вызывает репликацию и не решает, какой сервер прав. Его задача скромнее и полезнее: зафиксировать отклонение до того, как один из партнёров станет единственным доступным DHCP.

Источник ITF-DHCP для журнала Application нужно создать один раз из повышенной консоли. В самом ежедневном скрипте повторять New-EventLog не следует. Событие 9001 — выбранный нами внутренний идентификатор, а не штатное событие Microsoft DHCP. На него можно настроить триггер Zabbix, PRTG, SIEM или другой системы мониторинга.

Для чтения данных обоих DHCP-серверов задача должна работать под учётной записью с правами на обоих партнёрах. Группа DHCP Users предоставляет доступ только для просмотра и подходит для сверки; для репликации потребуются административные права на DHCP. Я не полагаюсь на LocalSystem при удалённом запросе: его машинная учётная запись по умолчанию не обязана иметь доступ ко второму серверу. Сервисной учётке также нужно предоставить право пакетного входа, если этого не сделал Task Scheduler или доменная политика.

Скрипт сверки для Windows PowerShell: ```powershell $sourceServer = 'dc01.zarechye.local' $partnerServer = 'dc02.zarechye.local' $relationshipName = 'DC01-DC02' $eventSource = 'ITF-DHCP' $problems = [System.Collections.Generic.List[string]]::new() function Get-ReservationSignature { param( [Parameter(Mandatory)] [string]$Server, [Parameter(Mandatory)] [ipaddress]$ScopeId ) Get-DhcpServerv4Reservation -ComputerName $Server -ScopeId $ScopeId | ForEach-Object { '{0}|{1}|{2}|{3}|{4}' -f ` $_.IPAddress, $_.ClientId, $_.Name, $_.Type, $_.Description } | Sort-Object } function Get-OptionSignature { param( [Parameter(Mandatory)] [string]$Server, [Parameter(Mandatory)] [ipaddress]$ScopeId ) Get-DhcpServerv4OptionValue ` -ComputerName $Server ` -ScopeId $ScopeId ` -All | ForEach-Object { [pscustomobject]@{ OptionId = $_.OptionId Value = @($_.Value) -join ',' VendorClass = [string]$_.VendorClass UserClass = [string]$_.UserClass PolicyName = [string]$_.PolicyName } | ConvertTo-Json -Compress } | Sort-Object } $relationship = Get-DhcpServerv4Failover ` -ComputerName $sourceServer ` -Name $relationshipName if ($relationship.State -ne 'Normal') { $problems.Add( «Отношение $($relationship.Name): состояние $($relationship.State)» ) } foreach ($scopeId in $relationship.ScopeId) { $sourceReservations = Get-ReservationSignature ` -Server $sourceServer ` -ScopeId $scopeId $partnerReservations = Get-ReservationSignature ` -Server $partnerServer ` -ScopeId $scopeId $reservationDifference = Compare-Object ` -ReferenceObject $sourceReservations ` -DifferenceObject $partnerReservations if ($reservationDifference) { $problems.Add( «Область $scopeId: расходятся резервации; отличий $($reservationDifference.Count)» ) } $sourceOptions = Get-OptionSignature ` -Server $sourceServer ` -ScopeId $scopeId $partnerOptions = Get-OptionSignature ` -Server $partnerServer ` -ScopeId $scopeId $optionDifference = Compare-Object ` -ReferenceObject $sourceOptions ` -DifferenceObject $partnerOptions if ($optionDifference) { $problems.Add( «Область $scopeId: расходятся значения опций; отличий $($optionDifference.Count)» ) } } if ($problems.Count -gt 0) { Write-EventLog ` -LogName 'Application' ` -Source $eventSource ` -EventId 9001 ` -EntryType Warning ` -Message ($problems -join [Environment]::NewLine) exit 1 } exit 0 ``` Однократное создание источника события: ```powershell New-EventLog -LogName 'Application' -Source 'ITF-DHCP' ``` Регистрация ежедневной задачи на 07:30 под отдельной доменной учётной записью: ```powershell $taskCredential = Get-Credential 'ZARECHYE\svc-dhcp-audit' $taskAction = New-ScheduledTaskAction ` -Execute 'powershell.exe' ` -Argument '-NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\ITfresh\dhcp-failover-check.ps1"' $taskTrigger = New-ScheduledTaskTrigger -Daily -At '07:30' Register-ScheduledTask ` -TaskName 'ITF-DHCP-Failover-Check' ` -Action $taskAction ` -Trigger $taskTrigger ` -User $taskCredential.UserName ` -Password $taskCredential.GetNetworkCredential().Password ` -RunLevel Highest ` -Force Remove-Variable taskCredential ``` Пароль здесь передаётся локальному API Task Scheduler и не выводится в консоль, но для долговременной эксплуатации лучше применять управляемую сервисную учётную запись и действующие в организации правила хранения секретов.

Что проверить сегодня и как закрепить порядок

Первую проверку можно выполнить за пятнадцать минут, если отношений и областей немного. Получите список отношений на обоих серверах, сравните состояния и состав ScopeId. Затем сравните резервации и значения опций по каждой области. Отдельно проверьте DNS credentials, MAC-фильтры и состояние списков Allow/Deny. Если всё совпало, это хороший исходный момент для включения ежедневного контроля.

Если найдено расхождение, не запускайте Force по привычке. Сначала сохраните вывод сравнения, выясните, где находится утверждённая конфигурация, и поговорите с коллегой, который последним менял DHCP. Затем экспортируйте принимающую сторону и используйте минимально необходимый уровень охвата: одну область либо одно отношение. Репликация всех отношений сервера оправданна только тогда, когда вы действительно проверили их все.

Приоритет я расставляю по влиянию. Сначала резервации устройств, адреса которых используются в очередях печати, системах склада, видеонаблюдении и контроле доступа. Затем опции 003 и 006: неверный шлюз или DNS способен затронуть целый VLAN. После них — учётные данные динамического DNS, фильтры и политики. MCLT и долю load balance я не меняю без отдельной причины. Значения по умолчанию для нового отношения — MCLT один час, load balance 50 процентов, а автоматический переход из COMMUNICATION INTERRUPTED в PARTNER DOWN по умолчанию выключен. Если автоматический переход нужен, его включают осознанно и выбирают StateSwitchInterval с учётом каналов между площадками.

В агрохолдинге «Заречье», 140 сотрудников, 5 площадок, мы закрепили простое правило: изменения failover-областей выполняются на DC01, после каждой согласованной правки запускается репликация отношения, а DC02 считается принимающей стороной. Напоминание внесли в Description каждой области и в регламент изменений. Ежедневная задача только сравнивает конфигурацию и поднимает тревогу; право автоматически перезаписывать партнёра ей не дали. За счёт этого плановое обслуживание сервера перестало быть проверкой качества конфигурации на живых пользователях.

DHCP failover — не кластер с общей конфигурационной базой. Это два DHCP-сервера с синхронизированными состояниями аренд и отдельной операцией переноса настроек областей. Рабочая модель проста: изменения делаются на назначенном источнике, репликация выполняется осознанно, а расхождения ищет автоматическая проверка.
Порядок действий: Что проверить сегодня и как закрепить порядок — схема
Порядок действий: Что проверить сегодня и как закрепить порядок. Открыть схему в полном размере

Частые вопросы

Резервации можно реплицировать штатно или нужен отдельный копировщик?

Можно штатно. `Invoke-DhcpServerv4FailoverReplication` включает в конфигурацию области резервации, свойства области, значения опций и политики. Отдельный скрипт полезен для сравнения и оповещения, а не для обязательного копирования каждой записи.

Репликация конфигурации удалит активные аренды партнёра?

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

С какого сервера запускать команду?

С того, где находится правильная конфигурация. Значение ComputerName обозначает источник, а его партнёр становится получателем. Для партнёров с разными версиями ОС Microsoft рекомендует изменять настройки и начинать репликацию с сервера под более новой Windows Server.

Почему устройство не обязательно меняет адрес сразу после отказа?

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

Можно ли запускать репликацию каждый час?

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

Появится ли новая область на партнёре после обычной репликации?

Нет. Сначала существующую на исходном сервере область нужно добавить в отношение командлетом `Add-DhcpServerv4FailoverScope` или через оснастку DHCP. Область не должна уже существовать на партнёре. После включения в отношение её последующие изменения можно реплицировать обычным командлетом.

Что нужно проверять отдельно от областей?

Значения опций уровня сервера, серверные политики, пользовательские и vendor classes, MAC-фильтры, включённое состояние Allow/Deny и учётные данные динамических обновлений DNS. Одинаковые DNS credentials обязательны, если оба DHCP-сервера регистрируют записи за клиентов.

Как MCLT связан с переходом в PARTNER DOWN?

MCLT ограничивает, насколько сервер может продлить аренду сверх времени, известного партнёру, и участвует в безопасном получении контроля над адресами партнёра. StateSwitchInterval — другой таймер: при включённом AutoStateTransition он определяет время перехода из COMMUNICATION INTERRUPTED в PARTNER DOWN. После перехода серверу всё равно требуется дождаться MCLT, прежде чем он безопасно получит полный свободный пул партнёра.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

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

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи