Automating Office 365 with PowerShell and Flow

New Tools, New Tasks

When it comes to automating Office 365 operations, administrators have the choice of multiple tools. In the past, PowerShell was the tool, but recently I have seen several other tools grow in popularity. Just like Office 365 itself, automation doesn’t stay still.

PowerShell and Office 365

PowerShell is critical to Office 365. Behind the scenes, many Office 365 operational processes are coded in PowerShell. To me, the flexibility of PowerShell in the way that it goes from a single command to simple scripts to moderately complicated procedures right up to full-blown operational frameworks is very powerful.

In the hands of an expert (not me), PowerShell can do some remarkable things that possibly lie far beyond the expectations of its inventors. Take the script written by Vasil Michev to report the membership of Exchange distribution lists.

On the surface, this seems like a straightforward operation and there are many examples of how people have approached the problem posted on the internet. The basic idea is to use Get-DistributionGroup to return a set of distribution lists in the tenant and Get-DistributionGroupMember to expand the membership of each list. Things become more complex when you consider that lists might have dynamic membership, or that their membership can be made up from different mail recipient types, or that they can include nested distribution lists. The upshot is that the task is much harder when all the possible members of distribution lists are considered.

PowerShell Problems in Office 365

Good as PowerShell is in the hands of experts, it suffers from the fact that it is not universally available for all the Office 365 apps. Exchange Online has excellent support, SharePoint Online less so. Teams is just starting. Planner knows nothing about PowerShell, and so on.

PowerShell can be messy at times too. Microsoft doesn’t show much interest in adding PowerShell support for some Office 365 applications, nor does it seem able to consolidate modules together so that you can load a single set of cmdlets spanning multiple apps (supporting MFA) with one command.

The last downside is PowerShell’s inability to access user data, which is why other protocols (like Exchange Web Services) exist. This is not a problem if you only need to write operational procedures, but it can be limiting at times.

Considering Flow

Which brings me to the new world of automation tools available for Office 365 administrators. An example is worth a thousand words, so if you’re unsure that you need to go near tools like Flow and the Graph, have a look at a practical example from Lee Ford showing how to use Forms to collect a user request for a new team, Flow to orchestrate the steps to approve and action the request, and the Graph to create the new team complete with an owner.

If you’re unfamiliar with Flow, it will take you some time to work through the steps described in the article. The flow isn’t perfect because it lacks some steps, such as what happens if approval is not granted for a new team, and in production the flow would run from a service account rather than a user account. But that’s not the point – the flow shows you what’s possible without writing a line of code (OK, some JSON is involved) to bring together bits of Office 365 to accomplish a task.

New World of Automation

PowerShell is great. Used in the right way PowerShell helps administrators get lots of work done. But the world is changing and other possibilities for automation now exist. If you haven’t had a look at Flow, maybe it’s time for you to do so?

---

We include a whole chapter on Flow (Chapter 23) in the Office 365 for IT Pros eBook. And we have tons of PowerShell too. In fact, we’re fully automated.