Administre Exchange Online a escala
Después de que una empresa ha migrado efectivamente a Microsoft 365 y ha adoptado nuevos servicios en la nube, la cantidad de objetos, como usuarios, invitados y grupos en un inquilino, crece constantemente. Lo mismo se aplica a Exchange Online.
Incluso si ha seguido las instrucciones para la caducidad del grupo de Microsoft 365 o la administración del ciclo de vida de la identidad, el resultado es comparable: la cantidad de objetos que administra está aumentando, convirtiéndose en un desafío cada vez mayor para los administradores. En este artículo, examinaremos cómo administrar Exchange Online a escala usando PowerShell.
Mantener grandes conjuntos de objetos.
Como todos sabemos, Microsoft desarrolla constantemente diferentes portales y centros de administración para que los administradores los utilicen diariamente para administrar el servicio. Recientemente, Microsoft anunció que el nuevo centro de administración de Exchange estará disponible de forma generalizada.
Uno de los impulsores del nuevo portal es el rendimiento y la capacidad de realizar operaciones masivas. Está basado en REST y diseñado para minimizar el tiempo de espera, reducir errores y mucho más. En pocas palabras, puede mejorar su experiencia como administrador.
PowerShell puede potenciar
A pesar de las mejoras en el nuevo centro de administración de Exchange, sigue siendo limitado en términos de funcionalidad y deja espacio para mejoras en el rendimiento. Para ver mejoras, debe salir del centro de administración y usar PowerShell. Específicamente para Exchange Online, desea instalar y utilizar el módulo Exchange Online PowerShell (EXO) V2.
Este módulo combina los cmdlets heredados y los nuevos. A día de hoy, nueve nuevos cmdlets aprovechan la nueva arquitectura basada en REST. Puede que nueve no parezca mucho, pero piénselo en relación con las operaciones que realiza a diario, y son más que suficientes.
La mayoría de los comandos que utiliza son para recuperar atributos o estadísticas del buzón o del destinatario, como información sobre el buzón o todas las carpetas dentro de un buzón.
Los nuevos cmdlets le permiten reducir la cantidad de atributos solicitados, lo que resulta en una menor transferencia de datos por cable. La capacidad de hacer esto se denomina Conjuntos de propiedades, que se describe con más detalle aquí.
Combinar la nueva arquitectura de cmdlets con mejoras más pequeñas, como el uso de conjuntos de propiedades, puede generar un mayor rendimiento. Sin embargo, dado que los conjuntos de propiedades no se definen automáticamente, debe tener en cuenta lo que necesitará recuperar al actualizar sus scripts a los nuevos cmdlets.
Además de una nueva arquitectura, el uso de PowerShell desbloquea varias tareas. Puede realizar fácilmente operaciones masivas según su filtrado y también le permite recopilar propiedades que ni siquiera son visibles en el nuevo centro de administración de Exchange.
El filtrado del lado del servidor es más importante de lo que cree
Es importante enfatizar que actualmente Microsoft recomienda utilizar el filtrado del lado del cliente para obtener un rendimiento óptimo utilizando el módulo Exchange Online V2. Sin embargo, esto se aplica sólo a este módulo.
A continuación se muestra un breve ejemplo que destaca la diferencia:
# client-side filtering
Get-EXOMailbox -ResultSize 20000 | Where-Object -FilterScript {$_.RecipientTypeDetails -eq 'UserMailbox'}
# server-side filtering
Get-EXOMailbox -ResultSize 20000 -RecipientTypeDetails UserMailbox
En el primer ejemplo, el filtrado se realiza después de que su cliente haya recibido todos los artículos. El segundo ejemplo le pide al servidor que filtre en el lado de la nube y luego envíe el resultado al cliente. Esto tiene al menos dos implicaciones que significan que los resultados de cada ejemplo proporcionan resultados diferentes.
En primer lugar, especificamos el parámetro "-ResultSize 20000". Esto significa que recibiremos 20000 buzones de correo; sin embargo, es probable que la colección contenga varios tipos de objetos además de UserMailbox. Por ejemplo:
En segundo lugar, esto demuestra otro problema: es posible que no recupere todos los objetos que espera. Como puede ver en el ejemplo anterior, solo 13219 son UserMailbox.
Sin embargo, al utilizar el filtro del lado del servidor, recibiremos el resultado correcto:
Por lo tanto, puede valer la pena mejorar el rendimiento al utilizar el filtro del lado del servidor para garantizar que reciba resultados precisos.
Utilice Microsoft Graph con PowerShell para obtener el máximo rendimiento
Cabe señalar que si necesita modificar objetos usando PowerShell, está limitado al módulo Exchange Online V2 PowerShell. Desafortunadamente, Microsoft Graph actualmente no proporciona una forma de modificar los atributos de Exchange Online.
Sin embargo, eso no significa que no puedas usar Microsoft Graph en absoluto. Dado que su objetivo es recuperar datos rápidamente, puede evitar la sobrecarga del módulo Exchange Online V2 para filtrar los datos que desea recuperar.
Al hacer esto, debe asegurarse de que el filtro que desea utilizar sea compatible con Microsoft Graph. Pero en la mayoría de los escenarios, debería poder hacerlo. La lista completa de parámetros de consulta admitidos por Microsoft Graph está disponible en Microsoft Docs.
Antes de combinar el uso del módulo Exchange Online V2 con scripts Graph, debe considerar si vale la pena. Para dar una idea de cuándo esto marcará la diferencia, considere que la sobrecarga de ciertos módulos puede marcar una gran diferencia.
En un entorno local, puede aprovechar las consultas LDAP con un filtro y pasar el resultado a Exchange. Con esto, mejora drásticamente el rendimiento general ya que LDAP está optimizado para consultas. El mismo principio se aplica a Microsoft Graph.
A continuación se muestra un ejemplo de una consulta utilizando el módulo Exchange y la correspondiente utilizando Microsoft Graph:
# Exchange command
Get-User -Filter {Department -like 'Reta*'}
# Microsoft Graph request
https://graph.microsoft.com/v1.0/users?$filter=StartsWith(Department,'Reta')
La ejecución de subprocesos múltiples en los scripts de PowerShell proporciona otra opción para mejorar el rendimiento
Si bien esta técnica es más avanzada, puede mejorar el rendimiento a un nivel que aún no has visto.
Subprocesos múltiples, en pocas palabras, significa que bifurca varios subprocesos (que podría considerar como un subproceso) de su script de PowerShell en ejecución y que cada subproceso ejecute su código tanto en su cliente como en el lado del servidor. Esta técnica es principalmente útil para recopilar datos. La ventaja es que realiza una ampliación horizontal para su trabajo y varios subprocesos funcionan en paralelo en lugar de en orden secuencial. El módulo Exchange Online V2 PowerShell utiliza esto en la arquitectura. Para darle una idea del poder del uso de subprocesos múltiples, eche un vistazo al primer ejemplo de subproceso único:
En el segundo ejemplo que utiliza subprocesos múltiples, vemos una mejora del 44 % en el tiempo de recuperación:
Administrar múltiples entornos de Exchange Online desde una sesión de PowerShell
Otra característica del nuevo módulo Exchange V2 es la capacidad de conectarse a varios inquilinos en una sesión de PowerShell. Esto puede resultar extremadamente útil durante las migraciones de inquilino a inquilino. Sin embargo, deberá cumplir con algunos requisitos previos y limitaciones importantes antes de utilizar la función:
- Deberá asegurarse de poner un prefijo en cada conexión; sin hacerlo, solo recuperará objetos de la última sesión establecida.
- Los nuevos cmdlets Get-EXO* ya tienen el prefijo y estarán disponibles SÓLO para la última conexión establecida.
En el siguiente ejemplo, me conecté a un inquilino de origen y de destino. Como los nuevos cmdlets solo están disponibles para la última conexión establecida, me conecto primero al destino porque quiero aprovechar los nuevos cmdlets para recopilar datos:
Nota: Para distinguir los objetos de los inquilinos, seleccioné PrimarySmtpAddress y UserPrincipalName.
Utilicé los siguientes comandos y orden:
# connect to target tenant
Connect-ExchangeOnline -UserPrincipalName admin@M365x345322.onmicrosoft.com -Prefix Target
# connect to source tenant
Connect-ExchangeOnline -UserPrincipalName admin@M365x278799.onmicrosoft.com -Prefix Source
Resumen
Espero que este artículo le haya brindado la información y la motivación para comenzar a buscar otras formas de administrar su entorno Exchange Online cuando tenga muchos objetos que administrar o a gran escala.
Recuerde, puede usar más que el módulo Exchange Online V2 para la administración de PowerShell. Debería intentar aprovechar varias herramientas, como Microsoft Graph, para mejorar el rendimiento de sus scripts y tareas administrativas. Con estas técnicas, puede crear una base sólida para reducir el tiempo que lleva recuperar información y estadísticas de su entorno y crear scripts para automatizar tareas rutinarias.
