使用WiX工具集升级服务时，请勿覆盖服务帐户 [英] Don't override the service account when upgrading a service using WiX toolset

问题描述

我正在尝试设置一个WiX安装程序，该安装程序安装Windows服务并处理升级和更新.

I am trying to setup a WiX installer that install a windows service and handles upgrades and updates.

安装程序的工作方式像超级按钮，用户使用 LocalSystem 帐户安装服务，然后服务工程师必须为该服务分配域帐户.

The installer works like a charm, the user installs the service under the LocalSystem account then a service engineer has to assign a domain account to that service.

这是我的服务安装程序组件:

Here is my service installer component:

  <Component Id="my_exe_Component">
    <File Id="Myexe" Source="$(var.Myproject.TargetPath)" KeyPath="yes" />
    <ServiceInstall Id="my_exe" Type="ownProcess" Vital="no" Name="NME" DisplayName="My intaller" Description="My installer description" Start="auto" Account="LocalSystem" ErrorControl="ignore" Interactive="no">
      <util:ServiceConfig
        FirstFailureActionType="restart"
        SecondFailureActionType="restart"
        ThirdFailureActionType="restart"
        RestartServiceDelayInSeconds="0"
        ResetPeriodInDays="1"/>
    </ServiceInstall>
    <ServiceControl Id="my_exe" Stop="both" Remove="uninstall" Name="NME" Wait="yes" />
  </Component>

当我执行安装程序升级时，设置为服务的帐户会被覆盖回 LocalSystem 帐户，执行升级时如何保留设置为我的服务的帐户?

When I perform an upgrade to the installer, the account set to the service get overwritten back to the LocalSystem account, how do I persist the account set to my service when performing an upgrade?

我的升级子句设置如下:

My upgrade clause is set like so:

 <MajorUpgrade AllowSameVersionUpgrades="yes" AllowDowngrades="no" DowngradeErrorMessage="A newer version of [ProductName] is already installed." Schedule="afterInstallExecute" />

任何帮助将不胜感激.

推荐答案

这是真理问题的经典来源. MSI希望成为真理的源头，并且在代码中没有任何内容可以说明这种情况.它认为该服务应为LocalSystem，因此希望对其进行修复. (这不只是升级，维修也可以做同样的事情.)

This is a classic source of truth problem. MSI wants to be the source of truth and doesn't have anything in it's code to account for this scenario. It thinks the service should be LocalSystem and so it wants to fix it. ( This isn't just upgrades ... a repair will do the same thing. )

那该怎么办?

选项A:

将用户名/密码配置导入MSI. UI工作，凭据验证和凭据的加密将其持久保存在计算机上的某个位置，以便后续事务可以解密和重用凭据.

Bring username /password configuration into the MSI. UI work, credential validation and encryption of the creds persisting it on the machine somewhere so that subsequent transactions can decrypt and reuse the credentials.

注意:有风险.这些凭据可以进行逆向工程..尽管我得到了消息，但是Windows LSA机密和应用程序池标识等也是如此.

Note: Risk. The creds can be reverse engineered.. I got news though... so can windows LSA secrets and Application Pool Identities and such.

选项B:

使用自定义操作创建服务.这样，您可以进行逻辑处理以在后续交易中不接触服务.

Use custom actions to create the service. This way you can do logic to not touch the service during subsequent transactions.

选项C:

在CreateServices标准操作上放置条件表达式，使其仅在首次安装时适用，而不适用于重大升级.

Put conditional expressions on CreateServices standard action to only apply during first time installation and not major upgrades.

风险:如果您更改了有关服务的其他任何内容，则升级将不会部署该服务，因为该服务已被绕过.此外，这不仅适用于MSI，还适用于您的MSI中的所有服务.

Risk: If you ever change anything else about the service it won't get deployed by an upgrade because it's been bypassed. Also this is for all services in your MSI not just this one.

选项D:

以内置服务帐户身份运行，并使用活动目录权限向该计算机对象授予对其连接的对象的权限.

Embrace running as a built in service account and use active directory permissions to grant that computer object rights to whatever it connects to.

选项E:

如果用户在安装后应用了凭据，那么他们只需在升级后再做一次即可.他们可以处理.

If the user applies creds after install, then they can simply do it again after upgrade. They can deal with it.

这篇关于使用WiX工具集升级服务时，请勿覆盖服务帐户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！