Serie del décimo aniversario de Office 365: alimentación a través de PowerShell

*Este es el quinto artículo de la continuación de nuestra serie semanal que celebra el décimo aniversario de Office 365; La segunda parte Paul Robichaux detalla sus experiencias con la llegada de la voz en la nube; En la tercera parte, Nicolas Blank comparte su experiencia como Microsoft Certified Master of Exchange 2010 y cómo siguió Exchange hasta la nube; En la cuarta parte, Randy Rempel reflexiona sobre su viaje con SharePoint y cómo cambió la conversación con los clientes después de la oferta de nube.

Cuanto más cambian las cosas, más permanecen igual

Sorprende lo poco que ha cambiado en algunas partes del servicio, al menos en lo que respecta a la gestión. Sí, tenemos una interfaz de usuario nueva y brillante, pero acciones masivas, secuencias de comandos, automatización: a menudo todavía se hace con PowerShell, con o sin realizar algunas llamadas a API externas como Graph.

Hace diez años, el módulo MSOnline se conocía como Módulo de servicios en línea de Microsoft para Windows PowerShell (MOSMWP) y presentaba muchos de los mismos cmdlets que seguimos usando hasta el día de hoy. Y cuando se trata de Exchange Online, la experiencia de Remote PowerShell prácticamente no ha cambiado. Lo que, a su vez, significa que los administradores que invirtieron en aprender PowerShell continúan obteniendo los beneficios.

Adoptar una mentalidad de "PowerShell primero"

Yo era uno de esos administradores. Justo cuando Microsoft estaba lanzando Office 365, decidí hacer un cambio de carrera y conseguí un puesto como ingeniero de soporte de primera línea en el centro de EMEA, atendido por HP en ese momento. Si bien había usado PowerShell anteriormente, fue en ese momento cuando comencé a apreciar plenamente su solidez y me desafié a adoptar una mentalidad de "PowerShell primero". En otras palabras, cada vez que tenía que realizar una tarea, intentaba encontrar una manera de hacerlo a través de la consola. Y hubo muchas tareas con Office 365 y su infraestructura de soporte.

Para escenarios exclusivos de la nube, el módulo MOSMWP se convirtió rápidamente en mi herramienta preferida para administrar los objetos y la automatización de Office 365. El módulo AD cubría escenarios híbridos, pero fue Exchange Online Remote PowerShell donde las cosas se pusieron serias. Como el producto en sí fue diseñado teniendo en cuenta PowerShell, casi no había tarea que no pudiera realizar. Soporte de canalización adecuado, filtrado del lado del servidor, ayuda en línea, soporte para los conmutadores -WhatIf, -Verbose y -Confirm, los cmdlets de Exchange realmente mostraron lo que PowerShell puede ofrecer. Además, una vibrante comunidad de expertos en servidores Exchange ya había producido una multitud de ejemplos de scripts que se podían adaptar fácilmente para trabajar con Exchange Online, o simplemente aprender de ellos.

Aprovechando los beneficios de los informes

Otra área en la que PowerShell resultó inmensamente útil fue la de informes. El Portal original de Microsoft Office 365 (apodado MOP) no ofrecía ningún informe en aquel entonces, por lo que si deseaba comprender cómo se utiliza el servicio, tenía que armar algo usted mismo. O “tomar prestado” algún código de otros miembros de la comunidad y adaptarlo a sus necesidades, aprendiendo ocasionalmente un par de cosas en el proceso. Incluso hoy en día, PowerShell sigue siendo la única forma de generar informes sobre algunos datos.

Por supuesto, muchas cosas han cambiado desde entonces, pero PowerShell sigue siendo igual de útil. Gracias a PowerShell Core y Azure Cloud Shell, ahora puede ejecutar cmdlets directamente en el navegador, haciendo clic en el botón correspondiente en el Centro de administración de M365 o en el nuevo Centro de administración de Exchange. Otras cargas de trabajo también lanzaron módulos de PowerShell, pero desafortunadamente, ninguno de ellos se acerca a la experiencia que obtenemos con Exchange Online. En muchos casos, los cmdlets de PowerShell disponibles solo sirven como "envoltorio" para cualquier API que utilicen las cargas de trabajo y no ofrecen ninguna de las funciones de "calidad de vida" que me encantan.

Las API subyacentes también han pasado por varias iteraciones. Hoy en día, se trata de Graph API o puntos finales RESTful equivalentes, lo que significa que puede realizar la mayoría de las tareas mediante simples solicitudes HTTPS. PowerShell, por supuesto, no tiene problemas para hacer eso, pero en el proceso pierde su atractivo. Lo que alguna vez fue una herramienta muy apreciada por los profesionales de TI está siendo reemplazada lentamente por herramientas diseñadas por desarrolladores que nunca han tocado las bondades que puede ser PowerShell. Ni siquiera Exchange Online se ha salvado, ya que el nuevo EAC ya no utiliza PowerShell en el backend. Entre otras cosas, esto significa que perdimos la siempre tan útil función Mostrar registro de comandos.

Evolucionando con la tecnología

En realidad, la nube expuso algunas debilidades de PowerShell, como los problemas de rendimiento al administrar o informar sobre grandes inquilinos; la dependencia de WinRM y la autenticación básica (¿recuerda cuando tuvo que instalar el Asistente de inicio de sesión de Microsoft Online Services para conectarse a MOSMWP?) y más.

A medida que la forma en que se diseñan y consumen los servicios en la nube continúa evolucionando, también lo harán nuestras habilidades. ¡Pero gracias a Office 365, mi experiencia con PowerShell ha mejorado enormemente!