Установка msi через powershell

Обновлено: 20.11.2024

Сценарий Powershell, который можно использовать для установки MSI-файла Windows или установочного EXE-файла без загрузки, выбора и нажатия клавиш. Скрипт загружается с удаленного сервера и устанавливается.

Запустите powershell от имени администратора и вставьте, чтобы установить 7zip:

Проверьте каждую папку на наличие доступных приложений и версий.

Для Windows 10 версии 2018+ или Windows Server 2018+
Один лайнер или легко скопированный в консоль powershell, нет необходимости скачивать-импортировать модули.
Сохранить загрузку в $env:TEMP
Название такое же, как у пакетов Chocolatey. К сожалению, Chocolatey не имеет открытого исходного кода. Обсуждение открытого исходного кода было полностью удалено владельцем Chocolatey. Без shimgen и с учетом ограничения PATH в Windows нет хорошей возможности иметь менеджер пакетов.
по умолчанию принимаются настройки, отключающие телеметрию

Через SSH на удаленном компьютере

Проверьте, установлено ли оно уже

По реестру, по местоположению файла, по запущенному процессу или по пути.

Надежное хранилище с контрольными суммами

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

Обнаружить, что у нас 32-разрядная версия, и загрузить эту версию.

Можно заходить в $env:TEMP для каждой установки и проверять установленные файлы. Как поддерживать отчет об ошибках в нужном масштабе?

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

Возможно, модуль PowerShell был бы хорошей идеей.

Возможности APPX, MSIX и Windows уже легко установить с помощью PowerShell. Так что все еще можете предоставить их здесь для унифицированного внешнего вида. И они работают из PowerShell, но не работают из pwsh (ядро Powershell), поэтому можно попытаться обернуть что-то, работающее из pwsh . Таким образом, pwsh может вызывать powershell при необходимости.

Список приложений и версий

Доступ к git и список папок с версией. Автоматизируйте создание списка при каждом нажатии.

Зависимости? Добавление элементов в PATH без раздувания PATH?

О нас

Это простой сценарий Powershell, который можно использовать для установки файла Windows .MSI (программного обеспечения) без выбора и нажатия клавиш. Он загружается с удаленного сервера и устанавливается. В нашем случае мы будем использовать распаковщик архивов 7-zip.

Я изо всех сил пытаюсь понять, как запустить файл msi без вывода сообщений из текущей папки. Мой план состоит в том, чтобы отправить сценарий через SCCM. По какой-то причине всякий раз, когда я запускаю сценарий через ISE, я получаю только диалоговое окно команды MSI.

Start-Process Msiexec.exe -ArgumentList '/i $PSScriptRoot\Firefox Setup 73.0.1.msi /qn'

Вот команда, которую я использую.

Start-Process msiexec.exe -argumentlist "/i "$pathtomsi" /quiet" -wait

Обязательно поместите ` внутри ".

К вашему сведению, Reddit съел вашу обратную связь.

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

Кроме того, в MSI есть пробелы, вам нужно БОЛЬШЕ кавычек вокруг него. Я бы сначала потренировался с реальной командой, прежде чем вводить ее в PS.

У Кевина Маркетта есть отличная запись в блоге о запуске MSI в PowerShell, которую я очень рекомендую. (Похоже, вы уже следуете этому совету, но другим читателям это может быть интересно)

Еще одна вещь, о которой следует помнить, это то, что вам нужно создать строку PowerShell, которая будет представлять нужную строку аргумента в MSI.

Скажем, $PSScriptRoot — это C:\here , и вы хотите, чтобы ваш окончательный вызов msiexec выглядел так:

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

Обратите внимание, что во втором аргументе мы использовали обе кавычки; первый набор предназначен для PowerShell, а второй — для определения пути как единого аргумента для самого msiexec.exe. Также обратите внимание, что когда вы находитесь в строке одного типа (в одинарных или двойных кавычках), кавычки другого типа являются обычными символами с точки зрения PowerShell. Таким образом, строка в двойных кавычках с одинарными кавычками по-прежнему будет раскрывать переменные:

Последняя строка, в которую будет расширена эта строка PowerShell в двойных кавычках:

Итак, вы можете видеть, что это 3 аргумента, причем пробелы второго заключены в кавычки.Точно так же, как вы бы назвали это в PowerShell или CMD, если бы делали это напрямую.

Если это немного сбивает с толку, мы можем немного разбить его:

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

Надеюсь, это поможет. Также стоит помнить, что пути слишком часто содержат пробелы (например, мой домашний каталог — C:\Users\Robert Holt\), поэтому действительно рекомендуется рассматривать все пути так, как будто в них есть пробелы.

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

Что такое MSI?

Установщики Microsoft, также известные как установщики MSI, представляют собой компонент операционной системы Windows, используемый для установки, обслуживания и удаления программного обеспечения. До введения Магазина Windows и «Современных» приложений с выпуском Windows 8 Microsoft поощряла сторонних поставщиков использовать установщики MSI для обеспечения согласованности внутренней базы данных установленных продуктов операционной системы Windows. К сожалению, поскольку это не было обязательно, многие сторонние поставщики использовали другие установщики, продвигая необходимость установки на прошлой неделе.

Каковы преимущества?

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

Стандартные коды выхода. Коды выхода для всех установок MSI хорошо задокументированы и обычно не меняются. Их можно найти здесь.
Стандартизированное управление состоянием. Одной из самых сложных частей управления программным обеспечением в любой среде является определение его состояния на любой заданной конечной точке. Поскольку все установки MSI создают экземпляр класса Win32_Product, определить наличие приложения так же просто, как написать одну строку в PowerShell.
Коды продуктов. Все установки MSI имеют уникальный идентификатор GUID, который можно использовать для идентификации конкретных установок. Этот идентификатор GUID обычно называют кодом продукта.
Транзакционные операции. Все операции MSI являются транзакционными. Это означает, что для каждого действия, предпринимаемого установщиком MSI, есть эквивалентное действие отката. Всякий раз, когда возникает ошибка, установщик MSI отменяет все изменения, которые он уже сделал, предотвращая частичную установку и поврежденные состояния.

Итак, мы знаем, что MSI — это прекрасно, но как с ними работать? Сценарий этой недели будет состоять из нескольких небольших примеров, демонстрирующих, как управлять установками MSI. Давайте начнем!

Определение состояния установки

Определение состояния установки приложения, установленного с помощью MSI, так же просто, как чтение из класса WMI, в частности Win32_Product.

Свойство IdentifyingNumber совпадает с кодом продукта, о котором мы упоминали ранее. Поскольку это уникально для установки, мы хотим использовать его для выполнения любых других задач, которые нам могут понадобиться. Таким образом, мы также собираемся использовать его для нашего сценария оценки. Если вы планируете использовать это в пользовательской политике Automox, не забудьте выйти с 1 или 0, в зависимости от необходимости исправления.

Установка с помощью MSI

Теперь, когда у нас есть сценарий оценки, мы можем приступить к исправлению. Хорошая новость заключается в том, что это тоже небольшое усилие. Первый шаг — получить файл MSI у поставщика. Используя настраиваемые политики Automox, вы можете загрузить этот файл, который будет распространен на конечные точки, требующие исправления. Этот файл будет помещен в ту же папку, из которой будет выполняться ваш сценарий исправления. При ссылке на файл вы можете использовать переменную PSScriptRoot, как показано ниже:

Вы заметите, что в назначении переменной $path есть несколько дополнительных кавычек. По сути, мы заключаем значение переменной $path в кавычки, чтобы предотвратить любые ошибки, которые могут возникнуть из-за пробелов в пути или имени файла. Как вы уже догадались, символ ` в PowerShell рассматривается как escape-символ:

Еще один момент, на который следует обратить внимание, — это аргументы, которые мы используем в вызове Start-Process. При установке продуктов MSI через командную строку msiexec — ваш лучший друг. Этот инструмент упрощает большинство операций MSI и поддерживает различные параметры командной строки, на которые вы можете ссылаться здесь. В нашем случае мы использовали только два:

\I — устанавливает или настраивает продукт
\qn — указывает, что установка будет «тихой» без интерфейса.
\L*v - Кости. Хотя это не используется в этом примере, все же стоит отметить. Вы можете использовать этот переключатель, чтобы установщик создал подробный журнал установки в указанном месте, что может упростить устранение неполадок при неудачной установке в будущем.

После завершения установки сценарий завершится со статусом 0, указывающим Automox на успешное исправление. Важно обернуть исполняемый код в блок try-catch и вернуть 1 в блоке catch на случай возникновения ошибок.

Удаление с помощью MSI

Для удаления продукта MSI обязательно измените приведенный выше сценарий оценки, чтобы он возвращал 1 вместо 0 при обнаружении нужного приложения. Это сообщит Automox о необходимости исправления при наличии приложения. Затем вы можете использовать тот же код в сценарии исправления, чтобы получить желаемый код продукта. В этом случае удалить продукт так же просто, как передать код продукта в msiexec с ключом /X, который указывает на удаление продукта. Как и в предыдущем сценарии исправления, вы также хотите вернуть 1 или 0 в качестве кода выхода сценария, чтобы сообщить Automox, была ли операция успешной.

На следующей неделе

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

Об Automox

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

Облачный и доступный по всему миру Automox обеспечивает управление ОС и сторонними исправлениями, настройки безопасности и пользовательские сценарии в Windows, Mac и Linux с единой интуитивно понятной консоли. ИТ-специалисты и специалисты по безопасности могут быстро получить контроль над локальными, удаленными и виртуальными конечными точками и поделиться ими без необходимости развертывания дорогостоящей инфраструктуры.

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

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

Если у меня есть выбор (и в этом есть смысл), я всегда предпочту GPO любому другому решению, потому что оно встроено в Active Directory и не требует установки, изучения и обслуживания дополнительных инструментов управления.

Одним из основных преимуществ установщиков MSI является то, что в 99% случаев вы можете просто использовать параметр «Установка программного обеспечения» в GPO, а GPO позаботится об автоматической установке. Кроме того, если более новая версия установщика когда-либо появится в списке, вы можете просто связать более новую версию установщика, и GPO позаботится об обновлении текущих установок.

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

Как узнать, можно ли установить MSI без вывода сообщений с помощью GPO

Мы собираемся использовать инструмент MsiExec (установщик Windows), мой файл установщика называется: GoogleChromeStandaloneEnterprise64.msi

И синтаксис командной строки:

Таким образом, моя команда выглядит так:

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

Настройка объекта групповой политики

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

Итак, я собираюсь скопировать файл установщика в свою папку NETLOGON:

И создайте новый объект групповой политики:

Чтобы создать объект групповой политики для установщика:

После открытия управления групповыми политиками щелкните правой кнопкой мыши корень/или подразделение и выберите создание нового объекта групповой политики и его связывание.

Дайте ему подходящее имя, а затем разверните настройки:

Компьютер > Политики > Параметры ПО > Установка ПО. Затем щелкните правой кнопкой мыши > Создать > Пакет.

Укажите его на ваш установочный файл — важно, чтобы вы указали через сетевую папку; таким образом, либо \DomainName\someshare, либо \ComputerName\share

Выберите «Назначить» и работа будет выполнена.

Иногда установщик программного обеспечения требует предоставления настраиваемых переключателей, и единственный способ выполнить установку — использовать настраиваемый сценарий. К счастью, в GPO у нас есть возможность запуска/выключения сценариев, которые будут выполняться каждый раз, когда компьютеры загружаются/выключаются.

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

Проблема с такими установщиками заключается в том, что они часто не сообщают, какие переключатели требуются, что значительно усложняет задачу. Таким образом, на этом этапе вы можете быть вынуждены либо проверить веб-сайт/руководство разработчика, либо даже связаться с ним, если поддерживается автоматическая установка. Вы также можете ознакомиться с разделом советов ниже, который может подсказать вам решение.

Давайте возьмем в качестве примера программу установки Airtame — она основана на MSI, однако требует специальных переключателей для автоматической установки. Скорее всего, поставщик программного обеспечения предоставил руководство и необходимые переключатели:

Самый быстрый способ проверить сценарий без его написания — запустить в оболочке.

Вы можете открыть оболочку, нажав и удерживая клавишу SHIFT, затем щелкните правой кнопкой мыши в окне и выберите «Открыть оболочку Windows здесь»

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

GPO со сценарием запуска

Я поместил программу установки в NETLOGON как предыдущую программу установки.

Создайте новый объект групповой политики и настройте его следующим образом:

Разверните раздел Конфигурация компьютера > Политики > Параметры Windows > Сценарии > Автозагрузка

В свойствах запуска нажмите «Показать файлы…» и создайте там новый текстовый файл, изменив его расширение на BAT (я настроил на всех своих машинах отображение расширений файлов — таким образом я могу изменить расширения файлов). как изменение имени файла), откройте его и вставьте приведенный ниже скрипт:

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

Вторая строка — та же команда с яичками минуту назад

Последняя строка вернет путь к исходному местоположению — на самом деле это не нужно, но приятно иметь его.

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

Вернувшись к окну «Свойства запуска», на этот раз нажмите «Добавить», и если вы не видите свой сценарий, вставьте путь к окну — теперь вы можете указать на только что созданный файл сценария.

Перейдите на свой тестовый компьютер, запустите «gpupdate /force» из оболочки и перезагрузите компьютер — убедитесь, что программное обеспечение установлено.

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