Last Update: Sep 04, 2024 | Published: Mar 29, 2018
Because I come from the Exchange side of the Office 365 house, PowerShell is a natural tool for me to turn to whenever I need to do something with Office 365 that Microsoft hasn’t included in the admin tools. The PowerShell coverage for Exchange is deep and extensive, even in the cloud. By comparison, PowerShell is not well covered in other Office 365 applications. Skype for Business Online has some administration functions while SharePoint Online offers mediocre support. Planner has no support, and the first version of the Teams PowerShell module could be so much better.
Given the spotty coverage in other parts of the service, I guess it should come as no surprise that Office 365 administrators who do not have a background in Exchange might consider PowerShell to be an odd but sometimes useful command-line interface. But that’s not the case. Simply put, PowerShell is a core skill for Office 365 administrators.
It’s true that PowerShell has its quirks. Like any scripting language, PowerShell syntax can be baffling and obscure, so using an IDE is the best approach for someone starting out. Writing raw PowerShell in the console is for masochists.
PowerShell has significant scalability limitations too, especially inside Office 365 where throttling controls clamp down on anyone who tries to consume resources with abandon. PowerShell will not process tens of thousands of objects rapidly, but that’s not its purpose.
If you think you need to process large numbers of Office 365 objects, listen to the recording of the seminar by MVPs Alan Byrne and Vasil Michev. The techniques they explain will help you get the job done, but it won’t be quick.
The reasons why Office 365 administrators need to achieve a basic level of competency with PowerShell are varied. Here’s my top pick.
Beauty is in the eye of the beholder and Microsoft probably thinks that its admin tools are just fine, but some of the more interesting jobs you might want to do need you to plunge into PowerShell. A recent example is the provision of cmdlets to recover deleted items for users without the need to log into their accounts.
Another is the support article cited in my article on GDPR data spillage. The list of steps needed to discover and report all the holds in place for a mailbox that must be temporarily lifted to remove items is long and prone to error. Scripting the retrieval and release of holds for a mailbox would automate the process and make it easier to stand over in court, should the need arise to justify the removal of held information. Finally, I point to the need to enable mailbox auditing for new mailboxes to ensure audit data flows into the Office 365 Audit Log. This problem has been around for years and it’s surprising that Exchange Online does not enable auditing by default. But you can, with PowerShell.
Try to write down all the tasks that you think an Office 365 Admin will perform in a year. Once you get past the easy stuff like creating accounts, monitoring usage reports, and so on, it becomes increasingly difficult to anticipate just what admins will be called upon to do. The Office 365 Admin Center and the other associates consoles represent a lot of functionality, but there’s always the possibility that you might have to do something that isn’t available as a menu choice in a GUI.
Two recent examples are how to archive inactive Office 365 Groups (and Teams) and how to identify when Groups and Teams are not being used. Microsoft offers the Azure Active Directory expiration policy for Groups, but this is based on time (that is, a group expires after a set period) instead of activity, which creates the possibility that Office 365 could expire and remove your most important teams or groups even though they are in active use daily. You can easily recover the expired groups (within 30 days), but that’s not the point. It’s better to understand what groups and teams are active and act on that basis.
The group expiration policy has a GUI (in the Azure portal) to work with its settings, but many Office 365 features need admins to run some PowerShell commands to set things up. The Office 365 Groups policy is a good example. If you want to set up a naming policy or restrict group creation to a defined set of users, you need PowerShell.
Understanding how a technology works is a great way to master it. For instance, running the Get-MailboxStatistics cmdlet against a group mailbox reveals its contents. You might or might not be interested in this information, but it is surprising how often detail like this has proven invaluable.
I am not a programmer now. I used to be, with VAX COBOL and VAX BASIC, in the last millennium, but I can cheerfully hack away with PowerShell and get stuff done. Anyone can too. It’s not hard and a ton of useful examples and advice exists on the web (here’s a good start). Of course, you should never download and run a script in your production environment without carefully examining (and understanding) the code first, but that does not take away from the point that you are not alone.
Perhaps oddly, PowerShell can be fun too. A sense of achievement comes when a recalcitrant script finally works to make Office 365 give up some secrets or some piece of data becomes more understandable. Although Microsoft might create a perfect nirvana of administration within Office 365, tenant admins need some competence with PowerShell for the foreseeable future. The sooner you start, the better you’ll be.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.