In some cases, PowerShell is not able to load modules. One example is after installing the gigantic (almost 1 GB) Microsoft Graph PowerShell module:
PS C:\> Connect-MgGraph -scopes "User.ReadWrite.All"
Instead of loading the module, you see the following error message:
Connect-MgGraph : The 'Connect-MgGraph' command was found in the module 'Microsoft.Graph.Authentication', but the module could not be loaded. For more information, run 'Import-Module Microsoft.Graph.Authentication'. At line:1 char:1 + Connect-MgGraph -scopes "User.ReadWrite.All" + ~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (Connect-MgGraph:String) , CommandNotFoundException + FullyQualifiedErrorId : CouldNotAutoloadMatchingModule
What’s up with that?
Check Your PowerShell Execution Policy
The most common cause of the “Module could not be loaded” error message is a restricted PowerShell execution policy.
If you haven’t been doing a lot of PowerShell scripting on the current system, this should be the first thing to check.
The following command will show you the current execution policy on your system:
PS C:\> Get-ExecutionPolicy AllSigned
An execution policy of “AllSigned” will block you from loading unsigned PowerShell modules, including the Microsoft Graph PowerShell modules.
You can use various settings (e.g., Unsigned, Bypass, etc.) and scopes (e.g., UserPolicy, Process, etc.) to modify the execution policy. Read this article for a complete overview.
For a quick fix to this issue, set the execution policy to unrestricted for the current process:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process
This setting will allow you to run unsigned scripts in the current session (only)
For a more relaxed scope, use “CurrentUser,” so you don’t have to worry about the execution policy next time you feel like PowerShelling.
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
With the modified execution policy, you should now be able to load the module:
PS C:\> Connect-MgGraph -Scopes "User.ReadWrite.All" Welcome To Microsoft Graph!
How to Avoid Complicated PowerShell Scripts
Let’s be clear: PowerShell is great for automation. But it stinks for ad-hoc support.
Fortunately, there’s a simple solution to allow first-level supporters to do their work quickly and efficiently:
Easy365Manager is a snap-in for AD Users & Computers that lets you do all daily Office 365 mailbox management directly from AD user properties.
This includes tasks like calendar delegation, that typically require complex PowerShell scripting:
Easy365Manager offers a lot of benefits that has made it an instant hit with companies and organizations worldwide:
- Manage everything from a single tool (no need for multiple, diverse web consoles).
- Well-known and intuitive user interface (AD Users & Computers).
- Eliminates attribute authority confusion (everything is managed in one place).
- Enables the removal of Exchange on-premises.
- Per-tenant licensing that supports unlimited users and admins.
- Simple installation with no infrastructure changes and no learning curve.
Read more about Easy365Manager here and download the free 30-day trial.