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