Проблемы с обновлением MSI с помощью объекта групповой политики (сбои в перезаписывании/удалении)

Question

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

Проблема: наша компания упаковывает приложение в MSI. Этот MSI, когда он установлен вне какого-либо объекта групповой политики, обновляется, блокирует попытки понизить (или перейти от более высокой версии к более низкой версии) и никогда не имеет проблем с удалением предыдущих версий приложения независимо от того, как давно эти версии были созданы/установлены. Например, мы можем установить версию 1.2.3, а затем установить версию 2.3.4, и приложение будет правильно установлено без проблем. Однако мы работаем с клиентом, который использует GPO для развертывания нашего приложения на сотни компьютеров. Каждый раз, когда мы предоставляем обновленную версию приложения, указывалось следующее:

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

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

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

Мой вопрос: есть ли техническая проблема с тем, как установка обрабатывается частично через объект групповой политики и частично снаружи? Должен ли GPO быть ответственным за весь жизненный цикл приложения? ИЛИ разумно ли ожидать, что приложение будет обновляться как на машинах, где исходная версия была установлена ​​вручную (вне объекта групповой политики), и когда она была установлена ​​изначально из объекта групповой политики?

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

Мы будем рады приветствовать любые решения, ссылки на техническую документацию, которые официально проливают свет на правильное управление или ожидания здесь, или ссылки на информацию. Наши исследования показывают, что «лучше всего» управлять всем жизненным циклом приложений внутри объекта групповой политики, но я пока не смог определить, что это необходимо на 100%.

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

Answer 1

Если вы закончили с двумя версиями, установленными на панели управления, то при прочих равных условиях наиболее вероятным объяснением является то, что вы обновили установку для каждого пользователя с помощью установки (или наоборот). В мире GPO, который связан с назначением его пользователю или компьютеру, что-то в этом роде. Это легко проверить, получив подробный журнал и проверив действия FindRelatedProducts, указав, что другой продукт найден, но в другом контексте.

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

Я считаю, что GPO подавляет пользовательский интерфейс в большинстве случаев, а пользовательский интерфейс (или последовательность пользовательских интерфейсов) иногда находится там, где установлен пользователь/на машину. Это может быть что-то другое, что могло бы вызвать его, в зависимости от того, как публичный объект публичного доступа публикует на компьютере или пользователе.