The MSOnline module for PowerShell offers a convenient API to automate management of Azure AD resources like users and licenses.
Installing it is quite easy. And failure quite frequent.
This post will take you through the most common errors seen during installation of the MSOnline module.
How to Install the MSOnline Module
To install the MSOnline module launch PowerShell 64 bit in administrative mode and run the following command:
- Install-Module MSOnline
If everything works out well your MSOnline module is retrieved from the PSGallery and installed within a minute (subject to Internet bandwidth).
If, however, the result of running this command is complete and utter failure then continue reading.
The following sections will cover the most typical reasons why MSOnline module is not working out for you.
Check That You’re Running PowerShell 5.1 or Later
It’s a waste of time to examine all corners of your house if it’s actually the whole foundation that’s broken.
If you’re running Windows Server 2012 R2 or earlier or if you’re running an early release of Windows 10 or earlier, spend a few seconds to check your PowerShell version:
If you’re running PowerShell 5.0 or earlier make sure to upgrade. Read this article for instructions on how to install PowerShell 5.1 on your system.
Check Your Package Providers
When you’re installing modules from the PSGallery you’re using package providers to retrieve the module code. Package providers offer an easy way to automatically install and update code.
PSGallery is dependent on two package providers, NuGet and and PowerShellGet. Check the availability of these using the Get-PackageProvider command:
If NuGet is missing from your system install it using the Install-PackageProvider cmdlet:
- Install-PackageProvider NuGet
Check That You’re Running as Administrator
Running your script in an elevated PowerShell prompt is not a requirement as such. However, installing modules in a non-elevated prompt will place the modules in your user profile.
Storing PowerShell modules in your user profile may or may not be desired, but it definitely can lead to some confusion regarding module loading. I’ll cover that further down this post.
If in doubt, check your admin status using these two lines:
- $currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
If the output is ‘true’ the current prompt is elevated.
The ‘Install-Module’ command was found in the module ‘PowerShellGet’, but the module could not be loaded
Sometimes you may see an error message similar to this:
This means that your PowerShell execution policy is blocking execution of scripts.
Check your execution policy using the following command:
The above output indicates that you’re not allowed to run scripts and this needs to change.
As a bare minimum set the current process to allow execution of remote signed scripts using the following command:
- Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process
If you don’t want to run this every time you start a new PowerShell console you can set the scope to CurrentUser or LocalMachine depending on your temperament.
Package ‘MSOnline’ failed to download
Some cases may lead to this error message:
This error is caused by Microsoft disabling TLS 1.0 and 1.1 support on the PSGallery around end of March 2020.
This can be resolved by enabling TLS 1.2:
- [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
After running this command retry your installation from the PSGallery.
PackageManagement\Install-Package : A command with name ‘Get-MsolUser’ is already available
If commands in the MSOnline module are conflicting with existing commands on your system you’ll see an error message similar to this:
The error message is quite clear: To solve this type of issue use the -AllowClobber switch. This will allow the MSOnline module commands to override any commands already existing on your system:
- Install-Module MSOnline -AllowClobber
PowerShell Module Side-by-Side Installation
PowerShell modules can be installed side by side and in different locations.
In general you’re targeting two different folders when installing PowerShell modules on your system:
- Installing modules from a non-elevated PowerShell console will place modules in your user profile:
- (replace ‘Documents’ with localized name if non-English)
- Installing modules from an elevated PowerShell console will place modules in Program files:
This means you can e.g. have MSOnline version 1.0 and 18.104.22.168 installed in your user profile AND version 22.214.171.124 and 126.96.36.199 installed in program files. As is exactly the case seen here:
And now, the 10,000 $ question is of course:
What is the PowerShell Module Load Order?
To understand the PowerShell module load order you must first examine the module path variable, $env:PSModulePath. On my system it looks similar to this:
(The first two module paths are the most interesting as this is where we dump modules that we install from PSGallery).
By default, PowerShell will load the highest version number of the module in the first folder in the module path where the module is found.
Let’s do a small test:
We have four versions of MSOnline installed in two different folders:
We load the MSOnline module explicitly by running the following command:
- Import-Module MSOnline
The first folder in the PS module path is: ‘C:\Users\SOGP50\Documents\WindowsPowerShell\Modules’.
The highest MSOnline version in the first path is 188.8.131.52.
And if we check the file handles generated for the MSOnline module, e.g. using Process Explorer we can confirm this to be the case:
Take a moment to let it sink in:
Even though I just installed the latest MSOnline module using an elevated prompt the older MSOnline version in my user profile is still getting loaded.
So make sure to tidy up different versions of your modules if you want to control what versions are getting loaded!
This concludes our small tour of installing and troubleshooting the MSOnline PowerShell module.
If a problem took you here I hope you were able to solve it and move on with your admin work.
If you’re looking for ways to further speed up your work, take a look at our tool Easy365Manager. We’re helping IT admins in Oceania, Europe and the United States to work smarter by consolidating all daily Office 365 tasks inside the Active Directory Users & Computers tool:
With Easy365Manager you can configure AD user properties, Office 365 licenses and Exchange Online mailboxes without logging into the multiple Office 365 web interfaces.
Save hours and headache every week. Get rid of your on-prem Exchange server. Download and test run the fully functional 30-day trial now, with free support by phone or email.