Solución de problemas del entorno de ejecución de integración autohospedado

Artículo
01/05/2024

SE APLICA A: Azure Data Factory Azure Synapse Analytics Microsoft Purview

Sugerencia

Pruebe Data Factory en Microsoft Fabric, una solución de análisis todo en uno para empresas. Microsoft Fabric abarca todo, desde el movimiento de datos hasta la ciencia de datos, el análisis en tiempo real, la inteligencia empresarial y los informes. Obtenga información sobre cómo iniciar una nueva evaluación gratuita.

En este artículo se exploran los métodos comunes de solución de problemas del entorno de ejecución de integración (IR) autohospedado en áreas de trabajo de Azure Data Factory y Synapse.

Recopilación de registros de IR autohospedado

Azure Data Factory y Azure Synapse Analytics

En el caso de las actividades con error que se ejecutan en un IR autohospedado o un IR compartido, el servicio permite ver y cargar registros de errores. Para obtener el identificador del informe de error, siga las instrucciones que se indican aquí y, a continuación, escriba el identificador de informe para buscar problemas conocidos relacionados.

En la página Supervisar de la interfaz de usuario del servicio, seleccione Ejecuciones de canalización.
En Ejecuciones de actividad, en la columna Error, seleccione el botón resaltado para mostrar los registros de actividad, tal como se muestra en la siguiente captura de pantalla:
- Azure Data Factory
- Azure Synapse
Los registros de actividad se muestran para la ejecución de actividad con errores.
Para obtener más ayuda, seleccione Enviar registros.

Se abre la ventana Share the self-hosted integration runtime (IR) logs with Microsoft (Compartir los registros de entorno de ejecución de integración [IR] autohospedado con Microsoft).
Seleccione los registros que quiere enviar.
- Para IR autohospedado, puede cargar los registros relacionados con la actividad con errores o todos los registros del nodo de IR autohospedado.
- En el caso de un IR compartido, solo puede cargar registros relacionados con la actividad con errores.
Cuando se carguen los registros, conserve un registro del identificador del informe para más adelante si necesita ayuda adicional para resolver el problema.

Nota

Las solicitudes de visualización y carga de registros se ejecutan en todas las instancias de IR autohospedado en línea. Si falta algún registro, asegúrese de que todas las instancias de IR autohospedado estén en línea.

Microsoft Purview

En el caso de las actividades de Microsoft Purview con errores que se ejecuten en un IR autohospedado o un IR compartido, el servicio permite ver y cargar registros de errores del Visor de eventos de Windows.

Puede buscar los errores que vea en la guía de errores siguiente. Para obtener una guía de soporte técnico y solución de problemas de SHIR, es posible que tenga que generar un identificador de informe de errores y ponerse en contacto con el soporte técnico de Microsoft.

Para generar el identificador del informe de errores para el soporte técnico de Microsoft, siga estas instrucciones:

Antes de iniciar un examen en el portal de gobernanza de Microsoft Purview:
1. Vaya a la máquina donde está instalado el entorno de ejecución de integración autohospedado y abra el Visor de eventos de Windows.
2. Borre los registros del Visor de eventos de Windows en la sección Integration Runtime. Haga clic con el botón derecho en los registros y seleccione la opción borrar registros.
3. Vuelva al portal de gobernanza de Microsoft Purview e inicie el examen.
Una vez que el examen muestre el estado Error, vuelva a la máquina virtual de SHIR o a la máquina y actualice el visor de eventos en la sección Integration Runtime.
Los registros de actividad se muestran para la ejecución del examen con errores.
Para obtener más ayuda de Microsoft, seleccione Enviar registros.

Se abre la ventana Compartir los registros de entorno de ejecución de integración autohospedado (SHIR) con Microsoft.
Seleccione los registros que quiere enviar.
- Para IR autohospedado, puede cargar los registros relacionados con la actividad con errores o todos los registros del nodo de IR autohospedado.
- En el caso de un IR compartido, solo puede cargar registros relacionados con la actividad con errores.
Cuando se carguen los registros, conserve un registro del identificador del informe para más adelante si necesita ayuda adicional para resolver el problema.

Nota

Error general de IR autohospedado

Problema de memoria agotada

Síntomas

Se produce un error OutOfMemoryException (OOM) al intentar ejecutar una actividad de búsqueda con un IR vinculado o un IR autohospedado.
Causa

Una nueva actividad puede generar un error OOM si la máquina de IR experimenta un uso intensivo de memoria. El problema puede deberse a un gran volumen de actividad simultánea, y el error es así intencionadamente.
Resolución

Compruebe el uso de recursos y la ejecución de actividades simultáneas en el nodo del entorno de ejecución de integración. Ajuste el tiempo interno y del desencadenador de las ejecuciones de actividad para evitar demasiadas ejecuciones simultáneas en un único nodo del entorno de ejecución de integración.

Problema de límite de trabajos simultáneos

Síntomas

Al intentar aumentar el límite de trabajos simultáneos desde la interfaz de usuario, el proceso se bloquea con el estado Actualizando.

Escenario de ejemplo: El valor máximo de trabajos simultáneos está establecido actualmente en 24, y se quiere aumentar el número total para que los trabajos se puedan ejecutar con mayor rapidez. El valor mínimo que se puede especificar es 3, y el valor máximo es 32. Aumenta el valor de 24 a 32 y, luego, selecciona el botón Actualizar. El proceso se bloquea con el estado Actualizando, como se muestra en la captura de pantalla siguiente. Actualiza la página y el valor aún se muestra como 24. No se ha actualizado a 32 como era de esperar.
Causa

El límite en el número de trabajos simultáneos depende del núcleo lógico y de la memoria del equipo. Intente ajustar el valor a la baja hasta un valor como 24 y, a continuación, vea el resultado.
Sugerencia
- Para obtener más información sobre el recuento de núcleos lógicos y determinar el número de núcleos lógicos de la máquina, consulte Cuatro maneras de encontrar el número de núcleos de la CPU en Windows 10.
- Para obtener información sobre cómo calcular math.log, vaya a la calculadora logarítmica.

Problema de certificado SSL de alta disponibilidad (HA) de IR autohospedado

Síntomas

El nodo de trabajo de IR autohospedado notifica el siguiente error:

"Error al extraer los estados compartidos del nodo principal net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. Id. de actividad: XXXXX No se pudo compilar la cadena CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft de certificado X.509. El certificado que se utilizó tiene una cadena de confianza que no se puede comprobar. Reemplace el certificado o cambie el certificateValidationMode. La función de revocación no pudo comprobar la revocación debido a que el servidor de revocación estaba sin conexión".
Causa

Al tratar casos relacionados con un protocolo de enlace SSL/TLS, es posible que surjan algunos problemas relacionados con la comprobación de la cadena de certificados.
Resolución
- A continuación, se muestra una manera rápida e intuitiva de solucionar los errores de compilación de la cadena de certificados X.509.
  1. Exporte el certificado, que debe comprobarse. Para ello, haga lo siguiente:
    
    a. En Windows, seleccione Inicio, empiece a escribir certificados y, a continuación, seleccione Administrar certificados de equipo.
    
    b. En el Explorador de archivos, en el panel izquierdo, busque el certificado que desea comprobar, haga clic con el botón derecho en él y, a continuación, seleccione Todas las tareas>Exportar.
  2. Copie el certificado exportado en el equipo cliente.
  3. En el lado cliente, en una ventana del símbolo del sistema, ejecute el comando siguiente. Asegúrese se reemplazar la <ruta de acceso del certificado> y la <ruta de acceso al archivo txt de salida> por las que correspondan.
```
Certutil -verify -urlfetch    <certificate path>   >     <output txt file path> 
```
    Por ejemplo:
```
Certutil -verify -urlfetch c:\users\test\desktop\servercert02.cer > c:\users\test\desktop\Certinfo.txt
```
  4. Compruebe los errores en el archivo TXT de salida. Puede encontrar el resumen de errores al final del archivo TXT.
    
    Por ejemplo:
    
    Si no ve ningún error al final del archivo de registro, como se muestra en la siguiente captura de pantalla, puede considerar que la cadena de certificados se ha compilado correctamente en la máquina cliente.
- Si se configura una extensión de nombre de archivo de AIA (acceso a la información de entidad emisora), CDP (punto de distribución cRL) una OCSP (protocolo de estado de certificados en línea) en el archivo de certificado, puede comprobarlo de una manera más intuitiva:
  1. Para obtener esta información, compruebe los detalles del certificado, tal como se muestra en la captura de pantalla siguiente:
  2. Ejecute el siguiente comando: Asegúrese de reemplazar la <ruta de acceso del certificado> por la ruta de acceso real del certificado.
```
  Certutil   -URL    <certificate path> 
```
    Se abre la herramienta de recuperación de dirección URL.
  3. Para comprobar los certificados con las extensiones de nombre de archivo AIA, CDP y OCSP, seleccione Recuperar.
    
    Habrá creado la cadena de certificados correctamente si el estado del certificado de AIA es Comprobado y el estado del certificado de CDP u OCSP es Comprobado.
    
    Si hay un error al intentar recuperar AIA o CDP, trabaje con el equipo de redes para preparar la máquina cliente para conectarse a la dirección URL de destino. Será suficiente si se puede comprobar la ruta de acceso HTTP o la ruta de acceso del Protocolo ligero de acceso a directorios (LDAP).

IR autohospedado no pudo cargar el archivo o ensamblado

Síntomas

Se muestra el siguiente mensaje de error:

"No se puede cargar el archivo o ensamblado 'XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' o una de sus dependencias. El sistema no encuentra el archivo especificado. Id. de actividad: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

He aquí un mensaje de error más específico:

"No se puede cargar el archivo o ensamblado 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' o una de sus dependencias. El sistema no encuentra el archivo especificado. Id. de actividad: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"
Causa

En Process Monitor, puede ver el siguiente resultado:

Sugerencia

En Process Monitor, puede establecer filtros como se muestra en la captura de pantalla siguiente.

El mensaje de error anterior indica que el archivo DLL System.ValueTuple no se encuentra en la carpeta de caché global de ensamblados (GAC) relacionada, en la carpeta C:\Archivos de programa\Microsoft Integration Runtime\4.0\Gateway ni en la carpeta C:\Archivos de programa\Microsoft Integration Runtime\4.0\Shared.

Básicamente, el proceso carga el archivo DLL primero desde la carpeta GAC, luego de la carpetaShared y, finalmente, de la carpeta Gateway. Por lo tanto, puede cargar el archivo DLL desde cualquier ruta de acceso que resulte útil.
Resolución

Puede ver que el archivo System.ValueTuple.dll se encuentra en la carpeta C:\Archivos de programa\Microsoft Integration Runtime\4.0\Gateway\DataScan. Para resolver el problema, copie el archivo System.ValueTuple.dll en la carpeta C:\Archivos de programa\Microsoft Integration Runtime\4.0\Gateway.

Puede usar el mismo método para resolver otros problemas de archivos o ensamblados que faltan.
Más información sobre este problema

La razón por la que se ve el archivo System.ValueTuple.dll en %windir%\Microsoft.NET\assembly y %windir%\assembly es que es un comportamiento de .NET.

En el siguiente error, puede ver claramente que falta el ensamblado System.ValueTuple. Este problema surge cuando la aplicación intenta comprobar el ensamblado System.ValueTuple.dll.

"<LogProperties><ErrorInfo>[{"Code":0,"Message":"Se produjo una excepción en el inicializador de tipo para 'Npgsql.PoolManager'.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"No se puede cargar el archivo o ensamblado 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' o una de sus dependencias. El sistema no encuentra en archivo especificado.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"

Para obtener más información sobre GAC, consulte Caché global de ensamblados.

Falta la clave de autenticación del entorno de ejecución de integración autohospedado

Síntomas

El entorno de ejecución de integración autohospedado se queda sin conexión repentinamente sin una clave de autenticación, y el registro de eventos muestra el mensaje de error siguiente:

"Authentication Key is not assigned yet" (La clave de autenticación no se ha asignado todavía)
Causa
- Se eliminó el nodo de IR autohospedado o el IR autohospedado lógico en Azure Portal.
- Se realizó una desinstalación limpia.
Resolución

Si no corresponde ninguna de las causas anteriores, puede ir a la carpeta %programdata%\Microsoft\Data Transfer\DataManagementGateway para comprobar si se ha eliminado el archivo Configurations. Si se eliminó, siga las instrucciones del artículo de Netwrix sobre la detección de quién eliminó un archivo de los servidores de archivos de Windows.

No se puede usar IR autohospedado para enlazar dos almacenes de datos locales

Síntomas

Después de crear los IR autohospedados tanto para el almacén de datos de origen como para el de destino, quiere conectar los dos IR para finalizar una actividad de copia. Si los almacenes de datos están configurados en redes virtuales diferentes, o los almacenes de datos no pueden entender el mecanismo de la puerta de enlace, recibirá uno de los siguientes errores:
- "The driver of source cannot be found in destination IR" (No se puede encontrar el controlador de origen en el IR de destino)
- "The source cannot be accessed by the destination IR" (El IR de destino no puede acceder al origen)
Causa

IR autohospedado está diseñado como nodo central de una actividad de copia, no como agente cliente que debe instalarse para cada almacén de datos.

En este caso, debe crear el servicio vinculado para cada almacén de datos con el mismo IR, y este debe poder acceder a ambos almacenes de datos a través de la red. No importa si el IR está instalado en el almacén de datos de origen, en el almacén de datos de destino o en una tercera máquina. Si se crean dos servicios vinculados con IR diferentes, pero se usan en la misma actividad de copia, se usa el IR de destino, y es necesario instalar los controladores para ambos almacenes de datos en la máquina del IR de destino.
Resolución

Instale los controladores para los almacenes de datos de origen y de destino en el IR de destino, y asegúrese de que este puede acceder al almacén de datos de origen.

Si el tráfico no puede atravesar la red entre dos almacenes de datos (por ejemplo, están configurados en dos redes virtuales), es posible que no finalice la copia en una actividad, incluso con el IR instalado. Si no puede finalizar la copia en una sola actividad, puede crear dos actividades de copia con dos IR, cada uno en una red virtual:
- Copie un IR del almacén de datos 1 a Azure Blob Storage
- Copie otro entorno de ejecución de integración de Azure Blob Storage en el almacén de datos 2.
Esta solución podría simular el requisito de usar el IR para crear un puente que conecte dos almacenes de datos desconectados.

El problema de sincronización de credenciales provoca la pérdida de credenciales de alta disponibilidad

Síntomas

Si la credencial del origen de datos "XXXXXXXXXX" se elimina del nodo actual del entorno de ejecución de integración con la carga útil, recibirá el mensaje de error siguiente:

"Al eliminar el servicio de vínculos en Azure Portal, o bien la tarea tiene una carga incorrecta; vuelva a crear un nuevo servicio de vínculos con sus credenciales".
Causa

El IR autohospedado está integrado en el modo de alta disponibilidad con dos nodos, pero los nodos no están en un estado de sincronización de credenciales. Es decir, las credenciales almacenadas en el nodo del distribuidor no se sincronizan con otros nodos de trabajo. Si se produce una conmutación por error del nodo distribuidor al nodo de trabajo, y las credenciales solo existen en el nodo distribuidor anterior, se producirá un error en la tarea al intentar acceder a las credenciales, y recibirá el error anterior.
Resolución

La única manera de evitar este problema es asegurarse de que los dos nodos estén en un estado de sincronización de credenciales. Si no están sincronizados, tendrá que volver a escribir las credenciales para el nuevo distribuidor.

No se puede elegir el certificado porque falta la clave privada

Síntomas
- Ha importado un archivo PFX al almacén de certificados.
- Al seleccionar el certificado a través de la interfaz de usuario de IR Configuration Manager, recibió el siguiente mensaje de error:
  
  "No se pudo cambiar el modo de cifrado de la comunicación de intranet. Es probable que el certificado "<nombre del certificado>" no tenga una clave pública que se pueda intercambiar o que el proceso no tenga derechos de acceso para la clave privada. Consulte la excepción interna para obtener más información.""
Causa
- La cuenta de usuario tiene un nivel de privilegios bajo y no puede acceder a la clave privada.
- El certificado se generó como firma, pero no como intercambio de claves.
Resolución
- Para usar la interfaz de usuario, use una cuenta con los privilegios adecuados para acceder a la clave privada.
- Para importar el certificado, ejecute el siguiente comando:
```
certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
```

Problema de nodos del entorno de ejecución de integración autohospedado sin sincronización

Síntomas

Los nodos del entorno de ejecución de integración autohospedado intentan sincronizar las credenciales entre nodos, pero se quedan bloqueados en el proceso y encuentran el mensaje de error siguiente al cabo de un tiempo:

"El nodo Integration Runtime (autohospedado) está intentando sincronizar las credenciales entre nodos. Esto podría tardar varios minutos".

Nota

Si este error aparece durante más de 10 minutos, compruebe la conectividad con el nodo de distribuidor.
Causa

El motivo es que los nodos de trabajo no tienen acceso a las claves privadas. Esto se puede confirmar a partir de los registros del entorno de ejecución de integración autohospedado a continuación:

[14]0460.3404::05/07/21-00:23:32.2107988 [System] A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

No tiene ningún problema con el proceso de sincronización al usar la autenticación de la entidad de servicio en el servicio vinculado. Sin embargo, al cambiar el tipo de autenticación a clave de cuenta, se inició el problema de sincronización. Esto se debe a que el servicio del entorno de ejecución de integración autohospedado se ejecuta en una cuenta de servicio (NT SERVICE\DIAHostService) y debe agregarse a los permisos de clave privada.
Resolución

Para solucionar este problema, debe agregar la cuenta de servicio del entorno de ejecución de integración autohospedado (NT SERVICE\DIAHostService) a los permisos de clave privada. Puede aplicar los pasos siguientes:
1. Abra el comando de ejecución de Microsoft Management Console (MMC).
2. En el panel de MMC, puede aplicar los pasos siguientes:
  1. Seleccione Archivo.
  2. Elija Agregar o quitar complemento en el menú desplegable.
  3. Seleccione Certificados en el panel "Complementos disponibles".
  4. Seleccione Agregar.
  5. En el panel emergente "Complemento Certificados", elija Cuenta de equipo.
  6. Seleccione Siguiente.
  7. En el panel "Seleccionar equipo", elija Equipo local: el equipo en el que se ejecuta esta consola.
  8. Seleccione Finalizar.
  9. Seleccione Aceptar en el panel "Agregar o quitar complementos".
3. En el panel de MMC, siga estos pasos:
  1. En la lista de carpetas izquierda, seleccione Raíz de consola -> Certificados (Equipo local) -> Personal -> Certificados.
  2. Haga clic con el botón derecho en Microsoft Intune MDM beta.
  3. Seleccione Todas las tareas en la lista desplegable.
  4. Seleccione Administrar claves privadas.
  5. Seleccione Agregar en "Nombre de grupo o usuario".
  6. Seleccione NT SERVICE\DIAHostService para concederle acceso de control total a este certificado, aplicarlo y asegurarlo.
  7. Seleccione Comprobar nombres y, después, Aceptar.
  8. En el panel "Permisos", seleccione Aplicar y, a continuación, Aceptar.

Mensaje de error UserErrorJreNotFound al ejecutar una actividad de copia en Azure

Síntomas

Al intentar copiar contenido en Microsoft Azure mediante una herramienta o un programa basado en Java (por ejemplo, copiar archivos de formato ORC o Parquet), recibirá un mensaje de error similar al siguiente:

ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment is not found. Vaya a http://go.microsoft.com/fwlink/?LinkId=808605 para realizar la descarga y la instalación en la máquina del nodo Integration Runtime (autohospedado). Nota: Integration Runtime de 64 bits requiere JRE de 64 bits, e Integration Runtime de 32 bits requiere JRE de 32 bits. JRE.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Unable to load DLL 'jvm.dll': No se encontró el módulo especificado. (Excepción de HRESULT: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge
Causa

Este error se produce debido a uno de los siguientes motivos:
- Java Runtime Environment (JRE) no está instalado correctamente en el servidor de Integration Runtime.
- El servidor de Integration Runtime no tiene la dependencia necesaria para JRE.
De forma predeterminada, Integration Runtime resuelve la ruta de acceso de JRE mediante entradas del registro. Esas entradas se deben establecer automáticamente durante la instalación de JRE.
Resolución

Sigue meticulosamente los pasos que se describen en esta sección. Pueden producirse problemas graves si modifica el Registro de manera incorrecta. Antes de modificarlo, haz una copia de seguridad del registro para restaurarlo, por si se produjeran problemas.

Para corregir este problema, siga estos pasos para comprobar el estado de la instalación de JRE:
1. Asegúrese de que Integration Runtime (Diahost.exe) y JRE están instalados en la misma plataforma. Compruebe las siguientes condiciones:
  - JRE de 64 bits para Integration Runtime de ADF de 64 bits debe instalarse en la carpeta C:\Program Files\Java\.
    
    Nota
    
    La carpeta no es C:\Program Files (x86)\Java\.
  - Versión 11 superior de Java Runtime (JRE) de un proveedor de JRE, como Microsoft OpenJDK 11 o Eclipse Temurin 11. Asegúrese de que la variable de entorno del sistema JAVA_HOME esté establecida en la carpeta JDK (no solo en la carpeta JRE). Es posible que también tenga que agregar la carpeta Bin a la variable de entorno PATH del sistema.
2. Compruebe en el Registro la configuración adecuada. Para ello, realice los pasos siguientes:
  1. En el menú Ejecutar, escriba Regedit y presione Entrar.
  2. En el panel de navegación, busque la siguiente subclave:
    
    HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.
    
    En el panel Detalles, debería haber una entrada Versión actual que muestre la versión de JRE (por ejemplo, 1.8).
  3. En el panel de navegación, busque una subclave que coincida exactamente con la versión (por ejemplo, 1.8) en la carpeta JRE. En el panel de detalles, debe haber una entrada JavaHome. El valor de esta entrada es la ruta de instalación de JRE.
3. Busque la carpeta bin\server en la ruta de acceso siguiente:
  
  C:\Program Files\Java\jre1.8.0_74
4. Compruebe si esta carpeta contiene un archivo jvm.dll. Si no es así, compruebe el archivo en la carpeta bin\client.
Nota
- Si alguna de estas configuraciones no es la descrita en estos pasos, utilice el instalador de Windows de JRE para solucionar los problemas.
- Si todas las configuraciones de estos pasos son correctas tal y como se describen, es posible que falte una biblioteca del entorno de ejecución de VC++ en el sistema. Puede corregir este problema instalando el paquete redistribuible VC++ 2010.

Configuración de IR autohospedado

Error de registro del entorno de ejecución de integración

Síntomas

En ocasiones, es posible que quiera ejecutar un IR autohospedado en otra cuenta por alguno de los siguientes motivos:
- La directiva de la compañía no permite la cuenta de servicio.
- Se requiere autenticación.
Después de cambiar la cuenta de servicio en el panel de servicio, es posible que el entorno de ejecución de integración deje de funcionar y reciba el siguiente mensaje de error:

"El nodo de Integration Runtime (autohospedado) ha encontrado un error durante el registro. No se puede conectar al servicio host de Integration Runtime (autohospedado)".
Causa

Muchos recursos solo se conceden a la cuenta de servicio. Al cambiar la cuenta de servicio a otra cuenta, los permisos de todos los recursos dependientes siguen siendo los mismos.
Resolución

Vaya al registro de eventos de Integration Runtime para comprobar el error.
- Si el error en el registro de eventos es "UnauthorizedAccessException", haga lo siguiente:
  1. Compruebe la cuenta del servicio de inicio de sesión DIAHostService en el panel del servicio de Windows.
  2. Compruebe si la cuenta de servicio de inicio de sesión tiene permisos de lectura y escritura en la carpeta %programdata%\Microsoft\DataTransfer\DataManagementGateway.
    - De manera predeterminada, si no se ha cambiado la cuenta de inicio de sesión del servicio, debe tener los permisos de lectura y escritura.
    - Si ha cambiado la cuenta de inicio de sesión del servicio, siga los pasos a continuación para mitigar el problema:
      
      a. Realice una desinstalación limpia del IR autohospedado actual.
      b. Instale los bits de IR autohospedado.
      c. Cambie la cuenta de servicio mediante el procedimiento siguiente:
      
      i. Vaya a la carpeta de instalación de IR autohospedado y cambie a la carpeta Microsoft Integration Runtime\4.0\Shared.
      ii. Abra la ventana Símbolo del sistema con privilegios elevados. Reemplace <user> y <password> por su nombre de usuario y contraseña y ejecute el comando siguiente:
      dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
      iii. Si quiere cambiar a una cuenta LocalSystem, asegúrese de usar un formato correcto para esta cuenta: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
      No use este formato: dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
      iv. De manera opcional, dado que el sistema local tiene más privilegios que el administrador, también puede cambiarlo directamente en "Servicios".
      v. Puede usar un usuario local o de dominio para la cuenta de inicio de sesión del servicio de IR.
      
      d. Registre el entorno de ejecución de integración.
- Si el error es "No se pudo iniciar el 'servicio de Integration Runtime" (DIAHostService). Compruebe que dispone de suficientes privilegios para iniciar servicios del sistema", haga lo siguiente:
  1. Compruebe la cuenta del servicio de inicio de sesión DIAHostService en el panel del servicio de Windows.
  2. Compruebe si la cuenta de servicio de inicio de sesión tiene permiso Iniciar sesión como servicio para iniciar el servicio de Windows:
Más información

Si ninguno de los dos patrones anteriores de resolución se aplica en su caso, intente recopilar los siguientes registros de eventos de Windows:
- Registros de aplicaciones y servicios > Integration Runtime
- Registros de Windows > Aplicación

No se encuentra el botón Registrar para registrar un IR autohospedado

Síntomas

Al registrar un IR autohospedado, el botón Registrar no se muestra en el panel de Configuration Manager.
Causa

A partir del lanzamiento de Integration Runtime 3.0, se ha quitado el botón Registrar en un nodo de Integration Runtime existente para habilitar un entorno más limpio y seguro. Si un nodo se ha registrado en algún entorno de ejecución de integración, ya sea en línea o no, para volver a registrarlo en otro entorno de ejecución de integración, debe desinstalar el nodo anterior y, a continuación, instalar y registrar el nodo.
Resolución
1. En el Panel de control, desinstale el entorno de ejecución de integración existente.
  
  Importante
  
  En el proceso siguiente, seleccione Sí. No mantenga los datos durante el proceso de desinstalación.
2. Si no tiene el archivo MSI del instalador del entorno de ejecución de integración, vaya al centro de descarga para descargar el entorno de ejecución de integración más reciente.
3. Instale el archivo MSI y registre el entorno de ejecución de integración.

No se puede registrar el IR autohospedado debido a localhost

Síntomas

No puede registrar el IR autohospedado en una máquina nueva cuando usa get_LoopbackIpOrName.

Depuración: Se ha producido un error de tiempo de ejecución. El inicializador de tipo para "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" produjo una excepción. Se produjo un error no recuperable durante una búsqueda de base de datos.

Detalle de la excepción: System.TypeInitializationException: El inicializador de tipo para "Microsoft.DataTransfer.DIAgentHost.DataSourceCache" produjo una excepción. ---> System.Net.Sockets.SocketException: se produjo un error no recuperable durante una búsqueda en la base de datos en System.Net.Dns.GetAddrInfo(nombre de la cadena).
Causa

El problema suele producirse cuando se está resolviendo el localhost.
Resolución

Use la dirección IP de localhost 127.0.0.1 para hospedar el archivo y resolver el problema.

Error al instalar IR autohospedado

Síntomas

No puede desinstalar un IR existente, instalar un IR nuevo ni actualizar un IR existente a un IR nuevo.
Causa

La instalación del entorno de ejecución de integración depende del servicio de Windows Installer. Puede experimentar problemas de instalación por los siguientes motivos:
- Espacio en disco disponible insuficiente.
- Falta de permisos.
- El servicio de Windows NT está bloqueado.
- El uso de la CPU es demasiado alto.
- El archivo MSI se hospeda en una ubicación de red lenta.
- Algunos registros o archivos del sistema se modificaron de forma accidental.

La cuenta de servicio del IR no pudo capturar el acceso al certificado

Síntomas

Al instalar el IR autohospedado a través de Microsoft Integration Runtime Configuration Manager, se genera un certificado con una entidad de certificación (CA) de confianza. No se pudo aplicar el certificado para cifrar la comunicación entre dos nodos, y se muestra el siguiente mensaje de error:

"Failed to change Intranet communication encryption mode: Failed to grant Integration Runtime service account the access of to the certificate '<certificate name>' (No se pudo cambiar el modo de cifrado de la comunicación con la Intranet: no se pudo conceder acceso al certificado [nombre del certificado] a la cuenta del servicio Integration Runtime). Código de error: 103".
Causa

El certificado usa un almacenamiento de proveedor de almacenamiento de claves (KSP), que todavía no se admite. Hasta la fecha, IR autohospedado solo admite el almacenamiento de proveedor de servicios criptográficos (CSP).
Resolución

En este caso, se recomienda usar certificados de CSP.

Solución 1

Para importar el certificado, ejecute el siguiente comando:

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

Solución 2

Para convertir el certificado, ejecute los siguientes comandos:

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

Antes y después de la conversión:

Entorno de ejecución de integración autohospedado, versión 5.x

La actualización a la versión 5.x del entorno de ejecución de integración autohospedado requiere el tiempo de ejecución de .NET Framework Runtime 4.7.2 o una versión posterior. En la página de descarga, habrá vínculos de descarga para la versión 4.x más reciente y las dos versiones 5.x más recientes.

Para clientes de Azure Data Factory v2 y Azure Synapse:

Si la actualización automática está activada y ya ha actualizado su entorno de tiempo de ejecución de .NET Framework a la versión 4.7.2 o posterior, el entorno de ejecución de integración autohospedado se actualizará automáticamente a la versión 5.x más reciente.
Si la actualización automática está activada y ya ha actualizado su entorno de tiempo de ejecución de .NET Framework a la versión 4.7.2 o posterior, el entorno de ejecución de integración autohospedado se actualizará automáticamente a la versión 5.x más reciente. El entorno de ejecución de integración autohospedado permanecerá en la versión 4.x actual. Verá una advertencia para la actualización del entorno de tiempo de ejecución de .NET Framework en el portal y en el cliente del entorno de ejecución de integración autohospedado.
Si la actualización automática está desactivada y ya ha actualizado el entorno de tiempo de ejecución de .NET Framework a la versión 4.7.2 o posterior, puede descargar manualmente la versión 5.x más reciente e instalarla en la máquina.
Si la actualización automática está desactivada y no ha actualizado el entorno de tiempo de ejecución de .NET Framework a la versión 4.7.2 o posterior, al intentar instalar manualmente el entorno de ejecución de integración autohospedado 5. x y registrar la clave, se le pedirá que actualice primero la versión del entorno de tiempo de ejecución de .NET Framework.

Problemas de conectividad de IR autohospedado

El entorno de ejecución de integración autohospedado no puede conectarse al servicio en la nube

Síntomas

Al intentar registrar el entorno de ejecución de integración autohospedado, Configuration Manager muestra el siguiente mensaje de error:

"El nodo de Integration Runtime (autohospedado) ha encontrado un error durante el registro".
Causa

El IR autohospedado no puede conectarse al back-end del servicio. Este problema se debe normalmente a la configuración de red en el firewall.
Resolución
1. Compruebe si el servicio de entorno de ejecución de integración está en ejecución. En caso afirmativo, vaya al paso 2.
2. Si no hay ningún proxy configurado en el IR autohospedado, que es la configuración predeterminada, ejecute el siguiente comando de PowerShell en la máquina donde está instalado el entorno de ejecución de integración autohospedado:
```
(New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")
```
  Nota
  
  La dirección URL del servicio puede variar en función de la ubicación de la instancia de área de trabajo de Data Factory o Synapse. Para dar con la dirección URL del servicio, use la página Administrar de la instancia de Data Factory o Synapse para buscar tiempos de ejecución de entornos y haga clic en su entorno de ejecución autohospedado para editarlo. Seleccione la pestaña Nodos y haga clic en View Service URLs (Ver direcciones URL de servicio).
  
  La respuesta esperada es la siguiente:
3. Si no recibe la respuesta que esperaba, use uno de los métodos siguientes, según corresponda:
  - Si recibe el mensaje "No se pudo resolver el nombre remoto", hay un problema con el sistema de nombres de dominio (DNS). Póngase en contacto con su equipo de redes para solucionar el problema.
  - Si recibe el error "El certificado SSL/TLS no es de confianza", compruebe el certificado (https://wu2.frontend.clouddatahub.net/) para ver si es de confianza en la máquina y luego instale el certificado público mediante el Administrador de certificados. Esta acción debería mitigar el problema.
  - Vaya a Windows>Visor de eventos (registros)>Registros de aplicaciones y servicios>Integration Runtime y compruebe si hay errores causados por DNS, una regla del firewall o la configuración de red de la empresa. Si encuentra este tipo de error, fuerce el cierre de la conexión. Dado que cada compañía tiene su propia configuración de red personalizada, póngase en contacto con su equipo de red para solucionar estos problemas.
4. Si el proxy se ha configurado en el entorno de ejecución de integración autohospedado, compruebe si el servidor proxy puede acceder al punto de conexión de servicio. Para ver un comando de ejemplo, consulte PowerShell, solicitudes web y servidores proxy.
```
$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
```
La respuesta esperada es la siguiente:
Nota

Consideraciones del proxy:
- Compruebe si el servidor proxy debe colocarse en la lista de destinatarios seguros. Si es así, asegúrese de que estos dominios estén en la lista de destinatarios seguros.
- Compruebe si el certificado TLS/SSL de wu2.frontend.clouddatahub.net/ es de confianza en el servidor proxy.
- Si usa la autenticación de Active Directory en el proxy, cambie la cuenta de servicio por la cuenta de usuario que pueda acceder al proxy como "Integration Runtime Service".

Mensaje de error: El nodo del entorno de ejecución de integración autohospedado/IR autohospedado lógico está en estado inactivo/"en ejecución (limitado)"

Causa

El nodo de tiempo de ejecución integrado autohospedado podría tener un estado Inactivo, como se muestra en la siguiente captura de pantalla:

Este comportamiento se produce cuando los nodos no pueden comunicarse entre sí.

Resolución

Inicie sesión en la máquina virtual (VM) hospedada en el nodo. En Registros de aplicaciones y servicios>Integration Runtime, abra el Visor de eventos y filtre los registros de errores.

Compruebe si el registro de errores contiene el error siguiente:

System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://xxxxxxx.bwld.com:8060/ExternalService.svc/WorkerManager. The connection attempt lasted for a time span of 00:00:00.9940994. TCP error code 10061: No connection could be made because the target machine actively refused it 10.2.4.10:8060. 
System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it. 
10.2.4.10:8060
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)

Si ve este error, ejecute el siguiente comando en una ventana del símbolo del sistema:
```
telnet 10.2.4.10 8060
```
Si recibe el error de la línea de comandos "Could not open connection to the host" (No se pudo abrir la conexión con el host) que se muestra en la siguiente captura de pantalla, póngase en contacto con el Departamento de TI para que le ayude a solucionar este problema. Una vez que pueda comunicarse con Telnet, póngase en contacto con Soporte técnico de Microsoft si todavía tiene problemas con el estado del nodo del entorno de ejecución de integración.

Compruebe si el registro de errores contiene la entrada siguiente:

Error log: Cannot connect to worker manager: net.tcp://xxxxxx:8060/ExternalService.svc/ No DNS entries exist for host azranlcir01r1. No such host is known Exception detail: System.ServiceModel.EndpointNotFoundException: No DNS entries exist for host xxxxx. ---> System.Net.Sockets.SocketException: No such host is known at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostEntry(String hostNameOrAddress) at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri) --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri)

Para solucionar este problema, pruebe uno de los métodos siguientes o ambos:
- Colocar todos los nodos en el mismo dominio
- Agregar la asignación de IP a host en todos los archivos de hosts de la máquina virtual hospedada

Problema de conectividad entre el IR autohospedado y la instancia de Data Factory o Azure Synapse, o entre el IR autohospedado y el origen o receptor de datos

Para solucionar el problema de conectividad de red, debe saber cómo recopilar el seguimiento de red, entender cómo usarlo y analizar el seguimiento de Monitor de red de Microsoft (Netmon) antes de aplicar las herramientas de Netmon en casos reales desde el IR autohospedado.

Síntomas

En ocasiones, es posible que necesite solucionar determinados problemas de conectividad entre el IR autohospedado y la instancia de Data Factory o Azure Synapse, como se muestra en la captura de pantalla siguiente, o entre el IR autohospedado y el origen o el receptor de datos.

En cualquier caso, puede que encuentre los siguientes errores:
- "Error de copia:Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=No se puede conectar a SQL Server: 'dirección IP'"
- "Se han producido uno o varios errores. Error al enviar la solicitud. Se ha cerrado la conexión subyacente: Error inesperado de recepción. No se pueden leer los datos de la conexión de transporte: El host remoto forzó el cierre de la conexión existente. El host remoto forzó el cierre de la conexión existente Id. de actividad."
Resolución

Cuando encuentre los errores anteriores, soluciónelos siguiendo las instrucciones de esta sección.
- Recopile un seguimiento de Netmon para el análisis:
  1. Puede establecer el filtro para ver un restablecimiento del servidor en el lado cliente. En la captura de pantalla de ejemplo siguiente, puede ver que el lado servidor es el servidor de Data Factory.
  2. Al obtener el paquete de restablecimiento, puede encontrar la conversación si sigue el Protocolo de control de transmisión (TCP).
  3. Para obtener la conversación entre el cliente y el servidor de Data Factory, quite el filtro.
- Un análisis del seguimiento de Netmon que ha recopilado muestra que el total del período de vida (TTL) es 64. Según los valores mencionados en el artículo de conceptos básicos del período de vida (TTL) de IP y límite de salto, como se extraen en la lista siguiente, se aprecia que es el sistema Linux el que restablece el paquete y provoca la desconexión.
  
  Los valores predeterminados de TTL y límite de salto varían entre distintos sistemas operativos, como se puede ver aquí:
  - Kernel de Linux 2.4 (2001 aproximadamente): 255 para TCP, Protocolo de datagramas de usuario (UDP) y Protocolo de mensajes de control de Internet (ICMP)
  - Kernel de Linux 4.10 (2015): 64 para TCP, UDP e ICMP
  - Windows XP (2001): 128 para TCP, UDP e ICMP
  - Windows 10 (2015): 128 para TCP, UDP e ICMP
  - Windows Server 2008: 128 para TCP, UDP e ICMP
  - Windows Server 2019 (2018): 128 para TCP, UDP e ICMP
  - macOS (2001): 64 para TCP, UDP e ICMP
  En el ejemplo anterior, el TTL se muestra como 61 en lugar de 64, porque cuando el paquete de red alcanza su destino, debe atravesar varios saltos, como enrutadores o dispositivos de red. El número de enrutadores o dispositivos de red se deduce para generar el TTL final.
  
  En este caso, se ve que es posible que el restablecimiento se haya enviado desde el sistema Linux con TTL 64.
- Para confirmar de dónde puede provenir el dispositivo de restablecimiento, compruebe el cuarto salto desde el IR autohospedado.
  
  Paquete de red del sistema Linux A con TTL 64 -> B TTL 64 menos 1 = 63 -> C TTL 63 menos 1 = 62 -> TTL 62 menos 1 = 61 IR autohospedado
- En una situación ideal, el número de saltos de TTL sería 128, lo que significa que el sistema operativo Windows está ejecutando la instancia de Data Factory. Como se muestra en el ejemplo siguiente, 128 menos 107 = 21 saltos, es decir, se enviaron 21 saltos para el paquete desde la instancia de Data Factory al IR autohospedada durante el protocolo de enlace de TCP 3.
  
  Por tanto, debe comunicarle al equipo de red que compruebe cuál es el cuarto salto desde el IR autohospedado. Si es el firewall, como con el sistema Linux, compruebe en los registros por qué el dispositivo restablece el paquete después del protocolo de enlace TCP 3.
  
  Si no está seguro de dónde investigar, intente obtener el seguimiento de Netmon tanto desde el IR autohospedado como desde el firewall durante el tiempo problemático. Este enfoque le ayudará a averiguar qué dispositivo podría haber restablecido el paquete y causado la desconexión. En este caso, también debe indicarle al equipo de red que avance.

Análisis del seguimiento de Netmon

Nota

Las siguientes instrucciones se aplican al seguimiento de Netmon. Dado que el seguimiento de Netmon no recibe actualmente soporte técnico, puede usar Wireshark a tales efectos.

Al intentar conectarse mediante Telnet a 8.8.8.8 888 con el seguimiento de Netmon recopilado, debería ver el seguimiento en las siguientes capturas de pantallas:

Captura de pantalla que muestra el mensaje de error "No se pudo abrir la conexión con el host en el puerto 888".

Captura de pantalla que muestra una descripción del seguimiento de Netmon.

Las imágenes anteriores muestran que no pudo establecer una conexión TCP con el lado servidor 8.8.8.8 en el puerto 888, por lo que ve dos paquetes SynReTransmit adicionales. Dado que el origen SELF-HOST2 no se pudo conectar a 8.8.8.8 con el primer paquete, seguirá intentando establecer la conexión.

Sugerencia

Para establecer esta conexión, pruebe la siguiente solución:

Seleccione Cargar filtro>Filtro estándar>Direcciones>Direcciones IPv4.
Para aplicar el filtro, escriba IPv4.Address == 8.8.8.8 y, después, seleccione Aplicar. A continuación, debería ver la comunicación desde la máquina local al destino 8.8.8.8.

Captura de pantalla que muestra las direcciones de filtrado

Captura de pantalla que muestra más direcciones de filtrado

En los ejemplos siguientes se muestran los escenarios correctos:

Si puede conectarse mediante Telnet a 8.8.8.8 53 sin problemas, hay un protocolo de enlace de TCP 3 correcto, y la sesión finaliza con un protocolo de enlace TCP 4.
El protocolo de enlace TCP 3 anterior produce el siguiente flujo de trabajo:
El protocolo de enlace TCP 4 para finalizar la sesión se muestra en los siguientes flujos de trabajo:

Determinación de si esta notificación le afecta

Esta notificación se aplica a los escenarios siguientes:

Escenario 1: comunicación saliente desde un entorno de ejecución de integración autohospedado que se ejecuta en el entorno local detrás de un firewall corporativo

Cómo determinar si se ve afectado:

No se verá afectado si define reglas de firewall basadas en nombres de dominio completos (FQDN) que usen el enfoque descrito en Configuraciones de firewall y configuración de direcciones IP permitidas.
Se verá afectado si habilita de forma explícita la lista de direcciones IP de salida permitidas en el firewall corporativo.

Si se ve afectado, adopte la medida siguiente: pida al equipo de infraestructura de red que actualice la configuración de red para usar las direcciones IP de Data Factory más recientes antes del 8 de noviembre de 2020. Para descargar las direcciones IP más recientes, vaya a Detección de etiquetas de servicio mediante archivos JSON descargables.

Escenario 2: comunicación saliente desde un entorno de ejecución de integración autohospedado que se ejecuta en una VM de Azure dentro de una red virtual de Azure administrada por el cliente

Cómo determinar si se ve afectado:

Compruebe si tiene reglas de grupo de seguridad de red (NSG) de salida en una red privada que contiene el entorno de ejecución de integración autohospedado. Si no hay restricciones de salida, no se verá afectado.
Si tiene restricciones de reglas de salida, compruebe si usa etiquetas de servicio. Si usa etiquetas de servicio, no se verá afectado. No es necesario cambiar ni agregar nada, ya que el nuevo intervalo IP está bajo las etiquetas de servicio existentes.
Se verá afectado si habilita de forma explícita la lista de direcciones IP salientes permitidas en la configuración de las reglas de NSG en la red virtual de Azure.

Si se ve afectado, adopte la medida siguiente: pida al equipo de infraestructura de red que actualice las reglas de NSG en la configuración de red virtual de Azure para usar las direcciones IP de Data Factory más recientes antes del 8 de noviembre de 2020. Para descargar las direcciones IP más recientes, vaya a Detección de etiquetas de servicio mediante archivos JSON descargables.

Escenario 3: comunicación saliente de SSIS Integration Runtime en una red virtual de Azure administrada por el cliente

Cómo determinar si se ve afectado:

Compruebe si tiene reglas de NSG de salida en una red privada que contiene SQL Server Integration Services (SSIS) Integration Runtime. Si no hay restricciones de salida, no se verá afectado.
Si tiene restricciones de reglas de salida, compruebe si usa etiquetas de servicio. Si usa etiquetas de servicio, no se verá afectado. No es necesario cambiar ni agregar nada, ya que el nuevo intervalo IP está bajo las etiquetas de servicio existentes.
Se verá afectado si habilita de forma explícita la lista de direcciones IP salientes permitidas en la configuración de las reglas de NSG en la red virtual de Azure.

Si se ve afectado, adopte la medida siguiente: pida al equipo de infraestructura de red que actualice las reglas de NSG en la configuración de red virtual de Azure para usar las direcciones IP de Data Factory más recientes antes del 8 de noviembre de 2020. Para descargar las direcciones IP más recientes, vaya a Detección de etiquetas de servicio mediante archivos JSON descargables.

No se pudo establecer una relación de confianza para el canal seguro SSL/TLS

Síntomas

El IR autohospedado no puede conectarse al servicio Azure Data Factory o Azure Synapse.

Al comprobar el registro de eventos de IR autohospedado después de ir a Windows>Visor de eventos (registros)>Registros de aplicaciones y servicios>Integration Runtime, encontrará el siguiente mensaje de error.

"The underlying connection was closed: No se ha podido establecer la relación de confianza para el canal seguro SSL/TLS. El certificado remoto no es válido según el procedimiento de validación".

La manera más sencilla de comprobar el certificado de servidor del servicio es abrir la dirección URL del servicio en el explorador. Por ejemplo, abra el vínculo (https://eu.frontend.clouddatahub.net/) para comprobar el certificado de servidor en la máquina donde está instalado el IR autohospedado y, a continuación, vea la información del certificado de servidor.
Causa

Este problema se debe a dos motivos posibles:
- Motivo 1: la CA raíz del certificado de servidor del servicio no es de confianza en la máquina donde está instalado el IR autohospedado.
- Motivo 2: está usando un proxy en el entorno, el certificado de servidor del servicio se sustituye por el proxy y el certificado de servidor reemplazado no es de confianza en el equipo donde el IR autohospedado está instalado.
Resolución
- Para el motivo 1, asegúrese de que el certificado de servidor del servicio y su cadena de certificados sean de confianza en el equipo donde el IR autohospedado está instalado.
- Para el motivo 2, confíe en la CA raíz reemplazada en el equipo con el IR autohospedado, o bien configure el proxy para que no reemplace el certificado de servidor del servicio.
Para obtener más información sobre la confianza de certificados en Windows, consulte Instalación del certificado raíz de confianza.
Información adicional
Hemos implementado un nuevo certificado SSL, que se firma desde DigiCert. Compruebe si DigiCert Global Root G2 está en la CA raíz de confianza.

Si no está en la CA raíz de confianza, descárguelo aquí.

Para obtener más ayuda para solucionar problemas, pruebe los siguientes recursos:

Compartir vía

Solución de problemas del entorno de ejecución de integración autohospedado

Recopilación de registros de IR autohospedado