Microsoft O365 加载项 "Installation failed"

Microsoft O365 Add-In "Installation failed"

我有一个有效且经过验证的 Add-In/manifest,它通过了 npm run validate。我和数百名用户都可以通过 link 下载我的清单。然而,一些用户一直面临这个错误:

This app can't be installed. The manifest XML file isn't valid. For security reasons DTD is prohibited in this XML document. To enable DTD processing set the DtdProcessing property on XmlReaderSettings to Parse and pass the setting into XmlReaderCreate method.

有些用户在什么情况下会出现这样的错误?

您可以根据 XML 架构定义 (XSD) 文件验证清单文件。这将确保清单文件遵循正确的架构,包括您正在使用的元素的任何命名空间。如果您从其他示例清单中复制了元素,请仔细检查您是否还包括了适当的命名空间。您可以使用 XML 架构验证工具来执行此验证。

要使用命令行 XML 架构验证工具来验证您的清单,您需要:

  1. 安装 tar and libxml,如果您还没有的话。
  2. 运行下面的命令。将 XSD_FILE 替换为清单 XSD 文件的路径,将 XML_FILE 替换为清单 XML 文件的路径。
xmllint --noout --schema XSD_FILE XML_FILE

此外,您可以尝试使用 npm run validate 命令验证您的清单。有关详细信息,请参阅 Validate an Office Add-in's manifest

其实我一年前就遇到过这个问题。正如@OutlookAdd-insTeam-MSFT 建议的那样,我也认为这与网络有关,特别是与 DNS 有关。

这是我能够找到的,但不幸的是,我的客户从未回来确认它是否有用。

(请注意,部分文本引用自底部列出的网站。)

错误信息

无法安装应用程序。清单 XML 无效。出于安全原因,本 XML 文档禁止使用 DTD。要启用 DTD 处理,请将 XmlReaderSettings 上的 DtdProcessing 属性 设置为 Parse,并将设置传递给 XmlReader.Create 方法。

为什么会这样?

当 O365 读取 manifest.xml 时,它正在通过 msoid.[organization_name].onmicrosoft.com 和 msoid.onmicrosoft.com 解析。如果失败(由于输入错误等),将调用 HTTP 404 错误。此时您的 ISP 的 DNS 服务器应该接管并根据它的 CNAME 记录 table 提供解析地址。 但是,一些组织可能有额外的 DNS 帮助。一旦 msoid 解析器服务检测到 404 错误,ISP 的 DNS 将尝试接管 DNS 解析(DNS 协助)。当失败时(由于缺少 CNAME 记录或输入错误),它 returns 一个 HTML 格式的查询结果返回给 O365。它基本上是 HTTP 200 响应,O365 将其解释为成功的身份验证。 在此之后,O365 开始处理 HTML 格式的响应,就好像它是原始 manifest.xml 一样。由于 HTML 包含错误方式的 DTD 声明,您会收到错误消息“出于安全原因,此 XML 文档中禁止使用 DTD”。

可能的解决方案:

a) 确保客户端计算机上的 DNS 设置正确。

b) 暂时切换到另一个 DNS 服务器(例如 Google DNS)

d) 关闭 DNS 辅助服务(如果适用)

请参阅以下文章了解更多信息:

https://www.codetwo.com/kb/dtd-prohibited/

https://www.veeam.com/kb2821

http://sharepointers.blogspot.com/2017/03/connect-pnponline-for-security-reasons.html

https://docs.microsoft.com/fi-fi/office365/admin/services-in-china/purpose-of-cname?redirectSourcePath=%252fen-us%252farticle%252fWhat-s-the-purpose-of-the-Office-365-CNAME-record-for-msoid-19b67e2b-1b28-4432-8cca-394803fbdc87&view=o365-21vianet

https://blogs.msdn.microsoft.com/joerg_sinemus/2017/07/10/sharepoint-online-vanity-domain-powershell-csom-and-the-msoid-cname-record/