Why We Write PowerShell (for Office 365) Like We Do?

No Error Checking, No Logging, Just Code…

A reader asked why the PowerShell examples in the book (and this site) are “just code.” It’s a reasonable question that deserves a reasonable answer.

PowerShell is a fantastic tool for Office 365 administrators. You can create your own solutions for many of the gaps that Microsoft leaves to be filled in the administration of different apps. But before you can fill anything, you need to know how to fill. We want to teach people what’s possible with PowerShell and Office 365 by showing them how to put together scripts to get real work done. The scripts work, but they are incomplete in the sense that they don’t represent professional production-ready code. And that’s just fine by us.

Every Tenant is Different

Every Office 365 tenant is different, which makes it awfully difficult to write a script to suit everyone. However, it’s possible to write a fully-functional script that illustrates all of the key functional points that need to come together to solve an operational problem. Our task is done when we publish an example in a blog post or a chapter in the book (and we have literally hundreds of scripts in Office 365 for IT Pros); the task of the reader only starts when they realize that a script might be useful in their environment. The work from that point might include bulletproofing the code to make it work better when errors happen (as they do); making sure that all the requisite modules are loaded and connected to with valid credentials; streamlining scripts by moving some code into functions to make the flow of commands easier to understand; and so on. You might even want to add some extra functionality, or use your preferred method to do something. Or if you’re working with Exchange Online, you might want to use the new REST cmdlets because they are more reliable and run faster.

Sometimes we even include comments in our PowerShell code
Figure 1: Sometimes we even include comments in our PowerShell code

In a nutshell, we consider our role is to create the basic skeleton of a script to inspire people to expand, enhance, and complete the code. We plant the idea; you take the idea on to completion. It’s a win-win for everyone.

Changes After Feedback

After this post was originally published, we received some great feedback about increasing performance for string handling in reports (you can read about this and and other interesting PowerShell tips online). As a result, we changed a bunch of example scripts that will appear in the December 2019 update for the Office 365 for IT Pros eBook. It’s a great example of community feedback in action and underlines yet again the value of the ePublishing model for technical books.


If you’re not convinced that you can deal with PowerShell, you might like to read the thoughtful article by Paul Cunningham explaining how he approaches writing new scripts. Other useful reads are on good PowerShell habits and code layout and formatting. But don’t adopt anyone’s ideas slavishly without thinking things through. Search for PowerShell solutions to different problems and browse some scripts published in repositories like Github to see how they’re put together and the techniques used, and then take those that make sense to you. Your code won’t be great at the start, but will get better with time and practice.

Don’t be too proud to fetch code from the internet and use it as the basis for what you want to get done. But always test code that you didn’t write to make sure that it does what you think it does. And then test it again, just to be sure.

If you want a book to consult, try the Practical PowerShell for Office 365 book by Damian Scoles (MVP). PowerShell shares the common problem with any book covering Office 365 in that the content changes all the time that topics discussed in a book might be completely different by the time you read the text. For this reason, look for books published in 2018 or later. Warning: there are many crap PowerShell books out there…

Now that we’ve told you just how horribly we write PowerShell code, let us redress the balance by saying that our code actually works. Which is why we proudly feature it in the Office 365 for IT Pros eBook. And if we find a problem, we fix it in the next monthly update.

2 Replies to “Why We Write PowerShell (for Office 365) Like We Do?”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.