从管理员配置文件在当前用户配置文件上创建文件夹和文件

Question

我们的客户端仅允许在以管理员身份登录时安装应用程序。必须为机器的当前用户安装需要安装的应用程序。该应用程序安装正常，当我需要在用户的 appdata/user 配置文件文件夹中放置一个配置文件时，我的问题就出现了。由于这是他们想要的地方，目前配置正在安装时被删除到管理员配置文件中。我如何解决这个问题，有没有办法让我检查安装是否有其他配置文件并可能写信给他们，但这感觉很脏。

Answer 1

交叉引用：一个相关的问题是当您有一个普通用户无法写入的设置文件时。这是消除这种情况的方法列表： System.UnauthorizedAccessException while running .exe under program files。

• 将两个互斥的同名文件安装到同一个目录下

我将只总结其他人基本上提到的内容，并尝试做一些“小参考”。

也许看看下面提到的Win10 勒索软件保护功能，了解有关此 Windows 更改如何影响用户配置文件部署的重要花絮。

常见方法

• 有很多方法可以将文件部署到计算机上的每个用户，但是大多数方法都存在许多缺点和问题。老实说，所有方法都存在问题，以一种或另一种形式存在。

• 下面首先列出一些常见的部署方法，然后提到一些“基于云的方法”。将来，此讨论可能会变得无关紧要，因为设置完全基于云并实时同步，并且部署可能完全从基于机器的部署切换到基于用户的部署。我们将不得不等待，看看结果如何。

  • 1：每台机器模板

    • 安装配置文件到每台机器的位置是可读的所有用户，然后复制从那里的文件，并把它放入USERPROFILE在应用程序启动使用应用程序本身做拷贝工作每个用户一次。
    • 这是推荐的方法。如果您需要使用这样的方法，您甚至可以使用逻辑更新您的应用程序以强制每个用户更新：http : //forum.installsite.net/index.php?showtopic=21552。
    • 当复制发生时，您将始终在正确的用户上下文中运行，您不必担心复杂的 MSI 模拟、调节和排序的复杂性。
    • 这种方法的一个很好的优点是，即使在应用程序启动时缺少安装源 (MSI)，它也能工作。

  • 2：启动时创建文件 - “内部默认值”

    • 正如 giliduck 建议的那样，只需在启动时使用应用程序的内部默认值创建配置文件，并且根本不安装该文件。每个用户发生一次，从那时起您使用那里的文件。将此类文件保留在安装程序之外意味着您可以消除安装程序意外覆盖或卸载它的风险。
    • 显而易见的问题是为什么您根本需要这样的文件 - 如果您可以从内部默认值创建它？答案很明显，您可能希望在创建文件后强制执行一些对于用户环境唯一的特定值。但是，像这样的设置也可以保存在注册表中吗？
    • 您可以在安装期间通过 PUBLIC PROPERTIES 在注册表的 HKLM 部分设置有问题的自定义设置（可由用户在命令行上或通过转换进行配置，请参阅：如何更好地使用 MSI 文件以获取有关此信息的信息），并在应用程序启动时为所有用户强制执行它们 - 换句话说，将它们写入 HKCU。或者您可以将 HKLM 中的设置保持为“只读”，并在您的应用程序中以这种方式为所有用户强制执行这些设置？（非用户可配置的设置 - 例如网络服务器名称或类似名称）。
    • 您仍然可以使用上面链接中的方法在应用程序启动时强制更新现有配置文件，方法是让您的设置向 HKLM 写入一个标志，以通知自上次启动以来部署已“发生”。
    • 或者，如上所述，或者使用注册表来保存设置。
    • 如何读取嵌入的资源文本文件

  • 3：微星自修

    • 使用MSI self-repair 为每个用户放置配置文件。这发生在调用广告入口点（例如用于启动应用程序的广告快捷方式）时。
    • 需要在修复发生时访问安装源。确保将您的 MSI 文件缓存在盒子上。
    • 自我修复可能不适用于终端服务器（禁用功能）。我上次测试这个已经有好几年了。我不确定这些天服务器是如何配置的。
    • 除非配置为不这样做，否则卸载可能会为运行实际卸载的用户卸载配置文件，或者更严重的是，这可能发生在重大升级（实际上是卸载并重新安装您的产品）期间。换句话说：将组件设置为永久（并且永远不会覆盖） - 否则您的文件可能会在升级过程中被覆盖（但它确实被卸载并重新安装）。
    • 对于 HKCU 注册表设置，您不一定需要安装源可用。检查Stefan Kruger 的解释：http : //www.msifaq.com/a/1011.htm。触发用户配置文件安装的过程相同（但需要安装源）。相关的讨论 - 如果有帮助。
    • 虽然我未经测试，但我已经考虑将注册表项路径值设置为：HKCU\Software\MyCompany\MyApplication\Version\HKCU_KeyPath = [ComputerName]为了使键路径值成为“移动目标”，以便在用户登录新计算机时可靠地触发自我修复（尽管漫游配置文件带来在现有的 HKCU 设置中）。
    • 正如我所说，未经测试，因为我几乎放弃了这种方法 - 因为依赖 Windows 的每个新更新都不那么可靠。每次都有奇怪的变化，结果不可预测。
    • 虽然不是 100% 相关，但我可以举出Windows 10 中新的勒索软件保护功能作为示例——它似乎会导致任何试图写入用户数据文件夹的 MSI出现间歇性运行时错误。将导致多少部署问题还有待观察 - 虽然到目前为止我们看到的是间歇性的结果 - 当它们默认打开该功能时会发生什么？
    • 而且，与上述相同，第三方安全软件还通过阻止某些文件系统活动和隔离因某种原因（包括误报）标记的文件来为部署提供障碍- 导致无法完成的自我修复，但保留白跑。
      • 请参阅此处有关自我修复和安全软件和恶意软件的问题 #7：如何避免使用我的 WiX / MSI 软件包触发 MSI 自我修复？
      • 总体部署复杂性总结：程序安装的好处和真正目的是什么？和这里的底部：Windows Installer 和 WiX 的创建。
    • 因此，作为一个简短的总结，以下是为什么通过自我修复来避免部署用户配置文件变得越来越有用的一些原因：
      • 漫游配置文件并发症。
      • 勒索软件保护功能干扰。
      • 安全软件干扰（尤其是恶意软件误报）。
      • 终端服务器限制自行修复。
      • 主要升级期间的数据重置或设置卸载问题。
      • 也许你和我有同样的感觉：还有更多，而且会继续变得更糟。
      • 我的两分钱：立即与您的经理讨论如何更好地管理您的应用程序的数据文件，并在部署期间放弃所有“智能”尝试。仅使用 MSI 部署每个机器文件 - 如果可能。
      • 将来，这种偏好可能会随着部署技术的变化而改变，并且安装仅针对每个用户（可能）。
      • 之前写的问题的详细描述：为什么在使用 MSI 时将文件部署限制到用户配置文件或 HKCU 是一个好主意？
      • 以及关于部署问题的整个混乱讨论：如何避免 WiX / MSI 部署解决方案中的常见设计缺陷？

  • 4：主动设置（不再推荐，请阅读）

    • 使用Active Setup放置配置文件。这发生在用户登录时（然后需要注销并登录，除非您确保该文件在安装时也安装到当前用户配置文件中）。
    • 这实际上是方法 1 的变体。您应该将配置文件安装到每个机器的位置，所有用户都可以读取。
    • 然后在注册表中注册一个任务，为每个用户运行一次“可运行的东西”。您可以运行任何东西，例如批处理文件、可执行文件、脚本或我首选的 MSI 修复方法，这些方法将设法将用户配置文件放置到位（在这种情况下，您不需要在每台机器位置的文件，但需要访问到安装源作为 Active Setup 运行）。
    • 注意不要覆盖当前用户在安装过程中放置​​的配置文件。或者通过写入在 Active Setup 为相关用户运行后写入的 HKCU 密钥来禁用 Active Setup 为该用户运行（请参见下面的链接）。
    • 我在此处的回答中尝试了该过程：更新 Windows Server 2003 上的每个配置文件的注册表。它全部基于每个用户运行一次的 HKLM 密钥。检查链接的答案以获取详细信息，其中有一些外部链接提供了更多详细信息。
    • 更新：在终端服务器上安装时，您将服务器置于“安装模式”，然后HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install在每个用户登录时将每个用户的注册表项写入并写入每个用户的 HKCU 配置单元。这可能与 ActiveSetup 冲突 - 据我所知。我从来没有机会测试它。终端服务器的打包通常由专门的专业服务器团队完成。

  • 5：MsiProvideComponent

    • Phil 的MsiProvideComponent很有意思，我没用过。我应该。

云风格的方法

• 随着数据存储似乎转移到云端，数据文件部署的常见方法可能很快就会过时。

  • 6：下载设置文件

    • 下载设置文件- 在应用程序启动时为每个用户下载一次 - 从本地网络数据库/共享或从Internet 下载- 如果这是一个选项。
    • 如果有新的默认值或需要删除某些内容，管理员可以维护远程文件以更新值。
    • 您的应用程序理解的设置文件中的配置机制可以强制执行新的“强制”值以应用于所有用户。
    • 允许在 HKLM 中配置服务器列表吗？可在 MSI 中通过PUBLIC PROPERTIES 进行配置？
    • 或者在安装过程中在您的设置中设置单个 URL 并通过该 URL 维护服务器列表（您通过 DNS 重定向它指向的服务器，因此配置是一项无需重新部署的系统管理任务？）。HKCU 中的当前选择集。

  • 7：远程数据库的读/写设置

    • 直接从本地 AD 数据库或Internet连续读取/写入设置。
    • 根本没有本地设置文件，或者无法访问服务器时缓存的只读副本？或者如果无法访问服务器，只需使用内部应用程序默认值运行？在后一种方法中根本没有要管理的文件。
    • 您可以编写用于 HKLM 的服务器 (URL) 列表（甚至通过组策略？），甚至可以为每个用户维护 HKCU 中当前选择的服务器。然后剩下的事情发生在网上。
    • 目前普遍用于企业客户端/服务器应用程序 - 但基于云的平台将永远改变部署 - 特别是对于家庭用户。我们已经看到浏览器通过 Internet 保存设置很长时间（Chrome、Opera、Firefox 等...）。
    • 远程数据库存储意味着您可以将用户设置作为数据库管理任务进行维护，您甚至可以对数据库中的用户数据进行版本控制，并作为集中的 DBO 任务轻松实施新的默认值或强制更新所有用户用户的现有值。
      • 不再有讨厌的漫游配置文件问题。
      • 用户配置文件的部署不再失败。
      • 总而言之：根本不需要部署用户设置，并且数据永远不会在不同机器上不同步。
      • 防火墙/代理和网络连接问题？

概括

我不喜欢选项 3（自行修复）和选项 4(Active Setup) 了，虽然我已经使用过很多次了——而且如果做得对，它们确实可以工作。但是，它们无法避免漫游配置文件问题（文件未在用户登录的所有系统上复制到位）以及在运行修复时无法访问 MSI 安装源 - 这可能会导致部署问题。在重置设置的重大升级过程中也经常出现并发症，并且在终端服务器上自我修复失败。由于勒索软件保护或安全软件干扰，自我修复可能无法安装到用户配置文件。选项 4（Active Setup）中指定的命令行可能有问题并清除数据（例如，您为 msiexec.xml 启用了错误的标志）。exe 意外修复并强制覆盖设置文件 - 这通常不会被发现，直到为时已晚并且损坏已经完成）。现在还有更多的问题让我望而却步。两种方法都有相似但略有不同的局限性。

我越来越喜欢基于云的方法来使本地（和隔离的）用户设置文件成为过去 - 但我很少能够以这种方式部署。不过，这些云方法可能会面临防火墙/代理问题和网络连接问题- 可能还有其他一些我还不知道的事情（现在开发人员将与 DBO 而不是部署专家等争吵......;-)）。分布式计算有其谬误：https : //en.wikipedia.org/wiki/Fallacies_of_distributed_computing. 另外：在基于云的方法中，允许将设置备份到磁盘的应用程序仍然可能是一个好主意，因此显然仍然需要一些文件管理 - 或者您只是导出几个数据库表？另外：如果您安装应用程序的试用版，您可能希望它能够在完全没有网络连接的情况下运行 - 以防用户位于非常严密的防火墙后面。由于技术原因不允许用户测试应用程序的功能，这是一个代价高昂的错误。

选项 1 和 2的最大好处是，即使在触发修复时原始安装介质丢失，它们也能正常工作。这对于家庭和小型办公室部署尤其重要，在这些部署中，如果没有集中的软件包共享，部署可能会相当随意。您可以通过在安装期间使用缓存方法在系统上缓存整个 MSI（在 Installshield 中可用，我没有检查 WiX 或 Advanced Installer）来解决这个问题（缺少源 MSI）。