Winrs error клиенту winrm не удается обработать запрос

(Клиент WinRM не может обрабатывать запрос) ошибка при подключении к Exchange Online через удаленные Windows PowerShell

При использовании удаленного Windows PowerShell для подключения к Exchange Online в Microsoft Office 365 вы получаете следующее сообщение об ошибке:

[outlook.office365.com] Подключение к удаленному серверу не удалось с помощью следующего сообщения об ошибке:
Клиент WinRM не может обрабатывать запрос, так как имя сервера невозможно разрешить. Дополнительные сведения см. в разделе about_Remote_Troubleshooting Справка.

+ CategoryInfo : OpenError:
(System.Manageme. RemoteRunspace:RemoteRunspace) [].
PSRemotingTransportException

+ FullyQualifiedErrorId : PSSessionOpenedFailed

Причина

Эта проблема возникает в одной из следующих ситуаций:

• Брандмауэр блокирует необходимый трафик.
• Служба Windows удаленного управления не запущена.
• Прокси-сервер работает неправильно.

Решение

Убедитесь, что брандмауэр не блокирует необходимый трафик.

Проверьте, установлена ли Windows служба удаленного управления и запущена ли она:

Введите services.msc в диалоговом окне Run и нажмите кнопку Ввод.

В MMC служб дважды щелкните Windows удаленное управление.

Установите тип запуска в Руководство, а затем нажмите кнопку ОК.

Щелкните правой кнопкой мыши службу, а затем выберите Начните.

Если служба уже запущена, но она не отвечает, может потребоваться перезапустить.

Попробуйте подключиться к Exchange Online снова.

Проверка параметра прокси-сервера

Откройте повышенный командный запрос.

Запустите следующую команду, чтобы проверить текущую конфигурацию прокси:

Примите одно из следующих действий:

Чтобы сбросить прокси WinHTTP, запустите следующую команду:

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

Например, запустите netsh winhttp set proxy 10.0.0.6:8080 .

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

Дополнительные сведения о конечных точках Microsoft 365 см. в Microsoft 365 URL-адресов и диапазонов IP-адресов.

Дополнительные сведения о том, как подключиться к Exchange Online с помощью удаленной PowerShell, Подключение в Exchange Online с помощью remote PowerShell.

Сообщения: 225
Благодарности: 1

Рабочая группа. Два сервера виндовс 2012 р2. Подключил к Диспетчеру серверов для мониторинга и управления удаленный (через интернет) сервер. Вроде как работает, но зайдя в Диспетчере серверов на вкладку Ролей и компонентов Файловые службы и службы хранилища, диски видны обоих серверов, но уже перейдя на вкладку Тома появляются такие сообщения

«Komandor Сбой перечисления общих ресурсов SMB.
Произошла ошибка при перечислении общих ресурсов SMB: Клиенту WinRM не удалось обработать запрос, так как не удалось разрешить имя сервера.»

«Komandor Ошибка при перечислении хранилищ.
Клиенту WinRM не удалось обработать запрос, так как не удалось разрешить имя сервера.»

Клиенту winrm не удалось обработать запрос так как не удалось разрешить имя сервера

На днях мой коллега задал мне вопрос, на который я не смог ответить с ходу. Ему не удавалось подключиться, с помощью powershell remoting, к удаленному серверу, находящемуся в другом домене. При попытке сделать это он получал примерно вот такое сообщение

Не удалось подключиться к удаленному серверу. Сообщение об ошибке: Клиенту WinRM не удается обработать запрос. Проверку подлинности по умолчанию можно использовать с IP-адресом при следующ
их условиях: транспортом является HTTPS или назначением является список TrustedHosts, кроме того, должны быть предоставлены явно указанные учетные данные. Чтобы настроить TrustedHosts, используйте winrm.
cmd. Обратите внимание, что в списке TrustedHosts могут находиться компьютеры, не прошедшие проверку подлинности. Для получения сведений о настройке TrustedHosts используйте следующую команду: winrm help
config. Дополнительные сведения см. в разделе справки, вызываемом командой about_Remote_Troubleshooting.

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

После нескольких экспериментов мой коллега сообщил, что если добавить адрес удаленного сервера в TrustedHosts на клиентской машине, то все работает. Все довольно странно и запутано. По этому – давайте подробнее разберем все эти ситуации.

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

Кроме того, исходя из сообщений об ошибках (да, их надо читать внимательно), и, соответственно, из методов обращения к серверу, есть две ситуации:

• при обращении к серверу, клиент указывает IP-адрес в качестве адреса назначения
• при обращении к серверу, клиент указывает имя в качестве адреса назначения

К сожалению в интернетах нет однозначного мнения по поводу того, где, на сервере или клиенте, нужно задавать параметр TrustedHosts, и нужно ли это вообще делать. На что это влияет и все такое. В целом, информация довольно скудная по этому поводу. Поэтому, после долгого забега по гуглу, я решил обратиться, куда бы вы думали – да, к первоисточнику. А именно – к спецификации на ws-management. Про параметр TrustedHosts там сказано следующее:

• Blank: No hosts are trusted.
• The asterisk «*» character: All hosts are trusted.
• A list of host name patterns separated by the comma «,» character, in which each host name can be one of four possible values:
  • String starting with the asterisk «*» character and containing at least two characters. All hosts that share the suffix are trusted.
  • String ending with the asterisk «*» character and containing at least two characters. All hosts that share the prefix are trusted.
  • The exact string » «: All NetBIOS names are trusted (for example, strings that do not contain the period «.» character).
  • A string without the asterisk «*» character: The host named by the string is trusted.

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

  Следующий этап – два домена с доверительными отношениями. В этом случае тоже нет необходимости в TrustedHosts. Однако необходимо обеспечить корректное разрешение имен. Однако, скажете вы, ведь в домене можно обращаться не только по имени, а еще и по адресу, и все должно работать корректно. А у нас, при попытке использовать адрес, вываливается ошибка. И вот тут возникает необходимость внимательно прочитать содержимое ошибки:

  Проверку подлинности по умолчанию можно использовать с IP-адресом при следующих условиях: Транспортом является HTTPS или назначением является список TrustedHosts.

  Прежде всего видим, что в TrustedHosts нужно указывать именно назначение. А почему такое ограничение на использование IP-адреса? Об этом написано в блоге Ask the Directory Services Team. Вкратце, там сказано, что нельзя в качестве использовать IP-адреса в синтаксисе записи SPN. И если в windows xp/2003 это работало то в Vista и старше при использовании IP-адреса в назначении не будет даже попыток использовать kerberos . Отсюда и ошибка: раз не используется протокол с взаимной аутентификацией – используйте HTTPS или пропишите TrustedHosts. Для того чтобы убедиться в этом, вы можете воспользоваться вашим любимым сниффером. В нем вы увидите, что клиент даже не пытается установить связь с сервером, если вы указываете в качестве назначения адрес. Ошибка выдается сразу. Более подробно про SPN вы можете так же прочесть в моей статье.

  И наконец – не доменное окружение. Powershell знает, что клиентская машина не в домене. Значит kerberos по определению не возможен. Следовательно либо TrustedHosts либо HTTPS.