Some Say It’s a Bad Idea to Install Every Microsoft Graph PowerShell SDK Sub-Module

An interesting article by Sam Ende made the case for not installing every one of the 38 sub-modules in the Microsoft Graph PowerShell SDK, not to mention the 171 sub-modules used by Azure PowerShell. The idea is that you review the full set of modules and only install the modules needed top run scripts. This is not a new notion. Azure Automation requires explicit installation of modules as resources for automation accounts before the cmdlets in the modules are used.

Advantages of Not Installing Every Sub-Module

Proponents of the idea cite several advantages. Taking the Graph SDK as an example, let’s discuss them:

Faster Auto-Import and Tab-Completion: Auto-import is what happens when a script references a cmdlet that isn’t already loaded into the session. If the module containing the cmdlet is installed, PowerShell loads it. Tab completion is what happens if you enter a partial cmdlet name and press tab. PowerShell cycles through the set of matching cmdlets for you to chose from. It makes sense that auto-import and tab completion will function faster when less processing is needed and I do see a slight delay when an SDK cmdlet is first referenced, but overall, I think the gain is marginal.

Reduced Memory Usage: Every module that’s loaded into a PowerShell session consumes some memory. On a theoretical level, if a session loads every SDK module, it might consume a lot of memory. However, auto-import means that PowerShell only loads modules when necessary, so I’m not worried about memory consumption on a modern PC.

Avoiding Conflicts: Because a cmdlet name most only be unique within a module, the possibility for cmdlet name clashes increases as the number of loaded modules mounts. However, Microsoft takes care of ensuring that SDK cmdlet names are unique (but very long at times), so this should not be an issue, even when beta modules and the Microsoft Entra module are considered. A bigger issue is Microsoft’s inability to coordinate module dependencies across products, something that still happens.

Improved Security: The fear is that unused modules might not be regularly updated. I assume the lack of updating is the fault of the user rather than the developer because Microsoft updates every module in the Microsoft Graph PowerShell SDK monthly using a process called AutoRest. If you automate module updating and make sure that this is done regularly, the fact that a few unused modules are on a drive shouldn’t be a concern.

Simplified Management: It’s true that the fewer components that must be maintained, the less chance that problems will sneak in to compromise an environment. However, if you perform periodic maintenance, all should be well. I use a script to maintain the full set of Microsoft 365-related modules (including Exchange Online, SharePoint Online, Teams, SharePoint PnP, DSC, etc.). Using PowerShell to manage PowerShell seems like the right thing to do.

From V2.0 on, the Microsoft Graph PowerShell SDK is divided into separate production and beta modules. I install the complete set of production and beta modules. I never know when a script will require a cmdlet that’s in a relatively underused module and prefer to have everything to hand at the expense of a little extra disk space (my automated script removes old versions of the SDK modules). I also install the Microsoft Entra module to keep an eye on its progress.

Determining Modules to Install

My preference is to install the complete Microsoft Graph PowerShell SDK. But if you want to reduce the set of modules, you must decide which to install. You can check each module to find the cmdlets it contains with the Get-Command cmdlet, like this:

Get-Command -Module Microsoft.Graph.Authentication | Sort-Object Name | Format-table Name, CommandType

Name CommandType
—- ———–
Add-MgEnvironment Cmdlet
Connect-Graph Alias
Connect-MgGraph Cmdlet
Disconnect-Graph Alias
Disconnect-MgGraph Cmdlet

An analysis of all the Graph SDK and Entra module cmdlets can be accomplished by extracting details of the cmdlets from all the modules. Here’s code to do the job:

$Report = [System.Collections.Generic.List[Object]]::new()
[array]$Modules = Get-InstalledModule -Name Microsoft.Graph.* | Select-Object Name, Version | Sort-Object Name
Write-Host (“{0} Microsoft Graph modules found” -f $Modules.Count)
ForEach ($Module in $Modules) {
Write-Host (“Processing module {0} version {1}” -f $Module.Name, $Module.Version)
If ($Module.Name -ne “Microsoft.Graph.Beta”) {
[array]$Cmdlets = Get-Command -Module $Module.Name
ForEach ($Cmdlet in $Cmdlets) {
$ReportLine = [PSCustomObject] @{
ModuleName = $Module.Name
ModuleVersion = $Module.Version
CmdletName = $Cmdlet.Name
CmdletType = $Cmdlet.CommandType
}
$Report.Add($ReportLine)
}
}
}
$Report | Sort-Object CmdletName | Out-GridView -Title ‘Microsoft Graph Cmdlets’

The script will take some time to run. On my PC, it reported 25,130 cmdlets in 38 Graph (production) modules, 44 Graph (beta) modules, and 2 Entra modules (Figure 1). Your numbers might differ depending on the version of the SDK (I used 2.23.0).

Another method is to check the modules loaded in an interactive session after running some representative scripts. Here’s what’s reported for my current interactive session.

Get-Module | Where-Object {$_.Name -like “*Graph*”} | Format-Table Name, Version
Name Version
—- ——-
Microsoft.Graph.Authentication 2.23.0
microsoft.graph.beta.calendar 2.23.0
microsoft.graph.beta.identity.directorymanagement 2.23.0
microsoft.graph.beta.people 2.23.0
microsoft.graph.beta.users 2.23.0
microsoft.graph.beta.users.actions 2.23.0
microsoft.graph.beta.users.functions 2.23.0
Microsoft.Graph.Calendar 2.23.0
Microsoft.Graph.DirectoryObjects 2.23.0
Microsoft.Graph.Groups 2.23.0
Microsoft.Graph.Identity.DirectoryManagement 2.23.0
Microsoft.Graph.Mail 2.23.0
Microsoft.Graph.PersonalContacts 2.23.0
Microsoft.Graph.Reports 2.23.0
Microsoft.Graph.Users 2.23.0

I can’t remember how long the session lasted (at least a few days) or what scripts were run (several), but this is a good indication of the modules that you actually use. The Microsoft.Graph.Authentication module is always required as without it you cannot authenticate.

A Personal Choice

Deciding what Microsoft Graph PowerShell SDK modules to install is a personal call. It is highly dependent on the objects that you focus on (like users, groups, and devices) and the actions taken in scripts. It might be worthwhile to check what modules you use as described above. You might then decide to trim what’s install or, if you’re like me, leave well enough alone and install everything.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.