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

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

Answer 1

不要在安装时创建配置文件，检查它是否在程序运行时存在，如果没有，则在运行的用户配置文件文件夹中创建它。 如果确实存在，则使用其中的数据并继续。

Answer 2

我将简要总结一下其他人基本上提到过的东西，充实了一些东西试图做出“小参考”。

或许可以看一下下面提到的Win10勒索软件保护function ，以了解这个Windows更改如何影响用户配置文件部署的重要信息 。

常用方法

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

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

  • 1：每台机器模板

    • 将配置文件安装到所有用户都可读的每个计算机位置 ，然后从那里复制文件，并在应用程序启动时使用应用程序本身将其放入userprofile ，以便每个用户执行一次复制工作。
    • 这是推荐的方法。 如果需要使用以下方法，您甚至可以使用逻辑更新应用程序以强制执行每用户更新： http ： //forum.installsite.net/index.php？showtopic = 21552 。
    • 当副本发生时，您将始终在正确的用户环境中运行，并且您不必担心复杂的MSI模拟，调节和排序复杂性。
    • 这种方法的一个很好的优点是，即使在应用程序启动时缺少安装源（MSI），它也能正常工作。

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

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

  • 3：MSI自我修复

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

  • 4：活动设置

    • 使用Active Setup将配置文件放置到位。 这发生在用户登录时（除非您确保文件也在安装时安装到当前用户配置文件，否则需要注销和登录）。
    • 这实际上是方法1的变体。您应该将配置文件安装到每个机器位置，所有用户都可以读取。
    • 然后在注册表中注册一个任务，以便每个用户运行一次“可运行的东西”。 您可以运行批处理文件，可执行文件，脚本或我首选的MSI修复程序，以便将userprofile文件放在适当的位置（在这种情况下，您不需要每个计算机位置的文件，而是访问权限）在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中配置服务器列表？ 可以通过PUBLIC PROPERTIES在MSI中配置吗？
    • 或者在安装过程中在您的设置中设置一个URL，并通过该URL维护一个服务器列表（您通过DNS重定向指向的服务器，因此配置是一个系统管理员任务，无需重新部署？）。 目前在HKCU的选择集。

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

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

摘要

我不喜欢选项3 （自我修复）和选项4 （活动设置），虽然我已经多次使用它们 – 并且它们在正确完成时可以正常工作。 但是，它们不能免于漫游配置文件问题（文件未在用户登录的所有系统上进行复制），并且在修复运行时无法访问MSI安装源 – 这可能会导致部署问题。 使用重置设置进行主要升级时也会出现频繁的复杂情况，并且终端服务器上的自我修复失败。 由于勒索软件保护或安全软件干扰，自我修复可能无法安装到用户配置文件。 选项4（活动安装程序）中指定的命令行可能是错误的并且消除了数据（例如，您为msiexec.exe修复启用了错误的标志并强制意外覆盖设置文件 – 这通常直到它也被发现迟到，损坏已经完成）。 还有一些问题让我现在无法摆脱困境。 两种方法都有类似但略有不同的限制。

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

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

Answer 3

您可以使用修复function进行此操作。 大局是该文件是在一个用户安装时在用户配置文件位置安装的，并且在每个系统安装中意味着当另一个用户登录使用该应用程序时该文件将丢失。 这取决于MSI组件，function和快捷方式的结构，但是使用广告快捷方式启动应用程序可能会导致丢失的文件被安装并进行自我修复。 显然这需要源MSI保持可用。

但是，为任何新用户安装文件的最安全方法是显式调用MsiProvideComponent，传递MSI的ProductCode，function名称，组件ID等，如文档中所述。 正如文档所说，如果组件丢失，这将安装组件，同样需要源MSI可用。

此function处理的是尚未创建用户帐户的情况，因此显然您无法将文件放在其配置文件文件夹中。

与其他方法相比，它是否是最佳方法取决于应用程序的具体细节。