La nueva transacción no se puede inscribir en el coordinador de transacciones especificado al intentar iniciar una transacción en MS DTC

Este artículo le ayuda a resolver un problema al iniciar una transacción en el Coordinador de transacciones distribuidas de Microsoft (MS DTC).

              Versión original del producto: Windows
Número de KB original: 922430

Importante

Este artículo contiene información sobre cómo modificar el Registro. Antes de modificar el Registro, asegúrese de hacer una copia de seguridad del mismo y Asegúrese de saber cómo recuperar el registro en caso de producirse algún problema. Para obtener más información sobre cómo realizar copias de seguridad, restaurar y modificar el Registro, vea Información del Registro de Windows para usuarios avanzados.

Síntomas

Imagine la siguiente situación:

  • Tiene un equipo cliente que se comunica con un equipo servidor.
  • MS DTC está instalado en ambos equipos.
  • Se cumplen una o varias de las condiciones siguientes:
    • Reinicie cualquiera de los equipos.
    • Reinicie MS DTC en cualquiera de los equipos.
    • Los equipos están en dominios diferentes.

En este escenario, recibirá el siguiente mensaje de error al intentar iniciar una transacción en MS DTC:

La nueva transacción no se puede inscribir en el coordinador de transacciones especificado (0x8004d00a)

Además, se produce un error en la primera transacción. Las transacciones posteriores se realizarán correctamente durante un tiempo. Sin embargo, las transacciones posteriores pueden producir un error de nuevo. Si se produce un error en las transacciones posteriores, recibirá el siguiente mensaje de error:

La nueva transacción no puede inscribirse en el coordinador de transacciones especificado (0x8004d00e)

Causa

Este problema puede producirse cuando se cierra la conexión de MS DTC entre el equipo cliente y el equipo servidor. Por ejemplo, un tiempo de espera de inactividad, una llamada a procedimiento remoto (RPC) o el firewall pueden cerrar la conexión de MS DTC entre el equipo cliente y el equipo servidor. Cuando se produce una nueva solicitud de transacción, el equipo cliente debe restablecer la conexión de MS DTC con el equipo servidor.

Cuando el equipo cliente intenta restablecer la conexión de MS DTC con el equipo servidor, el equipo cliente envía un paquete. A continuación, el equipo cliente espera una respuesta de paquete de enlace del equipo servidor. De forma predeterminada, el equipo cliente detiene la transacción si el equipo cliente no recibe una respuesta del equipo servidor en 4 segundos. La respuesta del equipo servidor puede retrasarse debido a problemas de latencia de red o retrasos de autenticación. Cuando la respuesta del equipo servidor llega finalmente al equipo cliente, las transacciones posteriores se completan correctamente.

La primera transacción puede tardar mucho tiempo y, a continuación, una solicitud posterior para realizar una transacción distribuida puede finalizar inmediatamente. Este problema puede producirse cuando el lado cliente de MS DTC tiene un problema de comunicación con el servidor Kerberos (KDC). Normalmente, este problema se produce si el cliente y el servidor están en dominios diferentes que tienen un firewall entre ellos.

Por ejemplo, este problema se produce en el siguiente escenario:

  • El servicio web está en la red perimetral de un dominio. El servicio web tiene que usar transacciones con un servidor de base de datos en otro dominio de una intranet.
  • Un firewall está entre la red perimetral y la intranet. El retraso excesivo en la primera transacción se produce porque el puerto 88 (Kerberos) del Protocolo de datagramas de usuario (UDP) está bloqueado.
  • El reintento y el intervalo de reintentos de la solicitud Kerberos equivalen a un retraso excesivo (más de 100 segundos).

Solución

Advertencia

Es posible que se produzcan problemas graves si modifica el Registro de forma incorrecta mediante el Editor del Registro u otro método. Estos problemas pueden requerir que reinstale el sistema operativo. Microsoft no puede garantizar la solución de estos problemas. Modifique el Registro bajo su propia responsabilidad.

Para asegurarse de que está experimentando el problema que se describe en este artículo, confirme que el archivo de registro de seguimiento de transacciones MS DTC contiene los datos siguientes:

; eventid=TRANSACTION_PROPOGATION_FAILED_CONNECTION_DOWN_FROM_REMOTE_TM ; tx_guid=f11cd9c9-7b8a-41e3-a904-4840123bacf7 ;" no se pudo propogar la transacción al nodo secundario " NombreDeEquipo " porque la conexión con el administrador de transacciones remotas se desintegró"

Nota:

En estos datos, la palabra propoción es un error ortográfico para la propagación de palabras. La palabra propogate es un error ortográfico de la palabra propagar.

Si el archivo de registro de seguimiento de transacciones MS DTC contiene estos datos, siga estos pasos:

  1. Seleccione Inicio, haga clic en Ejecutar, escriba regedit, y luego seleccione Aceptar.

  2. Busque la siguiente subclave del Registro:
    HKEY_LOCAL_MACHINE\Software\Microsoft\MSDTC

  3. Haga clic con el botón derecho en MSDTC, seleccione Nuevo y, a continuación, seleccione Valor DWORD.

  4. Escriba CmMaxNumberBindRetries y presione ENTRAR.

  5. Haga clic con el botón derecho en CmMaxNumberBindRetries y, a continuación, seleccione Modificar.

  6. Seleccione Decimal.

  7. En el cuadro Datos de valor , escriba 60.

    Este valor aumenta el tiempo que el equipo cliente espera la respuesta del paquete de enlace desde el equipo servidor. Este valor es el doble del número de segundos antes de que el equipo cliente detenga la transacción si el equipo cliente no recibe la respuesta del paquete de enlace. Por ejemplo, un valor de 60 es igual a 30 segundos. El valor de 60 es solo un valor recomendado. Es posible que se requieran pruebas adicionales en la configuración.

  8. Seleccione Aceptar.

  9. Reinicie MS DTC.

Nota:

Para el escenario de respuesta lenta, asegúrese de que los puertos necesarios para la autenticación Kerberos (UDP 88 y protocolo de control de transmisión (TCP) 88) estén abiertos cuando un firewall esté implicado en la red perimetral. Los puertos UDP 389 y TCP 389 (ambos para el protocolo ligero de acceso a directorios (LDAP) para buscar el Centro de distribución de claves (KDC)) también deben estar abiertos.