4013 предупреждение microsoft windows dns server service dns server

Troubleshoot DNS Event ID 4013 (The DNS server was unable to load AD-integrated DNS zones)

This article resolves the event ID 4013 logged in the DNS event log of domain controllers that are hosting the DNS server role after Windows starts.

Original product version: В Windows Server 2012 R2
Original KB number: В 2001093

Symptoms

On a Windows-based computer that’s hosting Active Directory domain controllers, the DNS server roles stop responding for 15 to 25 minutes. This issue occurs after the Preparing network connections message is displayed, and before the Windows logon prompt (Ctrl+Alt+Del) is displayed.

The following DNS Event ID 4013 is logged in the DNS event log of domain controllers that are hosting the DNS server role after Windows starts:

Event Type: Warning
Event Source: DNS
Event Category: None
Event ID: 4013
Date: Date
Time: Time
User: N/A
Computer: ComputerName
Description:
The DNS server was unable to open the Active Directory. This DNS server is configured to use directory service information and can not operate without access to the directory. The DNS server will wait for the directory to start. If the DNS server is started but the appropriate event has not been logged, then the DNS server is still waiting for the directory to start.

In this log entry, values of may not be logged. Or, they include but aren’t limited to the following values:

Example customer scenarios

Multiple domain controllers in an Active Directory site that are simultaneously rebooted.

Opening the DNS management console (DNSMGMT.MSC) fails and generates the following error message:

The server could not be contacted. The error was: The server is unavailable. Would you like to add it anyway?

Opening the Active Directory Users and Computers snap-in (DSA.MSC) generates the following error message:

Naming information could not be located

Single domain controllers in an Active Directory site

One domain controller is deployed in a site.

The DNS Server role is installed, and it hosts AD-integrated copies of the _msdcs. and Active Directory domain zones.

The domain controller points to itself for preferred DNS.

The domain controller has no alternative DNS server specified or points to a domain controller over a wide-area network (WAN) link.

The domain controller is restarted because of a power outage.

During restart, the WAN link may not be operational.

When the domain controller is started, it may hang for 20 minutes. This issue occurs after Preparing network connections is displayed, and before the logon prompt is displayed.

DNS Event ID 4013 is logged in the DNS event log.

Opening the DNS management console (DNSMGMT.MSC) fails and generates the following error message:

The server could not be contacted. The error was: The server is unavailable. Would you like to add it anyway?

Opening the Active Directory Users and Computers snap-in (DSA.MSC) generates the following error message:

Naming information could not be located.

Cause

The copy of Active Directory in some domain controllers contains references to other domain controllers in the forest. These domain controllers try to inbound replicate all locally held directory partitions during Windows startup, as part of an initial synchronization or init sync.

In an attempt to boot with the latest DNS zone contents, Microsoft DNS servers that host AD-integrated copies of DNS zones delay DNS service startup for several minutes after Windows startup. The delay won’t occur if Active Directory has completed its initial synchronization during Windows startup. Meanwhile, Active Directory is delayed from inbound replicating directory partitions. Replication is delayed until it can resolve the CNAME GUID of its source domain controller to an IP address on the DNS servers used by the destination domain controller for name resolution. The duration of the hang while preparing network connections depends on the number of locally held directory partitions residing in a domain controller’s copy of Active Directory. Most domain controllers have at least the following five partitions:

And these domain controllers can experience a 15-20 minute startup delay. The existence of extra partitions increases the startup delay.

DNS Event ID 4013 in the DNS event log indicates that DNS service startup was delayed. It’s because inbound replication of Active Directory partitions hadn’t occurred.

Multiple conditions can exacerbate the following issues:

These conditions include:

In Windows Server 2003 and Windows 2000 Server SP3 or later, the domain controllers that host operations master roles must also successfully replicate inbound changes on the directory partition that maintains the operations master role’s state. Successful replication must occur before FSMO-dependent operations can be performed. Such initial synchronizations were added to ensure domain controllers were in agreement about FSMO role ownership and role state. The initial sync requirements required for FSMO roles to become operational is different from the initial sync discussed in this article, where Active Directory must inbound replicate to start the DNS Server service immediately.

Resolution

Some Microsoft and external content have recommended setting the registry value Repl Perform Initial Synchronizations to 0 to bypass initial synchronization requirements in Active Directory. The specific registry subkey and the values for that setting are as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Value name: Repl Perform Initial Synchronizations
Value type: REG_DWORD
Value data: 0

This configuration change isn’t recommended for use in production environments, or in any environment on an ongoing basis. The use of Repl Perform Initial Synchronizations should be used only in critical situations to resolve temporary and specific problems. The default setting should be restored after such problems are resolved.

Other feasible options include:

Remove references to stale domain controllers.

Make offline or non-functioning domain controllers operational.

Domain controllers hosting AD-integrated DNS zones shouldn’t point to a single domain controller and especially only to themselves as preferred DNS for name resolution.

DNS name registration and name resolution for domain controllers is a relatively lightweight operation that’s highly cached by DNS clients and servers.

Configuring domain controllers to point to a single DNS server’s IP address, including the 127.0.0.1 loopback address, represents a single point of failure. This setting is tolerable in a forest with only one domain controller, but not in forests with multiple domain controllers.

Hub-site domain controllers should point to DNS servers in the same site as them for preferred and alternate DNS server and then finally to itself as another alternate DNS server.

Branch site domain controllers should configure the preferred DNS server IP address to point to a hub-site DNS server, the alternate DNS server IP address to point to an in-site DNS server or one in the closest available site, and finally to itself using the 127.0.0.1 loopback address or current static IP address.

Pointing to hub-site DNS servers reduces the number of hops required to get critical domain controller SRV and HOST records fully registered. Domain controllers within the hub site tend to get the most administrative attention, typically have the largest collection of domain controllers in the same site. Because they’re in the same site, replicate changes between each other occur:

This behavior makes such DNS records well known.

Dynamic domain controller SRV and host A and AAAA record registrations may not make it off-box if the registering domain controller in a branch site is unable to outbound replicate.

Member computers and servers should continue to point to site-optimal DNS servers as preferred DNS. And they may point to off-site DNS servers for additional fault tolerance.

Your ultimate goal is to prevent everything from causing a denial of service while balancing costs, risks, and network utilization, such as:

Make sure that destination domain controllers can resolve source domain controllers using DNS (for example, avoid fallback).

You should ensure that domain controllers can successfully resolve the guided CNAME records to host records of current and potential source domain controllers. Doing so can avoid high latency that’s introduced by name resolution fallback logic.

Domain controllers should point to DNS servers that:

Missing, duplicate, or stale CNAME and host records all contribute to this problem. Scavenging isn’t enabled on Microsoft DNS servers by default, increasing the probability of stale host records. At the same time, DNS scavenging can be configured too aggressively, causing valid records to be prematurely purged from DNS zones.

Optimize domain controllers for name resolution fallback.

The inability to configure DNS properly so that domain controllers could resolve the domain controller CNAME GUID records to host records in DNS was common. To ensure end-to-end replication of Active Directory partitions, Windows Server 2003 SP1 and later domain controllers were modified to perform name resolution fallback:

The NTDS replication Event IDs 2087 and 2088 in the Directory Service event logs indicate that:

WINS, HOST files, and LMHOST files can all be configured. So destination domain controllers can resolve the names of current and potential source domain controllers. Of the three solutions, the use of WINS is more scalable, because WINS supports dynamic updates.

The IP addresses and names for computers inevitably become stale. This issue causes static entries in HOST and LMHOST files to become invalid over time. When this issue occurs, queries for one domain controller may be incorrectly resolved to another domain controller. And no name query is observed in a network trace.

Change the startup value for the DNS server service to manual if booting into a known bad configuration.

If booting a domain controller in a known bad configuration that’s discussed in this article, follow these steps:

If the service startup value for DNS Server service is set to manual, Active Directory doesn’t wait for the DNS Server service to start.

Additional considerations

Avoid single points of failure.

Examples of single points of failure include:

Install enough DNS servers for local, regional, and enterprise-wide redundancy performance but not so many that management becomes a burden. DNS is typically a lightweight operation that is highly cached by DNS clients and DNS servers.

Each Microsoft DNS server running on modern hardware can satisfy 10,000-20,000 clients per server. Installing the DNS role on every domain controller can lead to an excessive number of DNS servers in your enterprise. And doing so will increase cost.

Stagger the reboots of DNS servers in your enterprise when possible.

If Windows Update or management software is installing software that requires reboot, stagger the installs on targeted domain controllers so that half the available DNS servers that domain controllers point to for name resolution reboot at the same time.

Install UPS devices in strategic places to ensure DNS availability during short-term power outages.

Augment your UPS-backed DNS servers with on-site generators.

To deal with extended outages, some customers have deployed on-site electrical generators to keep key servers online. Some customers have found that generators can power servers in the data center but not the on-site HVAC. The lack of air conditioning may cause local servers to shut down when internal computer temperatures reach a certain threshold.

More information

May 10, 2010 testing by the Active Directory development team:

DNS waits for NTDS and it can’t start until the initial replication of the directory has been completed. It’s because up-to-date DNS data might not be replicated onto the domain controller yet. On the other hand, NTDS needs DNS to resolve the IP address of the source domain controller for the replication. Assume that DC1 points to DC2 as its DNS server, and DC2 points to DC1 as its DNS server. When both DC1 and DC2 reboot simultaneously, there will be a slow startup because of this mutual dependency. The root cause of this slow startup is DNSQueryTimeouts.

If the DNS Server service runs well when NTDS starts, NTDS takes only two DNS queries to resolve the IP address of the source domain controller:

And these DNS queries return almost instantaneously.

If the DNS Server service isn’t available when NTDS starts, NTDS will need to send out 10 DNS queries to resolve the IP address:

Latency for each DNS query is controlled by DNSQueryTimeouts. By default, DNSQueryTimeouts is set to 1 1 2 4 4. It means that DNS client will wait 12 (1 + 1 + 2 + 4 + 4) seconds for the DNS server response. Each naming context source takes 120 seconds to resolve the IP address. Assume that there are five naming contexts (Configuration, Schema, domain, ForestDnsZones, DomainDnsZones), and one single replication source. In this scenario, it will take 850 (170 X 5) seconds, or greater than 14 minutes, for NTDS to finish initial replication.

Several tests were done to validate the above behavior.

Reboot domain controller when DNS server is a third domain controller that is online. For each naming context each source, we have two DNS queries and they finished almost instantaneously:

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com
in resolveDnsAddressWithFallback
GUID based DNS name
in GetIpVxAddrByDnsNameW
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:31:40.534
end GetAddrInfoW: 22:31:40.534
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:31:40.534
end GetAddrInfoW: 22:31:40.534

Reboot DC1 and DC2 simultaneously. DC1 is using DC2 for DNS DC2 is using DC1 for DNS. For each naming context each source, we have 10 DNS queries and each query takes about 12 seconds:

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com
in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.microsoft.com
in resolveDnsAddressWithFallback
GUID based DNS name
in GetIpVxAddrByDnsNameW
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:37:43.066
end GetAddrInfoW: 22:37:55.113
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:37:55.113
end GetAddrInfoW: 22:38:07.131
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:38:07.131
end GetAddrInfoW: 22:38:19.161
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:38:19.176
end GetAddrInfoW: 22:38:31.185
FQDN
in GetIpVxAddrByDnsNameW
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:38:31.200
end GetAddrInfoW: 22:38:43.182
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:38:43.182
end GetAddrInfoW: 22:38:55.191
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:38:55.191
end GetAddrInfoW: 22:39:07.216
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:39:07.216
end GetAddrInfoW: 22:39:19.286
NetBios
in GetIpVxAddrByDnsNameW
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:39:19.286
end GetAddrInfoW: 22:39:31.308d
in GetIpAddrByDnsNameHelper
start GetAddrInfoW: 22:39:31.308
end GetAddrInfoW: 22:39:43.324

To further study the relationship between DNSQueryTimeouts and the slow startup, DNSQueryTimeouts were set to 1 1 2 4 4 to make DNS client wait for 31 (1 + 1 + 2 + 4 + 4) seconds. In this test, 31 seconds were spent waiting:

Источник

Устранение неполадок DNS Event ID 4013 (DNS-сервер не мог загружать зоны DNS, интегрированные с AD)

В этой статье устраняется ИД события 4013, войдите в журнал событий DNS контроллеров доменов, которые после начала Windows будут принимать роль сервера DNS.

Оригинальная версия продукта: Windows Server 2012 R2
Исходный номер КБ: 2001093

Симптомы

На компьютере на базе Windows, где размещены контроллеры домена Active Directory, роли DNS-сервера перестают отвечать на 15-25 минут. Эта проблема возникает после отображения сообщения о подготовке сетевых подключений и до отображения запроса логотипа Windows (Ctrl+Alt+Del).

Следующий DNS Event ID 4013 регистрируется в журнале событий DNS контроллеров доменов, которые после начала Windows будут принимать роль сервера DNS:

Тип события: Предупреждение
Источник событий: DNS
Категория событий: Нет
ID события: 4013
Дата: Дата
Время: время
Пользователь: N/A
Компьютер: ComputerName
Описание:
Сервер DNS не смог открыть Active Directory. Этот DNS-сервер настроен на использование данных службы каталогов и не может работать без доступа к каталогу. DNS-сервер будет ждать запуска каталога. Если DNS-сервер запущен, но соответствующее событие не было в журнале, то DNS-сервер по-прежнему ожидает запуска каталога.

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

Примеры сценариев клиентов

Несколько контроллеров домена на сайте Active Directory, которые одновременно перезагружаются.

Открытие консоли управления DNS (DNSMGMT. MSC) сбой и создает следующее сообщение об ошибке:

Связаться с сервером не удалось. Ошибка была: сервер недоступен. Хотите добавить его в любом случае?

Открытие оснастки пользователей и компьютеров Active Directory (DSA). MSC) создает следующее сообщение об ошибке:

Сведения о именова-именах не могут быть расположены

Единые контроллеры домена на сайте Active Directory

Один контроллер домена развернут на сайте.

Установлена роль DNS Server, в ней размещены встроенные в AD копии _msdcs. и доменные зоны Active Directory.

Контроллер домена указывает на себя для предпочтительного DNS.

Контроллер домена не имеет альтернативного DNS-сервера, указанного или указывает на контроллер домена по ссылке широкой сети (WAN).

Контроллер домена перезапущен из-за отключения электроэнергии.

Во время перезапуска может не работать ссылка WAN.

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

DNS Event ID 4013 входит в журнал событий DNS.

Открытие консоли управления DNS (DNSMGMT. MSC) сбой и создает следующее сообщение об ошибке:

Связаться с сервером не удалось. Ошибка была: сервер недоступен. Хотите добавить его в любом случае?

Открытие оснастки пользователей и компьютеров Active Directory (DSA). MSC) создает следующее сообщение об ошибке:

Сведения о именова-именах не могут быть расположены.

Причина

Копия Active Directory в некоторых контроллерах домена содержит ссылки на другие контроллеры домена в лесу. Эти контроллеры домена пытаются реплицировать все локальные разделы каталогов во время запуска Windows в рамках начальной синхронизации или синхронизации init.

В попытке загрузки с последним контентом зоны DNS серверы Microsoft DNS, на которые встроены AD-копии зон DNS, задерживают запуск службы DNS на несколько минут после запуска Windows. Задержка не произойдет, если Active Directory выполнил первую синхронизацию во время запуска Windows. Тем временем Active Directory задерживается из-за входящие разделы репликации каталогов. Репликация отложена до тех пор, пока она не сможет разрешить GUID CNAME своего контроллера исходных доменов на IP-адрес на DNS-серверах, используемых контроллером домена назначения для разрешения имен. Длительность зависания при подготовке сетевых подключений зависит от количества локальных разделов каталогов, проживающих в копии Active Directory контроллера домена. Большинство контроллеров домена имеют по крайней мере следующие пять разделов:

И эти контроллеры домена могут испытывать задержку запуска на 15-20 минут. Наличие дополнительных разделов увеличивает задержку запуска.

DNS Event ID 4013 в журнале событий DNS указывает на задержку запуска службы DNS. Это происходит из-за того, что входящие репликации разделов Active Directory не происходили.

Несколько условий могут усугубить следующие проблемы:

К этим условиям относятся следующие условия:

В Windows Server 2003 и Windows 2000 Server SP3 или более поздних версиях контроллеры доменов, которые исполняют главные роли в операциях, также должны успешно реплицировать входящие изменения в раздел каталога, который поддерживает состояние роли главных операций. Перед выполнением операций, зависящих от FSMO, необходимо выполнить успешную репликацию. Такие начальные синхронизации были добавлены, чтобы убедиться, что контроллеры домена были в согласии с владением ролью FSMO и состоянием ролей. Начальные требования к синхронизации, необходимые для работы ролей FSMO, отличаются от начальной синхронизации, о которой говорится в этой статье, когда Active Directory должен входящие репликации, чтобы немедленно запустить службу DNS Server.

Решение

Некоторые microsoft и внешний контент рекомендовали установить значение реестра до 0, чтобы обойти начальные требования к синхронизации Repl Perform Initial Synchronizations в Active Directory. Подкайка конкретного реестра и значения для этого параметра являются следующими:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Имя значения: Repl Perform Initial Synchronizations
Тип значения: REG_DWORD
Данные значения: 0

Это изменение конфигурации не рекомендуется использовать в производственных средах или в любой среде на постоянной основе. Использование следует Repl Perform Initial Synchronizations использовать только в критических ситуациях для решения временных и конкретных проблем. Параметр по умолчанию должен быть восстановлен после решения таких проблем.

Другие возможные варианты:

Удалите ссылки на устаревшие контроллеры домена.

Сделайте автономные или не функционируют контроллеры домена рабочими.

Контроллеры домена, принимающие зоны DNS, интегрированные с AD, не должны указать на один контроллер домена и особенно только на себя в качестве предпочтительного DNS для разрешения имен.

Регистрация имен dNS и разрешение имен для контроллеров домена — это относительно легкая операция, которая очень кэшется клиентами и серверами DNS.

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

Контроллеры домена hub-site должны указать на DNS-серверы на том же сайте, что и для предпочитаемого и альтернативного DNS-сервера, а затем в качестве другого альтернативного DNS-сервера.

Контроллеры домена веб-сайтов филиала должны настроить предпочтительный IP-адрес DNS-сервера, чтобы указать на сервер DNS-узла, альтернативный IP-адрес DNS-сервера, чтобы указать на сервер DNS на месте или на ближайший доступный сайт, и, наконец, на себя с помощью 127.0.0.0.1 или текущего статического IP-адреса.

Указать на серверы DNS-узлового узла уменьшает количество переходов, необходимых для полной регистрации критически важных записей контроллера домена SRV и HOST. Контроллеры домена на сайте концентратора, как правило, получают наибольшее административное внимание, как правило, имеют самую большую коллекцию контроллеров домена на том же сайте. Поскольку они на одном сайте, происходят изменения репликации между собой:

Такое поведение делает такие записи DNS хорошо известными.

Динамический контроллер домена SRV и регистрации записей A и AAAA не могут сделать его отключенным, если регистрируемый контроллер домена на сайте филиала не сможет реплицировать исходящий.

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

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

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

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

Контроллеры домена должны указать на DNS-серверы, которые:

Недостающие, дублирующие или устаревшие записи CNAME и хост-записей способствуют этой проблеме. Очистка не включена на серверах Microsoft DNS по умолчанию, что повышает вероятность устаревших записей хост-серверов. В то же время очистка DNS может быть настроена слишком агрессивно, что приводит к преждевременной очистке допустимых записей из зон DNS.

Оптимизация контроллеров домена для отката разрешения имен.

Неумело настраивать DNS правильно, чтобы контроллеры домена могли разрешать записи GUID домена CNAME для хозяйских записей в DNS. Для обеспечения конечной репликации разделов Active Directory для выполнения отката разрешения имен были изменены контроллеры SP1 Windows Server 2003 и более поздние контроллеры домена:

В журналах событий службы каталогов репликация событий NTDS 2087 и 2088 указывают на то, что:

Можно настроить файлы WINS, HOST и LMHOST. Так контроллеры домена назначения могут разрешить имена текущих и потенциальных контроллеров домена источника. Из трех решений использование WINS более масштабируемо, так как WINS поддерживает динамические обновления.

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

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

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

Если значение запуска службы для службы DNS Server установлено вручную, Active Directory не ждет запуска службы DNS Server.

Дополнительные рекомендации

Избегайте единичек сбоя.

Примеры одиночных точек сбоя:

Установите достаточноЕ количество DNS-серверов для локальных, региональных и корпоративных показателей избыточности, но не так много, что управление становится бременем. DNS обычно является легкой операцией, которая высоко кэшется клиентами DNS и DNS-серверами.

Каждый сервер Microsoft DNS, работающий на современном оборудовании, может удовлетворять 10 000-20 000 клиентов на каждый сервер. Установка роли DNS на каждом контроллере домена может привести к чрезмерному числу DNS-серверов в вашем предприятии. И это увеличит затраты.

Ошеломляйте перезагрузку DNS-серверов в вашем предприятии, когда это возможно.

Если windows Update или программное обеспечение для управления устанавливает программное обеспечение, требующий перезагрузки, задайте шатаются установки на целевых контроллерах домена, чтобы половина доступных DNS-серверов, которые контроллеры домена указывают на перезагрузку разрешения имен одновременно.

Установка устройств UPS в стратегически важных местах для обеспечения доступности DNS во время кратковременных отключений электроэнергии.

Уполномойте серверы DNS на основе UPS с помощью генераторов на месте.

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

Дополнительные сведения

Тестирование 10 мая 2010 г. командой разработчиков Active Directory:

DNS ждет NTDS, и он не может начаться до завершения начальной репликации каталога. Это потому, что последние данные DNS еще не могут быть реплицированы на контроллер домена. С другой стороны, NTDS необходимо DNS для решения IP-адреса контроллера домена источника для репликации. Предположим, что DC1 указывает на DC2 в качестве DNS-сервера, а DC2 — на DC1 в качестве DNS-сервера. При одновременной перезагрузке DC1 и DC2 запуск будет медленным из-за этой взаимной зависимости. Основной причиной этого медленного запуска является DNSQueryTimeouts.

Если служба DNS Server работает хорошо при запуске NTDS, NTDS принимает только два запроса DNS для решения IP-адреса контроллера домена источника:

И эти DNS-запросы возвращаются практически мгновенно.

Если служба DNS Server недоступна при старте NTDS, NTDS необходимо отправить 10 запросов DNS для решения IP-адреса:

Задержка для каждого запроса DNS контролируется DNSQueryTimeouts. По умолчанию для DNSQueryTimeouts установлено значение 1 1 2 4 4. Это означает, что клиент DNS будет ждать 12 (1 + 1 + 2 + 4 + 4) секунд для ответа сервера DNS. Каждый источник контекста именования занимает 120 секунд для решения IP-адреса. Предположим, что существует пять контекстов именования (Конфигурация, Схема, домен, ForestDnsZones, DomainDnsZones) и один источник репликации. В этом сценарии для завершения начальной репликации NTDS требуется 850 (170 X 5) секунд или более 14 минут.

Для проверки вышеуказанного поведения было сделано несколько тестов.

Перезагрузка контроллера домена, когда DNS-сервер является третьим контроллером домена, который находится в Интернете. Для каждого контекста именования каждого источника у нас есть два запроса DNS, и они завершались практически мгновенно:

в I_DRSGetNCChanges nc = CN=Configuration,DC=contoso,DC=com в getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com
в resolveDnsAddressWithFallback
Имя DNS на основе GUID
в GetIpVxAddrByDnsNameW
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:31:40.534
end GetAddrInfoW: 22:31:40.534
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:31:40.534
end GetAddrInfoW: 22:31:40.534

Перезагрузка DC1 и DC2 одновременно. DC1 использует DC2 для DNS DC2, а DC1 — для DNS. Для каждого контекста именования каждого источника у нас есть 10 запросов DNS и каждый запрос занимает около 12 секунд:

в I_DRSGetNCChanges NC = CN=Configuration,DC=contoso,DC=com
в getContextBindingHelper pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.microsoft.com
в resolveDnsAddressWithFallback
Имя DNS на основе GUID
в GetIpVxAddrByDnsNameW
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:37:43.066
end GetAddrInfoW: 22:37:55.113
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:37:55.113
end GetAddrInfoW: 22:38:07.131
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:38:07.131
end GetAddrInfoW: 22:38:19.161
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:38:19.176
end GetAddrInfoW: 22:38:31.185
полное доменное имя;
в GetIpVxAddrByDnsNameW
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:38:31.200
end GetAddrInfoW: 22:38:43.182
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:38:43.182
end GetAddrInfoW: 22:38:55.191
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:38:55.191
end GetAddrInfoW: 22:39:07.216
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:39:07.216
end GetAddrInfoW: 22:39:19.286
NetBios
в GetIpVxAddrByDnsNameW
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:39:19.286
end GetAddrInfoW: 22:39:31.308d
в GetIpAddrByDnsNameHelper
начало GetAddrInfoW: 22:39:31.308
end GetAddrInfoW: 22:39:43.324

Чтобы дополнительно изучить связь между DNSQueryTimeouts и медленным запуском, DNSQueryTimeouts были назначены 1 1 2 4 4, чтобы клиент DNS ждал 31 (1 + 1 + 2 + 4 + 4) секунды. В этом тесте 31 секунда была потрачена на ожидание:

Источник