Запись srv автообнаружения не найдена в службе dns
Разберем процесс создания инфраструктуры для автоматической настройки почтовых клиентов. Для корректной работы Autodiscover нужен комплексный подход, так как у разных почтовых клиентов свои требования.
3. DNS SRV
Это метод, призванный быть универсальным. Более того, он описан стандартом RFC.
Суть заключается в создании SRV-записей в DNS. Данная запись создается по следующему синтаксису:
- — имя сервиса (например, imap).
- — сетевой протокол (TCP, UDP, TLS).
- — порядок, в котором идет учет строки.
- — если приоритеты совпадают у служб, порядок определяется по их весу.
- — порт, на котором слушает служба.
- — имя сервера, на который будет вести запись.
Пример записей для настройки почты:
* в данном примере мы отдаем приоритет более защищенным средствам подключения (smtps, imaps, pop3s).
Пример записей в DNS Bind:
В этой статье описывается проверка записей ресурсов локатора расположения службы (SRV) для контроллера домена после установки службы каталогов Active Directory.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 816587
2. Mozilla Thunderbird
Также, как с Outlook, необходимо настроить DNS и веб-сервер.
создаем А-запись (или CNAME). Пример в bind:
autoconfig IN A 111.111.111.111
* где 111.111.111.111 — IP-адрес на наш веб-сервер, который будет возвращать документ XML.
Создание записи SRV KMS вручную
Чтобы вручную создать запись SRV для узла KMS, использующего DNS-сервер Майкрософт, сделайте следующее:
- Откройте на DNS-сервере диспетчер DNS. Чтобы открыть диспетчер DNS, щелкните Пуск, Администрирование и Служба DNS.
- Выберите DNS-сервер, на котором необходимо создать запись ресурса SRV.
- В дереве консоли разверните узел Зоны прямого просмотра, щелкните правой кнопкой мыши домен и выберите Другие новые записи.
- Прокрутите список вниз, выберите Расположение службы (запись SRV) и щелкните Создать запись.
- Введите следующие сведения:
- служба — _VLMCS;
- протокол — _TCP;
- номер порта — 1688;
- узел, на котором размещена служба — FQDN узла KMS .
- По окончании щелкните ОК и Готово.
Чтобы вручную создать запись SRV для узла KMS, использующего совместимый с BIND 9.x DNS-сервер, следуйте инструкциям по настройке этого DNS-сервера и предоставьте следующие сведения для записи SRV:
KMS не использует значения приоритета или веса. Но запись должна содержать их.
Чтобы включить для совместимого с BIND 9.x DNS-сервера поддержку автоматической публикации KMS, включите для него обновление записей ресурсов с узлов KMS. Например, добавьте следующую строку в определение зоны в файле Named.conf или Named.conf.local:
Веб-сервер
В качестве примера, настройку выполним на веб-сервере NGINX, который работает на Linux. Если он не установлен, выполняем инсталляцию.
а) если сервер под CentOS / Red Hat:
yum install epel-release
yum install nginx
б) если сервер под Debian / Ubuntu:
apt-get install nginx
После разрешаем автозапуск и стартуем сервис:
systemctl enable nginx
systemctl start nginx
Затем создаем виртуальный домен:
error_page 405 =200 $uri;
>
Проверяем корректность настройки:
Если ошибок нет, перечитываем конфиг:
systemctl reload nginx
Создаем каталог, в котором будет наш XML:
mkdir -p /usr/share/nginx/html/autodiscover/autodiscover
Создадим сам XML:
* где из основных параметров на нужны:
- Type — тип протокола, используя который мы будем подключаться к почтовой системе.
- Server — сервер для подключения. Для каждого типа протокола может быть задан свой сервер или один и тот же.
- Port — порт, на котором слушает сервис. Как правило, для
- IMAP: 143, 993.
- POP: 110, 995.
- SMTP: 25, 465, 587.
Определение типа проблемы с маршрутизацией
Вы можете определить, связана ли проблема с разрешением имен или записью SRV, с помощью следующих команд.
На клиенте KMS откройте окно командной строки с повышенными правами.
В командной строке введите следующие команды:
В этой команде представляет полное доменное имя (FQDN) главного компьютера KMS, а представляет TCP-порт, используемый KMS.
Если эти команды помогли устранить проблему, значит проблема была в записи SRV. Вы можете устранить ее с помощью одной из команд, описанных в инструкциях по назначению узла KMS клиенту KMS вручную.
Если проблема не устранена, выполните следующие команды:
В этой команде представляет IP-адрес главного компьютера KMS, а представляет TCP-порт, используемый KMS.
Если эти команды помогли устранить проблему, это указывает на возможную проблему с разрешением имен. Дополнительные сведения об устранении неполадок см. в инструкциях по проверке конфигурации DNS.
Если ни одна из этих команд не устраняет проблему, проверьте конфигурацию брандмауэра компьютера. Любой обмен данными для активации между клиентами KMS и узлом KMS, происходит с использованием TCP-порта 1688. Брандмауэры должны разрешать обмен данными через порт 1688 как на клиенте KMS, так и на узле KMS.
Метод 1. Использование диспетчера DNS
После установки Active Directory на сервере, на который работает служба DNS, можно использовать консоль управления DNS для проверки создания соответствующих зон и записей ресурсов для каждой зоны DNS.
Active Directory создает свои записи SRV в следующих папках, где находится имя домена:
- Forward Lookup Zones/Domain_Name/_msdcs/dc/_sites/Default-First-Site-Name/_tcp
- Forward Lookup Zones/Domain_Name/_msdcs/dc/_tcp
В этих расположениях должна отображаться запись SRV для следующих служб:
1. Microsoft Outlook
С DNS все просто — создаем А- (или CNAME-) и SRV-записи. Пример таких записей в bind:
autodiscover IN A 111.111.111.111
* где 111.111.111.111 — IP-адрес на наш веб-сервер, который будет возвращать документ XML.
Метод 3. Использование Nslookup
Nslookup это средство командной строки, отображает сведения, которые можно использовать для диагностики инфраструктуры системы доменных имен (DNS).
Чтобы проверить Nslookup записи SRV, выполните следующие действия:
- В DNS выберите > запуск.
- В поле Открыть введите cmd .
- Введите nslookup и нажмите кнопку ENTER.
- Введите set type=all и нажмите кнопку ENTER.
- Введите имя домена и нажмите _ldap._tcp.dc._msdcs.Domain_Name кнопку ENTER.
Nslookup возвращает одну или несколько записей расположения службы SRV, которые отображаются в следующем формате, где находится имя хозяина контроллера домена, и где домен, к котором принадлежит контроллер домена, и является адресом internet Protocol (IP) контроллера домена:
Вы можете попробовать выполнить некоторые из этих инструкций, если выполняется одно или несколько из следующих условий.
- Для установки одной из следующих операционных систем используется корпоративный носитель и универсальный ключ многократной установки:
- 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, выполните следующие инструкции по устранению неполадок с конфигурациями маршрутизации. Процедуры перечислены по возрастанию сложности:
-
; ; ; ; ; ; .
Веб-сервер
Настраивая autodiscovery для Microsoft, мы уже настроили веб-сервер NGINX. Теперь нужно добавить виртуальный домен и создать соответствующий документ.
Откроем уже созданный нами файл конфигурации:
. и добавим в него:
Создаем каталог для хранения XML:
mkdir -p /usr/share/nginx/html/autodiscover/mail
- hostname — имя сервера для подключения. Для каждого типа протокола может быть задан свой сервер или один и тот же.
- port — порт, на котором слушает сервис. Как правило, для
- IMAP: 143, 993.
- POP: 110, 995.
- SMTP: 25, 465, 587.
- plain — без шифрования.
- SSL — SSL или TLS шифрование на отдельном порту (465, 993, 995).
- STARTTLS — TLS шифрование через STARTTLS на обычном порту.
Проверка конфигурации узла KMS
Проверьте реестр сервера узла службы KMS, чтобы определить, выполняется ли его регистрация в DNS. По умолчанию сервер узла службы KMS динамически регистрирует запись SRV DNS каждые 24 часа.
Внимательно выполните действия, описанные в этом разделе. Неправильное изменение реестра может привести к серьезным проблемам. Перед внесением изменений создайте резервную копию реестра для его восстановления в случае возникновения проблем.
Для проверки сделайте следующее:
- Откройте редактор реестра. Для этого щелкните правой кнопкой мыши Пуск, выберите Выполнить, введите regedit и нажмите клавишу ВВОД.
- Найдите подраздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform (ранее вместо SoftwareProtectionPlatform в Windows Server 2008 и Windows Vista было указано SL) и просмотрите значение записи DisableDnsPublishing. Эта запись может иметь следующие значения:
- 0 или не определено (по умолчанию). Сервер узла KMS регистрирует запись SRV каждые 24 часа.
- 1. Сервер узла KMS не регистрирует записи SRV автоматически. Если ваша реализация не поддерживает динамические обновления, см. руководство по созданию записи SRV KMS вручную.
- Если запись DisableDnsPublishing отсутствует, создайте ее (тип — DWORD). Если динамическая регистрация допускается, оставьте неопределенное значение или укажите 0.
Проверка основного IP-подключения к DNS-серверу
Проверьте основное IP-подключение к DNS-серверу с помощью команды ping. Для этого выполните следующие действия как на клиенте KMS, на котором возникла ошибка, так и на узле KMS:
- Откройте окно командной строки с повышенными правами.
- В командной строке выполните следующую команду:
Если выходные данные этой команды не содержат фразу Reply from, это указывает на проблему с сетью или DNS, которую необходимо устранить, прежде чем можно будет переходить к другим инструкциям, описанным в этой статье. Узнайте больше об устранении неполадок TCP/IP при сбое проверки связи с DNS-сервером в расширенном руководстве по устранению неполадок с TCP/IP.
Настройка узла KMS для публикации в нескольких доменах DNS
Внимательно выполните действия, описанные в этом разделе. Неправильное изменение реестра может привести к серьезным проблемам. Перед внесением изменений создайте резервную копию реестра для его восстановления в случае возникновения проблем.
Как описано в инструкциях по назначению узла KMS клиенту KMS вручную, клиенты KMS обычно используют процесс автоматического обнаружения для обнаружения узлов KMS. Для этого необходимо, чтобы записи SRV _vlmcs были доступными в зоне DNS клиентского компьютера KMS. Зона DNS соответствует либо основному DNS-суффиксу компьютера, либо одному из следующих компонентов:
- для компьютеров, присоединенных к домену, — домену компьютера, назначенному системой DNS (например, DNS AD DS);
- для компьютеров, входящих в рабочую группу — домену компьютера, назначенному протоколом DHCP. Это доменное имя определяется параметром с кодом, имеющим значение 15, как определено в RFC 2132.
Если узел и клиенты KMS используют разные зоны DNS, вам нужно включить для узла KMS автоматическую публикацию записей SRV в нескольких доменах DNS. Для этого выполните следующие действия:
- На узле KMS откройте редактор реестра.
- Найдите и выберите подраздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform (ранее вместо SoftwareProtectionPlatform в Windows Server 2008 и Windows Vista было указано SL).
- В разделе Сведения щелкните правой кнопкой мыши пустую область, а затем выберите Создать и Мультистроковый параметр.
- В качестве имени новой записи введите DnsDomainPublishList.
- Щелкните правой кнопкой мыши новую запись DnsDomainPublishList и выберите Изменить.
- В диалоговом окне Редактирование мультистроки введите в отдельную строку каждый суффикс домена DNS, который KMS публикует, и щелкните ОК.
В Windows Server 2008 R2 формат для DnsDomainPublishList отличается. Сведения см. в техническом справочнике по активации корпоративных лицензий.
З апустил test-OutlookwebServices
похоже что-то сертификат не дает работать.
Так же может, если это сертификат, сейчас на сервере купленный сертификат в состоянии "не удалось проверить списки отзыва". Но при обращении по OWA видно что сертификат работает , есть даже зеленая строчка в адресной строке (у меня EV сертификат)
Не понятно, почему сертификат не действительный, если по остальным виртуальным каталогам все работает. По OWA и по ECP на сертификат не ругается.
Коллеги нужна Ваша помощь в данной ситуации
Connectivity analyzer бы сказал что-то.
Возможно intermediate certificate для корневого сервера не установлен или не в том разделе.
scientia potentia est
My blogConnectivity analyzer пока не могу запустить т.к. exchange еще не опубликован. сейчас подготавливаю и тестирую настройки для доменных пользователей но с внешними dns (как будут резолвиться и т.д.)
по поводу промежуточного сертификата, не исключено. но вроде бы я его поставил как обычно.
от издателя сертификатов получил два файла "company.crt" и "company.ca-bundle"
первый я установил в IIS а второй я установил в "промежуточные центры сертификации"
пока я не установил промежуточный сертификат зеленая строка в браузере не появлялась. и в ECP сертификат был в статусе не довереный. а сейчас в статусе не удалось проверить отзыв.
Что попробовать сделать? переустановить корневые и промежуточные сертификаты на почтовых серверах?
scientia potentia est
My blogВ от результаты Connectivity analyzer (сканировал из локалки)
Мне непонятны следующие вещи:
1. Как у вас сертификат горит зеленым, вроде бы wildcard зелеными не бывают.
=*. hc . ru , OU = PremiumSSL Wildcard , OU = IT , O = JSC Hosting - Center , STREET = "Khoroshevskoe 3-I, 2.1" , L = Moscow , S = Moscow , PostalCode = 123308 , C = RU , издатель: CN = RU - CENTER High Assurance Services CA 2 , O = RU - Center (ЗАО Региональный Сетевой Информационный Центр), L = Moscow , S = Moscow , C = RU .
Microsoft Connectivity Analyzer пытается получить SSL -сертификат от удаленного сервера autodiscover . company . ru через порт 443.
Анализатору Microsoft Connectivity Analyzer удалось получить удаленный SSL -сертификат.
Сведения: Субъект удаленного сертификата: CN = mail . company . ru , OU = IT , O = MY COMPANY , L = MOSCOW , S = MOSCOW , C = RU , SERIALNUMBER = 1111111111111111111 , OID . 2.5 . 4.15 = Private Organization , OID . 1.3 . 6.1 . 4.1 . 311.60 . 2.1 . 3 = RU , издатель: CN = thawte Extended Validation SHA256 SSL CA , O = "thawte, Inc." , C = US .Затраченное время (миллисекунды): 7
Проверка имени сертификата.
Не удалось проверить имя сертификата.
Подробные сведения об этой проблеме и способах ее устранения
Сведения
Сведения: Имя узла autodiscover . company . ru не совпадает ни с одним именем, найденным в сертификате сервера CN = mail . company . ru , OU = IT , O = MY COMPANY , L = MOSCOW , S = MOSCOW , C = RU , SERIALNUMBER = 1067746239230 , OID . 2.5 . 4.15 = Private Organization , OID . 1.3 . 6.1 . 4.1 . 311.60 . 2.1 . 3 = RU .Как так может быть? Вы какой сертификат к IIS привязали?
Мне непонятны следующие вещи:
1. Как у вас сертификат горит зеленым, вроде бы wildcard зелеными не бывают.
=*. hc . ru , OU = PremiumSSL Wildcard , OU = IT , O = JSC Hosting - Center , STREET = "Khoroshevskoe 3-I, 2.1" , L = Moscow , S = Moscow , PostalCode = 123308 , C = RU , издатель: CN = RU - CENTER High Assurance Services CA 2 , O = RU - Center (ЗАО Региональный Сетевой Информационный Центр), L = Moscow , S = Moscow , C = RU .
Microsoft Connectivity Analyzer пытается получить SSL -сертификат от удаленного сервера autodiscover . company . ru через порт 443.
Анализатору Microsoft Connectivity Analyzer удалось получить удаленный SSL -сертификат.
Сведения: Субъект удаленного сертификата: CN = mail . company . ru , OU = IT , O = MY COMPANY , L = MOSCOW , S = MOSCOW , C = RU , SERIALNUMBER = 1111111111111111111 , OID . 2.5 . 4.15 = Private Organization , OID . 1.3 . 6.1 . 4.1 . 311.60 . 2.1 . 3 = RU , издатель: CN = thawte Extended Validation SHA256 SSL CA , O = "thawte, Inc." , C = US .Затраченное время (миллисекунды): 7
Проверка имени сертификата.
Не удалось проверить имя сертификата.
Подробные сведения об этой проблеме и способах ее устранения
Сведения
Сведения: Имя узла autodiscover . company . ru не совпадает ни с одним именем, найденным в сертификате сервера CN = mail . company . ru , OU = IT , O = MY COMPANY , L = MOSCOW , S = MOSCOW , C = RU , SERIALNUMBER = 1067746239230 , OID . 2.5 . 4.15 = Private Organization , OID . 1.3 . 6.1 . 4.1 . 311.60 . 2.1 . 3 = RU .по поводу первого пункта это данные сертификата на корпоративном сайте.
по поводу второго пункта это данные сертификата который я купил
Ранее я подробно расписывал один из способов настройки службы автообнаружения. В ситуации с несколькими smtp-доменами, которые активно используются сотрудниками компании ситуация несколько усложняется. При подключении клиент Outlook делает несколько проверок способов доступности сервера автообнаружения, и тот способ, который вернёт успешную проверку будет использоваться клиентом Outlook в течение сессии. Порядок проверки следующий:
Что из этого следует в случае наличия нескольких smtp-доменов?
2. Сертификат, установленный на наших CAS-серверах в поле Subject Alternative Names по идее должен (но не обязан!) содержать записи autodiscover для всех наших smtp-доменов + имена всех наших CAS серверов. С одной стороны самый простой способ (достаточно в SAN внести данные для всех доменов), с другой стороны самый немасштабируемый способ (в случае появления нового smtp-домена, который должен обслуживаться службой автообнаружения надо будет перевыпускать сертификат, что в случае с сертификатом, выданным внешним центром сертификации, может вызвать некоторые неудобства).
Затем из оснастки IIS Manager указываем явно для дефолтного сайта ip-адрес, который в dns закреплён за CAS сервером (по умолчанию, дефолтный сайт привязывается ко всем ip-адресам, которые прописаны на серверных сетевых картах).
Затем из оснастки IIS Manager на этом CAS сервере создаём новый сайт autodiscover_redirect:
Затем в новом сайте создаём папку autodiscover и в ней пустой файл autodiscover.xml, в свойствах которого указываем в качестве адреса перенаправления основной сервер службы автообнаружения:
Все адреса
Наш файл конфигурации рассчитан только на настройку одного адреса. Теперь нужно настроить его на обслуживание любого email. Для этого необходимо написать скрипт, например, на php и немного донастроить сервер.
PHP и php-fpm
Установим php и php-fpm, после разрешаем автозапуск php-fpm и стартуем его:
а) если сервер под CentOS / Red Hat:
yum install php php-fpm
systemctl enable php-fpm
systemctl start php-fpm
б) если сервер под Debian / Ubuntu:
apt-get install php php-fpm
systemctl enable php7.2-fpm
systemctl start php7.2-fpm
* где 7.2 — версия установленной php (проверяется командой php -v).
Настроим php-fpm
а) если сервер под CentOS / Red Hat:
systemctl restart php-fpm
б) если сервер под Debian / Ubuntu:
systemctl restart php7.2-fpm
NGINX
Внесем настройки в наш виртуальный домен:
.
error_page 405 =200 $uri;location ~ \.php$ set $root_path /usr/share/nginx/html/autodiscover;
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
>
.* мы добавили обработку скриптов php с помощью php-fpm.
Перезапускаем наш сервер:
systemctl reload nginx
Готовим скрипт
Создадим скрипт php:
//get raw POST data so we can extract the email address
$data = file_get_contents("php://input");
preg_match("/\(.*?)\/", $data, $matches);Переадресация с xml на php
Теперь настроим, чтобы наш веб-сервер переводил запросы xml на наш скрипт php. Открываем настройку нашего виртуального домена:
.
location = /autodiscover/autodiscover.xml rewrite ^/autodiscover/autodiscover.xml$ /autodiscover/autodiscover.php;
>
.systemctl reload nginx
Теперь можно открывать Outlook и проверять автонастройку для других почтовых ящиков.
Изменение ключа продукта на MAK
Если по какой-то причине вам не удается установить узел KMS или использовать активацию KMS, попробуйте изменить ключ продукта на MAK. Если вы скачали образы Windows с сайта Microsoft Developer Network (MSDN) или TechNet, номера SKU, перечисленные под носителем, обычно связаны с корпоративными лицензиями на носители, а предоставленный ключ продукта является ключом MAK.
Чтобы изменить ключ продукта на MAK, сделайте следующее:
- Откройте окно командной строки с повышенными правами. Для этого нажмите клавиши Windows+X, щелкните правой кнопкой мыши элемент Командная строка и выберите Запуск от имени администратора. При появлении запроса на ввод или подтверждение пароля администратора введите пароль или подтвердите его.
- В командной строке выполните следующую команду:
Заполнитель xxxxx-xxxxx-xxxxx-xxxxx-xxxxx представляет ключ продукта MAK.
Сводка
Запись SRV — это запись ресурсов системы доменных имен (DNS). Он используется для идентификации компьютеров, на которые размещены определенные службы. Записи ресурсов SRV используются для поиска контроллеров домена для Active Directory. Чтобы проверить записи ресурсов локатора SRV для контроллера домена, используйте один из следующих методов.
Проверка конфигурации DNS
Если не указано иное, выполните следующие действия на клиенте KMS, где возникла соответствующая ошибка.
- Проверьте IP-адрес, имя узла, порт и домен узла KMS.
- Если эти записи _vlmcs существуют и содержат ожидаемые имена узла KMS, перейдите к инструкциям по назначению узла KMS клиенту KMS вручную.
Если команда nslookup находит узел KMS, это не значит, что клиент DNS может найти узел KMS. Если команда nslookup находит узел KMS, но активация с помощью узла KMS по-прежнему не удается, проверьте другие параметры DNS, включая основной суффикс DNS и список суффиксов DNS.
Назначение узла KMS клиенту KMS вручную
По умолчанию клиенты KMS используют процесс автоматического обнаружения. При этом клиент KMS запрашивает у DNS список серверов, которые опубликовали записи SRV _vlmcs в зоне членства клиента. DNS возвращает список узлов KMS в случайном порядке. Клиент выбирает узел KMS и пытается открыть на нем сеанс. Если попытка удается, клиент кэширует имя узла KMS и попытается использовать его для следующей попытки продления. В случае сбоя клиент случайным образом выбирает другой узел KMS. Мы настоятельно рекомендуем использовать процесс автоматического обнаружения.
Но вы также можете назначить узел KMS определенному клиенту KMS. Для этого выполните следующие действия.
- На клиенте KMS откройте окно командной строки с повышенными правами.
- В зависимости от реализации выполните одно из следующих действий:
- Чтобы назначить узел KMS с помощью FQDN, выполните следующую команду:
- Чтобы назначить узел KMS с помощью IPv4, выполните следующую команду:
- Чтобы назначить узел KMS с помощью IPv6, выполните следующую команду:
- Чтобы назначить узел KMS с помощью NetBIOS, выполните следующую команду:
- Чтобы вернуться к автоматическому обнаружению на клиенте KMS, выполните следующую команду:
В этих командах используются следующие заполнители:
- KMS_FQDN>> — полное доменное имя (FQDN) главного компьютера KMS;
- >IPv4Address — IP-адрес версии 4 главного компьютера KMS;
- >IPv6Address — IP-адрес версии 6 главного компьютера KMS;
- >NETBIOSName — имя NetBIOS главного компьютера KMS;
- port> — TCP-порт, используемый KMS.
Метод 2. Просмотр Netlogon.dns
Если для поддержки Active Directory вы используете не microsoft DNS-серверы, можно проверить записи ресурсов локатора SRV, просмотрев Netlogon.dns. Netlogon.dns расположен в %systemroot%\System32\Config папке. Для просмотра этого файла можно использовать текстовый редактор, например Блокнот.
Первая запись в файле — запись SRV-протокола доступа к легкому каталогу контроллера домена (LDAP). Эта запись должна выглядеть так же, как и следующая:
Настройка узла KMS для активации клиентов
Для активации клиентов KMS нужно настроить узел KMS. Если в вашей среде нет узлов KMS, установите и активируйте их с помощью соответствующего ключа узла KMS. Настроив компьютер в сети для размещения программного обеспечения KMS, опубликуйте параметры DNS.
Читайте также: