У меня есть внутреннее приложение, использующее установщик Windows. Каждое обновление этого приложения является «крупным обновлением» (другой код продукта, тот же код обновления) и вызывает RemoveExistingProducts. (Фактически это означает, что каждый раз, когда создается новая сборка, вы можете установить ее, просто щелкнув файл MSI, поскольку она удалит старую версию, а затем установит новую версию.)
В настоящее время он развертывается через конфигурацию машины в групповой политике. Любой связанный GPO установит программное обеспечение при следующей загрузке, и это отлично работает.
У меня также есть сервер непрерывной интеграции (TeamCity), который создает и запускает тесты для этого программного обеспечения каждый раз, когда мы фиксируем что-то в системе контроля версий и «закрепляем» для развертывания. Я даже могу скопировать только что созданный файл MSI в общий сетевой ресурс для подготовки к развертыванию.
К сожалению, Я не вижу способа указать объекту групповой политики программно повторно развернуть недавно обновленный файл MSI. как часть моего процесса интеграции.
Если я просто перезаписываю существующий файл MSI и не касаюсь объекта групповой политики, то это изменение не будет замечено машинами, на которых установлена более старая MSI, а новые машины нервничают, когда не могут найти файл MSI с кодом продукта в сценарий, созданный редактором управления групповой политикой. Хорошо, имеет смысл.
Такое же поведение, кажется, произойдет, если я просто перезапишу существующий файл MSI и нажму «Повторно развернуть приложение» в GPME. Опять же, нам кажется, что мы недовольны тем, что пытаемся выполнить повторное развертывание с помощью файла MSI, код пакета которого не совпадает с кодом в сценарии, созданном GPME. Хорошо, имеет смысл.
какой делает работа заключается в том, чтобы щелкнуть правой кнопкой мыши установочный пакет в GPME, нажать «Немедленно удалить», а затем сразу же добавить установочный пакет - в результате создается новый сценарий * .aas, старый пакет удаляется, а новый пакет устанавливается при следующей загрузке. Есть ли способ сделать это с помощью пакетного сценария, который я могу добавить в процесс сборки моего сервера интеграции?
Спасибо!
Ознакомившись с замечаниями Эвана, В итоге я просто написал небольшой пакетный скрипт, который запускается при запуске.. Я также написал небольшую утилиту под названием msicheck который определяет, установлен ли данный пакет MSI. Это удовлетворило мои потребности и намного лучше, чем пролистывать страницы спецификации LDAP! знак равно
У меня было желание сделать что-то похожее, и я уже проводил некоторые исследования по этой теме в прошлом.
Нет открытого API, который я смог бы найти, чтобы делать то, что делает редактор групповой политики для создания этих файлов сценария рекламы приложения (.aas) и соответствующих записей в AD. API групповой политики PowerShell позволяет настраивать параметры на основе реестра, но не параметры для других расширений групповой политики.
Теперь есть ссылка на Расширение протокола установки программного обеспечения групповой политики (спасибо антимонопольному соглашению ЕС!), и я полагаю, вы могли бы попробовать накрутить движок, чтобы выполнять задания самостоятельно. Там есть транзакции LDAP, необходимые для выполнения добавления пакета, и формат файлов .aas. Это выглядит немного устрашающе (хотя и весело) ...
Откровенно говоря, стоит похвалить ваше внимание к деталям тестирования развертывания. Я хочу, чтобы вы писали программное обеспечение, которое используют мои клиенты. Тот факт, что вы используете только установщик Windows, делает вас впереди остальных. То, что вы знаете о развертывании программного обеспечения групповой политики и на самом деле его тестируете, вызывает у меня головокружение! Я бы хотел, чтобы какая-то поддающаяся измерению часть разработчиков была заинтересована настолько, насколько ясно, что это делаете вы.