Skip to main content


Office 365 – Why PowerShell Version Matters

Just a quick post today on a topic that is loosely related to Office 365 but certainly can be important…
It’s no secret that a good part of the management within Office 365 is done via PowerShell. Whether you’re writing the scripts yourself or downloading scripts from the “PowerShell for Office 365” site, you’re going to be using PowerShell pretty regularly.
In my role, I’m often testing some scripts in a lab environment before handing them over to a client to run. The expectation is that they should execute the same in production as they did in my lab.
But what happens when the script doesn’t produce the same results in production?
Below is one little trick that should probably be a best practice for any scripts you’re handing off to someone else to run.

For the most part, different versions of PowerShell respond the same. Newer versions will always have additional features but if a command runs in two versions, it usually produces the same results.
I’ll occasionally get tripped up by someone running PowerShell 2.0, where “Export-Csv” does not have an “-append” switch, and you quickly hit a wall when that occurs.
What I don’t expect is to have a command run but produce different results.
Take for example the following:

PowerShell Version 2

PowerShell Version 3

So while PowerShell 2 did not return any assigned licenses, there were in fact licenses assigned to the user. Imagine if the next operation was to disable or delete any user without a license.
Are there other ways this command could be put together such that PowerShell 2 returns the same data? Absolutely. The point however is that a script run in a test environment under a different version of PowerShell can produce different results. And while I can advise my client of what version they “should” use to be consistent with my testing, that doesn’t always happen.
A quick solution is to add a “requires statement” in my script that forces a particular minimum version (the version I tested with).
This can easily be done by adding the following to your script:

#Requires -Version 3

Yes, the pound sign (#) is intentional there...
If a user tries to run the script in a version lower than 3.0, they will receive the following error:

That's it, just a simple statement that should probably be included in any code you're sharing. If you wanted to take it a step further, you could use other methods to ensure the script is run under the same exact version as you tested. Either way, something to think about when sharing or used shared scripts.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

Leave a Reply

Your email address will not be published. Required fields are marked *

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

Joe Palarchio

More from this Author

Follow Us