DNS-сервер не может открыть зону msdcs

Обновлено: 21.11.2024

Эти страницы посвящены настройке DNS для использования с Active Directory в UDN. Предполагается, что вы уже знакомы с DNS/Active Directory. Информация здесь относится ко всем текущим версиям Windows Server.

Создание необходимых зон

Для правильной работы Active Directory в DNS должны существовать определенные записи о расположении службы (SRV). Наш текущий совет по настройке — создать единую основную зону для вашего домена. Если вы меняете свой DNS для использования одной первичной зоны из предыдущей конфигурации зон подчеркивания и зон разделов каталога, нет причин изменять существующее доменное имя или структуру. Если вы создаете новый домен или планируете перейти на новый домен, мы рекомендуем использовать имя в форме

Рекламная часть не является обязательной, но дает понять, что это Active Directory в вашем учреждении.

Вам следует избегать использования .local в качестве имени, которое, к сожалению, до сих пор часто рекомендуется в некоторой документации Microsoft. Причина этого в том, что local может вызвать конфликты с UPNP, Bonjour и Multicast DNS.

Решение для основной зоны

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

Использование серверов пересылки для рекурсивных серверов имен

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

  • Щелкните правой кнопкой мыши объект сервера в DNS MMC и отобразите свойства.
  • На вкладке серверов пересылки добавьте рекурсивные серверы имен.

Зоны обратного просмотра

Вы должны убедиться, что ваши хосты доступны через обратный поиск. Чтобы убедиться, что это произойдет, у вас есть 3 варианта;

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

3) Установить серверы пересылки.

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

Действительные DNS-имена

Действительные символы DNS-имени

Следующие символы могут использоваться для создания DNS-имени.

Не допускается использование символов подчеркивания или других символов.

Имена NetBIOS

Имя NetBIOS системы по умолчанию будет именем хоста DNS. Так и должно быть в большинстве случаев.

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

Несмотря на то, что перечисленные ниже символы допустимы в именах NetBIOS, их не следует использовать, поскольку они не разрешены в именах DNS;

Они должны быть удалены из ваших схем именования.

Известные проблемы, подсказки и подсказки

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

В ряде случаев мы замечали проблемы, когда _msdcs создавалась за пределами вашей основной зоны в качестве основной, а выделенная серым цветом (делегированная) зона _msdcs создавалась внутри вашей основной доменной зоны. Просто удалите обе зоны _msdcs и перезапустите вход в сеть на своих контроллерах домена, чтобы перерегистрировать записи SRV.

Server 2008 и более поздние версии изменяют настройки IP-адреса вашего сервера, чтобы автоматически использовать локальный хост (127.0.0.1) в качестве основного DNS-сервера при первой установке нового домена и DNS. С одним DNS-сервером это нормально, но вам следует избегать использования этой конфигурации с несколькими DNS-серверами, особенно с интегрированными зонами Active Directory. Всегда меняйте DNS-серверы на IP-адрес ваших DNS-серверов. Вам также следует указать своим контроллерам домена использовать DNS другого контроллера домена в качестве основного, чтобы обеспечить доступность DNS при перезапуске системы.

У вас должны быть зоны обратного просмотра для вашего домена. Вы можете создать их как первичные для диапазонов IP-адресов, которые вы используете. В большинстве случаев создавайте зону обратного просмотра для первых трех блоков IP в вашем адресе IPv4, например. если вы используете 172.28.15.x, вам потребуется обратная зона 15.28.172.in-addr.arpa.

Для целей разрешения имен нет различий между версиями R2 и другими версиями сервера Windows. Вы можете использовать обе версии и смешивать их в своем домене.

Дополнительная информация и устранение неполадок

Несколько проблем с подсетями

Некоторое старое программное обеспечение и службы Microsoft и сторонних производителей по-прежнему требуют наличия NetBIOS. Это может быть проблемой для разрешения имен в сетях, использующих более одной IP-подсети, где контроллер домена доступен не во всех подсетях. Простое решение — запустить контроллер домена во всех ваших подсетях с глобальным каталогом или WINS-сервером в вашей сети.

Интегрированный DNS Active Directory

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

Настройки DNS клиента и сервера

Ваши клиенты и серверы должны использовать только ваши DNS-серверы, у вас их должно быть как минимум 2. Вам не нужно использовать центральные DNS-серверы в настройках IP-адреса любого из ваших клиентов.

Проблемы с разрешением имен

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

В настройках TCP/IP клиента выберите Дополнительные свойства, а затем вкладку DNS.

Выберите вариант Добавить эти суффиксы DNS (по порядку): и введите;

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

Перенос зон

Если вы включите Zone Transfers по умолчанию, они будут включены для любого сервера, который их запрашивает. Хотя это вряд ли будет проблемой, вы можете ограничить передачу зон только вашими собственными серверами имен. Для этого выберите Свойства зоны, а затем перейдите на вкладку Zone Transfers. Здесь вы можете указать либо только серверы, перечисленные на вкладке Серверы имен, либо список серверов.

Второй DNS-сервер

Для отказоустойчивости рекомендуется иметь в сети второй DNS-сервер. Для предпочтения используйте Active Directory Integrated. Если вы не интегрируете AD, вам необходимо настроить второй DNS для подчинения ваших зон первому серверу, у которого есть DNS. Подчините зоны с этого первого сервера как ВТОРИЧНЫЕ зоны.

Недавно у нас был "Понедельник исправлений" – это необычно, поскольку обычно мы устанавливаем исправления по пятницам (на случай, если что-то пойдет не так, у нас впереди выходные). воспользовался возможностью исправить.

К сожалению, что-то пошло не так. Сначала после перезагрузки одного из серверов Exchange я получил следующую ошибку:

Exchange ECP / Сервер LDAP недоступен

"Поставщик топологии не смог найти Microsoft Exchange Active Directory"

В журналах было зарегистрировано событие с идентификатором 2142 MSExchangeADTopology с ошибкой "Ошибка обнаружения топологии"

Сначала я подумал, что это плохое исправление, но вскоре после этого все еще не исправленный Exchange
сообщил об ошибках.

Ошибки явно указывают на AD. Я посмотрел на контроллер домена, т.к. он тоже был обновлен. Сразу после входа в DC меня встретил неприятный сюрприз.

После открытия консоли DNS появилось сообщение «Отказано в доступе».

DNS был недоступен.

В DC были зарегистрированы следующие события:

Идентификатор события Microsoft-Windows-DNS-Server-Service 4000

Описание для идентификатора события ( 4000 ) в источнике ( Microsoft-Windows-DNS-Server-Service ) не найдено. Либо компонент, вызывающий это событие, не установлен на вашем локальном компьютере, либо установка повреждена. Вы можете установить или восстановить компонент на локальном компьютере или обратиться к производителю компонента за более новой версией.

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

Microsoft-Windows- Идентификатор события службы DNS-сервера: 4007

Описание для идентификатора события ( 4007 ) в источнике ( Microsoft-Windows-DNS-Server-Service ) не найдено. Либо компонент, вызывающий это событие, не установлен на вашем локальном компьютере, либо установка повреждена.Вы можете установить или восстановить компонент на локальном компьютере или обратиться к производителю компонента за более новой версией.

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

Это происходит, когда конкретный сервер DC/DNS теряет безопасный канал с самим собой или основным контроллером домена.
Это также может произойти в среде с одним контроллером домена, где этот DC/DNS-сервер содержит все роли FSMO и указывает на себя как на основной DNS-сервер.

Я до сих пор не знаю, почему это произошло в моем случае, но вот шаги, которые помогли мне решить эту проблему

Остановите службу KDC (центр распространения ключей Kerberos) в сервисной консоли на контроллере домена, которая не работает.


Запустите командную строку с повышенными привилегиями (от имени администратора) и введите следующую команду

(замените dc.domain.local на полное доменное имя вашего контроллера домена, а DOMAIN\domain_admin на ваш домен и учетную запись администратора)


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

По непонятной причине моя домашняя тестовая лаборатория сегодня вышла из строя! Не совсем удивительно. DC там не всегда включены/подключены; и я продолжаю переводить всю лабораторию в спящий режим, поскольку она работает с моего ноутбука, поэтому за кулисами обязательно могут скрываться ошибки.

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

  • Идентификатор события 4000: DNS-серверу не удалось открыть Active Directory. Этот DNS-сервер настроен на получение и использование информации из каталога для этой зоны и не может загрузить зону без нее. Убедитесь, что Active Directory работает правильно, и перезагрузите зону. Данные события — это код ошибки.
  • Идентификатор события 4007: DNS-серверу не удалось открыть зону в Active Directory из раздела каталога приложений

Быстрый поиск в Google выдал эту базу знаний Microsoft. Похоже, DC либо потерял свой безопасный канал с PDC, либо удерживает все роли FSMO и указывает на себя как на DNS-сервер. Любой из них мог быть виновником в моем случае, поскольку этот контроллер домена действительно имел все роли FSMO (и, следовательно, был также PDC), и поэтому, возможно, он потерял доверие к себе? Плохое состояние, не верить в себя… ;-)

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

В случае, если контроллер домена потерял доверие к себе, решение (согласно статье базы знаний) заключалось в сбросе пароля контроллера домена. Не уверен, как это восстановит доверие, но, по-видимому, это так. Для этого используется команда netdom, которая установлена ​​на сервере Server 2008 и более поздних версиях (а также в Windows 8 или если установлен RSAT, который можно загрузить для 2003 года из пакета инструментов поддержки). Команду необходимо запустить на компьютере, пароль которого вы хотите сбросить (поэтому вы должны войти в систему с учетной записью, инициалы которой кэшированы, или использовать локальную учетную запись). Затем запустите команду следующим образом:

В этой статье мы рассмотрим, почему невозможно присоединить новый компьютер к домену Active Directory из-за ошибки «Не удалось связаться с контроллером домена Active Directory».

Не удалось связаться с контроллером домена Active Directory: как это выглядит и как это исправить?

Пользователь или администратор пытается присоединить к домену новую рабочую станцию ​​или сервер Windows. Для этого откройте Свойства системы на рабочей станции, нажмите Изменить настройки > Изменить. Введите новое имя компьютера и выберите, что этот компьютер должен быть членом указанного домена. Введите полное доменное имя домена AD. После нажатия на кнопку ОК может появиться сообщение об ошибке:

Если имя верное, нажмите «Подробнее», чтобы получить информацию об устранении неполадок.

Нажмите кнопку "Подробности", чтобы получить дополнительные сведения об ошибке. В большинстве случаев вы увидите ошибку «DNS-имя не существует» (коды ошибок 0x0000232B RCODE_NAME_ERROR, 0x0000267C DNS_ERROR_NO_DNS_SERVER и 0x00002746 WSAECONNRESET).

Доменное имя «DOMAIN_NAME» может быть доменным именем NetBIOS.В этом случае убедитесь, что доменное имя правильно зарегистрировано в WINS.

Если вы уверены, что имя не является доменным именем NetBIOS, следующая информация может помочь вам устранить неполадки в конфигурации DNS.

При запросе к DNS записи ресурса расположения службы (SRV), используемой для обнаружения контроллера домена Active Directory (AD DC) для домена «DOMAIN_NAME», произошла следующая ошибка:

ошибка: «DNS-имя не существует».

(код ошибки 0x0000232B RCODE_NAME_ERROR)

Запрос был на запись SRV для _ldap._tcp.dc._msdcs.DOMAIN_NAME

Распространенные причины этой ошибки включают следующее:

– Записи DNS SRV, необходимые для обнаружения AD DC для домена, не зарегистрированы в DNS. Эти записи автоматически регистрируются на DNS-сервере при добавлении AD DC в домен. Они обновляются AD DC с заданными интервалами. Этот компьютер настроен на использование DNS-серверов со следующими IP-адресами:

xx.xx.xx.xx

xx.xx.xx.xx

– Одна или несколько из следующих зон не включают делегирование в дочернюю
зону:

имя_домена
local
.. (корневая зона)

Проверьте правильность настроек IP на вашем компьютере

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

Прежде всего проверьте, имеет ли ваш компьютер правильный IP-адрес на основном сетевом интерфейсе. IP-адрес можно получить с DHCP-сервера или указать вручную в настройках сетевого адаптера. Текущие сетевые настройки компьютера можно получить с помощью команды:

Убедитесь, что служба DNS-клиент запущена с помощью командлета Get-Service:

Откройте файл hosts (C:\Windows\System32\Drivers\etc\hosts) на компьютере с помощью notepad.exe или другого текстового редактора и убедитесь, что в нем нет записей для имен вашего домена или контроллера домена. Если такие записи существуют, удалите их.

Вы можете отобразить содержимое файла hosts с помощью команды:

Затем очистите кеш DNS и перезапустите службу из командной строки с повышенными привилегиями:

Затем проверьте, доступен ли контроллер домена с клиента. Откройте командную строку и выполните следующие команды:

Убедитесь, что ваш контроллер домена отвечает и доступен.

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

Если DC доступен, попробуйте добавить полученный IP-адрес в качестве DNS-сервера в дополнительных настройках TCP/IP вашего сетевого подключения.

  1. Откройте Панель управления > Сеть и Интернет > Центр управления сетями и общим доступом > Изменить параметры адаптера.
  2. Выберите сетевой адаптер, подключенный к вашей корпоративной сети, щелкните его правой кнопкой мыши и выберите "Свойства";
  3. Выберите Интернет-протокол версии 4 (TCP/IPv4) и нажмите "Свойства".
  4. Нажмите кнопку "Дополнительно" и перейдите на вкладку "DNS";
  5. На вкладке DNS нажмите "Добавить" и введите IP-адрес вашего DNS-сервера (контроллера домена). Не используйте общедоступные IP-адреса DNS в предпочтительных и альтернативных полях, например 8.8.8.8 (google) или 1.1.1.1 (cloudflare);
  6. Нажмите «ОК» (если в списке DNS-серверов указано несколько IP-адресов, переместите IP-адрес вашего контроллера домена в начало списка);
  7. Сохраните изменения и перезапустите рабочую станцию.
  8. Попробуйте подключить свою рабочую станцию ​​к домену AD.

    9. Убедитесь, что доступ к службе DNS на контроллере домена не заблокирован брандмауэрами. Самый простой способ проверить доступность порта 53 на контроллере домена — использовать PowerShell:

    В нашем примере TcpTestSucceeded: True означает, что служба DNS на контроллере домена доступна.

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

    Команда должна вернуть одну или несколько записей DNS-серверов.

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

    Если ваш компьютер успешно обнаружил домен и контроллер домена, команда должна вернуть информацию о домене, сайте AD и службах, работающих на контроллере домена:

    Подсказка. Еще одно полезное руководство, которое может помочь вам в устранении неполадок с подключением к контроллеру домена через RPC, — «Сервер RPC недоступен»

    Иногда в файле Netsetup.log можно найти полезную информацию об ошибках при присоединении компьютера к домену Active Directory. Это клиенты Windows регистрируют подробности операции присоединения к домену. Этот журнал можно найти здесь %windir%\debug\Netsetup.log. Внимательно изучите ошибки в файле Netsetup.log, они могут помочь вам найти проблему невозможности подключения к домену Active Directory.

    • Не удалось разрешить DNS-имя контроллера домена в присоединяемом домене. Убедитесь, что этот клиент настроен на доступ к DNS-серверу, который может разрешать DNS-имена в целевом домене;
    • Попытка выполнить операцию с несуществующим сетевым подключением — перезагрузите компьютер, убедитесь, что вы вводите имя DNS, а не имя NetBIOS;
    • Не допускается многократное подключение к серверу или общему ресурсу одним и тем же пользователем с использованием более одного имени пользователя. Отключите все предыдущие подключения к серверу или общему ресурсу и повторите попытку — перезагрузите устройство;
    • Сетевое имя не найдено — убедитесь, что ваш компьютер имеет доступ к DNS-серверу, на котором размещена зона DNS домена;
    • В настоящее время к этому удаленному компьютеру больше нельзя установить никаких подключений, потому что уже есть столько подключений, сколько компьютер может принять — удалите все сопоставленные диски и перезагрузите компьютер.

    Кроме того, попробуйте временно отключить встроенный брандмауэр Windows и все сторонние приложения с модулями антивируса/брандмауэра (Symantec, MacAfee, Защитник Windows и т. д.), которые могут блокировать сетевые порты для доступа к контроллеру домена. После отключения брандмауэров попробуйте присоединить компьютер к домену.

    Вот минимальный список сетевых протоколов, портов и служб, которые не должны блокироваться брандмауэрами между клиентом и контроллером домена для успешного присоединения устройства к домену Active Directory:

    • UDP 53 — DNS-трафик;
    • TCP и UDP 88 — аутентификация Kerberos;
    • UDP 123 — синхронизация времени Windows с DC;
    • TCP 135 — локатор удаленного вызова процедур RPC;
    • TCP и UDP 139 — служба сеансов NetBIOS;
    • TCP и UDP 389 (LDAP, локатор контроллеров домена, сетевой вход) или TCP 636 (LDAP через SSL);
    • TCP 445 (SMB/CIFS, сетевой вход);
    • TCP 49152-65535 — порты RPC, случайным образом распределенные высокие порты TCP.

    Проверьте записи репликации и DNS SRV на контроллере домена

    Если описанный выше способ не помог, проверьте, есть ли в зоне DNS вашего контроллера домена SRV-запись расположения контроллера домена.

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

    Проверьте, есть ли у указанного DNS-сервера запись SRV в следующей форме:

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

    Если вы не можете изменить настройки DNS на своем компьютере, вы можете вручную добавить две записи (SRV и A) на существующий DNS-сервер, которые помогут вам разрешить IP-адрес контроллера домена:

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

    Перезапустите службу Netlogon на контроллере домена с помощью команды:

    (или просто попробуйте перезагрузить контроллер домена)

    При запуске он попытается зарегистрировать необходимые записи SRV на DNS-сервере.

    Кроме того, вы можете перерегистрировать DNS-записи контроллера домена с помощью команды:

    Подождите некоторое время, пока записи появятся в DNS и реплицируются в домене.

    Также рекомендуется проверить, созданы ли общие сетевые папки SYSVOL и NETLOGON и доступны ли они на контроллере домена (выполните команду net share на ближайшем контроллере домена).

    Если каталоги SYSVOL и NETLOGON отсутствуют в списке общих ресурсов:

    1. Проверьте настройки IP и DNS на вашем контроллере домена (контроллер домена не должен получать IP-адрес от DHCP-сервера, используйте только статический IP-адрес);
    2. Проверьте, содержит ли каталог домена C:\Windows\SYSVOL папки Policies и Scripts;
    3. Если вы не перенесли репликацию Sysvol с FRS на DFS, чтобы реплицировать Sysvol с PDC на все контроллеры домена в домене, необходимо остановить службу репликации файлов (net stop NtFrs). Затем запустите Regedit и перейдите в раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/RestoreProcess at Startup, здесь измените значение параметра BurFlags DWORD на D4 (hex) на PDC и на D2 (hex) на всех дополнительных контроллерах домена. После этого запустите службу:

    Доступ к устаревшим контроллерам домена с использованием протокола SMB v1

    Если вы используете контроллеры домена под управлением Windows Server 2008/2003/2000 и пытаетесь присоединить к домену Windows 10 1803 (или более поздней версии) или Windows Server 2019, необходимо включить поддержку протокола SMBv1 на стороне клиента ( этот протокол отключен по умолчанию в более новой ОС Windows). Клиент SMB1Protocol-Client позволяет вашему компьютеру получать доступ к устаревшим серверам.

    Чтобы включить поддержку SMBv1 в Windows 10, выберите Панель управления > Программы > Включение или отключение компонентов Windows. Разверните узел Поддержка общего доступа к файлам SMB 1.0/CIFS, включите параметр Клиент SMB 1.0/CIFS и сохраните изменения.

    Вы можете проверить состояние клиентского протокола SMB 1.0/CIFS на компьютере с Windows 10 с помощью команды PowerShell:

    Если статус протокола SMB1Client отключен, вы можете включить его, используя:

    Вы можете проверить, включен ли клиент SMBv1 в Windows Server 2022 или 2019, с помощью следующей команды PowerShell:

    Чтобы установить клиент SMBv1 на Windows Server 2022/2019, выполните:

    В клиентах Windows 7/Vista состояние протокола SMBv1 можно определить с помощью команды:

    Если вам нужно включить клиент SMB v1 в Windows 7/Windows Server 2008 R2, выполните:

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

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