Guía de administración y troubleshooting de Microsoft 365 para helpdesk (2026)

Guía práctica para equipos de helpdesk con diagnóstico y resolución de problemas de Microsoft 365 en 2026. Cubre las interrupciones de enero, comandos PowerShell esenciales, migración de autenticación básica SMTP y estrategias de continuidad.

Introducción: El panorama actual de Microsoft 365 en entornos empresariales

A estas alturas, decir que Microsoft 365 es la plataforma de productividad dominante en el mundo corporativo no sorprende a nadie. Exchange Online, Teams, SharePoint Online, OneDrive for Business... millones de organizaciones dependen de estos servicios todos los días para funcionar. Pero aquí viene lo interesante: los eventos de enero de 2026 nos han dado una sacudida importante.

Interrupciones masivas que dejaron servicios esenciales caídos durante más de nueve horas. Sí, nueve horas.

Eso ha dejado claro algo que muchos ya sospechábamos: los equipos de soporte y helpdesk necesitan dominar a fondo las técnicas de diagnóstico, resolución de problemas y planificación de contingencia para Microsoft 365. No es opcional, es supervivencia.

Esta guía está pensada para administradores de TI, técnicos de helpdesk y equipos de soporte que se enfrentan día a día con los problemas más comunes de Microsoft 365 en 2026. Vamos a cubrir desde la monitorización del estado del servicio hasta la migración obligatoria a autenticación moderna, pasando por los problemas específicos de Outlook, Teams y Exchange Online que están dando dolores de cabeza este año.

Las interrupciones de enero de 2026: lecciones para el helpdesk

Qué ocurrió y por qué importa

El 22 de enero de 2026, Microsoft 365 sufrió una interrupción generalizada que comenzó sobre las 14:37 hora del Este de Estados Unidos. Los servicios afectados fueron prácticamente todos los importantes: Outlook, Exchange Online, Teams, SharePoint, OneDrive, Microsoft Defender y Purview. La cosa se prolongó durante casi diez horas, dejando a miles de organizaciones sin acceso a sus herramientas de comunicación y productividad.

¿La causa raíz? Durante trabajos de mantenimiento en un centro de datos en Norteamérica, se desactivaron demasiados servidores a la vez. Los sistemas restantes se vieron sobrecargados al intentar procesar un volumen de solicitudes muy superior al habitual. Para colmo, se identificó una configuración errónea en la capa de enrutamiento que se propagó por toda la infraestructura backbone, provocando fallos generalizados de inicio de sesión y tiempos de espera agotados.

Y lo más preocupante: no fue un incidente aislado. Fue la cuarta interrupción importante de Microsoft en enero de 2026. Este patrón expone algo que muchos arquitectos llevan tiempo señalando: mientras los proveedores de nube mantienen redundancias robustas a nivel de plano de datos (los servidores que almacenan y procesan información), el plano de control — que gestiona el enrutamiento de tráfico y la autenticación — a menudo representa un punto único de fallo.

Protocolo de respuesta para el helpdesk durante interrupciones

Cuando Microsoft 365 se cae, el pánico se extiende rápido. El equipo de helpdesk necesita un protocolo claro para no perder el control:

  1. Verificar el estado del servicio: Antes de ponerse a investigar problemas individuales, lo primero es confirmar en el Centro de administración de Microsoft 365 (admin.microsoft.com) si existe un incidente activo en Estado del servicio. Esto ahorra muchísimo tiempo.
  2. Comunicar proactivamente: Informar a los usuarios afectados que se trata de un problema del servicio, no de sus equipos. Créanme, esto reduce drásticamente el volumen de tickets.
  3. No tocar endpoints: Evitar reconstruir perfiles, reinstalar Office o modificar configuraciones de red durante una interrupción activa. Solo genera ruido diagnóstico adicional y complica todo después.
  4. Documentar la cronología: Registrar la hora de inicio, los servicios afectados y el número de usuarios reportando problemas. Esto es oro para el informe post-incidente.
  5. Activar canales alternativos: Si Teams está caído, hay que tener plan B. Correo externo, Slack, incluso llamadas telefónicas a la antigua usanza. Lo que funcione.

Monitorización del estado del servicio y alertas proactivas

Centro de administración de Microsoft 365

El primer recurso para cualquier administrador es el panel de Estado del servicio en el Centro de administración de Microsoft 365. Aquí se pueden ver incidentes activos, avisos y el historial de estado de cada servicio.

Para configurar alertas proactivas (y enterarse de los problemas antes que los usuarios):

  1. Acceda a admin.microsoft.com y navegue a Estado > Estado del servicio.
  2. Haga clic en Preferencias y active las notificaciones por correo electrónico.
  3. Configure los destinatarios (equipo de helpdesk, administradores de TI) y seleccione los servicios críticos a monitorizar.
  4. Habilite las notificaciones para incidentes, avisos y mantenimiento planificado.

Uso de PowerShell para monitorización avanzada

Si quiere ir un paso más allá, puede usar el módulo de PowerShell de Microsoft Graph para consultar el estado del servicio de forma programática. Honestamente, esto marca la diferencia entre un helpdesk reactivo y uno proactivo:

# Instalar el módulo de Microsoft Graph si no está instalado
Install-Module Microsoft.Graph -Scope CurrentUser

# Conectar con los permisos necesarios
Connect-MgGraph -Scopes "ServiceHealth.Read.All"

# Obtener el estado actual de todos los servicios
Get-MgServiceAnnouncementHealthOverview | Select-Object Service, Status

# Obtener incidentes activos con detalles
Get-MgServiceAnnouncementIssue -Filter "status ne 'resolved'" |
    Select-Object Title, Service, Status, StartDateTime |
    Format-Table -AutoSize

# Obtener los últimos avisos de servicio
Get-MgServiceAnnouncementMessage -Top 10 |
    Select-Object Title, StartDateTime, EndDateTime |
    Format-Table -AutoSize

Puede automatizar estas consultas con el Programador de tareas de Windows o un runbook de Azure Automation que envíe alertas por correo o a un canal de Teams cuando detecte problemas. Es una inversión de tiempo que se paga sola.

Herramienta de conectividad de red de Microsoft 365

Microsoft también ofrece una herramienta de prueba de conectividad accesible en connectivity.office.com. Ejecuta pruebas de diagnóstico desde la ubicación del usuario y evalúa la calidad de la conexión con los servicios de Microsoft 365, identificando problemas de latencia, enrutamiento y configuración de proxy. Es bastante útil para esos casos donde "Internet funciona pero Office no".

Problemas comunes de Outlook en 2026 y sus soluciones

Outlook no responde tras actualizaciones de enero de 2026

Este ha sido probablemente el problema estrella de enero de 2026. Outlook clásico deja de responder o directamente no se abre después de instalar las actualizaciones de seguridad de Windows del 13 de enero. Los síntomas típicos:

  • Outlook muestra "No responde" al intentar abrir la aplicación.
  • La aplicación se queda abierta en segundo plano sin mostrar la interfaz gráfica.
  • Los elementos enviados no aparecen en la carpeta correspondiente.
  • Bloqueos frecuentes al abrir o guardar archivos desde almacenamiento en la nube (OneDrive, Dropbox).

Este problema afecta especialmente a configuraciones con cuentas POP o archivos PST almacenados en OneDrive — una combinación más común de lo que uno pensaría.

Pasos de diagnóstico y resolución

Paso 1: Iniciar Outlook en modo seguro

:: Abrir el cuadro de diálogo Ejecutar (Win+R) y escribir:
outlook.exe /safe

Si Outlook funciona bien en modo seguro, el problema probablemente es un complemento. Hay que desactivarlos uno por uno desde Archivo > Opciones > Complementos hasta dar con el culpable.

Paso 2: Reparar el perfil de Outlook

  1. Cierre Outlook completamente.
  2. Abra el Panel de control > Correo (Microsoft Outlook).
  3. Haga clic en Perfiles > Propiedades > Archivos de datos.
  4. Seleccione el perfil afectado y haga clic en Reparar.

Paso 3: Ejecutar el Asistente de soporte y recuperación de Microsoft (SaRA)

SaRA es la herramienta oficial de diagnóstico de Microsoft y, sinceramente, funciona bastante bien para los problemas más comunes. Para entornos empresariales se puede ejecutar desde línea de comandos:

# Descargar e instalar SaRA en modo línea de comandos
# Ejecutar diagnóstico de Outlook
SaRAcmd.exe -S OlkCrash -AcceptEula

# Ejecutar diagnóstico de conectividad de Outlook
SaRAcmd.exe -S OlkCannotConnect -AcceptEula

Paso 4: Instalar la actualización fuera de banda KB5078127

Microsoft lanzó esta actualización el 24 de enero de 2026 para resolver específicamente los problemas con aplicaciones que dejaban de responder al interactuar con almacenamiento en la nube. Verifique que esté instalada:

# Verificar si la actualización KB5078127 está instalada
Get-HotFix -Id KB5078127

# Si no está instalada, instalar manualmente
wusa.exe KB5078127.msu /quiet /norestart

Fallos en conexiones remotas (RDP) tras la actualización de enero 2026

Otro efecto colateral: después de instalar la actualización de seguridad KB5074109, se reportaron fallos en las solicitudes de credenciales de aplicaciones de conexión remota, incluyendo Escritorio Remoto mediante Windows App, Azure Virtual Desktop y Windows 365. La solución es la misma: instalar la actualización fuera de banda KB5078127.

Diagnóstico y resolución de problemas en Microsoft Teams

Problemas de conectividad en Teams

Teams es una de esas aplicaciones que parece simple en la superficie pero por debajo depende de un montón de servicios: Exchange Online para calendarios y buzones, SharePoint Online para archivos y Microsoft Entra ID para autenticación. Un fallo en cualquiera de ellos puede manifestarse como un problema en Teams, lo que hace el diagnóstico especialmente complicado a veces.

Para diagnosticar problemas de conectividad:

  1. Verificar Autodiscover: Teams utiliza este servicio de Exchange para localizar la URL de EWS (Exchange Web Services). Se puede verificar con el Analizador de conectividad remota de Microsoft (testconnectivity.microsoft.com).
  2. Comprobar los endpoints de red: Teams requiere conectividad a múltiples endpoints. Este script ayuda a verificar lo básico:
# Verificar conectividad con endpoints críticos de Teams
$endpoints = @(
    "teams.microsoft.com",
    "login.microsoftonline.com",
    "graph.microsoft.com",
    "outlook.office365.com"
)

foreach ($endpoint in $endpoints) {
    $result = Test-NetConnection -ComputerName $endpoint -Port 443
    Write-Host "$endpoint : $($result.TcpTestSucceeded)" -ForegroundColor $(
        if ($result.TcpTestSucceeded) { "Green" } else { "Red" }
    )
}

Problemas de integración Teams-Exchange

Si los usuarios no ven sus calendarios en Teams, las reuniones no se sincronizan o la presencia no se actualiza, estos son los pasos a seguir:

  1. Verificar que el usuario tiene un buzón de Exchange Online activo.
  2. Comprobar que Autodiscover resuelve correctamente para el dominio.
  3. Revisar los permisos EWS del usuario:
# Conectar a Exchange Online PowerShell
Connect-ExchangeOnline

# Verificar la configuración EWS del usuario
Get-CASMailbox -Identity [email protected] |
    Select-Object EwsEnabled, EwsAllowOutlook, EwsAllowEntourage

# Verificar que EWS está habilitado a nivel de organización
Get-OrganizationConfig | Select-Object EwsEnabled, EwsApplicationAccessPolicy

Registros de diagnóstico de Teams

Para recopilar registros cuando un usuario tiene problemas persistentes en Teams:

  1. En la aplicación Teams, presione Ctrl+Alt+Shift+1 para generar registros de diagnóstico.
  2. Los registros se guardan en la carpeta de Descargas del usuario.
  3. También se puede ir a Configuración > General > Registros y hacer clic en Recopilar registros.

Administración de Exchange Online: comandos esenciales de PowerShell

Diagnóstico de problemas de flujo de correo

"No me llegan los correos" — posiblemente la frase más temida en cualquier helpdesk. Cuando un usuario reporta esto, el siguiente flujo de trabajo en PowerShell ayuda a identificar rápidamente dónde está el problema:

# Conectar a Exchange Online
Connect-ExchangeOnline -UserPrincipalName [email protected]

# Verificar el estado del buzón del usuario
Get-Mailbox -Identity [email protected] |
    Select-Object DisplayName, PrimarySmtpAddress, IsMailboxEnabled,
    ProhibitSendQuota, ProhibitSendReceiveQuota

# Verificar estadísticas del buzón (tamaño, elementos)
Get-MailboxStatistics -Identity [email protected] |
    Select-Object DisplayName, TotalItemSize, ItemCount, LastLogonTime

# Rastrear un mensaje específico en los últimos 7 días
Get-MessageTrace -SenderAddress [email protected] `
    -RecipientAddress [email protected] `
    -StartDate (Get-Date).AddDays(-7) `
    -EndDate (Get-Date) |
    Select-Object Received, SenderAddress, RecipientAddress, Subject, Status

# Verificar reglas de transporte que podrían bloquear correos
Get-TransportRule | Where-Object { $_.State -eq "Enabled" } |
    Select-Object Name, Priority, State, Mode |
    Format-Table -AutoSize

Gestión de cuarentena y filtrado

A veces el correo sí llega... pero queda atrapado en cuarentena. Para revisar mensajes que podrían estar siendo retenidos incorrectamente:

# Ver mensajes en cuarentena de un usuario específico
Get-QuarantineMessage -RecipientAddress [email protected] -Top 20 |
    Select-Object ReceivedTime, SenderAddress, Subject, QuarantineTypes |
    Format-Table -AutoSize

# Liberar un mensaje de cuarentena
Release-QuarantineMessage -Identity "mensaje-id" -ReleaseToAll

# Revisar políticas anti-spam activas
Get-HostedContentFilterPolicy |
    Select-Object Name, SpamAction, HighConfidenceSpamAction,
    BulkSpamAction, PhishSpamAction

Diagnósticos automáticos del Centro de administración

Algo que no todo el mundo sabe es que Microsoft proporciona diagnósticos automatizados directamente en el Centro de administración de Microsoft 365. Usan análisis avanzado para detectar problemas conocidos, validar configuraciones y dar instrucciones paso a paso. Algunos de los más útiles:

  • Verificación de dominio aceptado: Confirma que un dominio está correctamente configurado para prevenir fallos de entrega.
  • Prueba de RBAC de EXO para usuario: Verifica si un usuario tiene permisos para ejecutar cmdlets específicos de PowerShell.
  • Validación de DKIM: Comprueba la configuración de DomainKeys Identified Mail y verifica los registros DNS.
  • Diagnóstico de flujo de correo: Identifica problemas en la entrega de mensajes y sugiere soluciones.

Migración obligatoria: adiós a la autenticación básica SMTP

Cronograma y alcance del cambio

Bueno, hablemos del elefante en la habitación. Uno de los cambios más críticos para los administradores de TI en 2026 es la eliminación definitiva de la autenticación básica para SMTP AUTH en Exchange Online. El cronograma es claro:

  • 1 de marzo de 2026: Microsoft empezará a rechazar un porcentaje pequeño de envíos SMTP con autenticación básica. Esto permite monitorizar el impacto e identificar sistemas que necesiten migración acelerada.
  • 30 de abril de 2026: Se alcanza el 100% de rechazo. Fin de la historia.

Después de esa fecha, cualquier aplicación que intente usar SMTP AUTH con credenciales básicas recibirá el error: 550 5.7.30 Basic authentication is not supported for Client Submission.

Por qué se elimina la autenticación básica

La autenticación básica es un método heredado que, para ser directos, envía nombres de usuario y contraseñas prácticamente en texto plano. Esto la hace vulnerable a:

  • Robo de credenciales mediante ataques de intermediario (man-in-the-middle).
  • Ataques de fuerza bruta y rociado de contraseñas (password spraying).
  • Phishing y reutilización de credenciales.
  • Evasión de la autenticación multifactor (MFA), que es particularmente grave.

Identificar qué sistemas utilizan autenticación básica

Antes de migrar, hay que hacer los deberes: identificar todos los sistemas y aplicaciones que actualmente usan SMTP AUTH con autenticación básica. Es sorprendente la cantidad de cosas que se descubren cuando uno se pone a buscar:

# Verificar qué buzones tienen SMTP AUTH habilitado
Get-CASMailbox -ResultSize Unlimited |
    Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
    Select-Object DisplayName, PrimarySmtpAddress,
    SmtpClientAuthenticationDisabled |
    Export-Csv -Path "SmtpAuthBuzones.csv" -NoTypeInformation

# Consultar los registros de inicio de sesión para identificar
# conexiones con autenticación básica
# (Desde el Centro de administración de Entra ID)
# Navegar a: Entra ID > Supervisión > Registros de inicio de sesión
# Filtrar por: Aplicación cliente = "SMTP autenticado"
# y "Autenticación heredada"

# Verificar la configuración a nivel de organización
Get-TransportConfig | Select-Object SmtpClientAuthenticationDisabled

Opciones de migración

Las organizaciones tienen varias alternativas para reemplazar la autenticación básica. Vamos a repasarlas:

Opción 1: OAuth 2.0 (la recomendada)

La opción preferida es migrar a OAuth 2.0. Las aplicaciones y dispositivos deben usar OAuth como método de autenticación al emplear SMTP AUTH para enviar correo:

# Ejemplo de configuración para una aplicación que utiliza OAuth 2.0
# con SMTP AUTH en Python
import smtplib
from msal import ConfidentialClientApplication

# Configuración de la aplicación registrada en Entra ID
app = ConfidentialClientApplication(
    client_id="su-client-id",
    client_credential="su-client-secret",
    authority="https://login.microsoftonline.com/su-tenant-id"
)

# Obtener token de acceso
result = app.acquire_token_for_client(
    scopes=["https://outlook.office365.com/.default"]
)

access_token = result["access_token"]

# Conectar usando OAuth XOAUTH2
server = smtplib.SMTP("smtp.office365.com", 587)
server.starttls()
server.ehlo()

# Autenticación con XOAUTH2
auth_string = f"[email protected]\x01auth=Bearer {access_token}\x01\x01"
server.docmd("AUTH", "XOAUTH2 " + base64.b64encode(
    auth_string.encode()).decode())

server.sendmail(
    "[email protected]",
    "[email protected]",
    mensaje
)
server.quit()

Opción 2: Correo electrónico de alto volumen para Microsoft 365

Si se utiliza autenticación básica con SMTP AUTH para enviar correos a destinatarios internos del inquilino, se puede usar el servicio de Correo electrónico de alto volumen de Microsoft 365.

Opción 3: Azure Communication Services Email

Para enviar correos a destinatarios tanto internos como externos, Azure Communication Services Email ofrece una API moderna y escalable. Es una buena opción para aplicaciones que necesitan enviar grandes volúmenes.

Opción 4: Solución híbrida con Exchange Server local

Si tiene un Exchange Server local en configuración híbrida, puede usar autenticación básica con el servidor local o configurar un conector de recepción que permita la retransmisión anónima.

Dispositivos que requieren atención especial

Estos son los que más dolores de cabeza suelen dar con este cambio (y es mejor abordarlos cuanto antes):

  • Impresoras multifunción (MFP): La mayoría de las impresoras con "Escanear a correo electrónico" usan SMTP AUTH con autenticación básica. Hay que consultar con el fabricante si el firmware soporta OAuth 2.0 o, como alternativa, configurar un conector de retransmisión SMTP local.
  • Aplicaciones de línea de negocio (LOB): Sistemas ERP, CRM y otras aplicaciones que envían notificaciones por correo.
  • Scripts y automatizaciones: Scripts de PowerShell, Python o Bash que envían correos a través de SMTP. Estos suelen ser los más fáciles de actualizar, pero también los más fáciles de olvidar.
  • Sistemas de monitorización: Nagios, Zabbix, PRTG y otras plataformas de alertas por correo.

Diagnóstico de red y conectividad para Microsoft 365

Verificación de endpoints y puertos necesarios

Microsoft 365 necesita conectividad a un buen número de endpoints a través de puertos específicos. Una configuración incorrecta del firewall o del proxy puede causar problemas intermitentes que son especialmente difíciles de diagnosticar:

# Script de PowerShell para verificar conectividad con endpoints críticos
$m365Endpoints = @(
    @{Host="outlook.office365.com"; Port=443; Servicio="Exchange Online"},
    @{Host="smtp.office365.com"; Port=587; Servicio="SMTP"},
    @{Host="login.microsoftonline.com"; Port=443; Servicio="Autenticación"},
    @{Host="graph.microsoft.com"; Port=443; Servicio="Microsoft Graph"},
    @{Host="teams.microsoft.com"; Port=443; Servicio="Teams"},
    @{Host="*.sharepoint.com"; Port=443; Servicio="SharePoint"},
    @{Host="admin.microsoft.com"; Port=443; Servicio="Admin Center"}
)

Write-Host "=== Diagnóstico de conectividad Microsoft 365 ===" -ForegroundColor Cyan
Write-Host ""

foreach ($ep in $m365Endpoints) {
    if ($ep.Host -notlike "*`**") {
        $test = Test-NetConnection -ComputerName $ep.Host -Port $ep.Port -WarningAction SilentlyContinue
        $status = if ($test.TcpTestSucceeded) { "OK" } else { "FALLO" }
        $color = if ($test.TcpTestSucceeded) { "Green" } else { "Red" }
        Write-Host "[$status] $($ep.Servicio) ($($ep.Host):$($ep.Port)) - Latencia: $($test.PingReplyDetails.RoundtripTime)ms" -ForegroundColor $color
    }
}

# Verificar resolución DNS
Write-Host ""
Write-Host "=== Verificación DNS ===" -ForegroundColor Cyan
$dnsTests = @("outlook.office365.com", "autodiscover.dominio.com", "login.microsoftonline.com")
foreach ($dns in $dnsTests) {
    try {
        $resolve = Resolve-DnsName -Name $dns -ErrorAction Stop
        Write-Host "[OK] $dns -> $($resolve[0].IPAddress)" -ForegroundColor Green
    } catch {
        Write-Host "[FALLO] $dns - No se puede resolver" -ForegroundColor Red
    }
}

Configuración de proxy y SSL inspection

Uno de los problemas más habituales en entornos empresariales (y que más tiempo consume diagnosticar) es la inspección SSL que interfiere con los servicios de Microsoft 365. Si la organización utiliza un proxy que intercepta tráfico SSL, hay que asegurarse de excluir estos dominios:

  • *.office365.com
  • *.office.com
  • *.microsoftonline.com
  • *.microsoft.com
  • *.windows.net
  • device.login.microsoftonline.com
  • enterpriseregistration.windows.net

Planificación de continuidad y resiliencia

Estrategia multi-capa para interrupciones

Después de lo vivido en enero de 2026, ya no hay excusa para no tener una estrategia de resiliencia sólida. Aquí va un enfoque en capas que funciona:

Capa 1: Monitorización proactiva

  • Configurar alertas de Estado del servicio en el Centro de administración.
  • Implementar monitorización sintética de endpoints críticos.
  • Suscribirse a las actualizaciones de estado en redes sociales (@MSFT365Status en X).
  • Usar herramientas como Downdetector para detectar interrupciones antes de que lleguen los tickets.

Capa 2: Comunicación durante incidentes

  • Mantener una lista de distribución actualizada del personal de TI y gerencia.
  • Tener plantillas de comunicación preparadas para diferentes tipos de interrupciones. Cuando todo se cae no es el momento de ponerse creativo con los emails.
  • Establecer canales de comunicación alternativos que no dependan de Microsoft 365.
  • Designar un punto de contacto único para comunicación externa durante incidentes.

Capa 3: Soluciones de respaldo

  • Evaluar soluciones multi-nube o híbridas para servicios críticos.
  • Mantener un servidor de correo local como contingencia para comunicaciones críticas.
  • Implementar almacenamiento local sincronizado para archivos esenciales.
  • Probar regularmente los mecanismos de conmutación por error (failover). Que existan no significa que funcionen.

Documentación y procedimientos estándar

Cada equipo de helpdesk debería tener un manual de procedimientos que incluya:

  1. Ruta de escalamiento documentada: Desde autoayuda del usuario, pasando por soporte de nivel 1 (helpdesk), nivel 2 (administradores) hasta soporte de Microsoft o partners certificados.
  2. Runbooks para escenarios comunes: Procedimientos paso a paso para los 10 problemas más frecuentes de Microsoft 365.
  3. Matriz de contactos: Nombres, correos y teléfonos de los responsables de cada servicio.
  4. Inventario de dependencias: Qué aplicaciones de negocio dependen de qué servicios de Microsoft 365. Este punto es crítico y muchas organizaciones lo pasan por alto.

Mejores prácticas para el helpdesk en 2026

Triaje eficiente de tickets relacionados con Microsoft 365

Para clasificar rápidamente si un problema es local o del servicio, estas cuatro preguntas funcionan como un filtro bastante eficaz:

  1. ¿Afecta a un solo usuario o a varios? Si es a varios, verificar Estado del servicio de inmediato.
  2. ¿Funciona en la versión web? Si outlook.office.com o teams.microsoft.com funcionan bien, el problema es de la aplicación de escritorio.
  3. ¿Funciona en otra red? Por ejemplo, con datos móviles. Si funciona fuera de la red corporativa, el problema es de red.
  4. ¿Cuándo empezó? Correlacionar con actualizaciones recientes de Windows u Office. Muchas veces la respuesta está ahí.

Herramientas esenciales para el técnico de helpdesk

Todo técnico que soporte Microsoft 365 debería tener estas herramientas en su arsenal y saber usarlas:

  • Microsoft Support and Recovery Assistant (SaRA): Diagnostica y repara problemas comunes de Outlook, Teams y OneDrive automáticamente.
  • Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com): Prueba la conectividad de Autodiscover, Exchange ActiveSync y otros protocolos.
  • Centro de administración de Microsoft 365: Panel de Estado del servicio y diagnósticos integrados.
  • Exchange Online PowerShell: Cmdlets para diagnóstico avanzado de buzones, flujo de correo y configuraciones.
  • dsregcmd /status: Para verificar el estado del registro del dispositivo en Microsoft Entra ID. Es especialmente útil cuando hay problemas de Hybrid Join.
  • Visor de eventos de Windows: Los registros en Registros de aplicaciones y servicios > Microsoft > Windows > Registro de dispositivos de usuario a veces tienen la respuesta que nadie más encontró.

Capacitación continua del equipo

El ecosistema de Microsoft 365 cambia constantemente. Lo que funcionaba hace seis meses puede que ya no aplique. Para mantener al equipo actualizado:

  • Seguir el Centro de mensajes en el Centro de administración para cambios planificados.
  • Revisar periódicamente el Roadmap de Microsoft 365 (microsoft.com/microsoft-365/roadmap).
  • Participar en la comunidad técnica de Microsoft (techcommunity.microsoft.com) para compartir experiencias.
  • Programar sesiones mensuales de actualización técnica. Media hora al mes dedicada a revisar cambios recientes puede ahorrar horas de troubleshooting después.

Gestión de licencias y problemas de aprovisionamiento

Diagnóstico de problemas de licencias

Puede sonar trivial, pero uno de los motivos más frecuentes por los que un usuario no puede acceder a un servicio de Microsoft 365 es simplemente un problema de licencia. Licencia expirada, plan que no incluye el servicio, error de asignación... el clásico "tiene que ser algo más complicado" cuando en realidad la respuesta estaba en lo más obvio.

Para verificar el estado de licencias mediante PowerShell:

# Conectar a Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All", "Directory.Read.All"

# Verificar las licencias asignadas a un usuario específico
$usuario = Get-MgUser -UserId "[email protected]" -Property DisplayName, AssignedLicenses, AssignedPlans
$usuario | Select-Object DisplayName

# Ver detalles de licencias asignadas
Get-MgUserLicenseDetail -UserId "[email protected]" |
    Select-Object SkuPartNumber, SkuId |
    Format-Table -AutoSize

# Ver planes de servicio habilitados y deshabilitados
Get-MgUserLicenseDetail -UserId "[email protected]" |
    ForEach-Object {
        $_.ServicePlans | Select-Object ServicePlanName, ProvisioningStatus
    } | Format-Table -AutoSize

# Buscar usuarios sin licencia asignada
Get-MgUser -All -Property DisplayName, UserPrincipalName, AssignedLicenses |
    Where-Object { $_.AssignedLicenses.Count -eq 0 } |
    Select-Object DisplayName, UserPrincipalName |
    Export-Csv -Path "UsuariosSinLicencia.csv" -NoTypeInformation

Errores comunes de aprovisionamiento

Cuando una licencia se asigna pero el servicio no se activa, el estado de aprovisionamiento puede mostrar PendingInput, Disabled o Error. Las causas más comunes:

  • Conflicto de licencias: El usuario tiene dos planes que incluyen el mismo servicio con diferentes niveles. Por ejemplo, un plan E3 y un complemento de Exchange Online Plan 2.
  • Ubicación de uso no configurada: Microsoft 365 requiere que cada usuario tenga una ubicación de uso (UsageLocation) configurada antes de poder asignar licencias. Es un requisito que se olvida con frecuencia.
  • Licencias insuficientes: El inquilino ha consumido todas las licencias disponibles.
  • Grupos de licencias en conflicto: Con la asignación basada en grupos, pueden surgir conflictos si un usuario pertenece a múltiples grupos con asignaciones incompatibles.

Para resolver un conflicto de ubicación de uso:

# Verificar y establecer la ubicación de uso
Get-MgUser -UserId "[email protected]" -Property UsageLocation |
    Select-Object UsageLocation

# Establecer la ubicación de uso (ejemplo: España)
Update-MgUser -UserId "[email protected]" -UsageLocation "ES"

Seguridad y acceso condicional: problemas frecuentes

Bloqueos por políticas de acceso condicional

Las políticas de acceso condicional de Microsoft Entra ID son fundamentales para la seguridad, pero también son una fuente constante de tickets cuando están mal configuradas o cuando los usuarios no cumplen los requisitos. Los síntomas más comunes (y que seguramente le resultarán familiares):

  • El usuario puede iniciar sesión desde la oficina pero no desde casa.
  • Puede acceder a Outlook pero no a SharePoint.
  • Recibe el error "No cumple con los requisitos de la directiva de su organización".
  • La MFA se solicita repetidamente sin aceptar la verificación.

Para diagnosticar estos problemas, los registros de inicio de sesión son clave:

  1. Navegue a Entra ID > Supervisión > Registros de inicio de sesión.
  2. Busque el usuario afectado y localice el intento fallido.
  3. Revise la pestaña Acceso condicional para ver qué políticas se evaluaron y cuáles fallaron.
  4. Compruebe la pestaña Detalles de autenticación para entender qué métodos se utilizaron.

Gestión de MFA y métodos de autenticación

Cuando un usuario pierde su dispositivo de MFA o necesita restablecer sus métodos de autenticación, el helpdesk puede intervenir así:

# Restablecer los métodos de MFA de un usuario
# (requiere el rol de Administrador de autenticación)
Reset-MgUserAuthenticationMethodPassword -UserId "[email protected]"

# Ver los métodos de autenticación registrados por un usuario
Get-MgUserAuthenticationMethod -UserId "[email protected]" |
    Select-Object Id, AdditionalProperties

# Desde el Centro de administración de Entra ID:
# 1. Buscar el usuario en Usuarios > Todos los usuarios
# 2. Hacer clic en Métodos de autenticación
# 3. Seleccionar "Requerir nuevo registro de MFA"

Un punto importante: siempre verificar la identidad del usuario mediante un proceso establecido antes de restablecer métodos de MFA. Este es un vector de ataque de ingeniería social muy utilizado y no podemos ser nosotros quienes abramos la puerta.

Conclusión: preparación proactiva como clave del éxito

Las interrupciones de enero de 2026 nos dejaron una lección clara: incluso las plataformas más robustas pueden fallar. Y no una vez, sino cuatro veces en un mes.

La diferencia entre un equipo de helpdesk que genera confianza y uno que se ve desbordado no está en la suerte — está en la preparación. Monitorización proactiva, procedimientos documentados, herramientas de diagnóstico dominadas y planes de contingencia que realmente se hayan probado.

Los cambios como la eliminación de la autenticación básica SMTP AUTH representan tanto un desafío como una oportunidad para mejorar la seguridad de la organización. Si aún no ha empezado a identificar los sistemas afectados, este es el momento. La fecha límite de abril de 2026 está más cerca de lo que parece.

La clave está en pasar de un modelo reactivo — donde el helpdesk solo responde a incidentes — a uno proactivo donde los problemas se anticipan, las comunicaciones se preparan con antelación y los usuarios confían en que su equipo de TI tiene la situación bajo control. Con las herramientas, comandos y procedimientos de esta guía, su equipo estará mejor preparado para los retos de Microsoft 365 en 2026.

Sobre el Autor Editorial Team

Our team of expert writers and editors.