Хорошо, так что ответ был довольно прост, но все время безуспешно. В принципе, модуль (ы) не существовал в обоих путях Powershell (x86 и x64), поэтому копирование модулей в 32-разрядную среду powershell устранило проблему.

Я не знаком с Дженкинсом, но похоже, что это 32-битный процесс.

Можете ли вы указать местоположение исполняемого файла PowerShell? Если это так, попробуйте использовать этот путь: C:\Windows\SysNative\WindowsPowerShell\v1.0\powershell.exe

Если вы не можете этого сделать, вы можете сделать это в коде в своей «последовательности выполнения» с помощью Invoke-Command:

Invoke-Command -ComputerName . -ScriptBlock { [Environment]::Is64BitProcess }

Весь код в скриптблоке будет запущен в отдельном 64-битном процессе, и результаты будут сериализованы и возвращены.

Пояснения

Пути

В 32-разрядной ОС Windows системная папка C:\Windows\System32. В 64-битной ОС Windows 64-битная системная папка также C:\Windows\System32. Но системная папка для 32-битных процессов при установке 64-битной Windows фактически C:\Windows\SysWOW64.

Для совместимости 32-разрядный процесс на 64-битной ОС будет иметь любые вызовы C:\Windows\System32, прозрачно перенаправленные на C:\Windows\SysWOW64, без ведома процесса.

Чтобы включить 32 битный процесс для ссылки на real System32 на 64-битной ОС, вы можете использовать C:\Windows\SysNative.

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

Типичный сценарий (вы хотите вызвать версия той же битности) проще всего (просто назовите powershell.exe или обратитесь к ней через System32), но она становится волосатой, если вы хотите ссылаться на другую версию .

Invoke-Command Метод

Командлет Invoke-Command позволяет запускать код, как правило, на другом компьютере, но вы можете запускать его на том же компьютере. Это вызовет совершенно отдельный процесс, и любой вывод будет сериализован и отправлен обратно в вызывающий процесс.

Предостережение этому методу заключается в том, что вы должны включить удаленное управление PowerShell на машине через Enable-PSRemoting или Групповая политика (бесстыдный автозапуск).

Профиль по умолчанию (Microsoft.PowerShell), к которому вы подключаетесь на 64-битной машине, будет 64-разрядной версией PowerShell, независимо от того, OS вызывающего абонента.

Кстати, если вы хотите использовать Invoke-Command для подключения к 32-битной версии, вы можете сделать это, явно указав профиль Microsoft.PowerShell32.

Окружающая среда

• Дженкинс в Windows (моя работает как служба)
• плюс Плагин Powershell (для запуска сценариев Powershell как " build steps ")

Дженкинс обычно прибегает к правильной версии powershell.exe. Тем не менее, процесс-исполнитель / ведомый должен работать с 64-разрядной JRE, чтобы PowerShell также мог работать в 64-битном режиме.

Простой проект тестера со следующим сценарием Powershell может отображать вышеупомянутые 32-битные vs 64-битный характер:

$env:Path               # Path will have the right Powershell available
[intptr]::size          # outputs: 4 = 32-bit, 8 = 64-bit
Stop-WebAppPool FOOBAR  # fails when 32-bit, succeeds when 64-bit

Пример вывода консоли (дополнительные прозрачные строки для ясности):

[Powershell Test] $ powershell.exe -NonInteractive -ExecutionPolicy ByPass "& 'C:\Windows\TEMP\hudson123456789.ps1'"

C:\Windows\system32;C:\Windows;C:\Windows\System32\WindowsPowerShell\v1.0\

4

Stop-WebAppPool : Retrieving the COM class factory for component with CLSID 
{688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error: 
80040154 Class not registered (Exception from HRESULT: 0x80040154 
(REGDB_E_CLASSNOTREG)).

At C:\Windows\TEMP\hudson123456789.ps1:7 char:1

Решение

tl; dr ... Установите 64-битную JRE и настройте Jenkins на 64-разрядную версию.

Я использовал шоколадно, чтобы установить довольно недавнюю JRE через «Администратор» PowerShell:

Сначала установите шоколад:

iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

Посмотрел последнюю доступную версию https://chocolatey.org/packages?q=java (шоколадный имеет

Затем установите JRE (используя номер с более высоким номером JRE):

choco install -y javaruntime

Или:

choco install -y jre8

Наконец, я отредактировал конфигурацию jenkins.xml, чтобы он работал с использованием 64-битной JRE вместо встроенной JRE.

Изменено:

<executable>%BASE%\jre\bin\java</executable>

Кому (укажите путь, подходящий для вашего экземпляра):

<executable>C:\Program Files\Java\jre1.8.0_66\bin\java</executable>

Эта должна быть «всегда свежей» символической ссылкой (обрабатываемой системными обновлениями), которая должна позволить вашему экземпляру Jenkins выжить Перезагрузка и Update :

<executable>C:\ProgramData\Oracle\Java\javapath\java.exe</executable>

Затем я перезапустил Дженкинса. Выполнение Powershell разбудилось до 64-бит. Примечание. Я использую один экземпляр Jenkins, который выполняет двойную работу как «сервер» и «подчиненный» одновременно. Для полностью автономных подчиненных устройств я бы предположил, что делать все, чтобы процессы подчиненных агентов в 64-битном режиме приводили к аналогичному успеху.

Полная автоматизация? В соответствии с шоколадной документацией пакета «jre8» с использованием переключателей командной строки даже можно принудительно фиксировать пути назначения для JRE и исключать 32-разрядные и / или 64-разрядные версии, если необходимы полностью автоматические неинтерактивные шаги. https://chocolatey.org/packages/jre8