How to connect Microsoft Graph with PowerShell Best?

Connect-MgGraph is the entry point for the Microsoft Graph with PowerShell SDK, the module that replaced the deprecated AzureAD and MSOnline modules for scripting against Microsoft Entra ID, Exchange Online, SharePoint, Teams, and the rest of Microsoft 365. Every Graph cmdlet in a session — Get-MgUser, New-MgGroup, whatever you’re actually there to run — depends on how this one connects, which scopes it requests, and which identity it authenticates as.

There are two fundamentally different ways to use it: signing in as yourself for interactive, ad-hoc work, or authenticating as an application for anything that has to run unattended. Picking the wrong one for the situation is where most of the confusing errors in this SDK come from.

Connect To Microsoft Graph with PowerShell?

Install the module with Install-Module Microsoft.Graph -Scope CurrentUser, then run Connect-MgGraph -Scopes "User.Read.All" for an interactive, delegated sign-in — this opens a browser or uses Windows Web Account Manager and connects as you, limited to whatever scopes you request and consent to. For unattended scripts, use -ClientId, -TenantId, and either -CertificateThumbprint or -ClientSecretCredential to authenticate as an app registration instead of a person. On Azure-hosted compute — a runbook, VM, or Function — Connect-MgGraph -Identity uses managed identity and needs no stored secret at all.

Install the module first

Before you start, you must Install the Microsoft Graph PowerShell module. Start Windows PowerShell as administrator and run the command below.

Install-Module Microsoft.Graph -Scope CurrentUser -Repository PSGallery -ForceCode language: CSS (css)

That pulls in the full aggregate package and its resource submodules. If you only need a handful of cmdlets and want a lighter footprint — in a CI pipeline, for instance — installing individual submodules like Microsoft.Graph.Authentication and Microsoft.Graph.Users works just as well and imports faster.

Confirm it actually landed before you rely on it:

Get-InstalledModule Microsoft.Graph
Get-Command Connect-MgGraph -ErrorAction SilentlyContinueCode language: CSS (css)

If the module shows as installed but Connect-MgGraph still isn’t found, you’re almost certainly in a different PowerShell edition than the one you installed into — Windows PowerShell 5.1 and PowerShell 7 keep separate module paths. Import the authentication submodule explicitly to confirm:

Import-Module Microsoft.Graph.Authentication
Get-Command Connect-MgGraphCode language: CSS (css)

If you’re upgrading from the older v1.x SDK, expect command name clashes; Install-Module Microsoft.Graph -AllowClobber -Force gets past them.

Connecting interactively, as yourself

Connect-MgGraph -Scopes "User.Read.All", "Group.ReadWrite.All"Code language: CSS (css)

With no scopes specified, you get access to your own profile only — nothing else. Every additional permission the script needs has to be requested here, and each one you haven’t already consented to triggers a consent prompt, or fails outright if your account can’t grant it and no admin has pre-consented on the tenant’s behalf.

If a full browser sign-in isn’t practical — a jump box with no default browser, a remote session — device code flow is the fallback:

Connect-MgGraph -Scopes "User.Read.All" -UseDeviceCodeCode language: CSS (css)

This prints a code and a URL to visit from any device with a browser, and the PowerShell session waits until that sign-in completes elsewhere.

To connect as a different identity than your default cached one, or to avoid one script’s sign-in leaking into another session’s cached context, scope it to the current process:

Connect-MgGraph -Scopes "User.Read.All" -ContextScope ProcessCode language: CSS (css)

Connecting as an app, for anything unattended

Interactive sign-in doesn’t belong in a scheduled task or a runbook — there’s no human there to click through a consent prompt at 2 a.m. For that, you authenticate as an app registration instead of a user, using one of three credential types.

Certificate — the credential type Microsoft recommends for unattended scripts, since it doesn’t involve a plaintext secret sitting in a script or a vault entry that’s just a string:

Connect-MgGraph -ClientId "YOUR_APP_ID" -TenantId "YOUR_TENANT_ID" -CertificateThumbprint "YOUR_CERT_THUMBPRINT"Code language: JavaScript (javascript)

The certificate has to already be sitting in the local certificate store — Cert:\CurrentUser\My or Cert:\LocalMachine\My — before this runs; Connect-MgGraph doesn’t fetch it from anywhere for you. You can pass the certificate object directly instead of a thumbprint if you’ve already pulled it into a variable:

$Cert = Get-ChildItem Cert:\LocalMachine\My\<thumbprint>
Connect-MgGraph -ClientId "YOUR_APP_ID" -TenantId "YOUR_TENANT_ID" -Certificate $CertCode language: PHP (php)

Client secret — simpler to set up, weaker to operate, since the secret is a string that has to be stored and rotated somewhere:

$ClientSecretCredential = Get-Credential -Credential "YOUR_APP_ID"
Connect-MgGraph -TenantId "YOUR_TENANT_ID" -ClientSecretCredential $ClientSecretCredentialCode language: PHP (php)

Get-Credential here is just a convenient way to build the PSCredential object — the “username” is your app’s client ID, and the password prompt is where the client secret value goes. In an actual unattended script, pull that secret from Key Vault or your secret store rather than prompting for it live.

Managed identity — no stored credential of any kind, but it only exists on Azure-hosted compute:

Connect-MgGraph -Identity

For a user-assigned managed identity rather than the resource’s own system-assigned one, add its client ID:

Connect-MgGraph -Identity -ClientId "USER_ASSIGNED_IDENTITY_CLIENT_ID"Code language: JavaScript (javascript)

This is where a specific, easy-to-misread error shows up. Run -Identity from a laptop or any machine that isn’t an Azure resource with a managed identity actually attached, and it fails with something like ManagedIdentityCredential authentication failed: The character set provided in ContentType is invalid. That message has nothing to do with Graph permissions — it means there’s no IMDS endpoint to talk to, because managed identity is an Azure infrastructure feature, not a Graph SDK feature. It works from Cloud Shell, an Azure Automation runbook, an Azure VM, or an Azure Function; it does not work from a workstation, no matter how the script is written.

Checking and ending the session

Get-MgContext

This returns the account or app currently connected, the tenant, the granted scopes, and the auth type — worth checking before running anything destructive, especially in a script that might connect under more than one identity across its lifetime.

Disconnect-MgGraph

Signs out of the current context. Cheap to call at the start of a script, too, if you want to guarantee you’re not accidentally running under whatever was connected last.

“Insufficient privileges” isn’t a bug

Government and sovereign cloud tenants don’t authenticate against the same endpoints as commercial Microsoft 365:

Get-MgEnvironment
Connect-MgGraph -Environment USGov

For newer sovereign environments — Microsoft has been rolling out region-specific clouds under names like BleuCloud, DelosCloud, and GovSGCloud — the default Microsoft Graph PowerShell app registration isn’t usable at all; you need your own app registration and a recent enough version of Microsoft.Graph.Authentication to support it. Worth checking your installed version if a sovereign-cloud connection fails in a way that looks like an app registration problem rather than a credentials problem.

I hope I have been able to clearly explain the topic of Microsoft Graph with PowerShell to you.

Frequently Asked Questions

References

Microsoft — Connect-MgGraph (Microsoft.Graph.Authentication) https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.authentication/connect-mggraph

Microsoft — Use Microsoft Graph PowerShell Authentication Commands https://learn.microsoft.com/en-us/powershell/microsoftgraph/authentication-commands