Установка программ через powershell на удаленный компьютер

Обновлено: 04.07.2024

используйте что-то вроде

foreach($сервер в $серверах)

invoke-command -$server -script

$InstallString = '"\\servershare\Office 2010\setup.exe" /adminfile Updates/OfficeSetup.MSP /config ProPlus.WW/config.xml"'
([ WMICLASS ] "\\$server \ROOT\CIMV2:Win32_Process" ). Создать ( $InstallString )

не должно ли быть что-то в папке \\servershare\

вам нужно будет указать и это, как я сделал с $server

Обычно я использую start-process вместо WMI

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

Надеюсь, это поможет! Джейсон

Джейсон... приближаюсь. Теперь я получаю следующую ошибку, хотя я являюсь администратором на компьютере:

Этот метод работает как система? или мои учетные данные?

Пожалуйста, отметьте мой пост как полезный, ответ или еще лучше. обе! :) Спасибо!

Извините, я был глуп! Сначала вам нужно будет скопировать пакет локально, после того как вы начнете удаленное взаимодействие, вы больше не сможете использовать UNC.

Пункт назначения может быть где угодно на сервере, я использую временное, но это все, что вам нравится. Также мне нравится использовать $env:windir\temp в случае, если диск ОС не работает.

Надеюсь, это поможет! Джейсон

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

Надеюсь, это поможет! Джейсон

Локально мой исходный сценарий работает просто великолепно. Я собираюсь скопировать все 700 МБ на компьютер и посмотреть, сработает ли это.

Пожалуйста, отметьте мой пост как полезный, ответ или еще лучше. обе! :) Спасибо!

Снова ничего не происходит. Я запускаю новый скрипт и не получаю никаких ошибок, но процесс никогда не начинает показывать его установку. :)

Я скопировал файлы в удаленную систему перед запуском скрипта.

Пожалуйста, отметьте мой пост как полезный, ответ или еще лучше. обе! :) Спасибо!

Можете ли вы попробовать добавить параметр ожидания в конце? Установка Office займет некоторое время:

Можете ли вы проверить правильность добавления аргументов?

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

Надеюсь, это поможет! Джейсон

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

Пожалуйста, отметьте мой пост как полезный, ответ или еще лучше. обе! :) Спасибо!

Это отстой, к сожалению, теперь вам нужно устранить неполадки с установщиком, командная строка, которую я вам дал, запустит процесс. Если setup.exe удалит файл журнала, сделайте это, в противном случае используйте procmon, чтобы увидеть, где он зависает. Procmon доступен в наборе инструментов Sysinternals.

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

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

Надеюсь, это поможет! Джейсон

Просто проверяю, были ли предложения полезными. Сообщите нам, если вам нужна дополнительная помощь.

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

Каталея Ли
Поддержка сообщества TechNet

Отличные новости. Следующее работает как шарм! Файлы установки программного обеспечения должны быть локальными. Я не смог заставить скрипт "Invoke-Command" работать на меня, но Джейсон, ты мне очень помог. Спасибо за все ваши знания.

Пожалуйста, отметьте мой пост как полезный, ответ или еще лучше. обе! :) Спасибо!

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

и присвоить ему переменную $InstallString?

Это может помешать созданию локальной копии на целевой машине.

Как вести журнал после завершения или сбоя?

S C:\Scripts\software> C:\Scripts\software\rinstall.ps1

__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 2
__DERIVATION : < >
__SERVER:
__NAMESPACE:
__PATH:
ProcessId:
ReturnValue: 8
PSComputerName:

Что не так с вышеперечисленным, программное обеспечение не установлено?

Посмотрите на этот, здесь упоминается как минимум 8 методов

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

<р>1. PSRemoting должен быть включен на обеих машинах с помощью этих 3 команд

Enable-PSRemoting -Force
Set-Item wsman:\localhost\client\trustedhosts * -Force
Restart-Service WinRM

Ранее я рассказывал, как установить MSI без вывода сообщений. Следующее, что администратор хочет сделать, это установить его на удаленной системе. Это логичный следующий шаг. Это не всегда самая простая задача для новичка в PowerShell.

Чтобы эти примеры были чище, я собираюсь использовать воображаемый установщик, который не является MSI, но подход тот же. Основной способ выполнения удаленных команд — удаленное взаимодействие PowerShell с использованием командлетов Enter-PSSession или Invoke-Command. Я предполагаю, что в вашей среде уже работает PSRemoting. Если вам нужна помощь, обратитесь к электронной книге Secrets of PowerShell Remoting.

Я также использую Invoke-Command во всех своих примерах, потому что это то, что вы могли бы использовать в своих скриптах.

Если у вас уже есть файл в удаленной системе, мы можем запустить его с помощью Invoke-Command .

Есть две важные детали, о которых нужно знать сразу.

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

Вам нужно будет вызвать Start-Process -Wait, если у вас возникла эта проблема.

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

В большинстве случаев, если вы запускаете установщики в удаленной системе, у вас есть установщик на сетевом ресурсе (путь UNC). На первый взгляд, это должно работать:

Это может быть источником многих головных болей. В идеале вы хотите запустить установщик с пути UNC, но обнаруживаете, что он не работает.

Попытка скопировать файл внутри удаленной команды приводит к той же проблеме.

Все говорит вам, что файл либо не существует, либо у вас нет прав доступа к файлу. Это своего рода ложное сообщение, потому что оно существует, и у вас есть права доступа к файлам. Проблема в том, что ваш удаленный сеанс не имеет таких прав.

Проблема двойного перехода

Это проблема двойного перехода. Учетные данные, используемые для аутентификации на server01, не могут использоваться server01 для аутентификации на файловом сервере. Или любые другие сетевые ресурсы в этом отношении. Этот второй переход — это все, что требует аутентификации, но не в первой удаленной системе.

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

Я буду использовать эти переменные-заполнители в остальных примерах.

Предварительно скопировать файл, используя общий доступ администратора

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

Предварительное копирование с помощью PSSession (PS 5.0)

В Powershell 5.0 добавлена новая функция, позволяющая копировать файлы с помощью PSSession. Итак, создайте PSSession и скопируйте файл поверх него, используя приведенный ниже синтаксис. Отличительной особенностью этого подхода является то, что с помощью Powershell 5.0 вы можете создать сеанс PSSession для гостевой виртуальной машины через шину виртуальной машины (а не по сети) и по-прежнему можете скопировать в нее файл.

Хотя вы можете запускать Invoke-Command на нескольких компьютерах одновременно, имейте в виду, что Copy-Item -ToSession работает только в одном сеансе.

Копирование PowerCLI-VMGuest

Вы можете использовать PowerCli для копирования файлов в гостевую систему vSphere с помощью CmdLet Copy-VMGuest.

Повторная аутентификация из сеанса

На самом деле легко повторно аутентифицироваться в удаленном сеансе. Создайте объект учетных данных и передайте его в Invoke-Command. Затем используйте эти учетные данные для создания New-PSDrive. Даже если вы не используете это новое сопоставление дисков, оно установит аутентификацию для вашего пути UNC для работы.

В этом примере я использовал два приема, на которые нужно обратить внимание, если вы их раньше не видели. Во-первых, я помещаю аргументы в хэш-таблицу и использую оператор @ для передачи их в CmdLet. Второй — это область $using: для получения переменной из моего локального сеанса в этот удаленный блок сценария. Я комбинирую их оба, когда выполняю эту команду New-PSDrive @using:psdrive .

Я не могу говорить о проблеме двойного перехода, не упомянув CredSSP. Наиболее распространенное решение, которое вы найдете в Интернете, если погуглите о проблеме двойного перехода, — это включить CredSSP. Даже у Джеффри Сновера есть старая статья, в которой он рекомендуется.Сообщество в целом отошло от этого решения, потому что оно подвергает риску вашу среду. Проблема с CredSSP заключается в том, что ваши учетные данные администратора кэшируются в удаленной системе таким образом, что злоумышленники могут легко получить к ним доступ.

Подробнее см. в отличной статье: Случайный саботаж: остерегайтесь CredSSP

Ограниченное делегирование Kerberos на основе ресурсов

Но есть лучшее решение — ограниченное делегирование Kerberos на основе ресурсов. ограниченное делегирование в Server 2012 представляет концепцию управления делегированием билетов службы с использованием дескриптора безопасности, а не списка разрешений SPN. Это изменение упрощает делегирование, позволяя ресурсу определять, какие участники безопасности могут запрашивать билеты от имени другого пользователя. Дополнительные сведения см. в разделе Безопасное решение двойного перехода через PowerShell Remoting Kerberos.

Вот фрагмент кода, показывающий, как это работает.

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

Желаемая конфигурация состояния

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

Решение о том, как установить установщик на целевую систему, является сложной задачей при работе с DSC. Если вы настроили сертификаты, вы можете предоставить учетные данные для общего доступа к файлам для прямого копирования файлов. Или вы можете создать собственный ресурс DSC и поместить в него файлы. Целевая система загрузит его с опрашивающего сервера, как и другие ресурсы.

Вы можете комбинировать это с одной из следующих идей.

Загрузка из Интернета

Перед установкой файл можно извлечь с внешнего или внутреннего веб-сервера.

Установить с помощью управления пакетами

В Windows реализовано управление пакетами, которое можно использовать для установки пакетов из сетевых репозиториев.

Установить с помощью Chocholatey

Внутренний репозиторий

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

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

Если бы у вас был вопрос "Как мне устанавливать программное обеспечение?" тогда ваше внимание должно переключиться на управление пакетами. Это все еще новинка для экосистемы Windows, но именно в этом направлении движется Windows.

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

К приложениям, предназначенным для использования установщика Windows, можно получить доступ через класс Win32_Product WMI, но не все используемые сегодня приложения используют установщик Windows. Приложения, использующие альтернативные процедуры установки, обычно не управляются установщиком Windows. Конкретные методы работы с этими приложениями зависят от программы установки и решений, принятых разработчиком приложения. Например, приложениями, установленными путем копирования файлов в папку на компьютере, обычно нельзя управлять с помощью обсуждаемых здесь методов. Вы можете управлять этими приложениями как файлами и папками, используя приемы, описанные в разделе Работа с файлами и папками.

Класс Win32_Product не оптимизирован для запросов. Запросы, использующие фильтры с подстановочными знаками, заставляют WMI использовать поставщика MSI для перечисления всех установленных продуктов, а затем последовательно анализировать полный список для обработки фильтра. Это также инициирует проверку согласованности установленных пакетов, проверку и исправление установки. Проверка является медленным процессом и может привести к ошибкам в журналах событий. Для получения дополнительной информации см. статью базы знаний 974524.

Список приложений установщика Windows

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

Чтобы отобразить все свойства объекта Win32_Product, используйте параметр Properties командлетов форматирования, таких как командлет Format-List, со значением * (все).

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

Список всех удаляемых приложений

Поскольку большинство стандартных приложений регистрируют деинсталлятор в Windows, мы можем работать с ними локально, найдя их в реестре Windows. Не существует гарантированного способа найти каждое приложение в системе. Однако все программы, списки которых отображаются в разделе «Установка и удаление программ», можно найти в следующем разделе реестра:

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

Теперь у нас есть диск под названием «Удалить:», который можно использовать для быстрого и удобного поиска установленных приложений. Мы можем найти количество установленных приложений, подсчитав количество ключей реестра на диске Uninstall: PowerShell:

Мы можем продолжить поиск в этом списке приложений, используя различные методы, начиная с Get-ChildItem . Чтобы получить список приложений и сохранить их в переменной $UninstallableApplications, используйте следующую команду:

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

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

Уникальность значений DisplayName не гарантируется.

Установка приложений

Вы можете использовать класс Win32_Product для удаленной или локальной установки пакетов установщика Windows.

Чтобы установить приложение, необходимо запустить PowerShell с параметром "Запуск от имени администратора".

При удаленной установке используйте сетевой путь универсального соглашения об именах (UNC), чтобы указать путь к пакету .msi, поскольку подсистема WMI не понимает пути PowerShell. Например, чтобы установить пакет NewPackage.msi, расположенный в сетевой папке \\AppServ\dsp на удаленном компьютере PC01, введите в командной строке PowerShell следующую команду:

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

Удаление приложений

Удаление пакета установщика Windows с помощью PowerShell работает примерно так же, как установка пакета. Вот пример, который выбирает пакет для удаления на основе его имени; в некоторых случаях может быть проще фильтровать с помощью идентификационного номера:

Удалить другие приложения не так просто, даже если это делается локально. Мы можем найти строки удаления из командной строки для этих приложений, извлекая свойство UninstallString. Этот метод работает для приложений установщика Windows и для старых программ, появляющихся в разделе «Удалить»:

Вы можете отфильтровать вывод по отображаемому имени, если хотите:

Однако эти строки нельзя использовать напрямую из командной строки PowerShell без внесения некоторых изменений.

Обновление приложений установщика Windows

Чтобы обновить приложение, необходимо знать имя приложения и путь к пакету обновления приложения. С помощью этой информации вы можете обновить приложение с помощью одной команды PowerShell:

Если вы являетесь ИТ-администратором, весьма вероятно, что вам приходилось устанавливать программное обеспечение для других. В наши дни управление терминалами — это большой бизнес, а обслуживание программного обеспечения на сотнях или сотнях компьютеров — обычное дело в крупных учреждениях. Несмотря на это, крупный бизнес обычно означает большие деньги.

Что делать, если вы работаете в организации с небольшим бюджетом или без него? Может быть, вы или кто-то из вашей команды научились использовать PowerShell для автоматизации различных задач? Затем может оказаться полезным использование PowerShell для одновременного управления программным обеспечением на многих конечных точках.

Язык сценариев PowerShell — это мощный гибкий язык, который, кажется, может обрабатывать практически все в среде Windows. Работать с программным обеспечением на удаленных компьютерах проще простого!!

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

Где зарегистрировано программное обеспечение

Термин "программное обеспечение" является расплывчатым определением, особенно в Windows. При установке программного пакета разработчик программного обеспечения полностью определяет, какие изменения вносятся в компьютер пользователя. Установщики программного обеспечения копируют файлы, создают ключи реестра, добавляют экземпляры WMI и многое другое. Ключ к созданию точного отчета об инвентаризации программного обеспечения, независимо от метода, заключается в том, чтобы сначала понять, на что обращать внимание.

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

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

HKEY_LOCAL_MACHINE (32-битный маршрут)
HKEY_LOCAL_MACHINE6432Node (64-битный маршрут)
HKEY_CURRENT_USER (для каждого профиля пользователя)

Каждый вторичный ключ реестра в этих первичных ключах обычно носит имя глобального уникального идентификатора (GUID) программного обеспечения. Внутри этого ключа вы можете найти значения реестра для названия программного обеспечения, версии и т. д.

Требования к удаленному ПК

Чтобы использовать код, описанный в этом посте, я предполагаю, что на удаленных компьютерах включено и доступно PowerShell Remoting. Вы можете протестировать PowerShell Remoting, выполнив простую команду, например Invoke-Command -ComputerName REMOTEPCNAME -ScriptBlock . Если это не удастся, остальная информация, описанная в этом посте, также не будет работать.

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

Сначала в административной консоли PowerShell загрузите и установите модуль PSSoftware PowerShell из галереи PowerShell, запустив Install-Module PSSoftware .

После установки модуля проверьте доступные команды, запустив Get-Command -Module PSSoftware -Noun Software . Вы увидите некоторые команды, такие как Get-InstalledSoftware, Install-Software и Remove-Software. Эти команды являются основными функциями для управления программным обеспечением. В этом посте я сосредоточусь на функции Get-InstalledSoftware.

Попробуйте запустить команду Get-InstalledSoftware сначала локально без параметров. Вы сразу же увидите много различных программных пакетов.

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

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

Вы можете предпочесть видеть не все установленное программное обеспечение, а только программное обеспечение, соответствующее определенному наименованию. Вы можете отфильтровать эту информацию с помощью командлета Where-Object. В следующем примере выполняется поиск всего программного обеспечения, которое начинается с SQL на удаленном компьютере.

Обзор

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

Использование бесплатных модулей PowerShell от сообщества — отличный способ создавать недорогие отчеты об изобретателях программного обеспечения.

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