При настройке WinRM на серверах в домене Active Directory столкнулся со странной проблемой. После того как служба WinRM была настроена и включена на сервере, к ней разрешено удалённое подключение через Windows PowerShell Remoting, при попытке удаленного подключения к данному серверу с помощью команды Enter-PSSession msk-dp01 в консоли PowerShell появляется следующая ошибка WinRM:
Enter-PSSession: Сбой подключения к удаленному серверу msk-dp01. Сообщение об ошибке: Клиенту WinRM не удается обработать запрос. Невозможно определить тип содержимого ответа HTTP от компьютера назначения. Тип содержимого не является допустимым или отсутствует. Подробности см. в разделе справки «about_Remote_Troubleshooting».
строка:1 знак:1
Enter-PSSession msk-dp01
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
В английской версии Windows ошибка выглядит так:
PS C:\Windows\system32> Enter-PSSession msk-dp01
Enter-PSSession: Connecting to remote server msk-dp01 failed with the following error message: The WinRM client received an HTTP bad request status (400), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
Enter-PSSession msk-dp01
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CategoryInfo: InvalidArgument: (msk-dp01:String) , PSRemotingTransportException
FullyQualifiedErrorId: CreateRemoteRunspaceFailed
При этом на сервере порты WinRm (5985/HTTP, 5986/HTTPS) отвечают и принимают соединения. Проверить доступность TCP портов WinRM можно с помощью или командлета PowerShell :
TNC msk-dp01 –port 5985
Как оказалось, проблема оказалась связана с большим размером токена Kerberos у пользователя, за счет того, что пользователь состоит в слишком большом количестве доменных групп. Ошибка возникает при превышении размера токена 16 Кб (см статью ). В нашей ситуации происходит все тоже самое, сервер WinRm сбрасывает запрос от клиента, т.к. размер заголовка пакета аутентификации превышает 16 Кб. В статье по ссылке мы упоминали, что по-умолчанию в IIS используется размер HTTP заголовка не более 16 Кб, и в случае проблем с HTTP аутентификацией из за большого токена пользователя, его нужно увеличить до 64 Кб
Чтобы исправить проблему, нужно уменьшить размер токена (уменьшить количество групп безопасности, в которых состоит пользователь), а если это невозможно, тогда в редакторе реестра на сервере нужно изменить значение следующих DWORD параметров реестра в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
Осталось перезагрузить сервер и проверить подключение WinRm через Enter-PSSession с клиента.
У меня как-то раз возникли проблемы с WinRM на двух серверах.
1. SETSPN
На одном проблема была в том, что SPN записи HTTP/<имя сервера> были зарегистрирована для какой-то "левой" учётной записи пользователя.
Нашёл эти записи командой
setspn -F -Q */<имя сервера>
Затем удалил их командами
setspn -D http/<имя сервера>.<имя домена> <имя домена>\<левая учётная запись>
setspn -D http/<имя сервера> <имя домена>\<левая учётная запись>
Затем enable-psremoting -force выполнилась успешно.
2. LANGUAGE PACK
А на втором сервере была хитрая проблема якобы с фаерволлом Unable to check the status of the firewall
, перерыл кучу сайтов, а решение обнаружил интуитивно основываясь на ответе по поводу установленного Language Pack.
WinRm QuickConfig
WinRM service is already running on this machine.
WSManFault
Message
ProviderFault
WSManFault
Message = Unable to check the status of the firewall.
Error number: -2147024894 0x80070002
The system cannot find the file specified.
В ответе было написно, что данная ошибка лечится удалением дополнительного Language Pack.
Но я поступил иначе. У меня Английская операционка с дополнительным русским language pack. Я просто изменил язык интерфейса на Русский.
Панель управления, Язык и региональные стандарты, Языки и клавиатуры изменил язык интерфейса с англиского на русский.
Выполнил logoff и вошёл снова. Открыл PowerShell и повторил WinRm QuickConfig
PS C:\Windows\system32> winrm qc
Служба WinRM не настроена на разрешение удаленного управления компьютером.
Необходимо внести следующие изменения:
Создайте прослушиватель WinRM на HTTP://* для приема запросов WS-Man на любом из IP-адресов этого компьютера.
Выполнить изменения ? y
Служба WinRM обновлена для удаленного управления.
Создан прослушиватель WinRM на HTTP://* для приема запросов WS-Man на любом из IP-адресов этого компьютера.
Выполнилось успешно, но всё же не достаточно.
Появилась ошибка Access Denied при попытке выполнить команды удалённо на этом сервере с другого компа.
New-PSSession: [<имя сервера>] Connecting to remote server <имя сервера> failed with the following error message: Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
Тогда я повторил Enable-PsRemoting
PS C:\Windows\system32> Enable-PsRemoting
Быстрая настройка WinRM
Запуск команды "Set-WSManQuickConfig" для включения на данном компьютере удаленного управления с помощью службы WinRM.
Необходимые действия.
1. Запуск или перезапуск (если уже запущена) службы WinRM.
2. Изменение типа службы WinRM на "автозапуск".
3. Создание прослушивателя для приема запросов на любом IP-адресе.
4. Настройка исключений брандмауэра для трафика службы WS-Management (только для протокола http).
Продолжить?
(значением по умолчанию является "Y"):a
Служба WinRM уже настроена на прием запросов на компьютере.
Служба WinRM уже настроена на разрешение удаленного управления компьютером.
Подтверждение
Вы действительно хотите выполнить это действие?
Выполнение операции "Регистрация конфигурации сеанса" над целевым объектом "Конфигурация сеанса
"Microsoft.PowerShell32" не найдена. Будет выполнена команда "Register-PSSessionConfiguration Microsoft.PowerShell32
-processorarchitecture x86 -force" для создания конфигурации сеанса "Microsoft.PowerShell32". Служба WinRM будет
перезапущена.".
[Y] Да - Y [A] Да для всех - A [N] Нет - N [L] Нет для всех - L [S] Приостановить - S [?] Справка
(значением по умолчанию является "Y"):a
После этого WinRM на этом сервере заработал как надо.
Инструменты управления в Exchange 2010 зависят от IIS. Там же мы рассматривали ситуации, когда подключение инструментов управления к целевому серверу Exchange может завершиться аварийно, а сообщение об ошибке подключения оказаться сложным для понимания. Обычно (но не всегда) это случается, когда Exchange 2010 устанавливается на IIS уже находящийся в эксплуатации, или когда в IIS вносятся изменения после установки Exchange 2010. Мы видели, что эти изменения обычно вносятся, когда администратор IIS пытается «закрутить гайки» безопасности в IIS, редактируя настройки Default Web Site или PowerShell vdir.
Ситуация осложняется тем, что некоторые из представленных ошибок имеют похожие сообщения; кажется, что большинство из них происходит из-за WinRM (Windows Remote Management), и в некоторых случаях в корне различные проблемы могут производить совершенно одинаковое сообщение об ошибке. Другими словами в зависимости от того, насколько хорошо вы знакомы с этими ошибками, их устранение превращается в перебор всех вариантов… а это не забавляет.
И вот результат: представляем Exchange Management Troubleshooter (или кратко EMTshooter).
EMTshooter запускается на локальном (целевом) сервере Exchange и пытается определить потенциальные проблемы подключения инструментов управления к этому серверу.
EMTshooter выполняется за два шага. На первом шаге он тестирует IIS Default Web Site, PowerShell vdir и другие критические области, чтобы найти известные проблемы. Если он находит известную проблему, то он выдает сообщение с рекомендациями по ее устранению. Если все проверки проходят удачно, то он пытается подключиться к серверу точно также как инструменты управления. Если это попытка подключения получит ошибку от WinRM, EMTshooter будет пытаться сравнить эту ошибку со списком текстов (строк) ошибок, который мы составили на основе решений для аналогичных ошибок в службе поддержки. Если соответствие найдено, то EMTshooter выведет в окно CMD известные причины ошибки. Вот пример того, как это выглядит:
Когда я разрабатывал EMTshooter, я мог бы просто написать маленький поисковый инструмент для анализа сообщения об ошибке, которую вы получили, но я почувствовал, что это не столь надежное решение, как я хотел (и не дающее мне никакого опыта). Но EMTshooter выполняет предварительные активные проверки до анализа текста сообщения об ошибке. Количество предварительных проверок, которые он может выполнить, зависит от свойств операционной системы, на которой вы его запустили, и опций, которые вы на ней установили (например, WMI Compatibility).
По правде говоря, я взял всю документацию об этих ошибках, которая была доступна на тот момент, и сделал инструмент, который делает эту информацию доступной для вас, основываясь на сообщении об ошибке или проблеме, которую он обнаружил. Надеюсь, это уменьшит количество времени, которое необходимо для решения этих проблем.
Когда вы запускаете EMTshooter, он пишет сообщения в журнал событий. Все результаты, которые отображаются в окне CMD, также записываются в журнал событий.
События пишутся в журнал Microsoft-Exchange-Troubleshooters/Operational и не требуют пояснений.
В зависимости от текущих настроек вам может потребоваться настройка политики на компьютере, на котором выполняется EMTshooter:
Set-ExecutionPolicy RemoteSigned
Set-ExecutionPolicy Unrestricted
Не забудьте вернуть политику в исходное состояние после работы с EMTshooter.
Эта версия EMTshooter должна запускаться на сервере Exchange, к которому невозможно подключиться с помощью инструментов управления. Хотя наша цель была в том, чтобы запускать EMTshooter из любого места, где установлены инструменты управления, но он еще не готов для этого.
У нас были случаи, когда повреждение в PowerShell vdir или в самом IIS приводило к ошибкам, которые, как казалось, были вызваны чем-то другим. Например, мы работали над сервером, у которого была ошибка, которая указала на проблему с сетевым путем в PowerShell vdir. Но путь был правильным. Затем мы заметили, что PowerShell vdir потерял все свои модули, и отметили еще некоторые моменты. Так или иначе, PowerShell vdir на том сервере Exchange был безнадежно убит и не подлежал восстановлению. В этой ситуации WinRM возвращал лучшую ошибку, какую мог, EMTshooter взял эту ошибку и перечислил причины. Ни одна из них не решила проблему. Так что знайте: есть сценарии, в которых даже EMTshooter не может помочь в настоящее время.
EMTshooter еще недостаточно отточен, и мы планируем в будущем улучшить и расширить его возможности. Мы также надеемся со временем углубиться в настройки PowerShell vdir. Также отметим, что EMTshooter не будет делать изменения в конфигурации IIS без вашего разрешения.
Необходимые права
Для того, чтобы запустить EMTshooter, пользователь должен иметь права локального входа (log on locally) на Exchange сервер и права запуска Windows Powershell.
Во-первых, загрузите ZIP файл с EMTshooter , который находится .
Установка EMTshooter очень проста. Извлеките 4 файла из ZIP файла в одну папку, переименуйте их в.ps1и запустите локально EMTshooter.ps1 из окна PowerShell. Лично я создал ярлык на моем рабочем столе:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". "C:\EMTshooter\EMTshooter.ps1""
Однако большинство пользователей не запускают его часто, и вы, скорее всего, не захотите иметь ярлык. Только помните, что нужно запускать именно файл EMTshooter.ps1.
Как я упоминал ранее, EMTshooter все еще незавершен. Если вы хотите сообщить об ошибке или сделать предложение по улучшению, то оставьте, пожалуйста, комментарий к этому сообщению в блоге. Я буду их отслеживать, отвечать по возможности и вносить изменения в EMTshooter по необходимости. Если вы столкнетесь с ошибками, которые не известны EMTshooter, то запустите его, воспроизведите ошибку и отправьте мне transcript.txt file (вы найдете его в папке, где лежат 4 скрипта) вместе с пояснением, что вы сделали, чтобы устранить ошибку (если ошибка была устранена). Мой адрес: sbryant AT Microsoft DOT com.
Соединение с удаленным сервером перестало работать со следующим сообщением об ошибке: The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid.
. Соединение с удаленным сервером перестало работать со следующим сообщением об ошибке: The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL.
. Соединение с удаленным сервером перестало работать со следующим сообщением об ошибке: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command "Discover-ExchangeServer -UseWIA $true -SuppressError $true".
. Соединение с удаленным сервером перестало работать со следующим сообщением об ошибке: The WinRM client received an HTTP status code of 403 from the remote WS-Management service.
. Соединение с удаленным сервером перестало работать со следующим сообщением об ошибке: The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol.
. Соединение с удаленным сервером перестало работать со следующим сообщением об ошибке: The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service:
. Соединение с удаленным сервером перестало работать со следующим сообщением об ошибке: The WS-Management service does not support the request.
. Соединение с удаленным сервером перестало работать со следующим сообщением об ошибке: The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer
Стив Брайант
Перевод: Илья Сазонов, MVP
На днях мой коллега задал мне вопрос, на который я не смог ответить с ходу. Ему не удавалось подключиться, с помощью powershell remoting, к удаленному серверу, находящемуся в другом домене. При попытке сделать это он получал примерно вот такое сообщение
Я, в свою очередь, тоже попробовал сделать это в разных окружениях и получил несколько разных результатов:
После нескольких экспериментов мой коллега сообщил, что если добавить адрес удаленного сервера в TrustedHosts на клиентской машине, то все работает. Все довольно странно и запутано. По этому – давайте подробнее разберем все эти ситуации.
Прежде всего стоит отметить, что проблема возникает, когда используются не доменные окружения. То есть, если клиент и сервер находятся не в одном домене. Наиболее часто, на мой взгляд, встречаются три ситуации:
компьютеры сервера и клиента расположены в разных доменах
компьютер сервера расположен в домене а клиент – вне домена
компьютеры сервера и клиента не входят в домен
Кроме того, исходя из сообщений об ошибках (да, их надо читать внимательно), и, соответственно, из методов обращения к серверу, есть две ситуации:
К сожалению в интернетах нет однозначного мнения по поводу того, где, на сервере или клиенте, нужно задавать параметр TrustedHosts, и нужно ли это вообще делать. На что это влияет и все такое. В целом, информация довольно скудная по этому поводу. Поэтому, после долгого забега по гуглу, я решил обратиться, куда бы вы думали – да, к первоисточнику. А именно – к спецификации на ws-management . Про параметр TrustedHosts там сказано следующее:
TrustedHosts: Contains host names to which the Web Services Management Protocol Extensions for Windows Vista clients are allowed to send requests by using an authentication scheme and transport that does not allow the client to authenticate the service , such as Basic over HTTP.
The specified host names may be either Internet host names or IP addresses. 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.
The default value for the
element MUST be a blank string.
Основная идея выделена. И это означает, что параметр TrustedHosts нужно использовать на клиенте . В этом списке указываются машины, при работе с которыми невозможно использовать схемы с поддержкой взаимной аутентификации . Таким образом, если и клиент и сервер находятся в одном домене, то для подключения вы можете использовать простую команду без дополнительных параметров.
Следующий этап – два домена с доверительными отношениями. В этом случае тоже нет необходимости в TrustedHosts. Однако необходимо обеспечить корректное разрешение имен. Однако, скажете вы, ведь в домене можно обращаться не только по имени, а еще и по адресу, и все должно работать корректно. А у нас, при попытке использовать адрес, вываливается ошибка. И вот тут возникает необходимость внимательно прочитать содержимое ошибки:
Проверку подлинности по умолчанию можно использовать с IP-адресом при следующих условиях: Транспортом является HTTPS или назначением является список TrustedHosts.
Прежде всего видим, что в TrustedHosts нужно указывать именно назначение. А почему такое ограничение на использование IP-адреса? Об этом написано в блоге . Вкратце, там сказано, что нельзя в качестве использовать IP-адреса в синтаксисе записи SPN . И если в windows xp/2003 это работало то в Vista и старше при использовании IP-адреса в назначении не будет даже попыток использовать kerberos . Отсюда и ошибка: раз не используется протокол с взаимной аутентификацией – используйте HTTPS или пропишите TrustedHosts. Для того чтобы убедиться в этом, вы можете воспользоваться вашим любимым сниффером. В нем вы увидите, что клиент даже не пытается установить связь с сервером, если вы указываете в качестве назначения адрес. Ошибка выдается сразу. Более подробно про SPN вы можете так же прочесть в моей статье .
И наконец – не доменное окружение. Powershell знает, что клиентская машина не в домене. Значит kerberos по определению не возможен. Следовательно либо TrustedHosts либо HTTPS.
