Solución al error “The tenant admin disabled this bot” en extensiones de mensajes de Microsoft Teams (incidente TM710191)

¿Tu extensión de mensajes para Microsoft Teams funcionaba en local pero en el entorno de desarrollo muestra “The tenant admin disabled this bot”? A continuación encontrarás una guía completa que explica por qué ocurre, cómo se relaciona con la incidencia TM710191 y qué pasos adoptar para garantizar que tu bot vuelva a funcionar y evites futuras sorpresas.

Interpretación del error “The tenant admin disabled this bot”

Cuando pruebas una Message Extension (ME) fuera de tu máquina de desarrollo y las búsquedas devuelven un bloque JSON similar al siguiente, la IU de Teams suele mostrar el mensaje genérico “The tenant admin disabled this bot”:

{
  "errorCode": 0,
  "standardizedError": {
    "errorCode": 209,
    "errorSubCode": 1,
    "errorDescription": "..."
  }
}

El código 209 dentro de standardizedError es una pista de que Teams no ha podido ejecutar la operación contra el bot registrado en tu inquilino. Puede deberse a un bloqueo administrativo, a un manifiesto incompleto o, como sucedió con la incidencia TM710191, a un problema de infraestructura que afectó a varios tenants.

Causa raíz: incidente de servicio TM710191

El 15 de julio de 2025, Microsoft reconoció en el Service Health Dashboard un incidente de plataforma (identificador TM710191) que provocaba errores al invocar bots y extensiones de mensajes en un subconjunto de inquilinos de Microsoft 365. El equipo de ingeniería revirtió una actualización problemática y comunicó que el impacto había quedado mitigado tras restaurar la versión anterior.

Los puntos esenciales del comunicado fueron:

• La interrupción afectaba solo a determinados tenants y no estaba vinculada a cambios locales del código de los desarrolladores.
• Tras revertir el despliegue, los bots y message extensions volvieron a funcionar sin requerir ninguna acción de los clientes.
• Se recomendó a los administradores comprobar que el incidente apareciera como “Service health restored” en su panel antes de retomar las pruebas.

Cómo verificar si TM710191 afectó a tu proyecto

1. Ingresa al Microsoft 365 admin center con privilegios de administrador global o de Teams.
2. Accede a Health > Service health.
3. Filtra por Teams y busca el identificador TM710191. Si figura como Resolved o Service Restored, tu entorno ya no debería presentar los síntomas descritos.
4. Repite la prueba de la extensión de mensajes en un equipo o chat de prueba. Si las búsquedas responden correctamente, la causa era el incidente de Microsoft.

Procedimiento de recuperación y validación

El propio autor del post original confirmó que, una vez marcada como resuelta la TM710191, su extensión volvió a comportarse de forma normal. No obstante, cuando planifiques la publicación de tu ME en entornos de prueba o producción, sigue los pasos sistemáticos que se exponen abajo para acelerar la detección de la causa cuando aparezcan errores 209.

Elemento a revisar	Ubicación	Impacto típico
Estado del servicio Teams	Service Health Dashboard	Errores 209 generalizados para bots y MEs
Políticas de app permission	Teams Admin Center > Teams apps > Permission policies	ME no visible para los usuarios
Políticas de setup	Teams Admin Center > Teams apps > Setup policies	ME sin fijar en el cliente de Teams
Registro de la aplicación en Entra ID	Azure Portal > Entra ID > App registrations	Scope incorrecto o consent pendiente
Manifiesto de la app	Archivo manifest.json	Error 209 por campos faltantes o dominios no válidos
Versión de Teams Toolkit	NPM/Visual Studio Code	Diferencias entre debug local y empaquetado

Guía detallada de comprobación

Permisos y políticas en Teams

Cada bot o ME debe estar autorizado por las políticas de aplicaciones de tu tenant. Incluso si el incidente TM710191 causó la primera interrupción, un ajuste posterior en las políticas podría provocarte el mismo síntoma:

• Permission policies definen si la aplicación está Allowed, Blocked o Allowed for specific users.
• Setup policies determinan dónde aparece la ME (por ejemplo, anclada en la barra de redacción).
• Tras cada cambio, espera al menos 30 minutos o fuerza la renovación de caché cerrando sesión y reiniciando el cliente de Teams.

Configuración en Entra ID (antes Azure AD)

El registro de la aplicación controla la identidad del bot:

Application (client) ID y Tenant ID deben coincidir con los declarados en el manifiesto.
Si usas api://{app-id} como Application ID URI, asegúrate de que tu código envíe el mismo .

Comprueba igualmente:

• Que al menos un administrador haya otorgado consentimiento a los scopes requeridos.
• Que los redirect URIs incluyan la URL de la ME si implementas flujos OAuth.

Manifiesto actualizado

Microsoft Teams evolucionó su esquema; si mantienes un proyecto heredado, algunos campos ahora son obligatorios:

• validDomains declara expresamente los dominios externos de tu servicio.
• authorization establece el esquema de autenticación para escenarios SSO.
• webApplicationInfo es necesario cuando activas AAD app single sign-on.

Un manifiesto incompleto o con propiedades obsoletas genera el error 209 al desplegar el paquete .zip en el tenant.

Concordancia entre código y empaquetado

En modo debug local, Teams intercepta llamadas a través de un reverse proxy de la Toolkit, lo que enmascara discrepancias de URL o versión del SDK. Al empaquetar la app para un entorno de desarrollo, esas discrepancias emergen. Por ello:

• Actualiza a la versión estable más reciente de Teams Toolkit y verifica que el esquema de manifiesto corresponda a v1.16 (o la última estable al momento de leer este artículo).
• Prueba la extensión en un equipo mínimo (p. ej., “DevTesting”) antes de exponerla a más usuarios.

Estrategia de mitigación continua

Aunque TM710191 ya esté resuelta, adopta estas medidas para reducir tu tiempo medio de recuperación (MTTR) ante futuros incidentes:

1. Alertas proactivas del servicio
   Configura notificaciones por correo o Teams desde el Microsoft 365 admin center para recibir alertas cuando surja una incidencia de Teams.
2. Automatiza pruebas de salud
   Programa un flujo (p. ej., Power Automate o un job GitHub Actions) que invoque periódicamente tu ME en un canal de prueba y registre la respuesta. Si detecta un standardizedError.errorCode = 209, genera una alerta interna.
3. Documenta rutas de escalación
   Incluye en tu runbook la URL directa al foro “Teams Developer – Microsoft Community Hub” y los comandos de soporte (get-help) que aceleran la apertura de un ticket en el Centro de Administración.
4. Aisla entornos
   Mantén entornos de dev, test y prod en tenants o sandboxes separados. Así podrás descartar causas relacionadas con permisos o políticas propias de cada fase.

Preguntas frecuentes

¿Puedo seguir usando ngrok o un túnel externo?

Sí, pero declara el dominio de ngrok en validDomains. Además, al cambiar la URL de reenvío, regenera y vuelve a cargar el paquete .zip en Teams para que el manifiesto apunte a la nueva dirección.

¿Por qué funciona en local y no en dev?

En local, Teams Toolkit realiza bypasses de autenticación y PII-compliance que luego son estrictos al pasar por la nube de Microsoft. Los manifiestos incompletos o los scopes sin consentimiento suelen pasar desapercibidos hasta el primer despliegue en el tenant.

¿El error 209 siempre indica que el administrador deshabilitó el bot?

No. El texto “The tenant admin disabled this bot” agrupa varios escenarios: bloqueos de app, políticas, manifestos inválidos e incidentes de plataforma. Usa el bloque standardizedError para diferenciar cada caso.

Conclusiones

El incidente TM710191 demostró que incluso una Message Extension bien configurada puede fallar si la infraestructura de Teams sufre una regresión. Mantén la vigilancia en el Service Health Dashboard, documenta tu procedimiento de verificación y revisa sistemáticamente permisos, registro en Entra ID y manifiesto cada vez que surja el error 209. Con una estrategia de pruebas automatizadas y alertas proactivas reducirás al mínimo las interrupciones para los usuarios finales y agilizarás el ciclo de publicación de nuevas versiones.