Actualice sus secuencias de comandos de Exchange Online para utilizar el cmdlet Get-EXOMailbox

Suelte Get-Mailbox; Ha tenido su momento

Recientemente escribí sobre el cmdlet New-DistributionGroup para explicar por qué creo que las listas de distribución siguen siendo tan valiosas, a pesar de los mejores esfuerzos de Microsoft para convencer al mundo de que los Grupos de Microsoft 365 son mejores. Hoy quiero analizar un cmdlet aún más fundamental para la experiencia de muchas personas al trabajar con Exchange a través de PowerShell: Get-Mailbox. O para ser más precisos, el nuevo y mejorado Get-ExoMailbox.

Microsoft presentó Get-ExoMailbox como uno de los nueve cmdlets iniciales actualizados en 2019 para usar las API REST (como Microsoft Graph) en lugar de Remote PowerShell (RPS) por una muy buena razón. Obtener conjuntos de buzones para procesar es una actividad fundamental para cualquier administrador de Exchange. Get-Mailbox funciona, pero es lento y propenso a errores, especialmente cuando se trata de grandes conjuntos de objetos. En este sentido, comparte los mismos defectos que otros cmdlets de Remote PowerShell. El hecho de que Get-Mailbox se utilice con tanta frecuencia para procesar tantos datos hace que parezca más problemático que sus pares. En realidad no lo es. En cambio, Get-Mailbox revela todos los defectos inherentes a depender de una conexión a un servidor remoto designado que puede o no permanecer disponible durante una sesión completa.

Tres pasos para intercambiar felicidad en PowerShell en línea

En cualquier caso, a estas alturas ya debería haber convertido los scripts de Exchange Online a:

Utilice el módulo de administración en línea de Exchange en lugar de PowerShell remoto.
Utilice el cmdlet Connect-IPPSSession para conectarse al punto final de cumplimiento. La versión actual del módulo de administración en línea de Exchange permite sesiones simultáneas conectadas a la administración y el cumplimiento de Exchange.
Cambie Get-Mailbox para usar Get-ExoMailbox y cambie otros cmdlets importantes al mismo tiempo. Los tres cambios más urgentes que se deben realizar son Get-ExoMailboxStatistics, Get-ExoMailboxFolderStatistics y Get-ExoMailboxPermission.

El módulo de administración en línea de Exchange y los cmdlets basados en REST no existen para Exchange local. La forma en que funciona la infraestructura de Exchange Online reveló algunas de las fallas en Remote PowerShell que simplemente no ocurren en implementaciones locales, por lo que Microsoft aún no ha movido los nuevos cmdlets allí. ¿Sucederá esto alguna vez? No lo sé, pero si me obligaran a adivinar, diría que no. Pero nunca digas nunca.

Versión 2.0.5 de Exchange Online Management

Hablando de versiones, Microsoft lanzó la V2.0.5 del módulo Exchange Online Management el 10 de mayo. Todavía no han actualizado las notas de la versión del módulo, por lo que no sabemos qué hay en la nueva versión. En cualquier caso, he estado ejecutando 2.0.5 durante la última semana y todo parece estable. Alrededor de 70.000 personas más han descargado 2.0.5 y no he oído hablar de ningún problema hasta ahora.

Optimización de datos del buzón

Volviendo a Get-ExoMailbox, el gran problema de actualización del que escucho una y otra vez es la necesidad de especificar Propiedades al recuperar datos del buzón. Este es un cambio en el comportamiento sobre Get-Mailbox implementado para optimizar la recuperación de datos del buzón. El problema es que las propiedades de un buzón abarcan cientos de elementos diferentes, algunos de los cuales deben recuperarse o validarse con Azure AD. Si haces algo como:

Get-Mailbox -Identity TRedmond

Recupera todas las propiedades del buzón. Pero si ejecutas:

Get-ExoMailbox -Identity TRedmond

Exchange Online recupera sólo 15 propiedades. Estos son los más importantes, como el nombre para mostrar, el nombre principal del usuario, las direcciones de correo electrónico y el ExternalDirectoryObjectId, muy infrautilizado. Este es el puntero (GUID) a la cuenta de Azure AD propietaria del buzón. Todos los objetos habilitados para correo de Exchange Online conectados a Azure AD tienen esta propiedad para facilitar la conexión a Azure AD. El uso de GUID para hacer referencia a objetos es muy común en Office 365, especialmente en cada llamada a Graph API para obtener datos sobre un objeto, por lo que es bueno acostumbrarse a usar GUID.

Por ejemplo, puedo hacer esto:

Get-AzureADUser -ObjectId ((Get-ExoMailbox -Identity Tony.Redmond@office365itpros.com).ExternalDirectoryObjectId) | Select ObjectId, DisplayName

ObjectId                             DisplayName
--------                             -----------
f1dbb86a-69bf-4245-8bc7-5e1d09d9d8cc Tony Redmond (Office 365 for IT Pros)

Puedo tomar el ObjectId devuelto por Azure AD y usarlo con Get-ExoMailbox:

Get-ExoMailbox -Identity f1dbb86a-69bf-4245-8bc7-5e1d09d9d8cc

Debido a que Get-ExoMailbox es cuidadoso con lo que recupera, a menudo necesita incluir solicitudes para recuperar propiedades individuales o conjuntos de propiedades en sus llamadas (un conjunto de propiedades es una colección de propiedades comunes para algún propósito, como cuotas ). Por ejemplo, la propiedad WhenCreated no es una de las 15 básicas, por lo que si quiero usarla, debo incluirla en la llamada:

Get-ExoMailbox -Identity TRedmond -Properties WhenCreated

Grandes beneficios

Los beneficios de pasarse a Get-ExoMailbox incluyen:

Mejor rendimiento, especialmente al procesar una gran cantidad de buzones de correo. Su kilometraje variará dependiendo de lo que haga, pero cuando probé los nuevos cmdlets en público en Microsoft Ignite 2019, el aumento de velocidad fue entre tres y cuatro veces más rápido para procesar miles de buzones. No verá muchos beneficios si solo recupera un par de buzones. Y en el otro extremo de la escala, para procesar cantidades muy grandes de buzones de correo, las API Graph podrían ser una mejor solución.
Mejor confiabilidad. Get-ExoMailbox y los otros cmdlets basados en REST son más capaces de manejar los problemas del servidor. Si está recuperando miles de buzones de correo, lo último que desea es que Exchange Online cambie de controlador de dominio (sucede, incluso en la nube). PowerShell remoto fallará. Get-ExoMailbox probablemente se completará correctamente (los errores siempre son impredecibles).

El resumen ejecutivo es que algunos problemas a corto plazo al convertir scripts para usar los nuevos cmdlets se compensarán muchas veces con ganancias a largo plazo en rendimiento y confiabilidad. Es simplemente lo correcto, y a cualquiera que proponga escribir código usando los cmdlets antiguos se le debe pedir que reconsidere sus opciones con solo un toque de contundencia.