Conectarse a Exchange Online PowerShell: guía paso a paso

Por Mirko Peters · 2026-11-12

Conéctate a Exchange Online PowerShell con Connect-ExchangeOnline: requisitos, inicio de sesión interactivo, MFA, opciones para socios y ejecución desatendida, y soluciones a errores.

Traducido automáticamente con IA a partir de la publicación original. Lee el original en inglés

Para conectarte a Exchange Online PowerShell, carga el módulo ExchangeOnlineManagement y ejecuta Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com. Se abre una ventana de inicio de sesión, introduces tu contraseña y apruebas la solicitud de MFA, y la consola queda conectada. Este artículo está dirigido a administradores de Exchange y Microsoft 365 que necesitan los pasos exactos, las opciones de acceso para socios y acceso desatendido, y una breve lista de soluciones cuando la conexión falla. Sigue la documentación oficial de Microsoft vigente, por lo que los comandos de este artículo asumen autenticación moderna y ninguna sesión de PowerShell remota.

Puntos clave

• Para conectarte a Exchange Online PowerShell, carga el módulo y ejecuta Connect-ExchangeOnline con tu cuenta de administrador en formato UPN.
• El inicio de sesión interactivo funciona con y sin autenticación multifactor, así que no necesitas una solución alternativa aparte para MFA.
• La autenticación básica y el antiguo método New-PSSession ya no son compatibles, así que los scripts que dependan de ellos deben reescribirse.
• Usa Get-AcceptedDomain como prueba rápida después de conectarte, y termina siempre la sesión con Disconnect-ExchangeOnline.
• Los scripts desatendidos deben usar autenticación solo de aplicación o una identidad administrada en lugar de una contraseña almacenada.

Qué necesitas antes de conectarte

El comando de conexión viene del módulo, así que primero hay que instalarlo. Si aún no lo has hecho, instálalo desde PowerShell Gallery con Install-Module -Name ExchangeOnlineManagement. En la documentación de Microsoft, el módulo se denomina módulo V3. Microsoft cubre tanto Windows PowerShell 5.1 como PowerShell 7. Para PowerShell 7 necesitas la versión 2.0.4 o posterior del módulo.

Otros cuatro factores determinan si la conexión funciona:

• Permisos. El control de acceso basado en roles decide qué cmdlets puedes ejecutar una vez dentro. Conectarse no es lo difícil; lo difícil es ejecutar el cmdlet adecuado. Microsoft tiene una página para encontrar los permisos que necesita un cmdlet, y merece la pena guardarla en marcadores.
• Acceso a PowerShell para la cuenta. La cuenta debe tener permiso para usar Exchange Online PowerShell. Si un administrador lo ha desactivado para tu usuario, el inicio de sesión se completa, pero la conexión no se establece.
• Red. El puerto TCP 80 debe estar abierto entre tu equipo y Microsoft 365.
• Una ruta de perfil limpia. Microsoft indica que los comandos de conexión pueden fallar si la ruta de tu perfil de usuario contiene caracteres especiales de PowerShell, como $. Usa otra cuenta si la tuya tiene alguno.

Tampoco necesitas cambiar nada de WinRM. Las conexiones actuales usan REST por debajo, así que el antiguo consejo de habilitar la autenticación básica en WinRM ya no aplica.

Cómo conectarte a Exchange Online PowerShell paso a paso

Este es el método interactivo estándar. Funciona igual en Windows PowerShell 5.1 y en PowerShell 7, con o sin autenticación multifactor.

1. Abre una nueva ventana de PowerShell. Una ventana nueva evita conflictos de ensamblados con otros módulos que hayas cargado antes en la sesión.
2. Carga el módulo con Import-Module ExchangeOnlineManagement. Si el módulo ya está instalado, Microsoft indica que normalmente puedes omitir este paso e ir directamente al comando de conexión, porque PowerShell carga el módulo automáticamente.
3. Ejecuta Connect-ExchangeOnline -UserPrincipalName admin@contoso.com, pero con tu propia cuenta en formato UPN. En algunas organizaciones puedes omitir -UserPrincipalName y el sistema te lo pedirá. Si eso falla, añade el parámetro.
4. Introduce tu contraseña en la ventana de inicio de sesión y selecciona Iniciar sesión.
5. Si tu cuenta usa MFA, introduce el código de verificación y selecciona Comprobar. El código se envía mediante el método que hayas configurado, por ejemplo un mensaje de texto o Microsoft Authenticator. En PowerShell 7, el inicio de sesión usa tu navegador de forma predeterminada.
6. Espera a que aparezca el banner. Si no hay ningún error, significa que estás conectado.

Eso es todo. El mismo cmdlet te conecta a sesiones de PowerShell para Microsoft 365 GCC sin parámetros adicionales. Solo las otras nubes necesitan una configuración, que veremos a continuación.

Si no quieres que el banner de bienvenida aparezca en un registro de script, añade -ShowBanner:$false. Si quieres que Get-Help muestre la ayuda de los cmdlets de Exchange Online, añade -LoadCmdletHelp. Desde la versión 3.7.0 del módulo, esa ayuda ya no se carga de forma predeterminada, algo que sorprende a quienes actualizan el módulo y luego ven que Get-Help devuelve casi nada.

Otras formas de conectarse: PowerShell 7, partners y nubes

La documentación recoge varias variantes. Elige la que se ajuste a tu situación.

PowerShell 7 sin navegador. Ejecuta Connect-ExchangeOnline -Device. El comando muestra un mensaje que te indica que abras https://microsoft.com/devicelogin e introduzcas un código. Lo haces en cualquier otro dispositivo, inicias sesión, confirmas y la sesión original termina de conectarse. Funciona con y sin MFA, y es útil en servidores o equipos Linux sin escritorio.

PowerShell 7 con credenciales en línea. Connect-ExchangeOnline -UserPrincipalName admin@contoso.com -InlineCredential funciona con cuentas sin MFA. La mayoría de las organizaciones exigen MFA a los administradores, así que probablemente usarás esta opción poco.

Windows PowerShell 5.1 con un objeto de credencial. Para cuentas sin MFA, puedes ejecutar primero $Credential = Get-Credential y después Connect-ExchangeOnline -Credential $Credential. Microsoft indica que, si esto falla, debes usar -UserPrincipalName en su lugar.

Inquilinos de clientes como partner. Los partners del programa Cloud Solution Provider y los administradores invitados añaden -DelegatedOrganization, por ejemplo Connect-ExchangeOnline -UserPrincipalName admin@contoso.onmicrosoft.com -DelegatedOrganization adatum.onmicrosoft.com. La página de Microsoft remite al programa Cloud Solution Provider y a los privilegios de administración delegada granular (GDAP) en lo que respecta a los permisos.

Nubes gubernamentales y regionales. -ExchangeEnvironmentName selecciona el entorno. El valor predeterminado es O365Default, que cubre Microsoft 365 y GCC. Los valores documentados para los demás son O365USGovGCCHigh, O365USGovDoD, O365GermanyCloud y O365China.

Scripts desatendidos. No guardes una contraseña de administrador en un script. Microsoft documenta dos opciones mejores. Una identidad administrada, por ejemplo Connect-ExchangeOnline -ManagedIdentity -Organization "contoso.onmicrosoft.com", es adecuada para scripts que se ejecutan en Azure. La autenticación solo de aplicación con un certificado sirve para todo lo demás. El parámetro de huella digital del certificado solo se admite en Windows. La configuración requiere un registro de aplicación en Microsoft Entra ID, el permiso de aplicación Exchange.ManageAsApp con consentimiento de administrador, un certificado y un rol admitido, como Administrador de Exchange, asignado a la aplicación. Microsoft recomienda privilegios mínimos, así que no le asignes a la aplicación el rol de Administrador global a menos que no haya otra forma. Sigue el artículo independiente de Microsoft sobre autenticación solo de aplicación en lugar de una versión abreviada.

En un servicio de Windows, agrega -SkipLoadingFormatData para evitar errores. Si ves errores que mencionan Web Account Manager, la versión 3.7.2 o posterior del módulo tiene para ello el modificador -DisableWAM.

Mantén los scripts ligeros: limita lo que importas

Una conexión normalmente importa los cmdlets de Exchange Online que tienes permitido usar. Eso está bien para una consulta rápida a un buzón, pero un script que necesita tres comandos no necesita todos. La página del módulo de Microsoft ofrece un consejo específico al respecto. Las llamadas frecuentes a Connect-ExchangeOnline y Disconnect-ExchangeOnline dentro de la misma sesión pueden provocar una fuga de memoria. La solución es conectarse una vez por script y usar el parámetro -CommandName para importar solo los cmdlets que necesitas.

Un script que solo lee estadísticas de buzones, por ejemplo, necesita únicamente ese comando. Indica los pocos comandos que necesitas, conéctate una vez al principio, haz el trabajo y desconéctate una vez al final. Los scripts escritos así son más fáciles de revisar, porque la línea de conexión indica al lector qué comandos usa el script.

Dos hábitos más ayudan en entornos de equipo. Primero, mantén la línea de conexión en un solo lugar, por ejemplo en una pequeña función, de modo que un cambio en el método de autenticación se haga una vez y no en veinte scripts. Segundo, registra el nombre de la cuenta o de la aplicación que ejecutó el script, nunca su secreto. Cuando algo inesperado cambia en un buzón, esa línea de registro te ahorra horas.

Comprueba la conexión y desconéctate correctamente

Una conexión sin errores es buena señal, pero pruébala con un comando de lectura inofensivo. Get-AcceptedDomain muestra los dominios de tu organización y tarda un segundo en ejecutarse. Si aparecen dominios, tu sesión funciona y tu cuenta tiene al menos permisos de lectura.

Para ver detalles sobre tus conexiones, usa Get-ConnectionInformation. La página del módulo de Microsoft señala que Get-PSSession no devuelve nada útil para estas conexiones basadas en REST, así que los scripts antiguos que comprueban Get-PSSession necesitan cambiarse.

Cuando termines, ejecuta Disconnect-ExchangeOnline. Agrega -Confirm:$false en los scripts para omitir la confirmación. El artículo de Microsoft sobre conexiones advierte que cerrar la ventana sin desconectarte puede agotar las sesiones disponibles, y entonces tienes que esperar a que caduquen.

Soluciona los errores de conexión más comunes

La mayoría de los fallos se deben a una lista corta de causas. Revísalas de arriba abajo.

• Nombre de usuario o contraseña incorrectos. Repite los pasos y verifica ambos. Suena trivial, pero comprueba primero el formato del UPN.
• El acceso a PowerShell está desactivado para la cuenta. Un administrador puede habilitarlo. Microsoft tiene un artículo aparte sobre cómo habilitar o deshabilitar el acceso a PowerShell de Exchange Online.
• El puerto 80 está bloqueado. Pide a tu equipo de redes que permita el tráfico TCP por el puerto 80 hacia Microsoft 365.
• Cuenta federada con un proveedor de identidades inaccesible. Si tu IDP o STS no está disponible públicamente, Microsoft sugiere usar una cuenta no federada en Microsoft 365 para la conexión.
• "The term 'Update-ModuleManifest' is not recognized". La conexión necesita PowerShellGet y su dependencia PackageManagement. Actualiza ambos y reinicia PowerShell.
• "Could not load file or assembly 'System.IdentityModel.Tokens.Jwt'". El módulo entra en conflicto con otro módulo de la misma sesión. Conéctate en una ventana nueva de Windows PowerShell antes de importar cualquier otro módulo.
• Errores en una ventana abierta por un servicio o una tarea programada. Prueba con -SkipLoadingFormatData.

Si ninguno de estos casos aplica, la versión del módulo es el siguiente sospechoso. Ejecuta Update-Module -Name ExchangeOnlineManagement en el mismo ámbito con el que lo instalaste y vuelve a intentarlo en una ventana nueva.

Errores comunes

• Usar autenticación básica o New-PSSession. Microsoft las incluye solo como referencia histórica y indica que ya no son compatibles. Un script que todavía crea una sesión de este modo debe migrar a Connect-ExchangeOnline.
• Cerrar la ventana en lugar de desconectarte. Puede agotar tus sesiones. Haz que Disconnect-ExchangeOnline sea la última línea de cada script.
• Escribir una contraseña en texto plano dentro de un script. Usa en su lugar una identidad administrada o un certificado.
• Importar otros módulos antes. Un conflicto con otro módulo puede romper el inicio de sesión. Conéctate primero a Exchange Online o usa una ventana nueva.
• Dar por hecho que conectarse equivale a tener permisos. Si un cmdlet aparece como «no reconocido» después de conectarte, tu rol no lo incluye. Eso es una cuestión de RBAC, no un problema de conexión.

Temas relacionados para explorar

• Instalar y actualizar el módulo: la conexión depende del módulo y de la versión de PowerShell adecuados, así que lee los requisitos del módulo de PowerShell de Exchange Online antes de desplegarlo en un equipo.
• Consultar los permisos de un cmdlet: Microsoft explica cómo buscar qué rol necesita un cmdlet concreto de Exchange.
• Conectarse a PowerShell de Security & Compliance: el mismo módulo ofrece Connect-IPPSSession, que no está disponible en PowerShell 7 en Linux o macOS.
• Automatización desatendida: la autenticación de solo aplicación y las identidades administradas son la forma segura de ejecutar scripts programados de Exchange.
• Operaciones masivas grandes: los cmdlets basados en REST tienen un tiempo de espera de 15 minutos, así que divide las actualizaciones masivas de miembros en lotes.

Siguiente paso

Para conectarte de forma fiable a PowerShell de Exchange Online, empieza con una ventana nueva, ejecuta Connect-ExchangeOnline -UserPrincipalName con tu cuenta de administrador, comprueba la conexión con Get-AcceptedDomain y desconéctate al terminar. Después, planifica tus scripts desatendidos en torno a una identidad administrada o a un certificado, para que nadie tenga que escribir ni guardar una contraseña.