短版
在安装过程中似乎（意外）通过 WiX 元素或自定义操作应用了自定义权限（下面讨论的其他可能原因 - 可能检查主要特别是升级文件恢复的可能性 - 或组策略的可能性）。
调试线索可在 WiX 源代码、编译的 MSI 文件或详细日志文件中找到（举几个开始的地方）。下面每个选项的详细信息。
下面的内容写得很“有机”——它进化了一点——所以它有点多余。我会保持原样。
其他可能的原因
主要升级文件恢复：很奇怪，安装后文件权限变少了。也许这表明在安装期间重新创建了组策略或文件？对于如此重要的文件，后者听起来不太可能 - 但 如果更新是重大升级并且原始 MSI 将 INI 文件安装为文件（而不是 INI 文件条目）并将其设置为非永久文件。
在这种情况下，INI 文件将被卸载然后重新安装 - 可能会剥夺它的任何自定义 ACL 权限（ACL 权限非常复杂，它们可以继承和覆盖，并拒绝或授予等...）。添加到旧文件中的任何自定义 INI 条目也将被清除 - 在安装后检查这些缺失的自定义条目。
这是一个常见问题（主要升级文件恢复）：主要升级文件卸载并重新安装，使文件在被清除和安装后看起来恢复或覆盖除了 ACL 问题之外，还可能引发许多其他问题。
意外许可的其他潜在来源也是可能的：
- 针对同一 INI 文件的另一个与 Lotus Notes 相关的 MSI 包的修复/修改操作？
- 另一个 MSI 作为同一个安装包的一部分运行并进行许可？
- 执行标准 ACL 的组策略/活动目录进程？ (sample)
- 以管理员模式运行的可执行文件/服务正在做一些时髦的事情？
- 计划任务干扰？ (some possibilities)
- 登录脚本做一些时髦的事情？ （在您的情况下不太可能，但登录脚本几乎可以做“任何事情” - 他们确实可以）
- 其他一些意想不到的来源。 具有管理员权限的东西会这样做 - 这是明显的共同点。
我的 2 美分：如果这是一个内部企业包，use group policy to apply permissioning 并从您的包中删除操作（除非您部署到组策略控制之外的计算机 - 但是您可以有一个特殊的包，它只进行许可并将许可排除在您的主包之外 - 使其不易出错）。
ACL
你描述的问题很有趣。我不知道 WiX 中有什么自动会干扰 ACL，但我不能保证。但是，当您明确指定 ACL 时，有些结构旨在更改它们 - 您需要检查您的 MSI 是否有这些结构（如下所述）
但首先：我使用 WiX MSI 进行了快速烟雾测试，看看我是否可以复制问题，我无法复制它。我担心这可能会在最近的 Windows 更新中有所改变。换句话说，某种安全修复程序在任何人都不知情的情况下分发，这会改变 Windows Installer 中的核心功能 (it wouldn't be the first one)。
ACL 许可
有关如何在您的 MSI 中实施 ACL 权限的一些信息。本质上，您可以使用现成的 WiX 元素，或运行您自己的自定义操作。
有几个处理 ACL 许可的 WiX 元素，它们导致将设置添加到标准的内置 MSI 表中，或者将条目添加到自定义 WiX 表中。 在您的 WiX 源中查找这些元素（如果有） (samples)：
我不确定为什么 WiX 开发人员决定支持所有这些不同的许可选项 - 肯定有充分的理由 - 因为维护他们必须做很多工作。我自己编写了许可代码，在我看来，这是一个需要处理的阴谋复杂性的定时炸弹。权限的排列就像你不会相信的那样，但这不是这里的话题。在我的精简视图中，很少有权限有任何意义，但 ACL 权限允许充分的灵活性 - 你需要的所有绳索都可以让你自己在脚下开枪。我更喜欢通用的“宏”：GenericAll="yes"、GenericExecute="yes"、GenericRead="yes"、GenericRead="no" 等...
此外，您还可以使用自定义操作调用命令行权限工具，例如subinacl.exe、cacls.exe、xcacls.exe、icacls.exe 或其他几个- 出于可靠性和安全性的原因，我绝对不会推荐。当有其他选项时，自定义操作永远不会更可取：Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
由于技术原因我不会使用Permission 元素，我从未测试过内置的MsiLockPermissionsEx 表。如果我需要此 ACL 权限，我可能会选择使用特定于 WiX 的 PermissionEx 元素。
检查微星
如果您有 WiX 源访问权限，您应该能够找到导致问题的许可元素或自定义操作元素。
但是，如果您没有 WiX 源访问权限，您还可以检查您实际编译的 MSI 文件中是否有任何可以应用自定义权限的自定义功能。我将专注于Custom Action table 以及在相关 MSI 中找到的任何自定义 WiX / MSI 表。
换句话说：检查用于安装的已编译 MSI 文件是否有用于设置 ACL 的 自定义操作 和 自定义表。 See MSDN for a list of standard MSI tables。您找不到的任何表格都是自定义的。
要检查 MSI，请使用 Orca 或等效工具。有关您可以使用（商业或免费）的工具列表，请参阅此答案（朝向底部）：How can I compare the content of two (or more) MSI files?
详细日志记录
您也可以做我经常做的事情：为有问题的 MSI 安装创建适当的详细日志。这使您可以开始了解正在发生的事情 - 因此在某些情况下它可能比仅检查 MSI 更好。 You can find some information on how to do logging here.
或者，您可以为所有 MSI 安装启用日志记录。请参阅installsite.org on logging（“机器上的所有设置全局”部分）了解如何执行此操作。我更喜欢为 dev 和 test box 启用此默认日志记录，但它确实会影响安装性能，并且会在 temp 文件夹中添加大量日志文件（您可以偶尔删除一次）。通常你会突然看到一个 MSI 错误，并且希望你有一个日志 - 现在你可以，随时准备好在%tmp%。
我还会记下您使用的操作系统，并确定问题是否仅在该操作系统上出现？这还涉及确定您是否安装了最新的修补程序。