Site icon Office 365 for IT Pros

Installing the Entire Microsoft Graph PowerShell SDK Seems Like the Right Idea

Tony Redmond
Advertisements

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:

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).

Figure 1: Listing cmdlets from the Microsoft Graph PowerShell SDK

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.

Exit mobile version