Ошибка winrm не удается обработать запрос

При настройке WinRM на серверах в домене Active Directory столкнулся со странной проблемой. После того как служба WinRM была настроена и включена на сервере, к ней разрешено удалённое подключение через Windows PowerShell Remoting, при попытке удаленного подключения к данному серверу с помощью команды
Enter-PSSession msk-dp01
в консоли PowerShell появляется следующая ошибка WinRM:

В английской версии Windows ошибка выглядит так:

При этом на сервере порты WinRm (5985/HTTP, 5986/HTTPS) отвечают и принимают соединения. Проверить доступность TCP портов WinRM можно с помощью утилиты PortQryV2 или командлета PowerShell Test-NetConnection:

TNC msk-dp01 –port 5985

Как оказалось, проблема оказалась связана с большим размером токена Kerberos у пользователя, за счет того, что пользователь состоит в слишком большом количестве доменных групп. Ошибка возникает при превышении размера токена 16 Кб (см статью MaxTokenSize — размер токена Kerberos). В нашей ситуации происходит все тоже самое, сервер WinRm сбрасывает запрос от клиента, т.к. размер заголовка пакета аутентификации превышает 16 Кб. В статье по ссылке мы упоминали, что по-умолчанию в IIS используется размер HTTP заголовка не более 16 Кб, и в случае проблем с HTTP аутентификацией из за большого токена пользователя, его нужно увеличить до 64 Кб

Чтобы исправить проблему, нужно уменьшить размер токена (уменьшить количество групп безопасности, в которых состоит пользователь), а если это невозможно, тогда в редакторе реестра на сервере нужно изменить значение следующих DWORD параметров реестра в ветке HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesHTTPParameters

• MaxFieldLength увеличить до 0000ffff (65535)
• MaxRequestBytes увеличить до 0000ffff (65535)

Осталось перезагрузить сервер и проверить подключение WinRm через Enter-PSSession с клиента.

КРАТКОЕ ОПИСАНИЕ
    Описывает, как устранять неполадки удаленных операций в
    Windows PowerShell.

ПОЛНОЕ ОПИСАНИЕ
    В этом разделе описаны некоторые неполадки, которые могут
    возникнуть при использовании функций удаленного взаимодействия
    Windows PowerShell, основанных не технологии WS-Management, и
    приводятся рекомендации по устранению этих неполадок.

    Перед использованием функций удаленного взаимодействия Windows
    PowerShell ознакомьтесь с разделами about_Remote и about_Remote_Requirements,
    чтобы получить инструкции по настройке и выполнению базовых
    операций. Кроме того, в разделах справки по каждому из
    командлетов, в особенности в описаниях операций, содержатся
    полезные сведения, помогающие избежать неполадок.

    Обновленные версии этого, а также других разделов справки по
    Windows PowerShell, доступны в Интернете в библиотеке Microsoft
    TechNet. Чтобы открыть интернет-версию этого раздела справки,
    вставьте в интернет-браузер следующий URL-адрес:

 http://go.microsoft.com/fwlink/?LinkID=135188
 

    ПРИМЕЧАНИЕ. В Windows Vista, Windows Server 2008 и более поздних
    версиях Windows для просмотра и изменения параметров локального
    компьютера на диске WSMan:, в том числе конфигурации сеансов,
    доверенных узлов, портов и прослушивателей, запускайте Windows
    PowerShell в режиме «Запуск от имени администратора».

 УСТРАНЕНИЕ НЕПОЛАДОК, СВЯЗАННЫХ С РАЗРЕШЕНИЯМИ И ПРОВЕРКОЙ
 ПОДЛИННОСТИ

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

    ВЫПОЛНЕНИЕ ОПЕРАЦИЙ ОТ ИМЕНИ АДМИНИСТРАТОРА
    —————————
        ОШИБКА. Доступ запрещен. Необходимо запустить этот командлет
        из повышенного процесса.

    Для запуска удаленного сеанса на локальном компьютере или
    просмотра и изменения параметров локального компьютера на диске
    WSMan:, в том числе конфигурации сеансов, доверенных узлов,
    портов и прослушивателей, запустите Windows PowerShell в режиме
    «Запуск от имени администратора».

    Запуск Windows PowerShell в режиме «Запуск от имени администратора»

    — Щелкните правой кнопкой мыши значок Windows PowerShell (или
    Windows PowerShell ISE) и выберите пункт «Запуск от имени администратора».
   

    Запуск Windows PowerShell в режиме «Запуск от имени
    администратора» в Windows 7 и Windows Server 2008 R2

    — На панели задач Windows щелкните правой кнопкой мыши значок
    Windows PowerShell и выберите команду «Запустить Windows
    PowerShell от имени администратора».

    Примечание. В Windows Server 2008 R2 значок Windows PowerShell по
    умолчанию закреплен на панели задач.

    ВКЛЮЧЕНИЕ УДАЛЕННОГО ВЗАИМОДЕЙСТВИЯ
    ———————-
        ОШИБКА. ДОСТУП ЗАПРЕЩЕН
        — либо —
        ОШИБКА. В подключении к указанному удаленному узлу отказано.
        Убедитесь, что на удаленном узле служба WS-Management
        запущена и настроена на прослушивание запросов с
        использованием правильного порта и URL-адреса HTTP.

    Чтобы компьютер мог отправлять удаленные команды, никакая
    настройка не требуется. Однако для получения удаленных команд
    компьютер необходимо настроить, чтобы он поддерживал удаленное
    взаимодействие. Процедура настройки включает запуск службы
    WinRM, установку типа запуска «Авто» для службы WinRM, создание
    прослушивателей для подключений HTTP и HTTPS, а также создание
    конфигураций сеансов по умолчанию.

    Чтобы настроить на компьютере получение удаленных команд,
    воспользуйтесь командлетом Enable-PSRemoting. Следующая команда
    включает все необходимые параметры удаленного взаимодействия,
    активирует конфигурации сеансов и перезапускает службу WinRM,
    чтобы изменения вступили в силу.

        enable-psremoting

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

        enable-psremoting -force

    Дополнительные сведения см. в разделе Enable-PSRemoting.

    ВКЛЮЧЕНИЕ УДАЛЕННОГО ВЗАИМОДЕЙСТВИЯ НА ПРЕДПРИЯТИИ
    —————————————
        ОШИБКА. ДОСТУП ЗАПРЕЩЕН
        — либо —
        ОШИБКА. В подключении к указанному удаленному узлу отказано.
        Убедитесь, что на удаленном узле служба WS-Management
        запущена и настроена на прослушивание запросов с
        использованием правильного порта и URL-адреса HTTP.

    Чтобы включить возможность получения удаленных команд Windows
    PowerShell и приема подключений на одном компьютере,
    воспользуйтесь командлетом Enable-PSRemoting.

    — Чтобы включить исключение брандмауэра, воспользуйтесь групповой
    политикой «Брандмауэр Windows: Разрешать локальные исключения
    для портов». Инструкции см. в ниже в разделе «Создание
    исключения брандмауэра с помощью групповой политики».

    ВКЛЮЧЕНИЕ ПРОСЛУШИВАТЕЛЕЙ С ПОМОЩЬЮ ГРУППОВОЙ ПОЛИТИКИ
    ————————————————
        ОШИБКА. ДОСТУП ЗАПРЕЩЕН
        — либо —
        ОШИБКА. В подключении к указанному удаленному узлу отказано.
        Убедитесь, что на удаленном узле служба WS-Management
        запущена и настроена на прослушивание запросов с
        использованием правильного порта и URL-адреса HTTP.

    Чтобы настроить прослушиватели для всех компьютеров в домене,
    включите политику «Разрешить автоматическую настройку прослушивателей» по
    следующему пути групповых политик:

        Конфигурация компьютераАдминистративные аблоныКомпоненты Windows
          Удаленное управление Windows (WinRM)Служба WinRM.
       

    Включите политику и укажите фильтры IPv4 и IPv6. Подстановочные
    знаки (*) разрешены.

    ВКЛЮЧЕНИЕ ИСКЛЮЧЕНИЯ БРАНДМАУЭРА С ПОМОЩЬЮ ГРУППОВОЙ ПОЛИТИКИ
    ———————————————————-
        ОШИБКА. ДОСТУП ЗАПРЕЩЕН
        — либо —
        ОШИБКА. В подключении к указанному удаленному узлу отказано.
        Убедитесь, что на удаленном узле служба WS-Management
        запущена и настроена на прослушивание запросов с
        использованием правильного порта и URL-адреса HTTP.

    Чтобы включить исключение брандмауэра на всех компьютерах домена,
    включите политику «Брандмауэр Windows: Разрешать локальные исключения для портов» по
    следующему пути групповых политик:

        Конфигурация компьютераАдминистративные аблоныСетьСетевые
        подключенияБрандмауэр WindowsПрофиль домена

    Эта политика разрешает членам группы «Администраторы» на
    компьютере использовать брандмауэр Windows в панели управления,
    чтобы создавать исключения брандмауэра для службы удаленного
    управления Windows.

    УСТАНОВКА ТИПА ЗАПУСКА «АВТО» ДЛЯ СЛУЖБЫ WINRM.
    ————————————————
        ОШИБКА. ДОСТУП ЗАПРЕЩЕН

    При удаленном взаимодействии Windows PowerShell используется
    служба удаленного управления Windows (WinRM). Для поддержки
    удаленных команд эта служба должна быть запущена.

    В Windows Server 2003, Windows Server 2008 и Windows Server 2008
    R2 для службы удаленного управления Windows (WinRM) используется
    тип запуска «Авто».

    Однако в Windows XP, Windows Vista и Windows 7 служба WinRM по
    умолчанию отключена.

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

    Для выполнения команды на нескольких компьютерах можно создать
    текстовый или CSV-файл с именами компьютеров.

    Например, следующая команда получает список компьютеров
    из файла Servers.txt, а затем устанавливает тип запуска «Авто»
    для службы WinRM на всех компьютерах.

        C:PS> $servers = get-content servers.txt

        C:PS> set-service WinRM -computername $servers -startuptype Automatic

    Чтобы увидеть результаты, воспользуйтесь командлетом Get-WMIObject
    с объектом Win32_Service. Дополнительные сведения см. в разделе Set-Service.   

    ВОССОЗДАНИЕ КОНФИГУРАЦИЙ СЕАНСОВ ПО УМОЛЧАНИЮ
    —————————————————
        ОШИБКА. ДОСТУП ЗАПРЕЩЕН

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

    Командлет Enable-PSRemoting создает на локальном компьютере
    конфигурации сеансов по умолчанию. Удаленные пользователи
    применяют эти конфигурации сеансов каждый раз, когда удаленная
    команда не содержит параметра ConfigurationName.

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

    Если конфигурации сеансов по умолчанию были изменены и требуется восстановить
    исходные конфигурации сеансов по умолчанию, с помощью командлета
    Unregister-PSSessionConfiguration удалите измененные конфигурации
    сеансов, а затем с помощью командлета Enable-PSRemoting
    восстановите их. Командлет Enable-PSRemoting не изменяет
    имеющиеся конфигурации сеансов.

    Примечание. Когда командлет Enable-PSRemoting восстанавливает
    конфигурации сеансов по умолчанию, он не создает явные
    дескрипторы безопасности для этих конфигураций. Вместо этого
    конфигурации наследуют дескриптор безопасности элемента
    RootSDDL, который является защищенным по умолчанию.

    Чтобы увидеть дескриптор безопасности RootSDDL, введите команду:

        get-item wsman:localhostServiceRootSDDL

    ПРЕДОСТАВЛЕНИЕ УЧЕТНЫХ ДАННЫХ АДМИНИСТРАТОРА
    —————————————-
        ОШИБКА. ДОСТУП ЗАПРЕЩЕН

    Для создания сеанса PSSession или выполнения команд на удаленном
    компьютере по умолчанию текущий пользователь должен быть членом
    группы «Администраторы» на удаленном компьютере. Иногда
    требуется указывать учетные данные, даже если текущий
    пользователь является членом группы «Администраторы».

    Если текущий пользователь является членом группы «Администраторы»
    на удаленном компьютере или может указать учетные данные члена
    группы «Администраторы», воспользуйтесь для удаленного
    подключения параметром Credential командлета New-PSSession,
    Enter-PSSession или Invoke-Command.

    Например, в следующей команде задаются учетные
    данные администратора.

    ВКЛЮЧЕНИЕ УДАЛЕННОГО ВЗАИМОДЕЙСТВИЯ ДЛЯ ПОЛЬЗОВАТЕЛЕЙ, НЕ
    ЯВЛЯЮЩИХСЯ АДМИНИСТРАТОРАМИ
    —————————————————
        ОШИБКА. ДОСТУП ЗАПРЕЩЕН

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

    По умолчанию только члены группы «Администраторы» на компьютере
    имеют разрешение на использование конфигураций сеансов по
    умолчанию. Поэтому только члены группы «Администраторы» могут
    удаленно подключаться к компьютеру.

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

    Следующая команда открывает лист свойств, позволяющий изменять
    дескриптор безопасности конфигурации сеанса Microsoft.PowerShell
    по умолчанию на локальном компьютере.

        Set-PSSessionConfiguration Microsoft.Powershell -ShowSecurityDescriptorUI
       

    Дополнительные сведения см. в разделе about_Session_Configurations.

    ВКЛЮЧЕНИЕ УДАЛЕННОГО ВЗАИМОДЕЙСТВИЯ ДЛЯ АДМИНИСТРАТОРОВ В ДРУГИХ
    ДОМЕНАХ
    ———————————————————-
        ОШИБКА. ДОСТУП ЗАПРЕЩЕН

        C:PS> new-itemproperty -name LocalAccountTokenFilterPolicy -path `
            HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPolicies
            System -propertyType `DWord -value 1

    ИСПОЛЬЗОВАНИЕ В УДАЛЕННОЙ КОМАНДЕ IP-АДРЕСА
    ——————————————————
        ОШИБКА. Клиенту WinRM не удается обработать запрос. Если
        применяемая схема проверки подлинности отличается от
        Kerberos или компьютер клиента не входит в домен, необходимо
        использовать транспорт HTTPS или добавить компьютер
        назначения к значениям параметра конфигурации TrustedHosts.
       

    Параметр ComputerName командлетов New-PSSession, Enter-PSSession и
    Invoke-Command принимает в качестве допустимого значения
    IP-адрес. Но поскольку проверка подлинности Kerberos не
    поддерживает IP-адреса, в случае указания IP-адреса по умолчанию
    используется проверка подлинности NTLM.

    В случае использования проверки подлинности NTLM для удаленного взаимодействия
    необходимо выполнить следующие действия.

    1. Настройте на компьютере использование транспорта HTTPS или
       добавьте IP-адреса удаленных компьютеров в список
       TrustedHosts на локальном компьютере.

       Инструкции см. ниже в разделе «Добавление компьютера в список TrustedHosts».
      

    УДАЛЕННОЕ ПОДКЛЮЧЕНИЕ С КОМПЬЮТЕРА, ВХОДЯЩЕГО В РАБОЧУЮ ГРУППУ
    ——————————————————-
        ОШИБКА. Клиенту WinRM не удается обработать запрос. Если
        применяемая схема проверки подлинности отличается от
        Kerberos или компьютер клиента не входит в домен, необходимо
        использовать транспорт HTTPS или добавить компьютер
        назначения к значениям параметра конфигурации TrustedHosts.
       

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

    1. Настройте на компьютере использование транспорта HTTPS или
       добавьте имена удаленных компьютеров в список TrustedHosts
       на локальном компьютере.

       Инструкции см. ниже в разделе «Добавление компьютера в список TrustedHosts».
      

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

       Чтобы задать пароль для учетной записи пользователя,
       воспользуйтесь элементом «Учетные записи пользователей»
       панели управления.

    ДОБАВЛЕНИЕ КОМПЬЮТЕРА В СПИСОК TRUSTEDHOSTS
    ————————————————

    Элемент TrustedHosts может содержать список разделенных запятыми
    имен компьютеров, IP-адресов и полных доменных имен.

    Подстановочные знаки разрешены.

     Внимание! Действие значения, заданного в элементе TrustedHosts,
               распространяется на всех пользователей компьютера.
    

    Для просмотра списка доверенных узлов необходимо использовать
    следующую команду:

        get-item wsman:localhostClientTrustedHosts

    Кроме того, можно с помощью командлета Set-Location (псевдоним cd)
    перейти к нужному расположению на диске WSMan:.
    Пример: «cd WSMan:localhostClient; dir».

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

        set-item wsman:localhostclienttrustedhosts -value *

    Кроме того, с помощью подстановочного знака (*) можно добавить в
    список доверенных узлов все компьютеры из определенного домена.
    Например, следующая команда добавляет в список доверенных узлов
    все компьютеры из домена Fabrikam.

        set-item wsman:localhostclienttrustedhosts *.fabrikam.com

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

        <компьютер>.<домен>.<компания>.<домен_верхнего_уровня>

    Пример:

        set-item wsman:localhostClientTrustedHosts -value Server01.Domain01.Fabrikam.com
       

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

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

        $curValue = (get-item wsman:localhostClientTrustedHosts).value

        set-item wsman:localhostClientTrustedHosts -value «$curValue, Server01.Domain01.Fabrikam.com»

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

        set-item wsman:localhostClientTrustedHosts -value <IP-адрес>

    Пример:

        set-item wsman:localhostClientTrustedHosts -value 172.16.0.0

    Чтобы добавить компьютер в список TrustedHosts удаленного
    компьютера, с помощью командлета Connect-WSMan добавьте узел
    удаленного компьютера на диск WSMan: локального компьютера.
    После этого добавьте компьютер с помощью команды Set-Item.

    Дополнительные сведения о командлете Connect-WSMan см. в разделе Connect-WSMan.
   

 УСТРАНЕНИЕ НЕПОЛАДОК, СВЯЗАННЫХ С КОНФИГУРАЦИЕЙ КОМПЬЮТЕРОВ
    В этом разделе описаны неполадки удаленного управления, связанные
    с конкретными конфигурациями компьютеров, доменов
    или предприятия.

    НАСТРОЙКА УДАЛЕННОГО ВЗАИМОДЕЙСТВИЯ ЧЕРЕЗ АЛЬТЕРНАТИВНЫЕ ПОРТЫ
    ———————————————
        ОШИБКА. В подключении к указанному удаленному узлу отказано.
        Убедитесь, что на удаленном узле служба WS-Management
        запущена и настроена на прослушивание запросов с
        использованием правильного порта и URL-адреса HTTP.

    По умолчанию при удаленном взаимодействии Windows PowerShell для
    транспорта HTTP используется порт 80. Порт по умолчанию
    используется всегда, когда пользователь не указывает в удаленной
    команде параметр ConnectionURI или Port.

    Чтобы изменить порт, используемый в Windows PowerShell по
    умолчанию, с помощью командлета Set-Item на диске WSMan:
    измените значение Port в конечном узле прослушивателя.

    Например, следующая команда изменяет порт по умолчанию на 8080.

        set-item wsman:localhostlistenerlistener*port -value 8080

    НАСТРОЙКА УДАЛЕННОГО ВЗАИМОДЕЙСТВИЯ С ИСПОЛЬЗОВАНИЕМ ПРОКСИ-СЕРВЕРА
    ———————————————
        ОШИБКА. Клиенту не удается подключиться к узлу назначения,
        указанному в запросе. Убедитесь, что служба на узле
        назначения работает и принимает запросы.

    Поскольку при удаленном взаимодействии Windows PowerShell
    используется протокол HTTP, также действуют параметры прокси
    HTTP. На предприятиях, применяющих прокси-серверы, пользователи
    не могут напрямую обращаться к удаленному компьютеру
    Windows PowerShell.

    Чтобы решить эту проблему, необходимо использовать в удаленных
    командах параметры прокси-серверов. Доступны следующие параметры.

        —  ProxyAccessType
        —  ProxyAuthentication
        —  ProxyCredential

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

        1. С помощью параметров ProxyAccessType, ProxyAuthentication и
           ProxyCredential командлета New-PSSessionOption создайте
           объект параметра сеанса, содержащий параметры прокси
           -сервера предприятия. Сохраните объект параметра
           в переменной.

        2. Используйте переменную, содержащую объект параметра, в
           качестве значения параметра SessionOption команды
           New-PSSession, Enter-PSSession или Invoke-Command.
          

    Например, следующая команда создает объект параметра сеанса с
    параметрами сеанса прокси, а затем создает с помощью этого
    объекта удаленный сеанс.

        C:PS> $SessionOption = New-PSSessionOption -ProxyAccessTypeIEConfig `
               -ProxyAuthentication Negotiate -ProxyCredential Domain01User01

        C:PS> New-PSSession -ConnectionURI https://www.fabrikam.com

    Дополнительные сведения о командлете New-PSSessionOption см. в
    разделе New-PSSessionOption.

    Чтобы задать эти параметры для всех удаленных команд в текущем
    сеансе, используйте объект параметра, созданный с помощью
    командлета New-PSSessionOption, в качестве значения привилегированной
    переменной $PSSessionOption. Дополнительные сведения о привилегированной
    переменной $PSSessionOption см. в разделе
    about_Preference_Variables.

    Чтобы задать эти параметры для всех удаленных команд во всех
    сеансах Windows PowerShell на локальном компьютере, добавьте
    привилегированную переменную $PSSessionOption в профиль Windows PowerShell.
    Дополнительные сведения о профилях Windows PowerShell см. в
    разделе about_Profiles.
 

    ОБНАРУЖЕНИЕ 32-РАЗРЯДНОГО СЕАНСА НА 64-РАЗРЯДНОМ КОМПЬЮТЕРЕ
    —————————————————
        ОШИБКА. Условие «<имя_средства>» не распознано как имя
        командлета, функции, файла скрипта или выполняемой
        программы. Проверьте правильность написания имени, наличие
        и правильность пути и повторите попытку.

    Если на удаленном компьютере установлена 64-разрядная версия
    Windows, а в удаленной команде используется конфигурация
    32-разрядного сеанса, например Microsoft.PowerShell32, служба
    удаленного управления Windows (WinRM) загружает процесс WOW64,
    и операционная система Windows все ссылки на каталог %Windir%
    System32 автоматически перенаправляет на каталог %windir%
    SysWOW64.

    В результате при попытке загрузить из каталога System32 средства,
    у которых нет аналогов в каталоге SysWow64, например Defrag.exe,
    найти такие средства в каталоге не удается.

    Чтобы определить используемую в сеансе архитектуру процессора, воспользуйтесь
    значением переменной среды PROCESSOR_ARCHITECTURE. Следующая
    команда определяет архитектуру процессора сеанса в переменной
    $s.

        C:PS> $s = new-pssession -computername Server01 -configurationName CustomShell

        C:PS> invoke-command -session $s {$env:PROCESSOR_ARCHITECTURE} x86

    Дополнительные сведения о конфигурациях сеансов см. в разделе about_session_configurations.
   

 УСТРАНЕНИЕ НЕПОЛАДОК ПОЛИТИК И УСТАНОВЛЕННЫХ ПАРАМЕТРОВ
    В этом разделе описаны проблемы удаленного взаимодействия,
    связанные с политиками и параметрами, заданными на локальном и
    удаленном компьютерах.

    Например, следующая команда запускает процесс с политикой
    выполнения RemoteSigned. Изменение политики выполнения распространяется
    только на текущий процесс и не приводит к изменению параметра
    реестра Windows PowerShell ExecutionPolicy.

        set-executionpolicy -scope process -executionpolicy RemoteSigned

    Кроме того, с помощью параметра ExecutionPolicy
    программы PowerShell.exe можно запустить отдельный сеанс с менее
    жесткой политикой выполнения.

        powershell.exe -executionpolicy RemoteSigned

    Дополнительные сведения о командлетах см. в разделах
    Import-PSSession, Export-PSSession и Import-Module.
    Дополнительные сведения о политиках выполнения см. в разделе
    about_Execution_Policies. Чтобы получить дополнительные сведения о параметрах
    справки консоли PowerShell.exe, введите команду «powershell.exe -?».

    ЗАДАНИЕ И ИЗМЕНЕНИЕ КВОТ
    —————————-
        ОШИБКА. Общий объем данных, полученных от удаленного клиента,
        превысил допустимое значение.

    Квоты позволяют защищать локальный компьютер и удаленный компьютер
    от чрезмерного использования ресурсов, как случайного так и
    злонамеренного.

    В базовой конфигурации доступны следующие квоты.

    — Поставщик WS-Management (WSMan:) предоставляет несколько
       параметров квот, например параметры MaxEnvelopeSizeKB и MaxProviderRequests
       в узле WSMan:<имя_компьютера> и параметры MaxConcurrentOperations,
       MaxConcurrentOperationsPerUser и MaxConnections в узле WSMan:<имя_компьютера>Service.
   

    — Локальный компьютер можно защитить с помощью параметров
       MaximumReceivedDataSizePerCommandMB и MaximumReceivedObjectSizeMB командлета
       New-PSSessionOption и привилегированной переменной $PSSessionOption.
   

    — Удаленный компьютер можно защитить, добавив ограничения в
       конфигурации сеанса, например с помощью параметров MaximumReceivedDataSizePerCommandMB
       и MaximumReceivedObjectSizeMB командлета Register-PSSessionConfiguration.

    Если квоты противоречат команде, Windows PowerShell создает оШибку.

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

    Например, следующая команда увеличивает квоту размеров объектов в
    конфигурации сеансов Microsoft.PowerShell на удаленном
    компьютере с 10 МБ (значение по умолчанию) до 11 МБ.

        Set-PSSessionConfiguration -name microsoft.powershell ` -MaximumReceivedObjectSizeMB 11 -Force
       

    Дополнительные сведения о командлете New-PSSsessionOption см. в
    разделе New-PSSessionOption.

    Дополнительные сведения о квотах WS-Management см. в разделе
    справки, посвященном поставщику WS-Management (введите команду
    «get-help WSMan»).

    УСТРАНЕНИЕ ОШИБОК ТАЙМ-АУТА
    ——————————
        ОШИБКА. Службе WS-Management не удается заверить операцию в
        течение времени, указанного в OperationTimeout.

    Тайм-ауты позволяют защищать локальный компьютер и удаленный
    компьютер от чрезмерного использования ресурсов, как случайного
    так и злонамеренного. Если тайм-ауты заданы как на локальном,
    так и на удаленном компьютере, Windows PowerShell использует
    меньшее из заданных значений.

    В базовой конфигурации доступны следующие тайм-ауты.

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

    Если значение тайм-аута делает невозможным заверение операции,
    Windows PowerShell прерывает операцию и создает ошибку.

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

    Например, следующие команды с помощью командлета New-PSSessionOption
    создают объект параметра сеанса со значением OperationTimeout,
    равным 4 минутам (в миллисекундах), а затем создают удаленный сеанс
    с использованием этого объекта параметра сеанса.

        C:PS> $pso = new-pssessionoption -operationtimeout 240000

        C:PS> new-pssession -computername Server01 -sessionOption$pso

    Дополнительные сведения о периодах ожидания WS-Management см. в
    разделе справки, посвященном поставщику WS-Management (введите
    команду «get-help WSMan»).

    Дополнительные сведения о командлете New-PSSsessionOption см. в
    разделе New-PSSessionOption.

 УСТРАНЕНИЕ НЕПОЛАДОК, ПРИ КОТОРЫХ ОБОЛОЧКА ПЕРЕСТАЕТ ОТВЕЧАТЬ

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

    ПРЕРЫВАНИЕ КОМАНДЫ
    —————————
    Некоторые собственные программы Windows, например программы с
    пользовательским интерфейсом, консольные приложения, требующие
    ввода данных, и консольные приложения, использующие консольный
    интерфейс API Win32, некорректно работают с удаленным узлом Windows
    PowerShell. 

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

    Чтобы заверить переставшую отвечать программу, нажмите сочетание
    клавиш CTRL + C. Чтобы увидеть оишбки, которые могли быть
    созданы, введите на локальном узле и в удаленном сеансе «$error».

CМ. ТАКЖЕ
    Интернет-версия: http://go.microsoft.com/fwlink/?LinkID=135188
    about_remote
    about_remote_requirements

PS C:Windowssystem32> Enter-PSSession -ComputerName serv1

Enter-PSSession : Сбой подключения к удаленному серверу serv1. Сообщение об ошибке: Клиенту WinRM не удается обработать запрос. Если применяемая схема проверки подлинности отличается от Kerberos или компьютер клиента не входит в домен, необходимо использовать транспорт HTTPS или добавить компьютер назначения к значениям параметра конфигурации TrustedHosts. Чтобы настроить TrustedHosts, используйте winrm.cmd. Обратите внимание, что в списке TrustedHosts могут находиться компьютеры, не прошедшие проверку подлинности. Чтобы получить дополнительные сведения об этом, выполните следующую команду: winrm help config. Подробности см. в разделе справки «about_Remote_Troubleshooting».

строка:1 знак:1

+ Enter-PSSession -ComputerName serv1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (serv1:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

Some of ours servers (W2K8 R2) were moved to the cloud last week, once done that my powerswhell script started to fail (was working fine before), the exception is thrown on the line where the connection is trying to be established,

$ExSession = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri     "http://$g_strExchangeServer/PowerShell" `
-Credential $Credentials –Authentication Kerberos

With the following message,

[subd.staging.com] Connecting to remote server failed with the following error message : 
**WinRM cannot process the request**. The following error occured while using Kerberos authentication: There are currently no logon servers available to service the logon request.  
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help onfig. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionOpenFailed

this happens only if I try to target our testing domain, if I point the script to our production domain then it works.

The same error is displayed on all the servers that were already moved to cloud.

Notice that all the servers which have not already moved to cloud are able to run the script on both domains without any problem.

I’ve tried the following, but no luck.

//Add the destination computer to the WinRM TrustedHosts configuration setting. 
c:>WinRM set winrm/config/client @{TrustedHosts="stagingserver"} 


//Confirm that WinRM is properly configured.  
c:>Winrm quickconfig  

//Make sure that the remote server allows commands from any machine. 
PS c:>Set-item wsman:localhostclienttrustedhosts -value * 

Using Powershell v2 and WinRM v2

Any comments are welcome.