Сколько стоит установить windows 10 на компьютер в днс

Обновлено: 29.06.2024

В этой статье решается проблема с идентификатором 4013, зарегистрированная в журнале событий DNS контроллеров домена, на которых размещается роль DNS-сервера после запуска Windows.

Применимо к: Windows Server 2012 R2
Исходный номер базы знаний: 2001093

Симптомы

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

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

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

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

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

  • Домен с двумя контроллерами домена развернут в одном центре обработки данных.
  • Роль DNS-сервера установлена ​​на обоих контроллерах домена и содержит интегрированные в AD копии _msdcs. и доменные зоны Active Directory.
  • DC1 настроен на использование DC2 в качестве предпочтительного DNS и самого себя в качестве альтернативного DNS.
  • DC2 настроен на использование DC1 в качестве предпочтительного DNS и самого себя в качестве альтернативного DNS.
  • Все контроллеры домена имеют источники бесперебойного питания (ИБП) и резервные электрические генераторы.
  • В центре обработки данных часто бывают перебои в подаче электроэнергии на срок от 2 до 10 часов. Устройства ИБП поддерживают работу контроллеров домена до тех пор, пока генераторы не подадут питание, но они не могут управлять системой HVAC. Защита от перегрева, встроенная в компьютеры серверного класса, отключает контроллеры домена, когда внутренняя температура достигает ограничений, установленных производителем.
  • Когда питание в конце концов восстанавливается, контроллеры домена зависают на 20 минут. Эта проблема возникает после отображения сообщения Подготовка сетевых подключений и до отображения запроса на вход в систему.
  • Идентификатор события DNS 4013 регистрируется в журнале событий DNS.

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

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

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

Не удалось найти информацию об именах

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

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

Роль DNS-сервера установлена, и на ней размещаются интегрированные в AD копии файла _msdcs. и доменные зоны Active Directory.

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

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

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

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

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

Идентификатор события DNS 4013 регистрируется в журнале событий DNS.

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

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

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

Не удалось найти информацию об именах.

Причина

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

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

  • схема
  • конфигурация
  • домен
  • раздел приложения DNS для всего леса
  • раздел приложения DNS для всего домена

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

Идентификатор события DNS 4013 в журнале событий DNS указывает на задержку запуска службы DNS. Это связано с тем, что входящая репликация разделов Active Directory не выполнялась.

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

  • медленный запуск Windows
  • регистрация события DNS 4013 на DNS-серверах, настроенных для размещения зон, интегрированных в AD, которые неявно находятся на компьютерах, выступающих в качестве контроллеров домена.

Эти условия включают:

  • Настройка DNS-сервера, на котором размещены зоны DNS, интегрированные в AD. Его копия Active Directory содержит информацию о других контроллерах домена в лесу, чтобы указывать исключительно на себя для разрешения DNS-имен.
  • Настройка DNS-сервера, на котором размещены зоны DNS, интегрированные в AD. Его копия Active Directory содержит информацию о других контроллерах домена в лесу, чтобы указать на DNS-серверы, которые либо не существуют, либо в настоящее время отключены, либо недоступны в сети, либо на которых нет необходимых зон и записей, которые необходимо для входящей репликации Active Directory. Примеры включают запись GUID CNAME контроллера домена и соответствующую запись хоста A или AAAA потенциальных исходных контроллеров домена.
  • Загрузка контроллера домена и DNS-сервера, на котором размещены зоны DNS, интегрированные в AD. Его копия Active Directory содержит информацию о других контроллерах домена в фактически изолированной сети, потому что:
    • Сетевой адаптер или сетевой стек на вызывающем или целевом компьютере отключены или не работают.
    • Контроллер домена был загружен в изолированной сети.
    • Копия Active Directory локального контроллера домена содержит ссылки на устаревшие контроллеры домена, которые больше не существуют в сети.
    • Копия Active Directory локального контроллера домена содержит ссылки на другие контроллеры домена, которые в данный момент отключены.
    • Обнаружена проблема либо на исходном контроллере домена, либо на целевом контроллере домена, либо в DNS, либо в сетевой инфраструктуре. Таким образом, копия Active Directory локального контроллера домена содержит ссылки на другие контроллеры домена, которые подключены к сети и доступны, но с которых невозможно успешно реплицировать.

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

    Разрешение

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

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
    Имя значения: Repl Выполнение начальной синхронизации
    Тип значения: REG_DWORD
    Данные значения: 0

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

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

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

    Включите автономные или неработающие контроллеры домена.

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

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

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

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

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

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

    • каждые 15 секунд в Windows Server 2003 или более поздней версии
    • каждые пять минут в Windows 2000 Server

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

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

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

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

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

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

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

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

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

    Оптимизируйте контроллеры домена для резервного разрешения имен.

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

    • от CNAME GUID контроллера домена до полного имени хоста.
    • с полного имени хоста на имя компьютера NetBIOS.

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

    • Конечному контроллеру домена не удалось преобразовать запись GUID контроллера домена CNAME в запись хоста.
    • происходит резервное разрешение имени.

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

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

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

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

    1. Установите значение запуска службы DNS-сервера вручную.
    2. Перезагрузитесь, дождитесь объявления контроллера домена.
    3. Перезапустите службу DNS-сервера.

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

    Дополнительные соображения

    Избегайте единых точек отказа.

    Примеры единых точек отказа включают:

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

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

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

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

    • Для установки некоторых исправлений, пакетов обновлений и приложений может потребоваться перезагрузка.
    • Некоторые клиенты перезагружают контроллеры домена по расписанию (каждые семь дней, каждые 30 дней).
    • Разумно планируйте перезагрузку и установку программного обеспечения, требующего перезагрузки. Это делается для предотвращения одновременной перезагрузки единственного DNS-сервера или потенциального исходного партнера по репликации, на который конечный контроллер домена указывает для разрешения имен.

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

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

    Дополните свои DNS-серверы, поддерживаемые UPS, генераторами на месте.

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

    Подробнее

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

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

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

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

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

    • четыре для имени на основе GUID
    • четыре для полного имени
    • два для названия с одним ярлыком

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

    Было проведено несколько тестов для проверки описанного выше поведения.

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

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

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

    В этом разделе вы узнаете, как развернуть Windows 10 с помощью пакетов развертывания Microsoft Endpoint Manager и последовательностей задач. В этом разделе описан процесс развертывания образа Windows 10 Корпоративная на компьютере с унифицированным расширяемым интерфейсом встроенного ПО (UEFI) с именем PC0001. Для процедур в этом разделе используется существующая инфраструктура Configuration Manager, интегрированная с MDT.

    В этом разделе предполагается, что вы выполнили следующие предварительные процедуры:

    Для целей данного руководства мы будем использовать как минимум два серверных компьютера (DC01 и CM01) и один клиентский компьютер (PC0001).

    При желании PC0001 может быть виртуальной машиной, размещенной на сервере HV01, который представляет собой хост-компьютер Hyper-V, который мы использовали ранее для создания эталонного образа Windows 10. Однако если PC0001 является виртуальной машиной, необходимо убедиться, что у нее достаточно ресурсов для запуска последовательности задач OSD Configuration Manager. Рекомендуется 2 ГБ ОЗУ или больше.

    Все серверы работают под управлением Windows Server 2019. Однако можно использовать и более раннюю поддерживаемую версию Windows Server.

    Для работы PXE не требуется настройка консоли WDS. Все делается с помощью консоли Configuration Manager.

    Процедуры

    Запустите компьютер PC0001. В меню загрузки Pre-Boot Execution Environment (PXE) нажмите Enter, чтобы разрешить загрузку PXE.

    На странице "Добро пожаловать в мастер последовательности задач" введите пароль pass@word1 и нажмите "Далее".

    На странице "Выберите последовательность задач для запуска" выберите Windows 10 Enterprise x64 RTM и нажмите "Далее".

    На странице "Редактировать переменные последовательности задач" дважды щелкните переменную OSDComputerName и в поле "Значение" введите PC0001 и нажмите кнопку "ОК". Затем нажмите «Далее».

    Развертывание операционной системы займет несколько минут.

    Вы можете отслеживать развертывание на CM01 с помощью MDT Deployment Workbench. Когда вы увидите запись PC0001, дважды щелкните PC0001, а затем нажмите «Удаленное управление DaRT» и просмотрите параметр «Удаленное управление». Последовательность задач запустится и сделает следующее:

    • Установите операционную систему Windows 10.
    • Установите клиент Configuration Manager и исправление клиента.
    • Присоедините компьютер к домену.
    • Установите приложение, добавленное в последовательность задач.

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

    Мониторинг MDT.

    Наблюдение за развертыванием с помощью MDT.

    По завершении развертывания у вас будет присоединенный к домену компьютер с Windows 10 с установленным приложением Adobe Reader, а также приложениями, которые были включены в эталонный образ, например Office 365 Pro Plus.

    В этой статье описаны соглашения об именовании учетных записей компьютеров в Windows, доменных имен NetBIOS, доменных имен DNS, сайтов Active Directory и организационных единиц (OU), определенных в службе каталогов Active Directory.

    Применимо к: Windows Server 2012 R2
    Исходный номер базы знаний: 909264

    Обзор

    В этой статье обсуждаются следующие темы:

    • Допустимые символы для имен
    • Минимальная и максимальная длина имени
    • Зарезервированные имена
    • Имена, которые мы не рекомендуем
    • Общие рекомендации, основанные на поддержке Active Directory в малых, средних и крупных развертываниях.

    Все объекты, названные в Active Directory или в AD/AM и LDS, подлежат сопоставлению имен на основе алгоритма, описанного в следующей статье:

    В этой статье это соглашение об именовании применяется к именам компьютеров, подразделений и сайтов.

    Имена компьютеров

    Имена компьютеров NetBIOS

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

    Имена компьютеров NetBIOS не могут содержать следующие символы:

    Имена могут содержать точку (.). Но имя не может начинаться с точки. Использование не DNS-имен с точками разрешено в Microsoft Windows NT. Точки не должны использоваться в Microsoft Windows 2000 или более поздних версиях Windows. Если вы обновляете компьютер, NetBIOS-имя которого содержит точку, измените имя компьютера. Дополнительные сведения см. в разделе Специальные символы.

    В Windows 2000 и более поздних версиях Windows компьютеры, являющиеся членами домена Active Directory, не могут иметь имена, полностью состоящие из цифр. Это ограничение связано с ограничениями DNS.

    Дополнительную информацию о синтаксисе имен NetBIOS см. в разделе Синтаксис имен NetBIOS.

    Минимальная длина имени: 1 символ

    Максимальная длина имени: 15 символов

    16-й символ зарезервирован для обозначения функций, установленных на зарегистрированном сетевом устройстве.

    Специальные символы: точка (.)

    Точка разделяет имя на идентификатор области NetBIOS и имя компьютера.Идентификатор области NetBIOS — это необязательная строка символов, идентифицирующая логические сети NetBIOS, работающие в одной и той же физической сети TCP/IP. Чтобы NetBIOS работал между компьютерами, компьютеры должны иметь одинаковый идентификатор области действия NetBIOS и уникальные имена компьютеров.

    Использование областей NetBIOS в именах является устаревшей конфигурацией. Его не следует использовать с лесами Active Directory. Дополнительные сведения об областях NetBIOS см. на следующих веб-сайтах:

    Имена узлов DNS

    DNS-имена могут содержать только буквы (A–Z), цифры (0–9), знак минус (-) и точку (.). Символы точки допускаются только в том случае, если они используются для разделения компонентов имен доменного стиля.

    В системе доменных имен (DNS) Windows 2000 и DNS Windows Server 2003 поддерживаются символы Unicode. Другие реализации DNS не поддерживают символы Unicode. Избегайте использования символов Unicode, если запросы будут передаваться на серверы, использующие реализации DNS сторонних производителей.

    Для получения дополнительной информации посетите следующие веб-сайты:

    Имена узлов DNS не могут содержать следующие символы:

    пробел (пусто)

    Подчеркивание играет особую роль. Это разрешено для первого символа в записях SRV по определению RFC. Но новые DNS-серверы также могут разрешать это в любом месте имени. Дополнительную информацию см. в разделе Соответствие ограничениям имен для хостов и доменов.

    Все символы сохраняют форматирование регистра, кроме символов американского стандартного кода для обмена информацией (ASCII).

    Первый символ должен быть буквенным или цифровым.

    Последний символ не должен быть знаком минус или точкой.

    Двухсимвольные пользовательские строки SDDL, перечисленные в списке известных SID, использовать нельзя. В противном случае операции импорта, экспорта и принятия контроля завершатся сбоем.

    В Windows 2000 и более поздних версиях Windows компьютеры, являющиеся членами домена Active Directory, не могут иметь имена, полностью состоящие из цифр. Это ограничение связано с ограничениями DNS.

    При регистрации имени хоста DNS недопустимые символы заменяются символом дефиса (-).

    Минимальная длина имени: 2 символа

    Максимальная длина имени: 63 символа

    Максимальная длина имени хоста и полного доменного имени (FQDN) составляет 63 байта на метку и 255 байтов на полное доменное имя.

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

    В Windows 2000 и Windows Server 2003 максимальное имя хоста и полное доменное имя используют стандартные ограничения длины, упомянутые ранее, с добавлением поддержки UTF-8 (Unicode). Поскольку длина некоторых символов UTF-8 превышает один октет, вы не можете определить размер путем подсчета символов.

    Контроллеры домена должны иметь полное доменное имя менее 155 байт.

    Зарезервированные имена в соответствии с RFC 952

    Для получения дополнительной информации см. rfc952.

    Зарезервированные имена в Windows

    При создании имен для DNS-компьютеров в новой инфраструктуре DNS Windows Server 2003 руководствуйтесь следующими рекомендациями:

    • Выбирайте имена компьютеров, которые пользователям легко запомнить.
    • Указать владельца компьютера в имени компьютера.
    • Выберите имя, описывающее назначение компьютера.
    • Для символов ASCII не используйте регистр, чтобы указать владельца или назначение компьютера. Для символов ASCII DNS не учитывает регистр, Windows и приложения Windows не сохраняют регистр во всех местах.
    • Сопоставьте доменное имя Active Directory с основным DNS-суффиксом имени компьютера. Дополнительную информацию см. в разделе "Разрозненные пространства имен" ниже.
    • Используйте уникальное имя для каждого компьютера в вашей организации. Избегайте одинаковых имен компьютеров для компьютеров в разных доменах DNS.
    • Используйте символы ASCII. Это гарантирует совместимость с компьютерами, на которых установлены более ранние версии Windows, чем Windows 2000.
    • В именах компьютеров DNS используйте только символы, перечисленные в RFC 1123. Эти символы включают A-Z, a-z, 0-9 и дефис (-). В Windows Server 2003 DNS допускает использование большинства символов UTF-8 в именах. Не используйте расширенные символы ASCII или UTF-8, если только все DNS-серверы в вашей среде не поддерживают их.

    Доменные имена

    Вот подробная информация о доменных именах NetBIOS и доменных именах DNS.

    Доменные имена NetBIOS

    Доменные имена NetBIOS могут содержать все буквенно-цифровые символы, за исключением расширенных символов, перечисленных в разделе Запрещенные символы. Имена могут содержать точку, но имена не могут начинаться с точки.

    Имена компьютеров NetBIOS не могут содержать следующие символы:

    Имена могут содержать точку (.).Но имя не может начинаться с точки. Использование не DNS-имен с точками разрешено в Microsoft Windows NT. Точки не должны использоваться в доменах Active Directory. Если вы обновляете домен, NetBIOS-имя которого содержит точку, измените имя, перенеся домен в новую структуру домена. Не используйте точки в новых доменных именах NetBIOS.

    В Windows 2000 и более поздних версиях Windows компьютеры, являющиеся членами домена Active Directory, не могут иметь имена, полностью состоящие из цифр. Это ограничение связано с ограничениями DNS.

    Минимальная длина имени: 1 символ

    Максимальная длина имени: 15 символов.

    16-й символ зарезервирован для обозначения функций, установленных на зарегистрированном сетевом устройстве.

    Зарезервированные имена в Windows

    Имена обновленного домена могут содержать зарезервированное слово. Однако в этой ситуации не удается установить доверительные отношения с другими доменами.

    Специальные символы: точка (.).

    Точка разделяет имя на идентификатор области NetBIOS и имя компьютера. Идентификатор области NetBIOS — это необязательная строка символов, идентифицирующая логические сети NetBIOS, работающие в одной и той же физической сети TCP/IP. Чтобы NetBIOS работал между компьютерами, компьютеры должны иметь одинаковый идентификатор области действия NetBIOS и уникальные имена компьютеров.

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

    Доменные имена DNS

    DNS-имена могут содержать только буквы (A–Z), цифры (0–9), знак минус (-) и точку (.). Символы точки допускаются только в том случае, если они используются для разделения компонентов имен доменного стиля.

    В системе доменных имен (DNS) Windows 2000 и DNS Windows Server 2003 поддерживаются символы Unicode. Другие реализации DNS не поддерживают символы Unicode. Избегайте использования символов Unicode, если запросы будут передаваться на серверы, использующие реализации DNS сторонних производителей.

    Для получения дополнительной информации посетите следующие веб-сайты:

    Имена доменов DNS не могут содержать следующие символы:

    пробел (пусто)

    Подчеркивание играет особую роль. Это разрешено для первого символа в записях SRV по определению RFC. Но новые DNS-серверы также могут разрешать это в любом месте имени. Дополнительную информацию см. в разделе Соответствие ограничениям имен для хостов и доменов.

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

    Все символы сохраняют форматирование регистра, кроме символов ASCII.

    Первый символ должен быть буквенным или цифровым.

    Последний символ не должен быть знаком минус или точкой.

    Минимальная длина имени: 2 символа

    Максимальная длина имени: 255 символов

    Максимальная длина имени хоста и полного доменного имени (FQDN) составляет 63 байта на метку и 255 символов на полное доменное имя. Последнее основано на максимально возможной длине пути для доменного имени Active Directory с путями, необходимыми в SYSVOL , и должно соответствовать ограничению 260 символов MAX_PATH.

    Пример пути в SYSVOL содержит:

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

    Доменное имя AD FQDN появляется в пути дважды, так как длина доменного имени AD FQDN ограничена 64 символами.

    В Windows 2000 и Windows Server 2003 максимальное имя хоста и полное доменное имя используют стандартные ограничения длины, упомянутые ранее, с добавлением поддержки UTF-8 (Unicode). Поскольку длина некоторых символов UTF-8 превышает один октет, вы не можете определить размер путем подсчета символов.

    Пространства доменных имен с одним ярлыком

    Проблемы, связанные с однокомпонентными пространствами имен, включают:

    DNS-имена с одной меткой нельзя зарегистрировать с помощью интернет-регистратора.

    Домены с однокомпонентными DNS-именами требуют дополнительной настройки.

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

    По умолчанию члены домена под управлением Windows Server 2003, члены домена под управлением Windows XP и члены домена под управлением Windows 2000 не выполняют динамические обновления однокомпонентных зон DNS.

    Разрозненные пространства имен

    Как возникают несвязанные пространства имен:

    Первичный контроллер домена Windows NT 4.0 обновляется до контроллера домена Windows 2000 с использованием исходной версии Windows 2000. В элементе "Сеть" на панели управления определяется несколько суффиксов DNS.

    Домен переименовывается, когда лес находится на функциональном уровне леса Windows Server 2003.И основной суффикс DNS не изменяется, чтобы отразить новое доменное имя DNS.

    Последствия разрозненного пространства имен:

    Контроллер домена динамически регистрирует свои записи местоположения службы (SRV) в зоне DNS, соответствующей его доменному имени DNS. Однако контроллер домена регистрирует свои записи узлов в зоне DNS, которая соответствует его основному суффиксу DNS.

    Дополнительную информацию о непересекающихся пространствах имен см. в следующих статьях:

    Другие факторы

    Леса, подключенные к Интернету

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

    Максимальное количество доменов в лесу

    В Windows 2000 максимальное количество доменов в лесу — 800. В Windows Server 2003 и более поздних версиях максимальное количество доменов на функциональном уровне леса 2 — 1200. Это ограничение является ограничением многозначных несвязанных атрибутов. в Windows Server 2003.

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

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

    Избегайте использования общего имени, например, domain.localhost. Другая компания, с которой вы объединитесь через несколько лет, может последовать тому же принципу.

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

    Избегайте использования символов подчеркивания (_) в именах доменов. Приложения могут быть очень послушны RFC и отвергать имя, а также не будут устанавливаться или работать в вашем домене. Кроме того, у вас могут возникнуть проблемы со старыми DNS-серверами.

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

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

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

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

    Названия сайтов

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

    DNS-имена могут содержать только буквы (A–Z), цифры (0–9), знак минус (-) и точку (.). Символы точки допускаются только в том случае, если они используются для разделения компонентов имен доменного стиля.

    В системе доменных имен (DNS) Windows 2000 и DNS Windows Server 2003 поддерживаются символы Unicode. Другие реализации DNS не поддерживают символы Unicode. Избегайте использования символов Unicode, если запросы будут передаваться на серверы, использующие реализации DNS сторонних производителей.

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

    • Вы используете носитель с корпоративной лицензией и общий ключ продукта с корпоративной лицензией для установки одной из следующих операционных систем:
      • Windows Server 2019
      • Windows Server 2016
      • Windows Server 2012 R2
      • Windows Server 2012
      • Windows Server 2008 R2
      • Windows Server 2008
      • Windows 10
      • Windows 8.1
      • Windows 8

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

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

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

      Замените ключ продукта на MAK

      Если вы не можете установить узел KMS или по какой-либо другой причине не можете использовать активацию KMS, измените ключ продукта на MAK. Если вы загрузили образы Windows из Microsoft Developer Network (MSDN) или из TechNet, складские единицы (SKU), перечисленные под носителем, обычно являются носителями с корпоративной лицензией, а предоставленный ключ продукта — это ключ MAK.

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

      1. Откройте окно командной строки с повышенными привилегиями. Для этого нажмите клавишу с логотипом Windows + X, щелкните правой кнопкой мыши командную строку и выберите «Запуск от имени администратора». Если вас попросят ввести пароль администратора или подтвердить, введите пароль или предоставьте подтверждение.
      2. В командной строке выполните следующую команду:

      Заполнитель xxxxx-xxxxx-xxxxx-xxxxx-xxxxx представляет ваш ключ продукта MAK.

      Настройте хост KMS для активации клиентов

      Для активации KMS требуется настроить узел KMS для активации клиентов. Если в вашей среде не настроены узлы KMS, установите и активируйте один из них с помощью соответствующего ключа узла KMS. После настройки компьютера в сети для размещения программного обеспечения KMS опубликуйте параметры системы доменных имен (DNS).

      Сведения о процессе настройки узла KMS см. в разделах Активация с помощью службы управления ключами и Установка и настройка VAMT.

      Проверьте базовое IP-подключение к DNS-серверу

      Проверьте базовое IP-подключение к DNS-серверу с помощью команды ping. Для этого выполните следующие действия как на клиенте KMS, на котором возникла ошибка, так и на главном компьютере KMS:

      1. Откройте окно командной строки с повышенными привилегиями.
      2. В командной строке выполните следующую команду:

      Если в выходных данных этой команды нет фразы "Ответить от", это означает, что возникла проблема с сетью или DNS, которую необходимо устранить, прежде чем использовать другие процедуры, описанные в этой статье. Дополнительные сведения об устранении неполадок с TCP/IP, если вы не можете проверить связь с DNS-сервером, см. в разделе Расширенное устранение неполадок с TCP/IP.

      Проверьте конфигурацию узла KMS

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

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

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

      1. Запустите редактор реестра. Для этого щелкните правой кнопкой мыши "Пуск", выберите "Выполнить", введите regedit и нажмите клавишу ВВОД.
      2. Найдите подраздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform (ранее SL вместо SoftwareProtectionPlatform в Windows Server 2008 и Windows Vista) и проверьте значение записи DisableDnsPublishing. Эта запись имеет следующие возможные значения:
        • 0 или не определено (по умолчанию): хост-сервер KMS регистрирует запись SRV каждые 24 часа.
        • 1: Хост-сервер KMS не регистрирует записи SRV автоматически. Если ваша реализация не поддерживает динамические обновления, см. раздел Создание записи KMS SRV вручную.
      3. Если запись DisableDnsPublishing отсутствует, создайте ее (тип DWORD). Если динамическая регистрация допустима, оставьте значение неопределенным или установите его равным 0.

      Определить тип проблемы маршрутизации

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

      В клиенте KMS откройте окно командной строки с повышенными привилегиями.

      В командной строке выполните следующие команды:

      В этой команде представляет полное доменное имя (FQDN) главного компьютера KMS и

      представляет TCP-порт, который использует KMS.

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

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

      В этой команде представляет IP-адрес главного компьютера KMS и

      представляет TCP-порт, который использует KMS.

      Если эти команды решают проблему, скорее всего, проблема связана с разрешением имени. Дополнительные сведения об устранении неполадок см. в процедуре проверки конфигурации DNS.

      Если ни одна из этих команд не решает проблему, проверьте конфигурацию брандмауэра компьютера. Любая активация, которая происходит между клиентами KMS и узлом KMS, использует TCP-порт 1688. Брандмауэры как на клиенте KMS, так и на узле KMS должны разрешать обмен данными через порт 1688.

      Проверьте конфигурацию DNS

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

      1. Открыть окно командной строки с повышенными правами
      2. В командной строке выполните следующую команду:
      3. В результатах команды обратите внимание на следующую информацию:
        • Назначенный IP-адрес клиентского компьютера KMS
        • IP-адрес основного DNS-сервера, который использует клиентский компьютер KMS.
        • IP-адрес шлюза по умолчанию, который использует клиентский компьютер KMS.
        • Список поиска DNS-суффиксов, используемый клиентским компьютером KMS
      4. Убедитесь, что записи SRV узла KMS зарегистрированы в DNS. Для этого выполните следующие действия:
        1. Откройте окно командной строки с повышенными привилегиями.
        2. В командной строке выполните следующую команду:
        3. Откройте файл KMS.txt, созданный командой. Этот файл должен содержать одну или несколько записей, похожих на следующую запись:
        1. Проверьте IP-адрес, имя узла, порт и домен узла KMS.
        2. Если эти записи _vlmcs существуют и содержат ожидаемые имена узлов KMS, перейдите к разделу Назначение узла KMS клиенту KMS вручную.

        Если команда nslookup находит узел KMS, это не означает, что клиент DNS может найти узел KMS. Если команда nslookup находит узел KMS, но вы по-прежнему не можете выполнить активацию с помощью узла KMS, проверьте другие параметры DNS, например основной суффикс DNS и список поиска суффикса DNS.

        Вручную создать запись KMS SRV

        Чтобы вручную создать запись SRV для узла KMS, использующего DNS-сервер Microsoft, выполните следующие действия:

        1. На DNS-сервере откройте диспетчер DNS. Чтобы открыть Диспетчер DNS, нажмите "Пуск", выберите "Администрирование", а затем выберите "DNS".
        2. Выберите DNS-сервер, на котором необходимо создать запись ресурса SRV.
        3. В дереве консоли разверните Зоны прямого просмотра, щелкните домен правой кнопкой мыши и выберите Другие новые записи.
        4. Прокрутите список вниз, выберите Расположение службы (SRV), а затем выберите Создать запись.
        5. Введите следующую информацию:
          • Сервис: _VLMCS
          • Протокол: _TCP
          • Номер порта: 1688
          • Хозяин, предлагающий услугу:
        6. Когда закончите, нажмите "ОК", а затем выберите "Готово".

        Чтобы вручную создать запись SRV для узла KMS, использующего DNS-сервер, совместимый с BIND 9.x, следуйте инструкциям для этого DNS-сервера и укажите следующую информацию для записи SRV:

        KMS не использует значения приоритета или веса. Однако запись должна их включать.

        Чтобы настроить DNS-сервер, совместимый с BIND 9.x, для поддержки автоматической публикации KMS, настройте DNS-сервер, чтобы разрешить обновление записей ресурсов с узлов KMS. Например, добавьте следующую строку в определение зоны в Named.conf или Named.conf.local:

        Вручную назначить хост KMS клиенту KMS

        По умолчанию клиенты KMS используют процесс автоматического обнаружения. В соответствии с этим процессом клиент KMS запрашивает у DNS список серверов, которые опубликовали записи _vlmcs SRV в зоне членства клиента. DNS возвращает список узлов KMS в случайном порядке. Клиент выбирает узел KMS и пытается установить на нем сеанс. Если эта попытка сработает, клиент кэширует имя узла KMS и пытается использовать его для следующей попытки обновления. Если установка сеанса не удалась, клиент случайным образом выбирает другой узел KMS. Мы настоятельно рекомендуем вам использовать процесс автоматического обнаружения.

        Однако вы можете вручную назначить хост KMS конкретному клиенту KMS. Для этого выполните следующие действия.

        1. В клиенте KMS откройте окно командной строки с повышенными привилегиями.
        2. В зависимости от реализации выполните одно из следующих действий:
        3. Чтобы назначить узел KMS с помощью полного доменного имени узла, выполните следующую команду:
        4. Чтобы назначить узел KMS с помощью IP-адреса узла версии 4, выполните следующую команду:
        5. Чтобы назначить узел KMS с помощью IP-адреса узла версии 6, выполните следующую команду:
        6. Чтобы назначить узел KMS с помощью NETBIOS-имени узла, выполните следующую команду:
        7. Чтобы вернуться к автоматическому обнаружению на клиенте KMS, выполните следующую команду:

        Эти команды используют следующие заполнители:

        • представляет собой полное доменное имя (FQDN) главного компьютера KMS
        • представляет собой IP-адрес версии 4 главного компьютера KMS
        • представляет собой IP-адрес версии 6 главного компьютера KMS
        • представляет собой NETBIOS-имя главного компьютера KMS

        Настройте узел KMS для публикации в нескольких доменах DNS

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

        Как описано в разделе Назначение узла KMS клиенту KMS вручную, клиенты KMS обычно используют процесс автоматического обнаружения для идентификации узлов KMS. Этот процесс требует, чтобы записи _vlmcs SRV были доступны в зоне DNS клиентского компьютера KMS. Зона DNS соответствует либо основному DNS-суффиксу компьютера, либо одному из следующих:

        • Для компьютеров, присоединенных к домену, домен компьютера назначается системой DNS (например, доменными службами Active Directory (AD DS) DNS).
        • Для компьютеров рабочей группы домен компьютера назначается протоколом динамической конфигурации хоста (DHCP). Это доменное имя определяется параметром, который имеет кодовое значение 15, как определено в запросе комментариев (RFC) 2132.

        Если узел KMS и клиенты KMS используют разные зоны DNS, необходимо настроить узел KMS для автоматической публикации своих записей SRV в нескольких доменах DNS. Для этого выполните следующие действия:

        1. На узле KMS запустите редактор реестра.
        2. Найдите и выберите подраздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform (ранее SL вместо SoftwareProtectionPlatform в Windows Server 2008 и Windows Vista).
        3. На панели сведений щелкните правой кнопкой мыши пустую область, выберите "Создать", а затем выберите "Многострочное значение".
        4. В качестве имени новой записи введите DnsDomainPublishList.
        5. Щелкните правой кнопкой мыши новую запись DnsDomainPublishList и выберите Изменить.
        6. В диалоговом окне "Редактировать многострочный" введите каждый суффикс домена DNS, публикуемый KMS, в отдельной строке, а затем нажмите кнопку "ОК".

        Для Windows Server 2008 R2 формат DnsDomainPublishList отличается. Дополнительные сведения см. в Техническом справочном руководстве по многопользовательской активации.

        Читайте также: