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

Posted 2023-04-13

【中文标题】在当前用户配置文件上创建文件夹和文件，从管理员配置文件

【英文标题】：Create folder and file on Current user profile, from Admin Profile

【发布时间】：2018-06-19 17:32:27

【问题描述】：

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

【参考方案1】：

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

Install two mutually-exclusive files with the same name to the same directory

---

我只是总结一下其他人基本提到的内容，稍微充实一下，试图做一个“小参考”。

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

常用方法

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

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

1：每台机器模板

将配置文件安装到所有用户均可读取的

每台计算机位置

，然后从那里复制文件并将其放入

上的 userprofile应用程序启动

使用应用程序本身为每个用户完成一次复制工作。 这是推荐的方法。如果您需要使用这样的方法，您甚至可以使用逻辑来更新您的应用程序以强制每个用户更新：http://forum.installsite.net/index.php?showtopic=21552。 当复制发生时，您将始终在正确的用户上下文中运行，并且您不必担心复杂的 MSI 模拟、调节和排序的复杂性。 这种方法的一个很好的优势是，即使在应用程序启动时缺少安装源 (MSI)，它也能正常工作。

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

正如 gilliduck 建议的那样，只需使用应用程序的内部默认值

在启动时创建配置文件

，然后

根本不安装该文件

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

3：MSI 自我修复

使用

MSI 自我修复

为每个用户放置配置文件。这发生在调用 advertised entry point（例如用于启动应用程序的广告快捷方式）时。 需要在修复时访问安装源。确保在盒子上缓存您的 MSI 文件。 终端服务器上可能无法进行自我修复（禁用功能）。自从我上次测试这个已经有好几年了。我不确定这些天是如何开箱即用地配置服务器的。 除非未配置为，否则卸载可能会为运行实际卸载的用户卸载配置文件，或者，重要的是，这可能发生在重大升级期间（实际上是卸载并重新安装您的产品）。换句话说：将组件设置为永久（并且永不覆盖） - 否则您的文件可能会在升级过程中被覆盖（但它实际上已被卸载并重新安装）。 对于 HKCU 注册表设置，您不一定需要有可用的安装源。查看

Stefan Kruger 的

解释：http://www.msifaq.com/a/1011.htm。触发安装用户配置文件的过程相同（但需要安装源）。 An associated discussion - in case it is helpful。 虽然未经我测试，但我已考虑将注册表键路径值设置为：HKCU\Software\MyCompany\MyApplication\Version\HKCU_KeyPath = [ComputerName] 以使键路径值成为“移动目标”，以便在用户登录时可靠地触发自我修复新计算机（尽管漫游配置文件引入了现有的 HKCU 设置）。 正如我所说，未经测试，因为我几乎放弃了这种方法 - 因为对于 Windows 的每个新更新都不太可靠。每次都会发生一些奇怪的变化，结果无法预料。 虽然不是 100% 相关，但我可以举一个例子，以 Windows 10 中的新

勒索软件保护功能

- 它似乎会导致任何 MSI 尝试执行

间歇性运行时错误

写入用户数据文件夹。将导致多少部署问题仍有待观察 - 虽然到目前为止我们看到的结果是断断续续的 - 如果他们在默认情况下启用该功能以及是否会发生什么？。 并且，与上述相同，

第三方安全软件

还通过阻止某些文件系统活动和隔离因某种原因被标记的文件来提供

部署障碍

（包括误报） - 导致永远无法完成的自我修复，而是继续徒劳。

在此处查看问题 #7

，了解关于自我修复和

安全软件

和

恶意软件

：How do I avoid triggering MSI self-repair with my WiX / MSI package?

部署复杂性

总结：What is the benefit and real purpose of program installation? 并在此处底部：Windows Installer and the creation of WiX。 作为一个

简短的总结

，以下是为什么通过自我修复避免部署用户配置文件变得越来越有用的一些原因：

漫游配置文件问题

。

勒索软件保护功能干扰

。

安全软件干扰

（尤其是误报恶意软件）。

终端服务器自我修复限制

。

重大升级期间的数据重置或设置卸载问题

。 也许你和我有同样的感觉：还有更多，而且还会继续恶化。

我的两分钱

：立即与您的经理讨论如何更好地管理您的应用程序的数据文件，并在部署期间放弃所有“聪明”的尝试。仅使用 MSI 部署每个计算机文件 - 如果可能的话。 未来这种偏好可能会随着部署技术的变化而改变，并且安装只针对每个用户进行（可能）。 之前写的问题的详细描述：Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI? 还有一个关于

一般部署问题

的混乱聊天：How do I avoid common design flaws in my WiX / MSI deployment solution?

4：活动设置 (no longer recommended, please read)

使用

Active Setup

放置配置文件。这会在用户登录时发生（然后需要注销并登录，除非您确保在安装时该文件也安装到当前用户配置文件中）。 这实际上是方法 1 的一种变体。您应该将配置文件安装到每个计算机的位置，所有用户都可以读取。 然后您在注册表中注册一个任务，以便每个用户运行一次“可运行的东西”。您可以运行任何东西，例如批处理文件、可执行文件、脚本或我首选的方法 MSI 修复，它将设法将 userprofile 文件放置到位（在这种情况下，您不需要在每台机器的位置中的文件，但可以访问在 Active Setup 运行时复制到安装源）。 注意不要覆盖当前用户安装过程中放置​​的配置文件。或者，通过写入在为相关用户运行 Active Setup 之后写入的 HKCU 密钥来禁用 Active Setup 为该用户运行（参见下面的链接）。 尝试在我的回答中解释该过程：Updating every profile's registry on Windows Server 2003。它全部基于每个用户运行一次的 HKLM 密钥。检查链接的答案以了解详细信息，其中有一些外部链接提供了更多详细信息。

更新

：When installing on Terminal Server you put the server in "install mode"，然后将每个用户的注册表项写入HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install，然后在每个用户登录时写入他们的 HKCU 配置单元。据我所知，这可能与 ActiveSetup 冲突。我从来没有机会测试它。终端服务器的打包通常由专门的专业服务器团队完成。

5：MsiProvideComponent

Phil 的

MsiProvideComponent

很有趣，我从未使用过。我应该。

云方式方法

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

6：下载设置文件

下载设置文件

- 在应用程序启动时为每个用户下载一次 - 从

本地网络数据库/共享

或从

互联网

代替 - 如果这是一个选项。 如果有新的默认值或需要删除某些内容，管理员可以维护远程文件以更新值。 您的应用程序理解的设置文件中的配置机制可以强制新的“强制”值适用于所有用户。 是否允许在 HKLM 中配置服务器列表？可通过PUBLIC PROPERTIES在 MSI 中进行配置？ 或者在安装过程中在您的设置中设置一个 URL，并通过该 URL 维护一个服务器列表（您通过 DNS 重定向这指向的服务器，因此配置是一项系统管理员任务，无需重新部署？）。在 HKCU 中呈现选择集。

7：从远程数据库读取/写入设置

而是直接

从本地 AD 数据库或互联网连续读取/写入设置。

根本没有本地设置文件，或者无法访问服务器时的缓存只读副本？或者如果无法访问服务器，只需使用内部应用程序默认值运行？在后一种方法中根本不需要管理文件。 您可以编写用于 HKLM 的服务器 (URL) 列表（甚至通过组策略？），甚至可以在 HKCU 中为每个用户维护当前选择的服务器。然后其余的在线进行。 目前通常用于企业客户端/服务器应用程序 - 但基于云的平台将永远改变部署 - 特别是对于家庭用户。我们已经看到浏览器通过 Internet 保存设置很长时间（Chrome、Opera、Firefox 等...）。 远程数据库存储意味着您可以将用户设置作为

数据库管理任务

进行维护，您甚至可以对数据库中的用户数据进行

版本化

并轻松

实施新的作为集中式 DBO 任务，所有用户用户的默认值

或

强制更新现有值

。 不再有烦人的漫游配置文件问题。 不再部署用户配置文件失败。 总而言之：根本不需要部署任何用户设置，而且数据在不同机器上永远不会不同步。 防火墙/代理和网络连接问题？

总结

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

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

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

【讨论】：

嗯，这肯定充实了我的简单答案。尽管我的作品适用于 TL;DR 版本，但我赞成这一点以获得额外的细节。

【参考方案2】：

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

【参考方案3】：

您可以使用修复功能来完成这项工作。总体情况是，该文件是在安装时在用户配置文件位置为一个用户安装的，并且在按系统安装中，这意味着当另一个用户登录使用该应用程序时该文件将丢失。这取决于 MSI 组件、功能和快捷方式的结构，但使用宣传的快捷方式启动应用程序可能会导致通过自我修复安装丢失的文件。显然，这需要源 MSI 保持可用。

然而，为任何新用户安装文件的最安全方法是显式调用MsiProvideComponent，并传递文档中描述的 MSI 的 ProductCode、功能名称、组件 ID 等。正如文档所说，如果组件丢失，这将安装组件，再次要求源 MSI 可用。

此功能处理尚未创建用户帐户的情况，因此显然您还不能将文件放入他们的配置文件文件夹中。

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