排查 Microsoft Purview 自承载集成运行时 (SHIR)

本文探讨 Microsoft Purview 中自承载集成运行时 (SHIR) 的常见故障排除方法。

Azure 数据工厂 和 Azure Synapse Analytics 也使用自承载集成运行时 (SHIR) 。 尽管许多故障排除步骤重叠,但请按照本指南对这些产品的 SHIR 进行故障排除:

收集Microsoft特定于 Purview 的 SHIR 自承载集成运行时日志

对于在自承载 IR 上运行的 Purview 扫描失败Microsoft,该服务支持从 Windows 事件查看器查看和上传错误日志。

可以查找以下错误指南中看到的任何错误。 若要获取 SHIR 问题的支持和故障排除指南,可能需要生成错误报告 ID 并 联系 Azure 支持人员

若要为 Azure 支持生成错误报告 ID,请按照以下说明作:

  1. 在 Microsoft Purview 治理门户中开始扫描之前:

    1. 导航到安装了自承载集成运行时的计算机,并打开 Windows 事件查看器。
    2. 清除“Integration Runtime”部分中的 windows 事件查看器日志。 右键单击日志并选择“清除日志”选项。
    3. 导航回 Microsoft Purview 治理门户,然后开始扫描。
  2. 扫描显示“失败”状态后,请导航回到 SHIR VM 或计算机,并在“Integration Runtime”部分中刷新事件查看器。

  3. 将显示失败的扫描运行的活动日志。

  4. 有关Microsoft的进一步帮助,请选择“ 发送日志”。

    此时会打开“ 使用Microsoft共享自承载集成运行时 (SHIR) 日志 ”窗口。

    自承载集成运行时上的“发送日志”按钮的屏幕截图, (SHIR) 将日志上传到Microsoft。

  5. 上传日志后,如果联系 Azure 支持人员,请保留报表 ID 的记录以使用。

    Purview SHIR 日志的上传进度窗口中显示的报告 ID 的屏幕截图。

自承载集成运行时 SHIR 常规故障或错误

Purview SHIR、Azure 数据工厂或Azure Synapse SHIR 之间存在许多常见错误、警告和问题。 以下指南介绍了许多最常见的问题。

自承载 IR 一般性故障或错误

内存不足问题

尝试使用自承载 IR 运行扫描时,会出现 OutOfMemoryException (OOM) 错误。

如果 IR 计算机遇到一时的内存使用率过高,则新扫描可能会引发 OOM 错误。 此问题可能是由大量并发活动或内存不足引起的,错误是设计造成的。

检查资源使用情况以确认是否有其他软件同时运行,并确认 SHIR 计算机是否满足 建议的配置

自承载 IR 未能加载文件或程序集

您会看到以下错误信息:

“无法加载文件或程序集‘XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX’或其依赖项之一。 系统找不到指定的文件。 活动 ID:92693b45-92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

下面是更为具体的错误消息:

“无法加载文件或程序集‘System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX’或其依赖项之一。 系统找不到指定的文件。 活动 ID:92693b45-92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

在进程监视器中,可以看到以下结果:

进程监视器中的路径列表的屏幕截图。

提示

在进程监视器中,你可以按以下屏幕截图所示设置筛选器。 上述错误消息指出,DLL System.ValueTuple 未位于相关的全局程序集缓存 (GAC) 文件夹中、C:\Program Files\Microsoft Integration Runtime\4.0\Gateway 文件夹中或 C:\Program Files\Microsoft Integration Runtime\4.0\Shared 文件夹中。 简单来说,该进程加载 DLL 的顺序是:首先从 GAC 文件夹加载,再从共享文件夹加载,最后从网关文件夹加载。 因此,可以从任何有用的路径加载 DLL。

“进程监视器筛选器”页的屏幕截图,其中列出了 DLL 的筛选器。

可以在 C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan 文件夹中发现 System.ValueTuple.dll。 若要解决此问题,请将 System.ValueTuple.dll 文件复制到 C:\Program Files\Microsoft Integration Runtime\4.0\Gateway 文件夹中 。

你可以使用相同的方法来解决其他文件或程序集缺失问题。

System.ValueTuple.dll 位于 %windir%\Microsoft.NET\assembly%windir%\assembly 下,因为这是 .NET 行为。

在以下错误中你可以清楚地看到 System.ValueTuple 程序集缺失。 应用程序尝试检查 System.ValueTuple.dll 程序集时会出现此问题。

"<LogProperties><ErrorInfo>[{"Code":0,"Message":"Npgsql.PoolManager 的类型初始值设定项引发了一个错误。","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"无法加载文件或程序集 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' 或其依赖项之一。 系统找不到指定的文件。","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"

有关 GAC 的详细信息,请参阅全局程序集缓存

自承载集成运行时身份验证密钥缺失

自承载集成运行时在无身份验证密钥的情况下突然脱机,事件日志显示以下错误消息:

“尚未分配身份验证密钥”

显示“尚未分配身份验证密钥”的集成运行时事件窗格的屏幕截图。

Microsoft Purview 门户中的自承载 IR 节点或逻辑自承载 IR 已删除,或者执行了干净卸载。

如果上述两个原因均不适用,你可前往 %programdata%\Microsoft\Data Transfer\DataManagementGateway 文件夹,检查是否删除了 Configurations 文件。 如果已删除,请按照 Netwrix 文章检测从 Windows 文件服务器中删除文件的人员中的说明进行操作。

用于检查 Configurations 文件的事件日志详细信息窗格的屏幕截图。

由于私钥缺失而无法选择证书

  • 你已将 PFX 文件导入到证书存储中。
  • 通过 IR 配置管理器 UI 选择证书时,收到以下错误消息:

“更改 Intranet 通信加密模式失败。 证书“<”>可能没有能够进行密钥交换的私钥,或者进程可能没有私钥的访问权限。 有关详细信息,请参阅内部异常。”

“Integration Runtime Configuration Manager设置”窗格的屏幕截图,其中显示了 &商;私钥缺少"错误信息。

  • 用户帐户的权限级别较低,无法访问私钥。
  • 此证书是作为签名证书(而不是密钥交换证书)生成的。
  • 若要操作 UI,请使用具有适当权限的帐户访问私钥。
  • 通过运行以下命令导入证书:
certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE

运行扫描时出现 UserErrorJreNotFound 错误消息

尝试使用基于 Java 的工具或程序(例如 Parquet 格式化文件) ) (扫描数据源时,会收到类似于以下内容的错误消息:

ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=找不到 Java Runtime Environment。 转到 http://go.microsoft.com/fwlink/?LinkId=808605,在 Integration Runtime(自承载)节点计算机上下载和安装。 注意 64 位 Integration Runtime 需要 64 位 JRE,而 32 位 Integration Runtime 需要 32 位 JRE。,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=无法加载 DLL 'jvm.dll': 无法找到指定模块。 (HRESULT 异常: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge

此问题由以下原因之一导致:

  • Java Runtime Environment (JRE) 未正确安装在 Integration Runtime 服务器上。

  • Integration Runtime 服务器缺少 JRE 所需的依赖项。

默认情况下,Integration Runtime 使用注册表项解析 JRE 路径。 这些条目应会在 JRE 安装期间自动设置。

请认真遵循本部分所述的步骤。 如果注册表修改不正确,可能会发生严重问题。 在修改注册表之前,请备份注册表,以便在出现问题时可以还原。

要解决此问题,请按照以下步骤验证 JRE 安装的状态:

  1. 请确保在同一平台安装 Integration Runtime (Diahost.exe) 和 JRE。 检查以下情况:

    • 应在文件夹 C:\Program Files\Java\ 中安装适用于 64 位 ADF Integration Runtime 的 64 位 JRE

      备注

      文件夹不是 C:\Program Files (x86)\Java\

    • JRE 11 兼容扫描。 JRE 8 也是兼容的,但尚未验证早于 JRE 8 的版本是否适合此用途。

  2. 检查注册表中的相应设置。 为此,请执行以下步骤:

  3. 在“运行”菜单中,键入 Regedit,然后按 Enter。

  4. 在导航窗格中,找到以下子项:

    HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment

    在“详细信息”窗格中,应该有一个“当前版本”项,显示 JRE 版本(例如 1.8)。

    屏幕截图显示 Java 运行时环境。

  5. 在导航窗格中,在 JRE 文件夹下找到与版本(例如 1.8)完全匹配的子键。 在详细信息窗格中,应该有一个“JavaHome”项。 此项的值是 JRE 安装路径。

    屏幕截图:显示 JavaHome 条目。

  6. 在以下路径中找到 bin\server 文件夹:

    C:\Program Files\Java\jre1.xx.xxx

    屏幕截图:显示 JRE 文件夹。

  7. 检查此文件夹是否包含 jvm.dll 文件。 如果没有,检查 bin\client 文件夹中是否有该文件。

    屏幕截图:显示 jvm.dll 文件位置。

备注

  • 如果配置与这些步骤中所述不同,请使用 JRE Windows Installer 来解决问题。
  • 如果这些步骤中的所有配置都如所述正确,则系统中可能缺少 VC++ 运行时库。 你可以通过安装 VC++ 2010 可再发行包来解决此问题。

自承载 IR 设置

Integration Runtime 注册错误

你可能会因为以下任一原因,偶尔希望在不同的帐户中运行自托管的 IR:

  • 公司策略不允许使用服务帐户。
  • 需要进行一些身份验证。

在服务窗格中更改服务帐户后,你可能会发现集成运行时停止工作,并收到以下错误消息:

“Integration Runtime (自承载)节点在注册期间遇到错误。 无法连接到集成运行时(自承载)主机服务。

“Integration Runtime 配置管理器”窗口的屏幕截图,其中显示 IR 注册错误。

许多资源仅授予服务帐户访问。 将服务帐户更改为另一个帐户时,所有从属资源的权限保持不变。

查看 Integration Runtime 事件日志以检查错误。

IR 事件日志的屏幕截图,其中显示发生了运行时错误。

  • 如果事件日志中的错误为“UnauthorizedAccessException”,请执行以下操作:

    1. 在 Windows 服务面板中检查 DIAHostService 登录服务帐户。

      登录服务帐户属性窗格的屏幕截图。

    2. 检查登录服务帐户是否对 %programdata%\Microsoft\DataTransfer\DataManagementGateway 文件夹具有读/写权限。

      • 默认情况下,如果服务登录帐户尚未更改,则应具有读/写权限。

        服务权限窗格的屏幕截图。

      • 如果已更改服务登录帐户,请执行下列作来缓解此问题:

        1. 对当前自承载 IR 执行完全卸载。
        2. 安装自承载 IR 位。
        3. 通过执行以下作更改服务帐户:
          1. 转到自承载 IR 安装文件夹,然后切换到 Microsoft Integration Runtime\4.0\Shared 文件夹。
          2. 使用提升的权限打开命令提示符窗口。 将用户<和密码替换为>自己的用户名和密码,然后运行以下命令:<>dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
          3. 如果要更改为 LocalSystem 帐户,请确保为此帐户使用正确的格式:dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
          4. 使用此格式:dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
          5. (可选)由于 Local System 具有高于管理员的权限,因此你也可以直接在“服务”中进行更改。
          6. 可以将本地/域用户用于 IR 服务登录帐户。
        4. 注册集成运行时。
  • 如果错误是“服务 'Integration Runtime Service' (DIAHostService) 未能启动。 请确保有足够的权限启动系统服务”,请执行以下操作:

    1. 在 Windows 服务面板中检查 DIAHostService 登录服务帐户。

      服务帐户的“登录”窗格的屏幕截图。

    2. 检查登录服务帐户是否具有 “以服务身份登录” 权限来启动 Windows 服务:

      “以服务身份登录”属性窗格的屏幕截图。

如果上述两种解决方法模式都不适用于你的情况,请尝试收集以下 Windows 事件日志:

  • 应用程序和服务日志 > 集成运行时
  • Windows 日志 > 应用程序

找不到“注册”按钮来注册自承载 IR

注册自托管 IR 时,“注册”按钮不会显示在“配置管理器”窗格中。

“配置管理器”窗格的屏幕截图,其中显示一条表明未注册集成运行时节点的消息。

自 Integration Runtime 3.0 发行以来,为了实现更干净、更安全的环境,删除了现有集成运行时节点上的“注册”按钮。 如果某个节点已注册到某个集成运行时(无论是否联机),则必须卸载之前的节点,然后安装并注册该节点,才能将该节点重新注册到另一个集成运行时。

  1. 在控制面板中,卸载现有的 Integration Runtime。

    重要

    在下面的过程中,选择“是”。 在卸载过程中请勿保留数据。

    用于从集成运行时删除所有用户数据的“是”按钮的屏幕截图。

  2. 如果没有 Integration Runtime 安装程序 MSI 文件,请转到下载中心以下载最新的 Integration Runtime。

  3. 安装 MSI 文件,并注册 Integration Runtime。

因 localhost 而无法注册自承载 IR

使用 get_LoopbackIpOrName 时,无法在新计算机上注册自承载 IR。

调试: 出现运行时错误。 “Microsoft.DataTransfer.DIAgentHost.DataSourceCache”的类型初始化表达式引发了异常。 数据库查找期间发生不可恢复的错误。

异常详细信息: System.TypeInitializationException:“Microsoft.DataTransfer.DIAgentHost.DataSourceCache”的类型初始化表达式引发了异常。 >--- System.Net.Sockets.SocketException:在 System.Net.Dns.GetAddrInfo 的数据库查找过程中发生不可恢复的错误, (字符串名称) 。

此问题通常在解决 localhost 时出现。

使用 localhost IP 地址 127.0.0.1 托管文件,然后解决问题。

自承载设置失败

无法卸载现有 IR,无法安装新 IR,或无法将现有 IR 升级为新 IR。

集成运行时的安装取决于 Windows Installer 服务。 你可能会遇到安装问题,原因如下:

  • 可用磁盘空间不足。
  • 权限不足。
  • Windows NT 服务已锁定。
  • CPU 使用率太高。
  • MSI 文件托管位置的网络慢。
  • 意外改动了某些系统文件或注册表。

IR 服务帐户无法获取证书访问权限

通过 Microsoft Integration Runtime 配置管理器安装自承载 IR 时,会生成一个包含受信任证书颁发机构 (CA) 的证书。 无法将证书应用于加密两个节点之间的通信,并显示以下错误消息:

"未能更改内部网通信加密模式: 未能授予集成运行时服务帐户对证书 <证书名称> 的访问权限。 错误代码 103

显示错误消息的屏幕截图 "...未能向Integration Runtime服务帐户授予证书访问权限,"。

证书使用的是尚不受支持的密钥存储提供程序 (KSP) 存储。 到目前为止,自承载 IR 仅支持加密服务提供程序 (CSP) 存储。

在这种情况下,建议使用 CSP 证书。

解决方案 1

若要导入证书,请运行以下命令:

Certutil.exe -CSP "CSP or KSP" -ImportPFX FILENAME.pfx

用于导入证书的 certutil 命令的屏幕截图。

解决方案 2

若要转换证书,请运行以下命令:

openssl pkcs12 -in .\xxxx.pfx -out .\xxxx_new.pem -password pass: <EnterPassword> openssl pkcs12 -export -in .\xxxx_new.pem -out xxxx_new.pfx

转换前后:

证书转换前的结果的屏幕截图。

证书转换后的结果的屏幕截图。

自承载集成运行时版本 5.x

若要升级为自承载集成运行时版本 5.x,我们需要 .NET Framework 运行时 4.7.2 或更高版本。 在下载页中,你会发现最新的 4.x 版本和最新的两个 5.x 版本的下载链接。

对于 Azure 数据工厂 v2 和 Azure Synapse 客户:

  • 如果自动更新已打开,并且你已将 .NET Framework 运行时升级到 4.7.2 或更高版本,则自承载集成运行时会自动升级到最新的 5.x 版本。
  • 如果自动更新已打开,并且你尚未将 .NET Framework 运行时升级到 4.7.2 或更高版本,则自承载集成运行时不会自动升级到最新的 5.x 版本。 自承载集成运行时仍然保留为当前的 4.x 版本。 你可以在门户和自承载集成运行时客户端中看到有关 .NET Framework 运行时升级的警告。
  • 如果自动更新已关闭,并且你已将 .NET Framework 运行时升级到 4.7.2 或更高版本,则可以手动下载最新的 5.x,并将其安装在计算机上。
  • 如果自动更新已关闭,并且你尚未将 .NET Framework 运行时升级到 4.7.2 或更高版本。 则当你尝试手动安装自承载集成运行时 5.x 并注册密钥时,你需要先升级 .NET Framework 运行时版本。

对于 Azure 数据工厂 v1 客户:

  • 自承载集成运行时 5.X 不支持 Azure 数据工厂 v1。
  • 自承载集成运行时将自动升级到最新版本的 4.x。 4.x 的最新版本不会过期。
  • 如果尝试手动安装自承载集成运行时 5.x 并注册密钥,系统会通知自承载集成运行时 5.x 不支持 Azure 数据工厂 v1。

自承载 IR 连接问题

自承载集成运行时无法连接到云服务

尝试注册自承载集成运行时的时候,配置管理器显示以下错误消息:

“Integration Runtime (自承载)节点在注册期间遇到错误。”

“Integration Runtime (自承载)节点在注册期间遇到错误”消息的屏幕截图。

自承载 IR 无法连接到服务后端。 此问题通常是防火墙中的网络设置导致的。

  1. 检查集成运行时服务是否正在运行。 如果是,转到步骤 2。

    显示自承载 IR 服务正在运行的屏幕截图。

  2. 如果自承载 IR 上没有配置代理(这是默认设置),请在安装了自承载集成运行时的计算机上运行以下 PowerShell 命令:

     (New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")
    

    备注

    服务 URL 可能会有所不同,具体取决于数据工厂或 Synapse 工作区实例的位置。 若要查找服务 URL,请使用数据工厂或Azure Synapse实例中 UI 的“管理”页查找集成运行时,并选择自承载 IR 进行编辑。 选择“ 节点 ”选项卡,然后选择“ 查看服务 URL”。

  3. 下面是预期的响应:

    PowerShell 命令响应的屏幕截图。

  4. 如果未收到预期的响应,请根据情况使用以下方法之一:

    • 如果收到“无法解析远程名称”消息,则表明存在域名系统 (DNS) 问题。 请联系你的网络团队来修复此问题。
    • 如果收到“ssl/tls 证书不受信任”消息,检查证书 (https://wu2.frontend.clouddatahub.net/) 查看计算机上是否受信任,然后使用证书管理器安装公共证书。 此操作应该会缓解此问题。
    • 转到“Windows”>“事件查看器(日志)”>“应用程序和服务日志”>“Integration Runtime”,检查是否存在由 DNS、防火墙规则或公司网络设置导致的故障。 如果发现此类故障,请强行关闭连接。 每个公司都有自己自定义的网络设置,因此请与网络团队联系以排查这些问题。
  5. 如果在自承载集成运行时上配置了“代理”,请验证代理服务器是否可以访问服务终结点。 有关示例命令,请参阅 PowerShell, web requests, and proxies(PowerShell、Web 请求和代理)。

     $user = $env:username
     $webproxy = (get-itemproperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet
     Settings').ProxyServer
     $pwd = Read-Host "Password?" -assecurestring
     $proxy = new-object System.Net.WebProxy
     $proxy.Address = $webproxy
     $account = new-object System.Net.NetworkCredential($user,	[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($pwd)), "")
     $proxy.credentials = $account
     $url = "https://wu2.frontend.clouddatahub.net/"
     $wc = new-object system.net.WebClient
     $wc.proxy = $proxy
     $webpage = $wc.DownloadData($url)
     $string = [System.Text.Encoding]::ASCII.GetString($webpage)
     $string
    

下面是预期的响应:

屏幕截图:预期 PowerShell 命令响应。

备注

代理注意事项:

  • 检查是否需要将代理服务器放在“安全接收方”列表中。 如果需要,请确保这些域在“安全接收方”列表中。
  • 检查是否在代理服务器上信任 SSL/TLS 证书“wu2.frontend.clouddatahub.net/”。
  • 如果在代理上使用 Active Directory 身份验证,请将服务帐户更改为可作为“Integration Runtime 服务”访问该代理的用户帐户。

无法建立 SSL/TLS 安全通道的信任关系

自承载 IR 无法连接到 Microsoft Purview。

转到 Windows>事件查看器 > (日志) 应用程序和服务日志后检查自承载 IR 事件日志>时Integration Runtime你会发现以下错误消息:

底层连接已关闭:无法建立 SSL/TLS 安全通道的信任关系。 根据验证过程,远程证书无效。”

检查服务的服务器证书最简单方法是在浏览器中打开服务 URL。 例如,在安装了自承载 IR 的计算机上打开检查服务器证书链接 ((https://eu.frontend.clouddatahub.net/) ,然后查看服务器证书信息。

Azure 数据工厂服务的“检查服务器证书”窗格的屏幕截图。

用于检查服务器认证路径的窗口的屏幕截图。

此问题有两个可能的原因:

  • 原因 1:服务的服务器证书的根 CA 在安装了自承载 IR 的计算机上不受信任。
  • 原因 2:你在环境中使用了代理,代理替代了服务的服务器证书,而安装了自承载 IR 的计算机不信任已替换的服务器证书。
  • 对于原因 1:请确保服务的服务器证书及其证书链在安装了自承载 IR 的计算机上受信任。
  • 对于原因 2:请在自承载 IR 计算机上信任被替换的根 CA,或者将代理配置为不替换服务的服务器证书。

有关在 Windows 上信任证书的详细信息,请参阅安装受信任的根证书

我们推出了一个新的 SSL 证书,该证书从 DigiCert 签名。 查看 DigiCert 全局根 G2 是否在受信任的根 CA 中。

显示受信任的根证书颁发机构目录中的 DigiCert 全局根 G2 文件夹的屏幕截图。

如果它不在受信任的根 CA 中, 请在此处下载

后续步骤

有关故障排除的更多帮助,请尝试以下资源: