Cómo conectarse a múltiples servicios de Office 365 con PowerShell

Si administras Microsoft 365/Office 365 a diario, tarde o temprano descubres que hacerlo solo desde el centro de administración es un cuello de botella. PowerShell se convierte en la navaja suiza para gestionar buzones, usuarios, sitios de SharePoint, Teams o políticas de seguridad de forma masiva y automatizada.

El problema es que muchos admins acaban con cuatro o cinco ventanas de PowerShell abiertas a la vez: una para Exchange Online, otra para SharePoint Online, otra para Teams, otra para Microsoft Graph… y así sucesivamente. Ese enfoque es incómodo, difícil de mantener y poco eficiente. En esta guía verás cómo preparar el entorno y cómo conectarte a múltiples servicios de Office 365 desde una o pocas sesiones de PowerShell, usando los módulos modernos y las prácticas recomendadas de seguridad.

Requisitos previos y preparación del entorno

Antes de lanzarte a escribir comandos como si no hubiera un mañana, conviene asegurarse de que el puesto desde el que administras cumple unos requisitos mínimos de sistema, red y seguridad. Si te saltas esta parte, acabarás con errores crípticos tipo “cmdlet no reconocido”, “no se puede cargar el archivo” o problemas de autenticación.

En cuanto al sistema operativo, necesitas una versión de Windows de 64 bits. Están soportados, entre otros:

• Windows 11 y Windows 10
• Windows 8/8.1 y Windows 7 SP1
• Windows Server 2012, 2012 R2, 2016, 2019 y 2022

En estos equipos, la versión recomendada es PowerShell 5.1 o PowerShell 7+. Si usas Windows PowerShell 5.1, asegúrate de tener instalado .NET Framework 4.7.2 o superior y el módulo PowerShellGet actualizado, ya que es el que permite instalar módulos modernos desde PowerShell Gallery con comodísimos Install-Module.

A nivel de red, debes tener acceso HTTPS (TCP 443) hacia los dominios de Microsoft 365, como:

• outlook.office365.com (Exchange Online)
• login.microsoftonline.com (autenticación)
• graph.microsoft.com (Microsoft Graph)
• *.office365.com, *.microsoft.com en escenarios más restringidos

Si estás en un entorno con firewall o proxy corporativo, revisa con el equipo de redes que no se estén filtrando estos endpoints. Un simple Test-NetConnection outlook.office365.com -Port 443 te ayuda a verificar conectividad básica.

Otro pilar es la política de ejecución de scripts. Muchos módulos cargan scripts locales o remotos y, si la política es demasiado restrictiva, se bloquearán:

• Get-ExecutionPolicy para ver el valor actual.
• RemoteSigned es el punto de equilibrio más habitual: permite scripts locales sin firmar y exige firma a scripts descargados de Internet.

Para establecerla solo para el usuario actual:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

En algunos entornos se prefiere AllSigned (todo firmado) o, en casos muy específicos de pruebas, Unrestricted o Bypass a nivel de proceso. La clave es que entiendas que, sin ajustar esto, no podrás importar sesiones ni ejecutar scripts de conexión.

Rol del administrador y permisos necesarios

Da igual lo bien montado que tengas el entorno, si la cuenta con la que te conectas no tiene permisos, te vas a comer errores de “Access denied” uno tras otro. Para administrar Microsoft 365 con PowerShell de forma global necesitas, como mínimo, uno de estos roles:

• Administrador global (Global Administrator), si quieres controlar prácticamente todo.
• Administrador de Exchange para la parte de correo y buzones.
• Otros roles específicos: Administrador de Seguridad, Administrador de Teams, etc.

Dentro de Exchange Online se usa RBAC, por lo que tu cuenta debe estar en grupos como Organization Management o Recipient Management para poder crear y modificar buzones, reglas, etc. Y si vas a tirar de Microsoft Graph, necesitarás consentir los scopes adecuados, por ejemplo:

• User.Read.All para enumerar usuarios y leer datos básicos.
• Group.ReadWrite.All para gestionar grupos y, entre otras cosas, Teams.

Ten presente además que puedes habilitar o deshabilitar el acceso a Exchange Online PowerShell por usuario con cmdlets como:

• Set-User -Identity usuario@dominio.com -EXOModuleEnabled $true
• Set-User -Identity usuario@dominio.com -EXOModuleEnabled $false

Esto es muy útil para endurecer la superficie de ataque: no todo el mundo necesita poder abrir una sesión de Exchange Online PowerShell, aunque tenga buzón.

Instalación de módulos clave para Office 365/Microsoft 365

Para conectarte de manera moderna a los distintos servicios no necesitas ya aquellos viejos instaladores MSI de “Microsoft Online Services Sign-In”, Lync Online, etc. La mayoría de módulos actuales se instalan directamente desde PowerShell Gallery, lo que simplifica muchísimo mantenimiento y actualizaciones.

Los bloques básicos que te conviene tener instalados son:

• ExchangeOnlineManagement: módulo EXO V2 para Exchange Online (cmdlet principal: Connect-ExchangeOnline).
• Microsoft.Graph y opcionalmente Microsoft.Graph.Beta: SDK oficial de Microsoft Graph para PowerShell.
• Microsoft.Online.SharePoint.PowerShell: administración de SharePoint Online.
• MicrosoftTeams: gestión de Microsoft Teams por PowerShell.

Instalación típica (ejecutando PowerShell como administrador):

Install-Module -Name ExchangeOnlineManagement -Force -AllowClobber
Install-Module -Name Microsoft.Graph -Scope CurrentUser
Install-Module -Name Microsoft.Online.SharePoint.PowerShell -Force
Install-Module -Name MicrosoftTeams -Force

La opción -Force fuerza la instalación o actualización, mientras que -AllowClobber permite sobrescribir cmdlets de otros módulos si existe conflicto. Tras esto, puedes verificar cada módulo con:

Get-Module -ListAvailable -Name ExchangeOnlineManagement

Si necesitas compatibilidad con scripts antiguos, también puedes mantener módulos clásicos como MSOnline o AzureAD, pero la recomendación de Microsoft es ir migrando hacia Microsoft Graph PowerShell, que es el futuro de la administración de identidades y recursos.

Conectar a múltiples servicios en una sola sesión de PowerShell

El objetivo ideal es trabajar desde una única consola para evitar ir saltando entre ventanas. La buena noticia es que hoy se puede hacer perfectamente siempre que cargues los módulos adecuados y entiendas cómo funciona cada cmdlet de conexión.

Como patrón general puedes seguir este flujo:

1. Arrancar PowerShell (mejor 64 bits, con permisos elevados si vas a tocar ExecutionPolicy).
2. Crear un objeto de credenciales, si el módulo lo acepta (Get-Credential).
3. Cargar los módulos que vayas a usar con Import-Module.
4. Ejecutar los cmdlets de conexión: Exchange, Graph, SharePoint, Teams…

Ejemplo sencillo de inicio de sesión interactivo para varios servicios:

$credential = Get-Credential
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -ShowProgress:$true
Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChecking
$orgName = "tuempresa" # subdominio de tutenant.onmicrosoft.com
Connect-SPOService -Url https://$orgName-admin.sharepoint.com -Credential $credential
Import-Module MicrosoftTeams
Connect-MicrosoftTeams -Credential $credential

En paralelo, para Microsoft Graph la autenticación va por otro lado. No puedes pasarle las credenciales directamente al cmdlet, sino que se abre un flujo interactivo basado en OAuth 2.0:

Connect-MgGraph -Scopes "User.Read.All","Group.ReadWrite.All"

Aquí se lanzará un prompt que te pedirá iniciar sesión en el navegador y otorgar consentimiento para esos scopes. Una vez aceptado, la sesión de Graph queda usable en la misma ventana de PowerShell que ya está conectada a Exchange, SharePoint y Teams.

Con este enfoque tienes centralizado en una única sesión todo lo necesario para administrar cuentas, buzones, sitios, equipos y configuraciones de seguridad, sin ir abriendo pestañas como si no hubiera mañana.

Uso de Microsoft Graph PowerShell para toda la organización

Microsoft Graph PowerShell es el “nuevo estándar” para acceder a la capa de APIs de Microsoft 365. Con un solo SDK puedes tocar usuarios, grupos, Teams, dispositivos, informes, etc. Desde PowerShell, la experiencia es similar a cualquier otro módulo, pero con el matiz de los scopes y el modelo delegados vs. solo aplicación.

Para trabajar de forma interactiva, lo habitual es usar acceso delegado: inicias sesión como un usuario (normalmente admin) y consientes en nombre de ese usuario:

Install-Module Microsoft.Graph -Scope CurrentUser
Import-Module Microsoft.Graph
Connect-MgGraph -Scopes "User.Read.All","Group.ReadWrite.All"

Con esos scopes puedes por ejemplo:

• Listar usuarios para localizar el Id del usuario conectado.
• Ver los equipos de los que forma parte (joinedTeams).
• Enumerar canales de un equipo concreto.
• Enviar mensajes a un canal de Teams desde scripts.

Para escenarios desatendidos (jobs programados, pipelines CI/CD, automatizaciones nocturnas…), lo suyo es pasar a autenticación solo aplicación con un registro de app en Microsoft Entra ID y un certificado X.509. En ese caso la app se autentica con AppId, TenantId y certificado, y no necesitas interacción humana, lo que permite ejecutar tareas en segundo plano de manera controlada.

Conexión moderna a Exchange Online y otros entornos

Durante años se conectaba a Exchange Online con New-PSSession y la autenticación básica. Esa vía está oficialmente muerta desde octubre de 2022. Ahora todo pasa por el módulo ExchangeOnlineManagement, que utiliza autenticación moderna (OAuth 2.0) y soporta MFA, certificados, Managed Identities, etc.

El patrón básico para admins humanos es:

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName admin@tudominio.com

Se abre el cuadro de inicio de sesión, introduces contraseña, resuelves el MFA y listo. A partir de ahí puedes usar cmdlets como Get-EXOMailbox, Get-EXOMailboxStatistics, New-Mailbox, Set-Mailbox o Remove-Mailbox sin más.

Para automatizar sin navegador tienes varias opciones de autenticación basada en certificados o Managed Identities en Azure:

Connect-ExchangeOnline -ManagedIdentity -Organization tudominio.onmicrosoft.com

O bien, usando una app registrada y un certificado:

Connect-ExchangeOnline -AppId "APP-ID" -Organization "tudominio.onmicrosoft.com" -CertificateThumbprint "THUMBPRINT"

Este tipo de conexión es ideal cuando quieres lanzar scripts periódicos desde Azure Automation, Azure Functions o una VM con identidad administrada: no hay contraseñas en texto plano y el ciclo de vida del certificado está bien controlado.

Conectar a SharePoint Online y Teams desde PowerShell

Una vez que tienes cubierto el correo y la identidad, lo normal es que también quieras orquestar sitios de SharePoint y equipos de Teams desde scripts. La mecánica es muy parecida a lo que has visto con Exchange, solo cambian módulos y cmdlets.

Para SharePoint Online necesitas conocer la URL de administración de tu tenant, del estilo https://tuempresa-admin.sharepoint.com. La conexión básica es:

Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChecking
$cred = Get-Credential
Connect-SPOService -Url "https://tuempresa-admin.sharepoint.com" -Credential $cred

A partir de ahí tienes a tu disposición cmdlets como Get-SPOSite para listar colecciones de sitios, comandos para aplicar políticas, gestionar almacenamiento, etc. El mismo objeto de credenciales puedes reutilizarlo para otros servicios, simplificando el script.

En el caso de Microsoft Teams, el módulo también soporta autenticación moderna y MFA. Un flujo típico sería:

Import-Module MicrosoftTeams
Connect-MicrosoftTeams -Credential $cred

Aunque también puedes dejar que abra el diálogo de login sin pasar credenciales explícitas. Una vez conectado, cmdlets clave como Get-Team, New-Team o Get-TeamUser permiten automatizar la creación de equipos, gestión de miembros, configuración de canales, etc., a menudo en combinación con Microsoft Graph para escenarios más avanzados.

Gestión segura de sesiones y desconexión

PowerShell no es solo conectarse y listo: también hay que gestionar bien las sesiones abiertas. Exchange Online, por ejemplo, impone un límite de unas 3 sesiones concurrentes por usuario, y si te las dejas abiertas acabarás chocando con el famoso error de “se ha superado el número máximo de sesiones”.

La práctica recomendada es cerrar explícitamente las sesiones cuando termines tus tareas, en lugar de simplemente cerrar la ventana. Para Exchange Online con EXO V2:

Disconnect-ExchangeOnline -Confirm:$false

Si además has generado sesiones remotas con New-PSSession hacia otros servicios (o para compatibilidad con scripts antiguos), también conviene limpiarlas:

Get-PSSession | Remove-PSSession

Para SharePoint y Teams tienes sus propios cmdlets de desconexión:

Disconnect-SPOService
Disconnect-MicrosoftTeams

Trabajar así evita sesiones huérfanas en los servidores, libera recursos y reduce riesgos de seguridad. Además, si tienes scripts largos, plantéate ejecutarlos en una única sesión y controlar los tiempos de espera en lugar de crear conexiones y desconexiones en bucle sin ton ni son.

Solución de problemas habituales al conectarse

Por muy fino que lo tengas montado, casi seguro que en algún punto aparecerá algún mensaje extraño. La mayoría de errores de conexión a servicios de Office 365 con PowerShell caen en unos pocos grupos típicos:

Cuando ves mensajes como “El término ‘Connect-ExchangeOnline’ no se reconoce”, suele significar que el módulo no está instalado o no se ha importado correctamente. Lo compruebas con:

Get-Module -ListAvailable -Name ExchangeOnlineManagement

Si no aparece, vuelve a instalarlo desde PowerShell Gallery. Si sí aparece pero no se carga, asegúrate de no estar en una PowerShell demasiado antigua o de 32 bits que no soporte ese módulo.

Errores de autenticación (“Access denied”, “no tiene suficientes permisos”) suelen deberse a:

• Roles insuficientes en Microsoft 365 (falta de Exchange Admin, Global Admin, etc.).
• Requisitos de MFA no satisfechos, app password deshabilitadas, o políticas de acceso condicional.
• Credenciales cacheadas corruptas en el administrador de credenciales de Windows.

La receta aquí es revisar los roles en el portal de administración, comprobar si la organización tiene reglas de acceso condicional bloqueando PowerShell y, si hace falta, eliminar credenciales guardadas y probar de nuevo el flujo de login.

También son frecuentes los problemas con TLS o proxies: mensajes tipo “La conexión subyacente se cerró” o “No se puede conectar al servidor remoto” apuntan a que no se está usando TLS 1.2 o el firewall está cortando tráfico. Asegúrate de:

• Tener .NET actualizado (4.6.2 o superior).
• Forzar TLS 1.2 si hace falta desde PowerShell.
• Validar que el proxy permite el tráfico hacia los endpoints de Microsoft.

Finalmente, cuando tienes varios módulos instalados (MSOnline, AzureAD, ExchangeOnlineManagement, versiones antiguas de EXO, etc.), pueden aparecer conflictos de cmdlets o versiones. En ese caso:

• Lista módulos con Get-Module -ListAvailable.
• Averigua a qué módulo pertenece un cmdlet con Get-Command NombreCmdlet.
• Importa explícitamente la versión correcta con Import-Module -RequiredVersion.
• Desinstala módulos viejos que ya no necesitas con Uninstall-Module.

Con estas pautas, la mayoría de incidencias quedan resueltas sin tener que volverte loco leyendo logs eternos.

Dominar la conexión a múltiples servicios de Office 365 usando PowerShell te permite pasar de hacer cambios a mano en el portal a automatizar tareas masivas, aplicar configuraciones avanzadas que ni aparecen en la GUI y mantener un control mucho más fino de seguridad y acceso. Preparar bien el entorno (versiones, módulos, permisos y políticas de ejecución), usar autenticación moderna con MFA y certificados, centralizar las conexiones en una o pocas sesiones y cuidar el ciclo de vida de las sesiones hará que tu día a día como admin de Microsoft 365 sea mucho más fluido y, sobre todo, escalable.