*This is the fifth article in a continuation of our weekly series celebrating the 10-year anniversary of Office 365; Part two Paul Robichaux details his experiences with the advent of cloud voice; In Part three Nicolas Blank shares his experience as a Microsoft Certified Master of Exchange 2010 and how he followed Exchange into the cloud; In part four, Randy Rempel reflects on his journey with SharePoint and how he changed the conversation with customers after the cloud offering.
The More Things Change the More They Stay the Same
It is surprising how little has changed in some parts of the service, at least when it comes to management. Yes, we have shiny new UI, but bulk actions, scripting, automation – it’s still often done with PowerShell, with or without making some calls to external APIs like the Graph.
Ten years ago, the MSOnline module was known as Microsoft Online Services Module for Windows PowerShell (MOSMWP) and featured many of the same cmdlets we continue to use to this day. And when it comes to Exchange Online, the Remote PowerShell experience is practically unchanged. Which in turn, means that admins who invested in learning PowerShell continue to reap the benefits.
Embracing a “PowerShell First” Mindset
I was one such admin. Just as Microsoft was releasing Office 365, I decided to make a career change and landed a position as a frontline support engineer in the EMEA center, serviced by HP at the time. While I had used PowerShell previously, it was at this time when I started to fully appreciate its robustness and challenged myself with embracing a “PowerShell first” mindset. In other words, whenever there was a task I had to perform, I tried to find a way to do it via the console. And there were a lot of tasks with Office 365 and its supporting infrastructure.
For cloud-only scenarios, the MOSMWP module quickly became my preferred tool for managing Office 365 objects and automation. The AD module covered hybrid scenarios, but it was Exchange Online Remote PowerShell was where things got serious. As the product itself was designed with PowerShell in mind, there was almost no task you couldn’t perform. Proper pipeline support, server-side filtering, inline help, support for -WhatIf, -Verbose, and -Confirm switches, the Exchange cmdlets really showcased what PowerShell can offer. Moreover, a vibrant community of Exchange server experts had already produced a multitude of script samples one could easily adjust to work against Exchange Online, or simply learn from.
Reaping the Reporting Benefits
Another area where PowerShell proved immensely useful was reporting. The original Microsoft Office 365 Portal (nicknamed MOP) did not offer any reports back then, so if you wanted to get some understanding of how the service is being used, you had to put something together yourself. Or “borrow” some code from the other members of the community and adapt it to your needs, occasionally learning a thing or two in the process. Even today, PowerShell remains the only way to report on some data.
Of course, lots of things have changed since, but PowerShell remains as useful. Thanks to PowerShell Core and Azure Cloud Shell, you can run cmdlets directly in the browser now, by clicking the corresponding button in the M365 Admin Center or the new Exchange Admin Center. Other workloads also released PowerShell modules, but unfortunately, none of them comes close to the experience we get for Exchange Online. In many cases, the available PowerShell cmdlets only serve as a “wrapper” to whichever API the workloads use, and don’t offer any of the “quality of life” features I’ve grown to love.
The underlying APIs have gone through several iterations, too. Nowadays, it’s all about the Graph API or equivalent RESTful endpoints, meaning you can perform most tasks via simple HTTPS requests. PowerShell of course has no trouble doing that, but in the process, it loses its appeal. What was once a beloved tool for IT Pros is slowly being replaced by tools designed by developers that have never touched the goodness that PowerShell can be. Not even Exchange Online has been spared, as the new EAC no longer uses PowerShell on the backend. Among other things, this means we lost the ever so helpful Show command logging feature.
Evolving With the Technology
In reality, the cloud exposed some PowerShell weaknesses, such as the performance issues when managing or reporting on large tenants; the reliance on WinRM, and basic authentication (remember when you had to install the Microsoft Online Services Sign-in Assistant to connect to MOSMWP?) and more.
In the way cloud services are designed and consumed continues to evolve, so will our skillsets. But thanks to Office 365, my PowerShell experience has improved immensely!
